In Progress General Custom campaign map crashes on v1.0.0

Users who are viewing this thread

Version number


My custom campaign map was updated from e1.8.1, where it worked, to v1.0.0 where it crashes on loading the game. The only changes I've made from the e1.8.1 version were 1. Loading the map into the v1.0.0 Scene Editor and resaving it (in case things changed between versions); 2. Changing SubModule.xml to include <ModuleType value ="Community" /> rather than the previous <Official value="false"/> 3. Deleting all the siege_fire_particle_e game entities as these produced problem warnings in the Editor and are no-longer included in Sandbox\Main_map's scene.xscene file (previously used by looted villages etc).
As I still can't upload crash reports, the crash zip file is linked here:
While it may be unrelated, I was also getting this new assert warning in the Scene Editor:

MArdA TaleWorlds

Community Support & Localization
Community Support
Forwarded to the QA team for further investigation. We will reach out again if we need more information. Thanks for reporting and sorry for any inconvenience!


Further experimentation suggests changes in v1.0.0/e1.9.0 to either SettlementPositionScript or the treatment of navmesh.bin. My e1.8.1 navmesh was in two sections: 1. an inner core the size of Calradia with all faces set for the map; and 2. a disconnected border for future expansion with all faces set to 1. All entities were contained within the inner core. The settlementpositionscript entities were positioned at the corners of the inner core and presumably calculated the settlements_distance_cache.bin purely for that inner core, giving a navmesh.bin of 2,707Kb.
Replacing my two-section navmesh with a one-section navmesh (with all faces set to 1), repositioning the settlementpositionscript entities to its corners and manually running the three SettlementPositionScript scripts, creates a new navmesh.bin of 4,169 Kb. With that, I can load my custom campaign map in game again without the above crash.
Is this the result of intended changes or a bug? If intended, please clarify what the changes are so I can understand them.

Edit - removing the outer navmesh results in the same crash, eliminating navmesh holes as the problem. SettlementPositionScripts definitely seem to take much longer to calculate distance caches and can get stuck in ongoing infinite calculations. If something was “upgraded” in SettlementPositionScripts, it has undermined previously working navmeshes, which take a considerable time to make. As far as I can tell, v1.0.0 SettlementPositionScripts despite taking longer to run still creates the same 2,707 kb distance cache as e1.8.1 (and previous versions), however that now causes the above crash on loading the game.
Last edited:


Further experimentation shows all the crashes occur after the last child of the last clan is generated immediately prior to starting the game:

They are caused by some rejection of my navmesh.
All evidence suggests that the navmesh is being rejected for pathways between impassable sections of navmesh that are too narrow. Given these pathways worked fine in e1.8.1, the change is either a bug or a side-effect from further hardcoded 'optimisation' of Calradia's worldmap.
Identifying and correcting rejected sections of navmesh is very slow as nothing highlights these problems and the solutions aren't always obvious.
I have seen a new assert error throw up during settlement distance cache calculation:

The game always crashes, if I get that slow position warning whatever it is.

Our Worldmap was built with narrow passes through mountains, narrow tracks through impassable forests and slender bridges/fords - all of which seem to fall foul of this change in navmesh acceptance. I tried replacing impassable forest with passable forest that had movement penalties, but this was very poor at directing AI pathing along the correct routes.
EDIT: further tests rule out narrow pathways. The problems only ever occur with impassable navmesh faces and ATM I've no way of identifying which will work and which won't other than by extremely slow and tedious trial and error.
For example, this river causes crashes while similar rivers elsewhere don't:

Proof narrow bridges aren't the issue as this one works in game:
Section of forest circled in red which causes crashes in at least two sites if made impassable:
Seems very strange that exactly the same navmesh face(s) are acceptable in game if passable but rejected/crashed if impassable.
Last edited:


For example, this river doesn't crash the game, if it's navmesh faces are passable, but crashes the game if they are set to river (11) impassable.

Deleting all the river faces and then remeshing them before setting them as passable also crashes the game.
Deleting all the river faces made the calculate distance cache script crash until the editor was reloaded and tried again. Anyway, even with a subsequent correctly calculated distance cache, the game crashed with the river as a navmesh hole to stop AI movement that way.

Something, IDK what, allows the same section navmesh to function as passable faces but not as a hole or impassable faces. Seems an extremely bizarre bug that wasn't there in e1.8.1 and prior versions.
PS The same crash occurred when passable faces were given a cost of 150 to deter AI pathing.
Tracked the bug location down to two navmesh faces:

I deleted them and a couple of sea faces to remesh differently and got this assert on filling one rectangle:

Which produced this call stack after hitting retry:
Different remesh avoiding asserts also resulted in crashes:
Patching impassable faces around the problem pair (so they stayed passable) avoided a game crash but left the game load in an infinite calculation loop with a blue wheel spinning continuously.
Deleting the surrounding and problem faces and remeshing also crashed:
Accordingly, I'm now stuck with a ford at the neck of my river whether I want one there or not.
Last edited:
Top Bottom