[Bug]: Mod list reseted at launch

[paamu100]

Operating System

Windows 11

BG3 Mod Manager Version

1.0.9.11

BG3 Game Version

v4.1.1.3748643 (hotfix 8)

Bug Summary

Since version 1.0.9.11 (I was on version 1.0.9.9), the mod list gets wiped as soon as I launch the game, so I can't load my ongoing modded game.

The mod list becomes empty every time, as if the mod path is corrupted somewhere. I even tried setting modsettings.lsx (in C:\Users\XXX\AppData\Local\Larian Studios\Baldur's Gate 3\PlayerProfiles\Public) to read-only...

I still get the error message when loading my game as if I had removed all the mods from the Mods folder.

Links

No response

[LaughingLeader]

Are there any differences between your modsettings.lsx with 1.0.9.11 and 1.0.9.9? The game resets that file if it encounters an error when loading mods.

I haven't changed anything that would make that file write differently between versions, so it'd be helpful if you could check if the file itself differs between versions, with the same mod order.

[paamu100]

I reverted to version 1.0.9.9, and it didn't make any difference. I deleted everything in AppData except for the mod folder.

It seems like the game is no longer pointing to the original Mods folder, but at the same time, a mod like No Intro continues to work. However, the list of disabled mods in my previous game in the loading menu tooltip is as long as my arm (even No Intro is listed as disabled)...

this is my modsettings.lsx cleared after launching game :

`<?xml version="1.0" encoding="UTF-8"?>

`

and mod list from ModManager with my mods :

`<?xml version="1.0" encoding="UTF-8"?>

`

[LaughingLeader]

Export your mod order, then open modsettings.lsx externally with something like Notepad++. When you launch the game, if the file resets, that means you have an issue in your load order, such as a pak being corrupt, a subfolder being in your mods folder, or perhaps a missing dependency.

This is a common enough issue that I've had to repeat that information various times since release, since people assume it's the mod manager resetting your load order. Patches can break certain mods for instance.

I suggest saving your ideal load order to a separate file (File -> Save Order As...), which will create a load order json file, separate from modsettings.lsx. That way you have something to load again, when the game resets the load order.

Then going through your order with a "binary search" sort of process. Disable half the mods, export the load order, start the game and see if it resets. If it doesn't reset, then one (or more) of the mods you disabled were at fault, so switch back to the saved load order and disable half of the half you previously disabled, and try again.

Going about it that way should help narrow down which mods are at fault quicker, and then you can check if those mods have had updates.

[paamu100]

yeah i knew that, but after the hotfix 8 i had no pb (usual test), then i updated Mod Manager to .9.11 then i had this issue

I was aware of these recommendations; I don't think it happened immediately after the game update. I'll continue testing in the way you suggested. On some forums, I see similar comments as mine.

[paamu100]

A modder changed the name of the pack but not the name that appears in the game...

for info : Coloured Tootips (ingame)" and in the mod folder it changed from "Tooltips.pak" to "Tooltips Normal.pak." It's difficult to identify errors in these situations.

You were right 👍 ; it's the usual bug caused by an outdated or faulty mod that erases the list. I don't know what protection we can implement against this on the ModManager side. Ideally, modders should stay systematic.

[LaughingLeader]

for info : Coloured Tootips (ingame)" and in the mod folder it changed from "Tooltips.pak" to "Tooltips Normal.pak." It's difficult to identify errors in these situations.

Oof, yeah changing pak names is a big no-no.

I don't know what protection we can implement against this on the ModManager side. Ideally, modders should stay systematic.

Something to display duplicate paks should definitely help. Internally it's likely both of these paks have the same UUID in their metadata (meta.lsx), so when the mod manager loaded the next pak, the data just overrode the previous one (for the purposes of displaying what's available), instead of warning that a duplicate mod was found.

Thanks, I'll get that added to the list of features to add.

[paamu100]

You're welcome, it's a pleasure. If it can help provide insights for improving and protecting the mod list and load order (a crucial element, to say the least).