#Placed blueprint positions
1 messages · Page 1 of 1 (latest)
Oh oh oh I’m very interested in how you did this. Does it work for any blueprint placement?
I’m in need of a way to tell if a given ghost was placed as part of a given blueprint this tick.
I'm ironing out the details cause as you can expect with no easy way to do this, it's not perfect. Lots of weird issues regarding entities with offset selection boxes such as inserters.
My reason for making this is detecting if a crafting machine was pasted onto another machine of the same type to detect if the recipe changed, so I have it return the pasted positions of the entities so it is still somewhat "general".
I didn't design this with actual blueprints in mind, rather copy and pasting but it does seem to return the positions as expected for actual blueprints.
The gist of how I do this is with the on_pre_build event, I first check if the players cursor contains a blueprint. If yes, I get a list of all the entities in that blueprint, as well as the mouse position. Using some thrown together code (seriously I'm confusing myself at this point trying to get rotations to work correctly), it gets the selection box of the blueprint as a whole to then figure out the relative positions of all the entities from the center of the blueprint.
This is because when I get the positions of entities from the blueprint item, it is not the actual positions in the world but rather some other grid with 0, 0 being the center of the blueprint (or something along these lines.)
With the relative positions of all entities, I just add that to the mouse position (with some funky stuff regarding selection boxes to figure out if the entities center is in the center of a tile, or on the edge) and whabam, the pasted positions of an entity.
I think you can do more by combining this with the on_built_entity event, but I can't think of any reason why you may do that off the top of my head right now.
As I mentioned I'm ironing out the details regarding rotations. Entities like inserters that have selection boxes offset from the center of a tile are throwing a wrench in how I handle things lol, otherwise it works perfect
Works pretty well I'd say for the most part?
Ah, combining with on_built_entity would be clever because when on_pre_build fires, the entity isn't actually built yet (duh). You can use on_built_entity and iterate through the positions provided to find your entity
Indeed, https://github.com/tburrows13/PowerOverload/blob/master/scripts/poles.lua#L13-L45 was my attempt, but it doesn't actually work correctly
This is all in an attempt at making my own little library of useful things (no clue if I'd upload it) but I'd be happy to share the related stuff
That’s really cool!
Inserters have offset selection boxes? 🫠
Does your code account for flipping too?
My understanding is that until you flip/rotate a blueprint (or maybe until you modify it at all), the blueprint entity positions are just the same as the source entity’s position. Which is mostly what was preventing me from making it work.
If {0,0} in the blueprint was always the same as position in on_pre_build (i.e. all blueprint entity co-ordinates are relative to the blueprint center), the whole thing would be pretty straightforward, just a matter of applying the relevant rotations/flips. But I don’t think that’s always the case.
Such as:
- if it isn’t been modified (as I mentioned above)
- if it has been given an offset in the blueprint edit GUI?
- if it is using snap to grid functionality?
I haven’t checked the last 2 cases but I suspect they’re problematic too.
If that’s all true, then the only way I see to do it is to re-implement the engine ‘get center of blueprint’ function (which I assume exists) which would iterate through each blueprint entity, and average their positions? Maybe it does more, idk.
You’re right about pretty much all of that. I flip it 90 degrees one way until the proper rotation is reached, and then I find the placed positions.
The entity source positions are all the same as the relative positions, it was tricky trying to figure out the rotation though and when it needed to happen. Mostly because the source positions are relative to the blue prints center. Or when you place it, relative to the the mouse’s location (snapped to the center or edge of a tile)
When you rotate a blueprint, sometimes that snapping changes, which means the relative positions also need to account for the moving mouse position. I’m not explaining this well, so TLDR is rotating was hard.
As for flipping, that’s very easy. Just a matter of mirroring the pasted positions across an axis over the mouse positions at the end.
Not quite sure what you mean by modifying a blueprint (rotating?). I actually forgot about offsets in the blueprint gui lol so I’ll have to check that out. Should work the same, or almost the same I imagjne. Snapping to grid should work as well as the mouse position itself is being snapped to the grid which is the most importsnt part
For getting the center of a blueprint I iterated through all entities of a blueprint and checked their selection boxes and getting an overall bounding box. This involves checking prototypes, so there is an opportunity to make a lookup table here which I’d like to do.
You’re on the money pretty much. The bounding box starts at the position of the first entity, and for every entity I just check if its position + its selection box in the top left or bottom right would exceed the top left or bottom right of the whole bounding box. If yes, extend the bounding box.
I also account for tiles, but don’t need to check selection boxes.
Getting the center is as easy as
(right_bottom.x + left_top.x)/2, and the same for y
And yeah, inserter selection boxes are slightly offset in the y direction when placed with no rotation. It’s noticeable if you place 2 next to eachother with different rotations.
Was frustrating, but I believe I’ve got it fixed