Factorio Forums

• A generic method to forbid mining tiles if the tile underneath them would collide with the entities on the tile. This could be a flag on the tile prototype or something different.

mrvn wrote:Isn't that similar to mining rails when a train in on them?

Gergely wrote: Tue Aug 28, 2018 8:51 pm

mrvn wrote:Isn't that similar to mining rails when a train in on them?

No, rails are entities and they reference the train that is on them.

Tiles however don't know if there is an entity on top of them while they are being removed. The entities on mined tiles die as soon as they are ticked when it's already too late to undo the tile removal.

In other words, rails are more self-conscious.

So that's why implementing this can potentially impact the performance. When removing a single tile, all entities inside the chunk and neighboring chunks might have to be checked.

mrvn wrote: Mon Sep 17, 2018 7:36 am Do I understand this right? Every tick every entity checks the tiles it stands on and if they conflict with what the entity requires then the entity dies?
That sounds like a horrible design.

Rseding91 wrote: Mon Sep 17, 2018 10:23 am

mrvn wrote: Mon Sep 17, 2018 7:36 am Do I understand this right? Every tick every entity checks the tiles it stands on and if they conflict with what the entity requires then the entity dies?
That sounds like a horrible design.

No.

When a tile is changed the game scans the entities on the tile and destroys any that collide with the new tile.

The problem with "don't mine if any collide" is it has to then scan every time the mining operation starts in addition to every time it finishes.

if (dont_destroy) return false; // mining would destroy building

• The destroy operation for entities is a 1 step operation which means after a single method call, the entity forcefully ceases to exist no matter which part of the main loop the method was called from.
• The entities are in a one way only linked list (and likely are the links themselves) which means you can only destroy them during an iteration of the list.
• You figured iterating the list twice instead of once would largely impact the performance of bots that place modded water fill. I don't yet know how. Would that really impact the performance so much that it is no longer worth this feature?

Rseding91 wrote: Wed Sep 19, 2018 7:01 am Mining a tile can destroy multiple entities which means it can't just "stop mining the tile if it found 1 entity while destroying that can't be destroyed" since it could have destroyed others already.

mrvn wrote: Thu Sep 20, 2018 9:42 amBut even your case seems rather simple. Assuming entities overlap and some can be destroyed and other not. You first scan the area for any entities that may be destroyed and add them to a list. If you don't find any conflicts in the area the mining will succeed and you destroy all the entities in the list.

Gergely wrote: Fri Sep 21, 2018 8:29 am

mrvn wrote: Thu Sep 20, 2018 9:42 amBut even your case seems rather simple. Assuming entities overlap and some can be destroyed and other not. You first scan the area for any entities that may be destroyed and add them to a list. If you don't find any conflicts in the area the mining will succeed and you destroy all the entities in the list.

Ummm....

How exactly do you imagine "adding them to a list" would work memory wise if this is supposed to be extremely optimized?

std::vector to_be_destroyed(4);
for(entities_in_area) {
  if (should_be_destroyed(entity))
    to_be_destroyed.push_back(entity);
}

mrvn wrote: Tue Sep 25, 2018 8:17 am

Code: Select all

std::vector to_be_destroyed(4);
for(entities_in_area) {
  if (should_be_destroyed(entity))
    to_be_destroyed.push_back(entity);
}

As said the normal case would be at most 1 entity since they normally do not overlap. The vector starts of with space for 4. If more than 4 entities overlap the tile and need to be destroyed then the std::vector will allocate memory as needed in amortized O(1) cost per entity.

Gergely wrote: Sat Sep 29, 2018 8:10 pm Careful!

std:vector needs to re-allocate it's array a lot during which it takes up almost double the space.
This might make linked list a better choice because it would be faster, though less efficient on memory.