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

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 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 in 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, the 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.

Data Storage

• 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.
• Each value requires 8 bytes + (number of characters in the value's name) to store. Each child level in a container additionally requires 4 bytes + (number of characters in the child's name).