Mod Manager/Launcher

[♘Top Hat Zebra]

Okay, guys, we need to talk. We need to talk about the Total War Launcher, specifically about how absolutely garbage it is.

First of all, this might just be me, but every single time the launcher starts up, it freezes my entire computer for 30 seconds to two whole minutes. No other games do this, but every game with the Total War launcher does.

I could deal with that, if it weren't for the mod "Manager."

What even is this thing? It's slow, it's clunky, it shows me only three mods at a time and lists them from left-to-right? Instead of top-down? Deactivating and reactivating mods is a hassle because the only way to do it is all at once, or one at a time via tiny checkmarks in the corner of each mod box. And I have to deactivate and reactivate mods all. The. Time. The inability to adjust load order is the final and largest nail in the coffin, more of a stake, really, right into the cold, undead heart of modding. Anytime anything updates, or I change anything, or add anything, apparently my mod load order changes and it breaks everything. I thought that mod order was determined alphabetically, but it appears to have something to do with the order that you activate mods.

For instance, Im using Radious as my base overhaul mod. If I disable every mod, then enable Radious, then slowly, one by one, activate every other mod in the queue, everything works fine. If i then disable Radious, and re-enable it, everything breaks.

Why?? It must be changing load order, because nothing else makes sense, but why on Earth is it changing load order just because I activate it?


Please. PLEASE. Please. Please give us a new mod manager. I can't take this anymore, Im going to rip all of my hair out, and Im a zebra, so I have a lot of hair. You guys have Mitch working for you now, so you have no excuse.

P.S. Also increase men-per-unit limit please and thank you.

[The Holy Pilgrim]

At the very least, allow us to sort the mods by name, alphabetically. Pleeease!

All in all, I'm in absolute agreement with you, Zebra. #MakeModLaunchersGreatAgain

[Kurisu Paifuaa]

@Zebra

Don't fall into the "load order" trap... it's a mythical solution to conflict management that's largely irrelevant where database tables are concerned. And it's only marginally useful for getting non-database mods to play nice (e.g. texture and variant mods). Essentially, you should scrutinize the contents of every mod you use and perform manual conflict checking, editing and merges, if you want an optimal experience.

What we've needed for a long time is a mod manager that does actual conflict checking, down to individual database records and informs users so they can take corrective action. At the onset of Warscape modding, the devs encouraged modders to take a "single pack" approach in order to avoid conflicts. Quite sensible, but of course that didn't reflect how the modding community actually functions (a large number of individual authors) and then along came Steam Workshop, which compounded the problem by encouraging mod hording and not providing management tools. Mitch's manager did rudimentary conflict checking, but only where files had the same names. It was a good start, but didn't cover all the bases. I'm hopeful they're working on a comprehensive tool, as I'm sure they're aware that haphazardly smashing mods together is a terrible idea.

I agree that the launcher is clunky, prone to crashes, and presents the "mod list" in the worst way possible. But an update needs to go beyond load prioritization in order to solve what is an unavoidably complex problem.

At the very least, allow us to sort the mods by name, alphabetically. Pleeease!

@Pilgrim

You can sort by name and date, along with filtering by tags (pretty useless, given that so many people misuse tags). There are two drop down lists just above the mod display.

[craziii]

to be honest, with the death of big comprehensive mods for total war games. the current abandonware level mod manager works for it's current purpose.

[Kurisu Paifuaa]

to be honest, with the death of big comprehensive mods for total war games. the current abandonware level mod manager works for it's current purpose.

I think the opposite is true, no? If you were strictly using a comprehensive overhaul, your management needs would be relatively low... someone else has done all the work. But with Warhammer's extreme à la carte modding state, you create your own overhaul by cobbling together things you like. Thus, the need for a front end utility that doesn't completely ignore certain realities of modding is much greater.

[♘Top Hat Zebra]

I do a lot of merging (Which immediately gets destroyed every time there is a mod update, of course) but I have had multiple occasions in just the past two weeks where adjusting load order would have solved the issue. In Warhammer I would have needed to create a custom User.Script and manually load every single mod, and I just was not going to do that. Luckily the other issue was with Rome II, and I was able to just use .Mitch's Mod Manager to fix the issue that was causing a crash.


I've also had several occasions where files that both edit the same table are causing a crash, whereas I was reasonably certain they did not used to do that. Surely one is just supposed to overwrite the other? For instance, using Radious and a mod that adjusts Winds of Magic amount results in a crash, whereas using just one or the other doesn't. I had to manually merge the tables in order for it to work, and yet just a few months ago I was able to use both mods simultaneously, even though neither of them have made any changes that would cause them to crash while activated together that I can see.

[craziii]

I think the opposite is true, no? If you were strictly using a comprehensive overhaul, your management needs would be relatively low... someone else has done all the work. But with Warhammer's extreme à la carte modding state, you create your own overhaul by cobbling together things you like. Thus, the need for a front end utility that doesn't completely ignore certain realities of modding is much greater.

well, I tend to use a big base mod. then add the small ones. it is almost a 100% guarantee that there will be conflicts. if you use small mods exclusively. you aren't going to download 2 small mods that does that same thing right? smaller chance for conflicts?

[Kurisu Paifuaa]

I do a lot of merging (Which immediately gets destroyed every time there is a mod update, of course) but I have had multiple occasions in just the past two weeks where adjusting load order would have solved the issue. In Warhammer I would have needed to create a custom User.Script and manually load every single mod, and I just was not going to do that. Luckily the other issue was with Rome II, and I was able to just use .Mitch's Mod Manager to fix the issue that was causing a crash.


I've also had several occasions where files that both edit the same table are causing a crash, whereas I was reasonably certain they did not used to do that. Surely one is just supposed to overwrite the other? For instance, using Radious and a mod that adjusts Winds of Magic amount results in a crash, whereas using just one or the other doesn't. I had to manually merge the tables in order for it to work, and yet just a few months ago I was able to use both mods simultaneously, even though neither of them have made any changes that would cause them to crash while activated together that I can see.

Which tables are changed by the WoM mod you're using? I use Steel Faith as my base mod, so I'm not that familiar with Radious', but looking at his /db directory, he's directly replacing a lot of vanilla tables... _kv_winds_of_magic_params is one of them. I'm not sure why, as that table isn't one where you'd need to delete a record, and it works as a fragment. I'd ask him about it. It's likely that's creating a load dependency which will result in either a crash or ignored data if not respected. If that's the case, I could see where having an easy means to shuffle load order would be useful.

Though I still think it's best to strike at the root of the problem... eliminate or minimize the use of vanilla table names in all mods; edit the table names in small mods you want to sample to prioritize their changes over the base; merge changes you like into the base mod directly. Load order switching will only solve a certain subset of conflicts, whereas establishing and maintaining rules for your mod collection will keep you sane. Mostly. Sometimes...

What I do to protect any editing I've done to others' mods is to give the pack a prefix (my_x_mod, or whatever) while also keeping an unpacked working folder. Then I activate my pack and disable the original. When an update comes down the pipe, it stays disabled and I identify it by occasionally checking /data (sort by modified date) or sorting my subscription list in the Steam Client. When there's an update, I unpack and run a diff against my working folder, looking for changes that may overlap with my edits. A 3-way diff can sometimes be helpful (with either vanilla or the previous version as base). I like Beyond Compare for this. Then I resolve those and merge my edits into the new version, or vice versa. Also, backups... many, many backups.

Incidentally, instead of creating a prefs script to control load sorting (if that's your preferred poison), doesn't alphabetical pack naming work? It sucks that there's still no user db logging in these games to help figure this stuff out.

well, I tend to use a big base mod. then add the small ones. it is almost a 100% guarantee that there will be conflicts. if you use small mods exclusively. you aren't going to download 2 small mods that does that same thing right? smaller chance for conflicts?

I think anytime you put the work of multiple authors into the mix, you need to examine the contents. Too many chefs... that sort of thing. Ideally, you have a front end manager that flags obvious (to a machine) conflicts and the rest is up to you. But our current mod manager has exactly 0 features to help manage that, while Steam Workshop is conceptually geared towards accumulating "collections". That, of course, is not unique to TW titles.

[♘Top Hat Zebra]

Well my point initially is that I thought the load order was determined alphabetically. That's what everyone said. But when I would enable things in a certain order it would work, and when I enabled things in a different order it would crash. I can't think of any reason for that other than that the mod manager is changing my load order each time I enable/disable something.

I can't recall the exact mod for WoM I used, but it was extremely small. It literally only changed _kv_winds_of_magic_params, altering the base amount and replenishment rate. Radious also modifies that, but I thought that one mod would merely overwrite the other, not cause a crash.

I do agree that modders shouldn't use vanilla table names, but unfortunately CA can't control that. They can add the ability to adjust load order, though. I would rather have the ability to adjust load order than just hope modders will collectively create better .pack files, or have to manually go in with PFM and change the things I want.

[Kurisu Paifuaa]

Here's the most recent comment from CA_Darren concerning an update to the mod manager -- https://www.reddit.com/r/totalwar/comments/5r644r/whatever_happened_to_this_and_why_arent_we/dd4zwc0/

So that sounds great, if it encompasses all of the things described. My take on load sorting is just that it seems to be viewed as a cure-all by the community at large, when it really needs to be taken in context with how a mod is affecting db construction and the intention of the author. It won't work all of the time, and that should be made clear to users if it's included. Like in your example with the kv magic table... if both Radious and the author of the small mod had used table fragments (with unique names), load order arrangement wouldn't have helped at all. Priority would be entirely controlled by table names, and you'd have to dig in to fix it.

It's completely legit practice to replace a vanilla table... you have to if you need to remove original records for some purpose. Modding would be more limited if that wasn't possible. There are also sometimes cases where certain tables aren't addressable via fragments, then suddenly (via updates) they become so. So there's unavoidable difficulty in maintaining a standard. IMO, the best, first step would be to demystify db construction by providing some useful log output.

[The Holy Pilgrim]

@Pilgrim

You can sort by name and date, along with filtering by tags (pretty useless, given that so many people misuse tags). There are two drop down lists just above the mod display.

Well, give me the hat and call me a dunce, I must've missed that