#103 ECM/ECCM LoS

[Codicus Unitus]

ECM/ECCM should affect line of sight for electronic systems. Currently, it only works as a bubble that disables electronic systems when the victim is within range, which is not how it's supposed to (only) work.

ECCM rules are from Maximum Tech, while ECM rules are the same in BMR and TW. Essentially, ECM/ECCM have a 6 hex radius, and counter each other one for one in any particular hex (with the exception that Angel ECM counts as 2 regular Guardian systems).

Things get a bit trickier when we extend things into the third dimension. Currently, we use the straight Cartesian distance corresponding to 6 hexes, so ECM/ECCM spheres are actual spheres. Probably nothing wrong with this, even though it doesn't match the hex-oriented effect rules.

The problem is with adding ECM/ECCM to LoS. We not only need to compute when LoS passes through an ECM bubble, but whether ECM defeats ECCM (taking into account friend/foe). If ECM defeats ECCM at any point along the LoS, the LoS is blocked at that point.

To model all this, we need to find all potential interacting ECM/ECCM sources, model the (floating point) intervals they affect along the LoS, and check the overlap. This probably requires a dynamically-allocated interval structure, or at least a very large statically-allocated one.

Complicating matters is that we're using hex-based LoS, but non-hex-based ECM/ECCM.

Also, the current ECM hooks may not be adequate for modeling this, so we may need to add ECM checks to more places. Or not. Still evaluating that.

Proposed solution:

First, switch to hex-based LoS. The vertical component will use some appropriate metric, perhaps inspired by the rules for craters. For example, first go out horizontally, then handle the remaining hexes vertically.

Second, now that ECM/ECCM effects are hex-based, we can use the existing hex-based LoS as our interval data structure. We still have the problem of checking against all sources, but there's not much we can do about that except try and reject as early as possible (or do some space partitioning). Anyway, shouldn't be a major performance concern, depending on how many ECM/ECCM sources there are on any given map at one time.

The best way to implement part 2 of this solution is probably to generate a list of all ECM/ECCM sources. At the start of LoS walk, the list will initially be cleared. As the LoS enters and leaves the area of effect (which it will do at most once for each source), mark off the source. Eventually, search will terminate.

Alternately, we could compute the exact point along the LoS line closest to the ECM source (using a well-known geometric formula), translate that to the corresponding hex, and use that information to filter out potential ECM sources. This would give us performance approximately linear to the number of ECM/ECCM sources. There would be no performance benefit to early termination of the LoS search, however.

Issues:

Some user interface concerns with how ECM effects are presented, since the user should be able to determine that they are being jammed, but they shouldn't get a message that their systems have been completely shut down. Either we could change the current messages, or we could add a 'partially jammed' set of messages.