Are you planning on a single order (like Big World) or on a more flexible system (liked the mlox)?
You should probably try to seperate that part (if you're going to do it) into a seperate data driven tool, with a command line (addictional) interface - because it'd be useful by itself, and because it needs to be updatable regularly by non coders.
I was thinking of doing a "mini programming language" for that, but i'm not not rock solid (kinda mushy in fact) on the theory of how mlox does things. I mean it uses a sorting process that assures termination.
And
BG mods are more complex than morrowind ones : the mod sorter would need to sort components instead of mods: because most components can be installed optionally, and yet, it better minimize "movement" or components from other mods going into the middle of a sequence of another: more chances for bugs, slower (because
weidu has to start again) - another complexity is that
BG mods often have user input. We can put some default values there, but need a way to override those and at least in one mod the user input depends on the mods installed (Level1NPC's). Morrowind mods use a horrible "game config objects" system at play-time.
Things it would be cool for this tool to have:
The understanding and using the rule file to output a mod order (obviously)
a library of md5's of the mods versions (to detect a "new/edited" and warn (ask to the user what mod it actually IS if not recognized, because filenames are a really bad way to identify mods), to detect outdated versions and warn/ask for update)
Autoupdate rules from a shared file. Either from a wiki, or from a git repository or something.
Sharing a mod list with edited user input options and auto install of that (fool proof mode of installation).
Revert part of a install, update a mod and reinstall the rest. Not sure,
weidu already does this for removal right?
Things that probably belong on the main app:
download and extract files to the
bg dir (a big mess because
BG modding never standardized on only one compressor tool or folder structure).
GUI for selecting the components to install; possible components queried from
weidu (and that would be feed to the other tool/library).
Checking if the
BG install is ready to install mods?
Questions:
What should happen if the user is using a old mod version but there is a new one on the rules. The rules may have new constraints that didn't apply to the old version, or had rules deleted that don't apply to the new version. Would this system force everyone into the "bleeding edge" or force the use of Tuples of "mod order list, rule file version) to be able to use the set of mods? And if you only want to update one mod but not another it wouldn't work? It seems a difficult problem to work out perfectlly, maybe if we introduce qualifiers to the rules:
@since version (md5 value)
@previous version (md5 value)
or something like that?
Edited by i30817, 14 March 2012 - 06:03 PM.