Some of my experiences with the script editor (sFall Script Editor v4.1.7.RC1). [Which may be interesting, maybe?] Please note, I'm not an expert, just trench experience while learning Fo2 modding – no idea if this is news or not.
Must add a "Start" proc
I've seen Fo2 scripts work w/o it. However, any script w/o a start proc that gets compiled by this editor will treat the first proc from the top as start proc and run it when entering a map or loading a save. I had it with destroy proc, description proc and so on. Took a while to figure out what I did wrong, too. [Mind you the int scripts worked fine before I compiled them.]
Edit:
There's a detail I didn't realize until I double-checked it. It's the optimization that causes this.
If you set it to "none" you can compile w/o start proc (and it seems to work fine).
If you compile w/ "basic" (only one I tested) then it will declare (or treat) the top proc as start proc.
...
So it's an optimization issue.
Unreferenced "imported" variables
Having any of these messes up the compiling. Scripts seem to work, though. (At least, I can't assign a bug to it, yet). But do look odd (when decompiled again).
/*******************************************************
* Some unreferenced imported varables found. *
* Because of it it is impossible to specify *
* the real names of global variables. *
*******************************************************/
The interesting point here may be that it does not give a warning when compiling source. Only shows up when decompiling the int file.
Edit:
Same as above, but this time it only triggers with an optimization of "none". If using "basic" it eliminates the unreferenced imported variable.
Issue with Headers
This is one I just found today, but I'm not sure if it is a editor problem? When I open obj_dude.ssl (1.02d) and then move down the procs (starting w/ combat) the procs won't get highlighted on the right panel until I reach line 79. Then they do. When I disable the inclusion of the v13.h, it works correctly.
Seems the editor gets thrown off by [getTimeBit]. Not sure why though?
Could be the header actually.
Anyway, this had me bothered for a while as I thought I messed up by moving procs around. Wasn't me this time, though.
Search function
Don't use enter but mouse to click through. Using enter "can" (sometimes) skip out of search and enter lines to the script.
If it says keyword not found. Go back to the start of the script and try again. Sometimes it doesn't pick up on it right away. If it still won't trigger, it's not in the script, I'd say.
Once it finds keywords it's reliable (I think) but won't always loop around when reaching the last script.
[Note: these are mostly related to searching more than one script. These are also more "guidelines". I did not do full tests on this.]
Index thingy
Not sure what it is (or how to best describe it) but when having several scripts open, it can get confused and throw up an error. [Basically, it's on line 500, but the index has no line 500 and the editor breaks down... kind of.] Once that happens it's usually over (must close and restart app). Which can suck when in the middle of going through a batch of files.
...
This was eluding me for years. Never was able to find a consistent set up. But I think I did today.
Seems the script in first position defines the range of the index, and closing it, while the other scripts are outside that range (i.e. above it), causes the error.
So the "fix" would be to always close scripts from last to first. And/or to never close the first script before the others.
It also seemed fine to move the first script to a different position and then close it. However, moving a script from second to first position and then closing it "may"* again trigger the error (* if it has less lines than the other scripts). Seems the script in first position always defines the range for the index (kind of).
...
There may be more to it, but with the above I had a consistent set up to trigger (& avoid) the error.
That's all.
Just a few pitfalls I found myself into over the past three years.
PickUp proc
Other stuff was Header related. For example, if you delete pickup proc and try to declare it again it won't let you because it is already declared in a header. Had to temporarily comment out the define header to put it back in.
That was another pratfall that took a few hours to get up from.
Anyway, I'm slowly getting comfortable with using headers.
Lots to learn. Lots to find.