I'm not sure if it's strictly speaking a bug, but it's certainly unintended and/or unexpected behaviour, which is preventing at least two people from playing online.
I'll summarise the issue here:
When the client enables TCP mode for position updates, the positions of other cars are received over TCP as expected. However the client still sends its own position packets over UDP. This means that if there are UDP transmission problems, while the player can connect and stay connected to a server, his/her position packets never reach the server.
I've been able to confirm this issue myself when my iffy router occasionally decides to drop UDP for a few minutes.
I'm told that in previous versions, position packets were correctly sent both ways over TCP when in TCP mode.
In fact, the position packets have never been sent to the host using TCP. There is no code in LFS to support that. It has been assumed that the UDP problem is a problem at the receiving end, and a host that cannot receive UDP is considered useless.
The host must receive UDP packets from a connecting guest as part of the connection process, or the connection will not be allowed in the first place.
I've always thought the UDP problem is a problem with routers that are failing to send UDP packets back to the guest, maybe the router is forgetting the ephemeral port or something like that. But the host receives UDP on a well defined port where the user (hoster) has set up forwarding to a specific computer, so the router always knows the destination and so it's less likely that a host's UDP receive could break down.
I am surprised to hear about ISP's blocking / dropping UDP packets. My first thought is, don't use that kind of ISP. That's why I'm using Zen, it costs a bit more than BT, Virgin, and so on but instead of an awful service, I believe I know where I stand. But this is my job so I can afford a couple more pounds a month. Though on the other hand I think it ends up cheaper for me because the phone service I've got from them doesn't have a "connection charge" and rounding up to the minute. It's just per second billing. They have a bandwidth limit, rather than this "unlimited bandwidth... note : fair usage policy applies" nonsense. I believe they are an honest business, not one that tries to rip you off at every turn.
So maybe if your ISP has a problem, then to fix the problem you must change ISP.
About the skin problem :
I couldn't find any reason for glitches or slowdowns in the specific case where a skin is not available at LFS World. I can only think of the problem of searching for a skin on your own hard drive when a player exits the pits, if you have many thousands of skins, maybe the file search would take a good fraction of a second, or maybe more in some cases. But that would not be any worse if a skin is unavailable at LFS World.
Anyway, I agree with the thought that it is quite annoying when people insist on joining with a skin they have not uploaded to LFS World. There is no point in using a skin if no-one else can see it. I've taken a couple of days' break from the track editor functions I've been working on, to implement a host-side check to make sure your skin exists. This feature spectates you immediately if you join with an unavailable skin.
Would it not be less intrusive to fall back to a white skin, instead of forcing a spectate? Sounds a bit extreme, to be honest. Not having a skin uploaded isn't that big a deal. Or did I miss the point
I know this is completely retarded question, but what effects does it to change TCP to UDP on the connection list?
I did a brief search on google to find out what it does, but I am kind of confused how it will affect LFS..if any?
Edit:
Scawen, would it be possible to make such that the game would chose one of the random colors instead of just plain white when the skin is not found?
Or maybe one of the skins that follow the game?
I would LOVE not having all those damned white cars
In deed,that's a bit harsh - if someone can't be bothered to upload his skin,it's his problem,others just see him white as usual. Or create a default_b skin with a text "I'm too lazy to upload my skin" on it,which loads for others in case the skin isn't on lfsw...
I don't see anything extreme or harsh in it. No harm is done at all.
You join, mistakenly, with a skin you forgot to upload. You get the message "Your car's skin was not found at www.lfsworld.net" as before.
But instead of carrying on with that, and getting that same message again each time someone connects, you are simply spectated, which conveniently allows you to go back to the pits and select a skin which has already been uploaded.
UDP is on by default. If you have problems seeing other cars (missing a lot of position packets) you can try TCP to see if it helps. Then the host sends car position packets using TCP. It's not really the right choice of protocol for car position packets. Delayed packets are re-sent (this error correction is the purpose of TCP) but really for car position packets, it's better to forget about the missing one and just get the next one. So if there are no problems with your connection, UDP is the better choice.
Thanks for that answer, just two more fast before I'll crawl back under the rock
1: Se above, about the skin(s) - possible (the one question about using LFSs skins intead of white)?
2: If I struggle with DCs, then TCP would be best choise? My problem is that every 10 minutes or so I get a 10-15 second net "lock". This is due to some router problem I have not yet discovered why, but never more than 15 seconds it seems. 50% of the times it goes ok, but other times I get back after the 15 seconds - see all the cars and everything is fine, but I still lose connection to server some seconds later. It seems as it has problems connecting to the server again.
Again, I should try TCP here?
Well that sounds quite difficult and I think it's really ok to use the existing web system.
Besides, this is just a quick update I can do for hosts to install if they wish. There is no new patch coming out with new in-game features. I have editor functions and tyre physics to work on.
1) I really can't see a problem with the system I'm coding. A player who joins by mistake with a skin that he forgot to upload is immediately spectated with a simple message. It's not rude, harsh or extreme. So he can choose an appropriate skin to join with, and will appear the same on his computer and everyone else's.
2) No, if you use TCP for position packets, you are more likely to be disconnected from the host. The "game packets" that keep you in sync always use TCP. If you flood that system with position packets, and you have a bad connection, you may end up failing to maintain the game connection. The normal UDP packets can be lost without affecting your connection to the host.
Thank you so much! I am an total idiot, I see now that my game is on "TCP" on connection list. If I change to UDP I take it as I will have a bigger chance to be able to survive that lag
And about the spec-if-no-skin, that is something you are working on in a future patch yes? - Edit, ah just a host update nice!
The spectate feature when not having a skin uploaded might be good just for the sake of having everyone with a proper skin online, I understand that.
But I can imagine some demo teams using their own skins which they share with each team member, so only they can see them, and possibly use them to be shown in some team screenshots or videos. Or people who just like to drive with their own skin and don’t want it to be public (it may sound strange but there may be some people doing this).
There is another possible reason for ISP's dropping/blocking UDP, and that's for comercial reasons. VoIP is in direct competition with telephony, RTP video streaming etc. are now becoming "premium" services, and Torrents are a grey area, so certainly count as don't time critical. Perhaps gaming is considered low priority for mainstream internet access, and falls into the premium category alongside video? Overall you make some fair points, and hosters need to pay particular attention to their UDP service.
I've been reading that the standard speed and ping tests are not a good indicator of UDP throughput as they rely mainly on TCP. I'm not quite sure how this can be tested for properly, but RTP (real time protocol) jitter is probably a more worthwhile metric.
It is a strange one, and still has me scratching my head. I've investigated disk fragmentation, sound drivers/codecs (in case it was the "beep" that was the problem) and installation location. I'm now fairly confident that it must be an external agent (antivirus?) that is to blame. I'm going to set an exception for the skins folders and see what happens.
Thank you for taking the time to look into this. It was posted in the bugs area as it seemed to one of those issues that we've become accustomed to. Given the number of confirmations from those that I consider veterans only reinforced this thought.
For those affected by the stutter, it probably is a big deal. Any rhythm that gets built, is disturbed by this problem. A 500ms micro lag is enough to cause a miss-judged braking point or steering input. Without the stutter, the messages about missing skins can be distracting to some, or they simply tune out the messages altogether and possibly miss the important messages. Without getting too complex in vetting skins and replacements, getting spectated is a good compromise in my opinion.
Sounds interesting, and I can't wait to see this new feature although I fear an influx of "I want it now/when is it done" responses. Keep up the good work, and when it's done it's done is all I personally expect.
I'm affected by it, and it annoys me to no end that skin downloading and skin loading happens while I'm driving, and it isn't a 500ms stutter I experience either. Anything from nothing to two 1 second stutters, which is incredibly dangerous while near any other cars. What I would like to see is:
- Skins are not downloaded or applied when I'm in an active session (ongoing race, quali) unless my car is stationary. Afaik skins aren't applied while racing, but they are downloaded and that causes stutters.
- Host detects skin is not uploaded -> tells other clients car is using default skin / no skin, just colour -> owner of skin is told "skin not found". This is far, far less intrusive than a forced-spectate-nanny-state approach.
And no, I'm not going to manually turn "download skins" on and off between races.
What happens if LFSworld's skins feature is down (iirc something like that happened when the temp master server was up)? Is no one allowed to join the track?
Anything above 100ms is enough to cause a problem in simulators it's said.
I haven't been aware of this, but it may be something I've also filtered out. Pre and post race downloading sounds a good idea though.
I think the spectate option is possibly the most expedient. I tend to race privately, and sometimes forget to remove my "not for public use yet" skins when going online. If I got spectated immediately, then all I need to do is change/remove skin in the pits. I really can't see this being too overbearing, and it means the other racers that this affects won't have to suffer.
Don't "survive" but fix the problem permanently. You are just behaving like the rest now, first they need to get sentenced before something structural happens. Endangering races for everybody else.
I'm looking forward on the moment that 'ping' information is included @InSim system. But... Going to take a while I'm afraid.
And your allways as understanding as allways
If I had a choise I would of course do it, what you take me for? Stop beliving everyone is an idiot :/
I am on a sharenet with no possible way to do changes to the network. Even mobile network is not possible here so I am out of options.
Oh and yes, I was looking into the possibility to have an own line, turns out not one single ISP provider can provide anything to me - therfor I have to use the network which is not the best.
So yeah, call me an idiot for that, I am used to hear that. Usually I do not care about such comments, but Iv had enough of your sarcastic tone and allways speaking to me as I am a idiot.
Scawen, you said there's no point in using a skin if no one else can see it. I think there is. Even though i might not care to upload a skin, and let others see it, i might benefit from watching my car with it.
I've driven a lot of skins that aren't uploaded, just because i like them on my car, even if no one else sees them. Perhaps a better solution would just be making others completely unnafected by the inexistance of one's skin in LFSWorld. So if someone joins with a skin that isn't on LFSWorld i don't get any message or am affected in any way.
Well, I came up against "traffic management" when I was with Plusnet. Their service started out excellent, but (popularity?) went downhill after they tweaked their traffic management settings.
However, all recognised gaming packets were given high priority - the bandwidth used is generally tiny and gamers who can't play their favourite games are highly prone to leaving for another ISP (as I did).
They struggled for several weeks to find a way to recognise the LFS packets sequences but ultimately failed to find a reliably recognisable signature. Some times the game would work OK, sometimes stupid lag + disconnects. Thus I ceased to be a Plusnet customer...
But in any case, UDP packets are definitely the only way to go for ephemeral data like position updates. (I can't now recall whether TCP or UDP was more troublesome in my case.)
Missing skins: my vote would be with Scawen - spectate 'em
I guess Rifo's ISP must be treating the new networking code differently to before or something - something, somewhere seems to have changed as a result of the new version to prevent him from sending position packets.
He's tried disabling all firewalls and setting DMZ on the router, so it seems the problem is definitely at the ISP end.
For me, at least, I know that the problem is my router.
Is that still the case while the temporary master/web server is running? (I can't remember what the exact error message was while the temporary servers were running a few weeks ago)
