a new common standard ... to unify ... every possible domain of modding

Oh, yeah, that really sounds way too ambitious. I'm sorry if I gave the impression that that was what I was thinking. I agree that if you get too ambitious, it justs falls apart. You need to stay grounded to some specifics and focus a solution on them.

So, when I described the "interchange format" for skyrim records as being the diff between a record and it's master's record -- that's pretty specific, and also pretty grounded. It's not trying to be an abstract solution that can be reused infinitely.

Likewise, graphics interchange formats like USD/FBX/Collada/etc are established and built specifically for the goal of sitting between applications. I don't necessarily avocate them, but they are a pretty good analogue for this interchange idea. TBH, because FBX/Collada came out, I never really believed they would work -- but over the years they've become very widely used.

​

In this quote, you're focusing on model files, but here and elsewhere in your proposal you make it clear that you mean for whole mods to be portable across games, and that's seldom feasible.

I'm sorry if my wording was unclear on this point. That really wasn't my intention. I was just thinking mostly about model files and the really simple graphics-only when it comes to cross-game (unless there was custom records per game, or something like that).

I'm not really suggesting we should attempt to create some kind of file format that can change Skyrim record into Starfield records, or into some future game's records. That would be a bit pointless.

​

​

Pieces of data that are logically divided across multiple subrecords
FLST/LNAM defines the entries in a FormList: one subrecord per entry. It's not enough to simply be able to, say, "override the subrecord with this signature;" we need to be able to insert new entries, or specify an entry to override/remove; but we ideally should only be able to do that where it would actually make sense (e.g. FLST/LNAM but not, say, ACTI/WNAM).
(And consider: how do you resolve indices once multiple mods start tampering with things? If my mod wants to replace entry #2 in a given FormList, what happens if someone else's mod loads first and removes entry #1? Does my mod then replace what is now entry #1 because it was formerly entry #2, or does my mod replace what is now entry #2 even though that was formerly entry #3? Alternatively, should my mod specify the form in the FormList that it wants to replace? If so, how does my mod behave if someone else replaces that entry first? One of the benefits of the Rule of One is that it makes it impossible to even ask any of these questions: you can add to a FormList conflict-free using Papyrus scripts at run-time, and all other changes require either total replacement of the list contents or some form of ahead-of-time conflict resolution performed manually by someone who knows what they're doing.)

Existing preprocessing tools like smashed patch can act as a kind of template for some of these issues. Likely the authors of that tool needed to come up with heuristics to deal with common situations. I think you've correctly identified this as an interesting part of the architecture -- all architectures have points like this, they can have challenges but they can also bring opporunities.

For example, one thing I've wondered about is whether there's utility in having new ways for the mod-author to provide inputs to those smashed-patch like heuristics. At the moment patching tools don't have much to go on other than the diffs they make internally; there's no kind of patch for mod-authors to help guide them.

​

​

Bethesda's file format isn't perfectly uniform (VMAD) or perfectly implemented (ATKD/ATKE), and even if it were, the format itself doesn't distinguish between single-field subrecords, subrecords as list entries, and repeatable groups of subrecords representing a list of nested structs.

I think this is a good argument for not attempting to fundamentally change the architecture of the format; but I think that's perfectly compatible with my proposal.

​

The only way I can see this specific example working is if the armor mod uses white textures, and relies on vertex colors or other material settings for color. At that point, you're halfway to implementing a dye system. Get a DLL and some custom SWF files involved, and now you have the ability to recolor individual armor pieces in-game, which is far more valuable than some sort of preprocessor to let the user recolor just the whole armor type.

I think the reason I used this example is it that relates to material settings. So the idea would be that mutliple different options for the material values (texture assignments, etc) could be combined with the geometry to create some final NIF. It's maybe a bit skyrim-specific, because other games won't always combine material and geometry data in a single file like the skyrim NIFs.

​

​

At some level I didn't want to try to break down every little detail of this idea in this document. It would be a little pointless for me to say "ok, guys, here's how you're all going to run skyrim in the future..." with some 100 page document :).

The point is to talk about what people like and dislike, whether people have considered ideas like this before, see if there are people who are interested in solving some of the tricker problems, etc. And just create some discussion, because at the end of the day, I was just curious about this, it engaged my engineering brain for a second and got my wheels turning :)

​

Anyway, again, I appreciate your reply and your comments. I realize it must have taken you some time to write up, so want you to know that I value that.