Recent camera change changed behavior for move order to off map position

[Caball009]

https://www.youtube.com/watch?v=dsskOq55KrY&t=15778s

A recent camera change introduced (or revealed) a bug where some offmap move orders move units to 0, 0, 0. I think I tracked it down to these lines:
f933a03#diff-f50720c1f2aad91fd9cdb80ecf7f03bad01d56e3600d85ea50da7c507e77832aR782-R783

---

off_map_move_order.mp4

The USA Dozer shows the new behavior, the China Dozer shows the original behavior. I removed the border size subtraction while recording to show both behaviors.

[xezon]

A guess: The far clip plane no longer reaches into the blackness and so mouse clicks can no longer sample a valid terrain position and then it defaults to 0,0,0.

Does this cause Network mismatch? If not, then maybe the move client code needs looking at why it defaults to 0 when clearly a valid position is found (see the green mouse marker on the terrain)

[Caball009]

Does this cause Network mismatch? If not, then maybe the move client code needs looking at why it defaults to 0 when clearly a valid position is found (see the green mouse marker on the terrain)

No network issues, because the client just issues a move order to 0, 0, 0. AFAICT that coordinates comes from W3DView::screenToTerrain:

GeneralsGameCode/Core/GameEngineDevice/Source/W3DDevice/GameClient/W3DView.cpp

Line 2559 in 44deb06

Vector3 intersection(0,0,0);

[xezon]

A simple fix is to extend the ray length in W3DView::getPickRay