The Sexoutng Api (How-To For Modders)

[Halstrom]

Hmm just a quick question I couldn't find a clear answer to, is Sexout only supposed to animate one sex act at a time?

I noticed Sexout not working when I called masturbation on actors if another actor was already masturbating.

Of course it's possible I've just screwed up in my noobness at calling sex to occur

 

I have this in a effect added to an actor:

			if rZActor.GetItemCount 00SexoutActor < 1; *** && rZActor != PlayerREF
				rZActor.NX_SetEVFl "Sexout:Start::CallVer" 1
				rZActor.NX_SetEVFo "Sexout:Start::ActorA" rZActor
				rZActor.NX_SetEVFl "Sexout:Start::bDontUndressA" 1
				rZActor.NX_SetEVFl "Sexout:Start::anim" 101
				if GetRandomPercent > 35
					rZActor.NX_SetEVFl "Sexout:Start::anim" 105
				endif
				if GetRandomPercent > 65
					rZActor.NX_SetEVFl "Sexout:Start::anim" 106
				endif
				rZActor.NX_SetEVFl "Sexout:Start::duration" 30
				rZActor.CIOS SexoutBegin
			endif

[prideslayer]

Sexout can run an unlimited (within limits of the game engine & PC) number of animations at once, of any type, on any number of actors.

 

The main thing that prevents that from working is when you try to CIOS the same actor twice in the same run. I can't tell in your code snippet if that's in a loop of some kind or not, or what rzactor is set to, but CIOS is basically an asynchronous function call that doesn't actually get executed until the current script has returned. Using it twice on the same ref in a loop, or simply before Sexout has had time to pick up the first call, may result in an actual call stack that ends up being run as if you'd written this:

 

ref.NX_SetEVFl "Sexout:Start::CallVer" 1
ref.NX_SetEVFl "Sexout:Start::CallVer" 1
ref.NX_SetEVFo "Sexout:Start::ActorA" refA
ref.NX_SetEVFo "Sexout:Start::ActorA" refB
; ...
ref.CIOS SexoutBegin
ref.CIOS SexoutBegin

Looking at it that way you can see why it won't work.

 

Using explicit refs, it does work -- that is how I test. So that tells me that your rZActor is, somehow, the same value several times in a row. For example, a script like this with no timing breaks or returns works fine.

 

refSunny.NX_SetEVFl "Sexout:Start::CallVer" 1
refSunny.NX_SetEVFo "Sexout:Start::ActorA" refSunny
refSunny.CIOS SexoutBegin

refCass.NX_SetEVFl "Sexout:Start::CallVer" 1
refCass.NX_SetEVFo "Sexout:Start::ActorA" refCass
refCass.CIOS SexoutBegin

playerRef.NX_SetEVFl "Sexout:Start::CallVer" 1
playerRef.NX_SetEVFo "Sexout:Start::ActorA" playerRef
playerRef.CIOS SexoutBegin

[Odessa]

 

 With the returns, I mean for instance stages 700 & 701 seem to flow into each other during the same script iteration, but casting the same spell on different actors in the same frame can sometimes mess things up, and I think that's probably especially true with NGBegin.

 

 

I think you misread the script, its a bit long to make sense of. Its like this:

 

 

if iStage == 0
    set iStage to 695
 
elseif iStage == 700
    set iStage to 701
 
elseif iStage == 701
    ...
else
    let iStage += 1
endif

 

 

Two stages can't run during the same script iteration, but some will be in the next one, which will be 1-second later (quest script). I wrote it this way to avoid that very issue with same frame spells.

 

------

 

 

What does sexout check before giving a 5.2 or a 6.2 error? (so I can check it myself first)

 

I seem to remember reading once upon a time that sexout animations (sex positions) could be changed midway but the actors stopped and stood up in between them, which is why this functionality was unused, but that isn't an issue for me here. Is there a specific call available for this?

[Halstrom]

Hmm, yeah looking at it that's possibly the case that the token isn't there before it repeats, I do have the main of the script only running every 100th scan, but that might still be too quick. well now I know I'm just doing something wrong, I'll look into it deeper

 

It's also possible more than one of the actors with the effect are starting masturbation at the same time, I'll have to look into a way of blocking that possibility.

[nyaalich]

Probably not the correct thread, but...

 

What bearing does the bActor[#]male value have on anything?  If I don't set it, is it supposed to return 0?  I haven't looked at it finely to determine when it's returning what because I've been focused on getting the script working as a whole, but I've noticed that it's occasionally returning 0 for a guy.  I don't know if other mods use it for anything.

 

Part of my script randomizes it so that if females are allowed to use strap-ons on guys, there is an equal chance that either one of them could be Actor A.

 

Vaguely related question:  There are a shit-ton of sex toys in the game.  However, the toy animations look like they all use rather painful looking predefined wasteland objects.  Are the vibrators and dildos (We have to use the indefinite article a dildo, never your dildo. /quote) are only used in masturbation?

[jaam]

You must not set them.

Those variable are filled by sexout during the analysis of the sex act.

 

[nyaalich]

Okay.  Well that's good.  Is there any reason to be concerned that a male is being marked as female in that variable?

[prideslayer]

Okay.  Well that's good.  Is there any reason to be concerned that a male is being marked as female in that variable?

It's intentional if it happens. The opposite of a woman wearing a strapon, whatever the hell that might be.

[DoctaSax]

 

With the returns, I mean for instance stages 700 & 701 seem to flow into each other during the same script iteration, but casting the same spell on different actors in the same frame can sometimes mess things up, and I think that's probably especially true with NGBegin.

 

I think you misread the script, its a bit long to make sense of. Its like this:

 

 

if iStage == 0
    set iStage to 695
 
elseif iStage == 700
    set iStage to 701
 
elseif iStage == 701
    ...
else
    let iStage += 1
endif

 

Two stages can't run during the same script iteration, but some will be in the next one, which will be 1-second later (quest script). I wrote it this way to avoid that very issue with same frame spells.

 

I'm pretty sure that if you set istage to 701 in stage 700, and 701 directly follows 700, the both of them will be processed in the same script iteration if you don't hit a return in between. Same for 800 & 801. Whether cios'ing NGbegin twice in the same frame is the source of your problem however, I don't know, it's just something I'd be leery of doing.

Overall, that script's getting to be longish, and your catch-all "let iStage += 1" is at the very end, so maybe once in a while it doesn't reach there - although I've seen heavier stuff. Still for something so essential to the proper operation of things I'd stick it up top, or export some of those calls to a UDF.

[prideslayer]

That should not happen doc. There's an implicit return. A code chunk like this:

 

if val == 1
  set val to 2
; ...
elseif val == 2
  set val to 3
; ...
elseif val == 3
  set val to 4
; ...
else
; ...
endif

Is not going to execute the if statement over and over repeatedly in one frame. It'll run just the section it's supposed to and then bail. If you use it with a bunch of if's rather than elseif's then it will run them all in order if they're in the order they're being set.

 

This is why sexout's stages are descending in the script in most cases, while the actual stage value is ascending.

[DoctaSax]

That should not happen doc. There's an implicit return.

 

Ashes on my head it is.

[prideslayer]

What does that mean I don't even.

[Halstrom]

Is it possible to have a flag or is there a flag in Sexout that is set when ever it receives a new animation request and resets when it's ready for another so that mods can check before calling another animation request, to help alleviate any mods calling animations nearly or simultaneously. I could set a global or NX in my mod to prevent it calling multiple animations to close together but that wouldn't stop something like Lust calling at the same time.

[prideslayer]

Sexout:Start::spellTarget is set on every actor involved in a scene, and lasts until sexout is done with them. Being an NX var, this isn't like the CIOS or adding a token -- when you set an NX var on a ref, it's instantly available to be read back by your script or any other. Sexout sets that value as soon as the CIOS script starts running which is in the same frame the CIOS was actually called, or the following frame.

 

That is as quickly as sexout can set anything -- as soon as the CIOS happens. There is nothing I can do before then.

 

To truly avoid the very small window where sex acts can interrupt one another, mods have to cooperate with each other. They can do this by setting that var themselves on all involved actors, but checking for it first. They can do this regardless of their sexout calls otherwise using NX or not -- meaning setting that var will work fine even if you use the quest approach, though nobody should be using that any more.

 

If everyone did that then the final window that remains is one where you check those NX values, see they are empty, and proceed -- and later on in the same frame, a previous sexout CIOS from a mod that did not check takes effect.

 

There's simply nothing I can do within sexout itself to completely solve this. I can only set values myself in fast-running quest scripts or in the spell effect scripts, and both of those have windows of opportunity for things to go wrong.

[prideslayer]

Oh alternatively Hal, if you and everyone else want to agree on a flag in the NX vars thread, you can make up one of your own and just set it on the player -- to use as an overall 'block' on using sexout at all.

 

Check it. If it's 0, set it, then proceed. If y'all agree on one, I'll update the beta to set it back to zero as soon as sexout has control, but y'all will have to be the ones to check it's current value -- it would be meaningless for sexout itself to look at it.

 

Note that if you do this, it opens a door where a mod can break sexout for everyone using the system if the game is saved after that var is set, but before the sexout CIOS has happened. It's a tiny window, but it's there. If that happens and the mod that was going to CIOS is disabled by the user and then the save is loaded, the var will remain set, but the CIOS will never happen and thus sexout will never unset it.

[DoctaSax]

Might be worthwhile to look into a way of setting nx vars only for as long as the mod setting it is loaded.

 

As to the other thing, it's the same as with the formlists in scr and the NotNow and IsReserved variables - they only really work if we agree on them, modders adhere to them, and there aren't so many we don't know what's what anymore. I believe Lust now checks all of that before it does any of its auto-approach things, so like pride says, the window for fuck-ups is really rather small. And part of me is rather wary of a global 'block sexout' var that would stick in a save whether the mod's still loaded or not - just another thing to check as part of troubleshooting "sexout doesn't work for me" threads. Of course, it's the same for other such vars - mods will eventually each need their own pre-uninstall code to get rid of such vars they set.

[zippy57]

If the variable was a string variable and the mod set it to its own name could Sexout, on game load/restart, use that string to run an IsModLoaded and clear it if the mod has been removed?

[prideslayer]

I thought of those ideas (special NX vars and/or sexout checking IsModLoaded) and even of adding a lock function to NX. All of them are inadequate though, there's really no way to do this that doesn't involve the mods cooperating by agreeing on a sort of mutex and then using it. NX var setting is atomic and instant so it can be used for that rather than tokens or something, and while a quest var would work I don't want to add any more and it would have to be in sexout to get universal coverage.

 

If sexout could somehow know which mod initiated the act, then it could cancel any in-progress acts started by that mod if it sees the mod is missing -- which would by definition cause that var to get cleared as well. I don't know of any way for this to happen right now though.

 

What I do see is that sexout needs some kind of persistent ref added to it that is used strictly for mods to use for NX vars. Using the player works ok most of the time, but NX is smart enough to clear any vars on a ref if the mod that owns the ref is missing then the savefile is loaded. That obviously doesn't work with vars set on the player, since the player ref doesn't become invalid on a game load.

[Loogie]

Okay.  Well that's good.  Is there any reason to be concerned that a male is being marked as female in that variable?

 

ActorA does the poking and ActorB takes the poking. Sexout doesn't get hung up on gender.

[nyaalich]

My concern was just for Preg (which I would imagine takes a whole hell of a lot of other wrong variables to get a male pregnant) and possibly anything else that would be reading the var.

[prideslayer]

My concern was just for Preg (which I would imagine takes a whole hell of a lot of other wrong variables to get a male pregnant) and possibly anything else that would be reading the var.

Nothing except sexout should be reading those vars. Mods that do and don't understand what they're for will soon learn the error of their ways.

[Halstrom]

From memory Preg has checks that self-remove the Fertility & Pregnancy tokens if the wearer fails a GetIsSex Female check, maybe I shouldn't but there's no Male pregnancy bodies anyway and no call for it.

[nyaalich]

@Hal:  Okay, well all I'm saying is that it's not my fault if StrapOn 03 isn't shooting blanks.     Currently, mine is set to only allow humans and ghouls, but that didn't stop a mystery egg to happen earlier when testing creatures.  /different issue for a different thread

 

@Pride:  I'm setting 3some animations (NX Sexout:Start:AnimA #) in the mod that I'm working on (i.e., have worked on this whole goddamned weekend because it's being a little bitch).  I know that sexout spins actors (whee!), but unless it's the animations where the people are all piled on top of one another, everyone's just doing his/her own thing.  Is there other stuff that's supposed to go on and/or is being bypassed because I'm setting the anim as opposed to letting the Randomizer select it?

[prideslayer]

You need to set all the anim #s I believe so animA, animB and animC.

[nyaalich]

Animations:

 

103 looks like it's F Oral Receiving instead of masturbation.

 

121:  Is this supposed to be a 2 people masturbating at the same time?  There's 2 anim files.