Map editor instant deconstruction should raise events

[DaveMcW]

Steps to reproduce:

1. Run this code in the console:

Code: Select all

/c script.on_event({
  defines.events.on_player_mined_entity,
  defines.events.on_robot_mined_entity,
  defines.events.on_entity_died,
  defines.events.script_raised_destroy
}, function() game.print("entity destroyed") end)

2. Enter map editor
3. Make sure Settings -> Instant deconstruction is on.
4. Select Tools -> None.
5. Pick up a deconstruction planner and deconstruct something.

Expected result: "entity destroyed"

Actual result: nothing

[Rseding91]

The map editor destroys the entities when using the "instant deconstruction" option. The same way that an entity destroyed through https://lua-api.factorio.com/latest/Lua ... ty.destroy doesn't raise events by default the editor destroying entities doesn't raise events.

And I'm not going to make it raise events. There's no reason for it to.

[DaveMcW]

But it raises build events!

This results in a user instant blueprinting my compound entity, instant deconstructing it, and complaining that it leaves pieces behind.

[DaveMcW]

Steps to reproduce:

1. Enter map editor.
2. Make sure Settings -> Instant blueprint building and Instant deconstruction are enabled.
3. Select Tools -> None.
4. Make a blueprint of a miniloader. https://mods.factorio.com/mod/miniloader
5. Build the blueprint.
6. Deconstruct the blueprint.

Result: There are useless pieces of a miniloader left on the map.

[Rseding91]

Yes, and that's up to you to solve. The issue you describe is nothing new with the Map Editor. it has existed since for ever when trying to make compound entities and one of the reasons why compound entities are a bad idea.

[DaveMcW]

There's no reason for it to.

I just gave you a reason.

compound entities are a bad idea.

So when is the super-entity that can do everything going to be added?

[Rseding91]

There's no reason for it to.

I just gave you a reason.

A reason I don't consider valid considering the amount of overhead and bloat that has to be dealt with every time a Lua event is fired. I was originally going to have the editor not fire *any* events.

compound entities are a bad idea.

So when is the super-entity that can do everything going to be added?

Probably never. It's just not feasible and well outside of what I want to support modding wise.

[Nexela]

What if destroy in the map editor also destroyed every entity the entity collides with in its collision box? I can't think of anything off the top of my head that could be bad there except very minimal code bloat.

[DaveMcW]

I created a mod to generate script_raise_destroy events for everything destroyed in the map editor.
https://mods.factorio.com/mod/instant-d ... ion-bugfix

For performance reasons, it only tracks entities by request. Here is how to request it to track your entities:

Code: Select all

script.on_init(function()
  if remote.interfaces["instant-deconstruction-bugfix"] then
    remote.call("instant-deconstruction-bugfix", "add", "my-entity-name")
    -- Also supports a table of names
    remote.call("instant-deconstruction-bugfix", "add", {"entity-name-1", "entity-name-2"})
  end
end)

[Rseding91]

Blueprints are made "instant" by calling "revive()" on them once they're placed. That has a built in "entity revived" event. It's no different than any other mod calling entity.revive() during on_player_built_entity().

Deconstruction is made "instant" by calling "destroy()" on them once they're marked. This uses the same event hook that mods get when an entity is marked for deconstruction. It's no different than any other mod calling entity.destroy() during on_marked_for_deconstruction().

[Optera]

This stance about destroy event is why best practice for me became to ignore all deconstruct events and only use valid checks when entities are accessed as that's what we have to do anyway.

Does it work with lack of destroy events? yes
Is it more efficient if every mod does that than offering events? hell no!

[DaveMcW]

Blueprints are made "instant" by calling "revive()" on them once they're placed. That has a built in "entity revived" event. It's no different than any other mod calling entity.revive() during on_player_built_entity().

Specifically, entity.revive({raise_revive = true})

Deconstruction is made "instant" by calling "destroy()" on them once they're marked. This uses the same event hook that mods get when an entity is marked for deconstruction. It's no different than any other mod calling entity.destroy() during on_marked_for_deconstruction().

Specifically, entity.destroy({raise_destroy = false})

All I want is raise_destroy = true.

[Bilka]

Specifically, entity.destroy({raise_destroy = false})

All I want is raise_destroy = true.

Okay, added for the next version.

[eradicator]

Specifically, entity.destroy({raise_destroy = false})

All I want is raise_destroy = true.

Okay, added for the next version.

Thank you very much :).

[Klonan]

Does it work with lack of destroy events? yes
Is it more efficient if every mod does that than offering events? hell no!

Well, that is debateable,

A mod checking his own entity for .valid whenever he needs to access it or do something with it, that is reasonable,
It could happen once every couple hundred ticks, maybe only during some infrequent events (E.G, when a new surface is created).
And .valid is the cheapest API check to do

Every mod hooking every killed and deconstructed event in the case that the entity that died is your special sunflower-turret? Well that is incredibly innefficient,
You might only have 2 sunflower-turrets in the map, you might even have no sunflower-turrets at all, yet your code will still run and slowdown every single event that had the slightest possibility to destroy an entity.

Checking .valid is absolutely what I consider best practice, don't try to be clever and listen to all event so you can 'optimize' you code and skip valid checks, it is really not worth it.
Check valid on everything, entities, players, GUIs, surfaces, forces. Just do it. I do it.

[Bilka]

Gah, it's not (only) about .valid. Not having the event is a problem because it means the leftovers of compound entities can't be cleaned up.

[eradicator]

Does it work with lack of destroy events? yes
Is it more efficient if every mod does that than offering events? hell no!

Well, that is debateable,

A mod checking his own entity for .valid whenever he needs to access it or do something with it, that is reasonable,
It could happen once every couple hundred ticks, maybe only during some infrequent events (E.G, when a new surface is created).
And .valid is the cheapest API check to do

Every mod hooking every killed and deconstructed event in the case that the entity that died is your special sunflower-turret? Well that is incredibly innefficient,
You might only have 2 sunflower-turrets in the map, you might even have no sunflower-turrets at all, yet your code will still run and slowdown every single event that had the slightest possibility to destroy an entity.

Checking .valid is absolutely what I consider best practice, don't try to be clever and listen to all event so you can 'optimize' you code and skip valid checks, it is really not worth it.
Check valid on everything, entities, players, GUIs, surfaces, forces. Just do it. I do it.

That is certainly an interesting and valid approach (pun intended) for some cases. But not every of my moonflowers is entirely scripted (invisible inserters, etc). Sure, i can check valid, and add an on_600th_tick handler to clean stuff up if i miss deletitions. But to give the player the best (visual+gameplay) experience possible i want all visible or invisible component-entities of the moonflower gone *as soon as possible* when it gets destroyed. So i still have to hook all the possibly-destroyed events anyway.

[raiguard]

In the same vein, is there a way to access the vanilla instant blueprint/upgrade/deconstruction outside of the editor? The performance is much much better than my LUA implementation, despite being very similar.

[eradicator]

In the same vein, is there a way to access the vanilla instant blueprint/upgrade/deconstruction outside of the editor? The performance is much much better than my LUA implementation, despite being very similar.

If you're having performance problems you should make a modding help thread instead of hijacking unrelated topics that sound vaguely similar. On my machine i can not measure any significant difference between editor mode and a simplistic lua implementation.

Example code

Takes ~2 seconds for 50k entities:

Code: Select all

/c
local is_ghost = {['entity-ghost'] = true, ['tile-ghost']=true}
local function revive (node)
  return function (event)
    if is_ghost[event[node].type] then event[node].revive{raise_revive=true} end
    end
  end
  
script.on_event(
  {defines.events.on_built_entity,defines.events.on_robot_built_entity},
  revive'created_entity')
  
script.on_event(
  {defines.events.on_player_built_tile,defines.events.on_robot_built_tile},
  revive'tile')

[raiguard]

In the same vein, is there a way to access the vanilla instant blueprint/upgrade/deconstruction outside of the editor? The performance is much much better than my LUA implementation, despite being very similar.

If you're having performance problems you should make a modding help thread instead of hijacking unrelated topics that sound vaguely similar. On my machine i can not measure any significant difference between editor mode and a simplistic lua implementation.

Example code

Takes ~2 seconds for 50k entities:

Code: Select all

/c
local is_ghost = {['entity-ghost'] = true, ['tile-ghost']=true}
local function revive (node)
  return function (event)
    if is_ghost[event[node].type] then event[node].revive{raise_revive=true} end
    end
  end
  
script.on_event(
  {defines.events.on_built_entity,defines.events.on_robot_built_entity},
  revive'created_entity')
  
script.on_event(
  {defines.events.on_player_built_tile,defines.events.on_robot_built_tile},
  revive'tile')

I already tried requesting this capability separately, Rseding shot me down quicker than a drone flying over Area 51, similar to how this thread was immediately dismissed at first.

And the performance problems are real, your implementation doesn't take into account edge cases like trains on rails or item request proxies. Try installing Infinity Mode and place down an enormous blueprint, you'll see the lag.