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 - MCoburn

Pages: 1 [2] 3 4 5
16
TNet 3 Support / Re: UFPS(1.4.9) with TNet
« on: February 12, 2015, 01:36:46 AM »
i will be tackling the UFPS controller in 3-4 weeks...  i'd be happy to share when i get more experience with the asset.  it will start with a mod of "vp_FPInput" to include networking.  check out the quill youtube videos on networking.  the first dozen or so were helpful.
I've been thinking of buying the kit to be honest but I think if I can pull off my own implementation, then it helps me learn the inner workings of a shooter.

17
TNet 3 Support / Re: Query over WIFI LAN Racing Game before purchasing TNet
« on: February 12, 2015, 01:09:22 AM »
Great...

What if there is no WIFI node... and one phone serves as a server and another joins in as a client. Is that a possible scenario?
something like pairing of 2 devices
I think he means something like a game over BlueTooth. Possible, but I don't think Tnet supports bluetooth unless you can get Unity to set up a BlueTooth PAN (Personal Area Network). Not even sure iOS or Android can do that (I'm not a wizard in Bluetooth tech myself).

18
TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans
« on: February 12, 2015, 12:59:41 AM »
Thanks for that. I've had put down the project for a little while (well, at least the Networking Stack part of it) and only just recently picked it up again.

I have a potentially dumb question about the player count. If you're hosting and you set a channel up to host 16 players and then the host instance joins that channel, does that click down the limit to 15?

If I bring up my scoreboard (which is polling TNManager.channel.players.Count), it will say 0 until another client joins. Is this correct, or has TNet reserved a slot so only 15 other players can join instead? Why does it say 0 instead of 1 actual player? Does the local server instance not count as a regular player?

What I intend to achieve if I can get away with it, is the host instance is headless and it'll log to a file, telling the person running the server what's going on via Console (Linux-only maybe?), or it'll show a in-game UI server console but not render 3D graphics.

The other question is, will the lobby server show 1 player on server when the said server instance registers with the TCP Lobby Server, or will it just say 0 players?

EDIT: If a client doesn't send the same protocol version as the server, TNet by default throws a warning in the editor. Is it possible to actually have this as a flag, so if the client is, for example, outdated or they're trying to use another game with the lobby server IP, that I can detect and throw whatever at the player (for example "You need to update to play this title"). Or in standalone, does the TNetLobbyClient.error field get updated with the "not correct protocol" error message?

19
TNet 3 Support / Re: Preventing Cheating
« on: February 12, 2015, 12:31:25 AM »
Also consider learning internal/protected variables in the C# code. This protects the variables being modified from external binaries/assemblies, as per MSDN documentation.
You might also want to make public readonly values, and keep everything else private. For example:

  1. public float currentPlayerMoveSpeed { get { return mySpeed; } }

As this will make a public float that can only be read from, not written to.

Cheat Engine is a pain in the bum in itself and really is only for wannabe hackers. You won't stop the most determined hacker, but one thing is for sure - your game has to be good enough to hack in the first place. A hacker wouldn't want to hack a really boring game, unless he/she had no other things to do with their time.

Unity Player itself have some sort of tamper protection, but then there's the hardcore hackers that are even disassembling the .assets files from the standalone player, making mods to files (changing textures and even meshes (!)) and then repacking them and getting the Player to accept the updated .assets file.

tl;dr: You can deter hackers but we can't beat them with a sure-fire solution.

20
TNet 3 Support / Re: UFPS(1.4.9) with TNet
« on: February 12, 2015, 12:17:35 AM »
Thanks, i'll just go give your email to all the spammers.
Seriously. Don't give out your email address. Instead, ask if anyone's tried to convert UFPS to work with TNet instead.

21
What I learnt is that Rigidbodies are hardware dependent, and can be a pain in the backside to sync. You also run the risk of having sudden "spaz attacks" if players are lagging and then suddenly they go inside of a rigidbody you're controlling. For my shooter project's controller, I'm simply using a character controller to move the character, and hit detection is using rigid bodies on another layer that move with the female mesh animations.

You can use Rigidbodies over the network, but you'll have to do some safeguards.

22
TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans
« on: January 16, 2015, 08:30:22 PM »
Alright, so what voncarp's suggesting is that I embed the Network Management object into the scene as a prefab, so when the scene loads the script is there and RFCs can be received without the errors...

23
TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans
« on: January 14, 2015, 07:07:18 PM »
Where is the RFC being sent from?  Are you streaming the map in?

The RFC is being sent from the "server", which is a client in server mode. When a client-mode client (ie. non-host player) connects, the server fires all the update commands to the client. I think I have it set to OnNetworkPlayerJoin. This would be the issue, because the server is trying to call a RFC on a object that the client doesn't know about yet.

I have a huge map with tons of objects too and encountered this issue a number of times early in my project.  You probably want to make that call after the object is instantiated.

If your streaming with Unity Pro send the RFC after AsyncOperation.isDone or if you have another streaming solution your likely going to need some type of event or isFinishedLoading bool before you start sending the RFC.
I don't do level streaming, my levels aren't open world. They are loaded as a whole (think small maps like Call of Duty, not huge ones seen in Battlefield 3).

Another possible solution depends on your setup is to have the object in scene already and just take the network view. That way its already there and you don't have to wait for anything to load.

In-game UI: uGUI HUD, Scoreboard, etc.
NetworkManagement "Super" GameObject: This handles server and client code. This is TNObject #1

Those look like they could always be in scene.  Just take ownership of it.
I could, but then it has the issue where the UI might be different on a particular map for whatever reason (as in, the prefab didn't get updated on that scene). I'm using prefabs to be on the safe side and UI is not finalized, subject to changes.

What I'll do is when the client connects, I'll broadcast a RequestConfiguration RFC to the channel and the server will respond with the game setup. This might be the antidote to my issue.

24
TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans
« on: January 13, 2015, 10:50:28 PM »
Alright, so I tried this:

  1. void Update() {
  2.         // Check if we're actually finished loading level.
  3.         if (TNManager.isInChannel && !TNManager.isJoiningChannel)
  4.         {
  5.             print("[Client] Finishing server connection phrase.");
  6.             FinishUp();
  7.         }
  8. }
  9.  
  10.         void FinishUp() {
  11.         // while (TNManager.isJoiningChannel) yield return null; <- don't mind this, it's leftovers
  12.  
  13.                 // Spawn our persistent prefabs.
  14.  
  15.                 for (int i = 0; i < prefabsToSpawn.Length; i++) {
  16.                         Instantiate(prefabsToSpawn[i]);
  17.                 }
  18.  
  19.         // Destroy the splashscreen object.
  20.                 Destroy (this.gameObject);
  21.         }
  22.  

This basically checks if we're in a channel and we're not joining the channel (as in, the game's loading something). However, it seems that the RFCs still get triggered before that FinishUp function is called to spawn the persistent objects. Maybe I should just make a RFC that asks the server to send it the configuration when it spawns the NetworkManager object and then go from there...

I'm confused.  :o

25
TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans
« on: January 12, 2015, 07:34:20 PM »
Hrm, it seems TNManager.isLoadingLevel doesn't exist.

26
TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans
« on: January 12, 2015, 02:40:34 AM »
Don't do anything in OnNetworkPlayerJoin. Each client should be creating their own avatar/manager object after the scene finishes loading and TNManager.isLoadingLevel is finally 'false'.
Alright. I'll try this tomorrow, thanks for the advice!

27
TNet 3 Support / Re: unwanted guests
« on: January 12, 2015, 01:07:05 AM »
:o Uh. Please a less tricky solution for next update   ;D
You need to learn how to do tricky things otherwise you won't know how to do it next time :P

28
TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans
« on: January 12, 2015, 01:00:53 AM »
Alright, another issue that I caught:

  1. [TNet] Trying to execute a function 'SetGameMode' on TNObject #1 before it has been created.
  2. UnityEngine.Debug:LogWarning(Object)
  3. TNObject:FindAndExecute(UInt32, String, Object[]) (at Assets/TNet/Client/TNObject.cs:399)
  4. TNManager:OnForwardedPacket(BinaryReader) (at Assets/TNet/Client/TNManager.cs:1089)
  5. TNet.GameClient:ProcessPacket(Buffer, IPEndPoint) (at Assets/TNet/Client/TNGameClient.cs:817)
  6. TNet.GameClient:ProcessPackets() (at Assets/TNet/Client/TNGameClient.cs:747)
  7. TNManager:Update() (at Assets/TNet/Client/TNManager.cs:1113)
  8.  

This error pops up when you go to join a game in progress. When the player has input the IP address of the server they want to connect to, I load a level loading scene which has a script that takes the IP Address, connects to it and handles the channel joining. When the channel is joined, the script spawns two objects:

  • In-game UI: uGUI HUD, Scoreboard, etc.
  • NetworkManagement "Super" GameObject: This handles server and client code. This is TNObject #1

After it spawns them, the script that does the Network join and such kills itself and then those errors occur.

On the host, the host fires them as soon as the client joins inside OnNetworkPlayerJoin(). On the client, the client is still loading the map, which has a lot of objects. I am getting the impression that this is the wrong call to use, because in my case, we're joining the channel and the server is firing the commands to the object that hasn't been spawned yet, hence the error.

Should I instead send a RFC to the host (ie. GetGameConfiguration() ) and let it tell the client what's happening when the client is ready to go?

29
TNet 3 Support / Re: unwanted guests
« on: January 02, 2015, 08:27:07 PM »
Are you using the lobby server functionality or game server from the TNet binary?

If you're using the lobby server (which I am using for my project) then you can tell the binary to be a lobby-server-only configuration. People could discover the IP and ports, I usually set my lobby server to run on a high-number port that is uncommon.

Otherwise if you're using the (dumb) game server, then yes, people could connect to it and make their own channels. You'd need to make something to check if the server is only for a certain project/game and if not, force a disconnection. If you use the game server executable, IIRC it's just a relay between the host (first player that joins) and the other players. I use a P2P setup myself with a lobby server being the "directory" for players to connect.

30
TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans
« on: January 02, 2015, 08:26:24 PM »
I mean create an RFC that you can trigger, and inside that RFC just TNManager.Disconnect(). So when you want to disconnect someone, just send them that RFC.
Alright, that's what I was thinking myself. Just wanted to be sure we're all on the same page. :)

Pages: 1 [2] 3 4 5