TNObject SendQuickly Not working & Rapid Fire technique Question

[Voxel]

Hi,

TNObject SendQuickly is not working for me for some reason. Send works fine.

TNManager.canUseUDP shows as true on all clients and gives me a port number as well when I use TNManager.listeningPort.

The syntax I am using is:
tno.SendQuickly("PlayerRapidFireRecieve", Target.AllSaved, true, TNManager.player.id);

The reason I am looking to use SendQuickly is because my script is set to fire a projectile very 0.1 seconds. However because of the delay/timings less projectiles are being spawned at the remote player end. To compensate for this I use a counter to makes sure the right number of projectiles are spawned.

Either way I would like the use SendQuickly as a way of making the actual shoot function more responsive.

Any ideas?

Thanks!

[ArenMook]

I'd advise you to sync the time when you start firing and the time when you stop firing. Way less bandwidth this way, and ends up in the same effect.

Now, in regards to your question... what version of TNet do you use, what is your platform, and where is the server hosted?

Keep in mind, SendQuickly sends via UDP, which means the packets may not arrive at all -- which is quite bad when you expect them to.

P.S. Why do you use "Target.AllSaved"? Your function call gets saved... but why? Only the latest function call gets saved, so if you call it 1000 times, then a new player joins... that player will get 1 "PlayerRapidFireReceive" message.... what for?

[Voxel]

Hmmm all great point Arenmook!

The sync time idea is a good one, and I'll explore that route today.

I have the latest ver (1.7.2.c), Running on Windows 8, and the server is running on the same machine as all the the test clients I run as I do not have access to a second machine. I am also connecting through my public IP address so I can test for lag issues.

I have read up more about UDP and now understand that there is up to a 4% chance of them being lost, and as you rightly point out, that is not ideal for stuff like weapon triggers. To me this makes UDP pretty much pointless. Any examples of when the risk of packet loss outweighs the benefit of speed? Still I guess it would be nice to learn how to use them if not just to strengthen my (weak) understanding of networking

As for Target.AllSaved my thinking is this: AT the moment I use a counting system to know how many projectiles have been launched. Atthe start of the sequence I say the number is 9999 which is more than they could ever fire. When they stop shooting another message is sent to say they have stopped and with the actual number of shoots fired. When a new player joins they are told a player is shooting, so it starts, then when the player stops shooting the newly connected player is told they have stopped and the real number of shoots fired. Sustained bursts for 10s of second can done by the player shooting, so, someone new to the game would not know they were shooting.

Having typed the above, I am wondering if AllSaved only deals with the very last messagesaved. So if there are 10 players all shooting, would it only trigger the shooting for the last person that started shooting, even though in reality, they are all shooting? If so I think I now see the flaw in my thinking.

[ArenMook]

RFCs are saved per-TNObject. This means if you have 10 players, and each of them has their own TNObject, they all get their own saved state.

[Voxel]

Thanks for confirming!