[Lou][2.0.43] Crash Build check failed

[shunsicker1]

I can't seem to figure out what is happening. I have been having this issue for a while. I play with a list of mods, so if it's something related to that I will understand. What happens is I will be playing, and when I go to place a ghost of an item over something that already exists(ex: replacing a belt with a splitter ghost) it will crash. I have attached the crash log. If it is a mod and I can be told which one it is, I will report it but i feel like it's something in vanilla Factorio.

Thanks in advance.

[pioruns]

Please also share your savefile with exact steps how to reproduce it, so that developers can see exactly what is wrong.

[boskid]

Log looks suspiciously the same as 127533

Main part of the error is this:

Code: Select all

2584.163 Error BuildCheckResult.cpp:148: Build check failed: 3, cant-build-reason.entity-in-the-way(entity-name.underground-belt), entity[[name=transport-belt, type=transport-belt(TransportBelt), position={273.500, -128.500}, direction=North, force=player.unapproved_ghosts, surface=nauvis, setup=false, owned-by-ghost=true, to-be-deconstructed=false, to-be-upgraded=false, simulation=true]], collider[[name=underground-belt, type=underground-belt(UndergroundBelt), position={273.500, -128.500}, direction=North, force=player, surface=nauvis, setup=true, owned-by-ghost=false, to-be-deconstructed=true, to-be-upgraded=false, simulation=false]].

This error basically says that on the map there is a ghost of transport-belt of "unapproved_ghosts" force that is on top of real underground belt of "player" force. This is correctly detecting a fault case because such scenario would be a desync if there would be a real belt of unapproved_ghosts force on a tile next to it as it could connect either to a real underground belt (real belts connect regardless of their forces) or to a ghost transport belt (ghost belt connections need same force) and such connection would not be save-load stable.

Mod that is most likely helping trigger the issue is ConstructionPlannerContinued since this issue involves ghosts of other forces. From what i remember, i was able to reproduce this issue without any mods just by carefully placing transport belt ghosts of player force and ghosts of another force, having those 2 forces be a friend of each other so overlapping ghosts of both forces show for a player and then super force building some entities in a way that causes those ghosts to be replaced with underground belts. (commit with test 20ff61eb, super force building on belts)

[azaghal]

Hey,

This exact crash got reported to me on the mod discussion pages recently (ConstructionPlannerContinued - renamed to Construction Approvals).

For what it helps, using this bit of code helps reproduce it (based on the description, I assume you already have "working" code for this one, but just for the completeness sake):

Code: Select all

local function on_init()
    local player_force = game.forces["player"]
    local friend_force = game.create_force("friend")
    
    player_force.set_friend(friend_force, true)
    friend_force.set_friend(player_force, true)
end


local function on_built_entity(event)
    event.entity.force = game.forces["friend"]
end


script.on_init(on_init)

script.on_event(defines.events.on_built_entity, on_built_entity, {{ filter="type", type="entity-ghost"}})

With this tidbit in control.lua, it is sufficient to place one singular regular belt (not even an underground), and then attempt to force-place a belt at 90-degree angle on top of it. I did notice this didn't used to happen with some older versions of the game. I have tested against 2.0.28 where it worked fine, and the above code and steps crashed the versions 2.0.42, 2.0.43, and 2.0.45. I haven't tested any other versions in-between, though.

Is the crash itself still considered as a game engine bug, though?

On the desync and save-load stable part, I am not 100% sure I understand that part. Normally I have gotten used to desync referring to state (value) differences between two clients (or server/client etc). What I find interesting is that in version 2.0.28 in the scenario I have described, the game will (correctly) mark the placed belt for deconstruction - so that at least seems like a legitimate game state in that version?

Best regards,
Branko