Improve Flat World Map Framework
Closed this issue · 3 comments
If Navigator - Navmesh Fixes is installed with the "Rift Watchtower" option enabled in the FOMOD installer, it will install RiftWatchtowerNavFix.esp
. This is not in the LOOT masterlist, and LOOT will place it fairly early in the load order.
If FWMF for Fantasy Paper Maps.esp
from FWMF is also installed, then LOOT will place it immediately before the watchtower esp, despite it being in the very late Paper Maps group. This results in the paper maps showing up as the blue placeholder texture.
This is a pretty catastrophic sorting failure.
As you state, RiftWatchtowerNavFix.esp
isn't in the masterlist, so there's nothing in there that could force it to load after FWMF for Fantasy Paper Maps.esp
. I double-checked to be sure something else wasn't going on & couldn't replicate this. You may have overridden FWMF for Fantasy Paper Maps.esp
's group assignment to default (or an earlier loading group), in which case, LOOT will sort them the way you've described due to overlap rules. If this is the case, you should set it back to the Paper Maps
group. Otherwise, that means you either have a load after rule in your custom metadata that enforces this load order, your copy of RiftWatchtowerNavFix.esp
has FWMF for Fantasy Paper Maps.esp
as a master for some reason, or your copy of FWMF for Fantasy Paper Maps.esp
is flagged as an ESM for some reason. These are the only other possible scenarios in which what you've described is possible.
I can't have any custom metadata because my LOOT is the sort button in Mod Organizer 2. My copies of the esps are unmodified from the normal downloads on Nexus.
After further testing, I've determined that it's not just the watchtower esp; several others, if present, will act as if they're set to load after FWMF. Sorry about that.
I know the LOOT documentation says MO2 isn't supported, but I can't see how that would matter for this. The LOOT console output that MO2 displays looks fine: all the plugins are listed, etc.; it just puts them in the wrong order.
…Wait, it also says the built-in LOOT is version 0.17.1, which is not even listed in the GitHub releases, but if it was it would be about two years old.
And I just realized that my version of MO2 (2.4.4) is also that old, because that was its last release until a couple of months ago. That makes more sense. I'll close this now. If I'm still seeing this behaviour after updating MO2, I'll request a reopen.
Yes, that version of MO2 is ancient & uses an equally ancient build of libloot, so it won't receive the latest masterlist revisions which place FWMF in a late-loading group. For future reference, before reporting an issue, please make sure you can replicate it with the latest version of standalone LOOT. You can run it through MO2. We don't have control over any other team's implementation of LOOT, only our own.