Inconsistent entitytarget= values in desync reports?

[Klonan]

I cannot create a desync by simply doing global.locomotive_driver = global.locomotive.surface.create_entity({name = "character", position = global.locomotive.position, force = "player"}) global.locomotive_driver.driving = true and then deleting that surface. Neither with /c global.locomotive_driver = global.locomotive.surface.create_entity({name = "character", position = global.locomotive.position, force = "player"}) global.locomotive_driver.driving = true; global.locomotive_driver.riding_state = {acceleration = defines.riding.acceleration.accelerating, direction = defines.riding.direction.straight}; game.delete_surface(global.locomotive.surface);.

If I enter the /c command with our scenario running, I get heuristic fails in heavy mode.

I have spent a long while eliminating code right down to these lines:

Code: Select all

    surface.request_to_generate_chunks({0,0}, 2)
    surface.force_generate_chunk_requests()
    
    for x = -768 + 32, 768 - 32, 32 do
        surface.request_to_generate_chunks({x, 96}, 1)
        surface.force_generate_chunk_requests()
    end
    

if these lines are executed in on_init(), it is MUCH more predictable to be able to cause a desync. In fact I can do it every time if I then do the train command at around tick 20. I think at that moment the chunk is half way generating or something. They don't need to be forced either, that just seems to make it full deterministic.

Well, I would guess its your map gen, and nothing to do with trains.
And since your map gen us using that simplex noise, I would be highly suspicious that is the cause

[rocifier]

Here is my minimum reproducible scenario without any use of random and without any modules:

main.lua:

Code: Select all

function reset_map()

	local map_gen_settings = {
		["seed"] = 123,
		["height"] = 4,
		["width"] = 4
	}
	
	global.active_surface_index = game.create_surface("mountain_fortress", map_gen_settings).index

	local surface = game.surfaces[global.active_surface_index]

	surface.request_to_generate_chunks({1,1}, 1)
	surface.force_generate_chunk_requests()
	
	for y = -6, 6, 2 do
		surface.create_entity({name = "straight-rail", position = {0, y}, force = "player", direction = 0})
	end
	global.locomotive = surface.create_entity({name = "locomotive", position = {0, -2}, force = "player"})
	
end

local event = require 'utils.event'
event.on_init(reset_map)

Open the scenario with heavy mode enabled and paste this in the console:

Code: Select all

/c global.locomotive_driver = global.locomotive.surface.create_entity({name = "character", position = global.locomotive.position, force = "player"}) global.locomotive_driver.driving = true; game.delete_surface(global.locomotive.surface);

Caveat: This driver must be created at a later tick than the chunk requesting, or the desync doesn't occur. Hence doing it in the console. I normally paste this in at around tick 8-15. This line seems entirely optional: surface.force_generate_chunk_requests(). The map size must be at least 4x4

The way I see it the train is just a way to trigger the desync occuring due to the chunks. This manifests in other ways, but using this train driver for some odd reason is the most predictable way to trigger the desync. Once we get to the bottom of this I would really be interested in why that is In fact, the driver even has to be driving.

[Rseding91]

Thanks for the reproduction steps. I was able to reproduce it and it's now fixed for the next version of 0.17.

The issue was: destroying the train kicks the character out of it back into the surface.

Part of deleting a surface is going over every chunk and destroying every entity found. For a given chunk it cycles the chunk until nothing is found to destroy in case destroying one entity creates another. But this logic didn't handle if destroying one entity created another *on a different chunk*.

So then, it would delete all of the chunks one of which had the character on it still and delete the character without doing the proper destroy() call on it and that left the game in an inconsistent state resulting in the desync.

[rocifier]

That's fantastic. Love your work guys.

So is it fixed in a general case, or just for the train driver? After more investigation we have reason to believe there is some other type of entity producing a similar behaviour, and it dies before a soft reset. This also causes a desync. But that one is harder to nail down.

Thanks for the reproduction steps. I was able to reproduce it and it's now fixed for the next version of 0.17.

The issue was: destroying the train kicks the character out of it back into the surface.

Part of deleting a surface is going over every chunk and destroying every entity found. For a given chunk it cycles the chunk until nothing is found to destroy in case destroying one entity creates another. But this logic didn't handle if destroying one entity created another *on a different chunk*.

So then, it would delete all of the chunks one of which had the character on it still and delete the character without doing the proper destroy() call on it and that left the game in an inconsistent state resulting in the desync.

[Rseding91]

That's fantastic. Love your work guys.

So is it fixed in a general case, or just for the train driver? After more investigation we have reason to believe there is some other type of entity producing a similar behaviour, and it dies before a soft reset. This also causes a desync. But that one is harder to nail down.

General.