1
TNet 3 Support / Re: How can i make server-raycast system?
« on: February 12, 2018, 11:23:02 PM »
tno.isMine TNManager.IsHosting
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.
2
TNet 3 Support / Re: Can a TNObject belong to multiple channels?
« on: February 12, 2018, 11:20:32 PM »
You'd have to iterate every other UID in the channel to make sure it's unique then handle cases where it wouldn't be unique.
If you want the host to have authority, then the host has to know everything that's pertinent to its authority. You'd have to have the host join every channel that a player is in. Or use custom packets to communicate out-of-channel.
If you want the host to have authority, then the host has to know everything that's pertinent to its authority. You'd have to have the host join every channel that a player is in. Or use custom packets to communicate out-of-channel.
3
TNet 3 Support / Re: A few questions (ChannelData, TNObject Data, DataNode, Custom Files)
« on: February 10, 2018, 11:59:07 AM »
Channel data is saved in server.dat (can also be named world.dat, or whatever you specify as the -fn arg when starting the server). I think saved RFCs should work for what you need (just send the RFC with Target.AllSaved, Target.OthersSaved, etc etc). Server data could be a good place too, it really depends on how you want to organize it. Just remember: if you run multiple instances of the server from the same executable, you should pass a different -fn argument for each instance so they don't accidentally use the same .dat and .config files (unless you want that behaviour).
I've never used TNObject.Get/Set. Looking at the code, they do use Target.OthersSaved so they will be automatically saved as channel data.
There's an overload for DataNode.Write that accepts a StreamWriter. If you have a MemoryStream as the backing stream for the StreamWriter then you can call MemoryStream.ToArray() to get a byte[] that you can pass to TNManager.SaveFile. Aaaaaand I just realized DataNode has a ToArray function that does exactly as I described. Yeah, much easier. You can specify SaveType.Text too.
But using TNManager.SaveFile/LoadFile in place of TNet's existing save system is creating additional work for yourself. It's functionally no different than relying on saved RFC's or channel/server data, only that you're recreating a big chunk of the wheel. Channel / Server data use DataNode's as well and are saved exactly the same way, but it's done all automatically for you. You will be stripping away a huge chunk of TNet's power by not using any saved RFCs or channel/server data.
For your bonus question:
Instantiate it as you normally would, but specify that it should be persistent. This ensures that when the player that instantiated the chest (crafted and placed it) logs off that the chest will remain there for others to use. Its inventory can be synced and saved using saved RFCs.
TNet has great data persistence out of the box.
I've never used TNObject.Get/Set. Looking at the code, they do use Target.OthersSaved so they will be automatically saved as channel data.
There's an overload for DataNode.Write that accepts a StreamWriter. If you have a MemoryStream as the backing stream for the StreamWriter then you can call MemoryStream.ToArray() to get a byte[] that you can pass to TNManager.SaveFile. Aaaaaand I just realized DataNode has a ToArray function that does exactly as I described. Yeah, much easier. You can specify SaveType.Text too.
But using TNManager.SaveFile/LoadFile in place of TNet's existing save system is creating additional work for yourself. It's functionally no different than relying on saved RFC's or channel/server data, only that you're recreating a big chunk of the wheel. Channel / Server data use DataNode's as well and are saved exactly the same way, but it's done all automatically for you. You will be stripping away a huge chunk of TNet's power by not using any saved RFCs or channel/server data.
For your bonus question:
Instantiate it as you normally would, but specify that it should be persistent. This ensures that when the player that instantiated the chest (crafted and placed it) logs off that the chest will remain there for others to use. Its inventory can be synced and saved using saved RFCs.
TNet has great data persistence out of the box.
4
TNet 3 Support / Re: Quick call of server stop results in editor/build freeze
« on: February 10, 2018, 09:27:29 AM »
What exactly are you doing to trigger the freeze? Is it a hard freeze of the entire editor or just the game playback window? Does it ever unfreeze?
But yeah, starting and stopping the server very rapidly multiple times isn't healthy anyway: the OS has to do a lot of work to clean up those sockets. Same with file I/O. Basically anything that uses handles.
But yeah, starting and stopping the server very rapidly multiple times isn't healthy anyway: the OS has to do a lot of work to clean up those sockets. Same with file I/O. Basically anything that uses handles.
5
TNet 3 Support / Re: TNObject and rigid bodies bouncing
« on: February 10, 2018, 09:21:24 AM »
The TNSyncRigidbody script uses Target.OthersSaved which means the last network update is saved and re-transmitted when you re-connect (or when another player connects). This is probably why you get the little bounce. You can change it to Target.Others but then it'll lose position syncing for any new players or upon re-connecting.
The fix is to change velocity and angular velocity to be using Target.Others and the position and rotation to (continue to) be using Target.OthersSaved. They'll each need their own RFC.
The fix is to change velocity and angular velocity to be using Target.Others and the position and rotation to (continue to) be using Target.OthersSaved. They'll each need their own RFC.
6
TNet 3 Support / Re: I tryed to make animator sync script,but it has isues
« on: February 10, 2018, 09:08:42 AM »
The usual practice is to sync the action not the reaction. Animation occurs as a reaction to something, for example: player presses left-click to attack with a sword, the swing animation then plays. You'd want to send the "player has pressed left-click" part over the network and not the "sword is swinging" part.
I think this applies well in all cases, even with something like a ragdoll.
I think this applies well in all cases, even with something like a ragdoll.
7
TNet 3 Support / Re: how to know PlayersCount?
« on: January 10, 2018, 12:07:59 AM »
Not possible on the client. You can get a list of players given a channel ID but you have to be in that channel for it to work (TNManager.GetPlayers)
You could implement a custom packet and use that. The GameServer has an onCustomPacket delegate.
Though I'd ask why the client needs to know about every player on the server instead of just the ones in their channel. Only the players in the client's channel(s) are relevant.
You could implement a custom packet and use that. The GameServer has an onCustomPacket delegate.
Though I'd ask why the client needs to know about every player on the server instead of just the ones in their channel. Only the players in the client's channel(s) are relevant.
8
TNet 3 Support / Re: start localServer
« on: January 07, 2018, 09:07:34 AM »
Guessing it's throwing at GetControlURL as that's the only place that attempts to make a connection.
Dunno why it's happening. Quick google shows it's either a malformed URL or something with your proxy settings? Dunno how mono handles web requests and proxies though.
Try setting a breakpoint on GetControlURL and see what the url argument is. If it's not a valid URL you'll want to set a bp on ParseResponse and figure out why it's not able to parse out a correct URL.
Dunno why it's happening. Quick google shows it's either a malformed URL or something with your proxy settings? Dunno how mono handles web requests and proxies though.
Try setting a breakpoint on GetControlURL and see what the url argument is. If it's not a valid URL you'll want to set a bp on ParseResponse and figure out why it's not able to parse out a correct URL.
9
TNet 3 Support / Re: lobby server
« on: January 07, 2018, 08:58:55 AM »
Must be a bug in the tcp lobby then.
10
TNet 3 Support / Re: flag of country for server
« on: January 05, 2018, 10:40:40 PM »
Yep that's the only way to do it automatically. You could also have your users choose which flag to display if you don't want to mess with geolocation.
11
TNet 3 Support / Re: lobby server
« on: January 05, 2018, 10:38:47 PM »
I'm not sure what you're asking. You can launch a TNet server that acts as both a game server and lobby server:
That should start a game server on ports 5127 and 5128 and a lobby server on port 5129. The game server part will automatically register itself with the lobby server part.
- @echo off
- start "TNet Test Server" "TNServer.exe" -name "TNet_TestSrv" -tcp 5127 -udp 5128 -tcpLobby 5129
That should start a game server on ports 5127 and 5128 and a lobby server on port 5129. The game server part will automatically register itself with the lobby server part.
12
TNet 3 Support / Re: lobby server
« on: January 05, 2018, 04:22:10 AM »
Launching a dedicated lobby server:
Launch the dedicated server as you normally do, but specify the lobby port (udpLobby is valid too).
Registering dedicated game servers with your lobby server:
Simply launch the dedicated server using a batch file like this:
Registering runtime-created servers with your lobby server:
Launch the server as you normally do but pass in the endpoint for your lobby server.
Connecting to the lobby server and retrieving list of registered servers:
Attach a TNTcpLobbyClient component to any gameobject. Then, in your code, use TNLobbyClient to access lobby data. It just works.
And for your last question, I'm not sure. You can pass a callback to UPnP's Open function and see if UPnP was able to automatically port-forward, but UPnP failing doesn't necessarily mean the user is unable to host a server (they could have manually forwarded their ports or they aren't behind NAT). The only way I can think of is writing a super small client & server. Client takes in your gameserver's port and sends it to server. Server attempts to connect to port. If connection fails, notify client. Client notifies caller. Host the server somewhere remote. You could build this into TNet's lobby server, actually, so you wouldn't even need to write the client part.
Launch the dedicated server as you normally do, but specify the lobby port (udpLobby is valid too).
- @echo off
- start "TNet Test Lobby Server" "TNServer.exe" -name "TNet_TestLobbySrv" -tcpLobby 5129
Registering dedicated game servers with your lobby server:
Simply launch the dedicated server using a batch file like this:
- @echo off
- start "TNet Test Server" "TNServer.exe" -name "TNet_TestSrv" -tcp 5127 -udp 5128 -tcpLobby "192.168.1.2" "5129"
Registering runtime-created servers with your lobby server:
Launch the server as you normally do but pass in the endpoint for your lobby server.
- TNServerInstance.Start(5127, 5128, "", Type.TCP, new IPEndPoint(IPAddress.Parse("192.168.1.2"), 5129), true)
Connecting to the lobby server and retrieving list of registered servers:
Attach a TNTcpLobbyClient component to any gameobject. Then, in your code, use TNLobbyClient to access lobby data. It just works.
And for your last question, I'm not sure. You can pass a callback to UPnP's Open function and see if UPnP was able to automatically port-forward, but UPnP failing doesn't necessarily mean the user is unable to host a server (they could have manually forwarded their ports or they aren't behind NAT). The only way I can think of is writing a super small client & server. Client takes in your gameserver's port and sends it to server. Server attempts to connect to port. If connection fails, notify client. Client notifies caller. Host the server somewhere remote. You could build this into TNet's lobby server, actually, so you wouldn't even need to write the client part.
13
TNet 3 Support / Re: Directly editing player save file results in old version being loaded...
« on: January 04, 2018, 08:45:49 PM »
Sorry I wasn't clear. That's exactly what I did when testing and I wasn't able to reproduce your problem.
14
TNet 3 Support / Re: Directly editing player save file results in old version being loaded...
« on: January 02, 2018, 10:40:57 PM »
I'm not able to replicate this.
In TNManager's OnConnect callback I do as the tutorial specifies: TNManager.SetPlayerSave(SystemInfo.deviceUniqueIdentifier + "/Player.dat", DataNode.SaveType.Text);
If I load up the file and manually change name to 'nottesting' and run the game again it'll have the name 'nottesting' as expected. Pressing 'S' then changes it to 'testing'.
- using UnityEngine;
- using TNet;
- public class EditPlayerSaveTest : TNBehaviour
- {
- private void OnEnable()
- {
- TNManager.onSetPlayerData += OnSetPlayerData;
- transform.name = TNManager.player.Get<string>("Name", "<null>");
- }
- private void OnDisable()
- {
- TNManager.onSetPlayerData -= OnSetPlayerData;
- }
- private void Update()
- {
- if (Input.GetKeyDown(KeyCode.S))
- {
- TNManager.SetPlayerData("Name", "testing");
- }
- }
- void OnSetPlayerData(Player p, string path, DataNode node)
- {
- Debug.Log(name + " Saw OnSetPlayerData");
- if (p != TNManager.player) return;
- transform.name = p.Get<string>("Name", "<null>");
- }
- }
If I load up the file and manually change name to 'nottesting' and run the game again it'll have the name 'nottesting' as expected. Pressing 'S' then changes it to 'testing'.
15
TNet 3 Support / Re: SetPlayerSave callback
« on: January 02, 2018, 09:24:08 PM »
Yeah, you'd need to add a boolean like "isAuthenticating" to your gamecode to properly handle the callback in that case.
I agree it makes sense to have its own callback or at least an additional argument in the existing callback.
I agree it makes sense to have its own callback or at least an additional argument in the existing callback.