Messages

1

NGUI 3 Support / Re: Weird transparency sorting problem with new NGUI

« on: May 02, 2014, 05:03:45 PM »

Omg, I'm looking 4 hours into this and after writing this I found the solution 5 minutes after. Typical, isn't it?

I explicitly set the camera now to

1. camera.transparencySortMode = TransparencySortMode.Orthographic;

This solves the issue. That the issue didn't occur in the old version perplexes me still, but at least it's solved.

Greetings

2

NGUI 3 Support / Weird transparency sorting problem with new NGUI

« on: May 02, 2014, 04:54:03 PM »

Hey Tash!

I recently upgraded from 3.0.6 f1 Ngui to the latest (3.5..

There was no problem with NGUI itself but my quad rendering was suddenly screwed up. Here's a screen:


First I thought, NGUI can't be the problem here, but I reverted back and forth to the old version and it was always the same result. Old worked, new one doesn't
I use a custom shader for quads, no NGUI stuff used.

So do you know, if there's anything that could interfere with this?

Thanks in advance

3

NGUI 3 Support / Re: Non-Automatic UIRoot affects mouse position on drag

« on: May 27, 2013, 06:00:24 PM »

Just stumbled upon this.

UIRoot.screenSize doesn't exist anymore. What can I use instead?

Thanks

edit: Got it

1. int manualHeight = NGUITools.FindInParents<UIRoot>(gameObject).manualHeight;
2. int screenHeight = Screen.height;
3.  
4. float scaleDiff = (float) manualHeight / screenHeight;
5. delta *= scaleDiff;
6.  

4

TNet 3 Support / Re: Coming from built-in Unity networking

« on: March 05, 2013, 01:03:47 PM »

And as I always say, make a game that's worth hacking, then worry about hacking.

Excellent quote. I'll remember this.

But on topic. The server knows from which client it came through the IP address. That's pretty spoof free, isn't it?

Also if things should get more secure I'll add a simple system that sends an ID or string generated on the server to a client, so only the client and no one else knows about it. This ID/string is requested with every packet (guess this is overkill) or on a random timed (0.5-2sec) AUTH_CHALLENGE packet. If the client fails to send this, packets will be ignored.

With TCP I shouldn't have a problem with this. Kind of the OAUTH system that facebook uses only very stripped down.

5

TNet 3 Support / Re: UDP in the web player is simply no longer supported.

« on: March 02, 2013, 11:30:14 AM »

Oh my that's absolutely horrible to hear and stupid beyond belief on Unity's part.

From what I read now it's technically not an issue but Unity's socket layer requests the crossdomain.xml with every UDP send/rcv and doesn't buffer it.

6

TNet 3 Support / UDP in the web player is simply no longer supported.

« on: March 01, 2013, 06:49:05 PM »

Hey!

Can you tell me why that is?

7

TNet 3 Support / Re: Authoritative server; anti-cheating; and protected content

« on: February 08, 2013, 03:12:33 PM »

Hey!

Yes, I'm using the standard package. Running it is actually quite simple. Make a ServerStart.cs script, create a GameServer object, set parameters and Start it. I also added a public ServerStart property to GameServer.cs so I can communicate easier through a dispatcher.

Keeping the two threads safe isn't really problematic either. What you need is a proper thread safe generic array and not to many calls from thread to thread. I abstracted everything to a UserCommand class that has the info of user keystrokes and/or states. (rotation for example)

But keep in mind that you probably won't need this if you're running a 16-32 player server. I try getting 50-100 players into a lobby so optimizing and having the least amount of bottlenecks is crucial. The least thing you want is not receiving packets just because something stalls in the unity thread. And thanks to the garbage collector these things can happen.

8

TNet 3 Support / Re: Authoritative server; anti-cheating; and protected content

« on: February 06, 2013, 06:39:26 AM »

Hey!

Yes this is possible, I use it for my project. I'm running the TNGameServer in a parallel thread to Unity. The GameServer is able to communicate with thread safe singletons but you want to minimize this as much as you can.

You are pretty much safe from "hacker packets" but that also depends how you're calculating things on your server. I'm only using keypress packets and simulate the world on the server. It's tricky at first to get it right but when you got it it's very solid approach imo. I tried several other techniques and was really unhappy with the results, especially sending only the delta keypresses. (User pressed Forward and calculate from there on till the user released Forward) It's too error prone for just a little saved bandwidth.

The cool thing about this is that you have a lot of control what happens and when. The server is never reliant on the simulation and vice versa. Also you'll dip in threading problems a lot if you don't have proper classes and not implement the BeginSend/EndSend workaround that I used in another thread.

I don't know how your coding skills are. If they are not that high I'd recommend using the normal GameClient code for the server and strip away the unnecessary stuff.

9

TNet 3 Support / Re: Stresstesting - EndSend Exception

« on: February 04, 2013, 01:27:33 PM »

My unity server setup is the root cause. There's the unity thread running and parallel the server thread.

I know it sounds weird, initially I thought it would be a good idea.

edit: I got it under control with a SendLock object and Monitor.Enter(sendLock); in BeginSend and Monitor.Exit(sendLock); at the end of every EndSend. Not perfect but it's thread safe now.

10

TNet 3 Support / Re: Stresstesting - EndSend Exception

« on: February 03, 2013, 07:08:10 PM »

Damn, the problem still persists.

Ping is still sending in between my sends even though it runs from a single gameobject with a PacketSender script that sends at a given interval.

Back to Square1 I guess. ^^

11

TNet 3 Support / Re: Stresstesting - EndSend Exception

« on: February 03, 2013, 09:40:40 AM »

Ok, 2 good news and 1 bad news. You're right in your assumption that the buffer is not null when I call BeginSend.
The bad news is, it's thrown from a ResponsePing packet and not my packets.

The 2nd good one is that I can fix the problem when I comment out

1. //BeginSend(Packet.RequestPing);
2. //EndSend();
3.  

in TNGameClient.cs

Any ideas?

edit: I'll just ignore this behavior and rewrite the current individual sending to a more centered approach. Just wanted to let you know about this behavior. A system can never be solid enough. I ran into threading problems myself last week and that was NOT fun, especially in a network environment. Testing and debugging is soooo time consuming.

edit2: Sending is rewritten and I can't reproduce the problem anymore. Thanks!

12

TNet 3 Support / Re: Stresstesting - EndSend Exception

« on: February 02, 2013, 09:58:27 PM »

Hm, doesn't happen. Are you ruling out a threading problem?

To clarify, every networkPlayer on my server has a UserCommandProcessor script that checks if there was a new userCommand recieved, if yes process them. After this simulation tick I send position/rotation/animation states, etc.. to the client. This happens every 0.015ms. Maybe it's too much. I use some timings that Valve uses as a reference.

13

TNet 3 Support / Stresstesting - EndSend Exception

« on: February 02, 2013, 08:51:43 PM »

Hello!

It's the following setup:
- client and server on the same machine.
- client focused that it has 100% performance (best with vsync off)
- server in idle mode

What happens is that the server is stuttering but the client still sends around 1kb/sec.

As a result I'm getting random disconnects that I could pin down to an EndSend exception:

1. NullReferenceException: Object reference not set to an instance of an object
2. TNet.GameServer.EndSend (Boolean reliable) (at Assets/Scripts/TNet/Server/TNGameServer.cs:718)
3. UserCommandProcessor.FixedUpdate () (at Assets/Scripts/ArenaGank/UserCommandProcessor.cs:82)
4.  

I added some stuff so if your lines don't match:
718: mBuffer.EndTcpPacket(); // in public void EndSend(bool reliable)

and after a little while:

1. 30.915 Process player connections nextObject reference not set to an instance of an object   at TNet.GameServer.EndSend (Boolean reliable, TNet.TcpPlayer player)
2. [0x0005d] in C:\Users\Enzi\Documents\Unity3d\AG_Server\Assets\Scripts\TNet\Server\TNGameServer.cs:681
3.   at TNet.GameServer.ProcessPlayerPacket (TNet.Buffer buffer, TNet.TcpPlayer player, Boolean reliable)
4. [0x00199] in C:\Users\Enzi\Documents\Unity3d\AG_Server\Assets\Scripts\TNet\Server\TNGameServer.cs:923
5.   at TNet.GameServer.ThreadFunction ()
6. [0x00125] in C:\Users\Enzi\Documents\Unity3d\AG_Server\Assets\Scripts\TNet\Server\TNGameServer.cs:283
7. UnityEngine.Debug:Log(Object)
8. StartServer:Update() (at Assets/Scripts/AG/StartServer.cs:45)
9.  

where:
681:mBuffer.Recycle(); // in public void EndSend(bool reliable, TcpPlayer player)
923: EndSend(true, player); // in case Packet.RequestPing:
283: if (ProcessPlayerPacket(buffer, player, true))

Are you familiar with this problem? Does the buffer run out or something? Threading problem? *shiver*

As a workaround I'm setting the priority for the unity server to high. It eliminates the problem but the server will still crash under heavy load. (I guess)

Thanks in advance!

14

TNet 3 Support / Re: TNet: Tasharen Networking Framework

« on: January 27, 2013, 08:16:11 AM »

Quick question. In TNGameServer.cs every EndSend has mBuffer.EndTcpPacket even when reliable is false. Is this intended? If yes, why is that?

15

TNet 3 Support / Re: TNet: Tasharen Networking Framework

« on: January 25, 2013, 12:39:20 PM »

Zyeurgh, if you are working with DateTime.Now, keep in mind that it can be different on each client. You also have to sync this. I had to do this. But for overall timing I'm using simulation duration now instead of timestamps. The are annoying to work with because they are so inaccurate. So don't use them if you really need exact timings.