Globals or locals...?

[Kitana]

I've finally gotten around to sort of starting to code an NPC mod - easier said than done. I'll probably have a lot of questions as time goes by, but this seems like such a basic thing that I should probably know. I can't imagine it not having had been asked before, and I did use the search function, but searching for things was never my strong point.

 

So, uhm...

 

What is the difference between global variables and local variables? -Is- there a difference? Which should I use in what situations?

[berelinde]

That, my friend, is a question for the ages, and a question worthy of the sages.

 

Local variables are associated with one NPC, and one NPC only. If a create a local variable for Gavin, I can check it in any of Gavin's dialogue files or any of his scripts, but I cannot check it from Anomen's.

 

The advantage of using local variables is that they are not evaluated every time the saved game is evaluated. This can make load times *marginally* shorter. I say "marginally" because modern computers process information so fast, it hardly matters. The second reason you might prefer to use local variables as opposed to global variables is that if the variable is only going to be checked once, it's hardly worthwhile to commit it to the (likely) long list of global variables.

 

The advantage to using global variables is that they can be set and checked by any file in the game. I can set a global variable in Gavin's dialogue and check it from Anomen's script, or use it in an area script, whatever.

 

There are bound to be lots of folks who disagree with me on this, but I'd say that if you're going to check it once, and only once, in the same script/dialogue file, then go ahead and use a local variable, but if you think you might want to look at it again, use a global.

[cmorgan]

EDIT:

 

I just started to post way too much info. Sorry. What berelinde said.

 

Good stuff available on forum research here and at PPG on how to use and abuse these in conjunction with Area Scrips (or in place of Area Scripts) to do what you want.

[Kitana]

Okay, got it, that makes sense. Thanks.

[CamDawg]

I usually advocate a minimalist approach. For variables, if you don't need a global variable, don't use one. If the variable is only to be set and checked by one creature use LOCALS. If it will only be used in one area (but perhaps by multiple creatures) use an area variable.

[BigRob]

A follow up question on this point (as I limp towards doing some coding of my own). Does it matter who started the conversation as to whether a local can be checked, or does the individual just have to be involved?

 

So, can I set (and check) a local in one dialogue, and then also check it in a later dialogue initiated by a different NPC, but still involving the original one?

[devSin]

No, unless the dialogue is being run by the same character whose dialogue it was originally set in. Any check on a LOCALS variable in dialogue is going to check the value for the character who's currently talking (the same is true for setting a LOCALS variable).

[BigRob]

Thanks for clearing that up. Hmm, going to have to go over things very carefully in that case.

[Andyr]

I tend to use Globals for most variables--as I found sometimes I'd use a Local, but then require something else to be able to check the variable, so it was easier just to use a Global than go back and change every instance of the Global.

 

But if you're more organised than me, keeping track of Locals is probably not so hard.

[Guest jastey*]

For deciding whether to use locals or glogals, keep in mind that locals are not only bound to one NPC, they are bound to one cre. So, if your character dies and gets resurrected, all locals will be back at 0. In original BGII, romances would be dead if the NPC died, so triggering romance with local variables was feasible, but if you allow your NPC to continue romancing after dieing, using locals would lead to a great chaos.

 

I use globals for all varables I want to check later. I only use locals if it really doesn't matter if they get lost. For me, that is only if I want to distinguish between different dialogue paths in the same dialogue. Which, I learned, seems to be a speciality of my coding.

 

-jastey

[Kulyok]

When I was coding Xan, I asked here somewhere whether it mattered if I had a few thousand GLOBALS or LOCALS(memory, storage effects, whatever). And Domi said Ghreyfain told her(Ghrey isn't around these days, unfortunately) it didn't matter any.

 

Besides, Weidu adds like three hundred GLOBAL variables to Xan because of the interjections alone(the name of every I_C_T is a hidden GLOBAL variable, in case you didn't know).

 

So, for me it's GLOBALS all the way, with an obscure area variable here and there.

[berelinde]

With Gavin, I used global variables exclusively, and far, far too many of them, mostly because I made life tough on myself, and tracked a lot of things I didn't need to track.

 

For BG2 Gavin, I'll probably still use mostly global variables for the reasons Jastey gives: death and resurrection doesn't end Gavin's romance, so it will be more straightforward if everything's a global. For a more fully developed NPC like Gavin, there is a good chance that I will want to check even banter globals again, to see if a particular banter happened, so I'll use global variables there. For Haldamir, where there is no romance, and his banters are very self-contained, and there is no quest, I'll use local variables for the banters, and global ones only to keep the friendship talks running smoothly in case he dies and is resurrected.

 

In general, though, I find that I'm using far less variables in general. It was easy to forget what I used. I also advocate making up a variable map as you go, to track added globals so you don't forget.

[CamDawg]

Besides, Weidu adds like three hundred GLOBAL variables to Xan because of the interjections alone(the name of every I_C_T is a hidden GLOBAL variable, in case you didn't know).

I really, really wish more folks realized this. It's rare that you see prefixed dialogue state names, which means we can have all sorts of variable collisions for dialogue heavy mods.

[jastey]

It's rare that you see prefixed dialogue state names, which means we can have all sorts of variable collisions for dialogue heavy mods.

Seeing there are even tutorials available from modder(s) that don't care about prefixing their mod variables what can you expect?

[CamDawg]

It's rare that you see prefixed dialogue state names, which means we can have all sorts of variable collisions for dialogue heavy mods.

Seeing there are even tutorials available from modder(s) that don't care about prefixing their mod variables what can you expect?

Heh, to be fair, prefixing in a tutorial usually means that the folks using your tutorial will use your prefix. I thought Ghrey's complaint that many NPC mods were using J# was pretty funny until I noticed a slew of kit mods using C!.