Assigning names to RFC ids

[nicefive]

Hello TNetters,

I have been trying to assign names using enums a struct or a class to RFC numbers but have not been able to get this working.

The code below shows a couple of the methods I tried.  They compile but produce an error during play for each GameObject using them:
ArgumentNullException: Argument cannot be null.
Parameter name: key

 

1.     public enum RFCNumbers
2.     {
3.         DoSomething = 0,
4.         DoSomethingElse = 1
5.     }
6.  

1.     public static class RFCNumbers
2.     {
3.         public const byte DoSomething = 0;
4.         public const byte DoSomethingElse = 1;
5.     }
6.  

1. tno.SendQuickly((byte)RFCNumbers.DoSomething, Target.OthersSaved, theThingToDo);
2.  

[nicefive]

I forgot to ask.

Are these numbers unique to this GameObject type or is it a shared project-wide pool?  Obviously if the first is true then I don't have a problem.

[nicefive]

I worked out that the null error is due to using 0 as an ID (silly me) but am still curious if the numbers are shared across all GameObject types.

[cmifwdll]

RFCs are stored on the TNObject in a list. The list is built by searching for methods with the RFC attribute on the gameobject and all its children. So RFC(0) may technically be DoSomething() on one object hierarchy but DoSomethingElse() on another. Still, I wouldn't recommend re-using IDs. It only adds confusion and saves you a small number of bytes, not worth it.

1. public class NetManager
2. {
3.     public const byte NETID_DOSOMETHING = 1;
4. }
5. [RFC(NetManager.NETID_DOSOMETHING)]
6. void DoSomething()
7. {
8.     // something
9. }
10. tno.SendQuickly(NetManager.NETID_DOSOMETHING, ...);
11.  

The class doesn't need to be static as the field is constant: it'll be the same per-object, so it's effectively static.

[ArenMook]

As cmifwdll said, IDs are per object, so you can have up to 255 unique IDs per TNObject.

Note that IDs are just an optimization feature, and premature optimizations are the root of all evil. I myself almost never use them, and instead choose to just call RFCs by their name.

[ArenMook]

I put up TNet 3.0.8 with that button in place to make your life easier.

[nicefive]

Thanks for all this.  I was experimenting with RFC IDs to see if it affected a very strange problem I am having.

I am trying to sync some GameObjects but when connected to a server their Y position is off by about -745,000 units!  This is happening on the host when connected to a standalone server and is extremely hard to nail down as it is not always present.

If I comment out part of my SetPos RFC (the transform.position = part) which is not even executed on the host the problem goes away.  If I uncomment it again the problem will stay gone away until randomly returning and staying.  Even after rebooting (C&S concurrently) and clearing everything it is still present.  Very annoying and time consuming!  I have been doing Unity for 4 months, after more than 20 years of C++ app and game coding nothing prepared me for how fiddly Unity can be sometimes!  I found UE4 C++ a lot easier.

I would love to post about this much bigger problem but I can't pin it down and am not even sure it is directly related to TNet as here is lots more going on.

Anyway I am working away on trying to work this out.  The RFC numbering did not affect this problem but this is how I got here early on.

[ArenMook]

From my experience based on working with Unity for 9 years, such glitchy things lie between the chair and the keyboard 99% of the time. I've ran into many such situations where I'm ready to scream "Unity is totally br0ken!!" when it turns out it has been my fault all along. The rest of the time I was able to create work-arounds or submit a bug report to get them fixed.

Did you try adding a Debug.Log above that transform position set to check what it's setting the position to?