Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - cmifwdll

Pages: 1 2 3 [4] 5 6 ... 19
46
TNet 3 Support / Re: Static TNObject IDs
« on: September 20, 2017, 04:59:20 AM »
No, that's the intended usage of saved RFCs. It's just that ArenMook discourages static TNObjects because TNet 3 has no way of knowing when a static TNObject is destroyed, so the saved RFCs will always remain in the channel even if the object it belongs to is destroyed. This could lead to inconsistent behaviour if for some reason one of your client's static TNObject is destroyed. But like I said in the previous post, if you're just using static TNObjects for persistent singleton managers I don't think you'll run into any issues.

47
TNet 3 Support / Re: Static TNObject IDs
« on: September 19, 2017, 05:37:48 PM »
Sorry for the late reply.

Yep, but remember you'll have to remain in that channel for the lifetime of the objects. ArenMook pointed out an issue I overlooked though: TNet 3 more closely manages object lifetime, so to avoid the issues he mentioned you shouldn't use any of the Target.___Saved RFCs. There might be some other issues involved, so consider ArenMook's advice (don't use static objects). Though, I don't think it'll cause any issues if you're just using them for persistent singletons (even with saved RFCs). But ArenMook's strategy of instantiating your managers from the OnJoinChannel notification is just as effective as static TNObjects and you'd be able to use saved RFCs without worry. And, of course, if the dev himself discourages something, then you probably shouldn't start a new project with that thing. Could be phased out in later patches.

You're right, a call to JoinChannel without being connected to a gameserver results in a non-async load level. If connected, the server sends a ResponseLoadLevel (and a bunch of other stuff) which does lead to LoadLevelCoroutine being started.

48
TNet 3 Support / Re: Static TNObject IDs
« on: September 15, 2017, 02:57:28 AM »
I think so? Any objects in the scene you load via JoinChannel will be networked. Objects from previous scenes (like your startup scene) won't automatically become networked.

You shouldn't have any objects in your startup scene that require RFCs because you aren't connected to a channel at startup. How could they be aware of something that didn't exist at their birth?
Well, the same way we do, I guess, by being told about them:
  1. public class GameManager : TNBehaviour
  2. {
  3.         void OnEnable()
  4.         {
  5.                 TNManager.onJoinChannel += OnJoinChannel;
  6.         }
  7.        
  8.         void OnDisable()
  9.         {
  10.                 TNManager.onJoinChannel -= OnJoinChannel;
  11.         }
  12.        
  13.         private void OnJoinChannel(int channelID, bool success, string message)
  14.         {
  15.                 if (!success)
  16.                 {
  17.                         Debug.LogError(name + " Saw failed JoinChannel (" + message + ")");
  18.                         return;
  19.                 }
  20.                 tno.Initialize();
  21.                 tno.Send(45, Target.All, TNManager.isHosting ? "HOST initialized" : "CLIENT initialized");
  22.         }
  23.  
  24.         [RFC(45)]
  25.         void TestRFC(string msg)
  26.         {
  27.                 Debug.Log("Message from: " + msg);
  28.         }
  29. }
  30.  
Add the following to TNObject.cs:
  1. public bool IsInitialized = false;
  2. public void Initialize()
  3. {
  4.         if (IsInitialized) return;
  5.         Unregister();
  6.         channelID = TNManager.lastChannelID;
  7.         Register();
  8.         if (mCallDataChanged && onDataChanged != null)
  9.         {
  10.                 mCallDataChanged = false;
  11.                 onDataChanged(mData);
  12.         }
  13.         rebuildMethodList = true;
  14.         IsInitialized = true;
  15. }
  16.  

It's super sloppy but I tested it and it works. You could probably hook TNObject itself up to the OnJoinChannel event but that'd require modifying some of its existing code. So for the sake of posting this I went with an approach that only adds new code.



Oh, I also just realized that maybe you don't need *RFCs* but don't know about the glory of custom packets... I probably should've told you about those in like the first post. My bad.
You can use custom packets by calling TNManager.BeginSend and TNManager.EndSend directly. Set the packet handler with TNManager.SetPacketHandler. You only get one packet handler per packetID which is perfectly fine for a singleton manager.

And to sort of explain why getting RFCs working on an un-networked object is such a hassle:
RFCs belong to objects which belong to channels. The benefits of an RFC are: ease of use (one line!), instanced, and the ability to save the call on the channel so it's automatically sent to new players.
So if your object doesn't belong to a channel then RFCs can't work. The code snippet above forcefully registers your object with the channel to get its RFCs working.
Maybe it'd help to think of RFC (Remote Function Call) as RCC (Remote *Channel* Call). But TNet uses RCC for something else (Remote Creation Call), so yeah :P

49
TNet 3 Support / Re: Static TNObject IDs
« on: September 14, 2017, 07:06:00 PM »
Why does your GameManager and UIManager need to communicate via RFC? Maybe if you explained more specifically what you're trying to do I could provide some more direction.

Still waiting on ArenMook to show up :P

50
TNet 3 Support / Re: TNet 3 - Send RFC messages
« on: September 14, 2017, 07:03:24 PM »
TNManager.JoinChannel does load the scene asynchronously. No special call necessary. I think all scene loads in TNet are async.

You can access TNManager.loadLevelOperation for the async operation (check for null).

51
TNet 3 Support / Re: Static TNObject IDs
« on: September 13, 2017, 06:51:58 PM »
Every new object from point 2 onwards will be networked.

It's really not a limitation. It's basically just this: if you're not connected to a network, don't expect networking to work. Furthermore, if you connect to a network you'll need to re-initialize existing objects for them to be networked.

Again, I'd urge you to re-think your design. ArenMook's dealing with a lot of procedural content in his new game and we'd be getting any changes he makes to TNet. There haven't been many, so TNet definitely supports what you want to do.

However, as an immediate solution, you could just copy the two lines in TNObject's (not TNBehaviour's) Awake function and put it in a new public Initialize function. Add a bool IsInitialized so it doesn't get called twice. Now, in OnJoinChannel just call your TNObject's Initialize function. They should function as normal static tno's now.

52
TNet 3 Support / Re: Static TNObject IDs
« on: September 13, 2017, 08:39:25 AM »
I think ArenMook's saying that a static scene object can't be networked post-load. So, in your flow, none of your global managers from the menu screen could be networked (the central game management, UI management, etc).

But, I think, if the following conditions hold true *before* loading your main game scene then all should be well:
1. Your environment and terrain managers have a TNObject component with a non-zero, unique ID
2. You've connected to a server
3. You've joined a channel

And remember: if you leave the channel that you joined prior to loading the scene, then those static scene objects will be destroyed by TNet. So I'd suggest joining just one channel before loading the main game scene. That way it'll be easier for you to keep track of which channel you need to remain in.

53
TNet 3 Support / Re: Can TNet be used to stream video?
« on: September 13, 2017, 08:22:13 AM »
Yep, but a few major problems:
1. You haven't created a "WebCam" RFC. You probably just omitted it from your example, but thought I'd point it out.
2. data is a buffer with size webcamTexture.width * webcamTexture.height of a type that's 4 bytes long. The most popular webcam on Amazon is 1920x1080, so this means the buffer is 8294400 bytes.
3. You're sending 8294400 bytes every frame. Does your game run at and your webcam capture at 60 FPS? That's 497664000 bytes a second (roughly 500 MB a second, big B).

You're going to need to take the data from GetPixels32 and run it through an encoder to shrink that size dramatically. You'll probably have to restrict the webcam capture to a certain rate, too, but I guess that depends on the encoder. If your webcam performs hardware encoding there should be some way to read that encoded stream from the driver. This is obviously device- and OS-specific but I think it'd be ideal. I've never worked with drivers though so I don't know if that's even possible.

Maybe ArenMook or someone else has networked a webcam through Unity and can provide more direction.

54
TNet 3 Support / Re: Static TNObject IDs
« on: September 13, 2017, 08:07:46 AM »
Ah, no problem. I can't move your topic (I'm not an actual mod - was just given mod to bypass those notices).

I just tried it though. Manager exists in scene 'world' with TNObject (id set to 1). On my main menu scene I connect to the server then JoinChannel (channelID 3, empty string for level name). Then on keypress I load 'world' via Unity's SceneManager. The Manager immediately starts firing off its RFCs. Its TNObject gets its channelID set to 3. On keypress again I load my main menu scene. The Manager object persists (via Unity's DontDestroyOnLoad - not TNet) and continues to fire its RFCs in the main menu.

The only issue I can see arising from this is that you *have* to stay in whatever channel you joined last before loading into the scene with your manager. It doesn't matter how you load the scene. In TNObject's Awake() it'll set its channelID to TNManager.lastChannelID.

I'm not sure this is good design though. Maybe your managers should just keep references to whatever objects they manage and send RFCs via their TNObjects (either GetComponent or expose as public property).

55
TNet 3 Support / Re: Static TNObject IDs
« on: September 13, 2017, 07:05:02 AM »
Nope, nothing about that has changed from TNet2 to TNet3. There needs to be a TNObject on the gameobject and this TNObject needs to have a non-zero ID.

56
TNet 3 Support / Re: Can TNet be used to stream video?
« on: September 13, 2017, 05:55:16 AM »
WebCamTexture.GetPixels32 is the function you need, I think. See this page for an example: https://docs.unity3d.com/ScriptReference/WebCamTexture-didUpdateThisFrame.html
Keep a close eye on your bytes per second.

57
TNet 3 Support / Re: Can TNet be used to stream video?
« on: September 13, 2017, 04:45:21 AM »
In the end, TNet just sends bytes like everything else, so yes it's supported.
But video is heavy, so you're going to have to perform a lot of compression to achieve any kind of suitable result.
I don't have any experience in this area. My brief (5 minutes of googling) research shows H.264 seems to be the standard.
I'd look at how something like OBS works and go from there. I think OBS is open source? I mean, it has open in the name, so I'd hope so.
Then you just have to get the bytes from the webcam, feed them to your encoder, and send the output across the network. Then decode and display on the other end.

A lot harder than it sounds, I'm sure :D maybe Unity already has an encoder you can use? I'd look into their new video player stuff.

58
TNet 3 Support / Re: What are the TNet equivilent of these UNet functions?
« on: September 13, 2017, 04:29:15 AM »
I don't have much (any) experience with UNet, so I may mislead you unintentionally, but:
OnStartClient seems to match up with OnPlayerJoin. OnPlayerJoin is specifically for when other clients join a channel you're in. OnJoinChannel is for when you join a channel.
ClientRpc and Command seem to be RFCs but differ in who sends / receives it. With TNet, if you want an RFC to execute on the host only, you simply check if TNManager.isHosting returns true. If not, return. Furthermore, the sender has some control over who receives the RFC. Target.Others, Target.Host, Target.All, and others.

Don't forget the tutorials stickied at the top of this forum. They, along with the examples you're already going through, should ease the transition a bit :)

59
TNet 3 Support / Re: Delay syncing for joining players?
« on: September 12, 2017, 09:41:06 PM »
dartboy's reply would probably work. Channel#1 has a saved RFC for transmitting whatever data you need for your procedural generation and when that's complete you join Channel#2 for gameplay stuff. Back in 2013 TNet didn't have multi-channel support. Seems well suited to this task now.

60
TNet 3 Support / Re: WAN/LAN Lobby Server Connection Question
« on: September 08, 2017, 07:38:38 PM »
Looks fine to me. You should be able to connect to either 192.168.1.2 or 127.0.0.1. You won't be able to connect using your WAN IP from the same LAN because of router hairpinning.

Pages: 1 2 3 [4] 5 6 ... 19