Another question about the engine: how to properly implement a (short-term) timed behavior?
For example, a timed explosion to fire 10-seconds later.
I tried to poll game_time for +100 in a repeated global script.
But the condition always seem to fire early at 1s-8s. (huge drift)
That's strange, since game_time should return number of tics of game time, where one second is 10 tics. There is an sfall function which returns current system time or something like that, you could try to use it.
(The global script repeating interval varies badly between maps, but sort of consistent in the same map.)
That's because when you specify set_global_script_repeat it actually means how many frames to skip before executing "start" proc, so the frequency is closely tied to current frame rate.
So it seems that export/import is not yet ready to use for better modularization.
Seems so. However, try out export variables. They should be reliable now (and if not, easily fixable since all related engine hooks are already in place).
BTW maybe sfall hooks should cover all normal map/object events?
For example, it seems that proto data is reloaded between each map load, while global/hook scripts don't have map-enter hook.
That's a good question. I already started to move in direction of making sfall scripts more flexible and event-oriented rather than abusing set_global_script_repeat:
- no more need to place "start" proc in the beginning
- map_enter_p_proc, map_exit_p_proc, map_update_p_proc is already executed for all sfall scripts since 3.4
- register_hook_proc function (make specific proc to be called instead of "start")
- many functions which relied on current script having a SID (reference in scripts.lst) now work with sfall scripts
- there is also set_self function from earlier sfall versions (see question below)
Now the question is - what to do next? You obviously can't hook object events (like use_p_proc) on global scripts, so they are like map script in this regard. I might implement add_timer_event alternative for global scripts. Also there is a timed and event procedures, though I'm not entirely sure how they work, since no one ever used them in fallout scripting.
My long term plans in this regards is to find out how to pass argument values to and get return value from procedures. This will not only allow to take sfall hook arguments directly without calling get_sfall_arg (and same for return value), but also to completely replace vanilla opcodes related to exported procedures (may easier than fixing existing code). Interpreter code is very hard to understand from the asm...
Since there is one interested person, I have another question regarding
set_self function. Currently it allows to use functions like
pickup_obj(item) from sfall scripts, but only if you call set_self right before the relevant function call (original "self" is reverted automatically after next function call). While this is safer (in case you forget to "set_self" back), it is also not very user-friendly when you need to make chains of such calls. I can leave it as it is, since there are not many functions which actually use self_obj, what do you think?
(other options include reverting it back automatically after each event is fired for a given script, or at the end of the frame, etc.)