Add something along the lines pre_final_build_collision_check

[Anfilt]

So my idea is pretty simple for the event. The event is only fired/called after all checks game normally runs determines an entity can be placed, but right before it passes that boolean result to the rest of the game. Then the handler for event checks whatever criteria it wants and just returns false to treat it as a bad placement. Any other value returned from the handler has no effect. (Also might be good to also return a reason message ).

There are advantages to this compared to the current state of affairs. Currently to achieve similar behavior one checks their constraints in the on_built_entity event. Then if they do not pass instantly mine the entity. Some advantages to this is first the entity the player wants to place will look red just like any other entity that normally could not be placed, and would make placing blue prints for entities with additional constraints behave much nicer and consistent ect...

Also just a side note maybe a better name would be something along the lines pre_build_additional_criteria_check ect...

[Honktown]

One problem for the entity to be red: it would have to apply *every time* the entity could be built by the cursor. Filtering for an item or entity specifically might not be bad for singular entities, but to check every entity in a blueprint every time the blueprint is moved would be extremely disruptive for performance unless (maybe) filters could be checked only at the start of pulling out a blueprint, and optimized away to very strict options (area, nearby entities). For an entity or blueprint with off-grid placement for example, every time the player moved their mouse conditional placement would have to be completely checked by Lua.

Checking only when someone places, and printing a flying text would be a lot more efficient than preemptively refusing.

[Stringweasel]

Not to mention, the cursor isn't part of the game state. Meaning it's not possible for a mod to do calculations on the location of an item in the cursor, because it would desync.

In Factorio all clients do all calculations for all players. Meaning if you have Factory Planner installed, and your friend opens the GUI and does something, the code on your PC will also do the calculations for your friend. All clients do the exact same calculations. The problem comes that the cursor isn't part of the game state, meaning your PC won't know where your friend's cursor is, meaning it can't do the calculations. This will result the two saves getting into different states, and thus, desynchronise.

[Stringweasel]

Best workaround is to use collisions, like how Space Exploration very closely dictates which entities can be placed on which surfaces.

[Anfilt]

One problem for the entity to be red: it would have to apply *every time* the entity could be built by the cursor. Filtering for an item or entity specifically might not be bad for singular entities, but to check every entity in a blueprint every time the blueprint is moved would be extremely disruptive for performance unless (maybe) filters could be checked only at the start of pulling out a blueprint, and optimized away to very strict options (area, nearby entities). For an entity or blueprint with off-grid placement for example, every time the player moved their mouse conditional placement would have to be completely checked by Lua.

Checking only when someone places, and printing a flying text would be a lot more efficient than preemptively refusing.

I don't see this being that performance intensive. The script would be returning a boolean. If the script in the mod is that slow, although making the event only fire for certain/chosen would be fine I assume for most use cases. Also the game runs checks already on the ghost/filler entities as moved around by the cursor.

[Anfilt]

Not to mention, the cursor isn't part of the game state. Meaning it's not possible for a mod to do calculations on the location of an item in the cursor, because it would desync.

In Factorio all clients do all calculations for all players. Meaning if you have Factory Planner installed, and your friend opens the GUI and does something, the code on your PC will also do the calculations for your friend. All clients do the exact same calculations. The problem comes that the cursor isn't part of the game state, meaning your PC won't know where your friend's cursor is, meaning it can't do the calculations. This will result the two saves getting into different states, and thus, desynchronise.

I don't see a reason why a mod would need to change the game state in a event like this. All a mod would be doing here is returning a boolean to say if building is allowed or not. It should only be needing to read the current state of things to decide yes or no. So in the use case I am not sure how your thinking a de-sync would happen.

Also there are events that I am pretty sure don't fire across all clients like your thinking. For example `on_load` I am pretty sure only fires for the connecting client.

[Stringweasel]

Thinking about it again, they could probably add a new event for your request without having the cursor part of the game state. It's like a build event, just not successful.

Also there are events that I am pretty sure don't fire across all clients like your thinking. For example `on_load` I am pretty sure only fires for the connecting client.

If you're curious when those `on_load` events fire then you can read more here. And those are events when opening Factorio and joining a game, not how Factorio actually runs in multiplayer. For that you can read more in this Alt-F4 article which explains why all things happen for all players on all clients. Although if you don't trust my opinion then it might not help because I helped write it

[Anfilt]

Thinking about it again, they could probably add a new event for your request without having the cursor part of the game state. It's like a build event, just not successful.

Yea that was my thought.

If you're curious when those `on_load` events fire then you can read more here. And those are events when opening Factorio and joining a game, not how Factorio actually runs in multiplayer. For that you can read more in this Alt-F4 article which explains why all things happen for all players on all clients. Although if you don't trust my opinion then it might not help because I helped write it

I could be wrong, on_load from my understanding at least when reading the API docs only runs on the connecting players client when loading? That's what I mean by does not fire across all clients, and similar vein an event like this could be local to a client.

[Stringweasel]

similar vein an event like this could be local to a client

That may not happen though. If that were the case in the event handler you could teleport your player a 100 tiles away for example. But for all the other clients your player is still in the same position, because they did not receive the event. And BAM! desync.

[Rseding91]

Sorry but this isn't likely to ever happen. Build-check events happen outside the game state 99% of the time and mods are not allowed to touch read non-game-state things. Additionally all build-check related pieces of C++ code are not setup to handle if a mod modifies or invalidates the game state in any way and even beginning to think about changing that would be completely outside the scope of anything we want to work on for modding.