Loading...
  OR  Zero-K Name:    Password:   

Next Gen Bombers

22 posts, 580 views
Post comment
Filter:    Player:  
Page of 2 (22 records)
sort

34 days ago
TL;DR: A new widget allows bombers to hit cloaked units, to target submerged units, and more.

Bombers means here all planes that need Airpad rearm.

Terminology:
FFU = Force Fire ("F") -> click on a Unit,
FFD = Force Fire + Drag -- creates a queue of FFU,
FFP = Force Fire -> click on map Point where there is no unit.

Problems with Bombers

1. Targeting submerged units

Only Raven can target submerged units, but it would miss fast-moving units like Seawolf. Other bombers, despite being able to make some damage by hitting the surface, not only cannot target submerged units (with FFU) but are also prevented to target the surface (with FFP) right above them.

2. Disappearing targets

Often a target will disappear right before a bomber fires, due to either becoming cloaked, or destroyed by something else. In such a situation the bomber will recklessly circle around, at the frontline or even beyond it, and usually will be quickly destroyed. Of course, there are manual solutions for this, such as queuing Move to some back location after issuing FFU command, or, in case of a cloaked target, prompt FFP command to the target's expected location, but this is not ideal, considering that: (1) there could be several bombers, attacking simultaneously, (2) at the same time the air player often needs to micro the nearby Owl and Swifts.

3. Auto-Attack management

Minor issue: Attack Move is repeated until canceled, that is, after rearm, if no player action was done, bombers will attack again the same area. I find it not ideal and prefer for Attack Move command to be one-time action, that is, forgotten after firing.

What this widget does

1. If an attacked unit becomes cloaked, bombers will hit its presumptive location (accounting for last seen position and velocity).

2. Submerged units can be targeted, the water surface above the target will be hit, accounting for units speed and location. Raven (and other bombers) may hit fast submerged units like Seawolf.

3. If a targeted unit got destroyed by something else, and there is not a queued command, the bomber will return to air factory or airpad, to avoid dangerous circling at the frontline.

4. In contrast to 'Smart Bombers' widget (which should be disabled to use this one), this widget not only temporarily turns on the 'Free Fire' state when Attack Move is issued, but also discards the Attack Move command after firing. Thus the Attack Move becomes one-time action rather than a kind of a state.

How does it work





For cloaked or submerged targets, the widget replaces the player-issued FFU command with a series of FFP ones, accounting for bomber's and target's location and velocity, as seen in the clips.

For cloaked targets it calculates their presumptive location based on the last known position and velocity. Of course, if the target has changed direction or stopped after becoming cloaked, the bomber will miss.

The usual commands queue mechanism doesn't work here, because of the repeated FFP commands (CMD.REMOVE/CMD.INSERT wouldn't work), so the widget re-implements the queue. The major limitation is that FFU or FFD commands cannot be queued after Move or other non-FFU/D commands. That is, if they were queued, they will be discarded by the widget. Inserting commands with space isn't implemented either (I never use it for bombers so didn't bother).

Widget
+12 / -0

34 days ago
Bravo Rollmops !
+0 / -0
34 days ago
In the narrow case, auto-lead for ravens to hit units moving too fast to be tracked can be useful. Sure it doesn't work against micro, terrain and likes, but there is some chance that it is on move command.

-------------
I am also reminded of the existence of lead/no lead for various weapons.

It seems useful to have a widget that turn off the auto-leading the target when dealing with placeholder-d targets. Converse, non-leading weapons like impaler can also be made to lead in the off chance that it'd hit something. Finally, a toggle can help against "patrol tanking" of skirm/arty. The placeholder use case imo have potentially for biggest impact.
+0 / -0

33 days ago
i slowly but increasingly feel replaced by robots.
+1 / -0

33 days ago
^^ Leave boring automatizable stuff to robots, find interesting non-automatizable stuff for yourself, just like IRL.
+0 / -0



33 days ago
Looks good. How does it deal with latency?
+0 / -0

33 days ago
I'm not sure what you mean by "how": "how good" or "in what way"?

Regarding "how good", for me it has no issues, except in case of quite a few bombers (say, 4+) getting auto-FFP series, sometimes manual Move command (which should, among other things, cancel the targeting and the FFP-series) would be overwritten by delayed FFP, and I need to issue it again. May be need to add something in the code to solve this.

Regarding "in what way", I don't really know what/how to answer.
+0 / -0

33 days ago
Really cool shit, nicely done!

Can this be put into the base game as a toggle-able widget?
+0 / -0

33 days ago
Wohooo nice.
+0 / -0
32 days ago
WOW nice job, you fixed most of my major gripes about air play at the moment :D
+0 / -0
32 days ago
It would seem that now anyone playing air without this now is at a disadvantage. It is going to be distributed with the game any time soon?
+0 / -0
quote:
I'm not sure what you mean by "how": "how good" or "in what way"?

As in does it account for latency? Does latency make it noticeably less effective? Latency of 500ms is not uncommon and a unit can move 30 elmos in this time. This seems like enough to make a manually targeted Raven miss.

Anyway, I played around and it looks fairly solid so I've added it: https://github.com/ZeroK-RTS/Zero-K/commit/17c674fcace32d2c1d795882d8446b06ebfc7c7c

I renamed it to be a bit more descriptive, and most importantly, to start with the word "Bomber" for searchability. I have found a few things that could be tweaked though.

To me the main value of the widget is that bombers reacquire momentarily lost targets, rather than just fly idly towards their target without attacking. A close second is how it lets bombers drop their bombs against targets that cloaked a split second ago. The long range behaviour doesn't seem to useful though, and can be detrimental.


Here is a case where an enemy was visible in the middle of the dam, then moved south east. What I would want is for the bombers to move to approximately where the enemy was, then sight the target, then bomb it. Instead the bombers fly over the lowlands and bomb empty ground. I would limit prediction to a second or two. It is rare to want a bomber to shoot somewhere based on information more than a second or two old, and for Raven this window shrinks to a split second. If a Raven's target was lost more than half a second ago then firing at the ground is probably pointless, at least if the target was moving.

I also noticed some weirdness with radar and sonar. Radar dots that disappear don't seem to be handled by the widget at all. Surely they should be handled, as target reacquisition is a big feature of the widget. I was also able to get a Raven stuck attacking a point on the sea after it lost sight of a Seawolf. The Seawolf entered sonar range later but the Raven did not update its target.

The underwater behaviour also seems dodgy. Raven isn't any better vs Seawolf with this widget, and arguably it is worse. A Raven targeting a Seawolf tends to hit unless the Seawolf moves approximately forwards for the duration of the bomb. With the widget the Raven hits only if the Seawolf maintains a perfectly straight course. The widget is quite easy to exploit with a bit of micro. For example a circling Seawolf can cause a Raven to drop its bomb about 300 elmos away.
  • Old situation: Raven attack forces Seawolf to move forwards while the bomb drops. Raven is hard to bait. Decisions involved require low APM.
  • New situation: Raven attack forces Seawolf to make any minor adjustment to its trajectory. Raven is easy to bait with APM expenditure, and there are few decisions but implementation requires more APM in all cases.
So basically Raven is worse except against people with moving Seawolves that don't spend the APM.

The situation for commanders strictly worse. A Raven without the widget cannot miss a basic Strike Chassis in the north of Folsom Dam. With the widget, the commander just needs to jink a little and the Raven will fire wildly at the ground. Other bombers waste their shots against deep underwater targets, so there at least needs to be a height check. I'd say the only UI problem being solved here is the fiddliness of using non-Raven bombers to damage shallow targets. In the case of Seawolf we'd probably just have to make it travel deeper though.


There might be a problem with memory usage when 200 bombers attack something in the fog. Performance otherwise seems good.


Your water check is too permissive. This Ravager was able to juke because the Raven shot predictively rather than with its guided bomb.

Here is a summary:
  • Radar dots leaving coverage should be handled.
  • Bombers fly too far off target when they are far away.
  • Firing blind at a target that has been invisible for more than a few seconds seems useless.
  • This is even worse for Raven, and probably shouldn't happen after more than a split second, or maybe ever.
  • Most of the water handling behaviour is bad. In particular, Raven gets worse and other bombers waste shots against deep targets.
  • Take a look at memory pressure.
+4 / -0

32 days ago
I appreciate the thoroughness of your investigation, AUrankAdminGoogleFrog. Though I oppose the rigid RPS balancing in Zero-K, I would appreciate it if you could share some of your opinions regarding Future Wars, if you can spare some time.

Despite the fact that Future Wars is 80-90% balanced, the unit development there is quite impressive, especially for commanders. Just to keep this thread on topic, we can discuss this in a separate thread.
+1 / -0

31 days ago
quote:
Does latency make it noticeably less effective? Latency of 500ms is not uncommon and a unit can move 30 elmos in this time.

This widget was made with the (usually congested) lobsterpot in mind, where, I'd say, if you have high latency, you shouldn't play air in the first place, otherwise your fragile bombers wouldn't survive for long, with this widget or without.

Having said that, if anyone has any idea how to account for high latency, I may look into the way to implement it.

quote:
The long range behaviour doesn't seem to useful though, and can be detrimental.

Agree with the second part (if bombers left unsupervised), disagree with the first. Say, your bomber finished rearm and you see a Firewalker at the front you'd like to bomb. You can Move closer, then issue FFU from the close range (2 actions with couple of seconds between), or you can issue FFU from the beginning, then just keep an eye on the bomber and on the target, and, if a situation looks like the shot would be surely wasted or dangerous, cancel it. I prefer the second.

quote:
What I would want is for the bombers to move to approximately where the enemy was, then sight the target, then bomb it.

This is what the widget does if the target was sighted (and is not submerged). Only if the bomber cannot sight the target in its presumptive location, as when the target got cloaked, it will bomb with FFP.

quote:
Radar dots that disappear don't seem to be handled by the widget at all. Surely they should be handled, as target reacquisition is a big feature of the widget.

Only radar dots that never were in LoS are discarded. That because for such targets the velocity cannot be obtained, and the position is obfuscated, hence there is no way to know where to fly to find them.

quote:
I was also able to get a Raven stuck attacking a point on the sea after it lost sight of a Seawolf. The Seawolf entered sonar range later but the Raven did not update its target.

Is there is a difference between sonar and radar? I mean, isn't UnitEnteredRadar() called for both? If the same callin is activated for both radar and sonar, the situation you described seems like a bug; if there is an additional callin for sonar, it should be added to the widget's code.

quote:
The widget is quite easy to exploit with a bit of micro. ... So basically Raven is worse except against people with moving Seawolves that don't spend the APM.

I'm not sure there is only "a bit" of micro when several subs are attacked by several bombers, almost but not exactly simultaneously, and there is also enemy ships or other non-air units around.

Anyways, may be a toggle-able setting should be added, for Raven, whether use old-way FFU or predictive FFP for submerged units.

quote:
The situation for commanders strictly worse.

Probably need to limit applying FFP to submerged units only if their speed is above some limit (for Ravens only of course).

quote:
Other bombers waste their shots against deep underwater targets, so there at least needs to be a height check.

Agree, probably different heights for different bomber types.

quote:
There might be a problem with memory usage when 200 bombers attack something in the fog.

Don't know what to do about it other than to increase GameFrame interval. Or just to ignore it since 200 bombers doesn't seem to be too frequent situation.

quote:
Your water check is too permissive. This Ravager was able to juke because the Raven shot predictively rather than with its guided bomb.

I'm checking AimPostion.Y < 0. What's better test to decide if the unit is submerged, that is, cannot be targeted by bombers?




+0 / -0
31 days ago
Ummm.... yeah... but ... isnt this supposed to be fun game, and not script vs script FTW?
+0 / -0



31 days ago
quote:
This widget was made with the (usually congested) lobsterpot in mind, where, I'd say, if you have high latency, you shouldn't play air in the first place, otherwise your fragile bombers wouldn't survive for long, with this widget or without.

This can't be the approach for ZK default widget development. Gating unit AI by a bit of latency is too unfair. I suspect the most useful parts of this widget barely care about latency, but how to make the widget fair is still good to keep in mind. You partially could account for latency by adding extra prediction distance to Force Fire commands.

quote:
Agree with the second part (if bombers left unsupervised), disagree with the first. Say, your bomber finished rearm and you see a Firewalker at the front you'd like to bomb. You can Move closer, then issue FFU from the close range (2 actions with couple of seconds between), or you can issue FFU from the beginning, then just keep an eye on the bomber and on the target, and, if a situation looks like the shot would be surely wasted or dangerous, cancel it. I prefer the second.

Look at my first picture. This paragraph doesn't interact with my issue with the long range velocity prediction behaviour.

quote:
This is what the widget does if the target was sighted (and is not submerged). Only if the bomber cannot sight the target in its presumptive location, as when the target got cloaked, it will bomb with FFP.

The widet doesn't move to the approximate location of the enemy. It extrapolates position based on the velocity of the enemy and moves there, even if the new position is halfway across the map.

quote:
Only radar dots that never were in LoS are discarded. That because for such targets the velocity cannot be obtained, and the position is obfuscated, hence there is no way to know where to fly to find them.

By "the position is obfuscated" do you mean that it is technically unavailable in callins? In which case a PR for gadgets to report this would be required, although I vaguely recall one already happening. As for obtaining the velocity, I don't think this matters as much as you make assume. There is a pretty simple way to find a disappeared radar dot that works most of the time - fly to where the radar dot disappeared.

quote:
Is there is a difference between sonar and radar? I mean, isn't UnitEnteredRadar() called for both? If the same callin is activated for both radar and sonar, the situation you described seems like a bug; if there is an additional callin for sonar, it should be added to the widget's code.

Yes, I was reporting a bug.

quote:
I'm not sure there is only "a bit" of micro when several subs are attacked by several bombers, almost but not exactly simultaneously, and there is also enemy ships or other non-air units around.

Anyways, may be a toggle-able setting should be added, for Raven, whether use old-way FFU or predictive FFP for submerged units.

This line of reasoning doesn't tend to fit in ZK. Sure, some trivial bit of unit AI becomes harder and harder to manually implement in hectic situations. That doesn't have much bearing on whether units should be non-stupid though. Dodging a sea targeted Raven bomb is trivial for a Seawolf. I even refute your claim directly, is that dodging a lot of Ravens also seems pretty trivial.

quote:
Don't know what to do about it other than to increase GameFrame interval. Or just to ignore it since 200 bombers doesn't seem to be too frequent situation.

The thing is that a problem isn't going to suddenly appear at 200 bombers. If a performance issue is linear with units handled and we have 20 widgets that each tend to handle 10 units, then it is like we have 200 bombers, but the debug view would be too messy to find the 20 widgets. The 200 bomber check is for finding an issue. It may turn out that the excessive memory pressure is justified (eg maybe this is the overhead of adding and removing commands), but it is still worth investigating.

quote:
I'm checking AimPostion.Y < 0. What's better test to decide if the unit is submerged, that is, cannot be targeted by bombers?

I don't know, look around.
+0 / -0
31 days ago
quote:
AimPostion.Y < 0

Haven't seen the code, sorry if this is way off but... If Y = 0 is unit's position at sea level, then a Y < 0 is just touching water, and Y + Unit Height < 0 (or rather, I think I'd want to use the unit's hitbox height) is how I would define submerged.

In other words, I don't think anything that has even a pixel above water should be considered by the widget to be an underwater target.
+0 / -0
30 days ago
Great job! It is a clear improvement to the default behavior! It can also be improved further in various ways.

If you want an easy way to reduce memory usage, you don't have to store the human name of every single bomber separately. Just remove the name attribute of bomberClass. That won't fix the high allocation rate, though.

If the widget is reloaded, it forgets about all bombers that have been built in the past. Maybe you want to call the UnitFinished function on all your units at widget initialization.
+0 / -0

30 days ago
quote:
Maybe you want to call the UnitFinished function on all your units at widget initialization.

I call UnitGiven (line 562)
+0 / -0
30 days ago
Ah good, nvm.
+0 / -0
Page of 2 (22 records)