[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

[Rseding91]

I believe this crash was fixed in one of the more recent versions. Does your reproduction still crash? When I test it, it seems to work normally - but I'm not sure if I'm doing it wrong.

[azaghal]

I believe this crash was fixed in one of the more recent versions. Does your reproduction still crash? When I test it, it seems to work normally - but I'm not sure if I'm doing it wrong.

Sorry for the late reply, but looks like this has been fixed. I did a quick test with fresh install and version 2.0.45 (just to confirm the crash), and then the same test with version 2.0.60 (where no crash had occurred).

Thank you for the fix and letting us all know.

Best regards,
Branko