AndalayBay Posted November 1 Share Posted November 1 2 minutes ago, LenaWolfBravil said: This is one of the situations when the Wiki may not be correct. We are talking about a global variable that is mod-added, so it is not going to be on any list of global variables on the Wiki, since those are from Oblivion.esm only. I would suggest to the OP, try using GetGlobalValue as in the @RomanR example. This may just do the trick. I didn't think myself that you could feasibly access the value of a global variable when you only had a generic reference that you got with GetFormFromMod, as @AndalayBay pointed out. If GetGlobalValue works for you there, you're all set. If it doesn't work... I would try to find a different way to do it. I have used both quest variables and script variables that I got from another mod with GetFormFromMod - you access them with GetQuestVariable and GetScriptVariable, respectively. So that works, but global values may be treated differently. I'm pretty sure they don't need to use getGlobalValue at all. They should be able to reference the value by simply using the name. Global variables have a lot of overhead, so they were always discouraged from use. There were some folks that did a lot of performance metrics and posted their findings on the Bethesda forums. Link to comment Share on other sites More sharing options...
LenaWolfBravil Posted November 1 Share Posted November 1 1 minute ago, AndalayBay said: I'm pretty sure they don't need to use getGlobalValue at all. They should be able to reference the value by simply using the name. Global variables have a lot of overhead, so they were always discouraged from use. There were some folks that did a lot of performance metrics and posted their findings on the Bethesda forums. You don't have the name of that global if you are getting it from a mod that isn't a master. That's the OP's premise. All you have is a reference that you got with GetFormFromMod, and therein lies the problem. Link to comment Share on other sites More sharing options...
RomanR Posted November 1 Share Posted November 1 3 hours ago, AndalayBay said: I'm pretty sure they don't need to use getGlobalValue at all. They should be able to reference the value by simply using the name. No. You can't reference something by its name (precisely Editor ID) if it's foreign origin and file which defined it isn't loaded too, even in CS. Same for Oblivion - when it loads a mod and can't find something defined, it will check mods (and only ones) defined in its Parent Master records. If it couldn't find its definition there too, it makes part which uses it invalid, even if in reality such object exists. And here is a picture what my posted script does: Access Test picture Link to comment Share on other sites More sharing options...
HautdenLukas Posted November 23 Author Share Posted November 23 Sorry for the late reply and thank you all for the tips. RomanR's solution is the one that is working. In case you are wondering what I'm trying to do - I'm using Oscuro's Oblivion Overhaul and Maskar's Oblivion Overhaul. OOO has something called "Harvest Containers" (animates containers opening/closing) and MOO does not have this implemented yet. I don't like inconsistencies in my game, so I implemented harvest containers in MOO and wanted to make it dependent to the setting in OOO, if OOO is loaded. In order to get the "OOOHC" value, I could have: 1. made OOO a master to MOO, so I could access the global value directly, but I didn't want that, because it forces the use of OOO. 2. used the "GetFormFromMod" command and this is what I did. The code part from "MOOGetGameLoadedModLoadedFunctionScript" now looks like this and does what it should: if ( IsModLoaded "Oscuro's_Oblivion_Overhaul.esm" ) set MOO.OOOloaded to 1 set tempref to GetFormFromMod "Oscuro's_Oblivion_Overhaul.esm" "04FC1B" Let found := GetGlobalValue tempref if found == 1 set MOO.OOOHCactive to 1 else set MOO.OOOHCactive to 0 endif endif It checks the OOOHC global value via form ID and stores it in a MOO variable for use in MOO. There is just one tiny problem with it. The OOO update routine runs after the MOO update routine (no, not depending on load order), so it takes two game starts for MOO to recognize a change in OOOHC, at least in my setup. But that doesn't bother me much. Link to comment Share on other sites More sharing options...
Recommended Posts