Game.Player.Character.CurrentVehicle does not return null after leaving vehicle in v2699

[nomakewan]

Version
3.4.0

Description
As of the latest title update for GTA5 and SHV (2699), SHVDN is no longer returning null for Game.Player.Character.CurrentVehicle after a player leaves a vehicle. Once you enter a vehicle, Game.Player.Vehicle.CurrentVehicle is updated to the vehicle you are in. When you exit the vehicle fully, this value is nulled. If you revert GTA5 to v2628 (even leaving SHV 2699 alone), this behavior returns to normal. However, when using GTA5 v2699, this value does not return null after a player leaves any vehicle. Instead, it is updated each time the player enters a new vehicle, but is never nulled. This causes unexpected behavior in scripts which rely on knowing when a player has exited a vehicle in order to fire events.

Upon further testing, it appears there is something wrong with the underlying natives as of 2699. I do not know if this means a memory location has changed, or if Rockstar actually introduced a huge bug as of 2699.

If you return Function.Call(Hash.GET_VEHICLE_PED_IS_IN, Game.Player.Character.Handle, true), it will return the last vehicle you were in. If you change 'true' to 'false', it will still return the last vehicle you were in instead of null. However, Function.Call(Hash.IS_PED_IN_VEHICLE, Game.Player.Character.Handle, {vehiclehandle}) will return false as expected. So the game appears to be aware that you are not in a vehicle, but is not nulling the 'current vehicle'.

[kagikn]

I can see GET_VEHICLE_PED_IS_IN returns the last vehicle handle even if the second argument is set to false in b2699, so we should add a workaround about this.
I suspect Rockstar messed up with the native. They use last vehicle address and some flag like the ped is in the last vehicle to return current vehicle since GTA III. Maybe the procedure that checks the flag bit is unreachable from GET_VEHICLE_PED_IS_IN in b2699?
The piece of assembly code that checks the driving flag is like this in b2699:

mov eax, [rdi + 0x1468] // 0x1468 (or 0x146B) is where the driving flag is at of CPed
shr eax, 1E
test al, 01

[nomakewan]

In the script where I first noticed this behavior, I implemented a workaround by creating a void that checks Game.Player.Character.CurrentVehicle != null && Game.Player.Character.CurrentVehicle.Exists() && Game.Player.Character.CurrentVehicle.Occupants.Contains(Game.PlayerCharacter) and if true, returns Game.Player.Character.CurrentVehicle, otherwise it returns null. This corrected the issue with CurrentVehicle not returning null in my script.

However, there seems to also be odd behavior surrounding LastVehicle. In the mod, there is the ability to travel into the past and run into a clone of yourself that's performing all the tasks you did. In one check, we have Ped.NotNullAndExists() && Ped.LastVehicle.NotNullAndExists() && Ped.LastVehicle.IsConsideredDestroyed where 'Ped' in this context is not Game.Player.Character, but is rather (Ped)Entity.FromHandle(PedHandle) where PedHandle is the player's handle (so that we can handle character switching and such). In v2628, this check will return true if you destroy the last vehicle that this cloned ped had been in. In v2699, however, it does not return true upon the vehicle's destruction.

Just odd behavior all around. Not sure what Rockstar did, but it appears to have been something of a doozy.

[kagikn]

I can't reproduce the Ped.LastVehicle or Vehicle.IsConsideredDestroyed problems, but fixed Ped.CurrentVehicle. Wait for the next SHVDN version.

[nomakewan]

Just as a follow-up for closure's sake, I discovered the root cause of the other bug. It was because a check was happening later in the code for Game.Player.Character.IsFullyOutVehicle(). That void is defined as ped.CurrentVehicle == null && !ped.IsTaskActive(FusionEnums.TaskType.ExitVehicle) && !ped.IsTaskActive(FusionEnums.TaskType.EnterVehicle), and since CurrentVehicle never returns null, this statement never returned true.

Thus, this bug will likewise be fixed with the SHVDN update. Thanks again!