Global Variables, Other Options

[ozziefire]

Ok, I need to find out the amount of radiation damage a player is being subjected too, GetRadiation Level doesn't seem to work so I want to track the RadiationRads level of the player and use that, so I need to record the previous value to calculate the Radiation level, I'd really prefer not to use a Global variable and while researching it at http://geck.bethsoft.com/index.php/Globals I found this statement

 

"In most cases, variables defined in quest script are the better choice. "

 

Does this mean Non-Global variables in a quest script will be remembered somehow? Or there's a way to do so?

 

Thanks

[Tefnacht]

Hello.

 

All script variable content is “remembered” and stored in the savegame for as long as the scripted reference exists. This is true for every kind of script, even for effect scripts to a certain degree.

 

The problem is that most scripts are attached to non-persistent references and therefore there is no way to access the variables from outside the script.

 

Quest scripts are an exception, since quests always persist.

 

If you have a quest called MyQuest with a script like this attached:

 

ScriptName MyQuestScript

Short foo
Float bar
Ref actor

you can access those variables from ANY other script by using MyQuest.foo, MyQuest.bar and MyQuest.actor.

 

Set MyQuest.foo To MyQuest.foo + 1
Set MyQuest.bar To 3.14151
Set MyQuest.actor To Player

A quest with a script like this, one that only defines variables but has no actual GameMode or MenuMode blocks in it, is sometimes called a “variable container quest”.

There is a little caution recommended though. Commands Like StartQuest and ResetQuest will reset all the quest script variables to 0. After StopQuest was used, you can still access the variable content.

 

The same can be done with scripted persistent references. Imagine you create a new object. A door. The script attached to this object reads:

 

ScriptName MyDoorScript

Short foo
Short bar

and now you place a reference to this door into the gameworld and make it a persistent reference with the name MyDoorA and a second one, also persistent but with the name MyDoorB.

 

Now in ANY script you can do stuff like this:

 

Set MyDoorA.foo To 6				;variable foo on MyDoorA is now 6
Set MyDoorB.foo To 2				;variable foo on MyDoorB is now 2
Set MyDoorA.bar To MyDoorA.foo * MyDoorB.foo	;MyDoorA.bar is now 12
Set MyDoorB.bar To MyDoorA.bar – MyDoorB.foo	;MyDoorB.bar is now 10

You see, both doors use the same base object with the same script. BUT since they're two different references, they each keep their own copy of the variable content. MyDoorA.foo and MyDoorB.foo are different variables.

 

This works with all scripted persistent references. Containers, Actors, Activators. It even works with persistent armor and ingestible references in theory but you need to be very careful. A persistent armor reference placed in the players inventory can cause trouble. A persistent ingestible being eaten is suddenly gone and no longer accessible.

 

One last note: You cannot access variables dynamically in this way. The script compiler will not allow that because it has no way to validate it.

 

Imagine you have a actor object called MyNPC with this script attached:

 

ScriptName MyActorScript

Short foo

and then place the actor into the gameworld and give that reference the name MyActorRef.

 

Set MyActorRef.foo To 5		;works, we assign the variable foo specifically for MyActorRef

Ref actor
Set actor To MyActorRef
Set actor.foo To 5		;does NOT work.

By the way, that is one of the reasons why I always write variable names in lowercase and everything else with uppercase letters. If I see something like (lowercase)(dot)(lowercase) I immediately know that is not going to work.

 

Well, that was quite a wall of text. I hope it helps.

[ozziefire]

  On 4/10/2011 at 3:42 PM, Tefnacht said:

Hello.

 

All script variable content is “remembered” and stored in the savegame for as long as the scripted reference exists. This is true for every kind of script, even for effect scripts to a certain degree.

 

The problem is that most scripts are attached to non-persistent references and therefore there is no way to access the variables from outside the script.

 

Quest scripts are an exception, since quests always persist.

 

If you have a quest called MyQuest with a script like this attached:

 

ScriptName MyQuestScript

Short foo
Float bar
Ref actor

you can access those variables from ANY other script by using MyQuest.foo, MyQuest.bar and MyQuest.actor.

 

Set MyQuest.foo To MyQuest.foo + 1
Set MyQuest.bar To 3.14151
Set MyQuest.actor To Player

A quest with a script like this, one that only defines variables but has no actual GameMode or MenuMode blocks in it, is sometimes called a “variable container quest”.

There is a little caution recommended though. Commands Like StartQuest and ResetQuest will reset all the quest script variables to 0. After StopQuest was used, you can still access the variable content.

 

The same can be done with scripted persistent references. Imagine you create a new object. A door. The script attached to this object reads:

 

ScriptName MyDoorScript

Short foo
Short bar

and now you place a reference to this door into the gameworld and make it a persistent reference with the name MyDoorA and a second one, also persistent but with the name MyDoorB.

 

Now in ANY script you can do stuff like this:

 

Set MyDoorA.foo To 6				;variable foo on MyDoorA is now 6
Set MyDoorB.foo To 2				;variable foo on MyDoorB is now 2
Set MyDoorA.bar To MyDoorA.foo * MyDoorB.foo	;MyDoorA.bar is now 12
Set MyDoorB.bar To MyDoorA.bar – MyDoorB.foo	;MyDoorB.bar is now 10

You see, both doors use the same base object with the same script. BUT since they're two different references, they each keep their own copy of the variable content. MyDoorA.foo and MyDoorB.foo are different variables.

 

This works with all scripted persistent references. Containers, Actors, Activators. It even works with persistent armor and ingestible references in theory but you need to be very careful. A persistent armor reference placed in the players inventory can cause trouble. A persistent ingestible being eaten is suddenly gone and no longer accessible.

 

One last note: You cannot access variables dynamically in this way. The script compiler will not allow that because it has no way to validate it.

 

Imagine you have a actor object called MyNPC with this script attached:

 

ScriptName MyActorScript

Short foo

and then place the actor into the gameworld and give that reference the name MyActorRef.

 

Set MyActorRef.foo To 5		;works, we assign the variable foo specifically for MyActorRef

Ref actor
Set actor To MyActorRef
Set actor.foo To 5		;does NOT work.

By the way, that is one of the reasons why I always write variable names in lowercase and everything else with uppercase letters. If I see something like (lowercase)(dot)(lowercase) I immediately know that is not going to work.

 

Well, that was quite a wall of text. I hope it helps.

I certainly was, but very informative for me and hopefully others as well :)