Free Cores Bug

I’m analyzing a replay and for the life of me I can’t understand what’s going on here. https://terminal.c1games.com/watch/1461519

Maybe it’s another cache issue, but I’m trying to recreate this by hand and it’s not adding up. Round 3 Track3.4 get 4.5 cores (4 per turn + 0.5 removal refund), places 4 filters (-4 cores), then has 1.5 remaining. Is this a bug or am I missing something?

Edit: It happens again round 5, 6, 7, and 10. Playing by hand by round 10 I’m five cores behind even though I’m replicating the same moves.

Hypothesis at this point: 1 core is being refunded on seemingly random turns. This extra core is never spent that turn, so the algo does not appear to know about it until it’s informed of its new core value the next turn.

Noteworthy occurrences:

  • Round 11 encryptor placed, only 3 cores spent. (Not just tied to filters)
  • Round 17 0 cores spent, but on the first action frame an additional core is added. (Perhaps not tied to placements at all)

Other rounds this took place: 12, 13, 14, 15, 16, 18, 19, 20, 23, 24, 25, 26, 28, 30, 32.

In total, 22 cores appeared out of thin air (on one side) in 32 rounds.

Reproducible Bug: In round 14 of this game (first occurrence found in that game), an additional core is added. This is the same upload of my algo but a different version of Track (I’m branching out to see if I can spot it in different games/algos).

In round 8 of this game it also occurs. (Different version of mine, different version of Track).

In round 2 of this game is also occurs. (Different version of mine, not a Track algo).

3 Likes

Mm, this is worrying…
I’m seeing it in my games too: in round 11 and 12 of this game I just gain one core out of nowhere.

1 Like

I’m just cherrypicking games to look for this, but those last three games in the post were the first three I clicked on. This seems to happen a lot.

This is the first i’ve noticed this, it definitely a major issue. It looks like sometimes a player is getting 1 additional core at the first frame of an action phase. This will be my top priority, thanks for letting us know. I’ll try to put out a hotfix today or tommorow.

3 Likes

I agree it looks like the first action phase is gifting cores since none of the algos are spending that core the turn they get it. For a point of reference on when this may have been introduced, I first noticed it almost a week ago playing by hand, though I initially wrote it off as error on my part until today.

Ok, we got it I think.

When a unit scores, it calls ‘dealDamage(1)’ each time a unit scores. This function also awards the scoring player 1 core. When a player goes overtime, dealDamage(X) is called, where X is their overtime penalty. A side effect of this was giving the other player 1 core.

Our time penalty actually starts from 0 and increases by one every time-increment you are overtime. This means that dealDamage(0) was being called on algos ‘cutting it close’ to the deadline, awarding their opponents 1 core but having no other effect. You should be able to confirm that on the rounds where this issue happens, the opponent took over 5000ms on their previous turn.

We believe that this issue has been around since launch but was not noticed in the past because a majority of algos did not start cutting it closer to the time limit until a few weeks ago.

We should have a hotfix in later today.

6 Likes

That seems accurate. My algo likes to tow the line around a full 5 seconds most turns, so I wouldn’t be surprised if these has been happening for several weeks (to my algo specifically).

Worth noting, and I think this is what @876584635678890 is asking, is awarding the enemy with cores for a timeout intended?

It was never intended that going overtime would reward an opponent with cores, so we will be preventing cores from being awarded on overtime.

1 Like