thorium-cfx / mono_v2_get_started

Mono v2 runtime for FiveM/RedM
35 stars 1 forks source link

Have implicit conversion for int -> CString #37

Open AvarianKnight opened 4 months ago

AvarianKnight commented 4 months ago

Goal

There are quite a lot of natives server-side that expect a char* over an actual integer, but using the default Player class, Handle is an int so in order to use player.Handle you constantly have to do player.Handle.ToString().

It might be more intuitive (and less verbose) for CString to handle this itself.

Importancy

Quality of Life (QoL)

API and/or potential implementation

public static implicit operator CString(int integer)
{
    return Create(int.ToString());
}

Extra

It might be better to add these to some of these native calls to the Player class itself, but being able to manually use these natives is also useful.

thorium-cfx commented 4 months ago

Instead of using implicit conversions on the CString type (has its own set of bad practices and issues), maybe instead make QoL improvements to the Player class?

It seems the goal here is to make the Player object easier in natives, not so much to make .Handle more convenient to use, correct?

Code example:

Player p1 = new Player(1);
Natives.ThisCoolNative(p1, "hello", 1234); // ThisCoolNative(CString, CString, int), look no excessive .Handle usage!
Natives.ThisOtherNative(p1, "hello", 1234); // ThisOtherNative(int, CString, int);
AvarianKnight commented 4 months ago

Instead of using implicit conversions on the CString type (has its own set of bad practices and issues), maybe instead make QoL improvements to the Player class?

It seems the goal here is to make the Player object easier in natives, not so much to make .Handle more convenient to use, correct?

Code example:

Player p1 = new Player(1);
Natives.ThisCoolNative(p1, "hello", 1234); // ThisCoolNative(CString, CString, int), look no excessive .Handle usage!
Natives.ThisOtherNative(p1, "hello", 1234); // ThisOtherNative(int, CString, int);

I never thought about this, couldn't the same things be done for Entity related natives (if its not already)

thorium-cfx commented 4 months ago

Don't see why not. You can turn this whole ticket into a feature request for any/all of those, maybe there are more, Vehicle also comes to mind

geofmigliacci commented 2 weeks ago

Instead of using implicit conversions on the CString type (has its own set of bad practices and issues), maybe instead make QoL improvements to the Player class?

It seems the goal here is to make the Player object easier in natives, not so much to make .Handle more convenient to use, correct?

Code example:

Player p1 = new Player(1);
Natives.ThisCoolNative(p1, "hello", 1234); // ThisCoolNative(CString, CString, int), look no excessive .Handle usage!
Natives.ThisOtherNative(p1, "hello", 1234); // ThisOtherNative(int, CString, int);

Hello I'd like to contribute but, how could I implement that, where should I start? The C# natives are code-generated with a lua script, from what I understood from the fivem repository. What would be your approach and do you have examples of natives like that?

Hope it was clear.

AvarianKnight commented 2 weeks ago

Instead of using implicit conversions on the CString type (has its own set of bad practices and issues), maybe instead make QoL improvements to the Player class? It seems the goal here is to make the Player object easier in natives, not so much to make .Handle more convenient to use, correct? Code example:

Player p1 = new Player(1);
Natives.ThisCoolNative(p1, "hello", 1234); // ThisCoolNative(CString, CString, int), look no excessive .Handle usage!
Natives.ThisOtherNative(p1, "hello", 1234); // ThisOtherNative(int, CString, int);

Hello I'd like to contribute but, how could I implement that, where should I start? The C# natives are code-generated with a lua script, from what I understood from the fivem repository. What would be your approach and do you have examples of natives like that?

Hope it was clear.

In this case it would be as simple as having implicit operators on the C# classes (which are not automatically generated)

geofmigliacci commented 2 weeks ago

Instead of using implicit conversions on the CString type (has its own set of bad practices and issues), maybe instead make QoL improvements to the Player class? It seems the goal here is to make the Player object easier in natives, not so much to make .Handle more convenient to use, correct? Code example:

Player p1 = new Player(1);
Natives.ThisCoolNative(p1, "hello", 1234); // ThisCoolNative(CString, CString, int), look no excessive .Handle usage!
Natives.ThisOtherNative(p1, "hello", 1234); // ThisOtherNative(int, CString, int);

Hello I'd like to contribute but, how could I implement that, where should I start? The C# natives are code-generated with a lua script, from what I understood from the fivem repository. What would be your approach and do you have examples of natives like that? Hope it was clear.

In this case it would be as simple as having implicit operators on the C# classes (which are not automatically generated)

Before doing anything, for instance on the Player class I added:

#if MONO_V2
        /// <summary>
        /// Converts a <see cref="Player"/> to a null-terminated byte string <see cref="CString"/> using its handle.
        /// </summary>
        /// <param name="player">
        /// The <see cref="Player"/> to convert.
        /// </param>
        public static implicit operator CString(Player player)
        {
            return player.Handle.ToString(); // Note: using the implicit conversion of the CString
        }

        /// <summary>
        /// Converts a <see cref="Player"/> to a <see cref="int"/> using its handle.
        /// </summary>
        /// <param name="player">
        /// The <see cref="Player"/> to convert.
        /// </param>
        public static implicit operator int(Player player)
        {
            return player.Handle;
        }
#endif

Does it looks good to you, and should I apply this to all classes that have an handle?