Understanding reference variables

[Thalassicus]

If I understand this correctly, from what I've read on several sources, reference variables are instantiated objects of classes, and classes are called "base objects" in the CS? If so, how can I access data elements of the instanced object, like:

 

RefVar.FormID

 

I tried this in a script, which didn't work. Is the FormID a private/protected member? If so, what's the corresponding Get function?

 

Or do I have this wrong, and is a reference actually a pointer to an instantiated object? In which case, how would I dereference and access the elements, like the following?

 

RefVar->FormID

 

Or is a reference variable not a class at all, but instead a key in an associative array that identifies the actual instanced class object?

[Vagrant0]

Not quite sure what you're asking, but maybe I can still answer it.

 

Basically, there are two types of references; persistent and non-persistent.

 

Persistent references are objects which are placed within a cell in the CS and are given a higher priority in terms of being tracked by the game. Placed objects can be made persistent by ticking a box when editing the object in the render window. Some objects, like markers will always be persistent. A persistent object which exists within a .esm or the .esp containing the script can be accessed directly by both name (usually done when making it persistent) and Form ID of the placed reference. Persistent objects within one mod cannot be directly referenced by any script located in another mod without complications that aren't worth getting into.

 

Non-persistent references are objects which are either created by a leveled list (like most everything inside dungeons), spawned through scripting (as opposed to enabled), or are placed in the CS but do not have the persistent box checked. These objects cannot be directly referenced by any script, even when named. However, these objects can still be referenced by use of scripting functions which return a reference when called (getself, getcombattarget, ect), and are stored within that script as a script reference.

 

Both persistent and script acquired non-persistent references can be used for most scripting functions that work on the instance. For getting variables on those references, that reference must have a script attached which contains that variable. Provided that both the reference being used and the variable on that reference are valid, the scripting would look something like

 

For persistent references or references named within that script;

short npcvar1

begin onwhatever
set npcvar1 to <refname>.<variable>
end

 

For persistent references which are named in another script;

short npcvar1
ref actor

begin onwhatever
set actor to <questname>.<questreference>
set npcvar1 to actor.<variable>

 

The variable npcvar1 needs to be set to the value on the reference so that the script can make use of it. Something like;

begin onwhatever
player.setav strength to actor.<variable>
end

will usually not allow the script to be saved, and may not work properly in usage if it does. The rule of thumb is that if a script uses any variable or reference for a function or logic check, it is usually best to store that variable locally within that script.

 

Just keep in mind that when using non-persistent references within a quest script, you should always clear out the previous reference by setting it to some default persistent reference as soon as you are done with the operation. If a non-persistent reference no longer exists within memory, but is trying to be used by a script, you will almost certainly crash.

 

 

Not sure if this answers your question.

[Thalassicus]

Thanks for the help! I guess what I'm trying to do is understand how references work from a low-level programming perspective, to try and then visualize how they work at a higher level and interact with Oblivion's scripting language. From what I understand, and what you describe, a reference refers to an object that has multiple data elements within it? This sort of object is sometimes called a structure, record, or class, depending on the programming language used. It's often easier for me to understand things if I understand how they're actually implemented, which is usually in c++ for games.

 

The reason why it came up is I'm trying to figure out how to access data of an object in the game world to view for debugging scripts, such as the object's ingame name, form ID, or other useful information. One example is, I want to be able to tell when it's a player's horse activating a script, or it's the player riding the horse.

[Vagrant0]

I guess the best way to explain it is to down-think and put it in a somewhat plausible real-world model.

 

For the sake of this model, we'll say that Vanilla Oblivion is like a large corporate office building, it has its main staff (persistent, quest based actors), it's filler staff (other persistent actors), and a fair assortment of deliverymen, service techs, and other contracted parties (non-persistent actors). This office has a directory which knows all the main staff and filler staff by name, but does not really keep track of those deliverymen, service techs, and others in any constant manner.

 

If someone visiting that office (quest or outside script) needs to contact one of those people, they will need to consult with this directory to know where any person is. For main staff and filler staff, this is less of an issue since they all have their own offices (NPC data) which is kept on record in that directory. For the service workers however, this is much more difficult since the locations, or existence of any one person is not always known, and at best all you can do is wander around, and hope you manage to bump into one looks like the person you were looking to contact.

 

In the case of Oblivion with mods added, it is much the same way, except that you instead have an office building filled with many corporations, multiple directories, people from different corporations put into the same office (usually source of conflict), and many more service workers which aren't tracked in any significant way. Although the corporations occupy the same building they do not share information with eachother, and have no personal connection with anyone outside their corporation.

 

In the case of Oblivion with mods and OBSE, it's much the same way, except that instead of wandering around and hoping you can bump into who you are looking for, you also have a radar which can query the nearby area or work remotely.

 

What references stored in scripts do is like giving some of those people, both staff and service members a radio for the day so that if they are needed by anyone, they can be contacted. But, once that day is over, the worker will return the radio so that it can be used again later. The next day the radio will be used by someone else or left on the shelf. Typically, this job is handed out by a quest script, but can be done by having a staff member or known person bring a radio to that person, or leaving a radio at a desk where the person just picks it up.

 

As you can expect, this can make it very hard to find the person you want to find if they are not persistent, do not have a radio, and don't seem to be anywhere you can check, but this is the purpose behind the base. Although contacting the base will not tell you where any related person is, it can still relay some information to that person so that next time they appear they will either be easier to find, or can perform what you want done.

 

What scripts on actors are is like a notebook that some people carry around with them which tells that person what they should be doing or should look for. The actual instructions written in this notebook are written in pen, so cannot be changed. However in addition to the instructions they have a few spaces where numbers or the names of people can be penciled in, either to use directly, or to pass on to others. By using this notebook a person can keep track of where they've been, or even who they talked to at a specific point in time. This means that instead of having to find the person you were looking for directly, you might be able to find them if by asking if someone bothered to write down that person's name.

 

The real trick to all of this lies in knowing what questions you can ask to get any useful information. Everyone knows who they are currently talking to, making a delivery to, or fighting with, but only so long as they remain performing that action. As soon as that action is completed, the person loses all knowledge of the other, unless it was written down for later use.

 

This illustrates how persistent and non persistent actors are handled (kinda) and how you have to think about things when trying to find that particular reference you want to modify.

 

Personally, I try to approach it from the direction of known actors and unknown actors. Known actors are any actor who is persistent, or can be accurately singled out by use of a scripting function at any previously known location. Unknown actors are actors who aren't persistent, and can't be accurately singled out by use of a scripting function at any known location. An example of acquiring a known actor from an unknown actor would be something similar to that last point above:

 

You see a friend talking to someone you don't know. In order to know that other person, you will need to approach your friend and ask who they are talking to. Because your friend knows this person, you know this person.

 

Or

set knownperson to friend.getpackagetarget

 

To expand this further, let's say that that known person who was just introduced to you by your friend mentioned a cute sister who is single and who might like someone like you, and is nearby. Naturally, you would ask that that known person to introduce you to their sister.

 

Or

set knownperson to friend.getpackagetarget
set futuregirlfriend to knownperson.cutesister

 

In contrast, an unknown person is like some random jerkwad you see on a nightclub dancefloor. Although you may want to stomp his face in, you don't know him, will probably never see him again, and aren't about to ruin the party by trying to approach him. Although you can probably find it out if you really want, it can often lead to an excessive amount of work and conflict.

 

Hope that clears things up somewhat... If not, maybe it has atleast succeeded in confusing an entertaining you.

[ptbptb]

Damnit Vagrant0. You deserve half a dozen Kudos for a post that long (or a reference to a reputable psychiatrist ;) ) and I can only give one.