Jump to content

Crajjjj patches hub

crajjjj

Recommended Posts

Bigglsby

Bigglsby

Posted
Posted

Hi Crajjjj, love that you're looking at some fixes for FHU.  For me, I'm having problems with the patches though (have tried for both versions 1.96 and 2.03).

 

For whatever reason, on my setup, the player doesn't accrue any inflation or register a pool.  The first release of the patch (v 1.96), I installed mid-game and noticed it was player specific, and non-players did register and accumulate a pool.  I figured it was an update problem and started fresh - then tried fresh with 2.03 (which bugs out for me with post-deflate tracking problems, I have a theory on OAR animation conflicts, gonna try to test that later).

 

Having tried several times with fresh starts, behavior is the same - with your patches, the player doesn't register any accumulation or inflation (all stats stay 0.000).  I just ran a log to attach for your inspect.  I run .640, with hentairim and your current patches, SLU+.

 

 

Papyrus.0.log

andbgame

andbgame

Posted
Posted
3 hours ago, Bigglsby said:

then tried fresh with 2.03 (which bugs out for me with post-deflate tracking problems, I have a theory on OAR animation conflicts, gonna try to test that later).


Is the original mod installed? (FHU 2.03 + FHU baka 2.0.3 hentairim patch).

Attached logs for FHU 1.96 + FHU baka 1.96 hentairim patch ?

Bigglsby

Bigglsby

Posted
Posted
5 minutes ago, andbgame said:


Is the original mod installed? (FHU 2.03 + FHU baka 2.0.3 hentairim patch).

Attached logs for FHU 1.96 + FHU baka 1.96 hentairim patch ?

 

The attached log is with FHU 1.96 and the 1.96 hentairim patch.

 

Fought with 2.03 hotfix for several hours this morning, trying different things to get the broken crosshair tracking glitch to not happen, but couldn't isolate the problem (not OAR animation conflicts, not skeleton... ). 

Bigglsby

Bigglsby

Posted
Posted
47 minutes ago, andbgame said:


Is the original mod installed? (FHU 2.03 + FHU baka 2.0.3 hentairim patch).

Attached logs for FHU 1.96 + FHU baka 1.96 hentairim patch ?

 

I ran another log, with FHU 2.03 + hentairim patch for 2.03.  Had 2 scenes in the log (random, using Fever dreams as an easy scene starter).  Again, behavior is the same - 0.000 for player pool additions, but MCM does report sperm from both encounters.  In both 1.96 and 2.03 with their patches, inflation controls are locked after a scene, so the mod does recognize that inflation SHOULD be occuring, but nothing is being added to the player pool.

 

 

Papyrus.0.log

andbgame

andbgame

Posted
Posted
44 minutes ago, Bigglsby said:

Fought with 2.03 hotfix for several hours this morning, trying different things to get the broken crosshair tracking glitch to not happen, but couldn't isolate the problem (not OAR animation conflicts, not skeleton... ). 

Unfortunately, after rereading it several times, I could not understand the essence of the problem...

Bigglsby

Bigglsby

Posted
Posted (edited)
28 minutes ago, andbgame said:

Unfortunately, after rereading it several times, I could not understand the essence of the problem...

 

Yeah, I can't figure what the problem is either.  I ran another test out of curiosity, to see if the patch fixed the post-deflate tracking problem:  Running 2.03, without patch, have a scene to create a pool, then enable the patch and deflate.  No dice, the tracking issue still present.

 

The tracking issue if you haven't seen or heard of it before - after deflating (auto or manual), the Y-axis target tracking (imagine where your bow is pointing) is effectively twice what your mouse tracking is.  So at horizon - target crosshairs and arrow are in line.  Aim up 45 degrees, and your arrow is at 90 degrees.  Aim at 90, and you can shoot the horizon behind you.  Opening and closing racemenu resets this, until the next deflation.  Too annoying to play with, so I stick to 1.96 until it is fixed... but I keep thinking up things to try to isolate the problem...  no luck yet.  :(

 

Anyway, attached is a log with the same setup as the previous log, showing application of the pool with 2.03 just without the patch.  Nothing jumps out to me when I looked, just instead of some 0.0000 fill numbers, it's actual values for fill.  Just something is not applying...

 

Papyrus.1.log

Edited by Bigglsby
andbgame

andbgame

Posted
Posted
25 minutes ago, Bigglsby said:

 

I ran another log, with FHU 2.03 + hentairim patch for 2.03.  Had 2 scenes in the log (random, using Fever dreams as an easy scene starter).  Again, behavior is the same - 0.000 for player pool additions, but MCM does report sperm from both encounters.  In both 1.96 and 2.03 with their patches, inflation controls are locked after a scene, so the mod does recognize that inflation SHOULD be occuring, but nothing is being added to the player pool.

 

 

Papyrus.0.log 353.76 kB · 1 download


it's more clear now :) But we need expert in hentairim tags
```
 

[07/29/2025 - 02:10:14PM] [FillHerUp]: >> Penetration:LDI.Oral:LDI.Stimul:LDI.Penis:SDV.Ending:LDI
[07/29/2025 - 02:10:14PM] [FillHerUp]: Chloe slotted to thread 0.
[07/29/2025 - 02:10:14PM] [FillHerUp]: Chloe: Inflating, anal: False, Vaginal: False, Oral: False, cum amount: 0.285000
[07/29/2025 - 02:10:14PM] [FillHerUp]: Chloe: Status: current inflation: 0.000000, target: 0.000000, vaginal cum: 0.000000, anal cum: 0.000000, oral cum: 0.000000
[07/29/2025 - 02:10:14PM] [FillHerUp]: Chloe: Inflated to: 0.000000(0.000000)


```

fyi @crajjjj

crajjjj

crajjjj

Posted
  • Author
Posted (edited)
1 hour ago, andbgame said:


it's more clear now :) But we need expert in hentairim tags
```
 

[07/29/2025 - 02:10:14PM] [FillHerUp]: >> Penetration:LDI.Oral:LDI.Stimul:LDI.Penis:SDV.Ending:LDI
[07/29/2025 - 02:10:14PM] [FillHerUp]: Chloe slotted to thread 0.
[07/29/2025 - 02:10:14PM] [FillHerUp]: Chloe: Inflating, anal: False, Vaginal: False, Oral: False, cum amount: 0.285000
[07/29/2025 - 02:10:14PM] [FillHerUp]: Chloe: Status: current inflation: 0.000000, target: 0.000000, vaginal cum: 0.000000, anal cum: 0.000000, oral cum: 0.000000
[07/29/2025 - 02:10:14PM] [FillHerUp]: Chloe: Inflated to: 0.000000(0.000000)


```

fyi @crajjjj

I think it is fixed now. I mixed up the detection of the giving and receiving sides

Guide on tags here 

Edited by crajjjj
crajjjj

crajjjj

Posted
  • Author
Posted
1 hour ago, redrootcat said:

Do I need to start a new game? Can I use my old save?

It's all script-only patches- no new game needed. (If you change FHU version then maybe though)

Bigglsby

Bigglsby

Posted
Posted
1 hour ago, crajjjj said:

I think it is fixed now. I mixed up the detection of the giving and receiving sides

Guide on tags here 

 

Just wanted to report back.  Both version 1.96 and 2.03 patches are indeed fixed for adding to the cum pool.  👍

 

Unfortunately I'll still be relegated to 1.96 until the random problem some of us have with 2.03 can get dealt with... but that's not really your problem.  :)  1.96 works well (with the assorted patch options), and what works is what's best.  

 

Thanks for the all the fixes you've been putting out, much appreciated!

1
Bigglsby

Bigglsby

Posted
Posted

Unfortunately I think there is an error in the deflate script somewhere - at least in the FHU 1.96 patch.  I don't have a log file for this, but going off visual reference on behavior on deflate.

 

Started up a new game after all my testing and messing with the last issue.  First testing encounter I had - filling and pool were behaving correctly as had been confirmed previously.  But I noticed odd behavior when partially deflating.  It looks like the amount expelled during deflation is being added to the morph instead of removed.  Inflation pool numbers are decreasing, but the morph is increasing.  Looked odd and fully deflated - when empty, morph resets correctly.

 

So I got some more pool to work with for a second test, and did short deflations to gauge behavior, and it (visually at least) confirmed that the morph was being incremented in the opposite direction.  From a .5 fill to .1 fill, the morph was increased steadily until empty (which resets).

 

This wasn't tested with the 2.03 patch, but if you used the same logic, it likely has the same problem.

crajjjj

crajjjj

Posted
  • Author
Posted (edited)
7 hours ago, Bigglsby said:

Unfortunately I think there is an error in the deflate script somewhere - at least in the FHU 1.96 patch.  I don't have a log file for this, but going off visual reference on behavior on deflate.

 

Started up a new game after all my testing and messing with the last issue.  First testing encounter I had - filling and pool were behaving correctly as had been confirmed previously.  But I noticed odd behavior when partially deflating.  It looks like the amount expelled during deflation is being added to the morph instead of removed.  Inflation pool numbers are decreasing, but the morph is increasing.  Looked odd and fully deflated - when empty, morph resets correctly.

 

So I got some more pool to work with for a second test, and did short deflations to gauge behavior, and it (visually at least) confirmed that the morph was being incremented in the opposite direction.  From a .5 fill to .1 fill, the morph was increased steadily until empty (which resets).

 

This wasn't tested with the 2.03 patch, but if you used the same logic, it likely has the same problem.

Hmm, I did not change deflation I think. Is it the same behavior in the original one? In 2.0.3 baka changed deflation code

@andbgame confirmed it was wonky in 1.96

Edited by crajjjj
andbgame

andbgame

Posted
Posted
8 hours ago, Bigglsby said:

So I got some more pool to work with for a second test, and did short deflations to gauge behavior, and it (visually at least) confirmed that the morph was being incremented in the opposite direction.  From a .5 fill to .1 fill, the morph was increased steadily until empty (which resets).

Bodymorph and SLIF is enabled in MCM?

Bigglsby

Bigglsby

Posted
Posted (edited)
18 minutes ago, andbgame said:

Bodymorph and SLIF is enabled in MCM?

 

Bodymorph yes, SLIF no. 

 

Just the default settings related to morphs (except that I tone them down in magnitude).  I don't use SLIF, so those boxes are greyed out also.  It's the same config that I've been using for years, which is why I can isolate behavior to the patch.  Though with the fixes, that may necessitate some changes if my default settings were working around bugs.  :)

Edited by Bigglsby
crajjjj

crajjjj

Posted
  • Author
Posted (edited)
3 hours ago, Bigglsby said:

 

Bodymorph yes, SLIF no. 

 

Just the default settings related to morphs (except that I tone them down in magnitude).  I don't use SLIF, so those boxes are greyed out also.  It's the same config that I've been using for years, which is why I can isolate behavior to the patch.  Though with the fixes, that may necessitate some changes if my default settings were working around bugs.  :)

PLease try this one and share logs 
I tried with both bodymorph and slif and it works ok
[07/30/2025 - 04:03:23PM] [FillHerUp]: SetBellyMorphValue currentInf:0.384999.MorphName:PregnancyBelly
[07/30/2025 - 04:03:23PM] [FillHerUp]: [DefAbility]: deflate currentInf:3.8499930.000000.Cum:3.849993
[07/30/2025 - 04:03:23PM] [FillHerUp]: SetBellyMorphValue currentInf:0.374999.MorphName:PregnancyBelly
[07/30/2025 - 04:03:23PM] [FillHerUp]: [DefAbility]: deflate currentInf:3.7499930.000000.Cum:3.749993
[07/30/2025 - 04:03:24PM] [FillHerUp]: SetBellyMorphValue currentInf:0.364999.MorphName:PregnancyBelly
[07/30/2025 - 04:03:24PM] [FillHerUp]: [DefAbility]: deflate currentInf:3.6499930.000000.Cum:3.649993
[07/30/2025 - 04:03:25PM] [FillHerUp]: SetBellyMorphValue currentInf:0.354999.MorphName:PregnancyBelly
[07/30/2025 - 04:03:25PM] [FillHerUp]: [DefAbility]: deflate currentInf:3.5499930.000000.Cum:3.549993

 

Edited by crajjjj
Bigglsby

Bigglsby

Posted
Posted (edited)
1 hour ago, crajjjj said:

PLease try this one and share logs 
I tried with both bodymorph and slif and it works ok

 

This does fix the inverted morph behavior - deflating now actually is properly reducing the morph.  Attached log has two scenes, first one didn't roll me a FHU viable event.  Pertinent stuff is towards the end as expected though.

 

I've noticed with this testing though, morphs aren't being applied until there is an equipment change to the body slot.  After the troll scene in the log I was pretty filled, and the morph didn't apply until putting on body slot.  Likewise, morphs weren't updated post deflate until putting on something.  Unpatched had the morphs updating at the end of the morph adjustment phase (or delayed a bit with 2.03 I think).  Not a deal breaker, and would often go unnoticed - quite often events have clothing auto-equipped at the end of an event so it would be dealt with then.  Here I'd happened to be nekkid during testing so it was more apparent what was going on.

 

Papyrus.0.log

Edited by Bigglsby
Bigglsby

Bigglsby

Posted
Posted

@crajjjj

Thanks for the update - Confirm for you and any tracking the posts - the 1.96.4 patch has inflate/deflate working, and morphs are being applied and updated in a timely manner (without equip necessary to update).

 

Cheers!  :beer:

1
crajjjj

crajjjj

Posted
  • Author
Posted
3 hours ago, waiyan said:

Is there alternate tears texture for Apropos? Default one looks like crying out milk.

You can try the Diary of mine tears. And share it here pls if it works

 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Go to topic listing

  • Recently Browsing   1 member

×
×
  • Create New...