Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs

The autocombat glitch may be partially my fault, depending on what exactly you're talking about. I spent a long time stepping through memory dumps and reverse engineering how the autocombat stuff works to finally find a race condition involving the animation handling -- ref: https://itch.io/t/300782/bug-linux-x86-64-multiple-versions-race-condition-cause... 

The animation actually gets run with autocombat, but it's set to a small value. Autocombat can apply all the moves and end the battle, but since the coroutines are interdependent, on a fast machine one thread can terminate before the other is serviced; here, this meant the battle was ended and characters were removed from the arena prior to the animation completing.

My fix does allow the last move to always complete instantaneously without animation, but I wanted to change as little code as possible -- I didn't exactly have a lot to work with. I would advise extreme caution, because 'here be dragons'. Any complete fix that were to work 100% consistently is very likely going to be quite a bit more work than a check here or there: the combat loop code is kind of a mess (though it actually does approximately work) and needs to be fully decoupled from rendering. If it were chunked into an event dispatch model marshalled by the animation handler, any battle glitches would be solved.

(1 edit)

I should clarify the intent of my post is mostly just a heads-up that addressing combat isn't going to be the easiest thing, nothing more. That said, two thumbs up for putting together fixes for other various annoyances in the game. I quite like this game and feel it's definitely worth attempting to maintain!

I've skimmed your issue, and indeed moving "emit_signal("skillplayed")" lower down seems like it would have caused this issue. But I tested reversing your fix and this autoattack bug still happened, so I think coroutine race conditions are definitely at play. I think that the reason I gave for why my fix works was incomplete. My fix works because it limits possible outcomes by using a variable which is not likely to be subject to a race condition.(accidental success)
I am uncertain, but I think that my fix will inadvertently undo your fix, so it can only be applied safely to non-linux games. As both of us have pointed out a proper fix involves a significant rewrite of combat.