Difference between revisions of "Category:NVC"

Introduction/Tutorial

See Introduction to NVC

Concepts

ContainerID

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

Ownership/Protection

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

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 (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.

The names of both values and child containers are case sensitive. 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

Because string input is so important when trying to give values actual names, this plugin supports string variables from OBSE, Pluggy and TSFC. When a NVC function needs to take string input, you will typically see a pattern like:

FunctionName Input:string StringSource:int InputStrID:int

If you wish to give the function input as a string constant (that is, a string that you actually type into the editor when writing a script), you need only worry about the first parameter. For example:

FunctionName "Hello World!"

In order to use this function with string variables, you can ignore the first parameter (the compiler requires you to put something there, but it doesn't matter what - it will be ignored), and you will use the latter parameters.

Using string variables with NVC functions revolves around the StringSource parameter - when it is supplied and identifies a valid source, the function will ignore any string constant input and will instead attempt to retrieve the string(s) from the requested source.

String Sources

IMPORTANT! OBSE string vars are not yet supported. Support should hopefully be added once the OBSE v16 beta ends

ID     Source
0       OBSE
1       Pluggy
2       TSFC

An example using the fictional function above with a TSFC string:

int mystring
 
set mystring to StrNew "Hello World!"
FunctionName 0 2 mystring

Mixing Sources

If a function requires multiple strings for input, they must all be from the source. You may not get one string from Pluggy and another from TSFC, use one string constant and get one string from OBSE, or any other combination.

Miscellaneous

• 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).