Messages

1

TNet 3 Support / Re: Unity 4.6.2

« on: February 13, 2015, 04:42:41 AM »

I have not taken a look at the TNET code but my guess is that is has to do with:

"Delegate BeginInvoke/EndInvoke will not work though other delegate functions are working well. We will address this in an upcoming patch release."

So next patch of unity it probably works.

2

TNet 3 Support / Re: RFCs looping, freezes TNet stack and Unity

« on: October 20, 2014, 02:58:38 AM »

You should separate the sending of your RFC and the actual action from eachother. A basic rule of thumb would be to never invoke an [RFC] yourself only do it with to.Send.

So something like this:

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

3

TNet 3 Support / Re: Integration with Industrial Software such as LabView and MatLab(Simulink)

« on: June 26, 2014, 03:06:51 AM »

Hi!

Pretty interesting stuff your are doing there, but I don't think TNET will be of any use for you. TNET is a network library to make the communication between different instances of unity games easier. While what you are looking for is TCP/IP communication. This is possible with the System.Net.Sockets namespace. Maybe there is already a .NET library covering the MATLAB communications over TCP/IP in that case you can just plug that dll into unity.

So to conclude, I think TNET is on a higher layer abstracting the network communication between the same game. While you need communications between different applications using TCP/IP which is standard available in Unity.

4

TNet 3 Support / Re: Synchronizing a Team list efficiently

« on: April 23, 2014, 10:46:13 AM »

RFCs are saved per TNObject, so not per class or something like that. So you could fix you problem by creating a TNObject for every player. With an RFC that is something like player.JionTeam(1). I guess this will also solve you second issue.

5

TNet 3 Support / Re: Ghost RFC

« on: April 23, 2014, 04:02:28 AM »

Ok so you suggest working around this issue. I had come up with a solution like this myself, but although in my case it was happening frequently it could also happen less frequent, causing for very hard to track bugs.

6

TNet 3 Support / Re: Ghost RFC

« on: April 21, 2014, 06:41:01 AM »

OK I think I see the misunderstanding now. I think I wasn't clear about two things, the first is the level is loaded by the player, but this message is than of course distributed by the server once it receives this message from the host. So my explanation of the steps should be preceded by:

Host loads lobby level with TNManager.LoadLevel
Server sends load lobbylevel
Server clears saved RFCs
Client1 send RFC
Client1 receives load lobbylevel
Client2 receives load lobbylevel
Server receives RFC
Server distributes RFC
Client2 receives RFC
Client2 store RFC in delayed calls
[just lobby level code going on]
[switch level to game level]
All clients load game level
Client2 creates object with game uid as original ghostRFC sender
Client2 executes the delayed call from the previous level leading to unexpected behaviour

The second is that I talked about clearing RFCs, this is because I looked at the code and this is only for the saved RFCs. Nevertheless the issue would also occur when the RFC is not saved.

I will try to re describe the issue in the way I think it's occuring. It is occurring with level switches. When some of the clients have loaded the new level and some haven't. If a client with the old level sends an RFC for a TNObject in this old level and this message is received by a client that has loaded the new level, then the there is no TNObject with this the same uid, so the RFC is stored in the delayed calls. Then when a TNObject with the same uid is created the call is loaded. This is what I called the "GhostRFC" since some arbitrary call is executed on a new object.

In my case this happens very often, because of the level switching in the same channel and when a level is loaded the chances that a TNObject gets assigned the same uid is pretty large.

7

TNet 3 Support / Re: Ghost RFC

« on: April 19, 2014, 09:04:14 AM »

This is then I use TNManager.LoadLevel on the host. With server I really mean the TNServer.exe not the host.

8

TNet 3 Support / Ghost RFC

« on: April 18, 2014, 08:46:46 AM »

Hi!

I have ran into an issue with TNet. In my game I have 2 network level, one lobby and the actual game. When playing the game you go back and forth from lobby to the game level. Everytime, except for the first time, I load the game level I recieve ghost RFCs. Position updates for position I have not been in that game yet. After some debugging it looks like these are position update from just before quiting the level the previous time. When I run this on my remote VPS (with pretty low latency, around 16-50 ping) this happens everytime.

To make this issue clearer I will write down a sequence of actions that I think are happening that cause this issue.

Server sends load lobbylevel
Server clears saved RFCs
Client1 send RFC
Client1 receives load lobbylevel
Client2 receives load lobbylevel
Server receives RFC
Server distributes RFC
Client2 receives RFC
Client2 store RFC in delayed calls
[just lobby level code going on]
[switch level to game level]
All clients load game level
Client2 creates object with game uid as original ghostRFC sender
Client2 executes the delayed call from the previous level leading to unexpected behaviour

I hope the explanation is clear, otherwise I would gladly clearify the issue. I can work around this issue for now but I think this is something that should be handled by TNet and not by external code.

9

TNet 3 Support / Re: OnChangeHost event

« on: March 02, 2014, 05:11:59 PM »

yes that is what the boolean is for

10

TNet 3 Support / Re: OnNetworkConnect not triggered

« on: March 02, 2014, 05:09:55 PM »

Are you sure your TNManager is already up. Maybe your awake is called before TNManager's awake. Try testing you connect with something like a keypress or something like that. And make sure the TNManager is on a gameobject in your scene.

11

TNet 3 Support / Re: OnChangeHost event

« on: March 02, 2014, 04:59:55 PM »

I had the same issue a week ago: http://www.tasharen.com/forum/index.php?topic=8218.0

TNManager.client.onSetHost

12

TNet 3 Support / Re: TNet on iOS/Android without Unity Pro

« on: March 01, 2014, 09:41:11 AM »

Sounds very interesting.  Has anyone tried it? Does everything work? UDP?

13

TNet 3 Support / Re: DontDestroyOnLoad on TNObject

« on: March 01, 2014, 09:33:31 AM »

You have understood my correctly about creating alot of static TNObjects. Every player has an object for its own data. If I understand you correctly, every change a player make send the whole array to everyone again. Isn't this going to lead to a lot of traffic. I suspect other issues start occuring as well, for example when two players change soon after eachother. So the one array is not updated when the other is sending it. The change of the first one has disappeared.

Maybe I do not understand you correctly or maybe I am overestimating all those problems that might occur.

14

TNet 3 Support / Re: TNet.List IEnumerable

« on: March 01, 2014, 09:23:29 AM »

Ok, a lot has happened here since yesterday.

@ldw-bas: TNet's List already has GetEnumerator() implemented, so it should be already usable in a foreach. I'm not sure what your changes would add.

The IEnumerable implementation allows for the usage of LINQ. LINQ it totally build on IEnumerable and IQueryable. I am not sure if it also solves the "new List() {bla, bla}" issue danfoo showed.

I did google on memory unity ios foreach, but that didn't give any results, but your link indeed explains it and references the same gamasutra article danfoo mentioned, which I also had found during my memory search. But if I understand it correctly the gamasutra article actually says you should just use foreach. The memory leak issue only occurs when using as class instead of a struct for the Enumerator (which is not done by the .NET classes) and if you use the mono compiler. If I understood it correctly it says if come across issues, switch to the free .NET sdk compiler and you are fine.

I do agree with danfoo on the long post, memory leaks do no longer refer to the same phenomenon occuring in c++. Although I don't consider myself old I thought the same about it. For example some memoryleak that is mentioned is when eventlisteners are not unsubscribed. That is just something that you used be aware of but not really a leak or an error in C# since this is expected behaviour in a lot of cases.

I am a still a bit cynical about the GC issues, but I have not created high performance games in unity. Still I think those issues are solved reasonably quick, with profiling, but than again maybe I am underestimating the problem here.

15

TNet 3 Support / Re: TNManager.Create question

« on: March 01, 2014, 08:51:05 AM »

It sounds to me that what you need is CreateEx and RCCs. The function CreateEx allows you to remotely create an object and supply your own parameters to it. More information here: http://www.tasharen.com/forum/index.php?topic=5416.0 .