[14.22] Teleporting Fire to diff chunk causes desyncs

[Nexela]

Teleporting fire entities to a different chunk puts the game in a bad state

Connect with player 1
/c local fire = game.player.surface.create_entity{name="fire-flame-on-tree", position = game.player.position} fire.teleport({60, 60})
/c game.speed = 5
connect with player 2
After a short amount of time 2 will desync

Rehosting the map fixes it until the next fire teleport

Related viewtopic.php?f=209&t=44299

Workaround - Don't teleport fire entities.

[Arumba]

Relevent desync report from vanilla (*No* mods) recreation:

The attachment desync-report-2017-04-19_10-04-05.zip is no longer available

Also, upon trying to close Factorio, a hard crash and the related factorio.previous:

factorio-previous.log

(4.91 MiB) Downloaded 232 times

Also... because I just want to thank all the people who were involved with helping.... in case anyone is interested, here's a fairly large part of our initial testing. Though do note that it wasn't until the next day that Nexela and MagmaMcFry figured it out. I get the impression their minds worked on it all night long
https://www.youtube.com/watch?v=VDywcWebD-c

[posila]

Thanks for the report and figuring out easy reproduction steps for us

What is your use case for teleporting fire? There are already some entity type that have teleport disabled (anything that connects to pipes, belts, walls and since 0.15 also rails) and I wonder if it is worth spending time to fix teleport or it would be t good enough to block it and instead create new entity that would better fit your needs.

[Nexela]

Used in AAI as a light/pollution generating source

I am not the AAI Author but I am sure this can be changed to destroy/recreate or even a different way all together so just blocking teleport on fire shouldn't be a problem

[edit] With .15 burner sources can be added to entities. Would this allow lamps to have a fuel slot if they have a burner source or am I reading that wrong?

[MagmaMcFry]

AAI Programmable Vehicles uses a "fire" type entity to provide an autonomous vehicle with light, sound and pollution. Basically all we would need is an entity that can teleport around and produce light and sound (we can place pollution manually). However, your response does make me rather curious about how this desync issue is hard to fix. Also I'm not sure how deep this desync issue goes, so wouldn't it make more sense to find out what causes it and fix it instead of just quarantining it and hoping it won't show up somewhere else?

[Rseding91]

Fixed for 0.15. It would actually desync if you teleported any entity with emissions-per-tick defined in the entity prototype.

[Arumba]

Out of curiosity @Rseding91 could you explain how/why? We have been discussing it in our think-tank group all morning and my hypothesis was that the teleport function itself was doing something strange like allowing the pollution to be emitted simultaneously in both chunks for anyone connected, but new players joining would basically say "that's not possible" and 'disagree' with the corrupted game state. Apologies for my layman terminology, but I have been fascinated with this process over the past couple days.

[BenSeidel]

At a guess, each chunk has a pollution change per tick value as well as the current pollution. This is done so that entities like trees and the ground (that rarely change) don't have to be iterated over to calculate the amount of pollution that they are going to produce/absorb per tick. So when you cut down a tree, the polution change per tick is altered. When the pollution is updated, the current value is altered by the current pollution change value. As this tick change value is not saved in the map data, any new player calculates it when loading the map.

I bet that when you teleport an entity with a pollution per tick value the pollution change value is not being updated correctly. This means that everyone who is in the game sees the incorrect value, but everyone just joining has the correct value. After a tick the pollution values are out of sync.

I hope that makes sense.
It's a common optimisation and one that causes all manner of bugs in games. Diablo 3 had one like it with the "super" amulets being destroyed by a death (loss of durability) not removing the special power associated with it. Player could then equip another amulet and get two buffs. They could then repeat until they had all the buffs and slaughter everything in the game.

[posila]

However, your response does make me rather curious about how this desync issue is hard to fix.

Initially I though it is because of optimization we do for some updatable entities (like smoke, fire, corpses) that update just once in a while. These entities are kept in circular buffer on a chunk, and they are not removed from this buffer on old chunk and added to buffer on new chunk. But when I went through the code it wasn't the problem, even though the state is not exactly correct it doesn't cause a desync after all.
Fixing bugs due to broken assumptions in optimized code usually introduces some overhead into optimization. So than it becomes question of use case, if it is worth it to introduce new overhead or not.

Out of curiosity @Rseding91 could you explain how/why? We have been discussing it in our think-tank group all morning and my hypothesis was that the teleport function itself was doing something strange like allowing the pollution to be emitted simultaneously in both chunks for anyone connected, but new players joining would basically say "that's not possible" and 'disagree' with the corrupted game state. Apologies for my layman terminology, but I have been fascinated with this process over the past couple days.

BenSeidel's "guess" is accurate description of what caused desync

[robyoublind]

Fixing bugs due to broken assumptions in optimized code usually introduces some overhead into optimization. So than it becomes question of use case, if it is worth it to introduce new overhead or not.

Some next-level bit of wisdom right there.