Sexlab Cum Overlays Extended

[kaxat]

Like some other users I encountered the "-1V, -1O, -1A" issue in the MCM. I wanted to get to the bottom of this issue. So I sprinkled some Debug.Trace() throughout SCO_Utility and SCO_MCM. The cause was surprising but the solution was simple.

 

Something is resetting the SCO_Utility.BodyParts and SCO_Utility.Areas to an empty string array, in between the calls to SCO_Utility.Maintenance() and SCO_Utility.InitCumSets(). I do not know what is resetting this. SCOE has no losing conflict in my MO2, with the exception of sslActorLib getting overriden by P+ (latest). Nothing overrides SCOE in xEdit.

While I may not know the cause, it is easy to fix. I moved the initialization for those two string arrays to its own function called InitializeProps(). That new function gets called in Maintenance(), but now it also gets called during InitCumSets() when it is needed:

 

Function InitCumSets()
    Debug.Trace("SCOE: SCO_Utility.InitCumSets() - Start BodyParts.length=" + BodyParts.length + "; Areas.length=" + Areas.length)

    if BodyParts.length == 0 || Areas.length == 0
        InitializeProps()
    endif

 

This is what my extra Debug.Traces() were outputting prior to this patch. This output comes from a newish save that never had SCO, SCOE, or a similar mod.

 

    SCOE: SCO_Utility.Maintenance() - End BodyParts.length=3; Area.length=4
    [sco_mcm <SCO_MenuQuest (D7003EAD)>] INITIALIZED
    SCO_: Soft check: Zaz Installed: TRUE
    [sco_mcm <SCO_MenuQuest (D7003EAD)>] INITIALIZED
    SCO_: Soft check: Zaz Installed: TRUE
    SCOE: SCO_Utility.InitCumSets() - Start BodyParts.length=0; Area.length=0
    SCOE: Upgraded to v0.0.12

 

As you can see Maintenance() is getting called prior to InitCumSets(). And it is setting these variables. For some reason the MCM INITIALIZED event is getting called twice. OnInit() has some code in it to ensure Maintenance() never runs twice. It won't run even if the quest gets reset. I wonder if the second MCM init is wiping out SCO_Utility's properties, and OnInit() is refusing to set them again? I do not know why INITIALIZED is triggered twice. But the fix is easy. Ensure those properties are set anytime InitCumSets() runs. Also, as near as I can tell the code that prevents Maintenance() from running twice might be erroneous. I foresee no harm in running that function repeatedly. Running it again might have prevented this glitch.

 

Attached is my updated code and the patch for anyone else facing this issue on v0.0.16 of this mod. Here is a diff so you can compare. As you can see I sprinkled a lot of Debug.Trace code in there. The fix boils down to what I mentioned above. The debug code was written before getting to the bottom of the issue.

 

I would like to provide some constructive feedback on your mod description. It says your mod requires PapyrusUtils (latest). I recommend changing that to PapyrusUtils 3.9+. The latest version of PU is always tied to the latest verion of Skyrim AE (currently v1.6.1130 from last month). Of course many users can not update Skyrim to the latest version, without removing numerous mods and starting a new game. Fortunately your mod does not really require the latest, only 3.9+ for full functionality. And it looks like you have backwards compatibility code in place for even older versions of PU, like those LE uses. Old versions will have to use older naming rules for texture packs. That might be worth noting somewhere.

 

Just a friendly bit of feedback from the perspective of a mod user. I nearly skipped trying out your mod because of that "requirement". Fortunately I noticed that your mod says it is LE compatible. At which point I dug into your code, and discovered that your mod actually is compatible with my version of Skyrim/PU.

 

After patching my issue your mod has been working great for numerous gameplay hours. Thank you very much for an excellent mod!

SCOE 1.6 Kax Patch.7z

[ponzipyramid]

On 1/12/2024 at 7:07 PM, kaxat said:

Like some other users I encountered the "-1V, -1O, -1A" issue in the MCM. I wanted to get to the bottom of this issue. So I sprinkled some Debug.Trace() throughout SCO_Utility and SCO_MCM. The cause was surprising but the solution was simple.

 

Something is resetting the SCO_Utility.BodyParts and SCO_Utility.Areas to an empty string array, in between the calls to SCO_Utility.Maintenance() and SCO_Utility.InitCumSets(). I do not know what is resetting this. SCOE has no losing conflict in my MO2, with the exception of sslActorLib getting overriden by P+ (latest). Nothing overrides SCOE in xEdit.

While I may not know the cause, it is easy to fix. I moved the initialization for those two string arrays to its own function called InitializeProps(). That new function gets called in Maintenance(), but now it also gets called during InitCumSets() when it is needed:

 

Function InitCumSets()
    Debug.Trace("SCOE: SCO_Utility.InitCumSets() - Start BodyParts.length=" + BodyParts.length + "; Areas.length=" + Areas.length)

    if BodyParts.length == 0 || Areas.length == 0
        InitializeProps()
    endif

 

This is what my extra Debug.Traces() were outputting prior to this patch. This output comes from a newish save that never had SCO, SCOE, or a similar mod.

 

    SCOE: SCO_Utility.Maintenance() - End BodyParts.length=3; Area.length=4
    [sco_mcm <SCO_MenuQuest (D7003EAD)>] INITIALIZED
    SCO_: Soft check: Zaz Installed: TRUE
    [sco_mcm <SCO_MenuQuest (D7003EAD)>] INITIALIZED
    SCO_: Soft check: Zaz Installed: TRUE
    SCOE: SCO_Utility.InitCumSets() - Start BodyParts.length=0; Area.length=0
    SCOE: Upgraded to v0.0.12

 

As you can see Maintenance() is getting called prior to InitCumSets(). And it is setting these variables. For some reason the MCM INITIALIZED event is getting called twice. OnInit() has some code in it to ensure Maintenance() never runs twice. It won't run even if the quest gets reset. I wonder if the second MCM init is wiping out SCO_Utility's properties, and OnInit() is refusing to set them again? I do not know why INITIALIZED is triggered twice. But the fix is easy. Ensure those properties are set anytime InitCumSets() runs. Also, as near as I can tell the code that prevents Maintenance() from running twice might be erroneous. I foresee no harm in running that function repeatedly. Running it again might have prevented this glitch.

 

Attached is my updated code and the patch for anyone else facing this issue on v0.0.16 of this mod. Here is a diff so you can compare. As you can see I sprinkled a lot of Debug.Trace code in there. The fix boils down to what I mentioned above. The debug code was written before getting to the bottom of the issue.

 

I would like to provide some constructive feedback on your mod description. It says your mod requires PapyrusUtils (latest). I recommend changing that to PapyrusUtils 3.9+. The latest version of PU is always tied to the latest verion of Skyrim AE (currently v1.6.1130 from last month). Of course many users can not update Skyrim to the latest version, without removing numerous mods and starting a new game. Fortunately your mod does not really require the latest, only 3.9+ for full functionality. And it looks like you have backwards compatibility code in place for even older versions of PU, like those LE uses. Old versions will have to use older naming rules for texture packs. That might be worth noting somewhere.

 

Just a friendly bit of feedback from the perspective of a mod user. I nearly skipped trying out your mod because of that "requirement". Fortunately I noticed that your mod says it is LE compatible. At which point I dug into your code, and discovered that your mod actually is compatible with my version of Skyrim/PU.

 

After patching my issue your mod has been working great for numerous gameplay hours. Thank you very much for an excellent mod!

SCOE 1.6 Kax Patch.7z 6.04 kB · 12 downloads

 

Appreciate the feedback! I mentioned a couple pages back that I'm working on a rewrite but I can integrate your changes for an update in the interim if you're okay with that.

[kaxat]

1 hour ago, ponzipyramid said:

 

Appreciate the feedback! I mentioned a couple pages back that I'm working on a rewrite but I can integrate your changes for an update in the interim if you're okay with that.

 

Absolutely! You can do anything you want with my snippets of code. I'm not worried about credit or anything. It's just a simple patch.

 

Good to know an update is in the works. That is exciting.

[VaunWolfe]

I am a little confused I am using the original Le version and I am working on the shift over should the file layout be Texture then Sexlab - Cum Overlays Instead of anal oral or vaginal it is set1 set2. And in set1 it is all cum textures for one modder then and in set2 would be from another modder?

Edited January 15 by VaunWolfe

[AndreaSwag]

Cum disappears after loading a save (HELP)

[coegcoeg]

3 hours ago, AndreaSwag said:

Cum disappears after loading a save (HELP)

just have asegs again duh

[eclipsed7774]

No sure if this problem I am having is related to this mod or just Sexlab itself but if i have apply orgasm effects on(cum) it removes all overlays from NPCs. 

[Maidenslayer]

Do you (ponzipyramid) have any near-term plans to update SCOE 0.1.0 to work with Skyrim 1.6.1130 and SexLabFrameworkAE_v166?

[40Karats]

Is this compatible with SlaveTats? SCOE was working fine without it, but cum doesn't appear if I have tats, neither after sex or adding from the SCOE debug menu. I've increased my overlay slots and I know it says slots are shared but I'm not quite sure why its not working.

 

Edit: I solved it. I had changed my body overlay number to 12 but for whatever reason SCOE just doesn't like the number 12 (other people had the same problem if you go back in this thread). I changed it to 18 and this works perfectly.

Edited January 18 by 40Karats

[Gudulba]

Osmel usually states that nothing should ever overwrite his SexLab Utility Plus. The latest Cum version conflicts with one of his files (sslActorLibrary, see spoiler section). Is that a problem?

Spoiler

 

Edited January 18 by Gudulba

[ponzipyramid]

2 hours ago, Gudulba said:

Osmel usually states that nothing should ever overwrite his SexLab Utility Plus. The latest Cum version conflicts with one of his files (sslActorLibrary, see spoiler section). Is that a problem?

  Reveal hidden contents

 

 

You should be able to overwrite SCOE. I'll update the description soon.

[Kenway21]

Does 'Bathing in Skyrim' work well with this mod right from start? or do I have to toggle something in the MCM, like the "swimming removes cum"? 

[libertyordeath]

So after half a year i gave this mod another go, and.... having been burned by racemenu overlays before, i took precautions and tested on a throwaway save.

 

Result: This thing is still just as buggy as half a year ago, and it leaks overlays like a bottomless bucket, despite the author back then insisting that he will be careful about this.

 

So yeah, i'll wait for the rewrite. And then i'll let other players be the testdummy first.

[ponzipyramid]

2 hours ago, libertyordeath said:

So after half a year i gave this mod another go, and.... having been burned by racemenu overlays before, i took precautions and tested on a throwaway save.

 

Result: This thing is still just as buggy as half a year ago, and it leaks overlays like a bottomless bucket, despite the author back then insisting that he will be careful about this.

 

So yeah, i'll wait for the rewrite. And then i'll let other players be the testdummy first.

 

The changelog doesn't indicate these problems have been resolved and as mentioned above the rewrite is still underway so what exactly is the purpose of this post? Restating known issues is not helpful.

 

For anyone who is curious about the rewrite, I've finished the native overlay manager's application system and begun patching SlaveTats to use it which will solve those conflicts between it and SCOE. Still a decent amount of work to go but once that is complete, I can use it in the rewrite.

Edited January 27 by ponzipyramid

[km4387]

12 minutes ago, ponzipyramid said:

 

The changelog doesn't indicate these problems have been resolved and as mentioned above the rewrite is still underway so what exactly is the purpose of this post? Restating known issues is not helpful.

 

For anyone who is curious about the rewrite, I've finished the native overlay manager's application system and begun patching SlaveTats to use it which will solve those conflicts between it and SCOE. Still a decent amount of work to go but once that is complete, I can use it in the rewrite.

Just keep doing what you're doing.  Still using this mod cause it does what I want and I'm capable of fixing any minor hiccups.  Naysayers be damned - one of my favorite mods - thank you.

[NotAWeaboo]

Hey, having some issues with this on LE. It seems that other mods (specifically Sexlab Adventures) isn't detecting number of cum overlays correctly - it seems like it's always assuming 0 cum layers. I'm not sure if it's a compatability issue or if that function of SL Adventures is broken out of the box, but I'm curious if this is something that's come up before. 

[AureumCustos]

Hey im having a really weird issue where everything is working normally but during a scene and when adding a new layer during scenes the textures for the cum flash black a bunch. This doesn't stop until the scene is over so I was wondering if its a scanner issue?

[Yuni]

Thank you for your hard work, working on this deary. I really appreciate it. I know people can be buttheads about it. Legendary Edition player here.

[Jenova23]

I'm not sure if this is from this mod or Sexlab Aroused Creatures SE, but I believe it's the only cum overlay I have installed but I get this fatal error that corrupted all my saves. 

Spoiler

 

Edited February 4 by Jenova23

[NiffyFox]

dirt and blood isnt working with this

[zato770]

On 4/15/2023 at 12:22 AM, zato770 said:

If there was any way you could get normal maps working I would love you so much.

 

Also a great fallout mod to take inspiration from: 

 

The effect achieved in game with enb is so far beyond anything else I have seen. The screenshots do not quite do it justice. 

 

So far every texture pack or mod (incl oCum) the effects looked good on screenshots, but bad in game with ENB.

 

oCum does use some complimentary meshes, which are a nice addition. 

 

Moisturiser seems to achieve its meshes with 1 bodyslide and 2-3 meches on player (similar to old SL system.) To my knowledge. 

still praying on this effect ❤️ 

[dremora12]

On 7/23/2023 at 3:25 PM, tattooleak said:

Never mind I finally managed to fix it. The problem was I missed out on a recent  2023 papyrus extender update. Doing that well the overlays are appearing. 

Please tell me what kind of textures are you using? It looks gorgeous and as if in 3D.

[Bigglsby]

13 minutes ago, dremora12 said:

Please tell me what kind of textures are you using? It looks gorgeous and as if in 3D.

 

Those are special cum effects from BaboDialog - mod event specific.  They are 3D, built in bodyslide and applied after various mod events - not applied as standard sexlab cum effects though.

[dremora12]

16 minutes ago, Bigglsby said:

 

Those are special cum effects from BaboDialog - mod event specific.  They are 3D, built in bodyslide and applied after various mod events - not applied as standard sexlab cum effects though.

It's sad, I really wanted high-quality 3D textures. Thanks for the answer!

[Bigglsby]

21 hours ago, dremora12 said:

It's sad, I really wanted high-quality 3D textures. Thanks for the answer!

 

Agreed.  I think Baka actually got perms to use them from Commonwealth Moisturizer... that's my understanding (could be wrong though).