LuaSurface.can_place_entity() - ignore deconstruction-marked
Posted: Fri Feb 09, 2018 1:02 am
I've been playing for a couple months, and started paying attention to the community right around the time a lot of potential "belt buffs" were being discussed due to a certain controversial friday facts post. Not that I have any complaints about the fun things I can make with the amazing new splitters, but the thing that occurred to me that I wanted for belts was a "ghost belt planner" to go alongside the ghost rail planner, where you could lay down extensive belt ghosts with a few clicks. So, I made a mod for it https://mods.factorio.com/mod/replicating-belts - it creates transport belt ghosts without needing to hold the mouse button down while "painting" the entire length of the belt by running (or dragging the mouse); you just put "replicating" belts lined up with each other where the ends and corners of the belt need to be, and let the mod fill in the ghosts between them to complete the belt. (if that didn't make sense, the demo video linked from the mod page might be clearer)
I'm using LuaSurface.can_place_entity() to test whether a tile is occupied by any kind of obstruction, to consider those tiles as blocked and needing to be bypassed underground for ghost belt planning (or failing to generate ghosts if there's too much of the path blocked to make a connected belt). This works great for most cases - water, cliffs, buildings, and existing ghosts (when the entity being checked collides with the ghost layer) are all reported as invalid placement locations, and my mod treats them as such and avoids trying to put new ghost belts there, using undergrounds if possible.
The one case I have where using can_place_entity() to evaluate tiles is giving an awkward result for the player is for entities marked for deconstruction - if a deconstruction-flagged entity is the only obstruction in the tile and the tile would be otherwise placeable then I want to let the replicating belts see it as "clear" and place normal belt ghosts, in the same way that an attempt to place a blueprint over deconstruction-flagged obstructions would behave. Currently, if a player's using replicating belts through a forest marked for deconstruction, they end up with a mishmash of undergrounds avoiding the soon-to-be-gone trees.
I can't find a good way to check for "could this entity go here if the deconstructing stuff were gone" - as far as I can tell, I'd need a new parameter to can_place_entity() to have it ignore deconstruction-marked entities, or a new way to test whether a ghost of a specific entity can be placed at a position without collision (an inner_name parameter in can_place_entity(), or a can_place_entity_ghost() function).
I can imagine trying to creatively (hackily) solve this by finding all entities in each tile that can_place_entity() reports as occupied, checking if they're all marked for deconstruction, and if they are, just assuming the tile's unoccupied for belt-placing purposes - but I can imagine that breaking in some odd ways, like when a deconstuction-marked tree is next to some water that still blocks the belt placement - and I doubt the performance impact of all of those extra area-bounded function calls is a tradeoff that's worth fixing this one little annoyance in a mod that I'm trying to keep at a minimal performance impact.
Am I right in thinking there isn't a good way currently in the API to check for whether an entity could be placed assuming completed deconstruction - or am I just missing a better API mechanism to be using to test for ghost placability?
Thanks!
I'm using LuaSurface.can_place_entity() to test whether a tile is occupied by any kind of obstruction, to consider those tiles as blocked and needing to be bypassed underground for ghost belt planning (or failing to generate ghosts if there's too much of the path blocked to make a connected belt). This works great for most cases - water, cliffs, buildings, and existing ghosts (when the entity being checked collides with the ghost layer) are all reported as invalid placement locations, and my mod treats them as such and avoids trying to put new ghost belts there, using undergrounds if possible.
The one case I have where using can_place_entity() to evaluate tiles is giving an awkward result for the player is for entities marked for deconstruction - if a deconstruction-flagged entity is the only obstruction in the tile and the tile would be otherwise placeable then I want to let the replicating belts see it as "clear" and place normal belt ghosts, in the same way that an attempt to place a blueprint over deconstruction-flagged obstructions would behave. Currently, if a player's using replicating belts through a forest marked for deconstruction, they end up with a mishmash of undergrounds avoiding the soon-to-be-gone trees.
I can't find a good way to check for "could this entity go here if the deconstructing stuff were gone" - as far as I can tell, I'd need a new parameter to can_place_entity() to have it ignore deconstruction-marked entities, or a new way to test whether a ghost of a specific entity can be placed at a position without collision (an inner_name parameter in can_place_entity(), or a can_place_entity_ghost() function).
I can imagine trying to creatively (hackily) solve this by finding all entities in each tile that can_place_entity() reports as occupied, checking if they're all marked for deconstruction, and if they are, just assuming the tile's unoccupied for belt-placing purposes - but I can imagine that breaking in some odd ways, like when a deconstuction-marked tree is next to some water that still blocks the belt placement - and I doubt the performance impact of all of those extra area-bounded function calls is a tradeoff that's worth fixing this one little annoyance in a mod that I'm trying to keep at a minimal performance impact.
Am I right in thinking there isn't a good way currently in the API to check for whether an entity could be placed assuming completed deconstruction - or am I just missing a better API mechanism to be using to test for ghost placability?
Thanks!