Messages

1

TNet 3 Support / Re: Socket is still listening after/if Unity crashes

« on: September 12, 2013, 11:31:55 AM »

We had this problem as well, basically - things can and will crash. They'll crash for reasons you have no control over. Antivirus might kick in when the game is running. Windows update. A skype message. Or an incoming call from a mobile phone. Lack of ram. Bad display driver. Computer overheats. Os messages. All sorts of things, the list of reasons why something will crash is pretty much endless, and often this is nothing to do with your code.

The only workaround in these situations is to host the server apart from the client. The concept of any client running a server is a nice one, and achievable but problems like this can and will happen. I can't think of any resolution for it really

2

TNet 3 Support / Re: TNet roadmap?

« on: September 03, 2013, 07:21:42 AM »

Note: not trying to change or argue with TNet's direction - I feel it probably is better suited to TCP as well, but onto the discussion:

Sounds very awesome! Regarding UDP, there's a solid open source UDP here: http://enet.bespin.org/

As for first packet being lost via UDP - as you know if TCP has been in use heavily by the system, there is proof online that a computer using TCP will cause a higher rate of UDP traffic to drop. So you're authenticating, you're setting up a users, or a chrome browser is refreshing, or twitter client is refreshing, or any number of things on a typical system will cause that first UDP packet to fail a lot more than normal - something like 5% to any%. This means doing a single test for UDP then telling the system to be TCP only isn't a very good move overall. But that's only a bad move if the system really should support UDP.

Regarding photon latencies, I found europe tests and US tests (respectively) to be within the 40ms range. This is slower than TNet which saved 10ms on average (not worth worrying about in terms of difference). People will need to run a server somewhere that manages traffic. This is what Photon cloud does. So performance wise, I don't really see much of a difference if you want the game to continue after a host quits. I don't think currently, it's vital for a user to host the relay server, in fact it means more dropped games at this point.

The main point of contention is Photon can get expensive, and I think this is the valid reason TNet is so appealing   I agree with today's internet, TCP is much better than it used to be though.

If I'm running on consoles, I don't have a nat punch through issue, but I do have an issue where users might switch off their machines suddenly so it boils down to if I want to use azure or leaseweb to host the relay server or pay Photon to do it. In fact I was surprised and pleased that TNet was so full featured so early on vs say, Photon. TNet is 10x easier as well.

That's my current thoughts about it.

3

TNet 3 Support / Re: How to make some code working on the server side ?

« on: September 02, 2013, 01:39:19 PM »

If you have the .exe on your own server and isHosting player disconnects, then another player will be assigned the new host (and will return true for isHosting) and gameplay will continue without a break.

In your code, all clients will have the same code but the client who is the group leader (who returns isHosting == true) will be doing the NPC ai etc.

4

TNet 3 Support / Re: How to make some code working on the server side ?

« on: September 02, 2013, 11:07:56 AM »

You need to host online, such as amazon EC2, Azure or leaseweb etc for the server if you do not want the authoritative player (isHosting) to close the server.

5

TNet 3 Support / TNet roadmap?

« on: September 02, 2013, 07:17:19 AM »

Hiya,

Clients are wanting certain features and so forth, so we would love to know a rough idea of where TNet would be around December/new year. In particular we are wondering what features you may be adding as we are evaluating TNet (which we bought anyway because it's so cheap) and Photon.

In particular:

- TNet server reliability - does it handle situations where it is flooded with client requests and does not break
- TNet reliable UDP - is this planned?
- TNet forced UDP - don't fall back to TCP?
- Any extra ease of use functionality which would suit twitch gameplay types.
- Any advantages over photon cloud?

I feel currently TNet is ideal for mobile/general slower paced games, turnbased and games which aren't reliant on fast gameplay decisions, and it appears to be really great for those, however with so much realtime shooting and aiming going on, the client wants to know if TNet is the right choice hence request for your future plans since multiplayer takes a while to develop and we don't want to be caught pants down in a couple of months.

Thanks

6

TNet 3 Support / Force TNet to always use UDP?

« on: September 02, 2013, 04:45:35 AM »

Hiya,

Is is possible to force TNet to not fall back to TCP if the first UDP packet fails? If so where do I look? Thanks!

7

TNet 3 Support / 20 packets a second of fixed size vs small size random packets

« on: September 01, 2013, 02:36:32 PM »

Hiya,

Recently I was given the advice that it might actually be better to send 20 packets a second of 512 bytes (or whatever amount - so long as the amount was always constant) as this apparently makes routers in general prioritise the traffic.

Any thoughts about this?

8

TNet 3 Support / Re: TNet does support differrent network ?

« on: September 01, 2013, 02:34:46 PM »

I see! My brother can't get his upnp working either - he enabled it on the router but there's no way any server he hosts works. I'm guesting some routers are just bad.

9

TNet 3 Support / Re: TNet does support differrent network ?

« on: August 31, 2013, 06:54:26 PM »

Well, UPNP never works on all our machines, I guess in the UK it just doesn't work out. Naturally it wouldn't on any mac - but all our pcs fail on it too.

I was thinking if UPNP failed, why not try NAT, it can't hurt to do both I guess.

10

TNet 3 Support / Re: Address already in use - occurs once a remote player times out

« on: August 30, 2013, 06:14:25 PM »

remote player on pc
local player on mac
tnet server running on terminal using -mono to run the exe on a mac (could this be it?)

remote player shows timed out on terminal.
local player in unity stops playing, codes a little then presses play.

I think this just may be a result of running it on a mac under less than ideal conditions so I'm not in too much of a panic. It has happened more than once though, for example one play crashed, and this also triggered it. It has also happened if I paused unity to check something... so it's vaguely to do with a timeout.

Will just add to this thread if I get a better example. 1.80.

11

TNet 3 Support / Address already in use - occurs once a remote player times out

« on: August 30, 2013, 01:27:22 PM »

Once a remote player times out, the server starts getting stuck with Address already in use - and I have to reboot the macbook. Is this a concern?

12

TNet 3 Support / Re: Bought TNet

« on: August 29, 2013, 12:38:27 PM »

Thanks!

I'm thinking of this:

infrequent: position and velocity

instant: delta input (changes in input - which includes the jump button) - hows that sound? So player holding jump wouldn't send any packets but tapping jump would send a byte for the jump. Or holding left wouldn't send any packets but pressing right or not moving would send another.

13

TNet 3 Support / Re: rUDP and why - a quick discussion on avoiding TCP!

« on: August 28, 2013, 06:35:54 AM »

Yep sounds about right, thanks!

14

TNet 3 Support / Re: rUDP and why - a quick discussion on avoiding TCP!

« on: August 27, 2013, 07:22:20 PM »

Note: I haven't actually done any proper testing on this - I suspect it would only start to affect packets over a given size.

15

TNet 3 Support / rUDP and why - a quick discussion on avoiding TCP!

« on: August 27, 2013, 06:20:06 PM »

REF 1: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
REF 2: http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM

Brief:

Basically having TCP and UDP can induce more packet loss than normal with UDP, therefore I need to figure a robust and easy way to do reliable UDP and avoid TCP entirely in order to prevent the occasional TCP packet (these can be a couple of times a second, such as a grapple that MUST be applied or a gun that MUST fire). Rather than pressure Aren to do this (which I consider incredibly impolite - you buy a product with what it says on the tin, you don't pressure the author to change it) - I would like to spark some discussion in how we may do this ourselves for faster TNet games. Likely, many who adopt TNet will stumble across threads like these and wonder what options they might have.

In this case I am considering just having ping and pong. Basically UDP is sent, but buffered. If there is no reply by the time 1.5 x your ping time, then it's safe to probably send it again. What are your thoughts on this matter and do you have any advice? Is this the correct way I should go about it?

Thanks for reading!