Dealing with intersecting entities

[elswindle]

I wanted to have a bit of a discussion on how to conditionally reject/accept intersecting entities. Take this blueprint string for example:

bp_str = 0eNqdmt1u4jAQhd8l16Gyx7Ed8yqragU06kaiCQqh2qri3TcpPyplspyTS1ryceKZsY/H/szW20O16+qmz5afWb1pm322/PWZ7evXZrUd/9Z/7KpsmdV99ZblWbN6Gz91q3qbHfOsbl6qv9nSHp/zrGr6uq+r0/NfHz5+N4e3ddUNX7g+ue+HZ1//9IsvRJ7t2v3wVNuMPzWSUp59jMBjfgeRK2Rdvy6qbbXpu3qz2LXb6h4kcgYND1XDD67bQzdK8zEP7lmhO1Si+GmJBfmeToN4UokKCaQSr0EiqUSFlFfI5tC9Vy9TOsrTsJohYi91NwT3639eISby3aImyxpMlwRVV6EhLTleujAhXy+pFDafdQqb0FYtC8um9AQmgKl0rv1wGzLRkHCK27Mydwt1GrS8mSgXmz+rulmcp9R7cPF0RsuTv4VbDc5mv1XnBzFsSHQMnvJJHT+tvkWwODs9zlFDOiYkkiZDosVbilv4FLa8UP1Pqpaa4qksChw8UPB4gQ+5qqZBZJNSx1CFI8K9cmIzXtXoDKUxUhqdpeDhe1geLk9OGLjznHJ4vbEnagSY8OrjcCa8FHmcCZutiDPhiko4s4RjRAQJX4/wKBWGXZYRKL4LweNUsG7NqqavcDzmsTa4fgSPd4F7OSLegZ2bEWjkoRoGrhoh0iaxvgmAerhqHB5vD1eNw+Pt4apxeLw9XEMOD5TH1yAiUHANFUSg4BoqiEBFpulyEivmZ9NFcitWa7r4b4avXbe7tusVuReqBkjzfGzSfWww7DSsbpsD2wiYwAgyOuY/wxMcE75zXhDxC2x/QNSNfWD7AxOYMMs9i0Hcc4icwRX3uLpCyRlciJk4g4swo+EMLsS0VDNHisf78CicZ4ZkOtIzQ9CC9MwQ1JOeGYIG0jNDULZbIGrvKZY85rG2RHpmBFoa0jNDUHaRgaDCQzWMIz0zpK2g2oI/Z4ygIT1pwyGdgbThEDSSNhyClqQNh6CJtOEINBnShkNQS9pwCCqkDYegVPv60meWu7agVgOpYNeN+PiUIvlZvly87stTmNULBweAXo50jVzz2nIa2ea1rtEaw0548fHhijV2Vk8ce3VrZJ6t94itt8ZhhzfXfjiquqDOvZ3R4+VnHSWOQ4zEjb0lIBNH6ZE6S3cGOOY0JZvxE9rSrJO/+xH06ok/2zAQ/ZydvjowxWHb0U4/aaevD0xx6BsxTufQl2ImOGzGO30etWxveYrD7mGcnuWWXR8mOMLms9Pz8Nu9APyy1sBCb2tZYTcqo9Dn/HSPbfnt2luevVfd/uS8SlvEJNGHYUWzcjz+Az5/z8Y=

This is a pretty simple tileable rail grid where the snap distance is set such that the edge straight rails and big pole overlap each other (42, 38). Obviously, this isn't a problem in Factorio and I think this isn't too big of a deal within draftsman except when the entity is circuit or power connectable. In the example above, stitching this blueprint together with itself, you get electric poles that overlap. The blueprint can be imported Factorio as is no problem, but if you want to set up the power connections things start to break because the duplicate poles get deleted even though they had power connections attached to them. You end up with an incomplete power grid.

How do you think this should be handled. I can think of a couple things. First, have the user work within these limitations. It could be by not overlapping any connectable entity when tiling the blueprint but this could cause issues on the boundaries of tiling. The user could also do a pass on the entity list removing offending overlapping entities after adding everything together. Constraining the user seems to be one of the things you are avoiding, so I'm not sure this is a path you want to take.

Second, move the overlap checking code outside of the hashmap and have a separate function to handle overlapping entities so that it can be overridden and allow the user to define what to do in these instances. It would have to be moved out SpatialHashMap because there's no way of communicating with entities to remove/not add that particular entity. It could be added to entities even though the hashmap rejects it due to overlapping. Moving it may be unreasonable due to how SpatialHashMap recursively adds entities.

My last idea would be that SpatialHashMap somehow communicates with the containing class, i.e. Group, with a function similar to on_entity_insert. This function would perform the overlapping checks and could be overridden to give the user the ability to create custom overlapping behavior. Big issue I see here is what would happen when a sub-entity is overlapping another and should be removed? Communicating with Group isn't particularly useful since the entity in question is at an unknown depth in the entity list from the perspective of the group. I suppose the way to deal with that would be to keep track of the indexing down the recursive add and handing it back to the parent. Another issue is that the entity gets added after the hashmap does the recursive add. I suppose these two could be swapped in EntityList.

I feel I'm rambling a bit now, so I'll leave it here. Let me know your thoughts.

[redruin1]

Second, move the overlap checking code outside of the hashmap and have a separate function to handle overlapping entities so that it can be overridden and allow the user to define what to do in these instances. It would have to be moved out SpatialHashMap because there's no way of communicating with entities to remove/not add that particular entity.

This behavior, specifically the separation from spatial "detection" and "resolution" (I guess would be the best terms for them) is now possible in version 1.0.0, Though currently they still exist in SpatialHashMap under the helper function handle_overlapping(). This is done more out of convenience on my end (so I don't have to duplicate the code twice, once for Blueprint and once for Group), but this should now be completely customizable by overwriting an EntityCollection's on_entity_insert() function.

No matter what way you slice it though, it's hard to delegate certain operations, because they are all somewhat integrated with one another. For example, you could argue that EntityList itself should be able to issue overlapping warnings, as it can always just linearly search over it's contents and search for collisions that way. It would be really slow, but if the goal is maximum flexibility, why shouldn't the user be able to choose this as an option?