| 1 |
@Brackman released an overshooting widget in [url=http://zero-k.info/Forum/Post/243645#243645]this thread[/url]. He doesn't want that thread cluttered and the [url=http://zero-k.info/Forum/Thread/34089]widgets in MM[/url] thread is is messy enough as is, so here is a new thread.
|
1 |
@Brackman released an overshooting widget in [url=http://zero-k.info/Forum/Post/243645#243645]this thread[/url]. He doesn't want that thread cluttered and the [url=http://zero-k.info/Forum/Thread/34089]widgets in MM[/url] thread is is messy enough as is, so here is a new thread.
|
| 2 |
\n
|
2 |
\n
|
| 3 |
Anyway, to maintain fairness, nobody should use it. The only reason anyone should need is latency. It's my knockdown argument against many unit AI widgets ideas, and it's demonstrably a problem here.
|
3 |
Anyway, to maintain fairness, nobody should use it. The only reason anyone should need is latency. It's my knockdown argument against many unit AI widgets ideas, and it's demonstrably a problem here.
|
| 4 |
\n
|
4 |
\n
|
| 5 |
Here are two replays of the widget for Glaive vs. Glaive, one on the server and one in local skirmish: https://github.com/ZeroK-RTS/Zero-K/files/7072013/OvershooterReplays.zip
|
5 |
Here are two replays of the widget for Glaive vs. Glaive, one on the server and one in local skirmish: https://github.com/ZeroK-RTS/Zero-K/files/7072013/OvershooterReplays.zip
|
| 6 |
\n
|
6 |
\n
|
| 7 |
The server replay can be launched easily here: http://zero-k.info/Battles/Detail/1186151
|
7 |
The server replay can be launched easily here: http://zero-k.info/Battles/Detail/1186151
|
| 8 |
\n
|
8 |
\n
|
| 9 |
In local skirmish the retreating Glaive consistently fires at the edge of its range to kill the chasing Glaive. Here is a picture.
|
9 |
In local skirmish the retreating Glaive consistently fires at the edge of its range to kill the chasing Glaive. Here is a picture.
|
| 10 |
https://i.imgur.com/2ZxlJmA.png
|
10 |
https://i.imgur.com/2ZxlJmA.png
|
| 11 |
\n
|
11 |
\n
|
| 12 |
On the server the retreating Glaive shoots intermittently. I ran the test twice and the first one seemed to shoot less than half the time. The second one was a bit better.
|
12 |
On the server the retreating Glaive shoots intermittently. I ran the test twice and the first one seemed to shoot less than half the time. The second one was a bit better.
|
| 13 |
\n
|
13 |
\n
|
| 14 |
The reason is latency. In local skirmish, the widget's commands arrive in the simulation 33ms after they are issued. This allows it to keep the set target command just within the retreating Glaive's range so that it always fires. On the server I have 333ms to 366ms ping. The widget exists on my computer so any commands it issues take 1/3rd of a second to reach the simulation. By this time the command is often no longer within range of the Glaive.
|
14 |
The reason is latency. In local skirmish, the widget's commands arrive in the simulation 33ms after they are issued. This allows it to keep the set target command just within the retreating Glaive's range so that it always fires. On the server I have 333ms to 366ms ping. The widget exists on my computer so any commands it issues take 1/3rd of a second to reach the simulation. By this time the command is often no longer within range of the Glaive.
|
| 15 |
\n
|
15 |
\n
|
| 16 |
In short, the effectiveness of the widget increases dramatically as you go from 366ms to 33ms ping. Maybe it even works fine for @Brackman. His ping seems to range from 166ms to 233ms, lower than mine, and I presume he tweaked the range leeways and velocity predictions to work for him.
|
16 |
In short, the effectiveness of the widget increases dramatically as you go from 366ms to 33ms ping. Maybe it even works fine for @Brackman. His ping seems to range from 166ms to 233ms, lower than mine, and I presume he tweaked the range leeways and velocity predictions to work for him.
|
| 17 |
\n
|
17 |
\n
|
| 18 |
Thus nears the end of the strong part of this post. The unfairness described above seems indefensible. Zero-K isn't about drilling fibre through mountains to be ns closer to the stock exchange. Maybe some more advanced widget could take latency into account, but I am talking about this widget, the one that actually exits, not some theoretical extra. I'm about to talk about that possibility, but nothing said on that front detracts from what is above.
|
18 |
Thus nears the end of the strong part of this post. The unfairness described above seems indefensible. Zero-K isn't about drilling fibre through mountains to be ns closer to the stock exchange. Maybe some more advanced widget could take latency into account, but I am talking about this widget, the one that actually exits, not some theoretical extra. I'm about to talk about that possibility, but nothing said on that front detracts from what is above.
|
| 19 |
\n
|
19 |
\n
|
| 20 |
So, should the widget be fixed to take latency into account? In short, no.
|
20 |
So, should the widget be fixed to take latency into account? In short, no.
|
| 21 |
* Latency inherently reduces the performance of the widget, no matter how smart, because it can only predict what is going to happen and issue commands appropriately. Factors, such as changes in direction, will ruin its prediction.
|
21 |
* Latency inherently reduces the performance of the widget, no matter how smart, because it can only predict what is going to happen and issue commands appropriately. Factors, such as changes in direction, will ruin its prediction.
|
| 22 |
* If the widget maintains enough leeway to account for changes, then players with lower ping will require less leeway. This directly translates to the amount of damage your Glaives deal, before any input from the player, depending on their ping.
|
22 |
* If the widget maintains enough leeway to account for changes, then players with lower ping will require less leeway. This directly translates to the amount of damage your Glaives deal, before any input from the player, depending on their ping.
|
| 23 |
* Writing fancy latency prediction is a waste of time when the whole thing could be a gadget.
|
23 |
* Writing fancy latency prediction is a waste of time when the whole thing could be a gadget.
|
| 24 |
\n
|
24 |
\n
|
| 25 |
Next question. Should the widget be a gadget, or equivalently, would it be fine if we all lived 33ms from the server? We're getting into more arguable territory, but I think the answer is still no.
|
25 |
Next question. Should the widget be a gadget, or equivalently, would it be fine if we all lived 33ms from the server? We're getting into more arguable territory, but I think the answer is still no.
|
| 26 |
\n
|
26 |
\n
|
| 27 |
As @katastrophe says:
|
27 |
As @katastrophe says:
|
| 28 |
[q]I share Randys opinion about the overshooter-widget and want to add another aspect about it: the audio. It makes it a lot harder to percieve what is going on by your ears. In https://zero-k.info/Battles/Detail/1185842 there was a moment at the beginning of the game where an enemy glaive just ran through our base shooting at nothing. I was confused because i thought an actual interaction would take place. Yes, that is maybe a minor issue and yes, it was possible to somehow do that on purpose before (ground-attack), but not to that extend.[/q]
|
28 |
[q]I share Randys opinion about the overshooter-widget and want to add another aspect about it: the audio. It makes it a lot harder to percieve what is going on by your ears. In https://zero-k.info/Battles/Detail/1185842 there was a moment at the beginning of the game where an enemy glaive just ran through our base shooting at nothing. I was confused because i thought an actual interaction would take place. Yes, that is maybe a minor issue and yes, it was possible to somehow do that on purpose before (ground-attack), but not to that extend.[/q]
|
| 29 |
This is a problem I've thought about before, in the wider context of shooting at the ground being free. Having units shoot at the ground all the time is visually and audibly noisy. It's janky and annoying. Shooting at the ground being free is an unsolved problem, one with no good solutions that I've heard of.
|
29 |
This is a problem I've thought about before, in the wider context of shooting at the ground being free. Having units shoot at the ground all the time is visually and audibly noisy. It's janky and annoying. Shooting at the ground being free is an unsolved problem, one with no good solutions that I've heard of.
|
| 30 |
\n
|
30 |
\n
|
| 31 |
Glaive overshoot essentially re-implements the retreat range bonus, with some differences:
|
31 |
Glaive overshoot essentially re-implements the retreat range bonus, with some differences:
|
| 32 |
* It doesn't deal full damage, since it partially depends on spray and is shooting at the ground rather than the enemy.
|
32 |
* It doesn't deal full damage, since it partially depends on spray and is shooting at the ground rather than the enemy.
|
| 33 |
* The range is longer since some of the spray overshoots beyong even its static range.
|
33 |
* The range is longer since some of the spray overshoots beyong even its static range.
|
| 34 |
* It looks a lot jankier.
|
34 |
* It looks a lot jankier.
|
| 35 |
If we wanted the retreat range bonus, then we could just remove the physics hax that prevents it. I don't think having most units routinely shoot into the ground looks any good. I think I am going to end up hampering set target such that widgets can't make Glaive do this.
|
35 |
If we wanted the retreat range bonus, then we could just remove the physics hax that prevents it. I don't think having most units routinely shoot into the ground looks any good. I think I am going to end up hampering set target such that widgets can't make Glaive do this.
|
| 36 |
\n
|
36 |
\n
|
| 37 |
There is more of an argument to be made for Kodachi overshoot. This is what it does without the widget:
|
37 |
There is more of an argument to be made for Kodachi overshoot. This is what it does without the widget:
|
| 38 |
https://i.imgur.com/QmvQGjS.png
|
38 |
https://i.imgur.com/QmvQGjS.png
|
| 39 |
\n
|
39 |
\n
|
| 40 |
It's shooting range is increased slightly be the widget, but it is more in the realm of dealing tickly damage with its fire than hitting the chasing units directly.
|
40 |
It's shooting range is increased slightly be the widget, but it is more in the realm of dealing tickly damage with its fire than hitting the chasing units directly.
|
| 41 |
https://i.imgur.com/F2Na0zb.png
|
41 |
https://i.imgur.com/F2Na0zb.png
|
| 42 |
\n
|
42 |
\n
|
| 43 |
The
fire
spawning
aspect
of
Kodachi
implies
that
it
should
be
very
good
on
retreat,
so
I
think
it
makes
sense
for
the
Kodachi
AI
to
use
this
more
to
its
advantage.
Remember
that
I'm
on
the
weakest
part
of
the
post,
the
part
about
whether
any
behaviour
like
what
the
widget
implements
should
exist.
Speculation
here
does
not
change
the
latency
argument
above.
Using
the
existing
widget
for
Kodachi
is
unfair.
|
43 |
The
fire
spawning
aspect
of
Kodachi
implies
that
it
should
be
very
good
on
retreat,
so
I
think
it
makes
sense
for
the
Kodachi
AI
to
use
this
more
to
its
advantage.
Remember
that
I'm
on
the
weakest
part
of
the
post,
the
part
about
whether
any
behaviour
like
what
the
widget
implements
should
exist.
Speculation
here
does
not
change
the
latency
argument
above.
Using
the
existing
widget
for
Kodachi
is
unfair
if
it
has
anything
like
the
latency
problems
of
Glaive.
|
Brackman's Overshooter is unfair. Don't use it.