Difference between revisions of "Category:NVC"

Jump to navigation Jump to search

Category:NVC (edit)

Revision as of 11:21, 14 November 2008

35 bytes removed ,  11:21, 14 November 2008
updated
imported>Speedo
m
imported>Speedo
(updated)
Line 2: Line 2:


{{OBSE Plugin
{{OBSE Plugin
|Version    = Beta 2
|Version    = Beta 4
|InternalVer = 2
|InternalVer = 4
|Name        = Named Value Containers
|Name        = Named Value Containers
|Author      = [http://www.bethsoft.com/bgsforums/index.php?showuser=233615 Speedo]
|Author      = [http://www.bethsoft.com/bgsforums/index.php?showuser=233615 Speedo]
Line 16: Line 16:
}}
}}


==Introduction/Tutorial==
==Tutorial==
See [[NVC Tutorial]]
See [[NVC Tutorial]]


Line 32: Line 32:
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 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 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.


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 (\).
*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.
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===
===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:
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.
 
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:
For example, using the function [[nvcReadXXX|nvcReadInt]]:


FunctionName "Hello World!"
  (int) nvcReadInt ContainerID key:string ''location:string key:string_var location:string_var''


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


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.
set myintvar to nvcReadInt mycontainer "a value" "location 1\location 2"


====String Sources====
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):
'''IMPORTANT! OBSE string vars are not yet supported.  Support should hopefully be added once the OBSE v16 beta ends'''


  ID    Source
  string_var key
  0      OBSE
  string_var location
  1       Pluggy
...
  2      TSFC
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


An example using the fictional function above with a TSFC string:
*If a function has two parameters with the same name but different types (one string, the other string_var), the parameter with of the string type has priority so long as the string_var parameter is 0 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,


  int mystring
  string_var key
 
...
  set mystring to StrNew "Hello World!"
  set key to sv_Construct "a value"
  FunctionName 0 2 mystring
  set myintvar to nvcReadInt mycontainer 0 "location 1\location 2" key


====Mixing Sources====
:is perfect valid syntax.  The name of the value to read will be taken from the "key" string_var, while the location of the value uses a string literal.
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==
==Miscellaneous==
*Active NVC data is saved in the .obse save file.
*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.
*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).
*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 [[:Category:Pluggy|Pluggy]] arrays).


[[Category: Functions|Z]]
[[Category: Functions|Z]]
[[Category: Functions (OBSE)]]
[[Category: Functions (OBSE)]]
Anonymous user
Retrieved from "https://cs.uesp.net/wiki/Special:MobileDiff/3087"

Navigation menu