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
46
TNet 3 Support / Re: RFCs looping, freezes TNet stack and Unity
« on: October 21, 2014, 12:21:28 AM »
When you send an RFC, it will be called on the same TNObject. If you want to call an RFC on a different TNObject, then do just that -- it's like calling a function on a different component.

P.S. Why do you do the "to.Send" instead of using the built-in "tno.Send"? Make sure your script derives from TNBehaviour.
The scripts are MonoBehaviours. So if I replace that with TNBehaviour, it should be okay?

What a really wanted was a independent gameobject handling UI elements like scoreboard, etc. So that means to get the RFCs, I would need to assign the game object a TNObject ID, no? I'm confused...

47
TNet 3 Support / Re: Unityscript with WP8 is producing errors
« on: October 20, 2014, 09:26:27 PM »
Well, I stand corrected then.

Have you tried reimporting the latest package of TNet? Have you moved the TNet folder under Plugins or just TNet/Client into Plugins/TNet/Client ?

48
TNet 3 Support / Re: RFCs looping, freezes TNet stack and Unity
« on: October 20, 2014, 08:48:27 PM »
Okay, that works, but I want the void to be fired on the NetworkKillFeed script, not the same player script. It works as intended so far, but the NetworkKillFeed doesn't show up the entry as the RFC only gets fired on the playervitals script.

How do I get the script to trigger the RFC on that KillFeed script so it can add it to the log?

49
TNet 3 Support / [SOLVED] RFCs looping, freezes TNet stack and Unity
« on: October 20, 2014, 12:45:57 AM »
Alright, so here I am trying to make a Networked Kill Feed, so when someone frags the other player, it registers up in the frag list. This is the base script for that killfeed:
  1. public List<string> fragFeed = new List<string>();
  2.  
  3.     void OnGUI()
  4.     {
  5.         // The frag feed.
  6.         GUILayout.BeginArea(new Rect(Screen.width - 320, Screen.height - (amtOfFragsShown * 24), 310, (amtOfFragsShown * 24)));
  7.         GUILayout.BeginVertical();
  8.  
  9.         for (int i = 0; i > amtOfFragsShown; i++)
  10.         {
  11.             GUILayout.Box(fragFeed[i]);
  12.         }
  13.  
  14.         GUILayout.EndVertical();
  15.         GUILayout.EndArea();
  16.     }
  17.  
  18.     [RFC]
  19.     void AnnouncePlayerAction(string whatHappened)
  20.     {
  21.         Debug.Log("Got a player announcement...");
  22.         fragFeed.Add(whatHappened);
  23.     }
  24.  

In the appropriate scripts, I have this. This is taken from the player vitals script, which is basically the "heart" of the player - if they die, it does all the required things on death (respawn, ragdoll, etc). This function is the one that gets triggered when you take the easy way out or you fall into the void and the level OOB triggers hit the character.

  1. // ......
  2.    private void KillSelf()
  3.     {
  4.         AnnouncePlayerAction(TNManager.playerName + " ended it all");
  5.         currHealth = 0;
  6.     }
  7.  
  8.     [RFC]
  9.     void AnnouncePlayerAction(string whatHappened)
  10.     {
  11.         Debug.Log("Got a player announcement...");
  12.         to.Send("AnnouncePlayerAction", Target.All, whatHappened);
  13.         // fragFeed.Add(whatHappened);
  14.     }
  15.  

However, the issue here is that it loops itself and basically freezes Unity or the Unity Player, requiring a Task Manager to kill the process. Basically, I want to have one script fire the RFC to "announce" the event, and then the other script, which is the Network Feed script, to pick up the message, add it to the list, and then go from there.

Could you assist?

50
TNet 3 Support / Re: Unityscript with WP8 is producing errors
« on: October 20, 2014, 12:26:07 AM »
You shouldn't put TNet under plugins. It's not a compiled DLL. Just leave TNet's folder under assets.

51
TNet 3 Support / Re: Client Camera
« on: October 19, 2014, 09:26:07 PM »
How would i go about creating a camera when a client joins and then making the client owner of the camera, so everything in the camera like controller scripts and rendering only apply to that client.

I am a noob at multiplayer so thank you to anyone who can help.

What I am doing in my shooter is that the rig that controls the player has the camera, and then in the main logic script I have a check like so:

  1. public GameObject rigCam;
  2. private TNObject to;
  3.  
  4. void Awake() {
  5.    to = this.gameObject.GetComponent<TNObject>();
  6.  
  7.    // .....
  8.    if(!to.isMine) rigCam.SetActive(false);
  9. }
  10.  
So that only your camera is the one that gets rendered.

I found that if you use Start() for the TNObject check, it will throw a Null Reference Exception so Awake seemed a better fit.

52
TNet 3 Support / Re: TNet Server on Amazon EC2 linux
« on: October 07, 2014, 12:46:44 AM »
Copy the Assets/TNet folder from the UnityPackage to the server.

53
TNet 3 Support / Re: TNet: Network Level Loading
« on: October 06, 2014, 06:54:03 PM »
@MCoburn and @Nick: As I always say make a game worth hacking first, and then worry about hackers. Preventing hacking is like preventing piracy. You can try, but you will fail. You can make it less convenient for them, sure -- but you won't prevent them from getting the results they want in the end. Also keep in mind that some games actually benefit from a lack of such features. Anything you want moddable is better left without server-side checks for example.

That rings true. I guess hackers won't want to hack a game that isn't deemed worthy of hacking. I spoke to my teammate and we agreed that there's always going to be a minority of the public who want to flex their hacking skills, either for fun against there hacker friends, or just script kiddies.

At the very least, Unity's runtime has some sort of protection. I'm not sure how well that protection works, but it's not using a engine, like say IDTech where it's rather easy to hook up an aimbot. Whatever the case, I think for now I focus on making the game happen, then if the hacks occur, see what vectors they are attacking and then revise that chunk of the code. Like I said, we can't have the "perfect" app that is 100% hacker proof, somewhere there's bound to be a guy/girl poking memory and looking through the code to see what is going on.

I will protect the vitals though, such as health and such.

54
TNet 3 Support / Re: TNet: Network Level Loading
« on: October 04, 2014, 06:52:23 PM »
What level of cheat-prevention are you aiming for in your project? Because with the strategy you outlined, I'd imagine it'd be fairly easy for clients to misreport their location to peers, and cause some major issues. Doing hit / collision checking on one host should avoid major score / state synchronization issues, but wouldn't a client misreporting it's position cause problems? Client A could report it's position falsely and make it to be nearly impossible for clients B, C, and D to hit client A between the update on their screens and the roundtrip back to the "host".

I ask because I feel like your end-goal is the same as my own, and am at the point where I have to make smart architecture decisions. It's pretty desirable to have the server doing as little as possible, but having no cheating is important too.
Honestly, I'm not quite sure what implementation I should go with. I just don't have the finances to afford game servers that have big capacities of CPU grunt and RAM which is annoying, but as a 2-man start-up you have to do what you have to do. Even if I did have the finances, I would be spending it on team development hardware and software licensing, plus business costs.

What I can see is the "host" is the one that dictates what's going on, as for the match type, scoreboard, timer, etc. When a weapon requests to fire, it (the host) does the estimation and all the related things. I could view this as a "Thin Client Network" in the IT sector. However, as Aren stated, it's better to let the clients do all the other work, rather than just be a "puppet". Then another factor is client correction - the server needs to be able to tell a client "hey, you goofed, get back to Vector3(x,y,z)".

I really don't know. I think it's best if I can get together with someone who has worked on network systems before and discuss it with them, otherwise I'm going to run around in circles and goof something up. Cheating may happen, but hopefully kits like Anti-Cheat Toolkit will help protect the core, but not eliminate all the vectors. I'll possibly rely on community reporting, and have a function assigned to a snap key that will take a picture of whatever's on screen and relay it to the team with a message for review. I will, however say that if the players are found to be cheating with enough evidence (Aimbot, etc) they will be banned for oblivion (however I implement this will be a discussion topic down the track).

I don't mind having another brain (;)) to help assist with game coding areas that I am not fluent in.

I see two extremes: one end of the spectrum is having clients do everything, but that is the worst-case scenario for cheat prevention and best for resource utilization. The opposite is having a server do everything, which is the best case scenario for cheat prevention, but terrible on resource utilization. I realize it's really dependent on the game, but is semi-authoritative generally the balanced option?
I'd love to see what Aren weighs in with.

55
TNet 3 Support / Re: Dynamic Prefabs with Tasharen
« on: October 02, 2014, 11:07:24 PM »
EDIT: I read 'character' as 'car'. Why the heck did I do that for?!  ???

Here's one way of doing it:

Spawn a prefab of a generic car, or all the cars and everything packed into one prefab. Have it under nested GameObjects, like:

  1. DragCar
  2. -- V12 SuperCharger
  3. ---- Body
  4. ---- Decals
  5. -- V8 Turbo Diesel
  6. ---- Body
  7. ---- Decals
  8. <etc>
  9.  

Have a script attached to it that checks what the player settings are (ie. decals, Nitro, exhaust, paint job, etc) and enable/disable the child game objects depending on what the car has.
You might get a minor performance hit but since the script will kick in ASAP, the player shouldn't notice a big black box thing as the car is customized.

56
TNet 3 Support / Re: TNet Server on Amazon EC2 linux
« on: October 02, 2014, 11:01:38 PM »
You'll need to install "mono-complete" in Ubuntu or Debian. I did this on a ARM-based ODROID-XU.

  1. apt-get install mono-complete

This will pull a lot of dependencies including NET 2.0 to 4.0 support. Then, upload your TNServer stuff to a empty directory (ie. <homedir>/tnet ). Change into that directory and run "xbuild".

Then all you need to do on the binary is:

  1. mono TNServer.exe <vars go here>
.

Make sure you open your firewall ports in both Amazon Security Groups AND iptables!

If you have any issues, I can try to help. I successfully compiled 1.9.9 and 2.0.0 on Ubuntu 14.04 both on a Core i5 x64 machine, and a ODROID-XU ARM machine. I'm a linux system administrator so I know a fair chunk of issues that can stump newcomers.

57
TNet 3 Support / Re: TNet: Network Level Loading
« on: October 02, 2014, 10:56:07 PM »
Do you mean this in general, or for this specific scenario? I hate to hijack the thread
No offense taken. You raised a valid point.

but I was curious as to why you recommend not doing logic on the server with TNet.

I was under the impression I could build an authoritative server with TNet that ran a game simulation and updated each client. The clients could worry about prediction, rendering, gathering input to change the simulation.

My setup that I'm hoping to implement is sorta semi-authoritative. The server will run the prediction when you shoot your weapon, and report back to the client that request the shot "that's a hit on X", "that's a hit on Y", "no, you missed Z".

The problem with authoritative, is while the server is the master and controls everything, that's a lot of work for the server to do. If you have the CPU, RAM and knowledge then sure, you can do it - TNet is just a cake and you can put whatever icing you want on top. In my setup, I prefer to have the clients be "dumb" to some extent, but when you fire the weapon, the hosting player has the final say.

The host handles the Score Board and weapons. The connecting clients just report to each other where everyone is and what they are doing (moving, dead, idle ... etc). One thing we also need to do is Entity Rewinding... to help compensate for lag/jitter.

58
TNet 3 Support / Re: TNet: Network Level Loading
« on: October 02, 2014, 02:05:26 AM »
Uh.... double quote, wth?  :o

TNet doesn't track level loads you do yourself.

1. When you want to join a channel, first Application.LoadLevel your scene with the loading screen. Set this screen's game object to be DontDestroyOnLoad, and proceed to TNManager.JoinChannel to your proper game scene.

2. When you get OnNetworkJoinChannel, fade out your loading screen, then destroy the game object you marked as DontDestroyOnLoad.
Alright, I took your advice and it worked as intended.

When I connect to the server (in this case, a in-game hosted one), I immediately load a dummy scene (mp_superflat_load) with the splash image and invoke joining the channel that loads the correct level (mp_superflat). There is a little delay as Unity loads the level. When the channel is joined, it sets a flag, eases out the splash image which reveals the level and everything under that. Let's just hope it doesn't bug out. :P

Now with this in mind, I can focus on player controls and Network Sync...

59
TNet 3 Support / Re: TNet: Network Level Loading
« on: October 01, 2014, 02:55:54 AM »
So, you're saying create the server, then join a channel with the respective ID (let's say 1) and the levelname of say "mp_superflat_loader" that contains the UI overlay of the loading screen and the level loading script. TNet will load that level, which will start the actual proper level loading process, which level is "mp_superflat_real".

When the level loading isDone flag is true, then the script triggers the "OnLevelWasLoaded" call to spawn the client-side player manager, destroys itself, and then the player has it's control ?
Would I need to tell TNet to pause network queue processing before I start loading? Or will TNet detect I'm loading the level and auto-pause itself?

60
TNet 3 Support / Re: TNet: Network Level Loading
« on: September 30, 2014, 01:07:25 AM »
How would one go about putting a splash screen with a preview of the level before TNet actually joins the channel and loads the specified level?
At the moment, I have "server and client" functionality working - you select your server parameters, and then hit start and TNet boots up.

This is no biggie for the host. I can just make a toggle that will overlay the "Loading..." screen with a level image and then use TNet.LoadLevel("blah");

However, on the client, we connect to the server, then join channel 1 (which is the actual game channel). However, unless we poll the ChannelList first so we can get the level parameter from the channel that the game is happening on, the client will just "freeze" on whatever was there in the scene until the level is done loading.

Is it possible to get a channel's data like TNManager.client.RequestChannelInfo(id of channel) ? This would be really beneficial, because I can fetch the level out of the returned info, display the respective splash screen and then let TNet do the loading.

Or do you have another idea?

Pages: 1 2 3 [4] 5