EnablePlayerControls has bugs

[IntenseMute]

Edit: Made a mistake, no bugs here!

 

 

Just thought I'd post this bug I discovered with the function EnablePlayerControls and SetUIFloat.

 

If a mod uses the function EnablePlayerControls to enable the RolloverTextFlag...

EnablePlayerControls 0 0 0 0 0 1 0

...and another mod higher in your load order uses...

SetUIFloat "HudMainMenu\..............\visible" 0

...the function above will do nothing.

 

 

 

 

 

Note 1: SetUIFloat must edit a child of HudMainMenu and must be editing the visible trait to 0

 

Note 2: No matter what Vortex/Loot displays your load order to be, what really matters is the Date modified info that is stored within the ESP files. That is what decides whether this bug will occur or not.

Edited July 26, 2019 by IntenseMute

[dubiousintent]

Interesting. The implication being that making an edit to cause the internal modified date of the plugin with the "SetUIFloat" function to be later (regardless of position within the LO) will resolve the issue? Or has that not been tested?

 

-Dubious-

[IntenseMute]

Alright, I did some more testing and found out that this is no bug.

 

I didn't realize that both mods had the same quest priority and quest delay, which made it so both functions would run on the same frame everytime. This is where the load order decides what mod gets what priority (The ESP that has the higher "Date Modified" date will have a lower priority which makes the script execute last within that frame).

Edited July 26, 2019 by IntenseMute

[dubiousintent]

Still interesting information. That is the sort of subtle interaction that can cause much consternation and hair pulling. (Now to figure out how best to convey it. Leaning towards a "Scripting" TIP in the wiki "Getting started creating mods using GECK" article, but I'll wait a bit in case you turn up something else.)

 

-Dubious-

[IntenseMute]

Literally wasted about 4 hours trying to figure out what was going on, the real hair puller was not knowing that one of the issues lied within the "Date Modified" info, everytime I would edit and save the ESP with the GECK, the problem would be solved which made me think that what ever I just edited was the problem, but what was really going on was the "Date Modified" info was just getting updated to todays date (Which gave it a lower priority), and the problem would reappear when Vortex reorganizes the load order (Which edits the "Date Modified" info back to what it was).

[dubiousintent]

the problem would reappear when Vortex reorganizes the load order (Which edits the "Date Modified" info back to what it was).

That statement implies the issue is Vortex specific. Did you confirm that the Windows file "modified" date was different from the internal plugin header "modified date" after you save your changes?

 

I don't use Vortex myself, but would be really surprised that any manager would "reset" either modified date. What I do know about Vortex is that it works from an "empty Data folder" design and uses "symbolic link" references in the Data folder instead of actually copying files. So the next session would be getting a new symlink pointing to the install location of the plugin and placing that into the Data folder. My assumption would be that Vortex is only using the external file "Date modified" info instead of the internal info. If it isn't, that has other implications as well.

 

The GECK predates the use of symlinks by mod managers, so it logically will be "old school". As long as it uses Windows APIs things should be fine. However, if it by-passes the file I/O APIs at any point, then it is possible unpredictable things can occur. (Always bearing in mind that the GECK is a Vault-Tec experiment. :devil: )

 

You might want to try the experiment of actually copying the files needed by a GECK edit directly into the "Data" folder to see if that makes a difference in the result. (Of couse if it does, then you will need to copy the updated files back to their install location so they get properly used in game sessions.)

 

-Dubious-