[0.17.31] Certain blueprint flags are ignored for item-request-proxy

[Arcitos]

Dear devs,
i just stumbled upon the following issue:

If i add the "not-blueprintable" and "not-deconstructible" flags to an item-request-proxy, i'm still able to deconstruct those entities with a deconstruction planner.

Steps to reproduce:

1.
Add the "not-blueprintable" and "not-deconstructible" flags to the default "item-request-proxy" in demo-entities.lua:

Code: Select all

{
    type = "item-request-proxy",
    name = "item-request-proxy",
    picture =
    {
      filename = "__core__/graphics/logistic-delivery.png",
      flags = { "icon" },
      priority = "extra-high",
      width = 64,
      height = 64,
      shift = {0, 0},
      scale = 0.5
    },
    use_target_entity_alert_icon_shift = true,
    flags = {"not-on-map", "placeable-off-grid", "not-blueprintable", "not-deconstructable"},
    minable = { mining_time = 0, results={}},
    collision_box = {{0, 0}, {0, 0}},
    selection_box = {{-0.5, -0.4}, {0.5, 0.6}}
  },

2.
Get a deconstruction planner and draw a selection box around an entity with a item proxy above it


3.
Release the deconstruction planner.
Expected behavior: The item request proxy should still be there
Observed behavior: The item request proxy has been deleted

[Rseding91]

Thanks for the report. I don't know if I consider it worth the time to go around making the item-request-proxy respect those flags since by it's nature it only exists to be interacted with through blueprints and the deconstruction planner.

For now, I'm going to say it isn't worth it and leave it as is.

[posila]

I'd say it is for all intents and purposes considered to be a ghost, and ghosts ignore those flags too. Also, in this case, if machine the proxy is targeting becomes marked for deconstruction, the proxy needs to be destroyed anyway.

[Arcitos]

Thanks for the report. I don't know if I consider it worth the time to go around making the item-request-proxy respect those flags since by it's nature it only exists to be interacted with through blueprints and the deconstruction planner.

For now, I'm going to say it isn't worth it and leave it as is.

I'd say it is for intents and purposes considered to be a ghost, and ghosts ignore those flags too. Also, in this case, if machine the proxy is targeting becomes marked for deconstruction, the proxy needs to be destroyed anyway.

Thanks for your replies, guys!
I fully understand your point of view on this topic. I have to admit that i grinned a bit when you wrote about the original intents and purposes of request proxies, because, you know, modders love to ignore all intents and purposes if something goes with their solution...

But please let me elaborate, why this particular "fix" would be extremely helpful: My use case for this is - of course - a mod, which uses script generated item-request-proxies to simulate maintenance requests for machinery. The request proxies are really, really useful for this, as they treat the maintenance/repair demands like additional module requests. Also, it forces the logistical network to use construction robots to get the material to the machines instead of logistic robots - as intended!

Now the one problem remaining is, that dragging a deconstruction planner all over the place and candeling the deconstruction order immediately after, is at the moment a simple way to circumvent my mod's mechanic. But please test it for yourself, if you like
I prepared a small save with a pre-release version of this mod in action.



You would do me a great favor if you would reconsider your opinion on blueprint flags for item request proxies

Thank you for your understanding!