kevlar69 Posted May 27, 2013 Posted May 27, 2013 What is the scope for the registerForModEvent() ? I assume it is the script itself, but I have had some wierd results. I have two separate scripts registering for a custom hook from sexLab. Most of the time, both of these receive the events, but then one may stop in subsequent trials. Both scripts inherit Quest, auto startup. Any ideas? Also, on occassion, the startSex() ends with the player stuck in an animation, while partners get dressed and go about their business. Is this a known bug? Thanks.
Ashal Posted May 27, 2013 Posted May 27, 2013 What is the scope for the registerForModEvent() ? I assume it is the script itself, but I have had some wierd results. I have two separate scripts registering for a custom hook from sexLab. Most of the time, both of these receive the events, but then one may stop in subsequent trials. Both scripts inherit Quest, auto startup. Any ideas? Also, on occassion, the startSex() ends with the player stuck in an animation, while partners get dressed and go about their business. Is this a known bug? Thanks. Mod events are global, not localized in anyway, which is why it's important to not use the global versions of the hook events if your function is specific to your mods startsex() call. I haven't seen or heard of player getting stuck, are you using the newest version, 1.01, with a proper clean install? And are you using ragdoll end or not.
kevlar69 Posted May 27, 2013 Author Posted May 27, 2013 What is the scope for the registerForModEvent() ? I assume it is the script itself, but I have had some wierd results. I have two separate scripts registering for a custom hook from sexLab. Most of the time, both of these receive the events, but then one may stop in subsequent trials. Both scripts inherit Quest, auto startup. Any ideas? Also, on occassion, the startSex() ends with the player stuck in an animation, while partners get dressed and go about their business. Is this a known bug? Thanks. Mod events are global, not localized in anyway, which is why it's important to not use the global versions of the hook events if your function is specific to your mods startsex() call. I haven't seen or heard of player getting stuck, are you using the newest version, 1.01, with a proper clean install? And are you using ragdoll end or not. What I meant by 'scope' is for the receiver of the event, and I assume it is local to a script, meaning: unregisterForAllModEvents() in a script would remove the event handler for that script only. Not any other scripts attached to the same quest / actor / whatever. all scripts that call registerForModEvent() will receive the event, and no script can interfere with another's receiving of that event. I am using a custom hook events. My sexQueue script uses: int result = SexLab.StartSex(sexActors, animations, victim, hook="sexQueue") And my sexOutcomeResource script has: ; Get events directly from sexLab, to process results ; Use single handler to ensure events are processed in the correct order function registerForEvents() Utility.wait(2) questScr.logMe(self, "RegisterForModEvent()...") ;UnregisterForAllModEvents() RegisterForModEvent("AnimationStart_sexQueue", "outcomeEventHandler") RegisterForModEvent("AnimationEnd_sexQueue", "outcomeEventHandler") RegisterForModEvent("OrgasmEnd_sexQueue", "outcomeEventHandler") RegisterForModEvent("StageStart_sexQueue", "outcomeEventHandler") RegisterForModEvent("StageEnd_sexQueue", "outcomeEventHandler") endFunction And my stats. storage class has this: ; Get events directly from sexLab, to update stats. function registerForEvents() ; WARNING. Tests show this at times this is NOT run....WHY? wait. seems to help. Utility.wait(2) questScr.logMe(self, "RegisterForModEvent()...") ;UnregisterForAllModEvents() RegisterForModEvent("AnimationStart_sexQueue", "boo") ; debug RegisterForModEvent("AnimationEnd_sexQueue", "animationEnd") endFunction 95% of the time everything works. The sexOutComeResource script has never failed to receive the events. But the stats storage class sometimes receives, sometimes doesn't (both attached to single quest). When I wrapped up for the night yesterday, it was consistently failing, and I sort of reached my wit's end. I had hoped that someone had experienced something similar and had an idea I did not consider. While I am on the subject: do registerForModEvents() calls survive after a load game? do registerForModEvents() stack, or do subsequent calls 'override' the first call? (ie. events not received by the same script twice) For safety I was always unregistering and re-registering for all events on every init(), game load, and after a set of all events had been received by a script. But now I am not so sure. I haven't seen or heard of player getting stuck, are you using the newest version, 1.01, with a proper clean install? And are you using ragdoll end or not. Newest version, ragdoll end. All settings at default, all from a new game with the newest version of sexLab. If I recall correctly, it seems to happen more frequently for an 'aggressive' animation. EDIT: The player remains in the animation at the end if you hit the space bar a few times prior to the animation starting, but after the startSex() call. EDIT: For the registerForModEvents() problem. I think I have found either a bug or something undocumented with regards to that method. registerForModEvents() may fail from different scripts depending on which registers for the event first. I find the behavior reproducible, and when it works, the registerForModEvent() calls match the order that the scripts are attached to the quest in the CK.
kevlar69 Posted May 29, 2013 Author Posted May 29, 2013 Solved. registerForModEvent() calls are registered for the form, not the script. So if mulitple scripts are attached to the same quest, they may not both reliably receive all event notifications. EDIT. CORRECTION: the error in this case was on my part, as I was mistakenly calling registerForModEvent() from both scripts, with *different* callbackName values. As the method is for the form, not the script, whichever script used registerForModEvent() last would have it's event called, rather than the other.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.