Difference between revisions of "Category:NVC"

Tutorial[edit | edit source]

See NVC Tutorial

Concepts[edit | edit source]

ContainerID[edit | edit source]

Throughout this documentation the type ContainerID is used. This is simply an integer value, which stores a number identifying a particular container.

Ownership/Protection[edit | edit source]

Each container records the identity of the esp which created it. This ownership information is used both to determine when a container is no longer needed and to control access to it. In addition, each container also carries a protection flag which, when set, allows only the owning esp to modify the container. However, all esps may read data from any container.

• By default, all containers will be protected when they are created.
• Containers created either from the console or in a result script will use a unique esp/owner ID which is independant from normal EspID's. These containers may not be protected.

Identifying Values[edit | edit source]

The way NVC stores values can be thought of much like how your computer's hard drive stores files. Each value is identified by three characteristics: key (or name), location, and type (int/float/ref).

The container itself is essentially like the root of the drive (C:\). You may store values here if you wish, but you may also create child containers (which are like folders) within the container. One difference is that NVC seperates values within a container by type, so at any level it is perfectly valid to have values of different types which share the same key and location.

• Like the folders on your computer, child containers should be seperated with a backslash (\).
• There is no limit on the how many child containers or values may be created within a container (other than available memory), however for speed it is recommended to keep the number of child containers to a minimum.

String Input[edit | edit source]

In order to allow for more dynamic creation and access to NVC containers, all functions support the usage of OBSE string_vars for string input.

For example, using the function nvcReadInt:

 (int) nvcReadInt ContainerID key:string location:string key:string_var location:string_var

If you wish to use the function with string literals -actual text that you type into the editor before you save a script- you can simply ignore the string_var parameters:

set myintvar to nvcReadInt mycontainer "a value" "location 1\location 2"

If you wish to use the function with string_vars, will do the opposite, ignoring the first string parameters in favor of the string_var parameters (Note: The CS requires you to put in something for the string parameters, but it doesn't matter what - it will be ignored):

string_var key
string_var location
...
set key to sv_Construct "a value"
set location to sv_Construct "location 1\location 2"
set myintvar to nvcReadInt mycontainer 0 0 key location

• If a function has two parameters with the same name but different types (one string, the other string_var), the parameter of type string has priority unless the string_var parameter is non-zero or not supplied.
• If a function (such as the nvcReadXXX functions) takes multiple strings as input, it is possible to mix strings and string_vars. For example,

string_var key
...
set key to sv_Construct "a value"
set myintvar to nvcReadInt mycontainer 0 "location 1\location 2" key

is perfect valid syntax. The name of the value to read will be taken from the string_var "key", while the location of the value uses a string literal.

Miscellaneous[edit | edit source]

• Active NVC data is saved in the .obse save file.
• Container information will persist in the save (and be loaded into the game) until either that container is deleted, or the owning esp is unloaded.
• While the speed of NVC containers has not been fully tested, they generally should not be used in loops or other situtations where they will be heavily accessed (instead, prefer Pluggy arrays).