Infernio

Okay, fixed that one - it was a rogue walrus operator: 02780fe82bc005f64bcda7641fc255593f5783cb Will have a look at the rest tomorrow.

Looks great so far 👍

Getting an error in Oblivion that I'm not sure how to solve: ``` patcher_dialog.py 265 _error: Exception during Bashed Patch building: Traceback (most recent call last): File "E:\Infernio\Desktop\Programming\wrye-bash\Mopy\bash\brec\utils_constants.py", line 140,...

Re: performance - I did some quick profiling (see my two latest commits on the branch, which are the results of that). Times are really inconsistent, as per usual with...

Pushed a rebased version to `xxx-utumno-637-fids`, there wasn't much in the way of conflicts :) The fix seems to work, BP completes in Oblivion now 👍 I'll check if the...

There are some BP differences in Oblivion (one weird empty extra `GMST` is dumped and some `LVLI`s aren't getting items merged(?) in for some reason), I'll take a look at...

Okay, the problem is that `convertFids` used to call `setChanged()`: https://github.com/wrye-bash/wrye-bash/blob/00c9ee8298ca78c522e8ab85611348a3c6ead8e3/Mopy/bash/brec/record_structs.py#L226 Without that call, almost all records (besides some random ones in the leveled lists patcher) are marked as unchanged...

That would work for the BP - do we modify in any other places (e.g. links) without explicitly calling `setChanged` on the altered records?

Yeah, that might be the best solution for now. We can always toss that method in some later refactoring once we've hunted `load` down further.

Note for the future: if we change masters, then doing something like a recursive `setChanged` will still be necessary, since changing masters could impact every single FormID in the plugin...