prideslayer Posted May 26, 2014 Author Posted May 26, 2014 You know when I first started the NG project, one of the things I was doing early on was reorganizing the anims and naming them consistently for a day like this. I thought that I could do that back then -- build an anim name at runtime from strings, or put them into a bunch of different formlists and then pick a random entry. After I found I couldn't do either, I started slacking off. Now I can and I'm paying for that slacking.
Loogie Posted May 26, 2014 Posted May 26, 2014 Does this effect the names of any ZaZ stuff? I was experimenting with calling an animation directly so it lasted indefinitely without any of the unfortunate side effects of leaving a cell with Sexout active.
prideslayer Posted May 26, 2014 Author Posted May 26, 2014 I haven't touched zaz yet, so no. At some future point I may, I intend to integrate zaz into sexout (and deprecate the zaz download) in this release, but given what I'm dealing with right now, that may be a bit ambitious.
prideslayer Posted May 31, 2014 Author Posted May 31, 2014 2.6.85b1 in OP Features done, available in the beta, and fully tested: - Release # raised to 85. - NX required version string more descriptive for 'v0'. - New (internal for now) UDFs. - New quest and script to hold new anim related vars. - Upgrade moved out of main quest script and into fnSexoutUpgrade. - Masturbation animations RENUMBERED. 101-110 for males, 111-120 for females. - Updater changed to ensure it gets run whenever going from beta->beta, release->beta, or beta->release - random picker adjusted to include the supermutant oral anim (1430) - Questvar init moved to UDF. - Full animation list array in SexoutNGAQ.animsAll, keyed off of animation #. - Idle animation renaming for consistency. Creature 'a' anims renamed from 'SNG....x' to 'SNG....a'. Some misc renames of things like SexoutNG123a to SNG123a. Sexus old idles renamed from e.g. 'Stage251x' to 'SNG....x'.
prideslayer Posted June 1, 2014 Author Posted June 1, 2014 2.6.85b2 in OP - Added evp's to main effect to force SexoutDoNothing to run. - Sexout beta version now reported in console at startup, if it is a beta.
prideslayer Posted June 1, 2014 Author Posted June 1, 2014 I'm working on addressing the fact that InUse "lies" and am between a bit of a rock and a hard place. I've just cleaned up some unneeded stages in the cleanup effect script (which does the unlock) and there are now 4 post-unlock stages. 30 - Unlocks, removes SexoutDoNothing package, resets sporeplant alerts and bighorner scale, unrestrains actors, redresses, executes CBMoveTo. 100 - Executes callers callbacks (CB* call params). 120 - If there is a CBDialog callback in 100, 120 watches for it to happen, retrying up to 60 times (once per second). 200 - Sexout:Start:: EVs cleared if 100-120 did not create a new act. Global post-sex notification. Dispels self. 1000 - Do nothing, waiting on dispel from 200. The actor has to be unlocked prior to the dialog callbacks happening, because the dialog may be trying to initiate another scene and checking inuse itself. Thus calling InUse repeatedly in a fast loop will cause it to return false (actor available) while the cleanup script is still running stages 100 and up. However, the sanitizer will delay 0.5s and try again if it detects the cleanup spell on an actor, and reports 'NGSAN: ... finishing" in debug mode. It does this indefinitely. I'm not sure how/why it could be flat-out hanging.
Thenryb Posted June 1, 2014 Posted June 1, 2014 Probably a dumb question, but when installing these betas using FOMM (your version), do you need to deactivate prior beta versions or just allow the newest beta to overwrite when prompted? Disregard. Just downloaded latest and it is an esm only.
prideslayer Posted June 1, 2014 Author Posted June 1, 2014 Odessa, when you have time, can you grab the current ESM from git and try it? Send another debug log along if it doesn't work, please, and when it hangs -- save the game and send me the NX csv as well. It is in data\nvse\plugins\extender\saves and will be named the same as the savegame. One odd thing I'm seeing in your last log is that it wasn't cleanup OR the sanitizer aborting. It progressed on to the main effect, and then hung after locking the actor. I'm not sure right now how this can even happen.
DoctaSax Posted June 2, 2014 Posted June 2, 2014 200 - Sexout:Start:: EVs cleared if 100-120 did not create a new act. Global post-sex notification. Dispels self. Doesn't that mean that if a CB dialog creates a new act, some EVs from the old one are still stuck on the actor? I can't see that as desired behavior, really.
prideslayer Posted June 2, 2014 Author Posted June 2, 2014 200 - Sexout:Start:: EVs cleared if 100-120 did not create a new act. Global post-sex notification. Dispels self. Doesn't that mean that if a CB dialog creates a new act, some EVs from the old one are still stuck on the actor? I can't see that as desired behavior, really. It's certainly possible. I'm open to fresh ideas on how to tackle that entire section, order of events, etc. My main concern is simply to not break existing mods that expect things to work a certain way. I'm rethinking the whole thing myself, just need to be really careful I don't introduce any behavioral changes to the interface responses. Obviously EV cleanup and unlock should happen at the same time. The cleanup shouldn't happen until sexout is "actually" done with the actor. The callbacks shouldn't be called until after cleanup, so any acts they initiate are clean. The main concern with doing it that way is that an act with a callback that initiates a second act may get interrupted by a different mod (or hell even itself) between the cleanup and the callbacks actually happening. This is just problematic for dialog callbacks since they can't automatically "retry" the way a scripted callback can, by just looping until InUse becomes false. Sexout has to handle the dialog callback retries itself for all mods using it. I am pretty sure I need to restructure it all as outlined, except for the dialog callback retry loop, which I will put at the very end *after* cleanup. I can't think of another way.
Odessa Posted June 2, 2014 Posted June 2, 2014 I grabbed this version of '85 from gitlab: (removed) Waited around for ~1 minute then started the same scripted sequence as last time, and sex wouldn't start at all: .... fnSAP: WARNING! Caller 10009A95 (0) already has an act prepped, gonna get sideways!Error in script 0e08c33aOperator [ failed to evaluate to a valid result File: Sexout.esm Offset: 0x005A Command: Let....Error in script 0e08c338 .... The full scof is attached, plus the NX .csv. -- Afterwards I restarted FNV and triggered sex with veronica via console (NX method), that worked fine. CSV-is-zipped-because-its-file-type-upload-is-blocked.zip
DoctaSax Posted June 2, 2014 Posted June 2, 2014 It's certainly possible. I'm open to fresh ideas on how to tackle that entire section, order of events, etc. My main concern is simply to not break existing mods that expect things to work a certain way. I'm rethinking the whole thing myself, just need to be really careful I don't introduce any behavioral changes to the interface responses. Obviously EV cleanup and unlock should happen at the same time. The cleanup shouldn't happen until sexout is "actually" done with the actor. The callbacks shouldn't be called until after cleanup, so any acts they initiate are clean. The main concern with doing it that way is that an act with a callback that initiates a second act may get interrupted by a different mod (or hell even itself) between the cleanup and the callbacks actually happening. This is just problematic for dialog callbacks since they can't automatically "retry" the way a scripted callback can, by just looping until InUse becomes false. Sexout has to handle the dialog callback retries itself for all mods using it. I am pretty sure I need to restructure it all as outlined, except for the dialog callback retry loop, which I will put at the very end *after* cleanup. I can't think of another way. For the longest time mods assumed all "Sexout:Start" vars were cleaned on sex start anyway, so I doubt anybody really relies on them sticking around for whatever happens in their CBs. The main thing, I think, is keeping the vars around in some fashion until all possible CBs are done (dialog, spells, packages, items), but also clearing them right away in case the CBs start a new act & you don't want old ones to still be stuck when they do. You may look into using NX_GetEVFLAr & NX_GetEVFOAr to copy vars temporarily and store the resulting stringmaps in an array for the act that's just over, use those for your CBs, and clear the "Start" vars. (It's possible EVFOAr retrieves numbers though, not forms. I've only used it for readouts so wasn't terribly affected by that. Perhaps you could change the nx keys with sv_replace and re-set them. Or copy every key to a temporary ref maybe.)
prideslayer Posted June 2, 2014 Author Posted June 2, 2014 Odessa: Thanks, will investigate later on today (work is busy today). Can you remove the gitlab link please? I don't "publish" it because I do not want people who come in here and just click every goddamn thing and download it to get their hands on it without putting forth at least a *little* effort. Doc: It's not about them expecting them to be there -- it's the fact that the dialog callback may have set them and thus created a new act -- clearing them would be clearing the new act, not the old one. I can't know if the CB is going to start a new act or not, so I can't know if I should clear them *after* the CB or not. Internally the callsort script (this runs before the sanitizer, converts classic and UDF calls to NX) sets a sexout var (sexout:track::actid) on the player that is incremented every time a new act is initiated. The cleanup saves that and then compares it to see if it's changed after the callbacks to determine if it clear the vars or not. Reordering it will remove the need for that.
DoctaSax Posted June 2, 2014 Posted June 2, 2014 I meant clearing all start vars after you've grabbed what you need for CBs in your spell, but before you trigger the actual CBs.
prideslayer Posted June 2, 2014 Author Posted June 2, 2014 I meant clearing all start vars after you've grabbed what you need for CBs in your spell, but before you trigger the actual CBs. My brain is malfunctioning today, gotcha. Clearing them before I do the unlock shouldn't be an issue. It already caches them itself very early on and doesn't read them again. The global post-sex notification hook is the only thing I'm aware of (but I will check) that needs some NX information when it runs, but it uses Sexout:Core, not Sexout:Start -- changed that a long time ago so mods that weren't properly checking inuse didn't clobber the vars that sexout itself needed in order to run cleanly. I was thinking it should look like this, or close: -------------- 20: Waits for knockdown/cum to finish (this stage unchanged). 30: Everything it does now except the unlock. Bighorner rescale, sporeplant alert reset, redress, etc. 40: Clear EVs, unlock actor, issue initial dialog callback (startconversation). 50: Enter dialog callback retry loop (this tries once a second for up to 60 seconds). 100: Dispel self. 1000: Waiting on dispel (doing nothing at all). -------------- My gut tells me there's a race here, because the sanitizer looks for the cleanup spell on all target actors, and waits indefinitely for it to clear before proceeding. It doesn't issue an NGSAN error or anything because the actor is about to become available, so it shouldn't have to wait long. The following chain of events can break things (I think).. 1. moda starts a sexact (Act 1) with a CBDialog and runs. 2. Cleanup unlocks actors, waits on the dialog to complete. 3. While it's waiting, modb starts a sex act (Act 2) on the same actor. 4. The sanitizer for actB is waiting on cleanup to be dispelled. 5. The CBDialog finally occurs and moda starts a new act (Act 3). 6. Act 2 kicks off. 7. Act 3 errors out due to an NGSAN inuse check. Now.. I don't think this is any different from what can happen now, so it may not be important to solve in this fix, but I might be missing something. Ideally 6 & 7 would reverse acts. My preference (and I imagine players and modders) is that the "act chain" from moda should always succeed once started, and not even possibly be interrupted by some other mod. Those interruptions are what cause complicated callback oriented scenes like motor runner in fiends tryout to break in the middle. Unfortunately there's just no way for me to know if a dialog callback has resulted in a new sex act without being told -- meaning the interface would have to change. Sometimes I wonder if I shouldn't just issue a "don't do that" warning and say that sexout simply should not be started from dialog result scripts directly -- cast your own spell instead, so you can keep retrying if it fails.
DoctaSax Posted June 2, 2014 Posted June 2, 2014 Clearing them before I do the unlock shouldn't be an issue. It already caches them itself very early on and doesn't read them again. Yeah, I probably overcomplicated that bit, just a reshuffling of the spell script should be enough. As to the other thing, starting acts from dialog results is as old as sexout, of course, and a lot of mods would need adjusting if that ever became frowned upon. It's important though that we don't get in each other's hair. How about flagging actors as still InUse (perhaps a different value than actually 'in an act') if they're still lined up for or performing CBs, and only allowing the start of a new act under those circumstances if it's the CB that does it? I think you're already tracking the setting mod, so it may be possible to reserve actors to that mod until it's completely done with it, cbs & all.
prideslayer Posted June 2, 2014 Author Posted June 2, 2014 Clearing them before I do the unlock shouldn't be an issue. It already caches them itself very early on and doesn't read them again. Yeah, I probably overcomplicated that bit, just a reshuffling of the spell script should be enough. As to the other thing, starting acts from dialog results is as old as sexout, of course, and a lot of mods would need adjusting if that ever became frowned upon. It's important though that we don't get in each other's hair. How about flagging actors as still InUse (perhaps a different value than actually 'in an act') if they're still lined up for or performing CBs, and only allowing the start of a new act under those circumstances if it's the CB that does it? I think you're already tracking the setting mod, so it may be possible to reserve actors to that mod until it's completely done with it, cbs & all. I'm only tracking the issuer in the UDF interface, via GetCallingScript in prep. I can't do it in cleanup since the caller is sexout itself. I will try grabbing it in the SexoutBegin script -- maybe the CIOS caller will be returned to me there. Might not, no way to know without trying. If that does work then what I can do is have it return true (even when false) if cleanup is still active on the actor, and the caller doesn't match the NX var. Of course even that only applies to stuff using the UDF to check inuse. Everyone is basically still using Var04 or the token, which I can't fake out that way. :/ Oh and small correction.. callbacks are only as old as NG. The original sexout didn't have them, but SI did, and I really missed them.
jaam Posted June 2, 2014 Posted June 2, 2014 To be honest is there really a solution? You need to keep the actor as unavailable while at the time being able to have him/her available. Maybe do something with the actID. ie if the new call uses the same actID then the NPC can be still busy during start?
DoctaSax Posted June 2, 2014 Posted June 2, 2014 I'm only tracking the issuer in the UDF interface, via GetCallingScript in prep. I can't do it in cleanup since the caller is sexout itself. I will try grabbing it in the SexoutBegin script -- maybe the CIOS caller will be returned to me there. Might not, no way to know without trying. If that does work then what I can do is have it return true (even when false) if cleanup is still active on the actor, and the caller doesn't match the NX var. Of course even that only applies to stuff using the UDF to check inuse. Ah yeah, it's the calling script, which IIRC becomes the actID, no? Well, it may already be enough of a safeguard - if a mod's script interrupts its own act's CB's setting a new act by setting another act in between, that'd just be on them. And hey, more security for the UDF interface is a good incentive to change over. Oh and small correction.. callbacks are only as old as NG. Tssk. No need to be correcting what isn't wrong
prideslayer Posted June 2, 2014 Author Posted June 2, 2014 I'm only tracking the issuer in the UDF interface, via GetCallingScript in prep. I can't do it in cleanup since the caller is sexout itself. I will try grabbing it in the SexoutBegin script -- maybe the CIOS caller will be returned to me there. Might not, no way to know without trying. If that does work then what I can do is have it return true (even when false) if cleanup is still active on the actor, and the caller doesn't match the NX var. Of course even that only applies to stuff using the UDF to check inuse. Ah yeah, it's the calling script, which IIRC becomes the actID, no? Well, it may already be enough of a safeguard - if a mod's script interrupts its own act's CB's setting a new act by setting another act in between, that'd just be on them. And hey, more security for the UDF interface is a good incentive to change over. No, the actID is different. That is a simple serial that just increments every time sexout is told to start sex, via any interface. The calling script ID is just used by prep/run to keep multiple mods (or multiple scripts in one mod) from colliding when multiple preps are in motion at once -- I discard it when run is called. Actid is only used in that check we already discussed, so I can determine if I should smoke the EVs or not. As for it being enough of a safeguard.. it was, before the UDF stuff. It's not enough any more. If GetCallingScript doesn't give me what I want in the callsort script, I will have to come up with something else.
nyaalich Posted June 2, 2014 Posted June 2, 2014 Ooh! Ooh! Pick me! How easy is it to get the ActID, and when does it go away? That might make an array thing easier for me. And sorry: What's EV?
prideslayer Posted June 2, 2014 Author Posted June 2, 2014 The actid is an EV on all the actors (or maybe just the spell target? I forget..) stored in Sexout:Start::actid. An EV (extended value) is an NX variable.. as in NX_SetEVFl, etc.
prideslayer Posted June 2, 2014 Author Posted June 2, 2014 Odessa, I'm looking for a "full trace" if you can get me one. My personal procedure for making these.. 1. Get a save that is on it's own working fine. 2. turn on scof 3. turn on sexout debug mode 4. start the initial act. The last debug you sent me had a few successful acts that appeared to be chained followed by the explosion.. I wanted "that" but with the little additional debugging I put in the alpha ESM. This new one starts after the successful acts have already finished. That will of course need a new save at the end, so the NX CSV is up to date with what's "wrong". I can't tell if the CSV you sent is boned or not because all the sexout debugging messages that should match up to it are missing in the scof file since scof started 'late'. That all said, the initial "gonna get sideways" error is an indication that a script called fnSexoutActPrep once, then called it again -- without calling fnSexoutActRun or fnSexoutActReset first. One script calling prep twice in a row without running or clearing the act is a bomb waiting to go off.
prideslayer Posted June 2, 2014 Author Posted June 2, 2014 I'm getting the stage changes in place now and about to test. I just laughed and scratched my head because I made all the changes offline (as normal), copy/pasted into the geck and hit save... and it saved. Usually there are one or two stupid syntax errors. I didn't believe it. hah.
prideslayer Posted June 3, 2014 Author Posted June 3, 2014 2.6.85b3 in OP - Some cleanup effect stage refactoring. - Offsets adjusted (minor) to assume breeze's as default body. I tested the effect staging changes VERY simply. Two 2p acts in a row from the console which worked fine, followed by another 2p act also using an actorx+cbdialogx with a far-off sitting actor to ensure the dialog stuff was still working. All worked ok. Going on now to investigate using GetCallingScript as discussed.
Recommended Posts