[Solved] Finding fires

[Pi-C]

My water turrets should also attack fires, so they need to find them. Fires don't have health, so I need to place a dummy that can be killed on top of fires. Currently, each turret will scan its area/radius for fires (surface.find_entities_filtered) every 600 ticks and create a dummy at the fire positions.This worked alright during my tests, but now I've got a saved game with about 200 turrets (one right next to the other) surrounding a square area, and UPS went lower than expected.

I suppose it would be more efficient if my turrets didn't have to look for fires, but if the dummies were placed as soon as any fire was created anywhere, even if no turret was near it (the dummies are removed when the fires expire). But the common events like on_build don't trigger on fires. According to the wiki, fire inherits created_effect from Prototype/Entity, but I haven't been able to create dummies with it yet. Perhaps it's a wiki bug and the fire prototype doesn't support this property after all, but perhaps I'm doing it just wrong:

Code: Select all

local fires = data.raw.fire

for name, entity in pairs(fires) do
  entity.created_effect = {
    type = "direct",
    source_effects = {
      type = "create-entity",
      entity_name = acids[name] and WT.acid_dummy_name or WT.fire_dummy_name,
      trigger_created_entity = true
    }
  }
end

Is there anything missing, or can this property really not be used with fires?

[ickputzdirwech]

I can’t answer your question but could you merge all the areas in range of all water turrets so you don’t have to check every tile multiple times if the areas overlap? And if you find anything of interest check which turrets are in range?

[Klonan]

Is there anything missing, or can this property really not be used with fires?

As far as I see, it should work, if its not please make a bug report

[Pi-C]

I can’t answer your question but could you merge all the areas in range of all water turrets so you don’t have to check every tile multiple times if the areas overlap? And if you find anything of interest check which turrets are in range?

There may be multiple separated areas with turrets, and there may also be completely isolated turrets. I've stored their positions. Normal turrets have direction, and I've also stored the area each turret can cover (a bit more acutally, because they don't cover a rectangle but a trapezoid within that rectangle). The special fire extinguisher turrets cove a circular area, but that could be transformed to a square. Still, I wonder how I should merge the areas.

Make a lookup table turrets[x][y]. I could easily get x_min, x_max, y_min, and y_max that way and would get one merged area. But this area may be huge (think of a spread-out base with many outposts far away from the center and lots of empty area in between). There would be just one search running, but on an area that could be as big as the surface. Perhaps it would still be faster.

But there's another problem: Running a search every x ticks means that new fires created between x_n and x_n+1 will not be registered until tick x_n+1, so no dummy will be placed and the turrets can't target these new fires, so the fires will get a good headstart. The saved game I tried used a fork of the Flammable Oils mod, and when the last fire was extinguished, half of a big storage-tank area was destroyed. Even without this mod, the delay caused by not searching on every tick is an inherent limitation that could be avoided entirely if fires would announce themselves.

[Pi-C]

Is there anything missing, or can this property really not be used with fires?

As far as I see, it should work, if its not please make a bug report

Will do, thanks!

[posila]

source_effects directly in TriggerItem are used only by "line" trigger item type and I am not even sure what the point of having it is.
You should go all the way and use action = { type = "instant", source_effects = ... }

EDIT: Ok, so point of source_effect directly in TriggerItem is so it doesn't fire for each entity hit by LineTriggerItem, but just once per repeat_count. So I guess this should work for area and cluster trigger items too, and for consistency for direct one also.
I would consider renaming it to something else, so it is not ambiguous with source_effects on TriggerDelivery.

[Pi-C]

source_effects directly in TriggerItem are used only by "line" trigger item type and I am not even sure what the point of having it is.
You should go all the way and use action = { type = "instant", source_effects = ... }

Thanks for the hint! I guess you meant action_delivery? Perhaps I'm using it wrong:

Code: Select all

 entity.created_effect = {
    type = "direct",
    action_delivery = {
      type = "instant",
      source_effects = {
        type = "create-entity",
        --~ entity_name = acids[name] and WT.acid_dummy_name or WT.fire_dummy_name,
        entity_name = "small-lamp",
        ignore_collision_condition = true,
        trigger_created_entity = true
      }
    }
  }

With just the attached minimal mod, and a flamethrower + some ammo cheated in, Factorio will completely break down when the fire stream hits the ground or trees. I've also tried to use another entity (a combat-bot, just like my dummies), but that didn't change anything.

[Pi-C]

With just the attached minimal mod, and a flamethrower + some ammo cheated in, Factorio will completely break down when the fire stream hits the ground or trees. I've also tried to use another entity (a combat-bot, just like my dummies), but that didn't change anything.

OK, the crash is known and will be fixed for the next release of Factorio. Meanwhile, I'll use target_effects instead of source_effects, as pointed out by Klonan.