sby said:
i don't know why, but the bras/waistband strings are very picky about being loaded before other mods
Confirmed. The load-order rearrangement will serve as a temporary workaround.
could be something to do with hair extender looking at other mods loaded
More or less. The ROPE elements assume that other elements (especially Static clothing elements) have been loaded beforehand*. They attempt to attach to named elements of the scene via dotted notation paths begining with "her" (rather than, let's say, relative paths which might begin with "parent").
*This "context" is established by the modder - by placing the registerMod statements in the appropriate order, so as to populate the _mods array in the same order (with the implicit assumption that SDT code and mod code will always traverse this array incrementally from index 0).
The proximate problem is that the dynamicHairExtender code fails to catch the error locally, and hence it gives a confusing error message.
That's been patched.
The intermediate problem is that these paths really
are invalid at the moment when SDT attempts to load the ROPE object.
The ultimate problem is that the layers are not being managed properly. It's a combination/overlap issue involving
moreClothingv5_1 and
TemplateExtensionV5_sby. If I exclude the template extension (by reclassifying the BRA into a TOP) then it will load properly under moreClothing (or conventionally) -- no problems occur.
More specifically, the visual hierarchy looks like this after the first BRA mod is loaded:
[her]
∟[torso]
∟[breastCostume]
∟[bra]
∟[rightBreast]
∟{masks, sprites, etc}
If we load a SECOND bra mod with Overwrite=True, then the [rightBreast] element gets cleared out (all children removed) but it doesn't actually get deleted. moreClothing then instantiates a new element (also named "rightBreast") to contain the incoming mod elements.
[her]
∟[torso]
∟[breastCostume]
∟[bra]
∟
[rightBreast]
∟[rightBreast]
∟{masks, sprites, etc}
This process repeats itself -- we can end up with three or more [rightBreast] elements, if the moreClothing configuration file includes additional CostumeBra items.
The problem has presumably not been encountered previously because few modders have actually
used the CostumeBra template. They've instead created TOP mods and relied on the moreClothing reclassification operator (>) to
present them as Bras in the GUI.
The multiple-instantiation issue is not fatal on its own. It is only a problem because I
assumed that the BRA layers would behave in the same way as the TOP layers. When the dynamicHairExtender code attempts to load a ROPE object, it uses its dotted-notation logic to lookup the appropriate attachment element in the visual hierarchy. If we're dealing with a 2nd-or-later BRA mod, being loaded via moreClothing, then the dotted path is unreliable. The lookup function will grab the
first [rightBreast] element (one of the "derelicts"), attempt to lookup a named child, fail (because the derelict element
has no children), and then we're in a fault scenario.
Potential solutions
- sby - investigate the moreClothing and/or templateExtension code. Modify the code so that it will reuse the original element (which I've disparaged as "derelict" ) instead of instantiating a new one.
- I'll send you a PM if I can identify a specific code fragment which seems to be at fault
- stuntcock - alter the dynamicHairExtender lookup logic so that it searches back-to-front instead of front-to-back. Hence, it will skip the derelict elements and always use the newest one.
- tested; works; the resulting code is somewhat inelegant and brittle
- stuntock / Huitznahua - reclassify the BRA mods as TOPs and re-release. They'll appear silly if used in combination with actual TOP clothing, but they at least wouldn't crash during loading.
- tested; works; some adverse effects on gameplay and compatibility
And yes I'm currently working on the Miki Hoshii outfit.
