digitalpartisan Posted December 7, 2017 Share Posted December 7, 2017 Ah ha! I've used the wrong word entirely. The word I was looking for was Persistence. And whatever else wait() behaviors do, they also force the engine to unnecessarily persist an object that uses them. Link to comment Share on other sites More sharing options...
SKKmods Posted December 7, 2017 Share Posted December 7, 2017 Oh Ho ! good point, but if the Ref is associated with an active quest through an alias (like the OP's author & book) it will be persistent until cleared anyway, no ? The workaround for that I have been trying to profile is to generate everything in script (rather than quest fill functions) and hold Refs in script arrays rather than quest reference aliases, so even though the quest is running the ref *may* unload when the script unloads. I say may as there is no hard evidence this actually happens except oblique suggestions like "When any variable in a currently loaded script points at a reference ..." Then SMB92 found that scripts have a stack limit of 4096 bits for variables, so standby to shard those monolithic scripts. PS to be clear I totally agree that counters and timers are better than waits, and apologies to Yulliah for hijacking the thread. Link to comment Share on other sites More sharing options...
Yulliah Posted December 7, 2017 Author Share Posted December 7, 2017 No problem... So I use this source? int YM_SettlementDialogueTimerID = 10 Function SomeFunction() StartTimerGameTime(120, YMSettlementDialogueTimerID)EndFunction Event OnTimerGameTime(int aiTimerID) If aiTimerID == YMSettlementDialogueTimerID YM_SettlementDialogue.SetStage(20) EndIfEndEvent And then make a quest property for the YM_SettlementDialogue? Link to comment Share on other sites More sharing options...
SKKmods Posted December 8, 2017 Share Posted December 8, 2017 Looks good. If there is any other path to set the stage, then include a CancelTimerGameTime() in that script + id. Not just for technical hygiene, but to avoid a quest regression when the timer does fire. Link to comment Share on other sites More sharing options...
Yulliah Posted December 8, 2017 Author Share Posted December 8, 2017 I've added the following script to the dialogue the NPC says just after being recruited: Quest Property YM_SettlementDialogue Auto Const int YM_TimerID = 10 ; Give our timer an ID we can remember Function SomeFunction() StartTimerGameTime(120, YM_TimerID) ; Create the timer with a 30 minute game-time durationEndFunction Event OnTimerGameTime(int aiTimerID) If aiTimerID == YM_TimerID ; The 30 minute timer we started just expired Debug.Trace("Timer ended! Do some cool stuff now...") YM_SettlementDialogue.SetStage(20) EndIfEndEvent Link to comment Share on other sites More sharing options...
Yulliah Posted December 8, 2017 Author Share Posted December 8, 2017 Looks good. If there is any other path to set the stage, then include a CancelTimerGameTime() in that script + id. Not just for technical hygiene, but to avoid a quest regression when the timer does fire. There really isn't... It will only go to stage 20 when the timer runs out... Link to comment Share on other sites More sharing options...
Recommended Posts