fivem icon indicating copy to clipboard operation
fivem copied to clipboard

GetHashKey returns int instead of uInt

Open KevinCCucumber opened this issue 1 year ago • 6 comments

I want to collect hashvalues for Weaponmodels clientsided, so I am using this native function but as you can see when I want to call it in Visual Studio, it returns an int instead of uint: image This is a discrepancy that should be looked into.

CitizenFx Version is 1.0.5770 both for client and server

KevinCCucumber avatar Jul 30 '22 12:07 KevinCCucumber

Hi, GetHashKey always returned an int32 so this would be a breaking change. I think you should just use Convert. ToUInt32(Int32) here

william-des avatar Jul 30 '22 12:07 william-des

If you take a Look at the docs it is supposed to return an uInt. Its a discrepancy that should be fixed by either changing the docs or the Api.

KevinCCucumber avatar Jul 30 '22 13:07 KevinCCucumber

This is here for compatibility, I don't think there's any changing this without breaking the underlying resources that relied on this prior

You can also look at the docs and see that it marks it as a uint, and it is casted in the guides too

AvarianKnight avatar Jul 30 '22 13:07 AvarianKnight

I don't understand what point you are trying to make here. The docs should not show the wrong return type of the function.

KevinCCucumber avatar Jul 30 '22 13:07 KevinCCucumber

As of the nature of reverse-engineering, some natives have gotten the wrong types and were corrected later (int32 <-> uint32, bool <-> char, you name it). So you can say that the first assumed type is how they were made available initially on all runtimes and corrections came later, so the docs are more likely correct.

Now the real issue: C# is a type safe programming language, which also applies to method/function signatures. Changing the return type or any parameter type will break any assembly/script that is asking for the older method, meaning everyone needs to update and recompile their script almost every time when we make a slight change. Servers can be down for days if we do this. This is what AvarianKnight was referring to with compatibility.

On that note we are working on a solution.

thorium-cfx avatar Aug 01 '22 13:08 thorium-cfx

Thats good to hear. I can work around, but it can be annoying when trying to look up things

KevinCCucumber avatar Aug 01 '22 13:08 KevinCCucumber

Has there been any update to this? I'm currently running into the same issue myself.

hax4dazy avatar May 26 '23 23:05 hax4dazy

Currently there are several options:

Game.GenerateHashASCII(string)  // fastest, ASCII characters only
(uint)Game.GenerateHash(string) // will do a reinterpretation cast
(uint)API.GetHashKey(string)    // v1 only, slowest + reinterpretation cast
Native.GetHashKey(string)       // v2 only, same as 3 but follows latest native declarations

Since the mono v2 runtime follows the latest docs, this issue is now solved. Note v1 will never get this update due to backwards compatibility.

For v1 runtime I'd really advice Game.GenerateHashASCII(string) (v2 as well).

thorium-cfx avatar May 27 '23 07:05 thorium-cfx