[Bug/Issue?] Return to Initiative Order on Initiative Tie?

[117ksk]

Not sure if this can be helped as it almost looks like a Core/System issue. When a player attempts to "jump back in" the initiative order, they new initiative gets set to the value directly after the current turn. This works very well in most cases. The issue occurs when multiple players share the same initiative value in the tracker. If a player who is currently delaying decides to take their turn after the current turn is over, but there is already another player who ties the current player's initiative, the delaying player gets put at the end of all tied initiatives, not directly after the current player as would be expected.

Is this a limitation with the way the system handles tied initiatives? Or is there a way in this module to ensure a player gets to go next if they choose to jump in regardless of tied initiatives?

[oWave]

Are you using any modules that modify the combat tracker (minitracker, Combat Enhancements, etc)? Those also change the way initiative ties are done (with decimals, the pf2e system uses a separate priority flag).

I don't see what could cause this, unless there's something hidden in the system code. Made 3 actors and assigned them a player user (so they should count as PCs) to test, and it's working as expected there.

[117ksk]

Here is a short clip of what is happening (Rishalou delays, then when he tries to jump back in, it sets him right before current initiative):

https://github.com/oWave/pf2e-flatcheck-helper/assets/113755707/821d9275-afd7-42ca-91ae-9f02160e09b3

I do not have any other module installed that interact with the tracker when replicating this issue. It also appears to happen sometimes and not others when initiatives are tied.

[117ksk]

The above is actually happening with non-tie initiatives as well. I will dig deeper for module incompatibility.

[117ksk]

Here is clip of it breaking with no modules other than dependencies. Looks like a bug with Utility Buttons itself?

https://github.com/oWave/pf2e-flatcheck-helper/assets/113755707/0ff6ab07-3fab-487d-802e-d8a395b3c38f

Screenshot of enabled modules for the above clip:

[oWave]

That is really weird and not even a tie. Might be that the pf2e priority flag isn't set when there's no tie. Will push a fix for that tomorrow (hopefully).

[oWave]

v0.4.3 is ready. I still could not replicate this, so it's a stab in the dark.

If it still happens, could you run this code in your browsers console before and after delaying (starting with a completely new combat)?

game.combat?.combatants.contents
  .filter((e) => e.initiative !== null)
  .sort((a, b) =>
    a.initiative != b.initiative
      ? b.initiative - a.initiative
      : a.flags.pf2e.overridePriority[a.initiative] -
        b.flags.pf2e.overridePriority[b.initiative]
  )
  .map((e) =>
    [e.name, e.initiative, e.flags.pf2e.overridePriority[e.initiative] ?? "-"].join(
      " "
    )
  );

[117ksk]

After updating to v0.4.3, I was unable to replicate the issue for non-ties. However, I am still getting weird interaction when initiatives tie as seen below (not using any other modules than needed):

https://github.com/oWave/pf2e-flatcheck-helper/assets/113755707/e8adbadf-86cf-415c-b0bd-3af4b381aaeb

Looks like it moves people around incorrectly. Tandeji already had a turn but then after Target Dummy returns to order, he gets another one for some reason?

[oWave]

Turns out there's another piece in the system to solve tiebreakers. I rewrote the entire priority setting function to be closer to the way the system handles everything. 94% sure there are no more surprises.