Mod manager

T

Timeslip

Water Chip? Been There, Done That
Modder
I intend to make a mod manager for fallout 3 similar to my oblivion mod manager, since it will likely use a similar esm/esp/data file system. I made some, quite frankly, horrible design decisions in obmm partly as a result of starting work on it before oblivions release using the assumption that the modding system would be nearly identical to morrowinds. The non-existence of a fallout 3 construction set is advantageous there, because I have no need to rush something to be ready for the release day, and get a chance to see how fallout works first, and plan around it appropriately.

So basically, the question is if I was rewriting obmm from scratch what would you want to see added/changed? (Or, if you've never used obmm, what would you consider to be useful features of a mod manager?)
 
I've used Freelancer's Mod Manager and that's the closet I think would be to Oblivion's.

Since the Mod manager allows to to activate or deactivate mods, that's a pretty basic setup.

Perhaps a way to categorize mods whether it be just weapons, characters models, total conversions, etc. You may want to think about whether allowing the user to customize the categories, have set categories (cannot be deleted), or a mix of set & custom (select categories as sets, but any you can't think of the user can create).

That's all from the top of my head.
 
Good to hear that you are already prepared. Lots of modders will be sleeping better as a result. I sort of used OBMM but not as much as the rest of the community.

Most of what you had in there is really useful and anything similar will be adequate initially.

-----
Here is my prediction of how things will sort of work especially without a CS available.

First thing needed will be a BSA unpacker any number of people will have one of these within days of release perhaps yourself included.

I see the first round of mods will be texture replacement as that's the easiest. The next round will be game fixes in the form of scripts.

The next round being weapon and armor mods. Every game with guns always seems to get the realistic weapon mod with 487 new gun types.

There may be some optimization mods assuming the NIFs shipped with the game that are poorly optimized for lower end hardware.

--
So what is needed from a mod manager, the basics of activation and deactivation are obvious. Conflict detection/resolution would be nice. Categorization may be nice but I think without a CS there will be relatively few mods so this is not immediately needed.

What will really be needed are tools for creating/editing/cloning the ESP/ESM files as there will not be a CS for some time if at all. Not sure a mod manager is the right place for it though could be helpful if done well.

You may be in a good position to define folder layouts for mods for instance if your tool facilitates testing and deployment otherwise you will need to follow the existing model of putting everything in the data folder and then marking the files in a given mod.

Hard to guess where the future lies without seeing what is possible though.
 
I'd have to say an improvised conflict detector, except I have no idea if one can be made to detect any types of conflicts 100%.
 
Mrxknown said:
I've used Freelancer's Mod Manager and that's the closet I think would be to Oblivion's.

Since the Mod manager allows to to activate or deactivate mods, that's a pretty basic setup.

Perhaps a way to categorize mods whether it be just weapons, characters models, total conversions, etc. You may want to think about whether allowing the user to customize the categories, have set categories (cannot be deleted), or a mix of set & custom (select categories as sets, but any you can't think of the user can create).

That's all from the top of my head.
Click to expand...
obmm allowed the user to create groups, assign an omod to one or more of them and then filter the display based on group. omods moved from one obmm installation to another lost their group information. I wasn't planning on changing that system; people's idea of what constitutes a group varies too much for me to pick a single set of mod categories that everyone would be forced to use.

Adding a few set categories and allowing the users to add extra's might be a sensible idea though... Maybe I'll do that. :)

CrazyAce said:
I'd have to say an improvised conflict detector, except I have no idea if one can be made to detect any types of conflicts 100%.
Click to expand...
Script related conflicts can't be detected. (Or at least, can't be detected easily or reliably) Actual esp record conflicts can be detected 100%, and obmm does indeed do that. The problem comes because there's no way for obmm to tell if a 'conflict' is intentional, which means that the conflict reports obmm generates can't just be taken at face value and need to be interpreted by someone who knows what they mean. Fallout 3 is likely to be similar; spitting out a pile of records which are modified by multiple mods will be easy, but telling which of those will cause problems is probably not going to be something that can be automated.

tbh, I'm tempted not to include a conflict detector at all. obmm's was badly misunderstood, where everyone seemed to think that a red entry in the report was automatically bad and meant that two mods were completely incompatible. I'm sure that hurt the initial uptake of things like the unofficial patches, which conflict with pretty much everything despite being compatible with the vast majority of mods.
 
Timeslip said:
tbh, I'm tempted not to include a conflict detector at all. obmm's was badly misunderstood, where everyone seemed to think that a red entry in the report was automatically bad and meant that two mods were completely incompatible. I'm sure that hurt the initial uptake of things like the unofficial patches, which conflict with pretty much everything despite being compatible with the vast majority of mods.
Click to expand...
I hope you include a conflict detector. It steamlines the building of compatibility patches (where they are needed) and gives the mod user ability to assess the severity of conflicts. It would also be nice if it were possible to only test a few mods at a time - even ones that haven't been activated.
 
One thing I didn't like about OBMM was how popup windows always made it impossible to click in the main window, even if there really wasn't a reason for that.

Another thing would be the ability to add group headers to the load order list. Then you could right click a mod and do 'Send to <Group>' to make things a lot easier.

Oh, and the message that popped up when 'sending to top' that files have to load after .esm's was super annoying. Same with the messages about not having provided an author/description when creating omods.

As far as conflict detection, I would say just have popup text to indicate whether the mod is going to overwrite files, and whether the files are identical. That way people can decide for themselves whether the conflict level is red/black/etc.

Also, when deactivating a mod that has overwritten another mods files (aka, the files have two owners shown in the info screen), a message could be displayed to indicate that not all changes may have been undone. For example, install mod A, install mod B, deactivate mod A --> mod A's files are still there instead of mod B's.
 
I liked OBMM, but I wish you would ditch the .omod files. Not all mod makers use it, and inevitably you end up mixing omod and non-omod which was more of a pain in the ass than just prioritizing your texture / file overriding. To me at least.
 
los-angeles-times

êàðî÷å äàæ íå çíàþ
Ýòî ìîæíî è íóæíî :) îáñóæäàòü áåñêîíå÷íî
 
You must log in or register to reply here.
Back
Top