The batch files also need to be fixed. Just so you know I pulled down 0.55 40 minutes ago.

I just pulled down mlox and I'm not having any luck getting the command line parameters to work. I went ahead and deleted mlox.bat so I could guarantee I was running mlox.exe. When I'm in a DOS prompt and I run mlox, the GUI pops up. However, doing things like 'mlox -h', 'mlox --help', or 'mlox -c' do nothing. They just return me to the command line. The mlox.err file is empty. Do command line options not work with the exe?

The .bat files, unfortunately due to a Makefile oops, didn't get updated in the archive, but the correct ones should be there in a future release. I believe they should still work though. The important update was for the .txt files, to make sure that they are readable.

Currently the command line mode should work for the .py version but not the .exe version. Sorry, I should have documented that. Building .exe's for Python is a little funky, and I thought that since most .exe user's would only want the GUI mode, I built it so that it doesn't run in console mode.

I see something potentially wrong with your "definitions" or whatever they're considered to be- Piratelord says that his Trade Enhancement mod should be one of the last to load (only loading before Merged Objects and Leveled Lists), but mlox just proposed a load order that puts it waaay up near the top. I'll try it again later but you might want to look.

I'll see what I can do for PTE. Adding it to the global [Nearend] rule should work, but it becomes problematic when a number of mods say they want to be near the end of the load order.

The best solution is to find out what plugins PTE should follow and add [Order] rules for that. Unfortunately, I just don't know this and no one has submitted any info on this yet.

Edit: Okay, here's a new update of the rule-base that puts PTE in the Nearend rule:
mlox-data_2009-03-16a.7z
http://code.google.com/p/mlox/downloads/list

I hope that gets PTE closer to where you expect it to be in your load order.

Okay, thanks. I was hoping I didn't overlook something int he README.

I thought about a possible enhancement for the command line version. When you specify -e, it would be nice if you could just give it the number from your load order instead of having to type out the name of the ESP.

When I ran it against this very small load order:

GameFile0=Morrowind.esmGameFile1=Tribunal.esmGameFile2=Bloodmoon.esmGameFile3=Morrowind Patch v1.6.4.esmGameFile4=Book Rotate.esmGameFile5=DisableVanityCamera.espGameFile6=Vality's Bitter Coast Addon.espGameFile7=Expanded Sounds.espGameFile8=Bloated Caves.espGameFile9=Graphic Herbalism.espGameFile10=Graphic Herbalism Extra.espGameFile11=GH_ES1.3 Patch.espGameFile12=GH_Extra_ES1.3 Patch.espGameFile13=mge_kelp_remove.espGameFile14=turn_off_artificial_light_from_seaweed.espGameFile15=turn_off_artificial_light_from_mushrooms.espGameFile16=Better Bodies.espGameFile17=RealSignposts.espGameFile18=Book Rotate - Bloodmoon v5.3.espGameFile19=Book Rotate - Tribunal v5.3.esp

It told me I should move Bloated Caves above Graphic Herbalism. I expected it to output some text explaining why, but it didn't. Are most rules setup not to tell you why things should be moved around? I ended up going back to the mods README which confirmed mlox's suggestion, but it would have been nice for something like the following to come out of mlox:

Per the Graphic Herbalism README, its ESPs should be loaded in this order:
Bloated Caves.esp
Graphic Herbalism.esp
Graphic Herbalism Extra.esp

Also, it reported that Book Rotate - Tribunal should come before the Book Rotate - Bloodmoon, yet I could find nothing in the README for the mod to validate this. Any ideas why it made this suggestion?

Seems like a really cool tool. I didn't expect my short mod list would have any problems but I was surprised how easy it was to get things wrong.

Probably because Tribunal was released prior to Bloodmoon and loading in this manner would take care of any changes Bloodmoon made to things that Tribunal added.

sieboldii

That's probably possible. I'd rather allow it to be a substring or something like that. How does that sound?


The "explanation" printed by the -e switch is merely a kind of printable representation of mlox's internal sorting graph, it's not like the comments you see in the messages window that explain conflicts and dependencies. So it sounds like it is not at all like what you expected. I haven't really come up with a good method for giving a verbal explanation of why things end up sorted they way they are. If you print out the debug output, it will show you the complete graph which mlox uses for sorting, and any explanation of it could be quite complex. But, still it would be neat to be able to do, so maybe I'll be able to get this into a Version 2. Obviously, this is one area where the BOSS program has a big advantage over mlox, it's answer is simply the total known ordering.


The particular rule that did that is actually a bit redundant, and it is not supported by the documentation, as you say. However, it is a safe ordering, and there were a few cases where I did put orderings in the rule-base like that.

I suppose that would be somewhat easier, but you could also end up with duplicate matches on a very long mod list. I just figured that since you are probably going to do a -e after you just did a -c and got your list of mods back showing where things should move, it would be nice to use the number right next to the mod. Using numbers you'd never have to give more than 3 characters and you would be sure of what you are getting.

Mlox is reporting that a patch is needed GCD_Havish_patch.esp when using Havish and GCD. The havish scimitar fix provided by Jog says:

"Fixed an issue with "Galsiah's Character Development"
(the fix provided by GCD breaks the upgrading option for the scimitar)"

So I think the fix provided by Jog is the one to use correct? If that is the case I think it best to search for any one of these 2 fixes if possible.

Havish - Scimitar Update.esp (IF MWE is also detected, if not warn that this is an MWE mod if it is detected)

Havish - Scimitar Update + GCD (no MWE).esp (otherwise recommend this mod instead)

I think this is the way to go. I hope this hasn't been discussed before and I missed it.

Hope that helps.

Thanks. I'm trying to review the Readme for "HAVISH: Scimitar Update + GCD Compatibility", and it's not clear if the patches require Booty Island or not. It kind of reads like they don't, however, it's not explicitly stated as such.
Can you confirm that the patch plugins do not require Booty Island?

I can say that I don't get any errors during load. No, I haven't play tested it completely yet. I looked through the mods and the booty island compatibility just looks like possibly a weapon ID conflict and nothing more. Looks like he changed or added a weapon ID for the scimitar. I don't think doing that requires Booty Island but rather just fixes the issue. I'm not a mod creator though.

The other stuff in the mod just looks like making the scripts better while supporting Leveling mods. The +GCD .esp does require GCD as the readme says.

That's my take.

Also, I was wondering how come the rules put GCD_107x_to_108_patch.esp after Vampire Hunger while the rest of GCD comes before. I know that Vampire Hunger messes with the GCD Globals, which I heard Galsiah say doesn't affect load order but better safe than sorry I guess, but why does that upgrade .esp come after? Just trying to understand the load order with these mods is all.

Thanks.

The ordering rules of mlox work so that we can say that B must follow A. But if there are no other rules saying otherwise, then mlox is happy to put all the rest of your plugins in between A and B. As long as B ends up further down in your load order, it is correct as far as the rules are concerned. This is pretty much the essence of "partial ordering", which is the notion on which mlox is based.

I'm glad you decided to wait for more information. I'm just trying to promote discussion, don't want to be too hasty changing the rules.

I guess I'm asking why is there a rule saying GCD_107x_to_108 must follow Vampire Hunger? Was there a discussion somewhere that took place earlier?

Thanks to Vharlak for pointing out the Havish Scimitar update. I think I've got rules that adequately express the Readme, but it was a little complicated, so if anyone notices anything, please point it out!
So here's a new release of the rule-base: mlox-data_2009-03-19.7z
http://code.google.com/p/mlox/downloads/list

Just to be clear ...
Are you asking about why a specific rule exists? (In which case it would help if you quote the specific rule from the rule-base). In this case, I believe there are multiple rules that are chained together.
Or are you asking how does mlox's engine work, so that GCD_107x_to_108 ends up following Vampiric Hunger?

I tried to find the rule before I posted but I am horrible at reading that file and I have windows so it's kind of hard to read I think. I think I understand that mlox will let .esps stay wherever they happen to be if there isn't some rule telling them they have to be moved right? I'm trying to find out what rule is telling mlox to force 107x_to_108 to load after Vampire Hunger but I can't find it. Are you saying that there isn't a reason that it is doing it? I mean if there isn't a rule then it would just let the .esp stay wherever I wanted it right? So there must be a rule. Why does this rule exist is what I want to know. I just want to know if there is actually a reason that it needs to load after Vampire Hunger. Maybe I just don't understand correctly. I don't want to waste any of your time.

That file does use Unix style line-endings, not DOS (CRLF). Is there not an editor that allows you to view files that use Unix line-endings?

Well, I'll try to explain what's going on in this case. There is a general explanation of how mlox does what it does in the mlox_guts.txt document.

The [Order] rules in mlox are transitive. So if A comes before B, and B comes before C, then mlox knows that A must come before C.

In the rule-base there are the following rules:

[Order]
Galsiahs Character Development.esp
GCD StartScript for Trib or Bloodmoon.esp
GCD better balanced birthsigns.esp
GCD Over 60 level speedup.esp
GCD Restore Potions Fix.esp
GCD settings fairly easy.esp
GCD settings hard.esp
GCD - Cult of the Clouds patch.esp
GCD_Havish_patch.esp
GCD_SS_patch.esp
GCD TEO compatibility patch.esp
GCD_VH_patch2.esp
CharGen Revamped delay2.esp
Brittlewind fix.esp
GCD_WE_patch.esp
GCD_107x_to_108_patch.esp
GCD_107x_to_108_patch_MwOnly.esp

[Order]
Vampiric Hunger Base.esp
GCD_VH_patch2.esp

mlox will put them together: seeing that "Vampiric Hunger Base.esp" comes before "GCD_VH_patch2.esp" (2nd rule), and "GCD_VH_patch2.esp" comes before "GCD_107x_to_108_patch.esp" (1st rule), so mlox concludes: "Vampiric Hunger Base.esp" comes before "GCD_107x_to_108_patch.esp".

Now, if you want to know where those 2 rules came from, the 2nd rule should be pretty obvious, as the patch is supposed to modify what was in "Vampiric Hunger Base.esp", so it needs to come after it. The intention of the first rule is to put the patches for GCD after "Galsiahs Character Development.esp", which is generally what you do with patches, however it is true that this rule specifies more orderings than are probably necessary. For example, we could move "GCD_107x_to_108_patch.esp" above "GCD_VH_patch2.esp" in the rule and then mlox would no longer put "GCD_107x_to_108_patch.esp" after "Vampiric Hunger Base.esp".

So, why was the first rule written like it is? Well, because even though it doesn't really matter what the order of most of the GCD patches is, it's easier to write the one rule like that than separate rules to put each patch after the main .esp. And having one rule is easier to read, and so it makes the rule-base more maintainable, and lastly because it doesn't really harm anything to add some orderings even where they are not necessary, although some care has gone into not going overboard with this attitude in the rule-base.

Hope that helps a little.

Yes, that helps a lot thanks for taking the time to write that out. Very much appreciated.

New release of the rule-base: mlox-data_2009-03-22.7z
http://code.google.com/p/mlox/downloads/list

Just a few small fixups, trying to stay current.

Been spending some time with my mod list so here's some amended rules and a new one.

First up some additions for the Morrowind Code Patch, a couple of extra plugins invalidated by the MPP:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; @MPP [TES Morrowind Community, ThePal, Baldurdash, and quorn][...][Note] ! All of these plugins are either included in, or the problems they address are  ! also addressed by the latest MPP by quorn [Morrowind Patch v1.6.4]. It is  ! recommended that you replace them with the MPP: ! [src="http://forums.bethsoft.com/index.php?/topic/938026-relz-mlox-a-tool-for-analyzing-and-sorting-your-load-order/http://planetelderscrolls.gamespy.com/View.php?view=Mods.Detail&id=7347"]http://planetelderscrolls.gamespy.com/View...ail&id=7347[/url] ! [src="http://forums.bethsoft.com/index.php?/topic/938026-relz-mlox-a-tool-for-analyzing-and-sorting-your-load-order/http://www.elricm.com/nuke/html/modules.php?op=modload&name=Downloads&file=index&req=viewdownloaddetails&lid=4519"]http://www.elricm.com/nuke/html/modules.ph...ls&lid=4519[/url][...];; aedroth's BM Wolf Greaves Fixbm_wolf_greaves_fix.esp[...];; earlier version of 'Clean_Templar_Pauldron_Fix_v11.esp'Clean Templar Pauldron Fix.esp

And now the MCP, a plugin that expands on he already mentioned Fashionable Merchants:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; @MCP (Morrowind Code Patch) [Hrnchamd][...];; rules for mods obsoleted by the MCP[Note] !! The highly recommended "Morrowind Code Patch" by Hrnchamd also fixes the  !! problem of merchants wearing items sold to them (and much more). The MCP fix  !! is also less likely to conflict with other mods. If you have the MCP, you will !! not need Fashionable Merchants by TheMikrobe !! (Ref: [src="http://forums.bethsoft.com/index.php?/topic/938026-relz-mlox-a-tool-for-analyzing-and-sorting-your-load-order/http://www.tesnexus.com/downloads/file.php?id=19510"]http://www.tesnexus.com/downloads/file.php?id=19510[/url] )Fashionable Merchants (TheMikrobe).espFashionable Merchants (TheMikrobe Trib).espFashionable Merchants (TheMikrobe BM).esp

Next an amendment to a set of MGE-related plugins:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; @MGE Distant activators Fix [Povuholo][Note] There is no need to activate these mods in your game. (Ref: "Distant Activators fix readme (!!!).txt") You do not need to use these plugins if you are using MGE v3.7.2 or later.Pov_Distant_Activator_Fix_BloodmoonStones.espPov_Distant_Activator_Fix_GhostFence.espPov_Distant_Activator_Fix_Holamayan.espPov_Distant_Activator_Fix_Incarnate.espPov_Distant_Activator_Fix_Lava.espPov_Distant_Activator_Fix_Malacath.espPov_Distant_Activator_Fix_RavenRock.espPov_Distant_Activator_Fix_SignsAndBanners.espPov_Distant_Activator_Fix_SiltStriders.espPov_Distant_Activator_Fix_Strongholds.espPov_Distant_Activator_Fix_TelvanniStoneDoor.espPov_Distant_Activator_Fix_TR1_BigDoors.espPov_Distant_Activator_Fix_TR1_Striders.espPov_Distant_Activator_Fix_TR1_Waterfalls.espPov_Distant_Activator_Fix_TR2_Striders.espPov_Distant_Activator_Fix_TR2_Waterfalls.espPov_Distant_Activator_Fix_Vivec.espPov_Distant_Activator_Fix_Waterfalls.esp

Finally a new plugin, not that much of a rule set but people do seem to enable every plugin they can:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; @Real Wildlife 2b [Nedius][Conflict] Choose ONLY ONE of these plugins "Real_wildlife_2b.esp" - if you only have Morrowind. "Real_wildlife_2b_Tribunal.esp" - if you have Morrowind and Tribunal  "Real_Wildlife_2b_Bloodmoon.esp" - if you have Morrowind and Bloodmoon "Real_wildlife_2b Complete.esp" - if you have Morrowind and both expansions (Ref: "reame real wildlife 2.txt")Real_wildlife_2b_Tribunal.espReal_wildlife_2b Complete.espReal_wildlife_2b.espReal_Wildlife_2b_Bloodmoon.esp[Requires] (Ref: "reame real wildlife 2.txt")Real_wildlife_2b_Tribunal.esp[ALL Tribunal.esm     [NOT Bloodmoon.esm]][Requires] (Ref: "reame real wildlife 2.txt")Real_wildlife_2b_Bloodmoon.esp[ALL Bloodmoon.esm     [NOT Tribunal.esm]][Requires] (Ref: "reame real wildlife 2.txt")Real_wildlife_2b Complete.esp[ALL Bloodmoon.esm     Tribunal.esm]

Typo consistent throughout, 'reame' ipo 'readme'

sieboldii

:facepalm: Thanks for proofreading

I think I already had that one in there, but anyway, it's in there now.

Thanks guys! New Release for the rule-base, including Dragon32's update: mlox-data_2009-03-24.7z
http://code.google.com/p/mlox/downloads/list

mlox needs an auto updater. I can barely keep up with it.

Ha!

Well, that's actually quite possible. Would people like me have mlox check for database updates on startup? I could consider adding that to a future release. I might need to implement a "Preferences/Settings File" first, though.

On the other hand, at some point in the future updates will probably happen less frequently than they do now.