Will *any* script located in the script folder fire up along with the game?

[anjenthedog]

I'm wondering if, when being uninstalled, if a mod/mod-manager fails to remove or retrograde a given script, would/could it still run independent of its "parent" mod just because of its physical placement in the scripts folder? (in my limited understanding, or ignorance, as the case may be, any scripts in the scripts folder fires up when the game does.) 

 

 

[fishburger67]

28 minutes ago, anjenthedog said:

I'm wondering if, when being uninstalled, if a mod/mod-manager fails to remove or retrograde a given script, would/could it still run independent of its "parent" mod just because of its physical placement in the scripts folder? (in my limited understanding, or ignorance, as the case may be, any scripts in the scripts folder fires up when the game does.) 

 

 

.pex files in the Scripts folder override any .pex files in any bsa if that is your question.

[Seijin8]

1 hour ago, anjenthedog said:

I'm wondering if, when being uninstalled, if a mod/mod-manager fails to remove or retrograde a given script, would/could it still run independent of its "parent" mod just because of its physical placement in the scripts folder? (in my limited understanding, or ignorance, as the case may be, any scripts in the scripts folder fires up when the game does.) 

 

 

 

If you mean "is it safe to leave unused scripts in the scripts folder if their parent mod is gone", then the answer is generally yes, so long as nothing else has scripts of the same name.

 

Note though that if you are trying to clean scripts out of a save file, it is best to make sure those scripts are physically gone.

[anjenthedog]

46 minutes ago, Seijin8 said:

 

If you mean "is it safe to leave unused scripts in the scripts folder if their parent mod is gone", then the answer is generally yes, so long as nothing else has scripts of the same name.

 

Note though that if you are trying to clean scripts out of a save file, it is best to make sure those scripts are physically gone.

Yeah, that's basically what I meant. Wasn't/"Amn't" sure if there are scripts that autorun during skyrim startup, and if a script was autorun but orphaned, it could (theoretically) be a problem.

[anjenthedog]

2 hours ago, fishburger67 said:

.pex files in the Scripts folder override any .pex files in any bsa if that is your question.

No... Not in this case... but I chewed on that thought for a minute and it has potentially similar implications. That is, unexpected behavior. (in this case, one pex running when whatever called it thinks it called the other, and if their code differs, then their result can differ too) 

 

what I meant is that for whatever hairbrained reason, I had/have it in my head that any script that goes into the scripts folder is read by skryim on game-load, and therefore, if the script contains effective "autorun" code (perhaps something as simple as a couple of otherwise innocuous nioverride commands), it will be processed, no matter if the parent mod still exists. <<< don't ask me why. it's some mishmash in my head of a hundred posts I've read talking about scripts and where to put scripts and... and very limited understanding of the game's code. 

 

 

 

Edited January 13, 2022 by anjenthedog
append

[fishburger67]

24 minutes ago, anjenthedog said:

No... Not in this case... but I chewed on that thought for a minute and it has potentially similar implications. That is, unexpected behavior. (in this case, one pex running when whatever called it thinks it called the other, and if their code differs, then their result can differ too) 

 

what I meant is that for whatever hairbrained reason, I had/have it in my head that any script that goes into the scripts folder is read by skryim on game-load, and therefore, if the script contains effective "autorun" code (perhaps something as simple as a couple of otherwise innocuous nioverride commands), it will be processed, no matter if the parent mod still exists. <<< don't ask me why. it's some mishmash in my head of a hundred posts I've read talking about scripts and where to put scripts and... and very limited understanding of the game's code. 

 

 

 

Something has to trigger a piece of code to run.  It won't just run on it's own.  However, papyrus code can be loaded in lots and lots of ways.  It can be attached to dialog, objects and actors and many other things.  But, just because it is in the scripts folder does not mean it will ever run.  So, unless the script is loaded in a save file, it will never run if the host mod is removed.

[Seijin8]

2 hours ago, anjenthedog said:

I had/have it in my head that any script that goes into the scripts folder is read by skryim on game-load

 

Read, yes (as in inventoried), but not used unless it is called upon.

[anjenthedog]

7 hours ago, fishburger67 said:

Something has to trigger a piece of code to run.  It won't just run on it's own.  However, papyrus code can be loaded in lots and lots of ways.  It can be attached to dialog, objects and actors and many other things.  But, just because it is in the scripts folder does not mean it will ever run.  So, unless the script is loaded in a save file, it will never run if the host mod is removed.

 

I'm aware that something has to call a script. I guess that part of the point. if a script call is embedded in a save file, and if said script is not properly removed during uninstallation or otherwise flagged as code-detritus for removal via falrim tools (or via regular skryim housekeeping?),  then as long a the script exists in its "proper location", it could continue to be called, right? (ie, effectively a variant on my "autorun" scenario.) 

[pinky6225]

27 minutes ago, anjenthedog said:

 

I'm aware that something has to call a script. I guess that part of the point. if a script call is embedded in a save file, and if said script is not properly removed during uninstallation or otherwise flagged as code-detritus for removal via falrim tools (or via regular skryim housekeeping?),  then as long a the script exists in its "proper location", it could continue to be called, right? (ie, effectively a variant on my "autorun" scenario.) 

 

So you have mod A that has called script B running on a save, you uninstall mod A but script B's .pex gets left lying around for a reason

 

Would think that would behave pretty much like a regular orphaned script when the .pex has been removed but was baked into the save so you'd get stack dumps/other weirdness

Edited January 13, 2022 by pinky6225

[anjenthedog]

6 minutes ago, pinky6225 said:

 

So you have mod A that has called script B running on a save, you uninstall mod A but script B's .pex gets left lying around for a reason

 

Would think that would behaviour pretty much like a regular orphaned script when the .pex has been removed but was baked into the save so you'd get stack dumps/other weirdness

That's the idea anyway. Trying to explain some "weirdness" in my game, in my case, specifically in regards to some nioverride values that keep on magically being set by an unknown "mechanism".

Edited January 13, 2022 by anjenthedog

[Seijin8]

9 hours ago, anjenthedog said:

as long a the script exists in its "proper location", it could continue to be called, right? (ie, effectively a variant on my "autorun" scenario.)

 

Yes, though likely not successfully since the properties it is trying to access would probably be from the missing plugin.  That could cause stack dumps, as mentioned, and other weirdness could ensue.

 

Without knowing what these scripts in question were actually doing, it is hard to say more than that.  If they weren't set to an event (like update) they likely would never fire, but we can't know that is the case.

Edited January 13, 2022 by Seijin8

[anjenthedog]

Yeah, that's why I choose the "simple" case of something that simply sets some nioveride value (rather than grabbing for some also removed reference or other deleted resource). Innocuous but potentially ... annoying (like random-regularly adjusting hand size to some fixed value way out of range...in my case ~1.3 scale)

 

thanks for the explanation.