FreeGameDev

Seems with the refactoring also a small bug found its way into the game. Luckily no crasher bug this time. The cannon is acting strange.

Problem: The Cannon doesn't rotate anymore and shoots cannonballs into wrong directions and it shoots own creatures. Own creatures do not attack the cannon however.

When did it appear: The bug appeared some commits/days ago already, when generalizing everything into GameEntity. Not sure which commit exactly. Probably when making Trap a GameEntity.

I'd tried to find the cause of this behaviour, but I coulnd't find where the Cannon rotates itself and where I have to look for the code that finds out which objects to attack... I assume that some color comparison goes wrong here.

Maybe the refactoring even "fixed" some other Trap bug/hack that caused this new one to appear, because only the Cannon is acting strange, the fighting code for everything else works fine as always even though everything else was also refactored.

Just startet moving some stuff from MovablegameEntity into GameEntity. Moving position and the corresponding g/setters and semaphores and removing all uneeded 1:1 re-implmentations from derived objects.

This made the cannonballs fly correctly again: "Sub-Bug" no. 2 solved.

The cannon is still attacking own creatures and not rotating, however.

Are you sure the cannon was able to rotate? I would assume that would involve using faceToward somewhere.

I thought that I already saw this, but maybe I remember this wrong (maybe I'm mixing this up with Dungeon Keeper in my head )... faceToword seems not to be used by Cannon.

Let's assume rotating is currently not implmented, then the attacking bug is still left.

This is strange, as the cannon is using the same function as creatures to find enemies, and if it got the wrong colour, it should attack the rooms as well. (Is it doing that?)

Not sure, I never saw the cannon destroying rooms. As far as I can see, it's only attacking own creatures.

How long does it take for a cannon to destroy a room? Most creatures die at first hit.

edit: Yes, the cannon also attacks own Buildings. Just took all creatures into my hand, and after a rathr long wait the forge was destroyed.

how do you handle friend or foe selection? Tags or something else?

The objects compare their color with the color from near objects.

Not sure if this is the best way, however (think of allies: different colors, but no-attack contract).

The attack and ownership system should be reworked into a general ownership handling, anyways, IMHO. The color should not be a property of each individual object in the future, but only of the controlling seat/player. The seat/player should have a list of all objects belonging to him, so that all objects automatically have the color of it's owner. And each object only knows it's owner (then objects can just check if they have the same or a friendly owner). This would also make it posible to easily implemenent features that require ownership changes (e.g. trading or claiming of neutral objects): just move the object from one player list to another player list.

But these changes would require a lot of work if no currently working features should be broken, I believe. So maybe this (and other "engine related" changes) should only be started after the inheritance refactoring is done.

Hum, I was involved in the Canon implementation but that was quite some time ago, note sure I'll understand the code better than you :-/
I can assure you I never made the canon rotate ^^

Ah, ok, thanks for clearing this up. Seems I remember this wrongly then.

I get bug on specific IA32 machine , the canon ownership number is wrongly read, and the game segfaults ... no bl**** idea why :

{l Code}: {l Select All Code}

  is >> tempInt;
    t->setControllingSeat(t->getGameMap()->getSeatByColor(tempInt));

On other machine it does not segfault ,,,,

levels_git/Test.level:

{l Code}: {l Select All Code}

# Traps
1  # The number of traps to load.
# meshName   color      NextLine: numTiles      Subsequent Lines: tileX   tileY
Cannon   1
1
-14   -1


Not sure what could be causing different behaviour, I would guess it tries to get a seat that doesn't exist, which may or may not crash depending on what's in the memory at the specific location.
Why that happens I don't know, but the the player colour value should be checked to be valid before being used in a function that is looking something up using it. From what I remember, there are more places in the map reading code where that should be done.