SL Anims Do Not Support CBPC Gravity?

[libertyordeath]

Just wasted 2 hours trying to get a feature to work, that apparently is pure placebo. Or more specifically not supported by sexlab: CBPC gravity.

 

You see, normally CBPC checks the actor's orientation and applies gravity to bodyparts. And since everything about CBPC is cheaty, it has two forces for this instead of one: Gravity and Anti-Gravity (called InvertedGravityCorrection). The former applies when the actor is upgright, and the later when she's upside down - inbetween the two CPBC does some interpolation magick.

 

Cool, except it does not seem to work for sexlab scenes. I tried low values, high values, positive values, negative values - finally i enabled CBPC tuning, to see if changing values even makes a difference at all. The answer: NO! Those gravity values do absolutely nothing in sexlab scenes. 

 

So this got me thinking: How does CBPC determine the actor's orientation? Does it look at individual nodes, or just if the actor as a whole is considered "rotated"? Because if it's the later, i'm pretty sure that information isn't available during SL scenes. After all, the game itself thinks the actors are just playing standing idle anims, correct? So CBPC thinks the actors are standing upgright the whole time in SL scenes?

[traison]

Funny this comes up now of all times. I just finished a fix for this some week ago. I promised the author of CBPC I wouldn't compete with their mod however so all I can do is throw source code edit hints at you.

 

Edit: Also my CPBC has other edits you may or may not like:

• Adjusted how much the front door opens.
• Changed the way LinearZrotation.Z works to allow for a more natural motion for large booba.
• Fixed double collisions for the belly bone. (this has been reported to the CPBC author a long time ago but as far as I know it hasn't been made official)
• Fixed gravity and inverted gravity calculation.
• Added a new Papyrus function for improving physics during inflations: SetBellyWobble

Edited August 2, 2024 by traison

[libertyordeath]

1 hour ago, traison said:

Funny this comes up now of all times. I just finished a fix for this some week ago. I promised the author of CBPC I wouldn't compete with their mod however so all I can do is throw source code edit hints at you.

(Sigh) I wouldn't mind waiting for the CBPC author to merge your changes. But that's assuming that he will merge them, and do so in a reasonable timeframe. Unfortunally sourcecode edits aren't usable to me, because of my windows and skyrim version. I can't even get CK to run, so i'm basically limited to external tools like xedit.

 

1 hour ago, traison said:

 

Edit: Also my CPBC has other edits you may or may not like:

• Adjusted how much the front door opens.
• Changed the way LinearZrotation.Z works to allow for a more natural motion for large booba.
• Fixed double collisions for the belly bone. (this has been reported to the CPBC author a long time ago but as far as I know it hasn't been made official)
• Fixed gravity and inverted gravity calculation.
• Added a new Papyrus function for improving physics during inflations: SetBellyWobble

Speaking of coincidences (or bright minds thinking alike) most of the above are things that have bothered me for a long time:

 

I was never happy with the vagine opening settings, regardless of which values and nodepositions and spheres i tried.

 

I constantly am annoyed by double-collisions with the spine-node causing wild bellyjitter. And if i don't use multinodes, a single collider might go past the sphere - with results you've probably seen before.

 

Bellyphysics? Checked them out years ago and considered them useless for this exact reason: No way to differentiate flat bellies from inflated ones, unless you bake it into actor weight.

 

Horizontal rotation (Rot-Z)? Not sure if its the same thing you noticed, but in my case the problem was any somewhat realistic values would make them wildly slap left and right during normal walking. So i have those dimished too for the time being.

 

Are you sure you don't wanna compete with the CBPC author? 😛 I mean purely egoistically speaking, you seem to get all the stuff sorted out that has bothered me for years about CBPC. 

Edited August 2, 2024 by libertyordeath

[traison]

7 minutes ago, libertyordeath said:

Bellyphysics? Checked them out years ago and considered them useless for this exact reason: No way to differentiate flat bellies from inflated ones, unless you bake it into actor weight.

 

The papyrus function I added gets called from my own version of SLIF. Whenever inflation or deflation happens it updates the normal maps (without the so called pizza hands issue and without the gloves workaround) and passes the current value to CBPC and this internally adjusts physics values to make things... well more wobbly. Downside here is, since this is a personal edit, the values are hardcoded.

 

9 minutes ago, libertyordeath said:

Horizontal rotation (Rot-Z)? Not sure if its the same thing you noticed, but in my case the problem was any somewhat realistic values would make them wildly slap left and right during normal walking. So i have those dimished too for the time being.

 

This is something I've been considering fixing as well, but its not what I was talking about. The reason why I changed the way this work is that I wanted to simulate this sort of rotational motion you get on large bobs. For a lack of a better name I just called it "clapping" because I mean, that's sort of what they're doing. Anyhow, the side-effect of enabling this is that when actors are upside down, laying down or on their knees the nipples want to turn themselves inside out or they disappear into the armpits or something. I simply changed the way the rotation works so the motion is stable in all orientations.

 

11 minutes ago, libertyordeath said:

Are you sure you don't wanna compete with the CBPC author?

 

As with all my mods they're part of a separate ecosystem. I mentioned before that things are hardcoded, because I didn't feel like bothering exposing these values to the config files. The double belly collision issue I simply fixed by breaking regular belly collisions completely when the proper fix would have been to first check for whether BellyBulge > 0. Why do it properly when I was the only one that was going to use this, and I have the development pipeline setup.

 

16 minutes ago, libertyordeath said:

I mean purely egoistically speaking, you seem to get all the stuff sorted out that has bothered me for years about CBPC.

 

I suppose you can have my dll, if you trust me, agree with all my edits and its compatible with your game. Its version 1.5.7 for 1.5.97 (skse 2.00.20).

[libertyordeath]

3 hours ago, traison said:

 

The papyrus function I added gets called from my own version of SLIF. Whenever inflation or deflation happens it updates the normal maps (without the so called pizza hands issue and without the gloves workaround) and passes the current value to CBPC and this internally adjusts physics values to make things... well more wobbly. Downside here is, since this is a personal edit, the values are hardcoded.

Would things break in a bad way, if SLIF simply wasn't present? Or would the inflation features you added simply not be available? I'm running Hentai Pregnancy specifically to avoid dealing with SLIF. If SLIF is a hard dependency, sure i'll happly pay that price since the benefits outweight the downsides. But if i could simply not use the inflation features in order to avoid SLIF, i'd rather do that.

 

3 hours ago, traison said:

 

This is something I've been considering fixing as well, but its not what I was talking about. The reason why I changed the way this work is that I wanted to simulate this sort of rotational motion you get on large bobs. For a lack of a better name I just called it "clapping" because I mean, that's sort of what they're doing. Anyhow, the side-effect of enabling this is that when actors are upside down, laying down or on their knees the nipples want to turn themselves inside out or they disappear into the armpits or something. I simply changed the way the rotation works so the motion is stable in all orientations.

My first thought was i haven't seen this bug myself, but then i remembered i have my breast physics heavily "fenced off" (for lack of a better word), with many events disabled specifically because i encountered all kinds of weird stuff in breast collision physics before. In other words: What you're describing might actually have contributed to me disabling the majority of 3b collision physics in my setup.

 

 

3 hours ago, traison said:

 

 

As with all my mods they're part of a separate ecosystem. I mentioned before that things are hardcoded, because I didn't feel like bothering exposing these values to the config files. The double belly collision issue I simply fixed by breaking regular belly collisions completely when the proper fix would have been to first check for whether BellyBulge > 0. Why do it properly when I was the only one that was going to use this, and I have the development pipeline setup.

Wait a moment! I must be missing something here, which makes me think maybe we're talking about completely different things. This is about multiple colliders affecting a single receptor sphere - such as multiple nodes of a dick colliding with the spine/belly node (depending which is used for bulge). Is this correct? If yes: How would you prevent single node collision events at all? After all, there always first will be one node colliding first (such as the tip of a dick), and then maybe a second one. It never happens simultaneusly, so how can your hack work if it breaks on single-node collisions?

 

3 hours ago, traison said:

 

 

I suppose you can have my dll, if you trust me, agree with all my edits and its compatible with your game. Its version 1.5.7 for 1.5.97 (skse 2.00.20).

(Bows deeply) Thank you Traison!

 

Here's the bad news: I'm on GOG SkyrimAE 1.6.59, SKSE 2.2.3, CBPC 1.6.3.0.

Edited August 2, 2024 by libertyordeath

[traison]

56 minutes ago, libertyordeath said:

Would things break in a bad way, if SLIF simply wasn't present?

 

Whichever system you use, you'd have to add the call to SetBellyWobble yourself into its scripts.

 

56 minutes ago, libertyordeath said:

Wait a moment! I must be missing something here, which makes me think maybe we're talking about completely different things. This is about multiple colliders affecting a single receptor sphere - such as multiple nodes of a dick colliding with the spine/belly node (depending which is used for bulge). Is this correct?

 

Multiple colliders causing issues was alleviated slightly in some changes we made in 1.5.7 but there's still some issues I'm quite certain. It seems a bit... unpredictable sometimes. I think this all stems from the fact that CBPC does not have the concept of volume displacement. This is why a pencil can cause the same effect as a baseball bat. Its always calculated as one collision shape pushing another collision shape, never one collision shape entering another collision shape, and the overlapping volume being used as the resulting effect. This is why its practically impossible to get a larger belly bulge from a giant as you get from a wolf. Its more about where the dong is, not how big it is.

 

The issue I'm talking about is that when BellyBulge is > 0 the NPC Belly node gets collided with twice. Once through the collider shape defined for Spine1 and again for NPC Belly, despite NPC Belly not having a collision shape defined in the config. This is because the Spine1 shape is copied to the NPC Belly node. I simply added a check that ignores the NPC Belly node completely when colliding, obviously breaking actual belly node collisions (but not the BellyBulge effect).

[libertyordeath]

2 hours ago, traison said:

 

The issue I'm talking about is that when BellyBulge is > 0 the NPC Belly node gets collided with twice. Once through the collider shape defined for Spine1 and again for NPC Belly, despite NPC Belly not having a collision shape defined in the config. This is because the Spine1 shape is copied to the NPC Belly node. I simply added a check that ignores the NPC Belly node completely when colliding, obviously breaking actual belly node collisions (but not the BellyBulge effect).

That sounds like an outright bug. Not indirectly, as in user interface or experience, but straight up technical breach of spec: It's supposed to do X, but instead does Y. It's different to what i have been trashtalking CBPC for in the past, which was mostly bad documentation and misleading interfaces. This is different: CBPC is supposed to use either one or another mode for belly bulge - not both at the same time. So in my opinion, this is outside of you making changes for your own preferences: It's a straight up bugfix that should be merged into the main branch. Even if it's flawed and dirty by your own admission, it's closer to how things should work in theory than the current implementation. If i was in charge of maintaining CBPC, i would either merge your patch as a temporary hotfix, then work on a clean fix, or drop everything and fix it clean immediatelly.

 

And now on a completely different topic: What does it take to recompile across skyrim and SKSE versions? I'm not expecting you to do so, but since i don't have access to the tools, and i've seen developers moaning at the prospect, i'm just curious what does it actually take? To be more specific: Is this the best case scenario, where devs just need to download some files, and define some exceptions in the equivalent of makefiles, or is this full-on progressive tyranny, where shitheads in charge expect you have only the latest of everything, and if you want to do anything cross-version, go fuck yourself?

Edited August 3, 2024 by libertyordeath

[traison]

7 hours ago, libertyordeath said:

If i was in charge of maintaining CBPC, i would either merge your patch as a temporary hotfix, then work on a clean fix, or drop everything and fix it clean immediatelly.

 

Basically my message to Shizof was "Here's a thing I made to work around a problem. Consider implementing it properly like you did with my previous messes."

 

7 hours ago, libertyordeath said:

What does it take to recompile across skyrim and SKSE versions?

 

In the case of SE -> AE, as far as I know only the SKSE API changed a bit. Its the mods that use hardcoded offsets or fancy assembly hackery that can be problematic to convert over. Offsets need to be found again, and assembly code may need to be changed, code caves found again etc. I believe this is partly why we have CommonLibSSE and Address Library.

 

In the case of CPBC however, all this should be done already. I'd only need to document my changes and move them over. The areas I've been messing around in are already marked with comments so it shouldn't be too horrible to do.

[libertyordeath]

9 hours ago, traison said:

In the case of SE -> AE, as far as I know only the SKSE API changed a bit. Its the mods that use hardcoded offsets or fancy assembly hackery that can be problematic to convert over. Offsets need to be found again, and assembly code may need to be changed, code caves found again etc. I believe this is partly why we have CommonLibSSE and Address Library.

 

In the case of CPBC however, all this should be done already. I'd only need to document my changes and move them over. The areas I've been messing around in are already marked with comments so it shouldn't be too horrible to do.

So basically, unless a mod hooks into lots of undocumented engine functions, it's not too complicated? It's just extra work from having to maintain a codebase for multiple versions?

 

In that case, it's not like i need constant updates, and neither am i planning to change skyrim versions. So it would be a one time thing.

In that case, take your time and only do it when you got nothing else to do. I'm just grateful you're considering to recompile for my version at all. 

[traison]

Sent you a PM with download. I obviously can't test it so that your problem. See the changes.txt file for what was has been changed, you will need to change your physics configs.

• Note that most of the gravity parameters are gone and replaced with new ones.
  • gravityBiasInvertedStart could be 0.3
  • gravityBiasInverted could be 0.05
  • gravityCorrection could be 1.47
  • gravityBias could be 0.021 (this hasn't been changed, use this as a reference to calculate ratios between your own bias and mine to determine what the other values should be.)
• The changes to the gravity calculations had effects on pretty much everything but I find that generally the pre-change config values still work.

Basically there is no inverted gravity correction anymore, and gravity actually points *down* now, not whichever way your character's spine happens to be pointing.

 

Edit: And no there is no source for this becauase of what I said earlier. There is nothing stopping me from asking for permission from Shizof to make this a separate fork, but at the moment I don't have time in my day to do that.

Edited August 3, 2024 by traison

[libertyordeath]

3 hours ago, traison said:

Sent you a PM with download. I obviously can't test it so that your problem. See the changes.txt file for what was has been changed, you will need to change your physics configs.

• Note that most of the gravity parameters are gone and replaced with new ones.
  • gravityBiasInvertedStart could be 0.3
  • gravityBiasInverted could be 0.05
  • gravityCorrection could be 1.47
  • gravityBias could be 0.021 (this hasn't been changed, use this as a reference to calculate ratios between your own bias and mine to determine what the other values should be.)
• The changes to the gravity calculations had effects on pretty much everything but I find that generally the pre-change config values still work.

Basically there is no inverted gravity correction anymore, and gravity actually points *down* now, not whichever way your character's spine happens to be pointing.

 

Edit: And no there is no source for this becauase of what I said earlier. There is nothing stopping me from asking for permission from Shizof to make this a separate fork, but at the moment I don't have time in my day to do that.

Thank you Traison. Are you sure it's compiled for SkyrimAE 1.6.59, SKSE 2.2.3, CBPC 1.6.3.0 ?

 

 

Maybe it's just that the binary is missing some flag so it's recognized as built for the above version? Also, since you didn't make your SLIF-fork part of the PMed DL, am i correct to assume that it should work without SLIF? The bellywobble feature simply wouldn't be used?

 

 

Edited August 3, 2024 by libertyordeath

[traison]

12 hours ago, libertyordeath said:

Are you sure it's compiled for SkyrimAE 1.6.59, SKSE 2.2.3, CBPC 1.6.3.0 ?

 

Nope. I grabbed the source for 1.6.3 post-AE which seems to be made for 2.2.6 of SKSE maybe?

"CBPC SSE - 2.2.6 - Source 1.6.3"

 

Edit: Had a look at the source and it does not report itself as being in any way version dependant to SKSE. Not sure where that error is coming from.

 

Edit again: Actually it might want 1.6.1170. I'll see if that can be changed without consequences.

 

Edit again: Are you sure its 1.6.59? This does not seem to be a known GOG version.

 

12 hours ago, libertyordeath said:

Also, since you didn't make your SLIF-fork part of the PMed DL, am i correct to assume that it should work without SLIF? The bellywobble feature simply wouldn't be used?

 

My SLIF isn't the same as the LL/SL SLIF, its not a fork. It's built from the ground up to be the foundation of my 30 or so other mods. Its several hundered times faster than SLIF (as it was at the time I started making my own stuff) mainly because its integrated but also because its made differently. You'd have to swap out everything LL related you have, starting with SL itself, if you wanted to use my stuff. That's why I'm not releasing it. I'd much rather try to help people build their own stuff than come here on LL and say "Right guys its time you stop using everything you're using now and switch over to my world and my way of thinking." I think that would be rather rude.

 

So yes, no belly wobble for you unless you do it yourself. It's not complicated, if you have Papyrus compiling working.

Edited August 4, 2024 by traison

[traison]

Sent another pm with a build that's hopefully targeted at 1.6.659 (I assume this is what you meant).

[libertyordeath]

3 hours ago, traison said:

 

Nope. I grabbed the source for 1.6.3 post-AE which seems to be made for 2.2.6 of SKSE maybe?

"CBPC SSE - 2.2.6 - Source 1.6.3"

 

That's SKSE for AE 1,6,1xxx (the post thousand) builds. Major changes - almost every plugin broke when skyrim crossed the 1000 buildnumber. Accordingly most plugins either use the addresslibrary, or there are seperate builds for 1.6.6xx and 1.6.1xxx.) 

 

3 hours ago, traison said:

 

Edit: Had a look at the source and it does not report itself as being in any way version dependant to SKSE. Not sure where that error is coming from.

The error is thrown by skse-loader, which almost certainly checks if the plugin was built for the matching SKSE version. My experience as a user - rather than compiler - is as follows:

 

1. Plugins are either built depending on addresslibrary, in which case there typically is a build for SE and another for AE.

2. Otherwise there typically are three AE builds: Pre 6xx AE, 6xx AE, and post 1xxx. 

3. Some more complex plugins only work with the EXACT SKSE version. IIRC this has been true for CBPC: It always had builds for every single SKSE version, and using mismatched version - even if just one version apart (such as 640 vs 659) it would not load.

 

 

3 hours ago, traison said:

Edit again: Are you sure its 1.6.59? This does not seem to be a known GOG version.

MY MISTAKE, SORRY. It's Skyrim AE 1.6.659, which is the GOG counterpart to Steam 1.6.640. My reported SKSE and CPBC versions were correct: SKSE 2.2.3, CBPC 1.6.3.0

 

3 hours ago, traison said:

 

 

My SLIF isn't the same as the LL/SL SLIF, its not a fork. It's built from the ground up to be the foundation of my 30 or so other mods. Its several hundered times faster than SLIF (as it was at the time I started making my own stuff) mainly because its integrated but also because its made differently. You'd have to swap out everything LL related you have, starting with SL itself, if you wanted to use my stuff. That's why I'm not releasing it. I'd much rather try to help people build their own stuff than come here on LL and say "Right guys its time you stop using everything you're using now and switch over to my world and my way of thinking." I think that would be rather rude.

 

So yes, no belly wobble for you unless you do it yourself. It's not complicated, if you have Papyrus compiling working.

Got it! That's not just fine, it's actually the best scenario for me: Skipping the bellywobble in exchange for not needing SLIF was my prefered behavior from the start.

 

EDIT: Wrote this while you were typing your second above post. Will check it out immediatelly. Again: Sorry for the confusion: My correct versions are SkyrimAE 1.6.659, SKSE 2.2.3, CBPC 1.6.3.0

 

Edited August 4, 2024 by libertyordeath

[traison]

@libertyordeath was kind enough to let me borrow their computer for 5 hours but I was unable to get the dll working. The debugger approach failed, most likely because of the exotic setup they're running, so I still don't have an error message associated with the crash. Current thinking is that this is just me not knowing how to compile for skse 2.2.3.

 

So if anyone knows how to bend CBPC 1.6.3 for skse 2.2.6 (or any version) to run on skyrim 1.6.659 (GOG) skse 2.2.3 please enlighten me.

[traison]

liberyordeath found the CBPC GOG source and now it compiles. Version numbers are not an exact match:

 

SKSE version: The source suggests 2.2.2, but the file name suggests 2.2.3.

CBPC version: 1.6.2 according to the file name.

 

The annoying thing is I don't know WHY, as in, I couldn't take some arbitrary CBPC version and make it work on another game version.

• Windows SDK version, doesn't matter, even if it doesn't match the target computer. As expected, because this should only matter in cases where the API was changed, and that change is relevant to the application being built and the environment(s) where its to be used.
• The buildtools version didn't matter in this case. Again, as expected. v143 was used to build.

Previously I tried:

• Changing buildtools versions.
• Changing Windows SDK versions.
• Editing the SKSE version definitions to make it unaware of newer versions.
• Building CBPC 1.6.3 post-AE on different versions of SKSE:
  • 2.2.6 (steam)
  • 2.2.3 (steam)
  • 2.2.3 (gog)

All previous attempts ended with an instant crash when SKSE loads the dll. Edit: Building on 2.2.3 (gog) resulted in error code 0x45A as if DllMain had returned false. The DllMain in skse64.cpp can only return TRUE however. No further information on that.

 

So, for the TODO list:

• Grab the sources of SKSE 2.2.2 (steam), 2.2.3 (steam), 2.2.2 (gog) and 2.2.3 (gog) and run them through diff against the sources that work.
• Locate the sources of the closest relative of the CBPC 1.6.2 run it through diff against the sources that work.

Edited August 11, 2024 by traison