Difference between revisions of "Variables and Properties"
m
"Fixed" headers so highest level is h2
imported>Cipscis (→Full Property: ''set'' functions are called if the property's value is set in the CK) |
imported>Cipscis m ("Fixed" headers so highest level is h2) |
||
| Line 1: | Line 1: | ||
=Description= | ==Description== | ||
Variables and Properties are similar things, they both "hold" values and objects. A variable is "private" meaning that only that script is aware of them, can set their contents, and get their contents. A Property is essentially a variable that other scripts can access, their contents can be set and get by a other scripts. | Variables and Properties are similar things, they both "hold" values and objects. A variable is "private" meaning that only that script is aware of them, can set their contents, and get their contents. A Property is essentially a variable that other scripts can access, their contents can be set and get by a other scripts. | ||
| Line 5: | Line 5: | ||
If a variable or property holds a numeric value, like an integer, get/set returns its value. If a variable or property holds an object, you can access that object's properties and functions. (This is analogous to a reference variable from the old scripting system.) | If a variable or property holds a numeric value, like an integer, get/set returns its value. If a variable or property holds an object, you can access that object's properties and functions. (This is analogous to a reference variable from the old scripting system.) | ||
=Declaring Variables= | ==Declaring Variables== | ||
<source lang="papyrus"> | <source lang="papyrus"> | ||
float myFloat | float myFloat | ||
| Line 13: | Line 13: | ||
MyFloat starts at 0, myOtherFloat starts at 13.5 and can be set by scripting in its own script, but nothing else. | MyFloat starts at 0, myOtherFloat starts at 13.5 and can be set by scripting in its own script, but nothing else. | ||
=Declaring Properties= | ==Declaring Properties== | ||
==Full Property== | ===Full Property=== | ||
To define a property, you first write the type, then "property", then the name of the property. You then define two functions, a get which returns the property's value, and a set which takes a new value for the property. And then you cap it off with "EndProperty" | To define a property, you first write the type, then "property", then the name of the property. You then define two functions, a get which returns the property's value, and a set which takes a new value for the property. And then you cap it off with "EndProperty" | ||
| Line 78: | Line 78: | ||
If a full property has its value set in the Creation Kit, its ''set'' function will be called when the object is initialized, just before its [[OnInit]] event is called. | If a full property has its value set in the Creation Kit, its ''set'' function will be called when the object is initialized, just before its [[OnInit]] event is called. | ||
==Auto Properties== | ===Auto Properties=== | ||
An auto property is one that writes the above get and set functions for you, behind the scenes. There are also some minor optimizations in the VM that speed up auto properties slightly. To make an auto property, simply omit the functions and endProperty and add "auto" to the end of the property definition. You can set the property's initial value using the "= <value>" syntax. | An auto property is one that writes the above get and set functions for you, behind the scenes. There are also some minor optimizations in the VM that speed up auto properties slightly. To make an auto property, simply omit the functions and endProperty and add "auto" to the end of the property definition. You can set the property's initial value using the "= <value>" syntax. | ||
| Line 87: | Line 87: | ||
==Auto Read-only Properties== | ===Auto Read-only Properties=== | ||
An auto read-only property is an auto property that can never have its value changed. This can be convenient if certain numbers mean different things in your script and you want to use a name instead of a number to represent it. You specify these by using "AutoReadOnly" instead of "Auto". These properties ''must'' have their initial value set using "= <value>" syntax. | An auto read-only property is an auto property that can never have its value changed. This can be convenient if certain numbers mean different things in your script and you want to use a name instead of a number to represent it. You specify these by using "AutoReadOnly" instead of "Auto". These properties ''must'' have their initial value set using "= <value>" syntax. | ||
| Line 96: | Line 96: | ||
==Conditional Properties== | ===Conditional Properties=== | ||
Properties cannot be declared as conditional. Auto properties can be defined as conditional because what they actually do is define the hidden variable they create as conditional. This is why you see mangled auto property names when you select a Papyrus variable in the condition system - you're selecting from a list of hidden variables. | Properties cannot be declared as conditional. Auto properties can be defined as conditional because what they actually do is define the hidden variable they create as conditional. This is why you see mangled auto property names when you select a Papyrus variable in the condition system - you're selecting from a list of hidden variables. | ||
| Line 107: | Line 107: | ||
=Getting Properties of a Quest Script= | ==Getting Properties of a Quest Script== | ||
==From Result Script Owned by the Same Quest== | ===From Result Script Owned by the Same Quest=== | ||
Often you will need to get a property of a quest script, and use it in a result script somewhere else. This is one of the more tricky things, but once you understand what's happening, it makes sense. First look at the example, then we'll describe what's happening. | Often you will need to get a property of a quest script, and use it in a result script somewhere else. This is one of the more tricky things, but once you understand what's happening, it makes sense. First look at the example, then we'll describe what's happening. | ||
| Line 132: | Line 132: | ||
In other words, when we created MQ01Script which extended the Quest script, unless we cast the object returned by GetOwningQuest AS our new script, it won't have our new properties declared in our new script. | In other words, when we created MQ01Script which extended the Quest script, unless we cast the object returned by GetOwningQuest AS our new script, it won't have our new properties declared in our new script. | ||
===With kmyQuest=== | ====With kmyQuest==== | ||
If the fragment you are using has a "kmyquest" drop down, you can select a script attached to the quest owning that fragment, and then use the kmyQuest "magic variable" to refer to quest script without casting it. | If the fragment you are using has a "kmyquest" drop down, you can select a script attached to the quest owning that fragment, and then use the kmyQuest "magic variable" to refer to quest script without casting it. | ||
| Line 142: | Line 142: | ||
</source> | </source> | ||
==From Within a Magic Effect Script== | ===From Within a Magic Effect Script=== | ||
Let's look at an example where a scripted spell accesses a quest's properties: | Let's look at an example where a scripted spell accesses a quest's properties: | ||
| Line 177: | Line 177: | ||
</source> | </source> | ||
=Getting Properties From Any Other Script= | ==Getting Properties From Any Other Script== | ||
You can use the above example regarding the Magic Effect script as a basis for your script. You must define a property in your script, with the "Type" of your object you are wishing to access. If your object has a custom script, define the type as your object's script name. Be careful not to declare it as the object's name. All objects can have multiple scripts, so you must specify the ''script name'' you want to access. | You can use the above example regarding the Magic Effect script as a basis for your script. You must define a property in your script, with the "Type" of your object you are wishing to access. If your object has a custom script, define the type as your object's script name. Be careful not to declare it as the object's name. All objects can have multiple scripts, so you must specify the ''script name'' you want to access. | ||
For a list of objects you can use as a type that are already within the game, visit the [[Script Objects]] page. | For a list of objects you can use as a type that are already within the game, visit the [[Script Objects]] page. | ||
=Warnings= | ==Warnings== | ||
Be careful with variables and auto properties on scripts that are extended by other scripts - especially where some script somewhere else may have a property pointing to the base script, or trying to cast to the base script. This is because it would be possible to have two copies of a script attached to the same object, thereby creating two copies of the variable/auto property - and the other scripts that refer to the base script may randomly pick which one to talk to. | Be careful with variables and auto properties on scripts that are extended by other scripts - especially where some script somewhere else may have a property pointing to the base script, or trying to cast to the base script. This is because it would be possible to have two copies of a script attached to the same object, thereby creating two copies of the variable/auto property - and the other scripts that refer to the base script may randomly pick which one to talk to. | ||
| Line 190: | Line 190: | ||
*The list of properties in properties dialog is only updated after adding a new property or after compiling the script with the build-in editor. | *The list of properties in properties dialog is only updated after adding a new property or after compiling the script with the build-in editor. | ||
=See Also= | ==See Also== | ||
*[[Property Reference]] | *[[Property Reference]] | ||
[[Category: Papyrus]] | [[Category: Papyrus]] | ||
[[Category: Papyrus Tutorials]] | [[Category: Papyrus Tutorials]] | ||