Player names show up inconsistently while crewing vehicles

[Colin Basnett]

Appears to be an issue the turret's rotation not being added to the trace check.

[Matt Hands]

I think this must be a general problem wherever any functionality uses the Controller's rotation and the player may be in a vehicle, which probably will use relative rotation, i.e. bPCRelativeFPRotation=true, meaning the Controller's rotation is relative the the vehicle's rotation. To work effectively, the functionality needs to factor in the vehicle's rotation.

In this case I expect the offending lines in DHHud.DrawPlayerNames function are:

(line 1488) HitPawn = Pawn(Trace(HitLocation, HitNormal, ViewPos + 1600.0 * vector(PawnOwner.Controller.Rotation), ViewPos, true));

(line 1510) GetAxes(PlayerOwner.Rotation, X, Y, Z);

I think a pretty clean solution would be to a a GetNonRelativeRotation() type function in DHPlayer and use that to get a rotation that DrawPlayerNames() can use. I would factor in the vehicle's rotation whenever the player is in a vehicle with relative rotation, but would also factor in a turret's yaw if the player is in a turret. It may have utility in other functionality too, and having it in a central class like DHPlayer seems convenient, avoiding what could otherwise be rotation functionality in several vehicle classes (although this sort of problem will get easier in 7.0 when we add single DH parent classes for things like Vehicles and VehicleWeaponPawns).

[Matt Hands]

Actually, I think there's a ready made solution by using Canvas native function GetCameraLocation(), which gets the player's current camera rotation as well as its location.

EDIT - Probably even simpler & seems to work, CalcViewLocation is a PlayerController variable that saves the current camera rotation, so avoiding the need to call any function, even a native one, to get the camera rotation. PC function CacheCalcView() gets called every time the view is updated and saves the current camera location & rotation, plus the ViewActor and its location. Probably useful elsewhere too.

Will test more thoroughly later, but believe this is a fix.

[Matt Hands]

Fixed in 9e2fc1b.

Tested and works fine. Using the saved CalcViewLocation/CalcViewRotation definitely has utility in other functionality. It cuts straight through a lot more complex and sometimes faulty functionality to work out a non-relative view loc/rot.