Jump to content

Packed Generic Script Names... How would the game handle them loosely?


Blinxys

Recommended Posts

Ok, so in a personal life quest to explorer structure within FO4 mods in come into this question.

 

If I unpack a * - main.BA2 file, there are three generic scripts, Form.pex, ObjectReference.pex, ScriptObject.pex.

 

How does the game differentiate these internally?

 

So for instance, if i wanted to run the several mods as loose files and were to unpack them, they all would contain these three files.

Can they be unpacked and renamed serially, associativity, moved into *.esp subfolders under scripts?

 

Honestly looking to merge them together into other mods or a combined BA2 for scripts folder but structures like this are self-limiting without distinction.

So the question is out there.

 

How does the game differentiate these (vs. loose files) internally?

Hard to believe with all these mods these three loose root files exist unchanged since 5/12.

 

 

 

 

Link to comment
Share on other sites

Thanks SKK50 keep doing what you're doing, it really works! :cool:

 

EDIT:

Took me a while to wrap my head around this issue.

 

Super Mutant Redux was the randomly selected mod in question that contained script data.

On opening the BA2 ONLY those scripts existed.

F4SE is not a listed requirement of SMR, OR AKWCR, nor does it actually do anything script-ish of itself.

 

Tests:

1) Without * -main.ba2 = CTD

2) Unpacked scripts to scripts\super mutant redux.esp\ results in missing textures\clothes.

3) Can't unpack to scripts\ main because files with name exist, and based on 1 & 2 would not be effective.

 

Conclusion:

They appear to contain indexed data for general or possibly mod specfic chargen, but they are only in there incidentally.

From provided feedback they seem to potentially cause issues, if only because they are undocumented wildcards.

 

Problem:

Starting out over my head, but have a feeling I'm going to see this more times than conceivable in various mods. :wallbash:

So...

How to re|move the generic scripts from AND preserve functionality of the main mod?

Have zero clues how to do this poking around in CK/FO4edit...

Any indications would be well appreciated. :woot:

Edited by Blinxys
Link to comment
Share on other sites

  • 6 months later...

Sorry for necro post but I just have to comment on this to find out how other people handle it.

 

I once apon a time hated this too (and made sure I cleaned my BA2 while in CK before release), but then I was forced to include scripts from F4SE for 2 reasons -

1) People never follow the F4SE install instructions to extract the pex files as well - result are my mod didn't work (because I call those Script Extensions) but people say "I did install F4SE".

2) My mod wouldn't even load if some of these script extension pex files were missing (papyrus log errors).

 

Now, my mod detects F4SE and doesn't use F4SE functions if it is not installed - so runs perfectly fine without F4SE if your game doesn't have it - but because of 2) it wouldn't start amyway.

 

So I was forced to include these. My mod now works fine on games without F4SE installed, on games with only F4SE loader exe and dlls installed, and on games with F4SE properly installed.

When a later version of F4SE comes out it's 'loose files' will override the ones in my BA2 so that won't be an issue.

 

So - my question - is there an issue in what I am doing? Given that it has no impact on Games without F4SE installed (SKK's objection - 'infecting' the game) and can use F4SE if it is?

Win - win in my option...

 

 

The original question is still valid though - is it the last mod (with duplicate files in it's ba2) the winner for the whole game, or does each mod look first in it's own ba2 first?

(ignoring loose files - which always win).

Edited by PJMail
Link to comment
Share on other sites

If you hard reference script B from script A, script A will not load if script B is not present.

 

There are ways around this using Game.GetFormFromFile(), CallFunction() and proxy classes.

The idea is to encapsulate the hard references to script B in a proxy class. The main script (Script A) then interacts with the proxy class using CallFunction, so that there is no hard dependency on the proxy. In effect, the proxy will fail to load if script B is not present, but it won't prevent script A from loading.

 

Check this out: https://www.creationkit.com/fallout4/index.php?title=Inter-mod_Communication

 

 

Including foreign script files in a mod is very bad practice, for one reason: If your mod includes Version 1.0 of the foreign script, but I've got version 5.0 installed, installing your mod will effectively downgrade that script to Version 1.0 on my install, depending on inisettings, load order and the presence of loose files. Thereby causing potential mayhem that will be extremely hard to diagnose, especially if other scripts still expect version 5.0 to be installed. Vanilla game scripts should never ever be included with a mod either, for the same reason: If you put -for example- WorkshopScript.pex in your mod, installing your mod may destroy my WorkshopFramework install and potentially corrupt my saves I make after installing your mod.

 

That's why SKK was speaking of "infecting" user systems.

Link to comment
Share on other sites

I hadn't thought of trying to Proxy F4SE scripts (or at least functions that use them) - Interesting idea...

 

Fortunately the way F4SE is supposed to be installed is loose files - which resolves the versioning issue.

The only problem I can see is if someone installs only the F4SE dll and loader, then has another mod that require the scripts (but a later version than I include).

That mod would load but perhaps not work correctly.

Realistically though that mod wouldn't have worked at all without my mod supplying the scripts - so the answer in both cases is still the same 'install F4SE correctly'.

 

In the case of F4SE I think we are arguing general philosophy, not practicalities based on this specific case.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...