Idiotic spring attack behavior

[Forboding Angel]

Googlefrog, you are correct, however, you are not thinking about units with long reload times given attack commands a ways away from the target.

Artillery, bombers, fighters, things like penetrators, etc

[smoth]

how do you know when the unit has destroyed/lost it's target, that is the part of the yadayada I don't know.

here is my current guess
on target(attack command) store id in table.
on death of unit, check table for id, if id is found, it would have a table of all units currently ordered to attck it.. they would reset fire state.

[Google_Frog]

Googlefrog, you are correct, however, you are not thinking about units with long reload times given attack commands a ways away from the target.

Artillery, bombers, fighters, things like penetrators, etc

For most units in most games there is no cost to them shooting extra units when they are unable to shoot at the unit that you told them to shoot at.

Most units in most games. Not every unit in every game. I didn't ignore them, it's just that a significant number of units are not penetrators or bombers. Traditionally bombers are hold fire by default and good players use Penetrators with hold fire.

Try settarget + move commands.

[Forboding Angel]

Hold fire on bombers is a noobtrap, cause they will attack till they destroy the target, then they will happily land in the enemy base.

[Silentwings]

But its not something that can have its default changed because people will all want different things; it's much easier to write some new behaviour than to override some default behaviour. You could set the bombers to 'fly' by default (simplest way I guess is to set airfacs to fly by default), or add some 'return to base if you are an idle bomber' lua.

[Forboding Angel]

This isn't only about bombers, however, they are a perfect case study.

[smoth]

But its not something that can have its default changed because people will all want different things; it's much easier to write some new behaviour than to override some default behaviour. You could set the bombers to 'fly' by default (simplest way I guess is to set airfacs to fly by default), or add some 'return to base if you are an idle bomber' lua.

that is why I am discussing special commands. I can help hammer a few gadgets out for forb.

[Anarchid]

As it has been discussed, this can be implemented, instead as a global unit behaviour rule:

- manual attack order received: unit is forced into holdfire state, current state is stored.
- manual attack order cancelled after unit has entered the "special attack", either due to target death or override: holdfire lifted, unit reverts to previous mode.

[smoth]

*sighs* and you are IGNORING my posts that I am using to flesh it out before I write it. I don't like banging out(hack coding) stuff. I want to sit down and write out an idea, as this is not a dedicated task, I am not committing my brain to it, I am thinking out loud in this thread and hoping for some feedback because after I write this little guy I am going to forget all the rationale behind it.

[Silentwings]

that is why I am discussing special commands. I can help hammer a few gadgets out for forb.

Yes - after reading a discussion in #sy about what forb wants here, I agree that right thing to do is make one or two extra commands via lua.

[Jools]

how do you know when the unit has destroyed/lost it's target, that is the part of the yadayada I don't know.

In both cases it disappears from LOS. There is a callin: UnitLeftLos() --> "unitID, unitDefID, teamID"

[Jools]

The problem is if you want to take out enemy radar with a wombat for instance. It will first fire at other units and then be destroyed by andry enemy mob before shooting at the radar.

But how to handle this? Maybe just make a widget that puts artillery units on return fire (hold fire is a noobtrap).

[smoth]

how do you know when the unit has destroyed/lost it's target, that is the part of the yadayada I don't know.

In both cases it disappears from LOS. There is a callin: UnitLeftLos() --> "unitID, unitDefID, teamID"

AWESOME! thanks for the help jools! this resolves another question!

[smoth]

(hold fire is a noobtrap).

only if a noob is using it.

[Jools]

how do you know when the unit has destroyed/lost it's target, that is the part of the yadayada I don't know.

In both cases it disappears from LOS. There is a callin: UnitLeftLos() --> "unitID, unitDefID, teamID"

AWESOME! thanks for the help jools! this resolves another question!

Just mind, I think also morphing and cloaking triggers that callin.

So a A implies B but B doesn't imply A.

[smoth]

ah! good catch, yeah, no biggie, I just have to be sure to put the tables in GG and be sure to update them with morph etc.

[Pressure Line]

If you are using Lua unit scripts couldnt you just do a check in AimWeaponX to see if the intended target is the target with the user-generated Attack command? And if it is not, just don't let it aim/shoot?

[smoth]

maybe, I am not very well acquainted with the command areas of spring so that may well be a possibility.

[FLOZi]

If you are using Lua unit scripts couldnt you just do a check in AimWeaponX to see if the intended target is the target with the user-generated Attack command? And if it is not, just don't let it aim/shoot?

Or use script.BlockShot(weaponID, targetID, userTarget) last param is useful.

[Pressure Line]

If you do it in AimWeapon you can avoid the sillyness of it pointing its gun at the enemy, but not shooting. If you stop it from ever traversing/elevating its gun, it makes it clear that it is totally ignoring the other targets in favor of the user-supplied target.