Seeing as this PR is rejected I assume there is a way to keep track of what channels have been used in the project other than writing them down somewhere and hoping you remembered to do so, and not have to go find your notes every time you want to write an rpc with a channel?
If not then I don’t really understand why they rejected it (aside from the idea that they don’t want some annotations to accept them and not others). I feel like it would be a great way to keep your channels organized & not overlap them by mistake. Not to mention you could look up what functions all use that channel with ctrl+f + the enum/const name.
As far as I am aware this errors when you run it, the PR specifically mentions rpcs and quoteless strings which I think it may consider this enum as? Not sure, the error is a bit confusing.
I did some testing because it seemed to work sometimes and not others.
Turns out storing the RPC_CHANNELs on an autoload doesn’t work on it’s own, since the rpc compiles(?) before the autoload exists. I was falling into the trap of the second example, so I made it into a class and that works.
On an autoload called GM which is a GAME_MANAGER class: enum RPC_CHANNELS { TIME_SYNC = 7 }
results
Called from an rpc ON game manager - WORKS (prolly not the best practice) @rpc ("authority", "call_local", "unreliable_ordered", RPC_CHANNELS.TIME_SYNC )
Called from the autoload - DOES NOT WORK @rpc ("authority", "call_local", "unreliable_ordered", GM.RPC_CHANNELS.TIME_SYNC )
Getting the enum from the game manager class - WORKS @rpc ("authority", "call_local", "unreliable_ordered", GAME_MANAGER.RPC_CHANNELS.TIME_SYNC )
That makes sense, GM is a instance of something so it must be created and accessed after compile-time, during the game.
GAME_MANAGER is a class, the compiler knows about classes and will access the enumerated type.
Using TIME_SYNC on it’s own inside the game manager global might be accessing as self.TIME_SYNC implicitly, which again uses a instance, which is unfavorable in this case.