WickedWhims nude top conflict advisory

[Heliotropic]

It's been a long meandering road to hone in on the problem my mod was having with WW's Overrides file, but after 5 pages and 3 updates we finally got there.

 

WW's Overrides file conflicts with all nude tops, but few have encountered the problem because by sheer serendipity the recommended nude replacement mesh, Better Bodies, is packaged in a way that hides the problem.  Its nested folder structure leads a majority of users to simply drag either the BB 1.5 folder or the Male/Female folders into their mod folder while having WW in its own folder, either the default WickedWhimsMod or some similar name.  The result is that the desired mesh is in the same layer of folders in a folder that comes before the WW alphabetically and this, it turns out, just happens to be the arrangement Sims 4 needs to load the desired mesh into the game.

 

If you take Better Bodies' or any default female top replacement files and put it in:

• Any folder higher in the hierarchy than WW (i.e.: in the \Mods\ folder while WW sits in \Mods\WickedWhims\)
• Any folder in the same layer of the hierarchy that comes after the WW folder alphabetically (i.e.: in \Mods\Wj\ while WW is in \Mods\Wi\)
• The same folder as WW (i.e.: all files sitting loose in the \Mods\ folder with no sub-folders)

You will not see the modified mesh in your game, you will see the default mesh.

 

This may be an impasse because I assume WW needs to point to the game's nude assets a great deal and this conflict is probably coming from it being loaded after the modified mesh and necessarily pointing to a default resource.  Whether it is or not, it's worth documenting the issue and how to work around it.

[Buddy16]

So to make it clear if I create 2 folders:

                                                                  1.\mods\WH

 

                                                                  2.\mods\WW

 

and I put the top replacer of my choice in the WH folder and the WW overrides package in the WW folder the replacer of my choice is used instead of the Wickendwhims one or do I need to put all my wickedwhims package files into the WW folder?

 

[Heliotropic]

So to make it clear if I create 2 folders:

                                                                  1.\mods\WH

 

                                                                  2.\mods\WW

 

and I put the top replacer of my choice in the WH folder and the WW overrides package in the WW folder the replacer of my choice is used instead of the Wickendwhims one or do I need to put all my wickedwhims package files into the WW folder?

 

The Overrides file is the only one that seems to be conflicting, but when I did my tests I kept all WickedWhims files together.  I would keep all WW files together in a single folder and install mesh replacement mods in the other.  I personally dump all CAS mods into a folder named "CAS" which works out fine.  So long as it's in any folder that comes before your WW folder you're golden, so \WH\ would work if WickedWhims is in \WW\.

[Buddy16]

alright I did some testing myself now with some top replacer and all worked the way you described in your first post except this one  http://www.loverslab.com/topic/79210-sims-4-eve-mesh-body-v2/    the default replacer eve body top for some reason this top works if it's on the same folder as wicked whims so maybe you can have a look at that top maybe you find a way to add the same behavior to your nude top

[Heliotropic]

Good catch.  Cracking open EVE's top mesh in S4S I find all flags and values to be identical.  However, using Sims4PE I can see that the TGIOffset and TGIBlockList are not.

 

The TGIBlockList seems to list other assets the CASP file is pointing to, which makes it the likely culprit.  I suspect that my and other mods used an older version of S4S and/or TS4 to generate this file, and by extension, these lists when we first started making our mods.  After something updated EVE added a default replacement and S4S/TS4 has changed something about how this list is generated or what it's pulling from.  Starting a new Override project with the nude mesh yields a different TGIBlockList, and using that CASP file does in fact allow the mesh file to override WW's Overrides file no matter where it is in the hierarchy.

 

I can't find much information on what information exactly is being handled by the TGIBlockList so what specifically is going on is hard for me to discern.  It looks like it's pointing to the 4 GEOM files within its own package and 2 additional files, those additional files are what changed since regenerating the CASP file.  The CASP in WW's Overrides has the same list with the same TGIBlockList, which was different but is now identical.  If I had to guess I'd say that older mods using older CASP files were pointing to

 

0xAC16FBEC-0x80000000-0xFDC4902930068ACF

 

and saying "this is the nude asset, I'm overriding this", while newer mods and WW were pointing at 

 

0xAC16FBEC-0x00000000-0xB6DCAB99F33C43EE

 

and saying "this is the nude asset, use this, game".  So one package tells the game "use this data for the nude top CAS part" and the next one says "Don't use that CAS part at all for the nude top, use this one" which discards the modified CAS part.  Now that they're pointing at the same resource the one that loads 2nd no longer ends up changing where the game is looking.

 

I think.

 

TL;DR: Though the mods still technically conflict things can work better in future releases.

[Kestrel77]

Can it be something like that?

 

 

[TURBODRIVER]

If you load a Female Upper Body CAS Part before WW and it's properly tagged as a Default Nude Part everything should function just fine.

 

WickedWhims has to have this replacement because the game enforces top default bra on Sims in situations where these Sims have appearance modifiers applied. There is no other way to fix this other than removing that default bra.

 

As explained in this topic, any folder that is alphabetically before WickedWhims will be loaded first and this way take the priority, avoiding issues.

[Heliotropic]

Can it be something like that?

 

This looks like it should work.  If you're still having problems don't sweat it too much, the next release of Heavy Boobs will have an updated TGIBlockList which should avoid the conflict altogether no matter the load order.  Though this thread will still apply to legacy mods that were made using older versions like Anatomy tops and Better Bodies.

[Kestrel77]

 

Can it be something like that?

 

This looks like it should work.  If you're still having problems don't sweat it too much, the next release of Heavy Boobs will have an updated TGIBlockList which should avoid the conflict altogether no matter the load order.  Though this thread will still apply to legacy mods that were made using older versions like Anatomy tops and Better Bodies.

 

thx