Mod Unity Monster Black Market - Tits Mod V2P

[Krongorka]

Just a quick reminder that "mod development isn't dead". Until we hear anything about new version of game drop I can't really focus on it, plus I'm on vacation (I'm generally not effective when it comes to do this stuff at summer).

Anyway, here's another MBM's technical curiosity I wanted to tackle with and maybe I have some success with it too. In case you don't know, woman/girl type slaves in VVIP rooms use separate skeletons. Basically, when you put them there, game loads another set of skeleton data (CPU load) and a texture (GPU load). Technically, these separate skeletons are not unique, they just contain additional sprites for maid outfit.



Now, why base game use a separate skeleton for a VVIP room? Because when you put a slave with cloth option active, her normal 'rag' cloth sprites and chain sprites stays active too/overlaps. So if you port maid outfit to a normal skeleton, it's the issue you have to deal with.

Thankfully, game can check spine script data for a room which you put slave in. That's actually how game switch skeleton+texture data:



So this roomtype part works, but what needs to be done is to put "maid sprite activation/deactivation" lines in 'normal type' skeleton. It's a bit hard to showcase, since there's wall of sprite name text, but basically:

- Adding maid sprite lines to 'woman_stand'. When they stand in any other room other than "VvipRoom" it use:
"maid_cloth_titsC:maid_cloth_titsC_{ClothesType}_20"

(_20 is a tits type which doesn't exist, so sprite won't load. It's like an internal error which doesn't break anything and it's not reported to the user either)

And then you put them in VvipRoom line switches to:
"maid_cloth_titsC:maid_cloth_titsC_{ClothesType}_{TitsType}"

...but normal cloth set switches:
"cloth_tits_right:cloth_tits_right_{ClothesType}_{TitsType}" -> "cloth_tits_right:cloth_tits_right_{ClothesType}_20"

So using the Switch {TitsType} or any other switch incorrectly actually allows to load maid set of sprites in a particular room and to unload 'normal' set of clothes.
There's a bit of set up involved in that scripting data and there's a need to transfer a set of maid clothes with their meshes to a 'normal' skeleton type but the thing is game now only use one skeleton for all rooms. Also no need to port all changes you made on 'normal' skeleton to a 'maid' skeleton.

 

[AROc137]

Just a quick reminder that "mod development isn't dead". Until we hear anything about new version of game drop I can't really focus on it, plus I'm on vacation (I'm generally not effective when it comes to do this stuff at summer).

Anyway, here's another MBM's technical curiosity I wanted to tackle with and maybe I have some success with it too. In case you don't know, woman/girl type slaves in VVIP rooms use separate skeletons. Basically, when you put them there, game loads another set of skeleton data (CPU load) and a texture (GPU load). Technically, these separate skeletons are not unique, they just contain additional sprites for maid outfit.

View attachment 5038688

Now, why base game use a separate skeleton for a VVIP room? Because when you put a slave with cloth option active, her normal 'rag' cloth sprites and chain sprites stays active too/overlaps. So if you port maid outfit to a normal skeleton, it's the issue you have to deal with.

Thankfully, game can check spine script data for a room which you put slave in. That's actually how game switch skeleton+texture data:

View attachment 5038693

So this roomtype part works, but what needs to be done is to put "maid sprite activation/deactivation" lines in 'normal type' skeleton. It's a bit hard to showcase, since there's wall of sprite name text, but basically:

- Adding maid sprite lines to 'woman_stand'. When they stand in any other room other than "VvipRoom" it use:
"maid_cloth_titsC:maid_cloth_titsC_{ClothesType}_20"

(_20 is a tits type which doesn't exist, so sprite won't load. It's like an internal error which doesn't break anything and it's not reported to the user either)

And then you put them in VvipRoom line switches to:
"maid_cloth_titsC:maid_cloth_titsC_{ClothesType}_{TitsType}"

...but normal cloth set switches:
"cloth_tits_right:cloth_tits_right_{ClothesType}_{TitsType}" -> "cloth_tits_right:cloth_tits_right_{ClothesType}_20"

So using the Switch {TitsType} or any other switch incorrectly actually allows to load maid set of sprites in a particular room and to unload 'normal' set of clothes.
There's a bit of set up involved in that scripting data and there's a need to transfer a set of maid clothes with their meshes to a 'normal' skeleton type but the thing is game now only use one skeleton for all rooms. Also no need to port all changes you made on 'normal' skeleton to a 'maid' skeleton.

The work you do is incredible.
Do you think they'll continue updating it after the game comes out on STEAM?
It would be great if they added more haircuts or different outfits.

I feel like MBM still has a lot to offer

 

[Krongorka]

The work you do is incredible.
Do you think they'll continue updating it after the game comes out on STEAM?
It would be great if they added more haircuts or different outfits.

I feel like MBM still has a lot to offer

I can only tell what I know about potential steam version, which is somewhere in-between of current MBM build and ProjectR in terms of data handling. When and IF that version will be up, it may receive some minor patches from the dev, but don't expect much.
*From the top of my head, ending CG with non-brainwashed NPCs still have minor censorship which may get an updated uncensor version from a dev after release.

This is what we currently have:


This is what reserved for update (but it's a redacted version without a Niel )


Not much, but hey, new version is mainly to get better quality assets to the game (especially replacing heavily compressed ones for whole DLC area) and reduce visual bugs to the minimum.

Their main priority is to get ProjectR to the release.

Personally, I don't know how well ProjectR will perform, but MBM seem to "just work and takes whatever you throw in it" so more content/full remake/sequel will be popular.

 

[ShrimpLord69]

Just a quick reminder that "mod development isn't dead". Until we hear anything about new version of game drop I can't really focus on it, plus I'm on vacation (I'm generally not effective when it comes to do this stuff at summer).

Anyway, here's another MBM's technical curiosity I wanted to tackle with and maybe I have some success with it too. In case you don't know, woman/girl type slaves in VVIP rooms use separate skeletons. Basically, when you put them there, game loads another set of skeleton data (CPU load) and a texture (GPU load). Technically, these separate skeletons are not unique, they just contain additional sprites for maid outfit.

View attachment 5038688

Now, why base game use a separate skeleton for a VVIP room? Because when you put a slave with cloth option active, her normal 'rag' cloth sprites and chain sprites stays active too/overlaps. So if you port maid outfit to a normal skeleton, it's the issue you have to deal with.

Thankfully, game can check spine script data for a room which you put slave in. That's actually how game switch skeleton+texture data:

View attachment 5038693

So this roomtype part works, but what needs to be done is to put "maid sprite activation/deactivation" lines in 'normal type' skeleton. It's a bit hard to showcase, since there's wall of sprite name text, but basically:

- Adding maid sprite lines to 'woman_stand'. When they stand in any other room other than "VvipRoom" it use:
"maid_cloth_titsC:maid_cloth_titsC_{ClothesType}_20"

(_20 is a tits type which doesn't exist, so sprite won't load. It's like an internal error which doesn't break anything and it's not reported to the user either)

And then you put them in VvipRoom line switches to:
"maid_cloth_titsC:maid_cloth_titsC_{ClothesType}_{TitsType}"

...but normal cloth set switches:
"cloth_tits_right:cloth_tits_right_{ClothesType}_{TitsType}" -> "cloth_tits_right:cloth_tits_right_{ClothesType}_20"

So using the Switch {TitsType} or any other switch incorrectly actually allows to load maid set of sprites in a particular room and to unload 'normal' set of clothes.
There's a bit of set up involved in that scripting data and there's a need to transfer a set of maid clothes with their meshes to a 'normal' skeleton type but the thing is game now only use one skeleton for all rooms. Also no need to port all changes you made on 'normal' skeleton to a 'maid' skeleton.

Damn, this looks awesome, i've seen quite a lot of the stuff you're working on over the past 2 days, like clothes and womb tattoos on slaves and such, i'm guessing they're part of a mod you're working on, i downloaded the breast size mod you made, but that doesn't include the clothing i saw, so i'm guessing it's something different, or something you didn;t release ?

 

[Krongorka]

Damn, this looks awesome, i've seen quite a lot of the stuff you're working on over the past 2 days, like clothes and womb tattoos on slaves and such, i'm guessing they're part of a mod you're working on, i downloaded the breast size mod you made, but that doesn't include the clothing i saw, so i'm guessing it's something different, or something you didn;t release ?

You see, there's 2 types of post I usually write about MBM modding in particular:
- Proof of concept. I'd love to make them available for the mod, but these would take a lot of time to implement properly/takes way more CPU/GPU processing I want it to take.

<- "Ignore this one, I was drunk"


- 'Half-way there'/Ready for implementation. Self-explanatory. 'Normal-Maid' skeleton was needed for the mod to move things further. Because otherwise I'd have to port every change I make to the 'Normal' skeleton (Tits sizes, optimization for meshes, etc.), basically doing same thing 2 times. Then it's properly set up to switch clothes normally between VVIP and other rooms it may lead to other 'Proof of concept' post where I'll try to make something like 'room-context animation variations', but I'm not sure it will work properly for now.

As for clothes/additional clothes sprites - I don't really see much point to add more sprites. It will lead to a significant sprite sheet size increase. 'Hair variety' implementation was planned for a long time even before optimization work, so I want to get it done for the next version. In my opinion changing hair sprite even with mesh manipulation makes much more sense for changing female's look than clothes. Mesh manipulation alone is a very powerful tool for this goal, just need to make a coherent-looking changes to all skeleton variation which can make one's head hurt (and I fully understand why devs didn't bother with it)


Plus, some players disable clothes completely... not all players, that's true, but no one is able to disable hair sprites completely



V2p version is probably the last one for 2.0.16.0 by the way and it's stable/fast enough. I really want to switch to the new version to develop mod further.

 

[ShrimpLord69]

You see, there's 2 types of post I usually write about MBM modding in particular:
- Proof of concept. I'd love to make them available for the mod, but these would take a lot of time to implement properly/takes way more CPU/GPU processing I want it to take.
View attachment 5041978
View attachment 5041980 View attachment 5041983 <- "Ignore this one, I was drunk"


- 'Half-way there'/Ready for implementation. Self-explanatory. 'Normal-Maid' skeleton was needed for the mod to move things further. Because otherwise I'd have to port every change I make to the 'Normal' skeleton (Tits sizes, optimization for meshes, etc.), basically doing same thing 2 times. Then it's properly set up to switch clothes normally between VVIP and other rooms it may lead to other 'Proof of concept' post where I'll try to make something like 'room-context animation variations', but I'm not sure it will work properly for now.

As for clothes/additional clothes sprites - I don't really see much point to add more sprites. It will lead to a significant sprite sheet size increase. 'Hair variety' implementation was planned for a long time even before optimization work, so I want to get it done for the next version. In my opinion changing hair sprite even with mesh manipulation makes much more sense for changing female's look than clothes. Mesh manipulation alone is a very powerful tool for this goal, just need to make a coherent-looking changes to all skeleton variation which can make one's head hurt (and I fully understand why devs didn't bother with it)

View attachment 5042025
Plus, some players disable clothes completely... not all players, that's true, but no one is able to disable hair sprites completely

View attachment 5041971

V2p version is probably the last one for 2.0.16.0 by the way and it's stable/fast enough. I really want to switch to the new version to develop mod further.

regardless, you're doing really cool work, and good too, speaking of, i will have to learn spine for work at some point or another, but i heard the community is really gate kept when it comes to tutorials and things of the sort...

Anyways, i'll be keeping my eyes on this thread incase oyu release any of these as mods at some point.

 

[AROc137]

You see, there's 2 types of post I usually write about MBM modding in particular:
- Proof of concept. I'd love to make them available for the mod, but these would take a lot of time to implement properly/takes way more CPU/GPU processing I want it to take.
View attachment 5041978
View attachment 5041980 View attachment 5041983 <- "Ignore this one, I was drunk"


- 'Half-way there'/Ready for implementation. Self-explanatory. 'Normal-Maid' skeleton was needed for the mod to move things further. Because otherwise I'd have to port every change I make to the 'Normal' skeleton (Tits sizes, optimization for meshes, etc.), basically doing same thing 2 times. Then it's properly set up to switch clothes normally between VVIP and other rooms it may lead to other 'Proof of concept' post where I'll try to make something like 'room-context animation variations', but I'm not sure it will work properly for now.

As for clothes/additional clothes sprites - I don't really see much point to add more sprites. It will lead to a significant sprite sheet size increase. 'Hair variety' implementation was planned for a long time even before optimization work, so I want to get it done for the next version. In my opinion changing hair sprite even with mesh manipulation makes much more sense for changing female's look than clothes. Mesh manipulation alone is a very powerful tool for this goal, just need to make a coherent-looking changes to all skeleton variation which can make one's head hurt (and I fully understand why devs didn't bother with it)

View attachment 5042025
Plus, some players disable clothes completely... not all players, that's true, but no one is able to disable hair sprites completely

View attachment 5041971

V2p version is probably the last one for 2.0.16.0 by the way and it's stable/fast enough. I really want to switch to the new version to develop mod further.

That's what I meant by "It still has a lot to offer."
Small details like that can enhance the gaming experience.
El trabajo que haces es increible

 

[Krongorka]

View attachment MBMoneskeletonForDragAndMaidCRF20.mp4














"One Skeleton To Rule Them All"

Proof of concept/Ready for implementation kind of post

Here's a simple drag & drop action. Normally, game loads 3-4 skeletons for it (depending on what you count)
- Woman_stand (for any grown female figure)
- Woman_maid_stand (when you put a grown female figure into a VVIP room specifically, just to switch maid and base model cloth sprites)
- Woman_nude_move (at the moment when you drag a grown slave)/woman_nude_move_1 - exist for situation when you drag a grown female which is tired/low on health or dead.
- Woman_card (when you hold Left Mouse key to mass select entities, which gives you portraits of them on the right side of the screen, but not for a simple drag&drop action).

Here's a quick overview of how game handles this action by default:


Now watch the video at the start of the post again. With a proper set up it's possible to use one optimized default "Stand" type of skeleton for the whole drag&drop logic. Which means I don't need to take "maid" skeleton treatment into account but also discard "move" type of skeleton. Which is a big deal when you have 18 tits types/clothes/additional hair sprites. Less work overall, faster implementation for whole skeleton (woman/girl types).

I know some people will hate losing special drag and drop animation, but also consider this: game loads 3 times less data with this change. So I can actually raise complexity for a stand type of skeleton without encountering performance penalties.

For another "Move" skeleton when slave is tired/dead I plan to use actual 'death' skeleton instead.



This skeleton is also VERY light on resources by default, which is nice. No 'weighted meshes' here, just need a tighter packaging for sprites.

 

[Dadaism]

Mhhh, I can't play the video for whatever reason...

Anyhow, it's a bit sad to be losing the move skeleton. What sort of complexities are you thinking of implementing to make up for it?

 

[Krongorka]

Mhhh, I can't play the video for whatever reason...

Anyhow, it's a bit sad to be losing the move skeleton. What sort of complexities are you thinking of implementing to make up for it?

Basically when you implement an additional slot/asset into a default skeleton you need to make "copies" of it for all skeleton types.
'Maid' type of skeleton was completely unnecessary as I found out. So default female skeleton now include assets for maid clothes.
I plan to implement 18 tits type in total (for 1 default tits type there's 3 intermediate tits type with mesh deformation). Every tits type requires a separate mesh for clothes. I didn't want to use them all due to file size inflation, but that doesn't seem like a huge issue now.

There's even bigger issue with "Birth" skeleton. Game use 4 (FOUR!) separate skeletons for birth sequences so I'd like to combine them into one skeleton as well. I doubt I can merge them into one skeleton for normal/tired sequence and also normal/big birth types... So at least reducing that to 2 skeletons will be the minimum goal.



Update 22 jul 25: For now, I have some hopes to combine "Drained/Tired" birth skeleton with Normal one. We practically just need to take assets for female's head. The rest of the body is the same and Drained sequence in particular can use their own bone movements.
- Transfer assets from Woman_Nude_Birth_2 to 1 with adjusting naming for head bones and slots.
- Make approximate changes for bone movements in "Unified" skeleton.
- Set up main Spine scripting data file to load "Drained" type of assets and switch off "Normal" type of sprites... can be a bit messy, but should be possible.

 

[FluffyRaKu]

Speaking of tweaking visuals and stuff, I prodded through things on DnSpy to figure out the imregnation logic for multiples, but I was also wondering how the logic for the belly size works? Is it something that is done in the spine files themselves in that they read the entity data directly, as opposed to being a code thing?

 

[Krongorka]

Speaking of tweaking visuals and stuff, I prodded through things on DnSpy to figure out the imregnation logic for multiples, but I was also wondering how the logic for the belly size works? Is it something that is done in the spine files themselves in that they read the entity data directly, as opposed to being a code thing?

Spine Visuals for Gameplay in MBM are controlled in 3 places:
- .skel file itself
- Assembly code
- Big SpineData scripting file in assetdata

*CG with NPC have their scripting entirely coded into Assembly file which is whole new can of worms*

For existing "switching slots", like 'TitsType' you need to edit these 3 correctly.

The problem with adding whole new visual "switching slot", like non-existing-by-default 'FetusCount' command isn't possible to do with dnspy, because it can't handle editing some class/methods in Unit.cs



If you load same thing in latest ilSpy tool with updated disassembly module it will look much better. So to mod this we need to write BepInEx plugins to edit this part of the assembly... which I hate, Memacile made a plugin for belly size - maybe I still have sources for that somewhere.

 

[Krongorka]

More like "Proof of Concept" (Which I really want to implement in the future, but we'll see) kind of post.

As I mentioned before, there's a long standing issue with modifying MBM skeletons properly when adding new stuff. There's actually not that many poses but the amount of separate skeleton data is huge.

Each non-NPC girl/woman type have their own "Birth" skeleton-group which consist of:
- Birth 1 (birthing 1-3 offsprings)
- Birth 2 (birthing 1-3 offsprings when in Drained/Tired state)
- Big_Birth 1 (birthing Minotaur/Horse/Salamander's Egg)
- Big_Birth 2 (birthing Minotaur/Horse/Salamander's Egg in Drained/Tired state)

Animation wise there's not much difference between them (technically). Slave's head assets are different, but the rest of the body is the same.

First concept is to merge at least two birth skeletons into one (preferably all four, but we'll get to it)

Setup window with two Head group assets active at the same time (Birth 1 - 2/Normal - Drained, combined) :


In Spine it works like this: for a "birth 1" type we turn off "birth 2" head assets and vice versa. In most cases it works pretty good, but Umbilical Cord mesh keep acting up when I transfer it from another skeleton for some reason. Probably just a bug, but some alterations has to be made at some point to look right:



So actual difficulty is "Pussy" and "Umbilical Cords" meshes acting up in this merging mod. If it's handled properly it might be possible to use 1 skeleton for both cases (hopefully for Big Births too).

But that makes me to think about another old idea. Here's how much space is left on a 2048x1024 standard size for Woman Birth animation:



What can we do if there's still lots of space and we don't actually pursue 2048x512 asset and we have 4 Birth Skeleton for EACH non-NPC (32 (8x4) skeletons in total for Unique Slaves))?



So this is quick mock up I just made. Not actual Karen's skeleton, but her assets applied to a standard Woman's skeleton. If merging skeletons for Girl and Woman are successful my next idea is to implement all Unique Slaves sprite data into these skeletons - just need to make one "Merged Birth Skeleton" for Girl and Woman. Then game will only load these two for all situations, ignoring all other data.

38 separate skeletons and its texture data. Not needed, if this idea works out. Let that sink in.

For now it's just a concept, but it opens the road to idea of fully customizable Unique Slaves (like Karen in this case).

 

[FluffyRaKu]

It's also not just fully customisable unique slaves, but also opens up those unique assets for the normal slaves too. This means that you can now have the children of the unique slaves inherit the special visuals of their mothers. No idea how this might interact with randomly occurring slaves or the cosmetic potion though, as we probably don't want them just being another slave visual as that was part of the charm of the unique slaves.

Does this also mean the unique slaves could potentially have not only customisable features in terms of assets, but also potentially recolouring their hair/eyes, or are their colours on their features hard-coded?

 

[Krongorka]

It's also not just fully customisable unique slaves, but also opens up those unique assets for the normal slaves too. This means that you can now have the children of the unique slaves inherit the special visuals of their mothers. No idea how this might interact with randomly occurring slaves or the cosmetic potion though, as we probably don't want them just being another slave visual as that was part of the charm of the unique slaves.

Does this also mean the unique slaves could potentially have not only customisable features in terms of assets, but also potentially recolouring their hair/eyes, or are their colours on their features hard-coded?

Good question. There's several ways Unique Slave's assets can be handled.

Let me tell you about hair color in particular. Unique's hair color is color-coded (drawn as is). But to use them on all common females I do this:



That's how common hair sprites look in assets actually. White.

The downside to this method is you need to set Brightness level just right, since it start to destroy black highlights (still makes black to appear 'blurry').

Now we put that to Spine editor and then there's an option which allows to color-pick the color of the sprite individually:



Still a quick mockup. I didn't actually used color-picking here and just showcasing what can be done.

It's actually part of asset usage optimization. Either we use one grayscaled asset for Karen (with color-picking) and then use a copy with disabled colors of that asset for all normal slaves - and that hair asset will be packed ONCE on a sprite sheet. OR we use 1 hardcoded colored asset just for Karen specifically (it's controlled in a global SpineData scripting file) and 1 grayscaled asset for the rest and it will be packed twice on a same sprite sheet.

I'd like to use just 1 grayscaled asset because there's just less data to handle. Also, in this case you see the side-by-side comparison with high zoom level. During gameplay you might not even notice it with default max camera zoom.

I honestly can't tell you about clothes handling, since I don't really want to use grayscaled versions of them. It's also a much bigger part of skeleton data.
Currently I believe that max resolution of Birth skeleton combined assets can be rendered with 2048x2048 sprite sheet. With full clothes it will be probably increased to 4096x2048 or even 4096x4096 which in .DDS format will take ~28mb of VRAM just to render birth skeleton, because we still need LODs included. Yikes! But again, if we're going "Unified" asset route 'it is what it is' I guess.

Like I said for the long time, Unique Slaves in MBM is both bless and the curse. Sure, with their Separate skeletons you can make them truly individual for visuals, might adjust their movements specifically. But that also means you need to basically multiply mostly the same data with each new character. And then you can also forget about customization since every asset is hardcoded and common slave asset pool can't be used.

 

[Nothing?]

Hello, Mr. Krongorka. I would like to know more about this outfit. In many hours of playing with your mod, I have never met a girl in such a dress. Was it removed or are there hidden conditions for obtaining it? I did not find the answer in this thread.

 

[Krongorka]

Hello, Mr. Krongorka. I would like to know more about this outfit. In many hours of playing with your mod, I have never met a girl in such a dress. Was it removed or are there hidden conditions for obtaining it? I did not find the answer in this thread. View attachment 5083735

Hi. Some custom outfits were available in previous versions, but removed for v2p. Main reason for removal was unnecessary skeleton complexity increase which I started to improve.

While I hate to remove old content this had to go, but in return main skeletons are much faster performance-wise than before.

Maybe I’ll return it with Unified skeleton project if it’s successful, but we’ll see.

 

[Krongorka]

So we got a mix of good news and bad news.

Good: Combining 4 Birth animation types seems to be possible and can be implemented and animation data can be transferred between animation source projects which *should* save tons of work.
Bad: Although Spine 4.0.61 actually can transfer skeletons and animations into other projects (which it couldn't do in version 3 at all), it sucks ass at positioning bones and meshes. Actually completely fucks them up with presumably same coordinates/angles. Also can't transfer Sprite Order which shouldn't be an issue in the first place.

So while it's entirely possible to manage, there's a lot of manual tweaking involved. But hey, it's still about mixing 4 separate skeleton projects for all types of births into skeleton so I can't complain.

I thought that "Big Birth" types with Minotaur/Horse and Egg will present more issues, but apparently these are easier to handle.

One detail I did notice while working on it is scale settings for normal-size kids and big ones. Humanoids are set to scale 0.5 and large ones are at 0.75 till they are out of slave. "Realistic" 1.0 scale is possible to do, but it looks much worse than I'm willing to implement in a custom version, so I probably won't touch it (for now).

Further development probably going to slow down considerably till the end of September as well. We don't have news about new build for MBM - not even counting on steam, just want a new build to be available for DLsite. That's when we're going to talk about "V3" seriously.

Editor's test render. (custom) Big_Birth_Nude_1 (egg) animation in Big_Birth_1 skeleton. Notice how game doesn't need a chair and straw (where kids go) sprites. So these sprites don't need to be packed, saving more space on sprite sheet (target is still 2048x1024) :

*Default 0.75 Egg until it comes out* Scale:



"Normal" 1.0x Scaled Egg for Comparison (Just A Concept, controlling this for several pussy types with clipping mesh and for it to look stable is a nightmare) :

 

[Ilbrya]

View attachment 5062976














"One Skeleton To Rule Them All"

Proof of concept/Ready for implementation kind of post

Here's a simple drag & drop action. Normally, game loads 3-4 skeletons for it (depending on what you count)
- Woman_stand (for any grown female figure)
- Woman_maid_stand (when you put a grown female figure into a VVIP room specifically, just to switch maid and base model cloth sprites)
- Woman_nude_move (at the moment when you drag a grown slave)/woman_nude_move_1 - exist for situation when you drag a grown female which is tired/low on health or dead.
- Woman_card (when you hold Left Mouse key to mass select entities, which gives you portraits of them on the right side of the screen, but not for a simple drag&drop action).

Here's a quick overview of how game handles this action by default:
View attachment 5060633

Now watch the video at the start of the post again. With a proper set up it's possible to use one optimized default "Stand" type of skeleton for the whole drag&drop logic. Which means I don't need to take "maid" skeleton treatment into account but also discard "move" type of skeleton. Which is a big deal when you have 18 tits types/clothes/additional hair sprites. Less work overall, faster implementation for whole skeleton (woman/girl types).

I know some people will hate losing special drag and drop animation, but also consider this: game loads 3 times less data with this change. So I can actually raise complexity for a stand type of skeleton without encountering performance penalties.

For another "Move" skeleton when slave is tired/dead I plan to use actual 'death' skeleton instead.

View attachment 5060669

This skeleton is also VERY light on resources by default, which is nice. No 'weighted meshes' here, just need a tighter packaging for sprites.

Late but at least have them turn green while being dragged

 

[Krongorka]

I've already posted it on MBM's game thread, but I'll just leave a note here for anyone who's interested:

I got a word from the dev that

You must be registered to see the links

. It's a technical update, basically what was supposed to be a Steam version (better asset/data handling, better performance out of box and without steam content censorship in place), but Tits mod currently don't support it. DLsite version of MBM will be updated later (if there's no issues, of course) but only after they'll release ProjectR 0.6.

New build version is supposedly 2.1.0.0.

So any warnings this mod thread have about "non-compatible Steam version" is about current 072 project store version now.