Next Gen Bombers

Bravo Rollmops !

i slowly but increasingly feel replaced by robots.

Looks good. How does it deal with latency?

Really cool shit, nicely done!

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

WOW nice job, you fixed most of my major gripes about air play at the moment :D

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.

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?

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.

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.

Ah good, nvm.