As for now there is only one function to check the expected collision of some entity, which is going to appear on a map in some position, with other entities already existing on this map. It is a LuaSurface.can_place_entity() method.
My suggestion is to provide more flexible collision checking. As vehicles (which are among the most freely moving entities in the game) seem to check their collisions using rotated collision boxes, I assume that such check is more or less optimized on C++ side. And I hope that there is possibility to provide this check to the Lua API.
The function may take in a rectangle, an orientation (0..1 as for vehicles) and a collision mask of the layers to check collision with and return a boolean result indicating whether there is collision or not.
Allow more complex collision checking
- ArderBlackard
- Long Handed Inserter
- Posts: 74
- Joined: Thu May 05, 2016 12:41 pm
- Contact:
Allow more complex collision checking
Gib dich hin bis du Glück bist
Re: Allow more complex collision checking
It's not that simple. How do you define what collides with a rectangle?
Some entities can be built on other entities and some entities don't collide at all with other entities (ghosts of different forces). There's far more than just a rectangle and a location to see if something collides - which is why the "can_place_entity" check exists.
Some entities can be built on other entities and some entities don't collide at all with other entities (ghosts of different forces). There's far more than just a rectangle and a location to see if something collides - which is why the "can_place_entity" check exists.
If you want to get ahold of me I'm almost always on Discord.
- ArderBlackard
- Long Handed Inserter
- Posts: 74
- Joined: Thu May 05, 2016 12:41 pm
- Contact:
Re: Allow more complex collision checking
I see the point. So if an entity represents the collision parameters in the best way - then what about using the entity name instead of collision_mask in the function I suggested in the initial post?
So the parameters may be a rectangle, an orientation and the name of the entity which parameters will be used for collision checking. It seems even more appropriate, as it would allow defining some dummy entities with desired type and, probably, custom collision_mask to use for collisions checking.
So the parameters may be a rectangle, an orientation and the name of the entity which parameters will be used for collision checking. It seems even more appropriate, as it would allow defining some dummy entities with desired type and, probably, custom collision_mask to use for collisions checking.
Gib dich hin bis du Glück bist
Re: Allow more complex collision checking
That's what the "can_place_entity" is? You can define the direction in the definition of the entity you want to check.
If you want to get ahold of me I'm almost always on Discord.
- ArderBlackard
- Long Handed Inserter
- Posts: 74
- Joined: Thu May 05, 2016 12:41 pm
- Contact:
Re: Allow more complex collision checking
I mean a bit richer check. With possibility to provide arbitrary rectangle size and orientation.
Actually I'm looking to use this function to determine whether a car would collide something on it's route (then probably even possibility to provide the orientation only would be enough).
Still not sure, what would be more performant: checking collisions using single rotated rectangle or approximating collision check using a number of non-rotated but axis-aligned rectangles.
Actually I'm looking to use this function to determine whether a car would collide something on it's route (then probably even possibility to provide the orientation only would be enough).

Still not sure, what would be more performant: checking collisions using single rotated rectangle or approximating collision check using a number of non-rotated but axis-aligned rectangles.
Gib dich hin bis du Glück bist