Error when using SetVehicleHandling natives with value of 0

[jrgrimshaw]

What happened?

The recent merge of PR #3101 stemming from the issue #3097 now prevents the use of 0/0.0 as a valid handling value.

From what I can tell from a look into the codebase and some basic knowledge of C++, the game sees 0 the same as nil and it functionally acts the same from my testing too. I can use nil (in Lua) or 0 interchangeably and get the same results. I understand the original issue's point, I suppose for some handling values nil or 0 can break the physics of the vehicle, but ultimately a lot of different values can completely screw up vehicles to the point where they cannot be fixed.

A float value of 0.0 is valid for various different handling values, and is the default value of many, such as fSuspensionRaise. An int value of 0 is commonly used for signifying no flags, such as for strAdvancedFlags. These also work fine and don't break the vehicle when run in-game.

TL;DR: Using SetVehicleHandlingFloat with a value (arg index 3) of 0.0, the game now sees as invalid even though it should be valid. Same happens when running SetVehicleHandlingInt with a value of 0, it throws the same error.

Expected result

Using SetVehicleHandlingFloat with a value of 0.0 should run without an error.

Reproduction steps

The following code, attempting to 'reset' fSuspensionRaise back to 0.0:

local vehicle = GetVehiclePedIsIn(PlayerPedId(), false)
SetVehicleHandlingFloat(vehicle, "CHandlingData", "fSuspensionRaise", 0.0)

Returns the following error, saying arg 3 is nil:

Here's an example repro for strAdvancedFlags, setting a value of 0 to signify no advanced flags should be placed on the vehicle. The error returned is the essentially the same as the above.

local vehicle = GetVehiclePedIsIn(PlayerPedId(), false)
SetVehicleHandlingInt(vehicle, "CCarHandlingData", "strAdvancedFlags", 0)

Importancy

Crash

Area(s)

Natives, FiveM

Specific version(s)

FiveM Client 12746 (Currently canary only)

Additional information

No response

[DaniGP17]

The PR(#3101) that was merged was to avoid null values but the original issue was not for sending null values, because this context.GetArgument<float>(3) already return 0.0 if a null value is sended.
So the real issue is to use 0.0 in the handlers that @CeebDev provide in the issue: fTractionCurveMin / fTractionCurveMax / fLowSpeedTractionLossMult.
Already tested in my server and sending 0.0 value to those handlings get the same issue.

[DaniGP17]

fivem/code/components/handling-loader-five/src/HandlingLoader.cpp

Lines 215 to 218 in 7bcb23d

	if (fTractionCurveMax == 0.0f)
	{
	*(float*)(handlingChar + 140) = 100000000.f;
	}

If the handling of fTractionCurveMax is 0.0 it assign a high value, so I'm sure that this is the reason to have strange physics.

[jrgrimshaw]

The PR(#3101) that was merged was to avoid null values but the original issue was not for sending null values, because this context.GetArgument<float>(3) already return 0.0 if a null value is sended.
So the real issue is to use 0.0 in the handlers that @CeebDev provide in the issue: fTractionCurveMin / fTractionCurveMax / fLowSpeedTractionLossMult.
Already tested in my server and sending 0.0 value to those handlings get the same issue.

I thought so as I didn't see any difference when using 0 or null as a value; either way, the commit should be reverted & the native shouldn't be validated against null values.

[jrgrimshaw]

fivem/code/components/handling-loader-five/src/HandlingLoader.cpp

Lines 215 to 218 in 7bcb23d

	if (fTractionCurveMax == 0.0f)
	{
	*(float*)(handlingChar + 140) = 100000000.f;
	}

If the handling of fTractionCurveMax is 0.0 it assign a high value, so I'm sure that this is the reason to have strange physics.

Oh great find! I didn't notice that, yeah that is likely the cause of the strange physics.

[DaniGP17]

the commit should be reverted & the native shouldn't be validated against null values.

I'm not sure whether to open a PR to revert the previous changes or wait for someone from CFX to revert the commit. Still, I think it's easier to accept null values ​​because as we know they are converted to 0. And the function that does force arguments to be sent seems to take 0.0 as null.

[jrgrimshaw]

the commit should be reverted & the native shouldn't be validated against null values.

I'm not sure whether to open a PR to revert the previous changes or wait for someone from CFX to revert the commit. Still, I think it's easier to accept null values ​​because as we know they are converted to 0. And the function that does force arguments to be sent seems to take 0.0 as null.

Yeah agreed.

When I wake up tomorrow I'll probably just submit a PR to revert the commit with a bit of an explanation.