Fix GuiTraceRay for radardrift

[saurtron]

Work done

• Introduce new quadField::GetQuadsOnWideRay.
• Make TraceRay::GuiTraceRay use it for cases where useRadar=true.
• Fixes not being able to select certain radar dots with direct click (those who drifted into different quads because of radar).

Related issues

• fixes Radar dots cannot to be targeted sometimes Beyond-All-Reason#1488

Details

• Does make the engine scan more quads, although most of the time still less than before Should not GuiTraceRay for quads beyond the floor until the far plane. #1754 when that fix is applied. (fix not applied here will need to be applied after/when that is merged)
• I'm torn about enlarging the search area so much, but seems safest, even though I've generally seen the problem arise just close to the ground, since that's where generally targets are.
  • I enlarge the ray both forward and also to the sides.
• Could be optimized making the area smaller but probably prone to error in corner cases:
  • Don't enlarge unless close to ground/ray intersection (should be quite safe, but might result in some error corner cases). Might be worth it imo.
• Another approach could be adding radar dots to quads themselves, but each team having different radar positions could make this more cumbersome, also annoyingly a radar dot could also go into several quads if at the wrong place.
• I tried to change as small part as possible from GetQuadsOnRay so changes can be reapplied, if that method needs to be modified at some point this one should follow suit.

Before

(images showing traced quads and the offset from radar position to real position for units in such quads)

note the dots inside the quads with no offset. those are the "error dots". they are coming from a different quad outside of the one they currently flying above, so they wouldn't be selectable.

After

hopefully no dots without selection, but a lot more quads searched. (note it's not exactly the same ray, so not directly comparable with the prev image, just to show no "error dots" are happening). generally with the solution we will be scanning 3x the quads since we need to scan around the usual set of quads to find possibly far away radar dots.

Diagram

Didn't color all quads properly but it should show the idea

[sprunk]

Is the white quad debug view some standard /debugBla?

[saurtron]

Is the white quad debug view some standard /debugBla?

It's something quick and dirty I had to add myself to debug the ray and quad issues here, same with radardot-realpos line, and selected units quads. Was thinking about adding it somehow, but the fact it would require a check every quad at quad iteration inside GuiTraceRay, kind of puts me off.

[sprunk]

Looks good.

[lhog]

Needs a rebase now

[saurtron]

Needs a rebase now

Merged, not sure if you prefer rebase. It shouldn't matter for this but let me know if you want me to change the procedure, this way it's also easier to see what changes I did for the merge.

[lhog]

I have hard time reading GetQuadsOnWideRay (though not harder than reading the original GetQuadsOnRay).
I trust you have tested it thoroughly enough, haven't you?

[lhog]

Also seems like I can't merge it now due to some sort of conflict anyway.