Fallout 2 mod How to add new LVARs into the script&

[NukaJack]

I`ve changed the script - add some new LVARS. When I left the location, they`ve all dropped to zeros. How to prevent it? Where is the number of keeping variables?

Переделал скрипт - добавил LVARов. Вышел с карты - все LVARры сбросились в нули. Как их защитить от сбрасывания? Он где-то хранит, сколько LVAR будет сохранено?

 

[Lexx]

The amount of LVARs available in a script must be defined in scripts\scripts.lst - you sure you did that?

 

[NukaJack]

It was:
Scriptname.int ; some comments # local_vars=7

I did
Scriptname.int ; some comments # local_vars=17

It didn`t work.
Any info after ";" seems to be a comment. Was I wrong?

 

[Lexx]

No, ; does not act as a comment in Fallout files.

If this doesn't work, there must be some error in your script.

 

[NukaJack]

Maybe I should start new game?


can I write so:
#define LVAR_TEAM (8)
#define LVAR_WAITING (9)
#define LVAR_FOLLOW_DISTANCE (10)
#define LVAR_LOCAL_ARRAY (11)
#define LVAR_STATUS (12)
#define LVAR_ACTIVITY (13)

or I must redefine LVARS 0-7
#define LVAR_ENEMY (0)
#define LVAR_FLAGS (1)
#define LVAR_HOME_TILE (2)
and so on

===================
defined all 17 LVARs again



#define LVAR_ENEMY (0)
....
#define LVAR_MY16 (16)

In scripts.lst changed # loval_vars=17
considered numeration from 0

Started new game.
Doesn`t help. 0-5 - some numbers, 7-17 - zeros
as soon as I cross the green zone between locations

 

[FDO]

Maybe I should start new game?

Did you try? I regulary start a new game directly on dummy test maps to test almost everything, it save some time. I know most scripts changes don't require a new game, but for example creating new global variables do require it.

Otherwise, you don't have to redefine old LVAR when adding new ones in my experience, but I admit that my use of them is relatively limited, I use the vanilla style 'here_before', 'hostile' and such on new critters and it does the job, but when I need reliable variables to trigger on several maps, I am more confortable with GVAR variables, easier to keep tab on for me.

 

[Lexx]

but when I need reliable variables to trigger on several maps, I am more confortable with GVAR variables

Well, you will have to use GVARs or MVARs in these cases, because LVARs are... local to the script.

 

[FDO]

Yeah I know, but I meant even in the case of a critter that spawn on several maps, then I guess you can use LVAR for most stuffs concerning the critter, and maybe use the export\import variables to make your LVAR 'travel' between scripts, but I am just guessing on that. Like I said, I keep LVAR for basic things, that's why I find GVAR easier to handle for the more complex parts.

 

[Lexx]

Export/ import is for temporary variables. They will get cleared on the next map enter and/or load. It's really not the same and shouldn't be used like that.

MVARs should be used for everything inside the same map, though I'm not sure if that's really necessary anymore nowadays, as memory isn't a big deal anymore.. so might as well just use GVARs for everything that isn't local.

Anyway, to get back to the topic... If the lvar count is correct in the scripts.lst file, the issue is probably somewhere in the script itself. Need to see the script for that.

 

[burn]

You can use sfall gvars instead, that doesn't require chaging scripts.lst. Also see the docs.

 

[Lexx]

Sfall gvars are crap, though. I don't recommend it unless it's kinda necessary.

 

[FDO]

Sfall gvars are crap, though. I don't recommend it unless it's kinda necessary.

Do you say that because of a performance issue? It seemed to me that on occasion loading times became a bit slower since I started using hooks and global scripts, but I wasn't sure?

 

[Lexx]

Nah, sfall gvars must be 8 signs long and that sucks. :>

 

[FDO]

I see. Still, it seem to me sfall global scripts are slowing the engine a bit, but it's not like it does much difference in performances, unless maybe you somehow still play Fallout on a Pentium from the 90's eh.

 

[burn]

Nah, sfall gvars must be 8 signs long and that sucks. :>

Just how long do you need them to be? even with a 2-letter prefix, it's still some trillion names.
To avoid cryptic names, you can use something like "#define SGVAR_LOOTER "p_looter". A bit longer, yes, but I think improved compatibility is worth it.

 

[Mr.Stalin]

Nah, sfall gvars must be 8 signs long and that sucks. :>

This can have numbers, as well as vanilla global variables. You have spent so much time in scripting and don't know anything about it yet. Shame.

 

[Lexx]

I didn't said it can't have numbers - signs are both, letters and numbers.

 

[Mr.Stalin]

I see. Still, it seem to me sfall global scripts are slowing the engine a bit, but it's not like it does much difference in performances, unless maybe you somehow still play Fallout on a Pentium from the 90's eh.

scripts must be written correctly and optimized. the naked hook handler itself doesn't cause any slowing down.

 

[FDO]

scripts must be written correctly and optimized. the naked hook handler itself doesn't cause any slowing down.

The 'slowing' might be nothing more than a impression on my part. I don't even have the impression while testing my stuffs in-game or loading saves, it's basically when starting a new game, the white splash lasting maybe 1 second more than before, no big deal, and it could just be in my head.

 

[burn]

The 'slowing' might be nothing more than a impression on my part. I don't even have the impression while testing my stuffs in-game or loading saves, it's basically when starting a new game, the white splash lasting maybe 1 second more than before, no big deal, and it could just be in my head.

You play with sfall/hi-res settings to speed up splashes and stuff. (FO2tweaks has a component to do that automatically)