Atomicity (in Sexout)

[sen4mi]

I am trying to understand how data integrity works in sexout.

 

Currently, I see a lot of moving parts, and it seems to me that save/load can break some of the assumptions about how these parts are being used.

 

And it does not help that load (new game) and load (in existing game) seem to not be the same thing.

 

So, I am simultaneously trying to:

 

1. Understand how things work,

2. Invent best practices for me [when I play]

3. Invent best practices for coding [which I hope to be doing before too long]

 

...and knowing how everyone else views these topics would help me.

 

If anyone has any clues about this issue, please help me understand.

 

[Guest Loogie]

This doesn't address your questions directly, but it is a good piece of advice: when playing anything that runs on this engine, whether it be Oblivion, Fallout or Skyrim, always quit your game and restart if you want to load a save for a different playthrough. I've noticed in heavily modded games, loading saves of a character you aren't on tends to glitch vanilla gampeplay; also things like MCM go haywire.

 

As for coding, the game seems fairly robust as far as saving information. Tryouts add a lot of scripts that increase counts to keep track of various things (slavery freedom, when to get perks, etc) and I have never seen an instance of the game losing that information unless it's the result of a clean save.

[sen4mi]

As for coding' date=' the game seems fairly robust as far as saving information. Tryouts add a lot of scripts that increase counts to keep track of various things (slavery freedom, when to get perks, etc) and I have never seen an instance of the game losing that information unless it's the result of a clean save.

[/quote']

 

Ok... but... for example, if I save in the middle of a sexout animation, I should expect that that's ok?

 

One problem, here, is that I do not know, when making my saves, if I am in the middle of a sexout animation, or in the middle of some other sequence of events.

 

SexoutBrutalRapers can be a significant reason for this. On its default settings, things can get crazy if you run away. I have frequencies turned way way down now, after doing a clean save on it, but that's not a complete solution.

[Guest Loogie]

Ok... but... for example' date=' if I save in the middle of a sexout animation, I should expect that that's ok?[/quote']

 

Every time I've done that and loaded the save, the animation is going midway and completes normally. Even did it with an ongoing rape from regular rapers after I had gotten rid of rapers. Also, when testing Cook-Cook and saving and reloading in the middle of sex acts, his callbacks worked just fine.

 

One problem, here, is that I do not know, when making my saves, if I am in the middle of a sexout animation, or in the middle of some other sequence of events.

 

I wouldn't save in the middle of vanilla game events with really complicated scripting, like President Kimball's speech, but it should generally be okay.

 

SexoutBrutalRapers can be a significant reason for this. On its default settings, things can get crazy if you run away. I have frequencies turned way way down now, after doing a clean save on it, but that's not a complete solution.

 

I don't understand exactly what you mean. For what it's worth, I don't use stalkers and only use BrutalRapers for combat rape because there's too much of a chance it could interrupt Sexout callbacks, which Tryouts use a lot of.

 

[sen4mi]

I don't use stalkers and only use BrutalRapers for combat rape because there's too much of a chance it could interrupt Sexout callbacks' date=' which Tryouts use a lot of.

 

[/quote']

 

I should probably just turn stalkers off and leave it off, then, if it's breaking things.

 

Maybe I'll someday re-write it to my tastes and, in the process, keep it from breaking things. (In my opinion, it should only take effect when large chunks of time are passing, which means sleep, wait, fast travel and idle times long enough to trigger vanity camera. It would also be better if it mostly limited itself to rapers that had reasons to be fixating on you. Some of the turn down lines in hookups (back when I had that running) seemed like they should be enquing something in a list that gets used by stalkers.)

[Guest Loogie]

I think what Brutal Rapers would need is some command that looks to see if a callback has been issue and, if so, suppress stalkers for a few minutes or something.

[prideslayer]

There is no atomicity in sexout because none is available within the engine itself. It's a problem I am hoping to address within the NVSE plugin.

 

By default, the games script interpreter runs single threaded. Every frame, it evaluates which scripts need to run based on their frequency and triggers, and then runs them sequentially in an unpredictable order that is probably a combination of load order, quest delay (for quest scripts), ref ID, and who knows what other random factors.

 

All scripts are procedural in nature. All functions block execution. Any function that takes longer than the time allocated to the script will cause the script to exit, and start over at the top the next time it is scheduled to run. Spell casting, which is the closest we have to a function call, is NOT a function call -- the start of the spell being cast will be delayed at least until the next frame, and the function call (CIOS) returns instantly.

 

There is no way with any of the currently available parts of the system to ensure any sort of data integrity. The main concern here is in systems using quest variables as function parameters, such as SexoutNG.actorA as a 'parameter' to SexoutBegin.

 

The best that can be done here is for individual mods to check actorA BEFORE they set it, and if it is nonzero, delay setting it and making their SexoutBegin call until it becomes zero. That is, at least until I have some kind of "real" locking in sexout itself, or (better yet) a system that does not require locking. I am working on ideas in both veins.

[sen4mi]

The best that can be done here is for individual mods to check actorA BEFORE they set it' date=' and if it is nonzero, delay setting it and making their SexoutBegin call until it becomes zero.

[/quote']

 

Ok! that is good to know.

 

 

And, for the general concepts, if I understand you correctly:

 

A single script within a single frame is "usually but not always" atomic. And, since quest data is not private, quest structures composed of multiple quest variables cannot be atomic. Also, anything that involves items and actors cannot be atomic.

 

Do you have any feel for how much processing can happen before a frame fails?

 

 

[prideslayer]

A single script is always atomic(*). There is only one script VM running in the game engine by default. Scripts are run sequentially (in an unpredictable order). There are two things that are not "atomic."

 

1. Casting a spell. The CIOS / CastInstantOnSelf function call *schedules* that spell to be run, but due to the paragraph above, the script for that spell does not actually start or run until the current script (and perhaps others already scheduled this frame) run.

 

2. Anything involving the 3D engine. Moveto and other commands that cause changes in the viewport *may* not happen instantly, depends entirely on the speed of the PC involved and its load. It's best to put any commands like that at the end of a stage in the script and just count on NOT running anything else in that script until the following frame.

 

(*)You can hack on your config and multithread the games scripting engine. This can increase performance overall, but it can also introduce problems due to this lack of locking, which is probably why it's single threaded by default. Sexout copies the NG variables into the script and then zeros them out when it first starts, but it then copies some calculated variables BACK to the quest script and calls other spells, and it *counts on* the next spell picking up those calculated vars before another sexout spell casting zeroes them out. This is pretty reliable when single threaded, but rather dangerous when multithreaded.