It is not the core codebase's responsibility to prevent bad or untested scripting

I dont 100% agree with that, if you go that way, so in every native we just dont do any check on args passed.
But if NULL is parsed as 0.0f in these fields, then it's a GTA problem and I agree.

Imo we should have atleast a message when we pass NULL

Imo we should have atleast a message when we pass NULL

I'm not sure if that's possible, but I do think it's a good idea to have a warning when 0.0 is applied in some handlings, which is the same as null in this case, because it will set a very large value that breaks the physics.

It is not the core codebase's responsibility to prevent bad or untested scripting

I dont 100% agree with that, if you go that way, so in every native we just dont do any check on args passed.

But if NULL is parsed as 0.0f in these fields, then it's a GTA problem and I agree.

Imo we should have atleast a message when we pass NULL

I tested a decent range of different handling values and null/0.0 produce the same effect.

I took a look at CheckArgument to confirm & this is correct. In the case of setting a float, it checks whether the value is equal to an empty constructor of the type, which in the case of a float would be like running float(), which returns 0.0f.

So right now, we are validating against using 0.0f. So for example if you wanted to reset a vehicle's suspension height with SetVehicleHandlingFloat(vehicle, "CHandlingData", "fSuspensionRaise", 0.0), this currently results in an error.

Imo we should have atleast a message when we pass NULL

I'm not sure if that's possible, but I do think it's a good idea to have a warning when 0.0 is applied in some handlings, which is the same as null in this case, because it will set a very large value that breaks the physics.

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

Lines 215 to 218 in 7bcb23d

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

So this is the problem, why set this at 100000000.f and other handling values not ?

I'm not sure if that's possible, but I do think it's a good idea to have a warning when 0.0 is applied in some handlings, which is the same as null in this case, because it will set a very large value that breaks the physics.

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

Lines 215 to 218 in 7bcb23d

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

So this is the problem, why set this at 100000000.f and other handling values not ?

Well that's the same behaviour of the game.

Smth I dont understand, why a handling parameter cannot be set with 0.0 or 0? What's the reason?

Smth I dont understand, why a handling parameter cannot be set with 0.0 or 0? What's the reason?

Well that depend in the handling but if you look in the else of the screenshot I send you can see a division, if you divide by 0.0 ... 🤯

But using the native I get an error

But using the native I get an error

That's the reason to revert the previous PR, because the code is considering 0.0 as null, if this PR is merged we'll get the previous behavior that is allowing the 0.0 values.

Got it

Or at least, don't allow null, but allow 0.0 and 0

Or at least, don't allow null, but allow 0.0 and 0

#3134 (comment)

Any update on this? If the issue is spread to the stable version of the client it's going to screw up a lot of handling-related scripts.