Difference between revisions of "Tutorial: String Variables 2"
imported>Odessa (created page 2 of series) |
imported>Odessa (+category) |
||
Line 1: | Line 1: | ||
This is the second article in a [[Tutorial: String Variables|tutorial]] on [[string variables]]. | This is the second article in a [[Tutorial: String Variables|tutorial series]] on [[string variables]]. | ||
Line 63: | Line 63: | ||
==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://www.loverslab.com/topic/26963-tutorial-nvse4-part-3-string-variables/ The original text of this page was adapted with permission from this source] | ||
[[Category:String Variables]] |
Revision as of 11:20, 27 June 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