TNAutoSync issues dependent on external ip?

[gg67]

I'm working on a university network and depending on whether I'm on the school's wifi or a specific Ethernet port (different ports sometimes give me different external ips), TNAutoSync either works or doesn't work. What networking concept is TNAutoSync dependent on? Custom RFC calls seem to work fine. Sorry I don't have more info.

[ArenMook]

Do you have it marked as not important? If so, sync is done via UDP, which may or may not go through. Although TNet is supposed to detect if UDP is not functional. If you set it to "important", it will go via TCP, which is guaranteed to be delivered properly.

[gg67]

That did the trick. What is TNet supposed to do if UDP is found to be nonfunctional?

[ArenMook]

TNet is supposed to just always use TCP in that case. There may be edge cases where the first packet goes through, but further packets do not, causing TNet to be stuck in the state where it believes that UDP is functional when in fact it is not.

I'll need to add some periodic sync logic in there that will disable UDP if future packets fail to arrive.

[gg67]

Doesn't data like player position and voice chat usually send over UDP? I'm currently using TCP for everything because of the problem mentioned above and I'm wondering of it's causing a bigger latency than necessary.

Ps. I'm sending player position 10 times/sec.

Thanks

[ArenMook]

Frequent updates where each new state overwrites the previous should ideally go through UDP, yes. I'll do some investigations in the near future to see what may cause UDP traffic to stop and how to detect it.