GetHashKey returns int instead of uInt

[KevinCCucumber]

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: This is a discrepancy that should be looked into.

CitizenFx Version is 1.0.5770 both for client and server

[william-des]

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

[KevinCCucumber]

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.

[AvarianKnight]

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

[KevinCCucumber]

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

[thorium-cfx]

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.

[KevinCCucumber]

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

[hax4dazy]

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

[thorium-cfx]

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).