Mod Unity Monster Black Market - Tits Mod V2P

[Krongorka]

Is it possible that version 3 of this mod will open up the possibility of adding new animations or new special women to the game?

By the way, excellent work!

I've been following this mod for a long time, as I'm a big fan of the game and I'd like to add new content, but I don't know how to do it.

Do you have any tutorials or special links to learn how to mod this game? I'm a developer and I tried a bit with BepInEx and dn-spy, but I didn't get anywhere.

There's a lot of stuff in MBM which, as developer tends to say in PMs "is hardcoded". I'd love to restore some old build 0.7 functionality in release version (like hunger and food mechanic), but you'll need to analyze both 0.7 build and release build and know how to implement it. Just using BepInEx won't cut it, you'll need a deep dive into editing the Assembly-Csharp.dll too.

As for adding Special Slaves... if you read my previous post you can see that there's little "Special" about any of them. In fact, I can tell that dev tried to merge Special slaves at least for Gloryhole rooms for Woman type (Claire, Karen, Sylvia). Basically what I'm doing right now, but they must have run out of time to set it up right. Once I'm done with Gloryhole room (oral, vaginal, anal poses) I'll share some kind of a scene breakdown, because there's tons of shared assets and when you'll see 30 separate skeletons with according assets - 30x 1200x1200 sprite sheets can be merged into a single one 1024x1024 sprite sheet with all scene, you'll know that merging idea is crucial to the project. It's weird how this mod is about 'de-bloating' game's assets now, yeah.

Once all skeletons are merged, there would be no need in adding "Special girls", since whole asset pool for assets will be available. We can add graphics data to a single scene/pose skeleton at that point, but we'd need an artist to draw more sprites. Which is the thing that never took off for MBM community modding, sadly.

New poses is a very tricky matter. Especially with merged skeletons, because you'd still need a way to control and switch them via control file + logic from Assembly. Asset control in MBM comes not from one place, but it's combination of skeleton data, global spine control scripting data, Assembly data and sometimes also streaming assets data. Everything is connected and can break. As far as I can tell game is indeed hardcoded to take two states for poses which will switch between "normal" and "depraved"/"exhausted" states which is handled by two separate skeleton types. I honestly can't tell much more about it because I feel like there might be a breakthrough later, but I won't count on it for the time being.

I don't have any tutorials either, I'm afraid. I just analyzed how game works for quite some time. I do plan to share my Spine source files (which I edited) because at some point I'll exhaust ideas for this mod. 072 project version of the game (2.1.0.2) is more opened in terms of data handling, so users actually have access to character skeletons and sprite sheets, but you'd need a professional tier license for a Spine software to make meaningful edits. So yeah... it's a tough entry for modding this game, if you want to touch graphics.

If you want to change logic in gameplay, I'd recommend to analyze ComplexBreeding mod dll file with dnSpyEx. Mod is closed-source, unfortunately. But the fact that dev managed to squeeze so much from a BepInEx plugin makes me think it's possible to implement more game-changing stuff this way.

 

[Krongorka]

Just wanted to post WIP of reworked man_girl_nude_3 (gloryhole - anal). Same two additional "jiggle bones" with mesh following triangular path and body weights following them results in some exaggerated movements (made on purpose), but it kinda reminds me of FOBS a bit. If you know, you know.


As usual, skeleton file complexity is about 3 times less than default one. Still need to merge gloryhole skeleton group (30 into 1), though.

We also might be a bit closer to some other "technical MBM update", since developer care about it. But it's a very risky one and we must check if everything works perfectly first. Nothing is certain and I won't mention it again until it's set to come out... unlike Steam release *sigh*.

Nov 2: Too much experiments with jiggle bones, animated man movement and slave butt scale adjustment (it works in pair with jiggle bones and mesh weights)... I think it's alright for now:

 

[Krongorka]

Well, so much for "gloryhole scene merging" /s.

I actually had to rebuilt NPC characters for a pretty special test. V2p version use very basic 'mesh topology' for NPCs, which makes them very fast to be rendered and minimal system resource is taken, but they are very limited in movement. Basically, it's locked to default animation movement range. Move it past that and you'll see lots of artifacts.

I think I got a bit better on my own mesh building starting with gloryhole reworks, so I decided to rebuild NPCs with same methods in mind. What makes this test special is a usage of Spine 4.2, which technically can be implemented but it's a risky move and final decision to put it out is on a dev.

So I do tests like these to see how far things can be pushed both with performance and animation standpoint.

 

[Perniciousducks]

Just wanted to post WIP of reworked man_girl_nude_3 (gloryhole - anal). Same two additional "jiggle bones" with mesh following triangular path and body weights following them results in some exaggerated movements (made on purpose), but it kinda reminds me of FOBS a bit. If you know, you know.

View attachment 5394939 View attachment 5394941
As usual, skeleton file complexity is about 3 times less than default one. Still need to merge gloryhole skeleton group (30 into 1), though.

We also might be a bit closer to some other "technical MBM update", since developer care about it. But it's a very risky one and we must check if everything works perfectly first. Nothing is certain and I won't mention it again until it's set to come out... unlike Steam release *sigh*.

Nov 2: Too much experiments with jiggle bones, animated man movement and slave butt scale adjustment (it works in pair with jiggle bones and mesh weights)... I think it's alright for now:

View attachment 5400050 View attachment 5400091

question on the bottom two animations. Is it possible to tweak them so the section with the skirt jiggles a lot less than their butt cheeks? I do enjoy the bouncing butts, but their backs shouldn't quite move like that, if that's possible. If not, it's fine, just trying to be a little constructive.

 

[Krongorka]

question on the bottom two animations. Is it possible to tweak them so the section with the skirt jiggles a lot less than their butt cheeks? I do enjoy the bouncing butts, but their backs shouldn't quite move like that, if that's possible. If not, it's fine, just trying to be a little constructive.

You mean cloth in gloryhole anal animation?

If so, that's a tricky matter because not moving that cloth part with slave's butt will result in a noticeable sprite clipping from jiggling butt. Moving cloth part up or removing it will showcase how upper section of body is made out of sphere-like shape... which doesn't look right and needs to be covered with it.

I do agree cloth moving like that doesn't look quite right either. Butt movement is also extremely exaggerated, although it's more noticeable for slaves with large thighs. Small thighs have different "bone weight" so it repeats same movement, but with less force applied.

I tried to reduce it though, it's use same jiggle bone as a base so I just reduced cloth 'weight' for it in half:

*smaller thigh-butt version since I didn't post it yet:

 

[Perniciousducks]

You mean cloth in gloryhole anal animation?

If so, that's a tricky matter because not moving that cloth part with slave's butt will result in a noticeable sprite clipping from jiggling butt. Moving cloth part up or removing it will showcase how upper section of body is made out of sphere-like shape... which doesn't look right and needs to be covered with it.

I do agree cloth moving like that doesn't look quite right either. Butt movement is also extremely exaggerated, although it's more noticeable for slaves with large thighs. Small thighs have different "bone weight" so it repeats same movement, but with less force applied.

I tried to reduce it though, it's use same jiggle bone as a base so I just reduced cloth 'weight' for it in half:

*smaller thigh-butt version since I didn't post it yet:

View attachment 5411154

yeah, in this one her back doesn't look like it's made of jello. Not that jello is bad, just not usually in that particular location.

 

[Krongorka]

yeah, in this one her back doesn't look like it's made of jello. Not that jello is bad, just not usually in that particular location.

Yeah, I guess. Like I said, jiggle bones are straight out Night or Revenge animation which I looked at in Spine software for a bit. I implemented a 'dumb down' version of it here as an alternative to a proper physics module which we might or might not get. You see, if it's implemented I can actually reduce exaggeration a bit and it will get a physics randomness in some kind. I only tested it recently, so there's always a room for extra adjustments.

I'll just show how same scene look with active physics module on predefined jiggle part (takes over the flow, adds several parameters like mass, inertia, damping, etc.)

Looks a bit jerky because it's a quick addition to the scene and it needs to be adjusted specifically for a physics module in mind. Plus, it's a pre-rendered loop and actual movements are a bit random on repeat.

 

[Krongorka]

Got some good news: Spine 4.2 update will be coming to MBM. No ETA (because they currently sent 2.1.1.0 version to DLSite and it takes a lot of time to be accepted there). We were testing a beta build lately which have a support for physics module in animations and so far we don't see any major issues.

Now, support itself doesn't mean anything if animations don't have physics bone setup. It's pretty much my playground with a need of optimization first and then adding physics on top of it. Since it was my idea there's no way I'll drop this project till I consider it complete.

So skeletons which were used in V2p are pretty much scrapped at this point because they need to support wide range of movements. I'll show it on the example of Rune NPC: original skeleton structure, V2p skeleton "barebones" and a new version which supports physics and a tighter mesh (best texture packing so far)

Original mesh:


V2p -> "Spine 4.2-ready version"


New Asset packaging (fits 1024x512 without texture cuts which previous mesh had):

 

[Krongorka]

I didn't plan for this next 'character merge', but as it seems I need to do this just because it involves lots of shared assets between two skeletons.

Don't know if you are aware, but Amilia NPC use two separate skeletons for day and night time (amilia_day_stand and amilia_night_stand)
It's another unique case, because no other NPC does this... if we're not counting DLC NPC content where each Idle, Sex and Birth state have their own skeletons.

I've merged "Dead" Girl and Woman skeleton types together, but that didn't have active bones and bone constraints so Amilia merge prototype is a good testing ground since we have to transfer whole bone data, organize it and set it up in a way game can switch between two states.



So here's how it goes:
- Optimizations done for both 'Day' and 'Night' skeletons
- One of skeletons have all bones and slots renamed to have a marking on the end (Amilia night assets got "N" at the end of filenames). Textures are moved to a separate folder so it won't get replaced with other assets.
- In this case "Day_Stand" is a primary skeleton which got a .json data import of "Night_Stand" skeleton.
- Learned to NOT rename "root" bone the hard way: there will be an error 'root not found' on data import.
- "DAY" bone for primary skeleton needs to be created and all assets moved to it before the import of the secondary skeleton, otherwise it will create a clusterfuck of a bone structure. Much harder to navigate. If you didn't rename bones and slots in a secondary skeleton before the import result will be even more catastrophic... been there done that.
- Imported "Night_Stand" skeleton assets can be moved to a separate "NIGHT" bone.
- Bone constraints can't be transferred directly, so either I'll use existing ones from a primary skeleton (best case scenario) or I'll port and add new missing ones manually.
- Animations are not ported as well, but these have a separate Import function which should cover this.
- All assets are ON at the same time by default. The way to tell the game to switch between "Day" and "Night" state is to create flags for each slot on both skeleton groups. 'Day' animation disables 'Night' assets and vice versa.
- I don't think actual bones can be disabled during a particular DAY/NIGHT state, so that could be a problem with multiplied active bone count... but it needs to be done for lots of cases in MBM. We'll see how it goes in future tests.

Game 'calls' for "DAY" and "NIGHT" animation states when needed, but assets are now shared and load at the start of the game.
Shared Day and Night assets for:
- Dress is the same but is greyed out and painted by Spine. #FF0000 for night dress color and #5A4E4E for a day dress. Both are approximates, but they do look pretty close to originals, except missing white-ish highlights.
- Facial features
- Front hair
- Legs

Dress color picking for Day state:


Sprite sheet size for merged version is 1024x1024. Default sprite sheets for Day and Night skeletons are: 896x896 and 1072x1072

- Merged prototype can be pushed to 908x908 at minimum if we don't aim for NPOT size... won't recommend using Non Power of Two textures, but I'll admit it's packed nice in a square sprite sheet:



*magenta thing is a debug Spine packing feature. Show borders of image and meshes. Very useful since I'm using polygonal packing instead of rectangular which saves a lot of space.

Well, that covers most of it which is been done so far and needs to be done with remaining game's assets. Thanks for the read

 

[Krongorka]

Follow-up to a previous post.

Amilia NPC merge is complete. There are additional details I wanted to share, which helps to form the idea for future edits.

So first, current skeleton metrics change depending on a Day/Night state. It's same skeleton, but game only loads the amount of meshes it needs at the time:



Unfortunately, I don't see a way to effectively prevent Bone/Bone Transforms to be disabled for a separate animation state. I did optimize it with about ~20 bones removal in total, but others are still loaded at all times. I don't think it adds that much to the cost, since additional meshes won't load, but still.
One way to resolve this is to add SKIN function, but I'm afraid this game doesn't support it/no way to implement now.

Other than that, basic constraints were removed from day/night skeletons. 4 inverse kinematic constraints on legs - used to keep them in place when moving legs, but I used animation keys to do the same effect. Also several constraints for tits. I repurposed two "constraint type" tits bones to add additional jiggle effect without physics module (I'll show how it's amplified with Physics module shortly).

Does it actually work in game? Yes, it does. Currently it's designed to work on a new file data version of the game which is available at 072 project store (compatible versions are: 2.1.0.2 / 2.1.1.0).

After new "merged Amilia" file data is placed into its data folder, several edits need to be made:



In SpineData (resource.assets file)
"skeletonDataAssetName"/"skeletonDataAssetName1/2/3" - changed from "amilia_night_stand" to "amilia_day_stand". This tells game to use only a merged version of skeleton.
* "commonPartList - it's pretty interesting aspect of animation mix in MBM. I feel like it can be exploited in the future to add more functionality for other animations, but for Amilia it was simplified and its function repurposed to other switch type.

etc.animation - Data load file in newer version of MBM, every asset group have these to tell the game what to load:







So "Amilia_night_stand" data can be safely removed now. Game won't look for it anymore. Same principle which will be used for other merged/unified skeletons.

As for Spine 4.2 additional physics. It's a tricky matter. I do need to rebuild skeletons on old 4.0.61 spine just to be sure it can be used with classic version if game update with it won't come out (I've been told DLsite review might be completed next year, so it's a very slow process). If it actually comes out I can safely add my experimental physics data to an optimized skeleton. Take a note for this test I decided to concentrate physics on tits and her night accessories only (called 'showl' in data). Physics bones are always active too, so I need to restraint myself from overusing them. Don't want to cause performance issues.

View attachment AmiliaSpine42RuntimeTestCRF20.mp4


View attachment AmiliaMergedVersionSpine42PhysicsCRF20.mp4

 

[AROc137]

Follow-up to a previous post.

Amilia NPC merge is complete. There are additional details I wanted to share, which helps to form the idea for future edits.

So first, current skeleton metrics change depending on a Day/Night state. It's same skeleton, but game only loads the amount of meshes it needs at the time:

View attachment 5429408

Unfortunately, I don't see a way to effectively prevent Bone/Bone Transforms to be disabled for a separate animation state. I did optimize it with about ~20 bones removal in total, but others are still loaded at all times. I don't think it adds that much to the cost, since additional meshes won't load, but still.
One way to resolve this is to add SKIN function, but I'm afraid this game doesn't support it/no way to implement now.

Other than that, basic constraints were removed from day/night skeletons. 4 inverse kinematic constraints on legs - used to keep them in place when moving legs, but I used animation keys to do the same effect. Also several constraints for tits. I repurposed two "constraint type" tits bones to add additional jiggle effect without physics module (I'll show how it's amplified with Physics module shortly).

Does it actually work in game? Yes, it does. Currently it's designed to work on a new file data version of the game which is available at 072 project store (compatible versions are: 2.1.0.2 / 2.1.1.0).

After new "merged Amilia" file data is placed into its data folder, several edits need to be made:

View attachment 5429426

In SpineData (resource.assets file)
"skeletonDataAssetName"/"skeletonDataAssetName1/2/3" - changed from "amilia_night_stand" to "amilia_day_stand". This tells game to use only a merged version of skeleton.
* "commonPartList - it's pretty interesting aspect of animation mix in MBM. I feel like it can be exploited in the future to add more functionality for other animations, but for Amilia it was simplified and its function repurposed to other switch type.

etc.animation - Data load file in newer version of MBM, every asset group have these to tell the game what to load:

View attachment 5429435


View attachment 5429448


So "Amilia_night_stand" data can be safely removed now. Game won't look for it anymore. Same principle which will be used for other merged/unified skeletons.

As for Spine 4.2 additional physics. It's a tricky matter. I do need to rebuild skeletons on old 4.0.61 spine just to be sure it can be used with classic version if game update with it won't come out (I've been told DLsite review might be completed next year, so it's a very slow process). If it actually comes out I can safely add my experimental physics data to an optimized skeleton. Take a note for this test I decided to concentrate physics on tits and her night accessories only (called 'showl' in data). Physics bones are always active too, so I need to restraint myself from overusing them. Don't want to cause performance issues.

View attachment 5429455


View attachment 5429453

Could those physical principles be applied to all slaves? :c

 

[Krongorka]

Could those physical principles be applied to all slaves? :c

Yep, that's the goal:
- Optimize skeleton so it use less CPU/GPU/RAM
- Merge assets for most scene groups into single skeleton so it only loads once for all
- Apply physical properties (will only be done and implemented for game versions which will support Spine 4.2 if it comes out)

However, I do need to keep in mind of potential performance penalty since it requires more calculations per object.

 

[Krongorka]

"It's not a bug, it's a feature".

While testing for physics properties on bones I've encountered an unexpected side-effect on NPCs in "Quick-access tab" (NPC characters appears on screen bellow when you press F1, F2, etc hotkeys).

View attachment MBMspinephysicsNPCtabCRF20crop.mp4
















The moment of their appearance amplifies physics constraints and bone movement is affected a lot. It also continue to apply directional forces to 'physics bones' when player move camera. And it only affects the character in UI tab, not the actual character on a playfield (this part is considered a bug, I guess)

I tweaked physics bone properties to reduce X/Y movement while keeping damping effect low, so it still produce some jiggle effect on a character (otherwise the effect won't happen with reduced movement). Visually it looks better and cause a semi-interactive effect - in this case player can control breast movement.



Yeah... I can't guarantee we will keep it or fix the UI character behavior, so just consider it a fun behind the scenes test for now

Edit: later tests proved that it can work efficiently on character's hairs and accessories. I can set how far each part can move on X/Y coordinate and/or can it be rotated or not (Flora's earring can only rotate for example).


View attachment MBMspinephysicsNPCtabTestBCrop.mp4

 

[Krongorka]

Story about early made NPCs and their performance-expensive eyes.



So it's a an old thing I encountered before making changes for V2p version, which involves an expensive Spine function called "Clipping".

For this breakdown I'll just show you in steps how following NPCs (Amilia Day/Night, Flora, Niel, Rune) have their eyes drawn in order (on Flora's example) :



- "Head Front" sprite
- "Eye hair" sprite with opaque white, drawn as is
- "Eyeball/Eyeheart" sprite drawn above "Eye hair" sprite
- "Eye clipping mesh" is applied on top of it, culling Eyeball/Eyeheart sprites.

Last step cause performance penalty on CPU side, taken from Spine's technical info tab:

"Clipping in the Spine Runtimes is implemented using the CPU can be a very expensive operation, especially when using mesh attachments with many vertices. Always check the performance of your animations that use clipping on your target platforms."

So what I did in V2p is to reduce clipping mesh vertices down to 4, resulting in less clipping polygons/triangles. There still was few of them left because in order to remove them I needed to change the way face was drawn.

In addition to that, characters blink fairly often and I just realized it also affects performance (2 draw calls each 120 frames per character) :


For a blink effect they hide eyeheart, eyehair, eyeball sprites under head front/face sprite. With additional "clipping" mesh it gets even more expensive.

Developers realized it later in development and other NPCs got a new method of drawing eyes without clipping involved (Sena&Lena, Barbara, All Slaves, All DLC area NPCs). Breakdown of SenaLena's eye-face draw method:



- "Eyeback" sprite
- "Eyeball/Eyeheart" sprite
- "Head front" sprite with transparent 'cut outs/eyesockets'
- "Eye hair" with transparent 'cut outs'

No eye clipping is needed. Unfortunately, 'Draw Order' flags are still present on animation timelines for most characters and I never bothered with it until recently.

I decided to use some newer DLC character assets to redo older NPCs. The issue with these assets is most of them are drawn with angle position in mind. And faces are all for brainwashed state when NPC's face is blushing. I'm not good with digital drawing, but I tried my best since it's unlikely to get a help elsewhere and I need to get better with it.

So here's a result for a Flora NPC which doesn't need 'eye clipping' anymore (same is done for Amilia, Niel and Rune at this point). Draw order is fixed and stays the same at all times. Character blinking is done just by switching between eyehair/eyeblink sprites and turning 'eye socket' section of face on and off.



I do admit that 'Clipping' function is absolutely necessary in some situations, like for birth scenes. But these only happens depending on player's actions/size of the playfield.

So I'm happy that NPCs eye clipping/draw order calls for blinking are finally gone for good.

 

[ShrimpLord69]

"It's not a bug, it's a feature".

While testing for physics properties on bones I've encountered an unexpected side-effect on NPCs in "Quick-access tab" (NPC characters appears on screen bellow when you press F1, F2, etc hotkeys).

View attachment 5439453
















The moment of their appearance amplifies physics constraints and bone movement is affected a lot. It also continue to apply directional forces to 'physics bones' when player move camera. And it only affects the character in UI tab, not the actual character on a playfield (this part is considered a bug, I guess)

I tweaked physics bone properties to reduce X/Y movement while keeping damping effect low, so it still produce some jiggle effect on a character (otherwise the effect won't happen with reduced movement). Visually it looks better and cause a semi-interactive effect - in this case player can control breast movement.

View attachment 5439536

Yeah... I can't guarantee we will keep it or fix the UI character behavior, so just consider it a fun behind the scenes test for now

Edit: later tests proved that it can work efficiently on character's hairs and accessories. I can set how far each part can move on X/Y coordinate and/or can it be rotated or not (Flora's earring can only rotate for example).
View attachment 5440033

View attachment 5439463

LMAO that's hilarious XD

 

[jonnijimbo]

Story about early made NPCs and their performance-expensive eyes.

View attachment 5443760

So it's a an old thing I encountered before making changes for V2p version, which involves an expensive Spine function called "Clipping".

For this breakdown I'll just show you in steps how following NPCs (Amilia Day/Night, Flora, Niel, Rune) have their eyes drawn in order (on Flora's example) :

View attachment 5443764

- "Head Front" sprite
- "Eye hair" sprite with opaque white, drawn as is
- "Eyeball/Eyeheart" sprite drawn above "Eye hair" sprite
- "Eye clipping mesh" is applied on top of it, culling Eyeball/Eyeheart sprites.

Last step cause performance penalty on CPU side, taken from Spine's technical info tab:

"Clipping in the Spine Runtimes is implemented using the CPU can be a very expensive operation, especially when using mesh attachments with many vertices. Always check the performance of your animations that use clipping on your target platforms."

So what I did in V2p is to reduce clipping mesh vertices down to 4, resulting in less clipping polygons/triangles. There still was few of them left because in order to remove them I needed to change the way face was drawn.

In addition to that, characters blink fairly often and I just realized it also affects performance (2 draw calls each 120 frames per character) :
View attachment 5443797

For a blink effect they hide eyeheart, eyehair, eyeball sprites under head front/face sprite. With additional "clipping" mesh it gets even more expensive.

Developers realized it later in development and other NPCs got a new method of drawing eyes without clipping involved (Sena&Lena, Barbara, All Slaves, All DLC area NPCs). Breakdown of SenaLena's eye-face draw method:

View attachment 5443804

- "Eyeback" sprite
- "Eyeball/Eyeheart" sprite
- "Head front" sprite with transparent 'cut outs/eyesockets'
- "Eye hair" with transparent 'cut outs'

No eye clipping is needed. Unfortunately, 'Draw Order' flags are still present on animation timelines for most characters and I never bothered with it until recently.

I decided to use some newer DLC character assets to redo older NPCs. The issue with these assets is most of them are drawn with angle position in mind. And faces are all for brainwashed state when NPC's face is blushing. I'm not good with digital drawing, but I tried my best since it's unlikely to get a help elsewhere and I need to get better with it.

So here's a result for a Flora NPC which doesn't need 'eye clipping' anymore (same is done for Amilia, Niel and Rune at this point). Draw order is fixed and stays the same at all times. Character blinking is done just by switching between eyehair/eyeblink sprites and turning 'eye socket' section of face on and off.

View attachment 5443826

I do admit that 'Clipping' function is absolutely necessary in some situations, like for birth scenes. But these only happens depending on player's actions/size of the playfield.

So I'm happy that NPCs eye clipping/draw order calls for blinking are finally gone for good.

any ETA on when all these improvements will be included in a mod update?

 

[Krongorka]

any ETA on when all these improvements will be included in a mod update?

Hard to tell now because we don't have a current "primary" version of the game right now. Edit: For example, 2.0.16.0 was a primary version since the first version of mod came out for several years.

First 072 project store version update disrupted mod support because it had a new file system which V2p mod version doesn't support. I started to port V2p as is to it, but then it received some more technical updates several times.
At that point I suggested to update to new Spine version with a test base to make the adoption phase faster (project files with 4.2.37 .skel files), without any expectations. To my surprise, I got a confirmation it will be adopted too. So now we're waiting for version of the game 2.1.2.0 to come out so all current features are supported. We can't tell how long will it take to be approved on DLsite because it's a long review process and Tits mod can't be updated without "Primary/Version lock" first.

 

[jonnijimbo]

Hard to tell now because we don't have a current "primary" version of the game right now. Edit: For example, 2.0.16.0 was a primary version since the first version of mod came out for several years.

First 072 project store version update disrupted mod support because it had a new file system which V2p mod version doesn't support. I started to port V2p as is to it, but then it received some more technical updates several times.
At that point I suggested to update to new Spine version with a test base to make the adoption phase faster (project files with 4.2.37 .skel files), without any expectations. To my surprise, I got a confirmation it will be adopted too. So now we're waiting for version of the game 2.1.2.0 to come out so all current features are supported. We can't tell how long will it take to be approved on DLsite because it's a long review process and Tits mod can't be updated without "Primary/Version lock" first.

i see, as an aside though- are there any mods that add anthro women into the mix of monstergirls here? i know thats a big ask because it requires entirely new assets, but i get the sensation its out there somewhere. and if not- would you be willing to consider trying it yourself?

 

[Krongorka]

i see, as an aside though- are there any mods that add anthro women into the mix of monstergirls here? i know thats a big ask because it requires entirely new assets, but i get the sensation its out there somewhere. and if not- would you be willing to consider trying it yourself?

There was a discussion for the entirely new graphical mod in this game forum. I believe the author who wanted to make it did some progress and art for it under the name Fantasy Overhaul (you can check user's post about it here). Don't know how much of it is ready, though... I hope it's not abandoned because there's really not much I can tell about MBM's modding scene.

Tits mod at this point is an overhaul of how base game assets work with a target on performance/debloating assets. I'm really not an artist, but apparently I'm good enough at optimizing/bug testing so my goal is to build a strong foundation which can accept twice more assets with same or better performance than the base game.

Some experimental stuff with Niel:

 

[Krongorka]

Less known fact about Niel, but at some point she appeared like a simple green-robe figure:



It was also supposed to be that way in a censored non-patched "potential Steam" version of the game... which won't happen, but this design was planned to be used.

I have an idea how this could have been realized in main modded game. Basically, she could have appear like that at the start and then appear in her "known full-design" AFTER she's brainwashed. I know how to implement this, but the problem is obvious: this change won't be welcomed. So I guess this sprite will stay unused for the time being.

Anyway, "NPC rebuild 2.0" is ongoing and I just finished Niel character (main Area version). Each re-done NPC receive extra care with a more accurate meshes, ready for physics module as well. I can say for sure that Niel feels more interesting than the rest because she have flasks with liquid and cloth can change states/shape (also drawn as a separate wearable sprite which can be fully disabled).

I tried to add liquid-like animated mesh for a liquid in her mixing flask. For non-physics based version it use 3 bones with some keyed movement. For 4.2 physics version these bones received some properties which allows it to look like a liquid more... but it's hard to keep in flask sprite, thanks to lots of inertia.

Another thing which bothered me a lot is her right (from her POV) leg. Just load the game and check her CG scene: there's golden bracers on both calfs, but she only have one her left leg. Right one doesn't have one and the scale of the leg is off. I know that having her cloth on hides it, but once you see it you just can't unsee it:



Another thing about legs and comparison with her sex CG scene version - scale is also off. Well, for V2p I actually did tweak her leg scale a bit, but for the new version I mirrored her leg sprite which have a bracer too. Just like in sex CG scene.

Other things altered in her skeleton:
- Both shoulders actually connects to body.
- Front cloth is slightly semi-transparent, more transparent bellow (you can see a chair, tail and left leg behind it) than above due to technical reasons.
- Pregnant state use pregnant belly on top of the body mesh instead of replacing it with a full body sprite.
- Pregnant state cloth is now a base one, right side of non-pregnant sprite only gets on/off states now (no need to keep two full sprite versions).
- Eyes are remade to not using eyeball clipping method (face have proper 'eye sockets' now).
- Can properly blink without causing additional draw call.
- Front hair sprite moved a bit to the side to make her right eye a bit more visible. It's a debatable change, but I never liked the way her eye looks behind hair sprite. You can never see it normally and the eyeball itself looks like a glitched sprite due to color overlap with hairs.
- Chair she sits on is mirrored.
- Facial features (eyebrows, nose, mouth) drawn as a single sprite are separated. Which means they can be mixed in new ways. Added animated mouth sequence for a touch animation for a single sprite, hardly noticeable though.



- Eyes use several different sprites so other facial features position had to be altered. Eyes look less sick (but closer to her CG version, I guess).
- Liquid in mixing flask is animated with a single meshed sprite and 3 bones. I shared physics 4.2 test version above. Here's non-physics version:



- Overall skeleton complexity is in-between of V2p and default version as usual. I do need 3-4 times more vertex transforms than V2p use, but it's worth it for expanded movement range. Triangle/Vertices count are way lower, though.



- Texture packing is improved. Fits either standard 'power of two' 1024x512 with space to spare or can be pushed to 632x632 for NPOT variant: