Do RefIDs Need to Be Unique Across Different Mods?

[user826]

I'm pretty sure the answer is "no," but I'd like to confirm this. Do Reference IDs need to be unique across different mods?

 

Like, let's say the author of Mod #1 was very uncreative and named their custom companion MyFollowerREF. And let's say the author of Mod #2 was equally uncreative and also named their custom companion MyFollowerREF. If a player loads both of these mods into the same game, will they conflict?

 

From what I understand, they shouldn't, because the load order would give Mod #1's MyFollowerREF a unique prefix like 01######, and Mod #2's MyFollowerREF would be 02######, right?

[dubiousintent]

Point: the mod creator should NEVER attempt to assign a "Reference-ID". That is automatically done by the GECK. You assign "Editor-IDs" uniquely within a plugin and let the GECK handle the other related IDs. Please see the 'GECK Form-ID, Base-ID, Ref-ID, and Editor-ID' section of the wiki "Getting started creating mods using GECK" article for the distinctions between those terms. Using the correct terminology is terribly important with the GECK to avoid confusion.

 

Otherwise you are correct (though not the way you framed the question: they do need to be unique "Ref-IDs"). I've read that the game turns all "Editor-ID" values (which are the "human readable" forms of reference such as your "MyFollowerREF" example) into it's own sequentially numbered references to that form. And the "mod index" is indeed an important aspect to how it keeps them separated between plugins. For exactly the reasons you identified.

 

-Dubious-

[user826]

Okay, good. So aside from the terminology mixup, my reasoning is sound? I'm asking because I'm developing a standardized framework for my customizable companion mod, and I was hoping I wouldn't have to change the Editor ID for every new companion I make, because then I'd have to update all the scripts and dialogue, etc. to reflect the new Editor ID. In this case, I can have multiple different plugins, each with an actor named CustomizableCompanionREF, and it won't conflict because the mod index for each plugin would be different, correct?

[dubiousintent]

Hmm. (Thinking through this "out loud".) Context is everything. Scripts (and dialog) operate within the context of the situation in which they are called. Which is why you have to pay attention to and assign a "reference" value to a "reference variable". (This occurs implicitly with the "calling object", but it is good practice to be explicit whenever possible, because implications can change unexpectedly. In a "framework" such as contemplated, you already have an "abstract" situation where it will be difficult to track who will be operated upon as it is.) "CustomizableCompanionREF" is a "variable name" of type "reference". Once you assign it the "reference value" of the "companion", then it refers to that specific "companion" instance for the duration of that script context. Called in a different context with a different "companion" referenced, the script operates on the new "reference value" of that different companion.

 

Conceptually your framework should work. This being the GECK, however, confirmation is a must. The obvious "edge case" (where things tend to break down due to unexpected situations) are where more than one companion is actively using the same script at the relatively "same time" and the context is rapidly shifting.

 

My guess would be that someone has done this before, but I haven't dug into such code so can't point you to any examples. (My first suggestion would be "JIP CC&C" is likely to be doing something like that.) But it seems worth pursuing.

 

Good luck.

 

-Dubious-

[user826]

Hmm, okay thanks for your input. I guess I'll just have to try it and see.

[GamerRick]

I'm pretty sure the answer is "no," but I'd like to confirm this. Do Reference IDs need to be unique across different mods?

 

Like, let's say the author of Mod #1 was very uncreative and named their custom companion MyFollowerREF. And let's say the author of Mod #2 was equally uncreative and also named their custom companion MyFollowerREF. If a player loads both of these mods into the same game, will they conflict?

 

From what I understand, they shouldn't, because the load order would give Mod #1's MyFollowerREF a unique prefix like 01######, and Mod #2's MyFollowerREF would be 02######, right?

 

 

Yes, the Ref-ID you give a reference item has to be unique across all mods. The best practice is to start your new Form-IDs and Ref-IDs with something unique. You can use your name or initials or something unique to your mod.

 

For example (from the AWOP mod):

 

a new NPC FormID: AWOPRaiderLightArmor

Their Ref-ID when placed in a cell: AWOPRaiderLightArmorRef

 

I don't know what would happen if two mods used the same ID, but it would definitely be a problem if they were used in a script. It would likely cause the script to refer to the item in the last mod loaded with that Ref-ID.

A more common and insidious problem is where one mod edits an NPC or item placed in a cell that a previous mod added a Ref-ID to so it can reference it in a script. That mod will remove the Ref-ID from the object, possibly causing the previous mod's script to fail. For example, YUP adds Ref-IDs to objects so it can fix bugs in a script. A mod that edits the same item (like Vendors Containers Respawn Fix - Elaborate Edition), but did not have YUP as a master, will remove YUP's Ref-ID from the object. I am not sure what effect this have on YUP's script that references that object.

Edited August 27, 2019 by GamerRick

[dubiousintent]

Sometimes people use a term interchangeably without consequence, and sometimes it is extremely important to pay attention to the distinctions. This is one such instance of the latter case.

 

A "reference ID" ("Ref-ID") is not the same thing as a "reference variable". Neither is a "Form-ID" nor an "Editor-ID". "AWOPRaiderLightArmorRef" is a "reference variable", not a "Ref-ID". (The "Ref-ID" is not normally visible, and refers to an instance of an object that has been placed in the Render Window. Each object can have multiple references.) The OP made that mistake in the thread title. I think we have established that he is actually asking about a "reference variable".

 

In the case of a "reference variable", the "scope" of the variable (whether it is defined within or outside of a "Begin/End" block) is what matters. When defined outside of a "Begin/End" block, it can be referenced by other scripts. In which case, it is important to use "unique" names for those variables (as in the AWOP examples) to avoid the possibility of confusion as to the source and intended use.

 

But for the OP's intended purpose of use is within his scripts alone, by restricting their scope to only his scripts (by defining the variables within the "Begin/End" block), he should be able to re-use the same variables (which have to be re-assigned a "Ref-ID" before each use) in multiple instances.

 

With that clarification, if anyone has evidence to the contrary the community needs to get this established.

 

A very valid concern is posed by GamerRick in his last paragraph. But I feel the example is a bit muddied by the loose terminology use.

 

In order for another mod to "replace" an existing "Ref-ID"/reference, it has to "overwrite" the existing "reference" record in an ESP or "inject" one into an ESM. That happens at load time ("Rule of One"). A "scripted change" would be editing the "Form Data", not the "Ref-ID"/reference itself. (I haven't dug into the code of YUP, but would be surprised if it was actually changing any "Ref-ID" via a script once you bear the distinctions in mind.)

 

-Dubious-

[GamerRick]

I thought what the OP was asking was obvious when he used "MyFollowerREF" as an example. The GECK shows "Reference Editor ID" in the dialog box where you would assign a unique text Ref-ID to the instance of an object. Ref-ID for short. The GECK refers to the 8-digit hex numbers as "Form ID". I did not understand how you saw this as confusing, but I have never heard the term "reference variable" before. The GECK refers to the text box where you would enter a new Base Object ID with "ID".

 

It would seem this need to come up with different terms for the hex-ID versus the text-ID is not consistent with how the GECK labels things.

 

 

EDIT: Maybe I assumed too much? I assume he was referring to two mods that each created their own unique follower, added that NPC somewhere, and then they each gave that ref NPC the same Ref-var. In that case both would have unique hex-IDs.

 

Another scenario (which I didn't consider) would be two mods that each edit an existing base-game NPC (that doesn't already have a Ref-var, because the NPC wasn't a follower before) with the same Ref-var. In that case there would be no conflict or problem with the scripts from each mod resolving the Ref-Var to the correct NPC ref. However, they would likely conflict with each other as they tried to control that NPC.

Edited August 28, 2019 by GamerRick

[FiftyTifty]

FormIDs are the hexadecimal value given to every record, with the first byte being the load order position of the mod the record is contained in if it's a unique record, or the FormID of the owning file of the record it overwrites. EditorID's are a holdover from Morrowind, and should be unique.

[dubiousintent]

Here we are getting into some "Computer Science" basics which the GECK never addresses.

"Variables" are "placeholders" and "aliases" for other things that are used in programs (scripts in this case). As such they are generally given values that are "temporary" and "dynamic" in nature. However, sometimes those variables are supposed to be "fixed" in value, which are called "constants". Once assigned a value, that "constant" never changes it's "value". An example of a common "constant" are the values of "true" (=1) and "false" (=0). You are actively prevented from changing those values to other numbers.

All the GECK "IDs": "Form-", "Editor-", "Base-", and "Ref-" IDs are (implied) "constants" created by the GECK when you fill out their form data. You (the mod author) might give them a "human readable name" (such as "AWOPRaiderLightArmorRef") but that is just a label for the humans to remember instead of the actual hexadecimal "record" the game engine actually uses. It's value cannot be changed by a script/program once it is loaded into memory. (They can be changed by "overwriting" the records by a later loading plugin, but not once the "winner" has been decided when the game starts.)

A "variable" can have a number of different uses. In some programming languages these are "strongly typed", meaning once they are given a "type" at definition they are always of the type and trying to give them a value of a different type will fail with an error message. An example of this would be trying to give a "date" value to a "integer" type variable when a "date" is stored and interpreted differently.

The GECK doesn't appear to use "strong typing". All it seems to have are (character) "strings", "signed integer numbers", "implied decimal float numbers", and "references" which contain record numbers. These are not "typed" when defined, but when the value is assigned. As such it falls onto the script author it keep track of the use to which those variables are put, which is why it is a "best practice" to give the variable name a "prefix" identifying the use of that variable name for consistency purposes. (I've never tried to change the functional use of a variable within a GECK script to see what actually happens, as "that way madness lies" and the GECK is already "flakey".) A "reference variable" is one which is used to store a "referenced record". It can be re-assigned a different "reference record" at different times (such as when an "EventHandler" is called by different triggers) or the script is called by different objects.

This is not the same as the "constant" "Ref-ID" given at the time the "record" was created, but that "Ref-ID" may be stored in a "reference variable". That variable may also hold a "Base-ID" instead as that is also a valid "reference (Form) record" value.

As I understood the OP's original question, he was concerned about creating a "framework" of scripts using somewhat "generic names" for his script variables and was concerned that other mods might also use those same var-names (accidentally). I did not read it as meaning he wanted two different Actors or Objects using the same record number.

When two different plugins create a "Ref-ID", the GECK won't let them both use the same text "Ref-ID", because they wouldn't be unique. The "Ref-ID" text name has to be unique as it is identifying a unique record number. (However, it would only know about "Ref-IDs" for plugins loaded at the same time. No idea what would happen if two different plugins managed to create different records with the same "Ref-ID" text label. The actual "record" would still be unique though.) The two plugins could attempt to make changes to a given NPC, but not to the "Form Data" at "runtime" in a script. They would have to make such changes to the Form-ID record, and then one would "win" at the game load time, or using functions like "SetAV", etc. to make dynamic changes via script at runtime.

It appears from others observations that internally the GECK/Engine turns all variables in a script into it's own sequentially numbered series of variable names linked to the script, as in (for example) "AWOPSCN001-v001", "AWOPSCN001-v002", etc. (Not saying it uses that naming convention.) In which case, the var-names will never be identical between scripts. This approach makes a lot of sense, so (this being the GECK) how likely that is, is somewhat up in the air.

-Dubious-