In LW2 this only ever happened with the officer intervention ability, but no sequences ever did this so it didn't matter in practice. The risk would be if some other kismet sequence for some mission reads Timer.TurnsRemaining without pulling it from the game state first, and some game code modified the timer since the last time the turn changed naturally. In LW2 we "knew" that the only use of the timer kismet var was in the turn change sequence, so as long as we were careful to refresh it properly there everything works. I suppose there is the possibility for kismet sequences to break, but in practice we didn't have any problems with this. The alternative would still be to build a clone of UMS_BasicMissionTimer that includes the extensions you need. Doing that at mission start to be able to influence the timer based on distance to objective might be tricky to get the order of operations right, but it might be sufficient to be able to implement the officer intervention ability. Using it to alter kismet logic is a bit unusual, but it should work. That shows how uscript can call into pre-defined kismet sequences, but it's mostly used for triggering cinematics and things like that. For an example of this see X2HackRewards.ApplySecureDoorUnlock and the corresponding event sequence in the compound rescue mission. If all you need to do is increase or decrease the timer by a particular number of turns during a tactical mission you can probably do it by triggering the "GiveMeOneMoreTurn" and "ReduceTimerOneTurn" remote events. There are ways to modify the kismet variables from uscript, but they are kind of ugly. So it's still not terribly mod-friendly, unfortunately. The game state object only has control over suspending the timer, not adjusting the mission timer count, and the sitrep stuff happens by tweaking the timer rules according to specific hardcoded sets of variables. Ok, so I was wrong - the mission timer is still owned by kismet.
0 kommentar(er)
