Add support for 64-bit unsigned integers (for Steam ID support)

[hislittlecuzin]

Describe the project you are working on

I am making a game that uses Steamworks and uses Steam IDs for identifying players. Clients don't have "connection ids" for all the players. So clients are telling the server who they're talking to by Steam ID. The server knows the "connection IDs" and can relay the messages based on the Steam ID to the correct client. With Steam Matchmaking (now sometimes called Steam Lobbies) you can access the Steam ID of other players which is a "ulong" in C#.

Describe the problem or limitation you are having in your project

Right now I am limited to 9,223,372,036,854,775,807 instead of the real maximum value of 18,446,744,073,709,551,615 because the 64 bit integer is signed in GD Script. C# can use unsigned long or ulong to get that larger number.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The new unsigned integer will allow larger unsigned numbers for when Steam games have players with a steam ID higher than 50% of the maximum steam account value, there will be no issues.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I don't know how to create a new variable in GD Script. I suppose uint would be acceptable.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Right now I'm hoping that rolling over into negative values won't cause an issue. But if I need to access a steam account by exact ID, it will likely provide a failed result.

Is there a reason why this should be core and not an add-on in the asset library?

Unsigned 64 bit whole numbers have become standard in many languages.

[dalexeev]

I guess this is not necessary since int64 and uint64 have the same size and differ only in how the data is treated. You can use String.num_uint64() to display an int as if it were uint.

[hislittlecuzin]

I guess this is not necessary since int64 and uint64 have the same size and differ only in how the data is treated. You can use String.num_uint64() to display an int as if it were uint.

No. With netcode, it'll be slow to continually parse data types especially when converting to strings. Data should stay binary.

[dalexeev]

You don't need to convert int from/to String unless you want to display the ID for the user or store it as text. I think you can use int instead of uint without any problems. This won't corrupt the data because int64 and uint64 are the same size. It's unlikely that ID involves any complex operations or comparisons.

[hislittlecuzin]

You don't need to convert int from/to String unless you want to display the ID for the user or store it as text. I think you can use int instead of uint without any problems. This won't corrupt the data because int64 and uint64 are the same size. It's unlikely that ID involves any complex operations or comparisons.

You cannot use uint, because GD Script does not have a uint data type - hence the purpose of this issue.

[CsloudX]

You don't need to convert int from/to String unless you want to display the ID for the user or store it as text. I think you can use int instead of uint without any problems. This won't corrupt the data because int64 and uint64 are the same size. It's unlikely that ID involves any complex operations or comparisons.

You cannot use uint, because GD Script does not have a uint data type - hence the purpose of this issue.

[CsloudX]

You cannot use uint, because GD Script does not have a uint data type - hence the purpose of this issue.

You don't need uint, just use int. everyting will be OK. you see the id was negative, just it display on the screen was negative, in the memory, there was right data. for display, if you don't like negative, you can use String.num_uint64() just like @dalexeev say.

[BenLubar]

The top 7 bits are never set in a SteamID outside of Valve's internal network. Even within Valve's internal network, the top 5 bits are never set.

[zaddok]

GDScript should support unsigned integers. For type safety, it should be possible to declare a data type that should never be negative. I literally just had to fix a bug where a negative number appeared in a variable, where it should not be possible in the first place. What is the rationale for not supporting unsigned integers anyway?

[Calinou]

What is the rationale for not supporting unsigned integers anyway?

I believe it simplifies the language design and implementation a fair bit, which is why most high-level scripting languages don't support unsigned integers either.

You can use assert() to make sure a number is positive when needed. assert() is skipped in release builds (the expression isn't even evaluated), so it won't have a performance impact where it matters most.