Thread of weirdness in sfall scripting

[JimTheDinosaur]

Use this script to list weird behavior in sfall scripting so those generations of FO2 modders coming after us can benefit.

1. Halted script execution: as phobos explains here, some functions apparently cause frames to be skipped, meaning that anything which relies on a single frame for execution (temp_arrays, set_self, reg_anim_combat_check, etc.) breaks down. In the case of arrays, a simple workaround is of course to make permanent arrays instead.

2. UI button procs breaking down loops and arrays: Now this I still have no idea what causes it, though it could have to do with the previous point. What happens is that any button proc, or any procedure called by that button proc, causes temp arrays to break, and causes loops to become interrupted. What I mean by that last point is that if you, say, have a loop like this:

procedure button begin
variable counter:=0;
while counter < 4 begin 
global:=counter;
counter+=1;
end 
end

and you have your global script repeatedly checking whether the global variable is 2, then this gets called while the loop is still running. It's quite weird I think. A way to deal with problems arising from this is of course to add something like

loop_finished:=0;

before the loop, and set it to 1 afterwards, with your repeating script checking for whether the loop is finished.

 

[JimTheDinosaur]

An addendum to the last point, though it doesn't strictly have to do with sfall scripting, here's why I think you shouldn't do anything with button procedures other than setting variables:

There's probably a lot of big mods out there using button procs to do a lot of involved stuff, which I think is a very bad idea. The biggest reason for this is that they are extremely slow. Here's how long one procedure I use takes with a button procedure (times debugged through get_uptime()):

time1: 146403172
time2: 146403579

More than 400 whatever the time unit is. I should've made a vid, but I have some context menu building that literally takes more than 10 seconds to complete. Now, what if I use that same button procedure to set a variable, which I then check through a repeating global script, and run my procedure through that?

time1: 146402016
time2: 146402016

I.e. we go down from 400 to instantaneous. You of course lose some immediate responsiveness, but there's a second reason why not using button procedures directly is useful: because they're so incredibly slow, they will tend to interfere with other scripting activities you're performing (you can't use things like temp_arrays with them, for example, and other processes can cut through loops used by them).