I can't spot why the changes done in this change set would cause such behaviour.
You are right, your commit is fine. Congratulations, you've discovered a bug in the engine.
I've now fixed the bug in the dev version but, fortunately, it should only mildly affect you
even if you use the released version. I have wrongly advised you to use
AutoLeader True Truefor your players to maximize the number of leader changes done by AI (which are usually beneficial).
In fact, for technical reasons, the correct incantation is
AutoLeader True False.
If you use it, the bug will not manifest. Unfortunatley, for playerTechCult you'd need
AutoLeader False True, but that one would trigger the bug. So, for now, your cult
will change it's leader from time to time, I'm afraid. Technical details are at the end of this post.
BTW,
_meleeAndRanged, though a fine choice for, e.g., playerMerchant,
does not fit playerTechCult, because it means the non-leader cultists will never move,
only melee or reaction-fire. You can spot such content errors by defining a few debug modes
where playerHero is controlled by AI and, e.g., playerTechCult has a UI client so that you can observe
how it behaves. See, e.g., 'make frontendDefense'.
fcanEscape = True means if any cultist reaches the spaceship exit, they win the game.
That is fun, a race to the exit, but to have a chance, either move their starting point down,
or move the spaceship exit down (see Allure of the Stars, where exit is at the opposite end of the ship).
fneverEmpty = True is weird for a faction that spawns, because as soon as
there is no actor left, the faction is announced to be defeated, but then, some turns later
another actor may spawn. I have no clue what happens then (I hope not a crash).
I will have to check the code, but perhaps in the future we should just try to cross-verify
fneverEmpty and cactorFreq in CaveKind and reject such content.
Anyway, thank you for the unexpected use case.
You may want to use LeaderNull instead of LeaderAI for most (half?) of your factions,
because each leader keeps a single level active. That means that up to 5 AI factions
may be concurrently exploring the dungeon on 5 different levels. There'll be no loot left before
you heroes get anywhere.
TPatrol would help, but it's not yet implemented and there's even
less sense in a faction actively patrolling a level where no other faction has any actors.
With as many factions as you have, spreading out and establishing patrol areas
may be easily done when other non-human factions with leaders visit a level,
so that the patrolling faction is ready to get activated when the heroes come.
Technical details
-------------------
My wrong advice came from too simplified documentation (or too complex semantics),
to the point that it fooled even myself, after a particularly refreshing vacation.
The expanded documentation is below. The point is that in the current setup,
AI leader level changes are done exclusively by the server (hence
True in
AutoLeader True False) and extensive AI leader switching without level changes
is done only by the client (hence
False).
In the future, this should be more symmetric, with both kinds of leader changes available
both on the server and on the client. The server version would be more random, used as a mild drawback,
and the client version would be meticulous --- in case of leader level change, it would
maximize the chance of spawning a new party member, if the player that can spawn
on any levels (as specified per-level in CaveKind).
data AutoLeader = AutoLeader
{ autoDungeon :: !Bool
-- ^ leader switching between levels is automatically done by the server
-- and client is not permitted to change leaders
-- (the frequency of leader level switching done by the server
-- is controlled by @RuleKind.rleadLevelClips@);
-- if the flag is @False@, server still does a subset
-- of the automatic switching, e.g., when the old leader dies
-- and no other actor of the faction resides on his level,
-- but the client (particularly UI) is expected to do changes as well
, autoLevel :: !Bool
-- ^ leader switching within a level is automatically done by the server
-- and client is not permitted to change leaders
-- (server is guaranteed to switch leader within a level very rarely,
-- e.g., when the old leader dies);
-- if the flag is @False@, server still does a subset
-- of the automatic switching, but the client is permitted to do more
}
