Improved Scripting Tools (SSL+ and Script Editor)

What I meant was: I can trigger repeatedly map_update by opening/closing pipboy.
The situation is: there is gvar in map_update which gets reduced each time the proc triggers (normally every 30 seconds, roughly). So it should take some time until the gvar (of 100 units) is completely gone. But when I open and close the pipboy about 20 times in a row, the gvar is completely reduced after that, (which is roughly within 20 seconds; as long as it takes to click "p" and "esc" 20 times in a row) because each time I open/close the pipboy I trigger a map_update.
I do get the "every 30 seconds" in addition, I just found that there are many actions (as listed) that trigger additional map_updates (i.e. in addition to those 30 seconds intervals).
Making map_update very irregular, but also one of the most tight procs in the game. It basically gets triggered by everything but map_exit.
The 30 seconds even trigger during combat.
 
Maybe use timer event (or sfall global script) instead of map_update if you need a certain GVAR to only be changed by a fixed time interval?
 
map_update_p_proc - updated every 30000ms (30-sec, for the game it is 300 ticks).
If you opened-closed the pip-boy when 15 seconds have passed, then map_update_p_proc will still be updated after 15 seconds again.
30000ms does not mean that it will necessarily update at this value, it can be 30100ms.
Code:
if (global_var(16) > 0) then begin
   set_global_var(16, global_var(16) - 1);
   display_msg("You're at " + global_var(16) + ". Praise Muttie!");
end
You can put this in map_update of obj_dude. Set gvar 16 to 600 and see how and when you can trigger it. Makes the amount of additional map_updates fairly obvious.
[You can also remove the check of > 0, then you won't have to set the gvar. But I haven't tested what the engine does when it goes in the negative.]

Index error addition
While experimenting I kept the same script in various states like “obj_dude, obj_dudePROTO and obj_dudePROTOtest”.
When I open “obj_dudePROTOtest” then “obj_dudePROTO”, copy and paste something from “obj_dudePROTOtest”, close it, then paste it into “obj_dudePROTO” and try to save that one under the name of the just closed “obj_dudePROTOtest” then I did get the same “out of index” error.

Otherwise the sfall script editor is very solid. For example, I haven't yet discovered a single compiling or decompiling error. Always worked smoothly so far (and I sometimes compile and decompile and absurd amount of times when testing a bug or potential fixes for it). Never had an issue yet.

Maybe use timer event (or sfall global script) instead of map_update if you need a certain GVAR to only be changed by a fixed time interval?
Yes, I'm already testing that :)... this is more sharing my experiences so far.
 
One thing I find bizarre is the use of Doctor's bag (and the amount of map_updates they seem to trigger). Even varies when used “inside inventory” compared to “outside inventory”.
I had not tested the following with the code but during a “screen flicker” bug which seemed to trigger a flicker each time there was a map_update.

Doctor's Bag (inventory):
fade (use, skipped if not injured), fade/flicker (heal and used up), flicker (closing inventory).

Doctor's Bag (outside inventory):
fade (use, skipped if not injured), fade/flicker (heal), flicker (used up), flicker (end of use_obj_on).

[The fade to fade/flicker is a single fade (in normal game) but it seems longer when healing triggers.
However, they should trigger separate map_updates. At least the “stutter bug” I had triggered (when injured) 3 flickers (inventory) and 4 flickers (outside inventory) and if (not injured) it was 2 flickers (inventory) and 3 flickers (outside inventory).]

Skill book (inventory):
fade (use & used up), flicker (closing inventory).

Skill book (outside inventory):
fade (use), flicker (used up), flicker (end of use_obj_on).

P.S. The whole addition to the code was just a silly joke, I hope no one took that serious. Just a bit o fun.

Anyway, I'm probably in the wrong forum, this has gone a bit too far off from the original point of the definition of map_update_proc that can be found in the sfall script editor. Still, I find it interesting when and how procs trigger.
 
There are no releases on the github for the script editor btw

edit: - where da hell would I find "scripts.h" for it??

edit2: - ok, I'm out, I'll leave scripting up to others here
 
Last edited:
Where is the up to date version of the script editor? Everything I found so far is many year old.
 
Where is the up to date version of the script editor? Everything I found so far is many year old.
I recommend Stalin's "Sfall Script Editor" you can find it in download section on NMA. Once you are more confident with scripting, I'd recommend BGForge MLS (VSCode plugin).

Latest Modderspack still includes the old editor, it's supposed to work but for regular people there's hardly any reason to use it.
 
FYI and in case people keep looking and get confused.
The "Sfall Script Editor" isn't in the download section of NMA anymore. That one did not get restored like the others.
 
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.
 
Last edited:
First of all, I have nothing to do with "sFall Script Editor", the new one. You better write about it on the author's forum or VK group. I worked on the old editor for some time years ago, but it's pretty much abandoned now.

Second, some of these issues are related to script compiler, which is technically a separate software. Some of those might've been fixed in the latest versions. You can download sfall modderspack 4.4 from Source Forge (it is the latest one) and replace compile.exe, parser.dll and int2ssl.exe in the new editor (Resources folder) with the latest ones from that pack. I fixed a bunch of annoying bugs this year, so highly recommend you to update.

Personally I switched to using VSCode + BGForge MLS with custom compile batch script - it's way faster and more productive for me. Although it doesn't do the whole code parsing like the full editor (only simple regex-based syntax highlighting), there's no "find references", "go to declaration" doesn't work most of the time, there's no "rename symbol" option. But despite this, I still prefer it because VSCode is just vastly superior as a text editor to any "custom" editor made by one person.
 
Back
Top