Split - effectState.initialTargetedUnitId was defined but the unit was not found

[SoulMuncher]

It's really inconsistent, but I was able to repro it a few times on master branch in a 2 player localhost lobby Happens most consistently when spam casting Split / casting while other spells are currently running

P1 would split a unit into 4, P2 would only see 2 units, and ending turn/casting other spells wouldn't resolve the desync. If p1 targets a unit that exists on their client but not the other player's client, the effectState.initialTargetedUnitId error would be thrown

[jdoleary]

That's odd because split shouldn't change the id of the original unit. Is this during prediction?

[SoulMuncher]

This is not during prediction. I don't think it's changing the ID of the original unit. The resulting split units sometimes have different ID's on each client

Repro'd this again and devUnderworld.units.map(u => u.id) returned a different list of ID's on each client

• Caster-client, notice ID 7, 22, 24 are skipped: [0,1,2,3,4,5,6,8,9,10,12,13,14,15,16,17,18,19,20,21,23,25,26,27,28]
• Non-caster-client, notice no ID's are skipped, and there are fewer units [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18]
• Note that units 0-1 were players, 2-4 were naturally spawned, and everything else was a unit created with split

On the caster-client, the unit with ID=8 was the same unit that had ID=7 on the non-caster-client, and many of the following units on the caster-client had ID+1 when compared to the non-caster-client.

After this, I created a new unit (ID=19 on caster, 18 on non-caster) and then tried to split it. On the caster-client, units with ID's 20+ were made. On the non-caster-client, the error was thrown, and the unit was not split.

Upon End Turn, the caster-client was synced to match the non-caster-client. All of the caster-client's units, unit id's, and unit stats were set = to what they would have been on the non-caster-client. Image scalers/sprite size was not correctly synced (A non-split golem had a sprite as if it were split 3, which it previously was on the caster-client, before the sync)

[SoulMuncher]

Network messages of type SyncPlayers, SyncSomeState, SetPhase, and Spell all sync underworld.lastUnitId. It seems likely to me that the queued up spell messages are somehow interfering with the network message/sync order, so it increments and gets synced back, or syncs forward early and increments an extra time, causing the discrepancy.

@jdoleary do you have any ideas? You're better at navigating the deep engine/networking stuff

[jdoleary]

Hmm that's a good thought. We might need to add some logic to throw away old syncs...