Questions about (fluid) turrets

[Pi-C]

I've made turrets with an attack_target_mask that is set to just one custom mask, and a target entity that has only this same mask as trígger_target_mask

Code: Select all

data.raw[WT.turret_type][WT.extinguisher_turret_name].attack_target_mask = {
  WT.trigger_target_dummy,
}
entity.trigger_target_mask = {WT.trigger_target_dummy}

I've also set turret.attack_parameters.cooldown = 0.5. In regular intervals (default: 600 ticks), I create target entities within shooting distance (i.e. min_range <= target-turret distance <= range) per script. I expected that the turret would start attacking these entities as soon as the first one has been created. However, it may take a considerable time before the turret actually shoots. The targets are right in front of it, but the turret just sits there and ignores them. When it finally does start shooting, it will attack all entities. What can I do against this delay? I don't want to set turret.shooting_target explicitly in the control script, so if there's something I could change in the prototype, that would be the preferred way.

(Just an idea: The target entities are based on simple-entity-with-force, so once they've been placed, they won't move. Could it be that turrets react when they notice that an entity or unit is moving into their attack distance?)

Something else: How does attack_parameters.fire_penalty work? The wiki has this:

Code: Select all

fire_penalty

Type: Types/float

Default: 0

Used when searching for the nearest enemy, when this is > 0, enemies that aren't burning are preferred over burning enemies. Definition of "burning" for this: Entity has sticker attached to it, and the sticker has a spread_fire_entity set. 

Can it only be >= 0, or would burning enemies be preferred over enemies that don't burn if fire_penalty is negative? That's what I would expect, like with health_penalty:

Code: Select all

A higher penalty will discourage turrets from targeting units with higher health. A negative penalty will encourage turrets to target units with higher health. 

However, negative values are not mentioned at al for fire_penalty. Is that a wiki bug, or are negative values really not allowed?

[Squelch]

(Just an idea: The target entities are based on simple-entity-with-force, so once they've been placed, they won't move. Could it be that turrets react when they notice that an entity or unit is moving into their attack distance?)

You could try changing the force of the turrets to enemy, and use the player to test this theory perhaps?

Something else: How does attack_parameters.fire_penalty work? The wiki has this:

Code: Select all

fire_penalty

Type: Types/float

Default: 0

Used when searching for the nearest enemy, when this is > 0, enemies that aren't burning are preferred over burning enemies. Definition of "burning" for this: Entity has sticker attached to it, and the sticker has a spread_fire_entity set. 

Can it only be >= 0, or would burning enemies be preferred over enemies that don't burn if fire_penalty is negative? That's what I would expect, like with health_penalty:

Code: Select all

A higher penalty will discourage turrets from targeting units with higher health. A negative penalty will encourage turrets to target units with higher health. 

However, negative values are not mentioned at al for fire_penalty. Is that a wiki bug, or are negative values really not allowed?

It seems that fluid turrets only seem to be provisioned as offensive weapons. I take it that you want to use extinguishers, so therefore the target priority needs to be reversed? I'm not sure, but there might be a healing turret mod that could give some clues. I might be mistaken however. I would also have the same expectation that a negative value would reverse the priority fwiw.

[Edit]Nope, I was wrong on there being a healing turret. Was thinking of the wrong game, sorry.

[eradicator]

You could try changing the force of the turrets to enemy, and use the player to test this theory perhaps?

Or spawn a bunch of active=false biters already inside the range. (/sudo help spawn)

[Pi-C]

(Just an idea: The target entities are based on simple-entity-with-force, so once they've been placed, they won't move. Could it be that turrets react when they notice that an entity or unit is moving into their attack distance?)

You could try changing the force of the turrets to enemy, and use the player to test this theory perhaps?

The target entities are on their own force, which is neutral towards forces without players (force.set_friend = false, force.set_cease_fire = true) and enemy of all forces with players (force.set_friend = false, force.set_cease_fire = false).

It seems that fluid turrets only seem to be provisioned as offensive weapons. I take it that you want to use extinguishers, so therefore the target priority needs to be reversed?

No, that's OK. The turrets consider fire (or rather, the target entities I create on top of found fires) their enemy, so they attack it. When the target is destroyed, on_entity_died triggers and I remove the corresponding fire. If a fire expires before the target is dead, it will trigger on_entity_destroyed and the target will be removed. No need to reverse things there. But I already have a setting to prioritize fire over enemies, and I wondered if I could optimize that by attaching a fire sticker to the target and setting fire_penalty to a negative value.

I'm not sure, but there might be a healing turret mod that could give some clues. I might be mistaken however.

Good idea, thanks!

I would also have the same expectation that a negative value would reverse the priority fwiw.

Seems logical, but it's conspicuous that negative values aren't mentioned for this value …

[Squelch]

Or spawn a bunch of active=false biters already inside the range. (/sudo help spawn)

Interesting. I was under the impression that active=false stopped all attributes on an entity, and by extension, their force designation. Also, If the turrets do react to moving entities, as posited by Pi-C, then it would have the same negative result. This gives me food for thought and experiment. TIL, thanks.

The target entities are on their own force, which is neutral towards forces without players (force.set_friend = false, force.set_cease_fire = true) and enemy of all forces with players (force.set_friend = false, force.set_cease_fire = false).

Ah that would mean a bit of work for such a simple test

No, that's OK. The turrets consider fire (or rather, the target entities I create on top of found fires) their enemy, so they attack it. When the target is destroyed, on_entity_died triggers and I remove the corresponding fire. If a fire expires before the target is dead, it will trigger on_entity_destroyed and the target will be removed. No need to reverse things there. But I already have a setting to prioritize fire over enemies, and I wondered if I could optimize that by attaching a fire sticker to the target and setting fire_penalty to a negative value.

I see, I did rather try and interpret your goal with some assumptions that you wanted to target the entities on fire rather than unlit. Same outcome in a round about way.

Good idea, thanks!

I couldn't find anything in the mod portal, but something in the back of my head told me there was. A grep of my mod downloads didn't turn anything up, so it must be another game that I was thinking of.

[Pi-C]

Sorry, didn't notice this post before!

You could try changing the force of the turrets to enemy, and use the player to test this theory perhaps?

Or spawn a bunch of active=false biters already inside the range. (/sudo help spawn)

Biters won't be attacked -- turret.attack_target_mask makes sure of that. I could change that for testing, though (and hope I don't forget to revert this before release!).

[eradicator]

Sorry, didn't notice this post before!

You could try changing the force of the turrets to enemy, and use the player to test this theory perhaps?

Or spawn a bunch of active=false biters already inside the range. (/sudo help spawn)

Biters won't be attacked -- turret.attack_target_mask makes sure of that. I could change that for testing, though (and hope I don't forget to revert this before release!). :-)

Yea, i just meant it as test for the "when to turrents start reacting". Assuming they have some kind of sleep state and need to be woken up. In which case it might also be sufficent to given them just one target every now and then instead of completely managing all targeting.