Not a big fan of this. This sounds like they want to integrate themselves deeper into the modding setup with the likely end-goal of being a requirement to that setup. The problem there is they have a history of de-platforming mods (regardless how you feel about those mods personally) and declaring themselves the owner of mods (by refusing the removal of mods they wanted in Collections).

Allowing them more control over what mods users can access seems like a step backwards.

A year and a bit on from taking the reigns, Folmann’s put up a post reflecting on the new regime’s first year running the modding site and outlining hopes to turn it into “an operating system for user-generated content in gaming” in the long term.

I think that that’s a nice idea, but I think that ultimately, it’s going to be really hard to do that on the distribution side.

There are definitely improvements that can be made on that side.

• Trying to deal with malware. Some of this is arguably more of a platform vendor or Steam problem — almost all games really could run just fine in a sandbox, without access to the broader system. But mods massively exacerbate the problem, because you have lots of very small programs from anonymous authors and little review present.

• Making it easier for end users to diagnose conflicts. I remember Conflict Catcher, an extension manager for the classic Mac OS, that had quite a good system for this — I’ve set to see a similar software package that implements this to the same level. The first bit I have seen elsewhere: when you have a problem, switch off approximately half of the mods (though if you have mod dependencies, you’ll need to take that into account in selecting the ones to flip off). Ask the user if the problem is still recurring. Repeat. For a single-mod problem (this mod just doesn’t work on this system), this isolates a problematic mod in O(log N) tries, where N is the number of mods. But what Conflict Catcher would do is to also extend this to identify conflicts between two (and IIRC, more) mods that had problems with each other.

• Improve the creation and distribution of “mod sets”. For very moddable games, where you’re dealing with maybe thousands of mods, this is important. Right now, Wabbajack does something like this — I actually just used this successfully under Linux for the first time the other day, using Jackify — things have come a long way on Linux — and while they build on NexusMods, NexusMods doesn’t natively have the ability to do this.

• Improve the situation for load order dependency. Maybe let mods provide partial ordering recommendations WRT other mods and versions; not sure what the best solution is here.

But a lot of the work to make games moddable in the first place, or to work well when being modded, really needs to happen on the game developer side:

• Some of the ability to diagnose problems with mods really has to happen on the game side.

• Trying to track down the performance impact of mods in anything more-sophisticated than a “restart and see if problem is present” Conflict Catcher-style approach — and some games don’t deal well with disabling some mods that have already been used in a game, so it can be very time consuming to run a pass.

• In particular, I’d like support from the game for trying to run mod code in parallel, where possible. Like, “this code module doesn’t mutate anything, just looks at the world state and computes a result”, and runs in a VM that enforces that non-mutability, so all of that code can run in parallel each frame. A lot of mods have historically relied on running in various game scripting systems that do not support parallelization, which is nice from an “avoiding bugs introduced by scripts written by people who aren’t writing correct parallel compute code”, but not so great from a performance standpoint, given that modern computers have a lot of cores and as the amount of script code run by mods increases, it can place increasing pressure on a single thread bottleneck.

• Improving startup times for modded games. For me, this is a pet peeve with very large modsets in Bethesda games. They need a system — maybe it’s building an index and caching it, or allowing init code to run lazily, or a dependency system or something (“this flag indicates whether this mod need to be loaded before the menus creen is displayed”) — to allow mods to be loaded intelligently in a way that doesn’t massively increase game startup time.