Looks like an issue with a removal existing when the firewall it is trying to remove is already gone. I’ll check it out.
Can you reproduce the crash? If so, would be nice to attach the replay file. I just enabled replay file attachment to forum messages.
I had this problem to. I’m guessing the algo reads in data during the action phase. When you do this and your opponent removes units you need to put in try excepts so it essentually skips the creation of that unit. What I beleive is happening is the serialized_string isn’t being built correctly because of this which is understandable. I think the solution is as simple as putting a try except pass in your game_state.py line 83 where it is trying to parse it.
The quick fix is to do what you suggest and just check contains unit before adding a removal unit.
However, it uncovered a strange engine behavior that is when a firewall dies when its marked for removal it takes a extra frame for the removal unit to disappear. Not sure why its delayed yet, at first glance it doesn’t look like it should. For now I recommend doing what bcverdict suggested if you read action frames.
As for my algo it will only crash if a firewall is marked for removal and dies on the very first frame of the action frame so its very rare to crash. Sadly I didn’t have time today to implement a quick fix but expect a long term fix on monday for the engine.
Nevermind, I had time to at least put a hotfix onto starteralgo but the long-term fix in engine will still take awhile.
Also had time to fix madroxfactor4 (now called madroxfactor4Fix).
Would it also work to verify “and len(self.game_map[x,y]) > 0” on ~line 126 “if unit_type == REMOVE:”?
I think my algo has this crash issue but I’m not sure and it’s rare. I added this line but I’m not entire positive of the behavior.
Ya that should work as well if that’s what causing your algo to crash.