Update Post : Succubus Heart 5.3.6 DEV [Skyrim Mod]

Got another update out, this time with some ‘real’ fixes for OStim! I think… maybe.. hopefully? Turns out I was right in my post last update about Ostim’s internal systems not working correctly, so I was able to get more information, figure out some stuff I was doing incorrectly (I was given false information before when I got help with OStim which caused some issues) and made some work arounds for the issues caused directly by OStim. In addition to your usual set of bug fixes and QOL improvements I also transitioned all the consumable items in Succubus Heart into being either food (Sexual Fluids) or into untagged potions (Soul of items, souls, rare drops). This means Sexual Fluids ‘should’ now be fully compatible with survival/hunger mods! I tested with SunHelm which pops up a menu asking what the ‘food’ should be considered (I chose soup so it fills both hunger and thirst a small amount).

Some users of OStim have still reported animation trigger issues, however I can’t confirm whether it’s Succubus Heart, their set-ups, or OStim at this time, but hopefully I can get more information at some point to get OStim support into a proper release version at some point! OStim also will have a few features for NPC exclusive acts given the previous issues I ran into which would require some sort of extensive work around that I haven’t decided whether is worth the effort and script weight or not...

Download Links :
GDrive : https://drive.google.com/drive/folders/1yqt2P0fu2JRsjOIcuD7kAa03JuQ3rvZw?usp=drive_link
Mega : https://mega.nz/folder/xgBQDJRQ#4ucsQDMkY1thmkfM6sjy5g

Detailing the OStim Issue

Since the last update I was able to get some additional help over on the OStim Standalone Discord that helped me solve some of the issues we’ve been having with OStim support (thank you to those that helped me out! ^-^). Firstly I found out I was given some false information on what events I should use and when they trigger, I was lead to believe the mod event ostim_thread_orgasm would trigger when any actor orgasmed, however it was actually ostim_actor_orgasm! I was using a different event for the player, so that was triggering orgasms events properly but the one used for NPC was just straight up invalid so it was never called (something I had found out previously, though the fact the player event triggered had me a bit confused thinking it was just inconsistent).

The real confusing part comes from the end animation event. For Succubus Heart’s systems to work properly it needs both a start and end point, for SexLab I just use the begin anim and end anim events to toggle between states and manage when certain effects go off, but when transitioning this system to OStim I didn’t realize the 2 frameworks handle these sorts of cases in fundamentally different ways. SexLab’s tracking requires you to register/apply what actors you wish to track then sends an event call for every actor being tracked, Succubus Heart already has to track all NPCs to apply various effects such as combat seduction so we just use that method to track all relevant actors. OStim on the other hands doesn’t track actors, instead it only manages individual animation ‘threads’ without any tracking of actors. This means that while SexLab always sends the required event, once for every actor in an animation meaning I can just execute the required code specifically to each actor, OStim only reports the thread of the animation that sent the event, this means I have to manually pull the actors and then loop over them to apply the correct code. Because my code base is relatively modular this isn’t a ‘difficult’ task, just slightly annoying, all I had to do for this to work in theory was have events from each framework fire off their own event function, then get the relevant actors before sending it to the proper function, wish SexLab just being “hey, this actor has done the thing” and working just like before, but with OStim we have to pull data from the animation thread.

Notice how I said in theory? Yeah, SexLab works as expected with no issues and functions exactly as it did before (actually slightly faster since we don’t have looping code to account for OStim built into the general function anymore), but OStim has a major design flaw that doesn’t affect SexLab. Since OStim doesn’t track actors and only the animation thread, this means when an animation ends and the data clears itself, we can’t pull any data besides the ID for the animation that just ended! SexLab stores this data until it needs to be altered or overwritten, from what I understand it holds this information until the internal cache is filled or a set time has passed, this allows us to reference the animation and pull relevant data even if the animation has ended. OStim on the other hand appears to clear all of its data as part of the end procedure, meaning once the animation has ended and papyrus sends the end event to trigger our code in Succubus Heart, the relevant data has already been cleared, meaning in this example, we can’t get the actors from the animation and run the required code.

This is a pretty big issue and a major oversight by OStim, I do have a work-around however, manual tracking! The issue is I’m not sure it’s worth the performance cost and script weight to implement this for NPC only interactions. For player involved animations I already track the NPCs in the animation for the drain functions so my solution there is if the animation runs through OStim I simply send those NPC references to the proper end animation function (which isn’t required by SexLab) but for NPC animations I would need to create my own tracking system. OStim does have a way to quickly check if an animation includes the player however, which is quite nice! The player animation in OStim always returns with a threadID of 0, so we can use that to quickly check if the player is involved to set up whether we need to process the starting effects or not (skipping these effects/triggers for NPC only animations). I think currently I just won’t have NPC/NPC interactions being tracked, the vast majority of effects still apply such as orgasm so I don’t think most people will really mind all that much, but if it does become an issue we can create a tracking system for NPC animations using the ThreadID as identifiers to hopefully make up for that. (As a note, SexLab will obviously remain fully functional.)