Non-Physical Cover System


A non-physical (that is, not based on engine physics) cover system, whereby units near certain features take less damage from attacks.


First version complete (gadget disabled by default).
Crude display widget.


  • Certain tagged features will provide cover within some radius.
  • Cover reduces the damage taken by mobile ground units within that radius.
  • If a unit is within the radius of more than one source of cover, it takes the best of them.


  • Performance. Performing lengthy unit searches during UnitPreDamaged is not a good idea.
    [*]Object-based or sector-based? How much of the map and how many cover-providing features do we expect?
  • Probably best to store cover status about each unit and do staggered updates every x frames.
    ]Types of units. Perhaps different types of units should have different cover benefits… although this could quickly become complicated (and possibly performance-intensive) if arbitrary, explicit categories are used. Perhaps a unit tag controlling how well it benefits from cover?[/:m]
    ]Different cover shapes?[/:m]
    ]Units do not benefit from cover if the attacker is in the same piece of cover? Could complicate things though.[/:m]
    ]Improve display widget.[/*:m][/list:u]

Alright, it’s now minimally functional. Give a feature customParams cover_strength > 1, cover_radius > 0, enable the gadget and widget, and try it out.

Didn’t older sandbags offer this at one point?

Obviously units firing out of a zone should not be subject to the effects of that zone, while those firing into said zone should be, but what of directional cover effects?

With the new hit volume types, physics-based sandbags may be more feasible, although probably still tricky. Lua-based directional cover is possible in principle; you’d have to keep a list of what sources of cover each unit is benefiting from and check them at run-time, which may be expensive if there are many sources of cover. Although I suppose if you restricted it to the four cardinal directions (or indeed any finite set of directions, within reason) it wouldn’t cost too much performance.

This should be tied into the suppression system, i.e. cover reduces suppression instead of / as well as damage. Will also replace the tank ‘fear shield’ implementation which doesn’t really work at all currently.

This is probably easier said than done, however. Might even be easiest to re-write suppression as part of this gadget.

I could always expose a unit’s cover via GG or UnitRulesParam (actually I should probably do this regardless); that way we wouldn’t have to do it in the same file. Also I hear that partial or perhaps even full Lua replacement of COB will be possible in 0.80.

Well, only part of the complication is the supression system being split across lua and cob.

tbph I can’t quite remember the issue. :blush:

Question: do we want cover to be directional? I.e., the option to make it so that cover has to be in the same direction as the firer for the target to benefit from it. It would be more realistic, although it would also be more computationally complex and possibly less easy to use.

I think it would possibly be useful, even if we only used it for selected things.

If you’re up for coding it, that would be great. That makes rather more intuitive sense for larger units particularly. If you managed it, we could also potentially use this system for LoS cover, which is even cooler (urban combat! waaaaagh!)

Coding it is easy; it’s coding it to run fast that’s the tricky part. Simple directional cover shouldn’t be too bad, though, as long as we don’t have too many large-radius cover sources. LoS cover, on the other hand, might be a bit difficult to make a fast implementation for in Lua (it requires our own implementation ray-tracing). If we do want LoS cover, the following things will help performance, at the cost of flexibility:

  • Keeping it 2D (instead of 3D).
  • Keeping the number of sources of LoS cover down.
  • Guaranteeing that sources of LoS cover are not created or destroyed during the game. This would make it easier to build, for example, a bounding area hierarchy to speed up ray traces.

That kind of defeats the purpose (which was to implement smoke shells btw, among other things like mentioned urban combat).

Ah, I see. In that case, we could put temporary cover into a separate linear-search system, and permanent sources (if there are enough to warrant doing so) into a sublinear system (requires some precomputation though).

Will there be a massive performance hit if I apply this to all of the vehicle corpse features?

I expect the major cost will be the calls to GetUnitsInCylinder; the rest should be negligible. As far as this goes, I think the performance hit will be similar to that of the flag manager, perhaps a couple times greater (since the number of vehicle corpses in a long game may be a few times the number of flags), but then perhaps not quite as much overall, since the flag manager is more complex outside of the calls to GetUnitsInCylinder.

On a side note, I’m planning to add support for rectangular cover areas.

A note for me: need to shrink feature footprints more completely so infantry can get closer to the source of cover.