Ouroboros

Essentially the question is; why is this the way it is? If the limitation of adding spaces invalidates the use of blueprint names is intentional, why is it so? Or is this a case of the code behind calling blueprint names breaks if you use a space and it's not worth the effort to try and remedy that?

reading is for nerds, don't @ me nerd

I am blind, but also; if spawning blueprints via name is permissible, why explicitly break them if spaces are included?

• Type of Bug: Invalid characters allowed in blueprint names. • Description: If a space is included in the name of a blueprint, it will return a success at saving it, but then become impossible to spawn or interact with using that name. • Evidence (Chat message/Screenshot): Attached screenshot. • Steps to reproduce: Create a blueprint, include a space in the name, then attempt to spawn the blueprint with that name. It will return an invalid result; the ID can still be used to delete, spawn etc but the name function is broken. By comparison a blueprint without spaces in the name can be successfully interacted with using that name. • Expected result: Blueprint should either return a refused request to include spaces in the name, or if allowed, succeed at spawning them using that string. • Observed result: Blueprint instead successfully saves as a now invalid name; compared attempts with and without space in the name, without space succeeds. • Reproduction rate: 100%.

• Type of Bug: Graphical Rendering Error • Description: This bug appears exclusive to my phase and I can't determine what the cause is, or how to replicate it; the eps_emptywmo_gilneas_garrison_magictower_v3 - 879568 is rendering with the wood trim ignoring all light sources, defaulting to a bright lighting. Attached picture for examples; tested with other players and determined that it only does this in my phase. Skyboxes don't seem to be the culprit, after using the reset all confirm command to make certain they weren't changed, relog and restart of client don't fix the issue. Same is true of phase weather. This isn't a very helpful bug report, because I have absolutely no idea what's causing this or even where to begin on process of elimination after confirming weather and skyboxes aren't at fault. • Evidence (Chat message/Screenshot): Attached screenshot. • Steps to reproduce: Absolutely no clue. • Expected result: Model should be rendering with the wood trim being impacted by ambient lighting. • Observed result: See attached screenshot; parts of the wood trim render as hyper-lit. • Reproduction rate: 100% for me, but no clue on how to actually provoke this error.

Problem figured out with Raz's help; the issue is that outfit components roll over if you go above the maximum, which then disables modifying other features; example being Male Dwarves only have 24 hairstyles so if you go above that and then try to change haircolor, it will fail. Entirely different issue to what I'd thought.

As of this post, the following races have no valid haircolor options beyond option zero; Orcs, Dwarves, Tauren, Draenei, Pandaren and Void Elves. In addition to this, the following races now have no valid face options beyond option zero; Nightborne, Highmountain, Lightforged, Zandalari, Kul Tiran, Dark Iron, Vulpera, Mag'har and Mechagnomes.

• Type of Bug: Phase Forged NPC Customisation. • Description: Cosmetic options are missing from .phase forge npc outfit face for Gnome Females. • Steps to reproduce: Create a phase forged npc, set their race to 7 (Gnome), gender to female. Any face choice besides 0 is listed as an invalid option. • Expected result: Should return valid choices up to at least face 9. • Observed result: [NPCOutfit] Invalid face. • Reproduction rate: 100%

As well as it still being an issue as of last restart, terrain cut gobs now have a warning message that prints with each spawning. This pushes unaware people to attempt using the cutting tool without being aware that it still erases all cuts post-reset.

• Type of Bug: Streaming Error (WOW51900322) • Description: Streaming Error caused via use of 9.0 SL .wmo assets. • Evidence (Chat message/Screenshot): Follow steps below to replicate. • Steps to reproduce: Enter into owned phase, spawn in any of the 9.0 SL .wmos, teleport away. Streaming error will ensue. • Expected result: Streaming error as in attached screenshot. • Observed result: As above. • Reproduction rate: Some variability on how many teleports it initially takes to start causing streaming errors, but has a 100% success rate after the second teleport for my client. • Additional information: Razmataz already mentioned on discord that this is a known quality; he stated it's not related to the -1 supervisibility status but the LOD rendering. Writing this up for posterity; would be cool if someone could update the announcement about supervisibility causing it when it's caused just by them being used at all.