Least costly way to use variables for this script ?

[csbx]

I have a script attached to a quest that checks to see if a mod is installed. It uses Game.GetFormFromFile. I've selected, e.g. the formid of the cell added by) the given mod and used that # for the check.

What I'm then doing is assigning a global variable = 1 IFF the check is not NONE (ie. doesn't find the form).

I then use this GV in a condition for a dialogue that may be repeated.

All seems to be working thus far.

My question is, I'm running this function (ie. check to see if these mods are installed, if so, assign the corresponding global variables to 1 if they are) every time the dialogue runs and just before the dialogue with the conditions, so there's no real need to store these global variables in a save file.

I'm very very new to scripting and just want to know if there's a less costly way to make this work. Do they have to be global variables ? And is there a way to avoid saving this to file given that it's not needed ?

edit: I guess it has to save somewhere to apply to the condition but only temporarily...

Edited March 3 by csbx

[scorrp10]

You generally do not need global variables.   One benefit of a global is it is easy to check or set via console.  However, a global does use up a FormID in your mod.

If your mod has a running quest, and that quest has a script attached, all the variables in that sript instance are persisted.    

What you can do is flag the script attached to your quest as Conditional.    Then, you can flag properties within that script as Conditional.  These properties can be checked in dialogue and other conditions.

Good read:

https://tesalliance.org/forums/index.php?/topic/5039-class-2-properties/

 

[xkkmEl]

For the amount of memory involved, you should not worry.

You could use a quest script property instead of a global:

bool property ModFound = False Auto Conditional

And then test it with a "GetVMQuestVariable" condition in the dialogue.

You also need to make your quest script conditional (add the keyword Conditional at the end of the very first line)

Script myQuestScript extends Quest Conditional

 

[csbx]

Cool - I've moved some of my variables from using globals to using conditionals and getvmquestvariable in the way you two described. Thanks - definitely learned something that would have taken hours to find on my own !

Another question. If I use Game.GetFormFromFile and pull the ID# from e.g. a unique cell that the pertinent external mod adds to the game, is that generally a safe ID# to use ? If some other mod edits that cell, will the ID associated with the cell change ? Is there a more persistent / safe thing to pull from ?

[xkkmEl]

ObjectReferences are tricky: not always in RAM, subject to deletion, etc.  Other forms should be fine.  Quests are the standard choice.

I have little experience with cells but I expect them to be fine for your purpose.

 

[IsharaMeradin]

If you are not using SKSE, then you can use any form ID found in the target plugin if all you are doing is checking for the presence of the mod itself.  If, however, you want to work with the object then you'll need to use the ID of the desired object and cast it appropriately to store within your designated variable.

Record ID #s do not change. But an author might delete a record you have been relying on within an update and thus your mod won't find what it has been looking for.  It is rare, but it can happen.  If you use GetFormFromFile and a target mod updates, you will should double check the target mod to ensure that you are still pointing to a valid object.

If you are using SKSE functions / events within your project, you can use GetModByName instead of GetFormFromFile.  This returns the load order index of the mod in question or 255 if it is not present.  With this you do not need to worry about using a valid form ID.  But, you will still need to check that the target mod did not change its plugin name during an update (this is rare but has happened too).

[scorrp10]

Yes, I always do 'GetModByName'  call before trying to pull any forms from a mod.    

As to which form to pull - the answer is:    the one you will be using.    The most common form obtained is the primary Quest of that mod, the one that is start-game enabled, and generally holds all the relevant properties.    But for example, the target mod applies a change to a set of weapons contained in a FormList.    Then I directly pull that FormList if I need nothing else.    If you just want to ascertain a mod presence, use GetModByName. (or GetLightModByName) 

[csbx]

Thanks. I chose the cell to draw from because the mods I'm checking are dungeon mods--their purpose is adding a given cell. I'm not planning on working on any objects within these mods--just making sure they're present.

SKSE is too advanced for me at this point. Gotta graduate from modding kindergarten first. It's tempting, though, seeing these additional functions available.

 

[scorrp10]

2 hours ago, csbx said:

SKSE is too advanced for me at this point. 

No, it is not like that.   Yes, there is the whole thing about writing SKSE plugins (.dlls)  where you need to code in C++, know your way around VisualStudio and all that.    I did get my feet wet a bit, and managed to put together a plugin that would properly register and did some basic stuff, but I generally prefer to stick to Papyrus.    But that is not what is being talked about here.

What Ishara means by 'using SKSE' is simply taking advantage of additional Papyrus functions that SKSE provides, in your scripts.      

I.e. if you look at Actor script in the wiki,   it  lists the vanilla member functions and events implemented for the type, but also lists the added SKSE  functions.    I.e. if you have SKSE, you can use functions like IsSwimming()  or  SheatheWeapon() on Actor objects in your scripts.

 

[csbx]

On 3/4/2024 at 11:27 PM, scorrp10 said:

No, it is not like that.   Yes, there is the whole thing about writing SKSE plugins (.dlls)  where you need to code in C++, know your way around VisualStudio and all that.    I did get my feet wet a bit, and managed to put together a plugin that would properly register and did some basic stuff, but I generally prefer to stick to Papyrus.    But that is not what is being talked about here.

What Ishara means by 'using SKSE' is simply taking advantage of additional Papyrus functions that SKSE provides, in your scripts.      

I.e. if you look at Actor script in the wiki,   it  lists the vanilla member functions and events implemented for the type, but also lists the added SKSE  functions.    I.e. if you have SKSE, you can use functions like IsSwimming()  or  SheatheWeapon() on Actor objects in your scripts.

 

Thanks so much for clarifying--totally opened some doors I didn't notice.