View rotation can go wrong on entering vehicle, due to saved config from using behindview

[Matt Hands]

When behind view is used in a vehicle or vehicle weapon position, the ClientSetBehindView() function in the PC class saves all config properties for the vehicle pawn class to the user.ini config file, with entries like this for every vehicle & subclass:

[DH_Vehicles.DH_M3A1HalftrackTransport]
CrossHairColor=(B=0,G=0,R=0,A=0)
CrosshairX=0.000000
CrosshairY=0.000000
CrosshairTexture=None
bDesiredBehindView=True
TPCamDistance=3600.000000

The crosshair stuff is harmless & just clutter, but bDesiredBehindView=True causes the entry rotation to get screwed up in the vehicle's ClientKDriverEnter() function. It gets saved as true if the player leaves the game while in vehicle behind view. Then in future, every time the player enters that vehicle the view rotation will be wrong, unless overridden/corrected by something else.

Secondary problem is that any old values of TPCamDistance that have been saved in the .ini over the years, are used as the default for that vehicle, overriding values in default properties. So when using behind view some odd camera distances can be used, which are at odds with def props. In my case, bafflingly & maddeningly so, as all my changes to def props were seemingly ignored, until I figured out what was going on !

[Matt Hands]

Fixed in commit f0914f6.

I had previously stopped the ClientSetBehindView() function in the PC class from saving all the pawn's config variables every time a player goes went into behind view in a vehicle. But that didn't clear years of accumulated stuff.

So I've gone further and called ResetConfig() on the vehicle pawn, which resets the vehicle's config in the user.ini file to it's default (if there is one), or cleanly removes the veh's config block from .ini if there is no default config (currently the case). This ensures the correct class def props get used, and also over time it will clean up the .ini file (mainly effecting ppl like us who use behind view in debug mode, or modders).

But it's bDesiredBehindView that is critical to ensuring correct entry rotation in normal gameplay, so while that will get cleaned up over time by ResetConfig(), I've actively enforced it's correct false value in the vehicle's ClientKDriverEnter().