Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have implicit conversion for int -> CString #37

Open
AvarianKnight opened this issue Apr 22, 2024 · 6 comments · May be fixed by citizenfx/fivem#2822
Open

Have implicit conversion for int -> CString #37

AvarianKnight opened this issue Apr 22, 2024 · 6 comments · May be fixed by citizenfx/fivem#2822
Labels
enhancement New feature or request triage This issue needs to be triaged

Comments

@AvarianKnight
Copy link

AvarianKnight commented Apr 22, 2024

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.

@AvarianKnight AvarianKnight added enhancement New feature or request triage This issue needs to be triaged labels Apr 22, 2024
@thorium-cfx
Copy link
Owner

thorium-cfx commented Apr 23, 2024

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
Copy link
Author

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
Copy link
Owner

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
Copy link

geofmigliacci commented Aug 23, 2024

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
Copy link
Author

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
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request triage This issue needs to be triaged
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants