(fixed?) crash to desktop

[kaypy]

"Monsters cant agree who is boss
This is more than likely a bug in DSB"

log.txt:
AI: Boss 10165 thinks 10095 is boss!
AI: 10095 thinks 10095 is boss
Error: Monsters can't agree who is boss.
This is more than likely a bug in DSB.

uh, is that actually a disagreement?

[kaypy]

(0.81 for the record. I do a bit of AI tweaking for my stairs stuff, but I don't think anything that should be causing problems in the engine-side code...)

10165 is a level transition, several teleporters and a bunch of walking away from 10095 but its not impossible for them to have grouped up.

[Sophia]

The error message is a bit weird, but the actual issue here is that 10165 is being considered the boss of its tile, so its boss should be set to itself (i.e., 10165) but it is instead 10095.

The part that confuses me is that (as you can see in monster.c in monvalidateboss) just before this error is thrown, there is a check that the monsters aren't on the same tile, and it properly invalidates the monster's boss in that case, which causes it to be recalculated. Suppose we have three monsters. Monster B is the boss of the tile, along with A and C. Monster A gets yoinked away by code. Normally, the next time monster A gets a turn, it will detect that it no longer shares a tile with its boss, and will promote itself to be the boss of its new one-monster group.

This means that regardless of whatever distance apart the monsters were (or are supposed to be) they are somehow ending up on the same square at the time this error happens. The macro UNLIKELY there is an optimization to tell the compiler this branch is not going to happen much... and it shouldn't happen at all.

Do you have a way of reproducing this?

[kaypy]

Unfortunately, I cant see reproducing it as any more than random chance. There's nothing I can see that makes it likely here. The critters in question aren't particularly close to start with, and my last save was annoyingly old by the time it happened.

[kaypy]

Grasping at straws here:
What happens if we have monster group A+B and monster group C+D.
Then A+B split, where one of them moves to a new tile and onto a teleporter dropping them instantly into C+D.
Could A+B still be considered a group and one of them a boss long enough to cause some mishap? Or would their boss status get cleared before they split? (Or some other housekeeping take care of things first)

[Sophia]

Normally, that won't happen, because when a monster gets a turn, its boss information is updated properly. However, if a monster group splits, the boss information is set properly by the Lua code, not by the core engine; if you just dsb_move a monster elsewhere, the boss will be invalid. This is not normally an issue, because it will get automatically fixed the next time the monster gets a turn. Teleporters in the base code won't cause a problem because they won't teleport to an occupied location, but this is again a problem that is avoided at the Lua level, so if your Lua code is doing things differently, it might not have the same checks.

If you somehow managed to get two different two-monster groups together on the same square and the old boss got subordinated to the new location's boss but the old boss's subordinate didn't get the memo, this would cause the error to happen. This is an extremely contrived set of circumstances, but it is possible to set this up via dsb_move and a bit of bad luck. So lacking any better ideas, for 0.82 I'll make it so that directly moving a monster via code to a different location will set ai->boss to 0 which will force DSB to recalculate it, and hope this fixes things.

[kaypy]

Nice!

I had a minimal level where I was smooshing groups of critters together with dsb_move, but I hadn't been able to reproduce the issue...