Tutorial: String Variables 1

Revision as of 11:42, 9 July 2014 by imported>Odessa

This is the first article in a tutorial on string variables.

String Theory

Strings are particular combinations of characters - letters, numbers and punctuation. They're nothing new to the vanilla game and you've seen them all over. Just about anything that you see in the game interface that is a word or sentence instead of a number is a string: the names of the buttons in your menu, the word 'Open' or 'Enter' that pops up when your crosshair hovers over a container or door, the notification "You no longer have hunger sickness", the 'name' of the key the game kindly suggests that you press to activate something, and so on, they're all stored as strings under "Game Settings". Different language versions of the game will have different values for those strings.

Many vanilla script functions actually accept strings, although you may not have realised it, for example:

PlayerREF.SetAV Health

'Health' is actually a string that can be replaced by a numeric int referring to the same actor value - using the string 'Health' just makes it so you don't have to look up that int. You could type this for identical effect:

PlayerREF.SetAV "Health"

What we'll be talking about here mostly are formatted strings, however, not those game setting or actor value ones. If you've ever used functions like DebugPrint, PrintC, or MessageEx, you've used formatted strings to tell the game what to display:

DebugPrint "I'm a string"
PrintC "I'm a string"
MessageEx "I'm a string"

What's in between those quotation marks is a formatted string, because you've used the double quotation marks to tell the script compiler it's a formatted string. Without that, it would complain that 'I'm' is not a valid argument to the function. (Because double quotation marks are used to mark strings, I'll use single ones to quote things in this tutorial, to avoid confusion. And I'll just use 'string' for 'formatted string' from now on.)

The problem with strings, from a scripting POV, is that vanilla doesn't leave us many options to manipulate them through script. That is especially true for game setting strings and actor value strings. Formatted strings at least have the advantage that vanilla allows us to use a few format specifiers on them, to pass the value of a float variable to the string itself:

if 'fSomeFloat' is 3.4, then

DebugPrint "The number is %.0f" fSomeFloat   --> will display 'The number is 3'

DebugPrint "the number is %g" fSomeFloat     --> will display 'The number is 3'

DebugPrint "The number is %.2f" fSomeFloat   --> will display 'The number is 3.40'

DebugPrint "The number is %2.2f" fSomeFloat  --> will display 'The number is  3.40'

and NVSE added some more that we've been using a long time:

if rRef is DocMitchellRef:

DebugPrint "The object's name is %n" rRef           --> will display 'The object's name is Doc Mitchell'

DebugPrint "The ref's formid is %i" rRef            --> will display 'The ref's formid is 00104C0C'

DebugPrint "%ps is scratching %pp balls" rRef rRef  --> will display 'He's scratching his balls.'

MessageEX "Press %k to scratch your own" iInt
--> will display 'Press M to scratch your own', if iInt is 50, because that's the directxinput scan code for the M key

MessageEX "Press sUActnActivate to activate"
-->  will display "Press E to activate" if that's the key you use for activating stuff, because sUActnActivate displays the key name for what's used for the activate control, see the control codes

So far so good, but we still couldn't store those strings anywhere or edit them through script other than by entirely retyping them. That's where string vars come in.


Tutorial part 2: Basics, declaring and initializing

External Links