prideslayer Posted June 9, 2014 Author Posted June 9, 2014 Argh, thanks Odessa. Will try to look it over after work today. Another weekend spent wrenching left me with no time to work on SO. Buddy showed up on Friday at about 430pm to change water pump and oil pan. On Friday we rented a trailer and I towed his truck home with both driveshafts, transmission, and transfer case in the bed of his truck. We did get the new waterpump and oil pan in though!
prideslayer Posted June 13, 2014 Author Posted June 13, 2014 Using '85b5, I am still getting the actor freeze if I don't delay once after fnSexoutActorInUse returns false. Have not reproduced the CTD yet, apologies for delay. I looked over your last log, the one in this file from 85b5, and it looks like everyone was properly cleaned up this time. I did notice some spunk script errors throughout but I don't think spunk could prevent sexout from proceeding properly. Going to remove some of the spammy logging and add the return val for inuse to the logging, not sure why I forgot that one.
prideslayer Posted June 13, 2014 Author Posted June 13, 2014 Actually I did add it there already, just didn't notice. The actor is definitely being unlocked at the right time.. unless something is resetting the inuse flag somehow things should have proceeded normally. Will clean up the logging and post up beta6, should have time for more testing tonight to see if I can duplicate. Does the test esp you sent me cause this problem now? It didn't the last time I tried.
prideslayer Posted June 13, 2014 Author Posted June 13, 2014 2.6.85b6 in OP - Reduced logging output vs beta5. - Removed broken creature scan stuff (thanks tomm434). - (Also remembered to fnvedit version string to match this time).
jaam Posted June 17, 2014 Posted June 17, 2014 ; Get all actors if ar_HasKey SexoutNG.preppedActs[iCaller] "actorA" let actorA := SexoutNG.preppedActs[iCaller]["actorA"] endif if ar_HasKey SexoutNG.preppedActs[iCaller] "actorB" let actorA := SexoutNG.preppedActs[iCaller]["actorB"] endif if ar_HasKey SexoutNG.preppedActs[iCaller] "actorC" let actorA := SexoutNG.preppedActs[iCaller]["actorC"] endif I don't think this is what you expected to do: The three lines set actorA, rather than going through A, B and C. (already present in B5 ) EDIT: taken from fnSexoutActRun
prideslayer Posted June 17, 2014 Author Posted June 17, 2014 Oh sweet jesus. Copypaste ruins my day again!
Odessa Posted June 17, 2014 Posted June 17, 2014 I think this is an '85b6 new issue. When trying to start a ZAZ anim via the UDF method, the sounds play and controls disable, but the player just stands around (not frozen). My UDF code in the script is: call tsolUnequip rBoxGirl, "Gag" ; * contains no sexout UDF calls call tsolUnequip rBoxGirl, "Buttplug" ; * "" call fnSexoutActPrep call fnSexoutActSetInt "nUseZAZ", True call fnSexoutActSetRef "ActorA", rBoxGirl call fnSexoutActSetInt "Duration", 240 call fnSexoutActSetInt "Anim", 1021 call fnSexoutActSetInt "IsAnal", True call fnSexoutActSetInt "IsVaginal", True ;call fnSexoutActSetInt "bDoKOCons", False if rBoxGirl == SexoutSolGerdaREF call fnSexoutActSetInt "bDontUndressA", True endif call fnSexoutActRun In game, after ~15 seconds I then console cast finish now on my character. I then console started the identical anim via the old NX call method, copying the sexout debug info and this time it worked correctly. Scof log attached. EDIT: Forgot to include- this is consistently reproducible, at least for that save.
prideslayer Posted June 17, 2014 Author Posted June 17, 2014 2.6.85b7 in OP - Fixed bug in fnSexoutActRun (Thanks jaam!)
prideslayer Posted June 17, 2014 Author Posted June 17, 2014 Thanks Odessa. Can you see if beta7 fixes it? That screwup jaam caught probably had a lot of bad side effects.
Odessa Posted June 19, 2014 Posted June 19, 2014 Does not fix, also tried on a different save for no change. UDF method does not play anim, but still does associated sounds/tfc, whilst the old NX method via console works as expected. EDIT: added my test plugin that runs the call once, after a 5 second delay, if thats useful. The test plugin fails with '85b7 and '85b4. However, it functions correctly with the current stable version. (Other versions not tested). Side note: the debug print for the current stable ('84) calls it version '85. I redownloaded it when I tested it. The script is: scn SexoutZAZTestScript int iRuns ref rBoxGirl Begin GameMode if iRuns < 1 let iRuns := 1 return endif if iRuns == 99 return endif MessageEx "Making ZAZ Call Now" let rBoxGirl := PlayerREF call fnSexoutActPrep call fnSexoutActSetInt "nUseZAZ", 1 call fnSexoutActSetRef "ActorA", rBoxGirl call fnSexoutActSetInt "Duration", 240 call fnSexoutActSetInt "Anim", 1021 call fnSexoutActSetInt "IsAnal", 1 call fnSexoutActSetInt "IsVaginal", 1 call fnSexoutActRun let iRuns := 99 End odessa-zaz-test.esp
prideslayer Posted June 19, 2014 Author Posted June 19, 2014 Hmmm that's odd. Thanks, will try to dig deeper today. You said 85b6 and/or 85b5 worked? That will help narrow it down thanks to the power of git diffs.
Odessa Posted June 19, 2014 Posted June 19, 2014 No, for that test plugin: Success: 84 (the stable download) 85b3 Failure: 85b7 85b4 (85b6: for a near-identical test) No other versions tested. (Updated: I had 85b3 archived, it works with that, but not 84b4 (retested))
prideslayer Posted June 19, 2014 Author Posted June 19, 2014 Thanks a ton. I'll look at the diffs between b3 and b4 this afternoon/evening.
prideslayer Posted June 19, 2014 Author Posted June 19, 2014 hmmm beta4 is where I introduced all the changes to the staging I dicussed a few pages back.. Controls disabled, tfc going, sounds playing, but no animation.. that's usually a sign that the anim is missing. Not the case here, but maybe the tokens didn't get handed out, or pickidle didn't get called quck enough before the tfc switch. You didn't happen to look in inventory during the bugged scene did you?
prideslayer Posted June 19, 2014 Author Posted June 19, 2014 Something I'm really having trouble understanding is that the main effect stages seem to progress MUCH faster when sex is started via the UDF vs the SexoutBegin spell. There is no real difference between the two; the UDF (fnSexoutActRun) just sets the NX vars as you would manually, and then casts the spell for you. There's no reason I can fathom that doing it this way should result in the entire sanitizer, randomizer, and main effect script stages running at turbo speed. But it seems that they are -- in your freeze test ESP I'm seeing sometimes invisible chars (happens when TFC delay is too short), chars that don't move (same thing but for moveto rather than tfc), etc. Tracking down the source of that problem might help resolve this or at least shed some light on it. The new UDF also does the locking before casting the spell (rather than letting the spell do it), but that shouldn't matter.
Guest tomm434 Posted June 19, 2014 Posted June 19, 2014 Something I'm really having trouble understanding is that the main effect stages seem to progress MUCH faster when sex is started via the UDF vs the SexoutBegin spell. There is no real difference between the two; the UDF (fnSexoutActRun) just sets the NX vars as you would manually, and then casts the spell for you. There's no reason I can fathom that doing it this way should result in the entire sanitizer, randomizer, and main effect script stages running at turbo speed. But it seems that they are -- in your freeze test ESP I'm seeing sometimes invisible chars (happens when TFC delay is too short), chars that don't move (same thing but for moveto rather than tfc), etc. Tracking down the source of that problem might help resolve this or at least shed some light on it. The new UDF also does the locking before casting the spell (rather than letting the spell do it), but that shouldn't matter. So, have you read the discussion in 101 thread about UDFs that they completely stop the game(and other scripts) while being executed?(at least that happens in my game)
prideslayer Posted June 19, 2014 Author Posted June 19, 2014 Yeah I did, but I don't think it has anything to do with this. This UDF is really simple and is over quickly. Just gets some strings from a stringmap, uses them to set NX vars, casts a spell, and it's done.
Guest tomm434 Posted June 19, 2014 Posted June 19, 2014 Yeah I did, but I don't think it has anything to do with this. This UDF is really simple and is over quickly. Just gets some strings from a stringmap, uses them to set NX vars, casts a spell, and it's done. So, UDF only set variables ? You don't actually rewrite code for UDFs?
prideslayer Posted June 19, 2014 Author Posted June 19, 2014 I'm not sure what you're asking. Rewrite code? This is the script, it's dead simple, and runs quickly. http://git.loverslab.com/prideslayer/sexout/blob/master/scripts/fnSexoutActRun.scn
prideslayer Posted June 19, 2014 Author Posted June 19, 2014 Odessa, a non-release beta8 esm is in the gitlab if you want to try it. I don't think it'll fix anything for you but I put it up just in case. I'm still trying to get to the bottom of the timing issue.
Guest tomm434 Posted June 20, 2014 Posted June 20, 2014 I'm not sure what you're asking. Rewrite code? This is the script, it's dead simple, and runs quickly. http://git.loverslab.com/prideslayer/sexout/blob/master/scripts/fnSexoutActRun.scn I mean that now Sexout is based on spells. not on UDFs. But you already answered my question.
prideslayer Posted June 21, 2014 Author Posted June 21, 2014 2.6.85b8 in OP - Some undress stuff moved to a UDF (formlist checks). - Added missing undress list check. - Moved unlock out of cleanup and back to main script effect. - Main effect now waits on cleanup to finish. - InUse UDF only returns 0 or 1 now - New validity UDF: fnSexoutActorValid. Returns 1 if valid, < 0 if invalid (-4 child, -3 dead, -2 not actor, -1 not ref) Odessa, this one worked fine with the freeze test with two caveats that are actually issues in the test and might be issues in your code as well.. 1. There needs to be a delay between when you move the actors to the player and start calling sexout. This is why sometimes there is an invisible actor in the first act. 2. Between calls unused actors sometimes wander off. If they wander out of the cell, then the freeze occurs. I witnessed this testing outside the saloon when sunny went back inside and then the test tried to use her in the following act. I should probably address #2 myself by throwing an error if the actors aren't all in the same cell. I'll add this to the sanitizer.
prideslayer Posted June 21, 2014 Author Posted June 21, 2014 I have a change in my local copy that will cause NGSAN to error out with 12.0 if all the actors given to an act are not in the same cell. This will stop the freezetest from continuing, but eliminates the freeze itself.
DoctaSax Posted June 21, 2014 Posted June 21, 2014 Bit of a caveat for modders using the InUse UDF: simply replacing the old var04 mask or token count with it may lead you to have that udf call in a rather complex if-line that can bug out on you. This is what went wrong with the Lust 6.66 update, nesting instead fixed that. Ain't nothing wrong with a little nesting, folks. I still have an outstanding issue there with inuse possibly not returning true if masturbating though. (Not sure about the NG versions, relying on other people's feedback.)
prideslayer Posted June 21, 2014 Author Posted June 21, 2014 That eval thing is a real PITA at times. I wonder why it's needed.. but not enough to go digging around in NVSE, plenty of other fish to fry right now Inuse should always return true as long as the ref given to it is valid -- unless the masturbating actor isn't getting locked, which I don't think is possible if the animation actually plays.
Recommended Posts