Changed RPC strings to static functions

[TheYellowArchitect]

Solves #242
(Related: #237 )

also changed RPC strings to static functions

Strings in RPC calls dynamically search for RPCs.
By having them static, there is a slight performance gain (and ofc typos are caught by the compiler)

[elementbound]

This won't work unfortunately - this class is released part of an addon, which can't rely on game-specific knowledge.

[elementbound]

This also assumes a bit much about the addon user's game; see my comment on get_player_id.

[elementbound]

Thanks for the PR! Could you please separate the static RPC call parts into its own PR? It's a good improvement and something I have considered myself too. This way we could discuss the projectile ID change separately.

[TheYellowArchitect]

As for the projectile ID, I originally wanted to have it as EntityID. Same trick with using PlayerID. The problem is that PlayerID doesn't exist in netfox at all, yet all games use it in some way or another. Being a single variable which doesn't change, it would help tons.

The full plan is to make a singleton (LocalPlayerData or NetworkCommonData) which stores non-changing values on joining. Like, the current player ID (int), and all player IDs (Array[int]) and all peer IDs (Array[int]), and optionally whatever the user wants to add, like player name, or team color.
Personally, for my project, these optional additions contain:

1. session_id (very important, helps with replays and stuff)
2. The tick the player joined (idk if this is stored somewhere i missed)
3. The local avatar (handy variable instead of get_nodes_in_group("_"))

Note this is a singleton, no need to have it autoload, could be a static class, as once it gets its initial state, its immutable pretty much. But ofc its the same as having it autoload pretty much.

Having access to this singleton is quite handy, since the above data don't change, and are filled on joining. Having such a singleton would also solve the above problem with player_id being fetched in such a hacky/ugly way.
After all, every online game must display somewhere a list of players (e.g. pressing Tab), and they don't want to show 234256235, 12313765, 4284723456, but 1, 2, 3 up to end of list.
So this takes a chore away from the netcoding developer.
Also it helps greatly in serialization as a player ID is 1 byte, while a peer ID is 4 bytes!

What do you think? How would you like me to implement player id? The scope of whatever holds it must be above the brawler, so if not a singleton, then a Node named "LocalData" at the forest brawler scene (but I don't like having it on a scene, because if there is another playable scene loaded, it will conflict)

[TheYellowArchitect]

Thanks for the PR! Could you please separate the static RPC call parts into its own PR? It's a good improvement and something I have considered myself too.

Done 👍

[elementbound]

Added a version bump, otherwise looks good, thanks!