[harm_unit_loti] incinerate/drain/leech

[white-haired-uncle]

Since h_u_l supports slowed and poisoned, it only seems logical that it should support incinerated. Not just because it's perfectly logical, but also because I'm lazy and don't want to code a separate event.

Also, it probably makes sense to add support for drains, leeches, perhaps even something like mind_raid.

I wonder if it is not also the place for things like explosive, explosive_slow, etc. Or maybe those should go in systemd, don't want to get too crazy.

[Dugy]

The only problem is that while [harm_unit_loti] triggers on hit events, it doesn't tell them which attack triggered them, so weapon specials don't activate. I can implement that quite easily but I am not quite willing to do so, because it would make many weapon specials much stronger in combination with others, and there are already too many interactions of weapon specials that stack up too much.

[white-haired-uncle]

I guess I don't understand the issue, which is okay. To be clear, I'm not expecting [harm_unit_loti] to know how to handle incinerate and automatically make use of it because the weapon being used has a special, I just want to be able to add incinerated=yes when I call [harm_unit_loti], like I can for slow or poison, so that I don't have to set the status myself.

[Dugy]

For builtin specials like slow, poison, drain etc, it has to be implemented in [harm_unit_loti]. But for event-based specials like Incinerate, it's much easier - just trigger the event that makes this work.

[white-haired-uncle]

        [switch]
            variable=catapult
            [case]
                value="catapult1"  # napalm
{CATAPULT_FIRE}
                [harm_unit]
                    [filter]
                        x,y=$hit_locs[$i].x,$hit_locs[$i].y
                    [/filter]
                    damage_type=fire
                    amount=16
                    #incinerated=yes
                    animate=yes
                [/harm_unit]
                [harm_unit]
                    [filter]
                        [filter_location]
                            x,y=$hit_locs[$i].x,$hit_locs[$i].y
                            radius=1
                        [/filter_location]
                    [/filter]
                    damage_type=fire
                    amount=8
                    #incinerated=yes
                    animate=yes
                [/harm_unit]
            [/case]

So, fire_event with [primary_attack] and [secondary_unit] for the first, then rewrite the second using store_unit so I can iterate over them?

I'm about clueless what goes in [primary_attack], unless perhaps it's a [attack] block with [special] id=incinerate... ?

[Dugy]

For first, you need to use [harm_unit_loti] for anything to be triggered. In [harm_unit], only the eventual kill event is triggered.

Next, to pick the right attack, you can just fill the id of the attack as the only setting in the [primary_attack]. I am not sure if you will need to iterate, having multiple targets should work, but I don't remember if I have it tested with something or not.

[white-haired-uncle]

[harm_unit] accepts slowed= and poisoned=.

In this case then I guess I give the catapult an attack and use it as the primary unit? Right now, I'm just harming the unit, there is no actual "attacker" to hold a weapon. Not sure what I'd do if I was trying to build, for example, a booby-trapped chest (manually edit the victim's stored unit I guess).

[Dugy]

In this case then I guess I give the catapult an attack and use it as the primary unit? Right now, I'm just harming the unit, there is no actual "attacker" to hold a weapon.

Yes. You need a weapon with the weapon special for that to trigger.