Difference between revisions of "Tutorial: String Variables 2"

From the Fallout3 GECK Wiki
Jump to navigation Jump to search
imported>Odessa
(+category)
imported>Odessa
m
Line 62: Line 62:
*[[Let]]
*[[Let]]
==External Links==
==External Links==
*[http://www.loverslab.com/topic/26963-tutorial-nvse4-part-3-string-variables/ The original text of this page was adapted with permission from this source]
*[http://fallout.bethsoft.com/eng/links/privacyredirect.php?site=http://www.loverslab.com/topic/26963-tutorial-nvse4-part-3-string-variables/ This tutorial was originally adapted with permission from this forum post]


[[Category:String Variables]]
[[Category:String Variables]]

Revision as of 11:42, 9 July 2014

This is the second article in a tutorial series on string variables.


String Variable Basics: Declaring and Initializing

Just like a reference variable refers to a reference or form, and a float variable refers to a floating point number, string variables refer to a string. Duh, you might say, but it's important to remember that they themselves are not strings, which is why I make it a point not to use the word 'string' when I mean 'string var'. We already had strings, string vars to store and manipulate them are what's new. The actual strings that the string vars refer to are stored in the .nvse file that corresponds to your save file.

You declare a string variable like this:

string_var somestringvariablename

(A note about naming conventions: most scripters prefix their variable names like float fSomeFloat, ref rSomeForm to remember what they really refer to. Some do the same with string vars and use the 's' prefix (sSomeStringVar) but I'd advise against that, because there are hundreds of string-based game settings that use that same convention and you're bound to have conflicts. Personally, I use the 'sv_' prefix a lot, or none at all. Of course, there is the possibility of a conflict with the string var functions, which also have that prefix, but there are only a handful of them. Anyway, your choice, just watch out.)

Declaring a string var doesn't mean it actually refers to a string yet, it's the same with them as with other script variables: if you don't bother to set a ref var to something, it refers to nothing at all, and if you perform a function on nothing at all, you get squat or even crash.


Making a string var refer to a string is called 'initializing' it, and you do this by either: - 'letting' it to a formatted string, - 'letting' it to a string var, or - 'letting' it to a function that is supposed to return a string (including UDFs that return a string or stringvar with SetFunctionValue).

let sv_mystringvar1 := "I'm a string"   ; compare with: let rRefVar := DocMitchellRef
let sv_mystringvar2 := sv_mystringvar1  ; compare with: let rRefVar2 := rRefVar1
let sv_mystringvar3 := player.GetName   ; compare with: let rRefVar := GetActionRef

You can also still use the format specifiers when initializing, although this has you revert to an antiquated way of initializing strings by using Sv_Construct:

let sv_mystringvar := sv_construct "I'm string number %.0f" someInt
let rForm := Pencil01
let sv_mystringvar := sv_construct "Got a %n?" rForm

(Note that for passing numbers and names of things into strings, it's often much easier to just use ToString, see the chapter on that.)


If a string var is not initialized it returns the numeric value 0. That's the only time string vars and numbers can mix: never set a string var to a number, never set a float var to a string var or a string. In order to check if a string var is initialized or not before you use it for something, you can go:

if sv_mystringvar
 ; do stuff with your initialized string var
else
 ; you haven't initialized
endif

if eval !(sv_mystringvar)   ; ! means LogicalNot
 ; you haven't initialized
endif

Of course, if you know you've initialized it, there's no point.


Tutorial part 3: 'Let' vs 'Set' syntax

See Also

External Links