3 replies to this topic

[GammaLeak]

Morrowind has a tool for making sure that all of your mods are loaded in the correct order. It's called mlox (although you pretty much have to use it in conjunction with another tool, Wrye Mash). mlox will also warn you if you have two mods colliding with each other and causing incompatibility issues. For total n00bs (like me and most people) it's a super helpful tool for avoiding problems.

Would such a tool be helpful for Weidu mods? Or are there relatively few incompatibility issues?

Even if such a tool would be helpful, is it realistic? I actually know next to nothing about IE modding and Weidu. But the little I do know suggests a possible avenue of attack for such a tool. For instance:

• Tool analyzes a group of .tp2 files to determine if there are any files that more than one mod changes/overrides
  
• Assuming that multiple non-conflicting changes can take place to a single file (big assumption on my part, I don't actually know), the tool then analyzes the changes and looks for any conflicts.
  
• If a conflict is found, the tool tries to determine which one is the "preferable" change so that it can order the mod installation appropriately
  
• If there is no "preferable" choice between two conflicting changes, the tool alerts the user that the two mods are incompatible and asks them to choose only one.
  
• Once mod order is established, tool spawns off setup-modname executables in serial until the entire list has been installed.

I'm not 100% sure I really have time to research and create such a tool, but if there's sufficient need I'd probably start dabbling at the very least.

[Wisp]

In my (possibly pessimistic) estimation such a scheme would be infeasibly complex. TP2 has a bunch of operations that would be difficult to analyse in that manner; everything from copying files matching some regexp to copying the file given by the evaluation of some variable (which may have been set anywhere in the TP2 file or in its dependencies).

i30817 was working on a rule-based approach to mod orders (foo depends on bar but must be installed after baz and is mutually exclusive with quux, and so on), but I am uncertain of what the status of that initiative is today.

[i30817]

Indefinitely stalled because of terminal laziness. And since Big world was chugging along i didn't see the need.

The idea is exactly like mlox: take stuff out of hardcoded mod orders (like previously in morrowind, or Big World currently on the BG series) and into atomic precedence rules that would warn you when things are about to go wrong and suggest a computed "compatible mod order" (in this case, component order).

Advantages:
0) more configurable (or to be exact: able to deal with more variation on the installed components - after the incompatibilities are found and the rules written)
1) it would be less of a effort for the end-user
2) it could (probably...) be extended into sharing/installing a mod order anyway.
3) it would get away from bat files into a portable program. Well, if all the mods behaved without hacks at least, which i doubt.
4) because of 3 and of explicitness of the rules (the cause of them) i expect it could be more maintainable.
5) it would be faster installing since, it could "join up" invocations of Weidu. You know how the big world bat file is full of "if X install mod A.C otherwise install mod B.A then install mod A.D" ? If mod B is not to be installed, all continuous components of mod A can be installed at once. This is more of a issue in wine i expect (where WeiDU takes forever to start installing a mod).

So-so:
1) it seems as complex (if not more) than the approach of Big World for the maintainers: lots and lots of rules. mlox rule database is 936 KB
2) to be able to auto-update/download mod packages there would have to be a "standard package" instead of the 3-4 competing autoexec extractors currently used. Soooo... i don't think it will work for that without drifting into a lot of code (like BGTSetup) - but it's a good opportunity for it, since if it needs encoding auto updated rules anyway - why not put the links there?

(Potentially) bad:
1) Once you let go of a hardcoded order some certainties go away and some hidden assumptions derived from the current Big World install order could be invalidated - leading to new and exciting problems until the underlying assumption can be encoded into the rules/bug fixed.
2) Everyone's order could be different (maybe not if the same mod components, i'm not quite up to speed on sorting theory, so i'm not sure if the topological sort could be stable -> same input, same order). People don't install the same mods even with Big World, but allowing "different components options" (unlike Big World now) would lead to more fragmentation.

I've read that Big World lost it's maintainer... well.

Edited by i30817, 18 February 2012 - 10:07 AM.

[neird]

Ended up writing one for myself to work like this:

ie-setup --language=english --type=wine --size_x=1280 --size_y=768 --dir=bg1 --setup << EOF_BG1
use standard, fixpack, ub ;
#bg1, bg1ub autoinstalled
game bg1totsc ;
EOF_BG1

ie-setup --language=english --type=wine --size_x=1280 --size_y=768 --dir=bg2 --setup << EOF_BG2
use standard, fixpack, ub, widescreen, bw-fixpack ;
#bg2, bg2fixpack, ub, widescreen autoinstalled, bwp patches autoused
game bg2tob ;
mod bgt 0 input "bg1" ; #version 1.12
mod bg2_tweaks 0 120 1080 1140 1160 1170 1180 1220 2090 2120 2170 2192 2240 2250
			   2261 input "a" 2271 input "a" 2281 input "a" 2294 3000 3010 input "b" "a" 3183 3200 ;
mod itemupgrade 10 11 ;
mod gui match "Elminster wielding staff" ;
mod bgtmusic match "Baldur's Gate Trilogy - Music -> Hybrid" ;
EOF_BG2
rm -fr bg1

with 'use' files containing dependency info like:

game bg2tob requires and recommended by game bg2 ;
mod bg2fixpack 0 2 3 100..115 1000 1001 requires game bg2 or game bg2tob ;
game bg2tob recommends mod bg2fixpack 0 1000 ;
mod bg2fixpack 0 forbids and required by mod bgt 0 ;
game bg2tob and type wine recommends mod widescreen 0 input "$size_x" "$size_y" "Y" ;
mod ub 0..24 requires and recommended by game bg2 ;