Jump to content

[WIPz] TES5Edit


zilav

Recommended Posts

We could place the CC elements list in the settingsfile or another external text file. That way it could be updated without the need to recompile the program.

Link to comment
Share on other sites

26 minutes ago, Arthmoor said:

[…]

The load order ESL files use is in fact hardcoded in the exe so yes, that would be something to need to keep track of as more of them come out.

All of the above is strictly for CC content. I have not had a chance yet to see how it handles user made ESL files, but I suspect they will simply fall in after the CC ESL files right above the ESP group.

Is it possible ESL files are simply being loaded in alphabetical order by filename, between ESMs and ESPs?

After all, load order within the ESL block should not matter.

Link to comment
Share on other sites

2 minutes ago, Arthmoor said:

It appears to be alphabetical order.

They're ordered alphabetically in the Creation Kit, which sorts ESPs by timestamp with the exception of ESPs that are flagged as Masters (which appear below the ESLs and above the other ESPs, though I only have one such oddity *cough*  to go by).  Hence my speculation.

I would assume non-CC ESLs would get the same treatment.  So there may not be any need for special handling beyond that (i.e. no need to constantly track updates to the executable).

Link to comment
Share on other sites

User generated ESL files are dropping in after the CC group. I'll have to make a few more to see if they respect load order, but the CC stuff is definitely alpha-sorted. I don't imagine this is gonna be much fun for Wrye Bash either :troll:

Link to comment
Share on other sites

How about user created esm files, will they be loaded before the ESL files or would user created esm be loaded after the CC content?  Scratch that...

1 hour ago, Arthmoor said:

According to the test saves I've made, ESL files load after the final ESM file and before the first ESP file.

I think this will increase mods that is an esm, now will be a false esm such as the Campfires dev kit and the Campfires mod for all platforms.

Link to comment
Share on other sites

Since they held out the possibility for future CC content to include ESMs, that will be a thing, but I see it no different than traditional DLC.  I imagine load order will be fixed by order of release.  Some sort of configuration specification for (official) ESM files might be beneficial in the long run, if one is anticipating a cavalcade of CC ESMs (or seeks to simplify the support for new ESMs as/if they are added).

From Data File - Creation Kit (Fallout 4, and as these are edits made by Arthmoor in the past few days it may be evolving info)

Quote
  • .esl Files released by Bethesda Game Studios (Creation Club releases) are flagged as master files and will load with the .esm files. Creation Club releases will automatically load into the game whether they are activated or not, and load before any .esm based mods made by modders.
  • .esl Files released by Modders are flagged the same as .esp files, but these ALSO load with the master files, but they will load in the order specified in plugins.txt. These .esl files will need to be activated before the game will load them.

So I'm assuming user-created ESL files will follow plugins.txt order, AFTER the CC ESL files load (after ESMs), and BEFORE ESPs.

How to order a user-created ESL file that does not appear in plugins.txt?  I imagine by timestamp, but placed after any (user-created?) ESM that might appear, and before any ESP.

Would official ESMs and CC ESLs ever appear in plugins.txt?  Would the game just ignore 'em?

Link to comment
Share on other sites

Just logged in at Bethesda.net and read this post, in fact the whole thread is interesting to read.  Is it true that master files cannot be disabled in SSE after being updated to the 1.5 patch?

Link to comment
Share on other sites

Ok. Just so this is straight now. Here's the deal after testing with the dev version of Wrye Bash with the save headers fully visible.

The order goes like this:

* Original 5 SSE master files - hardcoded load order. Cannot be changed.

* Standard ESM files generated by users. In whatever order they are specified in plugins.txt. ESP files flagged as ESM files are treated the same.

* CC Content flagged as master ESL files. Files within this segment are sorted alphabetically. This is hardcoded.

* User generated ESL files flagged as masters. Loaded in the order specified by plugins.txt.

* Standard ESP files. Loaded in the order specified by plugins.txt.

* User generated ESL files NOT flagged as a master. Loaded as specified in plugins.txt.

  • Like 3
Link to comment
Share on other sites

Yes, annoying, cause it'll cause them to load after the bashed patch (once such a thing is possible).

Link to comment
Share on other sites

I am pretty sure it was Hlp that mentioned what happened at runtime.  So while everyone here is trying to figure out how to handle them, have you considered that you can't handle them?  Look at it this way, do you handle your save game?  Do you handle FF or FE?  Do you think LOOT or Wrye Bash will sort them at FE?  What... how... are people even coming up with this stuff?  How do you expect to make the game to do what YOU want. ESL files load at FE.

if IsESL (* as in flags bit 9 is set *) then begin
 baseID = formID and 111111111111b; (* yes that is only 12 bits *)
 fileID = formID or 11111110000000000000000000000000b; (* modIndex $FE *)
 eslID = eslLoadOrder shl 12
 formID = fileID + eslID + baseID;
 (* mmmmmmmmeeeeeeeeeeeebbbbbbbbbbbb *)
end else begin
 baseID = formID and 00000000111111111111111111111111b;
 fileID = formID or  11111110000000000000000000000000b; (* modIndex $FE *)
 (* mmmmmmmmbbbbbbbbbbbbbbbbbbbbbbbb *)
end

 

Link to comment
Share on other sites

7 hours ago, Arthmoor said:

Ok. Just so this is straight now. Here's the deal after testing with the dev version of Wrye Bash with the save headers fully visible.

The order goes like this:

* Original 5 SSE master files - hardcoded load order. Cannot be changed.

* Standard ESM files generated by users. In whatever order they are specified in plugins.txt. ESP files flagged as ESM files are treated the same.

* CC Content flagged as master ESL files. Files within this segment are sorted alphabetically. This is hardcoded.

* User generated ESL files flagged as masters. Loaded in the order specified by plugins.txt.

* Standard ESP files. Loaded in the order specified by plugins.txt.

* User generated ESL files NOT flagged as a master. Loaded as specified in plugins.txt.

Wonderful, they couldn't make it more complicated, could they? I really dislike this hardcoding of CC plugins, you know it's going to mean we all need to update everything further down the line...

When I did my own research, I didn't pick up on the master flag affecting ESLs, do master-flagged ESLs still have their FormIDs loaded at FE/FF, or do they go somewhere else? I also found that ESLs get treated like ESMs (they go before ESPs in the CK, for example) even without the flag. Granted, my findings are a month old and things might have changed since.

Also, I'm finding myself a bit out of the loop about these things, should I just be checking this thread, or are there other places too?

11 hours ago, zilav said:

Official DLC files are finalized and likely never going to change, so hardcoding them is fine. But constantly updating CC... What'll happen if me and hlp will stop updating in the future for some reason, but CC will still be going on. I don't like that.

Well there is option 5. Detect if LOOT is installed and optionally use it's API to pull load order, it's plugins list is at least updated by community and unlikely to be abandoned any time soon. Though I don't know about the current state of LOOT API, anything new @WrinklyNinja?

I'm working on updating it for Bethesda's latest shenanigans, but frankly chasing after them is proving to be very little fun and is making me wonder if I shouldn't just throw in the towel and let this nonsense be someone else's problem. While the LOOT masterlists are community-maintained, the code is pretty much just me, and this low-level load order stuff is all code (my libloadorder library, to be precise). It wouldn't be difficult for someone else to pick up and maintain, but it does have a higher bus factor.

Maybe I'm just grumpy because I haven't slept much this week though...

Link to comment
Share on other sites

23 minutes ago, Sharlikran said:

I am pretty sure it was Hlp that mentioned what happened at runtime.  So while everyone here is trying to figure out how to handle them, have you considered that you can't handle them?  Look at it this way, do you handle your save game?  Do you handle FF or FE?  Do you think LOOT or Wrye Bash will sort them at FE?  What... how... are people even coming up with this stuff?  How do you expect to make the game to do what YOU want. ESL files load at FE.


if IsESL (* as in flags bit 9 is set *) then begin
 baseID = formID and 111111111111b; (* yes that is only 12 bits *)
 fileID = formID or 11111110000000000000000000000000b; (* modIndex $FE *)
 eslID = eslLoadOrder shl 12
 formID = fileID + eslID + baseID;
 (* mmmmmmmmeeeeeeeeeeeebbbbbbbbbbbb *)
end else begin
 baseID = formID and 00000000111111111111111111111111b;
 fileID = formID or  11111110000000000000000000000000b; (* modIndex $FE *)
 (* mmmmmmmmbbbbbbbbbbbbbbbbbbbbbbbb *)
end

 

Well we're trying to figure out how to handle them because like it or not, they need to be handled somehow. We can't just ignore them. The save headers are quite clear on where the game is storing the information so it seems logical to at least display this to the user on the load order the same way.

I am fully aware that at runtime this is all effectively meaningless since ESL files all occupy the FE load order slot. Which raises a few small concerns of it's own given that FE was previously a valid slot to stick a normal mod and may no longer be treated as such by the game.

@WrinklyNinja Right now I don't know if master flagged ESLs are doing the same with the FE slot but I have little doubt that they must be or the system would be untenable. I've tried to keep my findings on this forum at the very least but as you can imagine it hasn't been easy to pin this stuff down completely. The simplest thing I can think of is that the FE load order slot should simply be declared off limits in the same manner FF is now.

Link to comment
Share on other sites

The placement of the file in the Save header is arbitrary. Bethesda just added a count and a list of file names.  The fact that they are after the esp and esm files is because Bethesda had a task to accomplish.  It's not "How" they are sorted.  You see it as they are sorted after the ESP and ESM files. I see it as, "I'm making a feature for consoles and we just need a place to put the file names in the header, any ideas guys?"

Link to comment
Share on other sites

@Arthmoor I mentioned over a month ago that ESL files should be sorted (although it doesn't matter) after the ESM files. For programming reasons. They have the ESL flag, and official files have ESL and ESM flags. So from a programming standpoint it's silly to put them after ESP files.

Link to comment
Share on other sites

@WrinklyNinja I have not tried any of your betas for handling ESL files. I don't think they should have a number (01) or symbol in the load order since their placement doesn't matter.  If you have the DLC loaded you will just end up with this anyway.

  • 00 Main Master
  • 01 Some Master
  • 02 Some Master
  • 03 Some Master
  • 04 Some Master
  • 05 Some ESP
  • 06 Bash Patch
  • FE ESL Plugins merged at runtime.

Or at least that's my understanding anyway.

Link to comment
Share on other sites

IIRC, what the save header means is that esls are treated as a bunch as far as the save file is concerned. Now where this bunch belongs in load order is a mystery

Link to comment
Share on other sites

6 hours ago, Utumno said:

IIRC, what the save header means is that esls are treated as a bunch as far as the save file is concerned. Now where this bunch belongs in load order is a mystery

How is it a mystery? It's arbitrary. Excluding user created ESL files, official ESL files are hard coded and load in a specific order if I'm reading all the comments correctly. However, to me there is no difference. Do you honestly think Bethesda will make a routine to load all the official ESL files in one way and the user created files in another way? They might load official content first, but that's about it.  They aren't going to do utilize some mysterious vodoo mojo magic.  If I understand Hlp's comments they load at FE. Where you put them is purely cosmetic. You can put them after the ESM files, you can put them before the ESM files, you can put them at the end of the ESP files. Visually it will be whatever is most pleasing to your eyes. Because at runtime, where you saw them in Wrye Bash or LOOT isn't where the game manages them.

Furthermore you could assign them a load order number, if you like but it won't matter because they will be at FE when the game loads.  Again if I understand what is being said.  I just barely downloaded a mod and it's survival mode. I would have to make my own armor mod if I want a mod that adds armor or something that I can track through the console (in game because you may have never used player.additem) using "help" to lookup the FormID.

But don't forget they should be ignored when making a Bash Patch.  Don't merge the leveled lists, the armor, or anything about them into the Bash Patch.  Now if programming wise that isn't trivial then that may be the answer as to what to do with them.  If you will have a hard time with the backend code then sort them after all esm/esp files.  Not like how LOOT would assign them a position in the load order like 0A, 08, 2C, but I mean unnumbered, sorted according to what is hard coded in the EXE, and after all the files that are in the Data folder that aren't ESL files. If you think users will be confused by not having a load order number then you have to choose to continue from the last mod in the list or assign them all FE.  Which will be least confusing to users?  People do load up the console and add items in game. If they see it as 1F and the type "player.additem 1F034EF4 1" to add 1 sword then the game will error saying it's not found.  If everything loads as has been explained then "player.additem FE034EF4 1" would be the correct way to add the sword.

I just realized I have my God Armor mod that I can convert since it uses all Bethesda assets.

Link to comment
Share on other sites

Expanding on hlp's idea ..

23 hours ago, hlp said:

We could place the CC elements list in the settingsfile or another external text file. That way it could be updated without the need to recompile the program.

.. is there any possibility that such a file, a (text)file containing the hardcoded CC-.esl-filenames, could be used by all of the important third party tools (maybe even for both games: FO4 and SSE)? To be precise, I'm thinking of xEdit, LOOT, Wrye Bash as well as Vortex (and possibly other tools as well, if they so desire). New impending rules for load order put aside for a moment, the reality of the Creation Club is, that all the tools (and as such their creators) need to account for these new hardcoded files, and as has been discussed, it isn't very reasonable to expect that even one dev of said tools will happily add them and update his/her tool accordingly forever.

Given that it seems to me that such a "community supported" file containing CC .esl filenames would be in the best interest of everyone.

Edit: IF this would be a possibility, the question would be, of course, how such a file could be distributed between the tools.

Link to comment
Share on other sites

8 hours ago, pStyl3 said:

.. is there any possibility that such a file, a (text)file containing the hardcoded CC-.esl-filenames

I'm still leaning towards autodetection of CC mods. The presence of Localized flag itself already filters out almost all custom mods because absense of strings files for some language crashes the game and hence custom mods very rarely use that feature, and doing additional regular expression check on plugin name (starts with "cc", has "-" char in between) pretty much guarantees no false positives unless someone decides to trick that on purpose.

If such hardcoded names file is ever going to be used, it'll be optional I think.

Link to comment
Share on other sites

Load order of (user-generated) ESL files most certainly does come into play.  Create one ESL ("Dragonbane X.esl") that renames Dragonbane to "Dragonbane X".  Create another ("Dragonbane Y.esl") that renames it to "Dragonbane Y".  Ensure that both are in Plugins.txt and active.

If "Dragonbane Y.esl" appears after "Dragonbane X.esl" then your Dragonbane will be "Dragonbane Y", every time.  It's not arbitrary.  It's load order.  It's not a function of structure, it's a function of time.  Skyrim doesn't just take all the ESLs in a bunch and start randomly flinging them off to separate threads for maximal chaos.

Place both of those "Dragonbane ?.esl" files above USSEP in Plugins.txt and you'll find that USSEP's override for Dragonbane wins out and your Dragonbane will be "Dragonbane".

(If you try to position them below any ESP that is not also flagged ESM, the game loads ESLs before normal ESPs so the ESP will always win out.  Things apparently get a little weird and whacky when you give the ESL a normal ESP as a master, however; the ESL will of course load after any ESP it has as a master, it's just when that ESP itself now loads that's apparently fun).

@zilav I like that approach.  I'd not even considered "Localized".  The file names seem to be 'cc' + 3 alphanumerics denoting (primary) development team (e.g. 'bgs' for Bethesda Game Studios) + 3 alphanumerics denoting game (e.g. 'sse' for Skyrim Special Edition) followed by '-' and the rest of the name.  All lowercase.

If someone wants to "trick" the tools, it's on them.  (I also wouldn't put it past Bethesda to buck their convention and come up with completely arbitrary names for future CC ESLs.)

Any tools that can could also always just provide the option for a user to flag a given file as CC content, thus shuffling it to wherever/however it is decided to present/handle such content.

I definitely prefer a reasonable autodetection.  i r laze

 

Edited by Nukenin
Dragonbane, not Dragonbone, ya bonehead
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...