Mesh Extended Swap System

[iamnoone]

View File

---

Dynamically switches armor/clothing replacers (meshes) based on races, bodytypes, and player.
Break Armor and TamagoSetBody conversions included.

 

What does this do?

 

- NPCs with different bodytypes can have separate equipment replacement meshes. No longer a "one size fits all."
- The player-character (PC) can have an entire replacer set just for him/her.
- Each race can also have their own replacer sets to better reflect their unique traits.
- TamagoSetBody conversion to be compatible with the other MESS mods.
- Break Armor conversion will detect other MESS mods and search for BA meshes in MESS replacement paths.

 

How does this work?

 

MESS uses Blockhead to handle mesh swapping.
When MESS mods have an overriding replacer available they will submit it to blockhead with a priority value.
When multiple mods compete for a particular item swap Blockhead picks the highest priority.

 

What does it have?

 

* SetBodyMess.esp - Swap clothing/armor meshes according to SetBody bodytypes
* RaceMess.esp - Swap clothing/armor meshes according to race
* PlayerClothingReplacer.esp - Swap clothing/armor meshes for player character

 

* BreakArmor.esp - Armor will visually go through stages of degradation (breaking) as its health decreases. (converted and enhanced for MESS)
* TamagoSetBody.esp - Switches clothing/armor/bodytypes for pregnant actors using TamagoClub (converted for MESS)

 

* Blockhead.dll - Features equipment mesh swapping
- Included file is current beta available at time of this release (version 11.0.10.307)
- Big THANKS to shadeMe for distribution permission

 

How many do I need?
- Blockhead is needed to use any of the esp files in MESS.
- SetBodyMess, RaceMess, PlayerClothingReplacer are all optional, and you can install whichever one(s) you want.
- Break Armor (MESS conversion) is recommended if using BreakArmor and any MESS mods.
- TamagoSetBody (MESS conversion) is recommended if using TamagoSetBody and any MESS mods.

 

Requirements
* Blockhead (ver 11.0.10 or later) (Included)
* PlayerClothingReplacer.esp - [meshes]
* SetBodyMess.esp - SetBody.esp
* RaceMess.esp - [meshes]
* TamagoSetBody.esp - TamagoClub, SetBody, [Pregnant meshes](Tamago Outlet)
* BreakArmor.esp - [break armor meshes] (BreakArmor for Vanilla Armors, BU Armors Compilation)

 

Installation
0. Install requirements

 

Wrye Bash
1. Tick boxes of desired mods
2. install

 

Manual
1. Put esp files in data
2. Put ini files in data\ini

 

3. Configure ini files (see documentation)

 

Issues and Stuff
Issue: Included Blockhead.dll does not automatically unequip (player's) item when switching to new one.
Solution: manually unequip the unwanted items

 

Credits/Thanks
movomo
shadeMe
ger4
gerra6
Kormgar
[everyone involved in the original mods]

 

Version History
[2.2]
* SetBodyMess.esp
- Added Unlimited pathsets for a bodytype combination and ranking
- Added Scanning for all possible pathsets for a bodytype and return highest ranking one

[2.1.1]
* RaceMess.esp
- Fixed: Multiple entries not registered

 

[2.1]
* BreakArmor.esp
- Added partial support for bound items
- Removed legacy bloat purging
- Minor bug fixes

 

* RaceMess.esp
- Fixed Initialization

 

* SetBodyMess.esp
- Fixed Initialization

 

* PlayerClothingReplacer.esp
- Fixed Initialization

 

* TamagoSetBody.esp
- [no changes]

[2.0]
* RaceMess.esp
- First Release

 

* BreakArmor.esp
- Added MESS mod polling
- Finished purge delay timer
- Minor bug fixes
- First (MESS) Release
- Base version 1.10f

 

* SetBodyMess.esp
- Inter-MESS compatibility
- Cleaned up scripts

 

* TamagoSetBody.esp
- Inter-MESS compatibility
- Restored original workings (e.g. ActionQueue is back)

 

* PlayerClothingReplacer.esp
- Inter-MESS compatibility

 

[1.1]
* SetBodyMess.esp
- All four SetBody slots supported
- Tiny optimization tweak
- Dropped wildcard/none options in ini (now always wildcard)

 

[1.0]
* SetBodyMess.esp
- First release

 

* PlayerClothingReplacer.esp
- Fixed bug in input santization

 

[0.2]
* TamagoSetBody.esp
- Removed more action queue remnants
- Removed no longer needed cleanup script
- Restored initial equip cycle

 

* PlayerClothingReplacer.esp
- Added prefix/suffix feature
- Debug logging now optional

 

[0.1]
- Initial release

 

---

• Submitter
  iamnoone
• Submitted
  08/19/2016
• Category
  Other
• Requires
  Blockhead (beta), OBSE

 

[movomo]

Very interesting and nice job. I especially love the name! Since I actually gave some thoughts several months ago... (you probably know where it is) I think I can help. I got several ideas and requests for the framework, too.

 

I decided not to actually make it at that time because Blockhead's new per-reference clothing swap didn't sound good enough to me. It was possible to implement the priority system without Blockhead, but I thought it isn't a radical improvement enough to bear the work of writing a new framework from scratch and rewriting three or more existing client plugins.

 

Hmm.. these function limitations don't sound good. Especially the 'override model source form must be present in the calling plugin' part... Perhaps this can be better without blockhead. I'll have a look shortly, anyway.

[iamnoone]

There's definitely some kinks and hurdles with this and a non-central system in general.  Especially, how to handle combinations, if such things exist.  I don't use BA so I don't know if there are BA pregnant meshes.   Even custom player-only pregnant meshes wouldn't be too farfetched (maybe).  Seeing as we don't have an existing framework mod, it seemed the blockhead route would be an alternative since it was there.  Also, I have no clue how to do a mesh update other than the action-queue system. update3D?

At the time I started, I didn't know it was going to take such a long way around.  The conversion process does feel like a hack, but appears to work.  I'm kind of surprised in a way since I do use the same dummy variables in the same frame for multiple NPCs, but blockhead appears to update after each NPC.  Definitely NOT after each call to the handler since re-using a single dummy variable for each call did not work.  Only the last mesh swap for an NPC would work in that case. Hence, dummy variables for each slot. 

 

I was wondering what other clients would be a part of this?  I only know these 2 + BA.  I was going to peek into Break Armors, but time and fear are holding me back for now.

 

RE: the name (which really is the most important part of this project)

Yes, I did see your ASS and I liked it...and if I did go with it, then I would have had to name it movomo's ASS.  Then, people would have thought you wrote it, and in the end it would be a big...(wait for it)...mess. UGH! Really that's not where it came from though.  I wanted some GNU style name MESH - Mesh Extended Swap H_____ , but didn't come up with a satisfactory H...also it would have been too vague having it in a load order or directory.  So it went MessyMesh->MeshMess -> MESS.

[movomo]

Ok. Let's say we will never have breakable pregnant meshes. That's reasonable enough... but player-only preg and player-only ba are a very real possibility. We can have such thing even right now. I imagine prg+ba in TSB gave you quite a headache, let's rewrite that part so that it would ignore ba completely and attempt to parse _pconly instead. Should be a bit simpler.

 

My request was originally this -> to take Break Armor into consideration when building framework. But you're already (kind of) doing that. Well.. Break Armor is simpler than Tamago, so no worries.

Then this -> to make this a centralized master plugin so that you won't need to write redundant codes in multiple plugins. But again, if you're going to use Blockhead, it is already dealing with the swap priority, which is why a separate plugin was needed when implemented without Blockhead. Perhaps we won't need to come up with a cool name like MESS at all since such thing won't be there in the first place. Still it will be convenient to have a separate plugin, though.

 

My other suggestions were like having some utility functions: such as recursive array prettyprinter (very convenient to have in a separate library), filename parser (aka permutation maker, something every mesh-swapper can make use of). Or ability to set the "degree of urgency" that controls exactly when the mesh swap/update should happen - probably not needed with Blockhead.

 

By the way, there is a tricky part in Break Armor. In PCR and TSR you cared about only *who* is equipping the armor. But in BA, not only who, *which* armor she is equipping also matters - that is armor health. I think it can be a bit hard to implement in blockhead way. BA can't be completely event-driven, something must watch the status of nearby actors constantly.

 

As for the "arEventRegistered" array in TSB; I needed that thing to keep track of registered actors because OBSE event handlers are not cleared unless you restart the game. If I'm reading Blockhead documentation correctly, EqOverride handlers by Blockhead are only valid within the current game session. That means if that's the case you don't need the "tsbrFnOnLoadGameCleanUp" function at all.

[iamnoone]

New version: 0.2 (update recommendation: HIGH)

 

TamagoSetBody.esp

The first version was very much a proof-of-concept, whereas this one is closer to an actual beta release.  More leftovers of the original were taken out, making less possible points of failure and conflict.  Had some (major) functionality restored that was broken in the initial release.  If player was in the same cell as an NPC that just got recognized as being pregnant than the appropriate mesh was not being swapped.  This situation and probably others should now be working.

 

PlayerClothingReplacer.esp

New feature - custom filename suffixes and path prefixes.  Filenames are no longer constrained to end in "_pconly".  Also, now you can put all the meshes in a separate folder structure without having to batch rename them.  Now you can organize by cup size or mod author or ...

 

I'm keeping the warning on the download page for now, but those reading this should feel less wary about this new version.

[Puuk]

By the way, there is a tricky part in Break Armor. In PCR and TSR you cared about only *who* is equipping the armor. But in BA, not only who, *which* armor she is equipping also matters - that is armor health. I think it can be a bit hard to implement in blockhead way. BA can't be completely event-driven, something must watch the status of nearby actors constantly.

Sorry to suddently jump in, but I didn't quite understand why BA needs to constantly monitor nearby actors. Since it just swaps meshes when necessary can't you just use OnHit-event?

[movomo]

 

By the way, there is a tricky part in Break Armor. In PCR and TSR you cared about only *who* is equipping the armor. But in BA, not only who, *which* armor she is equipping also matters - that is armor health. I think it can be a bit hard to implement in blockhead way. BA can't be completely event-driven, something must watch the status of nearby actors constantly.

Sorry to suddently jump in, but I didn't quite understand why BA needs to constantly monitor nearby actors. Since it just swaps meshes when necessary can't you just use OnHit-event?

 

 

I can't say BA can't be written in a different way. But event way has its own problems too.. For example,

- The OnHit event if I remember correctly, fires just before the victim is hit. To see if the armor should break after that particular hit, you need to check back later. You also need OnMagicEffectHit because there's the disintegrate effect.

- Not only hitting, but repairing is also one of the things that BA is interested. So you need to catch entering the repair menu and check later. Plus any other scripted repair events as well(such as companion auto repair).

- Simply changing the equipments must be able to trigger equipment check, because you don't know if their new armor can be ignored or not. Perhaps OnActorEquip on everyone....

[Puuk]

I can't say BA can't be written in a different way. But event way has its own problems too.. For example,

- The OnHit event if I remember correctly, fires just before the victim is hit. To see if the armor should break after that particular hit, you need to check back later. You also need OnMagicEffectHit because there's the disintegrate effect.

- Not only hitting, but repairing is also one of the things that BA is interested. So you need to catch entering the repair menu and check later. Plus any other scripted repair events as well(such as companion auto repair).

- Simply changing the equipments must be able to trigger equipment check, because you don't know if their new armor can be ignored or not. Perhaps OnActorEquip on everyone....

- When detecting a hit an event handler can add item to target's inventory. By attaching a script to this item and waiting just few frames before acting you can effectively monitor only those actors that are important. I used this tactic in my third version of Dynamic Underwear System to vastly reduce the impact it has on game. This most certainly would work with OnHit, I'm not sure if OnMagicEffectScript would require additotal consideration though.

- Repairing is something that I completely forgot. While detecting the repair menu is fairly simple with a simple Menumode block, I'm not sure about these 'scripted repairs'. However since this is probably only relevant when considering the PC or followers, I guess it wouldn't be too much to track with a quest script.

- OnActorEquip should work. Again I refer to my DUS mod, which does some similar things. Of course it doesn't swap meshes though.

 

I'm not saying that BU should be rewritten to use events. I'm just thinking of a way to unify all these things like SetBody, BU and Tamago. Because they are mainly written to work independently of each other (minus Tamago Setbody I think?), it would require a lot tinkering to make all of them work together. Blockhead could possibly have been the solution for this until that mesh limitation came apparent. While iamnoone has made some good results with such a limited function, I can't but doubt how all these complex systems would work together.

 

Every time I think about this issue I come to the solution that using just one framework for all these things would be best. When our target is about to equip something, one single OnActorEquip would run and check things in this order:

1. Gender?

2. Bodystyle?

3. Pregnant?

4. Broken Armor?

 

Example 1: we have a male target, but there are no male bodystyles in our database (excluding the default one game would use). Don't proceed.

Example 2: we have our male target again, but this time there multiple variations of a male body in the database. He will be assigned a random body variant if not already defined via token (probably best solution?). Since males can't be pregnant (unless for some reason someone really wants so and goes ahead to make all meshes etc.), we skip part 3 and look for an appropriate broken version of a mesh. In this case there isn't any, so we back up a little and just go with the body variant of what ever he is going to equip.

Example 3: we have a female target, who is pregnant and does have pregnancy meshes for her assigned bodystyle. She is also taken some damage and there is BA version of her equipment present so we proceed to change the mesh.

 

Example 3 probably doesn't happen since there would be too many permutations. Example 2 on the other hand is also unnecessary long process since there are no male BA variants that I'm aware of. This is easily fixed with some ini-settings (like I have 'ignoremaletops' in my DUS) to avoid any unnecessary processing.

 

About the actual mesh swap, I'm not quite sure how this is best implemented. If we can assing mesh path in the OnEquip-event so that it becomes visible I'd go with that. Otherwise I think that we after all should go the Blockhead route and do what iamnoone has achieved here.

[movomo]

By 'unify' it almost sounds like we must put all of these into just one single esp... is that correct?

[Puuk]

Yes. It was the most simple way to deliver my point across. I do aknowledge that it is not very good idea to do this in practice because this prevent further developement around it. Also something like Tamago is very complicated and not everyone's cup of tea so it wouldn't make sense to have all those scripts running. I guess that the actually best way to do this is to create a framework that handles all the actual mesh swap work and then have other mods attach to it. Maybe follow the Blockhead idea and assing every plugin a priority value that represent the folder structure. For example we have Tamago with the priority value of 10 and BA with 5. We start search from 'meshes\MESS\' folder. Tamago gets applied first and BA second so we try to find the mesh from 'meshes\MESS\tamago-X\ba-Y\', which should now represent the root folder of meshes, only with tamago's X and BA's Y stage applied to them. If we can't find the proper mesh, we forget that BA part and search from 'meshes\MESS\tamago-X\' and so on. Obviously if Tamago isn't active or the target pregnant we ignore it when searching and instead start from 'meshes\MESS\ba-Y'. The challenge here is to have our plugins inform the framework of these X or Y values, which may differ greatly from a mod to mod.

[movomo]

Yes.

Well, I was afraid you would say so... sort of.

 

I do aknowledge that it is not very good idea to do this in practice because this prevent further developement around it. Also something like Tamago is very complicated and not everyone's cup of tea so it wouldn't make sense to have all those scripts running. I guess that the actually best way to do this is to create a framework that handles all the actual mesh swap work and then have other mods attach to it.

But, since you do realize the practical limitations, I'd say it's the same as what I originally had in mind. But then, I decided that additional 'master' plugin is not needed with blockhead. I decided that anyone who is currently working on it has the best idea. Although we'll lose a good bunch of useful utilities by not making the separate esp, I think we should not make more plugin unless it's absolutely needed.

 

Of course, when we choose the blockhead way that is. If you're not going to use blockhead, it's indeed absolutely needed.

 

Maybe follow the Blockhead idea and assing every plugin a priority value that represent the folder structure.

Why folder? What advantages does it have over the current way (renaming files)? We'll have to totally and unquestionably break backward compatibility that way and it will be more difficult for the end users.

[iamnoone]

Version 1.0
-----------
With this major update I present you:

 

SetBodyMess - replaces clothing/armor meshes according to SetBody bodytypes.
-set folders or filenames on a per bodytype basis.
-(optional) specify a secondary location to fallback to.
The inner subfolders have to match what is being replaced. The important thing is you can just drop a whole archive of mesh replacers in a separate folder and just setup the ini. If you like the replacing meshes to be along side the originals, you can do that, too. You can even rename both the filename (suffix) and setup a separate folder.

Can't decide between Nailflan's originals and Nephenee's conversions? Why not both? Keep them in separate folders and let the bodytype decide which to use.

As part of the MESS, this is compatible with the existing converted mods, TamagoSetBody and PlayerClothingReplacer.

---
MESS is now officially out of the proof-of-concept phase and into beta.

[ger4]

With the limitations of the current Blockhead mesh swapping system, why doesn't someone bring them up with Shademe in the beth forums thread?

 

http://forums.bethsoft.com/topic/1603972-rel-blockhead/

[Puuk]

But, since you do realize the practical limitations, I'd say it's the same as what I originally had in mind. But then, I decided that additional 'master' plugin is not needed with blockhead. I decided that anyone who is currently working on it has the best idea. Although we'll lose a good bunch of useful utilities by not making the separate esp, I think we should not make more plugin unless it's absolutely needed.

 

Of course, when we choose the blockhead way that is. If you're not going to use blockhead, it's indeed absolutely needed.

The issue with Blockhead is that only the event with highest priority will be selected. If Setbody decides a target's body and BA the condition of item, you must choose which one you use. For every situation like this you need to have a patch that takes these both things into account somehow, as opposed to some kind of framework that handles all these issues.

 

Why folder? What advantages does it have over the current way (renaming files)? We'll have to totally and unquestionably break backward compatibility that way and it will be more difficult for the end users.

Nothing I say must be set in stone. When writing that I was thinking more about equipment replacers like EVE. It has a lot of meshes and editing the install path is less work than renaming everything it includes. After all, if you wish to have multiple models of same armor not every mesh can have the same name and be in same folder.

[movomo]

Ok, I was not considering per-body type swaps. I was only thinking about the 3: ba, tsb, and pc-only. Now that seeing you-Puuk and Iamnoone are doing the per-body swap, this makes more sense. Making sub-directories IS reasonable for the total armor conversions like EVE. I would suggest leaving the legacy naming convention of other plugins alone, though.

 

Nice work iamnoone, btw... I didn't get the chance to sit at my desktop. Would you ping Shademe yourself?

[iamnoone]

It sounds like it's back to BA and/or combination scenarios and the need for a framework.   I'm the least experienced here, so I'm trying to work through what we're trying to do.  Do let me know if I'm wrong (and preferably why so I understand).  This is a stream of free-floating thoughts...

 

Without running the thing I'm sure this MESS doesn't work with BA because isn't based on an OnActorEquip like all the others and has some other voodoo.  I'm under the impression that blockhead doing the actual mesh swap is better than the alternative.
The only way I see pounding this square peg (BA) into this round hole (beta blockhead) is being able to do an "equipitem" call on the same item without anything bad happening.  That's probably not a great assumption to be making.  Doing a re-equip of the same item will trigger the Blockhead equivalent of OnActorEquip.  It doesn't have to be unequipped to work and swap the meshes. Well it's worked for me fairly consistently in the MESS mods. Then we'd change the parts of the existing mods that do the mesh swaps to making calls to the framework plugin instead. (Make an option in their ini to use framework if available) . The framework would do the evaluation (more on this later) and make the re-equip decision.

 

All existing mod files stay as they are.  So where there isn't a conflict (or even a framework), everything is where it should be. The framework gets base mesh and new mesh passed in for sure (should probably a stringmap with various helpful fields). I should say "proposed" new mesh since it is still subject the combination check.   Depends on how we go about it, we can do suffix based and/or stage based parsing when setting up the framework.  Maybe allow both for more versatility.  Setup an ini option for that choice, too. 

 

I'm sure parsing and formatting rules can be worked out and all setup to be in the ini: the ini is where the work is involved.  It's up to the user/ini maintainer/modder to make Pregnant FLY Break Armors work.  I would like to think highly specialized combinations are rather rare.  So creating a robust general folder structure and have the framework do a bunch of permutations and searching would be overkill.  Such specific combinations should be setup in an ini.  They provide a mapping of primary mod's base mesh -> combined mesh when given status/stages/suffixes of the combining mods.  These mappings should be known ahead of time, right? It would take a certain set of circumstances for these meshes to even be used.

 

Would this work except for that whole needing to do an "equipitem" call?

 

What are we asking shadeMe to do exactly? Fix having it depend on equip events? having to use dummy variables?  I shouldn't be the one to ask, since I don't even know what to ask.  Besides, my last request didn't go over so well.

 

Are there other mesh swapping mods out there that could potentially use this framework?

 

 ---
Oh, I should say that SetBodyMess has the Blockhead equivalent of OnActorEquip on everyone.  It was written with autosetbody in mind where there were be a significant number of registered NPCs.  I have no idea what the actual performance hit in crowded cells would be with vs without NPC filtering.  It just seems like after a certain x number of NPCs registered it would start taking longer to check the list than letting them all in.   I may change it later.

[ger4]

Could someone make some example files showing how to use setbodymess? The setup seems quite complicated, so a "starter pack" with practical examples would be much appreciated.

[iamnoone]

Explaining things (actually communicating in general) isn't a strong suit of mine.  So the info in the ini is more overwhelming than it should be.  I just wanted to be thorough.
The main thing this mod does is match an NPCs body type to a set of clothing/armor replacers. 
Here's a quick example similar to the one in the ini, but uses DMRA.  That is, NPCs with DMRA bodies will have their vanilla equipment swapped with DMRA.

set SBMessIni.iBody1 to sv_construct "DMRABU" ;DMRA UpperBody Original
set SBMessIni.iBody2 to sv_construct "DMRAB" ;DMRA LowerBody Original
set SBMessIni.prefix1 to sv_construct "DMRA"  ;Data\Meshes\DMRA
setstage SBMessIni 15

To begin, the body codes are from Setbody Reloaded and can be found in "Body_Style_Code.txt" from the "core" archive of Setbody Reloaded Blockhead Edition.
The first line is the upperbody type, which in this case is DMRA  Original
The second line the lowerbody type, which is DMRA Original.
The third line is where the DMRA replacer files can be found.  "DMRA" expands to the path "Data\Meshes\DMRA".  The path "Data\Meshes\" is already implied.
The files and folders in the DMRA folder must follow the same naming as those being replaced.  If replacing vanilla armor/clothing, the subfolders and files should be the same as vanilla. 
E.g. "\Armor\chainmail\f\cuirass.nif"  =>  "DMRA\Armor\chainmail\f\cuirass.nif"
 
Then, when an NPC is encountered with DMRA upperbody AND DMRA lowerbody it will look for the replacing items under DMRA first.  If a replacing item doesn't exist, then defaults back to vanilla.
---
Now to expand this to include multiple bodies:
copy/paste the above block of code for each bodytype you want. 
For each block: set "ibody1" with upperbody code, set "ibody2" to lowerbody.  Assuming you make a separate path for each body style, set prefix1 to the path of that body.
 
---
There are other things in the ini for other scenarios.
suffix: changes the filename instead of the main path.  "\Armor\chainmail\f\cuirass.nif"  =>  "\Armor\chainmail\f\cuirass_DMRA.nif"
suffix2/prefix2: are secondary paths to search.  You could have HGEC_C, HGEC_E, HGEC_H paths with only the upperbody meshes and put all the files in common in separate path to avoid duplicates.

Example: HGEC C-cup/E-cup/H-cup

 

set SBMessIni.iBody1 to sv_construct "HGECBUC" ;HGEC C-cup
set SBMessIni.iBody2 to sv_construct "HGECBL" ;HGEC Large LowerBody
set SBMessIni.prefix1 to sv_construct "HGEC_C"  ;Data\Meshes\HGEC_C
set SBMessIni.prefix2 to sv_construct "HGEC" ;Data\Meshes\HGEC
setstage SBMessIni 15

set SBMessIni.iBody1 to sv_construct "HGECBUE" ;HGEC E-cup
set SBMessIni.iBody2 to sv_construct "HGECBL" ;HGEC Large LowerBody
set SBMessIni.prefix1 to sv_construct "HGEC_E" ;Data\Meshes\HGEC_E
set SBMessIni.prefix2 to sv_construct "HGEC" ;Data\Meshes\HGEC
setstage SBMessIni 15

set SBMessIni.iBody1 to sv_construct "HGECBUHA" ;HGEC H-cup type A
set SBMessIni.iBody2 to sv_construct "HGECBL" ;HGEC Large LowerBody
set SBMessIni.prefix1 to sv_construct "HGEC_HA" ;Data\Meshes\HGEC_HA
set SBMessIni.prefix2 to sv_construct "HGEC" ;Data\Meshes\HGEC
setstage SBMessIni 15

 

In this example, each cup size (C,E,H-A) has a separate path of replacers, but shares a common path "HGEC".  Since all bodytypes have the same lowerbody L, we can put common and "fallback" clothes in a shared folder.   Also, you could set the fallback to be the same as a previously used path.

 

set SBMessIni.prefix2 to sv_construct "HGEC_E" ;Data\Meshes\HGEC_E

 

Say if you don't have H-cup replacers for all items, but you do for E-cup.  Then, if an NPC with h-cup that doesn't have a matching replacer, it would attempt to wear the E-cup one instead.  Then if there isn't one in the E-cup path, it defaults to the original vanilla.

 

One last thing about the above examples, I'm not sure about the BBB style codes.  I believe they differ from original codes, but I didn't see them in the doc when writing this post.

---
If this doesn't help, you can tell me what you would like to try do.  If it's compatible with this mod, I can setup the ini.  Might be helpful to have more examples, anyway.

[ger4]

Explaining things (actually communicating in general) isn't a strong suit of mine.  So the info in the ini is more overwhelming than it should be.  I just wanted to be thorough.

The main thing this mod does is match an NPCs body type to a set of clothing/armor replacers. 

Here's a quick example similar to the one in the ini, but uses DMRA.  That is, NPCs with DMRA bodies will have their vanilla equipment swapped with DMRA.

set SBMessIni.iBody1 to sv_construct "DMRABU" ;DMRA UpperBody Original
set SBMessIni.iBody2 to sv_construct "DMRAB" ;DMRA LowerBody Original
set SBMessIni.prefix1 to sv_construct "DMRA"  ;Data\Meshes\DMRA
setstage SBMessIni 15

To begin, the body codes are from Setbody Reloaded and can be found in "Body_Style_Code.txt" from the "core" archive of Setbody Reloaded Blockhead Edition.

The first line is the upperbody type, which in this case is DMRA  Original

The second line the lowerbody type, which is DMRA Original.

The third line is where the DMRA replacer files can be found.  "DMRA" expands to the path "Data\Meshes\DMRA".  The path "Data\Meshes\" is already implied.

The files and folders in the DMRA folder must follow the same naming as those being replaced.  If replacing vanilla armor/clothing, the subfolders and files should be the same as vanilla. 

E.g. "\Armor\chainmail\f\cuirass.nif"  =>  "DMRA\Armor\chainmail\f\cuirass.nif"

 

Then, when an NPC is encountered with DMRA upperbody AND DMRA lowerbody it will look for the replacing items under DMRA first.  If a replacing item doesn't exist, then defaults back to vanilla.

---

Now to expand this to include multiple bodies:

copy/paste the above block of code for each bodytype you want. 

For each block: set "ibody1" with upperbody code, set "ibody2" to lowerbody.  Assuming you make a separate path for each body style, set prefix1 to the path of that body.

 

---

There are other things in the ini for other scenarios.

suffix: changes the filename instead of the main path.  "\Armor\chainmail\f\cuirass.nif"  =>  "\Armor\chainmail\f\cuirass_DMRA.nif"

suffix2/prefix2: are secondary paths to search.  You could have HGEC_C, HGEC_E, HGEC_H paths with only the upperbody meshes and put all the files in common in separate path to avoid duplicates.

Example: HGEC C-cup/E-cup/H-cup

 

 

set SBMessIni.iBody1 to sv_construct "HGECBUC" ;HGEC C-cup
set SBMessIni.iBody2 to sv_construct "HGECBL" ;HGEC Large LowerBody
set SBMessIni.prefix1 to sv_construct "HGEC_C"  ;Data\Meshes\HGEC_C
set SBMessIni.prefix2 to sv_construct "HGEC" ;Data\Meshes\HGEC
setstage SBMessIni 15

set SBMessIni.iBody1 to sv_construct "HGECBUE" ;HGEC E-cup
set SBMessIni.iBody2 to sv_construct "HGECBL" ;HGEC Large LowerBody
set SBMessIni.prefix1 to sv_construct "HGEC_E" ;Data\Meshes\HGEC_E
set SBMessIni.prefix2 to sv_construct "HGEC" ;Data\Meshes\HGEC
setstage SBMessIni 15

set SBMessIni.iBody1 to sv_construct "HGECBUHA" ;HGEC H-cup type A
set SBMessIni.iBody2 to sv_construct "HGECBL" ;HGEC Large LowerBody
set SBMessIni.prefix1 to sv_construct "HGEC_HA" ;Data\Meshes\HGEC_HA
set SBMessIni.prefix2 to sv_construct "HGEC" ;Data\Meshes\HGEC
setstage SBMessIni 15

 

 

In this example, each cup size (C,E,H-A) has a separate path of replacers, but shares a common path "HGEC".  Since all bodytypes have the same lowerbody L, we can put common and "fallback" clothes in a shared folder.   Also, you could set the fallback to be the same as a previously used path.

 

 

set SBMessIni.prefix2 to sv_construct "HGEC_E" ;Data\Meshes\HGEC_E

 

 

Say if you don't have H-cup replacers for all items, but you do for E-cup.  Then, if an NPC with h-cup that doesn't have a matching replacer, it would attempt to wear the E-cup one instead.  Then if there isn't one in the E-cup path, it defaults to the original vanilla.

 

One last thing about the above examples, I'm not sure about the BBB style codes.  I believe they differ from original codes, but I didn't see them in the doc when writing this post.

---

If this doesn't help, you can tell me what you would like to try do.  If it's compatible with this mod, I can setup the ini.  Might be helpful to have more examples, anyway.

Thank you, the mod is working great for the most part now. For some reason though, when I use setbodymess and then set the player's body (via set body self spell) to a body set which is affected/has a replacer mesh from/by setbodymess, I get multiple clothing items equipped (i.e. the game will let me equip two robes at once for some reason).

[iamnoone]

I think I know what you're talking about, and I forgot to add it to the list of potential issues.  When I was testing PCR, I would equip a new item, but the currently equipped item wouldn't get unequipped.  I had to manually unequip it.  It is strange to me that this happens.  I don't change what items get equipped nor make any changes to those items.  Even though I have to use "dummy items" to make this work, there's isn't any changing of the equipment slots.  There is a designated dummy item for each equipment slot.  All it does it change the mesh of the dummy item and tell blockhead that the dummy item has the mesh we want. 

 

I'll have to do some more experiments with it, but If you're up for doing a quick test: could you take an item that causes the double-equipping and equip it via console instead of the menu.  Then check the menu to see if it got double-equipped.  I want to rule out the possibility that it's limited to the menu with all this mesh-swapping happening in menumode.

[ger4]

For some reason I can't create a ZKEC body override, when I try the console just says something about more than 3 body parts not being supported.

 

As for menu mode, I tried equipping items via hotkeys while in gamemode and the issue still occurred. Thanks for your help

I believe the double equip issue might be a bug within Blockhead itself as I seem to recall someone else mentioning it before. If that does turn out to be true, it'll need to be reported to Shademe over at the beth forums.

[iamnoone]

I didn't do body styles that have 3 or 4 parts (hands/feet)...yet.  I am not certain the order of parts SetBody returns when asking for the current body assets.  SetBodyMess currently searches for iBody1 then iBody2, and it allows upper and lower to be in either variable in the off chance someone wants the lowerbody to be the primary search key.  However, I should change it to fixed expected body parts so that 3 and 4 parts are supported (easily).  Consider this part still beta/WIP.

 

SetBodyMess does enough funny things that I can't say it is a Blockhead thing yet.  My next test would be to see if this happens with fixed items in the mod (using Blockhead as it was intended).  If it happens with those, then it probably is in Blockhead.

 

Any chance you remember the other thread/context mentioning the bug?

 

I'm the one thanking you for testing this thing and giving feedback.  Lets me know what areas need more work to consider it complete.

[ger4]

I just tested your version of player clothing replacer and the double equip bug shows up with that as well. However, when I tried my Blockhead version of it, I did not get the bug. It appears that you accidentally introduced the bug into your version somehow when you were altering scripts.

[iamnoone]

I've just confirmed it is indeed Blockhead.  I used the exact example posted by shadeMe in the Bethsoft forum.  It has the same issue.  In fact, after I ran my experiment I saw it was already mentioned in that thread in this post.  While writing this reply, I found that shadeMe has already listed it as a known bug in the next thread.
(I'm just going to lay my head down for a bit)

So the thing I accidentally introduced was blockhead.   
It didn't show up in your version because it only registered the handler, but didn't return an item for Blockhead to use.

[ger4]

I've just confirmed it is indeed Blockhead.  I used the exact example posted by shadeMe in the Bethsoft forum.  It has the same issue.  In fact, after I ran my experiment I saw it was already mentioned in that thread in this post.  While writing this reply, I found that shadeMe has already listed it as a known bug in the next thread.

(I'm just going to lay my head down for a bit)

So the thing I accidentally introduced was blockhead.   

It didn't show up in your version because it only registered the handler, but didn't return an item for Blockhead to use.

Would be useful to report this issue still I think, more bug reports are always useful.