Vehicle interiors sometimes do not render

[Colin Basnett]

Might have something to do with some vestigial third person code?

[Matt Hands]

That's a view of the exterior mesh from inside the vehicle. The problem is it's failing to switch to the interior mesh. The same effect can be recreated by using the exec ToggleMesh in the driver's position when the view is normal.

I'm 99% certain I can see the cause of this problem. My money is on you or someone being in the driver's slot and using behind view, then exiting the driver's slot without 1st exiting out of behind view. Then when you enter the driver's slot you get the screwed up mesh view - and also no view limits. The problem is solved by entering behind view again and then back to normal. It can certainly be recreated that way.

The bug arises because I have POVChanged() set up so that when you go into behind view, it temporarily change all the DriverPositions meshes to the external mesh, and also removes any position FOV and view limits. This is so you see the correct vehicle mesh in behind view and without any zoom. These values all get reset when you manually exit out of behind view - but aren't being reset when it automatically switches you out of behind view when you exit the driver's position.

I can fix this easily, so it isn't going to be a problem. I'm just going to check a few things to find the best fix, preserving this very useful behind view functionality. Worst case scenario, if time runs out: disable behind view unless in DHDebugMode so this can't happen except in a dev environment. Outside of DHDebugMode, behind view is already disabled in multiplayer so even if we released this unchanged, it could only affect single player. But that's just to put it in context - I'll fix it properly before release.

[Colin Basnett]

@Matt_UK, the screenshots posted on this bug were captured in a multiplayer (dedicated server) environment.

[Matt Hands]

It's possible to use or at least to enable behind view in MP for now. The issue is: was behind view perhaps used on the vehicle when the mesh bug appeared? Bearing in mind, it could have been used on that vehicle by any player at any time during the round - and that would certainly cause the mesh bug.

[Matt Hands]

Just to let you know I haven't forgotten this. It's a relatively easy fix, but needs an hour or so to check some options out & I'm concentrating on more pressing issues.

I have in mind to strip all the mesh & FOV switching stuff out of POVChanged() - currently based on whether in behind view or not - and instead only do mesh & FOV switching in functions like HandleEnter, HandleTransition & SwitchMesh if the player is not in behind view. That would avoid the need to tamper with the meshes in the DriverPositions array, which is what causes this bug. But I am avoiding the temptation to start looking at this code as there is other stuff to do .......

[Matt Hands]

Fixed in commit 5f99897.

Bug avoided by new, improved behind view system. Behind view no longer messes with DriverPositions meshes, FOVs or camera offsets, or with any yaw or pitch limits. These all stay unaltered, so if player leaves vehicle while in behnd view, next player in doesn't get screwed up 1st person view because it's trying to use the old behind view mesh etc.

Instead, state ViewTransition simply ignores any mesh, FOV or camera offset changes if player is in behind view. And functions that limit yaw or pitch simply ignore yaw and pitch restrictions if player is in behind view, without actually having to change any of the limit settings.

When entering behind view, POVChanged() now just switches to default exterior mesh and normal view FOV. On leaving behind view it just switches back to the relevant DriverPositions mesh, FOV & camera offset.

Yaw limits work better with MGs, as now we keep bLimitYaw, which prevents MG weapon moving beyond its limits, but player's view yaw is unlimited in behind view. In the previous system, the MGs yawed around at crazy angles when rotating the view in behind view.