Well, let's see...

-Area Effect Projectiles is my personal version of Bethesda's Area Effect Arrows plugin. It's just a tweak to the new equipment, so all the same rules apply.

-Better Clothes Complete (BTB Edit) is a compatibility patch for my mod and Better Clothes. It replaces the original Better Clothes plugin and the More Better Clothes plugin.

-The names of the plugins from my mod are:

BTB - Character
BTB - Spells
BTB - Alchemy
BTB - Equipment
BTB - Settings

The only rule is that "Settings" needs to be loaded after "Spells"

Is it possible to get mlox to sort my mods the same way BOSS does? I don't really understand how mlox sorts mods, but it seems to me that the "Update Load Order" button will only be clickable if it detects that a certain mod (A) is ordered wrongly against another specific mod (B), and will not touch any other mods "if it won't cause any problems".

I like how BOSS sorts everything absolutely based on the order defined in the masterlist.

Have you read the thread? Because that is already answered. Mlox has no master order. It Infers the ordering dynamically based on rules and the mods you have. It is better(?) than a fixed list.

BTW:
@john.moonsugar how is that autoupdate feature for the rule base going. It's quite easy to point things at the google code svn repositories.
For the last raw file itself it is:
http://mlox.googlecode.com/svn/trunk/data/mlox_base.txt
Downloading it should be easy with python, it certainly is with java.

I already knew that. I was just wondering if there is a hidden feature or something for people who prefer a fixed list. Oh well. Thanks anyway.

You could setup your own order rules in the mlox_user.txt to force the plugins into the certain order you want. It's probably easier tho to redate plugins using Wrye Mash to group them as you like, then run mlox against that order to make sure things aren't conflicted.

Yup. This would allow Nash Muhandes to have his own fully specified ordering. But I agree, might as well just use another ordering tool like Mash if that's what you want.

Downloading is indeed easy. What is not so easy is accepting new rule contributions without doing some consistency checking to make sure that mistakes are not distributed to other users. I've been thinking of writing a little custom website to manage this, but I keep finding other things to do.

About the auto-update. You want to do it like a wiki? Cool idea, but in the interim wouldn't it be better just to release a version with "simple" auto-update, since people are often interrested in new mods that have conflicts that are explained by the authors, and the mlox contributor and reporters make a excellent job updating the rules, why not have a simple version at first? If the location of the "wiki-ed" file changes later, you'd have to have a new version anyway right? Or you could even put the rulebase location configurable, and hopefully, not change anything, except a config file or say to the people who already downloaded to edit that to point to the new location.


The only thing that bothers me about this is when i'm using texture replacers that affect the same texture/meshes. Like the recent on the rocks and the UV corrected rocks, or SWG skies and Vurt's skies.
Mlox doesn't know about these files and they can get replaced on the wrong order by wrye mash if you don't join them into a single archive in the right order. At least i guess so. If it doesn't based on the file stamp of all the files in the installer, maybe not, but if in the installer, maybe yes, since i often delete meshes i don't want from the installers, or repackage them (thus changing the creation date of the "installer").

I guess i'm asking if wrye replaces a conflicting texture/mesh based on the creation date of the mesh inside the archive or on order of installation (if at the same time) (this would be broken i think) or what?

There is also the case where the mod that replaces part of another is updated, and you update it (manually, since again, mlox can't warn you about pluginless replacers right?) and then it is not deterministic again?

Guess the only way to be sure on these mods is to join them on a single archive, overwriting the versions of the files we don't want? Updating that is a nightmare.

I don't really see the advantage. I haven't been updating as much as I should (There is an update in the works at the moment). Anyway, it's all on the big todo list.


The ordering that a plugin loads (mlox's domain) has got nothing to do with the order that meshes and texturs load (mash's Installer domain). You can completely customize which mod's resources (meshs/textures) take precedence via Mash's Installer feature, it's really quite nice. You do not need to join them into a single archive (or .bsa even). In fact, it's probably easier if you don't. Just look in Mash's Installer's tab for the "Order" column. The number there indicates whether it will override (higher number) or be overridden (lower number). All you have to do is change that Order number for a mod and you can change the precedence its resources have over other mods. Play around with that, and check out the "Conflicts" tab in the pane to the right. Perhaps it is a little complicated, but it reveals itself to a small amount of study.

What I'd like to see is load order support for deactivated plugins. For example I'd like to put Vurt's grass mods at the end of the load order. Mlox doesn't sort it because it isn't activated.
Also a "Shut up" button will be great. I clean Expanded Sounds every time I install Morrowind and mlox keeps warning me about wrong versions and etc...

Otherwise mlox is great and I will love all the new features. Autoupdate is great news.

Mmmm. But couldn't it handle "mash's Installer domain" if it was integrated with mash? (or a similar tool developed for it). I mean sure, texture mods are prefences, but if you have two overlapping texture/meshes mods (only) on a list, the preferred order 99% of the time is obvious. The one that replaces the most first. The more specific later. There are even texture mods whose readme says they are to be used like this, Vurt's Sky for instance.
Maybe the fact that it is a "aesthetic" matter, separates it from the rule-database of mlox that is a "correctness" domain. But i can't say that i would mind a separate project / fork of the rule-database integrated with mash that ordered the texture replaces with the ordering above.
It might get complicated when there are more than 2.

And if you do that, you might as well move it all.
Don't take it the wrong way, i love your program, and if there is no way you'll want it to be absorbed by wrye, or the programs input is too different to adapt without a massive hack or redesign i understand, just speculating on the possibilities.

Maybe wrye should be adapted to follow a "plugin model" (or runtime interface in Computer Science parlance) for that ordering function? Or maybe even to fork for mlox for internal use for these kind of ordering, but using md5 sums of the installers as keys?

I'm not following you there. Whether you want one texture to override another is purely aesthetics, there's no way to write rules to say which texture is better in a specific situation, as people's opinions on aesthetics will differ. Mash already has the ability to handle texture and model precedence, so I don't know what else needs to be done in this area.


As for adding mlox into Mash, that's okay with me if anyone wants to do it. But for the reason stated above, I really think using mlox or something like it for ordering texture/model installation precedence is not a good idea.

Hello,

First of all congratulations for this tool which in the principle is just terrific.

I am having a problem using it, though. I tried to customize a bit but it seems mlox will simply not take my mlox_user.txt into account. I imagine I overlooked or misunderstood something so I'll post my mlox_user.txt here in case someone can tell me where I go wrong:



I did not check if mlox did not take it into account at all, but I noted some rules do not apply. I updated the load order in mlox then checked it in Wrye Mash's mods tab: Vampire Embrace still comes before Antares, Neo's Unique Creatures before Creatures, etc. Any comments?

Other than that, mlox keeps telling me I have version 1.4 of RoHT and should upgrade, whereas I do have version 1.5 installed...???

One last thing: mlox does require wxPython 2.8.7.1, i.e. a more recent version than the one normally used by Wrye Mash (I think this has already been mentioned). Good news is, Wrye Mash seems to work just fine with v. 2.8.7.1 as well.

My apologies for double posting, but I forgot to ask: if I install Morrowind in a different location than the usual one (C:/Program Files/etc.) as it strongly advised for Vista/7 users, will mlox work as expected?
Sorry if that's a stupid question.

If you could do some testing and let me know if at least some of your rules are working, that would help immensely. Then we at least know you have your mlox_user.txt in the right place and are basically doing the right thing. If that's the case, the biggest reason for a rule not working is that the spelling of the plugin does not match the name of the plugin you have installed (of course it is not case sensitive).


It always helps to know the exact wording of the message you are inquiring about. In this case, I believe that the rule-base only knows about RoHT up to V 1.4. I'll check that for the upcoming rule-base update.


Yes, this is as documented.


As long as you install mlox somewhere under where you installed Morrowind, mlox should be able to travel up the directory hierarchy and find the "Data Files" directory. So it does not matter where Morrowind itself is installed as long as mlox is installed under it somewhere.

I wanted to do so, when I realized that the mlox_user.txt file was actually named mlox_user.txt.txt :facepalm: :facepalm: :facepalm:
Either there was a problem with mlox (which renamed it?), or I am a complete dope. Okay, it is more than likely that I am a complete dope.
Anyway I renamed the file properly and everything seems in order now.

By the way, about the rules I chose to apply: they are based upon what tespcdv031 tells me and reflect most of the conflicts it detects... Having said that, a clear and full understanding of what the consequences of such conflicts can be is something way beyond my skills, and some of my rules may be useless, if not dreadful... But for someone more experienced I guess tespcdv031 is a nice tool to help improving the mlox_base.txt

3 new lgnpc mods:
http://escf.rethan-manor.net/index.php?topic=1931.msg24606#msg24606

I hope this doesn't get lost on the 11th page . . .

I accidentally had both Morrowind Patch v1.6.4.esm *AND* Morrowind Patch v1.6.5-BETA.esm checked in my load order and mlox missed it. I didn't even notice it until I found a door doubled in the Balmora Council Club and checked out where they both came from. Might want to stick this in with the next rule base update.

Actually, Whattheh, you have version 1.41 and the mlox rule is completely accurate. It'll display the Note when it finds a version of RoHT less than 1.41

And 1.5 is less than 1.41 (5 < 41). I popped something in to update for 1.5 a week or two back. Hopefully John sees this / gets my PM about that before spending too much time writing stuff.
I know what you mean, trouble is with that is do we then start catering for all the other different possible combinations of versions out there? E.g. someone with both 1.41 and 1.5 of RoHT? It's bad enough with all the "You should upgrade!" Notes in there at the moment and checking up on them (I recently added some rules for BTB's Game Improvements and there's no way I'll be doing a version check on that!)

I'll listen to what John says of course: it's his program. But, to me, it seems that it's a lot of work for a pretty rare eventuality, we have to expect the mod user to do some of the work

That said, there was one thing I noticed that can cause a problem when someone has multiple versions of the same plugin. I was entering some rules for Gawain's "Knight saddle for Pegas Horse Ranch" and one of the user modlists I check against had two copies of Pegas Horse Ranch (Pegas Horse Ranch v3.0.esm and Pegas Horse Ranch v3.1.esm)

That combined with the rule I was testing:

[Requires] (Ref: Knight saddle - readme.txt)Knight saddle -steel- for ESMversion.espPegas Horse Ranch v?.?.esm

Led to a Parse error:

mlox_base.txt:11427: Parse Error(), expected start of rule [Buffer=pegas horse ranch v3.1.esm ]

Which I believe is because of using the "?" wild card.

Anyway, that's maybe something more for John that anyone else here.

If anyone's interested in the rules I've been adding I've mainly been going through the consolidated mod list from Fligg's Census and Excise Office. I compared the plugin names there against what's in mlox_base.txt and where a particular plugin name didn't appear (in mlox_base.txt) I've checked it out and written rules if needed. And wandered about through related plugins as is my wont. Current mlox_base.txt up on Google code has rules for all the plugins used by 16 or more people (~5% of C&E users). I'm going to stop when I've checked all the plugins used by 10 or more as then it starts to get a bit silly. So, this should mean that there's a better coverage of the popular mods, rather than just the ones I use or are reported here

Woah, code tags are a bit bonkers now.

Actually, Dragon32, that's why I use mlox. I have a pretty good idea of how my modlist should be loaded, but I use mlox to double check that I haven't made any dumb mistakes. I truly believed that checking for version conflicts was one of the more basic functions of mlox; especially something as widely used as MPP. I would say even though mlox depends on modders to keep john informed of updates, creating a rule that checks for nearly identical mod names wouldn't have to be done on an individual basis. Mlox may return some false positives using a general batch rule, but I'll take a false positive over a false negative any day.

Thanks for a great tool. I'm using it regularly as I tweak and re-tweak my ever-changing mod list.

I have a couple of suggestions to throw in, since there seems to be a fair amount of activity on this thread:

1. How about a custom/merged mods alias function supported in the custom rules list?

Something like:

[Custom Name="Merged Magicka 1"]Elemental Magicka 1.0.espSpect Sorcery pt 1.esp[Order]Merged Magicka 1.espNEDE v1.2.esp

The idea is to provide a way for Mlox to traverse merged mods during it's anolysis. I know this could get tricky, but a basic anolysis of known merge issues, and simple load order (i.e. are you combining mods that should be in different areas of the load list) would be really, really cool.

2. How about adding either a verbosity level, or checkboxes for options such as include warning, include suggestions, include version checks, etc.

Again, this could get out of control with feature overload, but it would be nice to have the option to suppress some of the more incidental comments.

I agree. Something algorithmic on the main mlox program like a http://en.wikipedia.org/wiki/Levenshtein_distance warning with a low value of distance reporting would be nice.

Yeah, I'd say if we think a situation is pretty rare, but implementing rules to warn about it would be extra complex, then it's probably more trouble than it's worth. mlox's general philosophy ought to be to cover most of the common ground while limiting rule complexity for the sake of ease of maintenance.


I think the problem there is actually the "for ESM" bit. Is that really the name of the plugin? Bleh. For the sake of parsing, I need some pattern that terminates the plugin name, and up until now it has been "esm" or "esp". I'll check into that for you. (sigh)

A simple "aliases" feature has been talked about before and is on the todo list.


Yes, this too has been on the todo list. I have to implement an application preferences feature first.

When this thread rolls over (real soon), I'll post the todo list on the first post.

I suggest adding this:

[Order]
;This prevents an error message regarding TC_CEGate in TR_CensusAndExciseTravel.esp's TC_CEShipDockScript script
;when starting a New game.
;Note: with both of these mods enabled, there will be two boat captains to talk to and two superimposed gate objects in Seyda Neen.
Siege at Firemoth.esp
TR_CensusAndExciseTravel.esp