Dungeon Master Forum

Another one : (in CSB, again with worms)
DSB 0.24 Crash :
LUA ERROR: Lua Function sys_ai_near: base/monster_ai.lua:848: Invalid facing 4

I've been looking at the code, and while I can't pinpoint exactly what happened (obviously, a monster on the center tile tried to move into another's tile, but why it didn't get caught before, I can't tell), but I have a couple of suggestions about the function in general.

First, there's a few times it runs a 'arch.size' check, and particularly an 'arch.size == oarch.size' check, which is redundant. if 'arch' is equal to 'oarch', by default their sizes will always be the same.
Secondly, I think this generalized approach is a bit overkill. After you've done the basic size, exvar, and 'max' checks (line 720 in the current code), the function should split into two possible paths - one for size 2 monsters, one for size 1. The fact is, it keeps flip-flopping through -- "do this and do this and do this, but if it's size 2 remember to check this, then do this and that, but if it's size 2, don't forget about that other thing" -- when it doesn't need to. If a size 2 arch has gotten past the checks, it's a given that it's one monster moving onto a square occupied by only one other monster. All they have to do is match face, push the 'oboss' off the center tilepos if it's there, and move the other monster in.
I'm not quite sure how occupied tilepos and face work for size 2 monsters, so I'm not going to presume to write the code, and I'm probably missing something fundamental with this quick-and-dirty idea, so take it with a grain of salt.

RemyR wrote:I can't pinpoint exactly what happened

What happened, exactly, was that a centered size 2 monster tried to move sideways into another monster's square. This is not considered an "easy move" (that is, a move in which each inst in the source tile can just simply move into an open spot in the destination tile) by the code, so it fell through to the special case to handle sideways moves, and centered monsters weren't dealt with. I've fixed that.

RemyR wrote:I think this generalized approach is a bit overkill.

Well, maybe, but this way is actually easier for me to debug, understand, and maintain.

Breaking off into two separate paths of execution is one way of doing it, sure, but then I'd have to duplicate a lot of code: they'd each have their own "easy move" code, their own code to shuffle the other group around on the tile, and such. This way does have a few special cases here and there, but (at least in my opinion) it's not really all that bad. Sure, there are occasional branches of "if it's size 2 remember to check this," but the other way would have a lot of redundant code-- and if it turned out there was a bug, I'd have to fix all that code twice.

As a general principle, I tried to keep this code generic and robust in hopes that it wouldn't break as soon as someone tried to do something weird in a custom dungeon.

Things like "arch.size == oarch.size" are there because I was actually in the middle of experimenting with the possibility of heterogenous monster groups (I make no promises yet!), but I decided to release 0.24 early due to some rather critical bugfixes. It didn't hurt anything, so I just left it there.