Posted by: AL|EN
« on: April 04, 2019, 05:50:37 AM »Well, I've been thinking you could version-stamp the copy andChanging semantic meaning of the options should not be allowed and the solution shouldn't be limited because someone would do crazy things. If a modder is facing such case, he should use new config key. New default config keys can be easy compared vs existing ones and can be copied to global config.
invalidate copies that do not match the version in the "TP3". And to
be clear, with version, I mean something distinct from the mod
VERSION. Generally, the problem with preserving copies and using them
together with future versions of the mod is that you do not know if
options have been added, or have had their semantic meaning
changed. Versioning the copy puts the modder, who is probably the best
person to make the call, in charge of when it is safe to reuse old
copies and when they should be invalidated.
I haven't thought about global copies. I suppose there could be anIf only global config exist, read values from it, if global and local config exists, read from local. It's a matter of providing standard location for reading values from config.
option of either saving the copy locally or globally.
I haven't given much thought to what people include in their modOk, manifest isn't really needed if the tp3 has all the data from manifest.
archives. I figured the manifest was obsoleted by the "TP3" file. I
don't really see the need. If it matters to something other than the
mod itself, it should be in the "TP3" or manifest file. Can you
elaborate on your concerns? Maybe I'm missing something.
Regarding concerns: zipped executable's, zipped rar's, double and tipple extra top-level directories, override&backup folders included etc. So how about:
- determine standards for 'infinity engine mod package' folder structure and content
- create tools to verify it: similar to dotnet new / puppet validate it would be 'iemp new' for creating new mod from template / 'iemp validate' to validate mod against standard
BTW: The .iemod file extension is not the good choice, it's "Infinity Engine Mod Package" , not mod definition file. So how about .iemp as file extension?
Probably not exclusive to "TP3", but perhaps implemented there
first. With TP2 I'm more or less only able to support a well-formed
subset of all possible predicates. My thoughts were running more along
the lines of "TP3" not needing any translation into a standard format,
like TP2 needs, and support of the full "TP3" set.
I'm all for tp3 but man, when? Creating new tp3 will take a lot of time, switching to the new standard will take even more time.
Even supporting subset of predicates would be better than nothing. But you still can list all of them, right? I don't understand what is so difficult to simply emit them it the way how internal parser validate correctness of tp2 file in terms of OR/AND keywords/round brackets which determine logic. Just start with including component keywords with values as a yet another JSON key and let see outcome.