REDO: Disable Vehicle Heading Updates When Vehicle Flying in First-Person Mode

[rkwapisz]

Again, apologies for the previous closed PRs.
I'm still learning how to properly collaborate with Github.

[gir489returns]

The same change needs to be applied to no clip as well, as the same behavior occurs.

We should also warn the user that it shouldn't be used in FPV.

[rkwapisz]

I'll update the noclip implementation in this PR, since both issues are related.

Regarding a player warning, I'm thinking two options (or or the other, or both).

1. A tooltip on mouse-over of the feature. Simply, out-of-the-way, but probably more easily missed since few people read tooltips.
2. A one-time warning from g_notification_service when the player enters FPV with either noclip or vehicle flymode active. More apparent, and we can easily make sure it only shows up once.

[gir489returns]

The tooltip idea is a bad idea, as it assumes the user uses the GUI to activate this feature and not the hotkey or command variant. You need to compensate for all 3 scenarios. The 2nd idea is also bad, as the user may not see it, or even if they do, they may not remember the next time and become frustrated as to why it's not working.

[gir489returns]

Referring to your notes from #2985 (And your commented code)

If you change car_rot and rotation_delta to static, you can determine what the previous call's Euclidian distance was from the new rotation. Thus, you could have a delta rotation of how much to turn the car based on where the user is now looking. I feel this is a better solution than just turning off the feature entirely.

[rkwapisz]

Referring to your notes from #2985 (And your commented code)

If you change car_rot and rotation_delta to static, you can determine what the previous call's Euclidian distance was from the new rotation. Thus, you could have a delta rotation of how much to turn the car based on where the user is now looking. I feel this is a better solution than just turning off the feature entirely.

I observed a related issue where, no matter what I had set the new rotation to, flying forward in the vehicle would automatically start pitching it down, resulting in a strange parabolic trajectory. I was unable to compensate for this pitch drop with the FPV camera. I think it's related to the fact that up-down camera movements are limited more than left-right, but even with different levels of clamping for horizontal vs. vertical camera movements I had the same issue.

Also, even with a reasonable amount of clamping to prevent the super-fast spinning, the camera would still "float" to where the camera was facing. It just didn't feel good, whereas the 3rd-person view is very snappy and responsive. I will revisit this issue, though.

Regarding No Clip, this feature actually seems to be working okay for me in third and first-person camera. See video.

noclip.mp4

[gir489returns]

Yes, we fixed that in #1791 I was wondering if we could just apply the same code from FPV noclip to FPV vehicles, but what you're telling me is that it doesn't work?

[rkwapisz]

It won't work reliably in a loop because when you're FPV in a car, your gameplay cam rotation will change as the vehicle entity rotation changes, so using GET_GAMEPLAY_CAM_ROT followed by SET_ENTITY_ROTATION in a vehicle is what will make you spin. Using Euclidean distance won't help since there is no constant reference to rotate towards.

If we want to use vehicle fly in first person, we will most likely need a different control scheme that doesn't rely on GET_GAMEPLAY_CAM_ROT. The problem is that I really like the 3rd-person control scheme, and using something different first FPV would feel jarring to users.

There's probably a half-decent solution in all this, I just need to figure something out.

[gir489returns]

It won't work reliably in a loop because when you're FPV in a car, your gameplay cam rotation will change as the vehicle entity rotation changes

You just answered your own question. Keep track of static Vehicle last_vehicle, if last_vehicle == self::veh do rotation code, else reset. Make sure your reset scenario sets last_vehicle = self::veh.

[rkwapisz]

I haven't forgotten about this work and tried a few different things over the weekend. All of which were unsatisfactory.

The closest I got to having something BARELY tolerable was setting
FORCE_CAMERA_RELATIVE_HEADING_AND_PITCH(0.f, 0.f, 0.f)

after every call to
ENTITY::SET_ENTITY_ROTATION

So this would let me grab the camera's rotation, then apply it directly to the vehicle's rotation, and then FORCE_CAMERA would instantly reset our camera heading to prevent the car from infinitely moving in that direction.

This allowed to a decent degree of control for left-right axis movement despite some very strong shaking even without any input. However, I still had problems with the car tipping nose down - you can actually see this behavior in 3rd-person as well, where if you fly in a straight line without mouse movement your car will start to arc down towards the ground.

[gir489returns]

@rkwapisz I know, and I too tried to get the Euclidian distance method I mentioned working as well, but to no avail. The problem stems from the wildly inaccurate Euler angles (or lack thereof) returned from this engine, and how it expects the user to supply a Δangle instead of just the angle itself.

To be honest, I think we can merge it as-is, or maybe just go with the Plan B scenario of just turning this off entirely while in FPV mode, and then alerting the user. I'll leave this up to you.

[rkwapisz]

I really can't decide what I want to do with with this. I'm thinking we just boot the player out of FPV if they're in a car with flying on, and also push a notification that tells them FPV is unsupported.

I'd rather provide some user feedback together with an automatic workaround rather than try to half-ass a fix that would only end up getting more bug reports against it.

Notification will be PR'd in translations:
"BACKEND_FLYING_VEHICLE_FPV_DISABLED": "First-person view is currently unsupported in Vehicle Fly mode.",

I've left in some commented code in case I want to revisit this in the future, but I think @gir489returns is correct in that the issue stems from the engine's piss-poor angle handling.

[github-actions]

Download the artifacts for this pull request:

• binary.zip
• pdb.zip

M