archers shooting own units

[uuu]

megapack (and similar) techtree improvement: archers shooting own units

Some ranged units use "attack-start-time" property, for example file:
(data dir)/techs/megapack/factions/tech/units/archer/archer.xml
uses code:
<attack-start-time value="0.5"/>
This means unit "archer" of faction "tech" takes some time before it shoots. However, if enemy unit dies between start of attack and time unit shoots, unit shoots anyway. In the meantime own unit could move into that spot, taking the shots of own/allied ranged units, possibly dying.

Schema (A - archer, E - enemy):
AAAAAA
E
shooting, enemy dies, archer moves:
 AAAAA
A
some archers are still shooting, archer dies of friendly fire
 AAAAA

This leads to strategy of "cannon fodder", i.e. producing cheap mellee units that are supposed to die anyway, together with ranged units. Producing more expensive mellee units is wasting of resources: they die either because of enemy, or because of friendly fire. They die even if they are much stronger (armor, health points), because they take all the friendly fire.

I myself developed this strategy while playing MegaGlest, and, as some of you might know, I can play pretty good.

I am making this suggestion, because even though it gives me advantage during game play (I realized internal workings), it would be more "fun" if this doesn't happen, because almost all expensive mellee units are not produced at all by advanced players. Lower number of different units used - less possibilities, less fun.

I suggest lowering attack-start-time value for every ranged non-splashing unit in megapack (titi, what do you think?), or any other pack where author agrees to it.

To easy the testing process, I prepared map+scenario as the showcase - see attachment.
Tech tree archers: original value attack-start-time value="0.5"
Test results:
Bad:
0.5 ... one archer HP=534/700 (enemy), one archer dies (friendly fire)
0.4 ... same as 0.5
0.3 ... one archer HP=440/700 (enemy + friendly fire)
Good:
0.2 ... one archer HP=535/700 (enemy)
0.1 ... no damage taken at all

Also note that if 0.2 is good or not might depend on the speed of mellee unit fighting in front of archers. I therefore suggest 0.1 and lower, however I am open to arguments based on scenario tests.

Attachement:
scenario: aaa_archers_test.xml
map: empty_2p_32x32.gbm
I don't see any "attach" in this forum, so here is file "mg.7z" in base64 encoding:
N3q8ryccAANo1JHx0QIAAAAAAAAjAAAAAAAAALBu5L8AHg/LhxHYzmaRD4Meyv17M9R/6bfaKLIqE47+cDBISITTiTFWOjWAYtLTFmBY+Wj/EB56GctfBOiVz3h8wTwAXNTM24PSngNn43dPiFpt6F654uIyTCXxunIjpasxxnkek5fR/fKtnoXlITRQfueHTgk4q6/Tsr5osstyCZG0do8kItvFjbCxK3j5q0XlE81iaflnv/hNoOEUxkPAg/VeF2egfYA4DJQ560VRGZQG9rUIU6JFIggmcgc26Se5HU4Hp135GmeFclxzTkF9urp7s0RlBvHg/cH9emgKgXqijv0D5cx+HxPTPoTuL7jVNg74JbyJHL/bxnAdYDf+ehccHZRICMKGQbyEMcGkU7waX207e2/rOpaJDg9bCpunh4oF+6KFcvuL/tuPz/4gW6lj4ZSVo2oCusy3W3kaZETSMXSfLB3+K3ZlbaD+RFL7IZATz+gDesUadZ6yYPKD5oENdXqkQdjZwc34tuErhfpIXUt3Yo53Q/EpK5feBWVd/w64wMkrO9whZGlM7raUZABt1CInnU98z+gu7oflm+ynVQgegE5WvG7kEymWxO7BAs2iTwNyS+hsyfMcvWhmC8QHYXykkeerYEiMeuzAJvLQxag0oT605j+25Dhghjff5jFpH+zlSwoxAgqXoO1n6KAG/1XXIkjCvoQ4HLlO9BVzB2Sk0MAJ4jAEE+GbwDm83Ha0s4Ys5bTt1w5KLg7JJFlDUrXjoshInQ3S+9G0ODCK4ZE+wN9u4CAfsqdibPOFYIbeaDIeYcsrywOEAAAAgTMHrg/VRHvH1yTT/rN+L4mSvr4+J5LNAipwpWjRMKVLOvUXwnuFlFY04NWPOeUnXD9YMeplxn++VZ/uDvRcPGSWvQljrQE0GuIl2ygVc4Mk0trB4ymR7YFfh8tmL1MqAXc2R6wbpilkZyS8motvGeledAuyYmTeDFsXggBxmGkdKH8eFwaCSwEJgIYABwsBAAEjAwEBBV0AEAAADIClCgHyNmpPAAA=

[MoLAoS]

Couldn't you just change the code to cancel more effectively if the target is dead?

Personally something I dislike about all Glest games is that ranged attacks can miss. Its totally unrealistic the way it happens because arrows travel much too fast for that. Certainly arrows can miss, but its not the same since that should happen even if the unit is standing still in that case and it doesn't. Plus it makes ranged units generally inferior.

[-Archmage-]

We can't do this, it would cause the arrow to shoot before the archer actually is seen shooting it. The real solution is to have the attack be automatically redirected to the next enemy, or cancelled once the enemy' he was firing upon has died. Increasing the speed of the arrow projectile is the only option in the XMLs and that would hardly help.

Friendly fire happens, the bigger issue with archers is that they are incapable of hitting a moving target unless it is moving very slowly.

[Ishmaru]

The real solution is to have the attack be automatically redirected to the next enemy

This ^

[MoLAoS]

We can't do this, it would cause the arrow to shoot before the archer actually is seen shooting it. The real solution is to have the attack be automatically redirected to the next enemy, or cancelled once the enemy' he was firing upon has died. Increasing the speed of the arrow projectile is the only option in the XMLs and that would hardly help.

Friendly fire happens, the bigger issue with archers is that they are incapable of hitting a moving target unless it is moving very slowly.

That last part is amazingly true.

As far as redirecting, that wouldn't work because you would have to initiate the command again to make the archer turn and face the target anyways so you might as well just cancel and let it pick a new target again.

Cancelling should be easy enough though, doing an isDead() check on the target and then not running the animation.

[uuu]

We can't do this, it would cause the arrow to shoot before the archer actually is seen shooting it. The real solution is to have the attack be automatically redirected to the next enemy, or cancelled once the enemy' he was firing upon has died.

You are right, I wasn't watching animations :-( The only solution really is outside the *.xml, to cancel attack once the enemy unit died, between start of attack and shooting (attack-start-time).

Increasing the speed of the arrow projectile is the only option in the XMLs and that would hardly help.

Yes, there is long-standing bug that makes it impossible to have higher values (above cca. 30) of projectile speed, because it would miss. And it's much "nicer" to see arrows flying.

Couldn't you just change the code to cancel more effectively if the target is dead?

Personally something I dislike about all Glest games is that ranged attacks can miss. Its totally unrealistic the way it happens because arrows travel much too fast for that. Certainly arrows can miss, but its not the same since that should happen even if the unit is standing still in that case and it doesn't. Plus it makes ranged units generally inferior.

Actually, it makes ranged units alone inferior, with cannon fodder they are quite superior.
If you want realistic way, there are many other problems - you can really shoot precisely with bows, and thus you can't shoot near your units. However, I agree that at certain low range it would be very helpful to not miss. Possible solution - have different animation speed of projectile (nice arrow flying) and different update speed of projectile (and fix the high-speed bug).

[uuu]

Cancelling should be easy enough though, doing an isDead() check on the target and then not running the animation.

I am thinking something like edit "source/glest_game/world/unit_updater.cpp":
if(attackStartTime>=unit->getLastAnimProgressAsFloat() && attackStartTime<unit->getAnimProgressAsFloat()){
 startAttackParticleSystem(unit);
}
Maybe some "unit->targetRef.getUnit()->isDead()" check? I am not mg developer, so I might be easily wrong, but maybe it would be something in that spirit.

[MoLAoS]

Cancelling should be easy enough though, doing an isDead() check on the target and then not running the animation.

I am thinking something like edit "source/glest_game/world/unit_updater.cpp":
if(attackStartTime>=unit->getLastAnimProgressAsFloat() && attackStartTime<unit->getAnimProgressAsFloat()){
 startAttackParticleSystem(unit);
}
Maybe some "unit->targetRef.getUnit()->isDead()" check? I am not mg developer, so I might be easily wrong, but maybe it would be something in that spirit.

I haven't actually looked at the MG code. But that is what I would do assuming isDead() exists.

[uuu]

I haven't actually looked at the MG code. But that is what I would do assuming isDead() exists.

Actually, I looked, and isDead() exists, as well as other parts I wrote. But I don't have set up build environment, neither I am sure about the internals (e.g. is animation and update logic separated?), so that's why I am unsure.

[Ishmaru]

As far as redirecting, that wouldn't work because you would have to initiate the command again to make the archer turn and face the target anyways so you might as well just cancel and let it pick a new target again.

Cancelling should be easy enough though, doing an isDead() check on the target and then not running the animation.

Canceling is problematic for attacks that consume EP, especially high amounts of EP (30,50,100+) That's an incredible amount of time wasted for an attack to be canceled.

[MoLAoS]

Well obviously we would refund the EP of failed attacks. Although it may make more sense to deduct the EP after the attack hits anyways.

[-Archmage-]

Although it may make more sense to deduct the EP after the attack hits anyways.

The attack really should be redirected, only cancelled if there are no more targets. Just pick the next target, continue the animation and rotate towards the target like any other attack.

[Ishmaru]

canceled will be better as long as do is not deducted till projectile is fired.

[titi]

I also thought about this very often, but I never had a real solution because:

1. Imagine the arrow is automatically targeting the next living enemy in range:
In this moment the range units get more and more powerful, because they kill more effectivly than before. so people will try to get even more range units than now.
And the animations will look very strange: imagine an archer targetting a unit in front  of him. If this unit suddenly dies he will shoot the next unit in range, which is maybe directly behind him. In this case the anymation will for example look like he shoots to the west, but in fact he shoots to the east. This will look very strange

2. Imagine the attack is aborted:
Real abort is ok, but if you stop the attack very direct, you more or less get the same problem as desrcibed in A .

3. ( and this might work)let the shot be finished, but wihout any effect ( no ep costs, no effects ):
But this will look ugly too :-(.

So my conclusion always was that the current state is not as bad as it seems when you first look at it.  And people arrange with it by playing with exactly this strategy uuu described. I would not mix this with the problem that some advanced meelee units are not used by the players. This is more a balancing issue. For example in magic the Behemot is used a lot more now, because I gave him a lot more armor than he had before.

[-Archmage-]

1. Imagine the arrow is automatically targeting the next living enemy in range:
In this moment the range units get more and more powerful, because they kill more effectivly than before. so people will try to get even more range units than now.
And the animations will look very strange: imagine an archer targetting a unit in front  of him. If this unit suddenly dies he will shoot the next unit in range, which is maybe directly behind him. In this case the anymation will for example look like he shoots to the west, but in fact he shoots to the east. This will look very strange

You simply slow the animation(automatically, not in XML) and have the archer rotate and shoot(finish the animation). Obviously you'd have to slow the animation down more in some cases because he'd be so close to shooting he'd flip around instantly and shoot. You could set a max rotate rate on units, something reasonable.

Another possibility is automatically reversing the animation, then retargetting and starting it again.

[titi_son]

Shooting your own units is a problem. The only expensive melee units that are not worth it are the knight and the ghost_armor or which units do you mean? I dont know any other...

[Coldfusionstorm]

1. Redirecting Attacks is a big no no.
Imagine a arrow flying around like a heat seeking missile?. no.

2. Friendly fire is fine, And a nice mechanic for killinge huge armies and/or defending a base when you are behind.
(please notice that when you are confined to your base your economy is already being punished in that you are inside and he is outside free to take the entire map.

3.Perhaps it's time to fix this bug.

4.I Doubt getting the bug fixed will remove arrows from your sight, you will still be able to see them travel, but it will be nice for faster missile type attacks, lasers and such.

Actually i kinda see this as a feature request.

What is REALLY being discussed here is two different types of attack.

Slow friendly fire attack.(and even then you should give the modder the choice to let it not give damage unpon missing it's original target).
Vs The
Fast Guranteed to hit missile(wich can be given spalsh damage in the particle xml if desired.)

[Omega]

1. Redirecting Attacks is a big no no.
Imagine a arrow flying around like a heat seeking missile?. no.

Redirection would obviously have to be an option in the projectile XML. It wouldn't make sense for an arrow, but might for magic. GAE had a tracking option that allowed projectiles to change course for moving targets. Tracking projectiles could still be avoided by very fast units (limited amount of tracking).

[Coldfusionstorm]

1. Redirecting Attacks is a big no no.
Imagine a arrow flying around like a heat seeking missile?. no.

Redirection would obviously have to be an option in the projectile XML. It wouldn't make sense for an arrow, but might for magic. GAE had a tracking option that allowed projectiles to change course for moving targets. Tracking projectiles could still be avoided by very fast units (limited amount of tracking).

I agree, This sounds like a good idea.

But how is it going to fit in the XML.
This requires some thinking.

What about making a system for tracking what can be targeted and not?. Basically im thinking filters based on a skill, so that you can set filter for what the skill/and/or Command can target.

<skill name="dull">
datatatata
"targets" ="allied","Enemy"
</>

And then you can define how the projetile flys in the Projectile XML.

(Im sorry if this is a little rough, it's late for me atm).