Fallout 2 utility Is it possible to have LVARs in sfall global scripts?

Velizar

First time out of the vault
Is it possible to use LVARs in sfall global scripts (i.e. scripts prefixed with gl_)? The script doesn't get run globally if I correctly include it in scripts.lst, but otherwise its LVAR doesn't seem to work correctly;

If I give it a filename which is too long and include it in scripts.lst then the game crashes, but if I give it a filename longer than 8 characters but not long enough to crash the game, then it seems to work globally, and the LVAR worked mostly correctly? But when I reloaded the game during combat then I saw weird unexpected behaviour with its variable.

The reason why I need a LVAR is because ideally I would like the variable to be only accessible by this particular global script. But if that's not possible then I'll use a GVAR.
 
You should read up on the documents. gl_ scripts are not to be included in scripts.lst, they run automatically. They are gl_ (global) for a reason.

LVARs don't work there. You either use an Sfall variable or a GVAR.
 
Okay, I'll use GVAR.

The problem with the docs, which I read before posting the thread, is that they don't mention that gl_ scripts stop working globally if they're included in scripts.lst (therefore no LVARs) - it might be worth updating them to mention that.
 
But the docs imply that they aren't recommended over GVARs in the normal circumstances: https://sfall.bgforge.net/global-variables/
"The functions are intended for use when a patch to a mod requires the addition of a new global variable, a case which would otherwise require the player to start a new game."

Is there a benefit of sfall globals over GVARs?

Edit: I suppose that I prefer to use only one type of global in my own code, instead of first using GVARs and then adding sfall globals if I write patches for my mods, which is good enough to break the tie in this choice.
 
Last edited:
Just for clarification.. GVARs are compatible with gl_ scripts, but if you want to make an independent gl_ script that works with every mod, you can't use GVARs, as they wouldn't be unique. In that case sfall variables need to be used, there is no other way.
 
I thought of this, and I was going to start numbering my GVARs from some number like 8150, but then the Fallout engine loves assuming that everything is in order, so I wasn't sure whether that would work. Although even in that case I could have defined a few hundred dummy variables which I ignore, but that's not very neat, so in the end I agree about using sfall globals.

Though I would love to have a different type of sfall variables which are only accessible within a single .int script.
 
Adding dummy GVARs to a high number will not make your gl script more compatible with other mods.

Though I would love to have a different type of sfall variables which are only accessible within a single .int script.

What would be the point of that?
 
What would be the point of that?
It's the equivalent of private variables in other languages - in this case the benefit would be that you will know that the variable will be used in this file only, and you won't need to look for other files reading it or changing it.

Having global mutable state can easily lead to messy code, but with Fallout 2 modding global mutable state seems unavoidable because a lot of the logic happens in hooks or global scripts which can't easily pass information to one another because they don't call each other. But file-local variables might be a tiny improvement.

Adding dummy GVARs to a high number will not make your gl script more compatible with other mods.
It might not work because I haven't figured out whether vault13.gam would be a problem, but it doesn't matter, there's no point in attempting this instead of using sfall globals anyway.
 
You already have the equivalent of private variables in other languages. It's normal variables.
 
is it weird for me to read these topics, enjoying the convo, yet dont understanding whats going on really?
tbh I was trying to do ICT waaaay back, but never had what it took. Other people from my class were like computer wizzes.
I recall like one on the first day, some classmates already bypassed the login screen at the first 5min of class (might have been due to a simple ALT+TAB, hell did I know), call me impressed anyways.

I guess that probably why I'm still checking, ya all impress me what you are still doing with this ancient game. Ya all bunch oh computer wizzes too!

Sorry, bit offtopic here, heh
 
Back in school we also had specific terminal software that would only allow you to start software that was enabled (in that moment) by the teacher. But it was super easy to circumvent the interface and all of us were browsing the internet all the time.
 
You already have the equivalent of private variables in other languages. It's normal variables.
You're correct, however I meant to say something else - I'm looking for private variables which get saved with your game state.
 
In fact, it is impossible to make private variables for global scripts (available only in your script).
But I will think about implementing private/local stored variables.
 
You're correct, however I meant to say something else - I'm looking for private variables which get saved with your game state.
It's the equivalent of private variables in other languages - in this case the benefit would be that you will know that the variable will be used in this file only, and you won't need to look for other files reading it or changing it.

Having global mutable state can easily lead to messy code, but with Fallout 2 modding global mutable state seems unavoidable because a lot of the logic happens in hooks or global scripts which can't easily pass information to one another because they don't call each other. But file-local variables might be a tiny improvement.
So you want state, but you don't want state.
Well, generally speaking you're right, encapsulation exists for a reason (in other languages). However, practically, in my years of Fallout modding, I probably used a whopping amount of... 5 sfall gvars? Maybe 10, tops.
And, like noted, you can utilize arrays for some basic namespace separation.
If you had a valid case where you'd need to use, say, 30-50 gvars at least, I might tend to agree, but so far it doesn't seem that much of an issue to me. Or do you?
 
Good point. I'm scripting Fallout bullshit for about 15 years now and I never felt the need for something like that.
 
Maybe I'm doing something weird. I already have 4 sfall global variables in my WIP mod which is very small in scope: 1. used during initialization, keeps track of whether it's a new game or a game is being loaded, 2. for keeping track of whether a player has crafted a certain weapon, if yes then add a chance for vendors to restock ammo for it; 3. same but for a different weapon; 4. pending charges for the recharger rifle so that even when it's out of your inventory its ammo can recharge, and when picked up all ammo from the variable gets added to its magazine.
I'd love to get some code reviews once I'm finished with the first release of the mod.

Also when you say that you haven't had a mess of global variables, that's evidence that maybe it doesn't tend to happen in Fallout modding. Global mutable state often leads to a very bad mess in regular programming, but that doesn't mean that Fallout modding is going to be the same.
 
Well, can I tell you now that for checking whether it's a new game, you can just check game_time. Or do something like (map_first_run and cur_map_index = MAP_START_AREA).
(Also, if you have a multiple bool vars, you can mimic vanilla and set/check individual bits in a gvar, although this approach is limited in its usefulness)

Additional issue with script-private vars is that people would eventually want to change those in a savegame editor. And I think vad didn't even add full support for sfall arrays yet? Always shows some "unreadable data" warnings or some such.
 
Last edited:
Back
Top