The online racing simulator
I can only second that. From what I see, that information has just been removed for no apparent reason. How are we supposed to find laggers now? By constantly pressing the tab-key and spec each player for 30 seconds? Sorry, that's definitely a step backwards.
Those bars are certainly not required to be shown everywhere, but at least in the network-debug mode.
Quote from mbutcher :I don't see how this lag bar change is an improvement. You can't see if anyone else is dropping packets any more as far as I can make out.

Will there be changes such that you can find out (from the lag bar) whether someone else is dropping?

Quote from chucknorris :I can only second that. From what I see, that information has just been removed for no apparent reason. How are we supposed to find laggers now? By constantly pressing the tab-key and spec each player for 30 seconds? Sorry, that's definitely a step backwards.
Those bars are certainly not required to be shown everywhere, but at least in the network-debug mode.

Well, today's lag bar must be an improvement over yesterday's one, so I assume you are comparing it with the old system.

The lag bars were not removed because I thought "hmm, let's get rid of the lag bars for no reason". They are gone because the information they described no longer exists. It's a completely different system. In the old system, packets were passed from all guests to all other guests all the time, and the game could not proceed until everyone had all the packets - so you could not pit, leave, join, etc... But in the new system, this simply does not happen any more. You do not receive packets from the other guests any more. So the information on the old lag bars - showing how many "spare packets" are available from each guest - simply does not exist, so could not be displayed any more. The closest thing to it was yesterday's single host lag bar. But when you didn't receive any packets that just sat at zero, so there was no indication of when you might time out. Today's one is the other way up and keeps moving up, so you get more info from it.

You may have missed what I said before, I'm thinking about the information display, I've been reading the suggestions and I've written about that in a recent post. Nowhere have I eliminated the thoughts of implementing a new system to display some other kind of info that is still possible to display - such as how long it has been since the host last received a packet from someone, and what is their average ping time.

Also, you shouldn't really be worrying so much about laggers as you used to. People with poor internet connections do not affect you in most ways they did before. Their poor connection only has one negative effect on you - their car's position will be jerky.
Actually it's "nickname (seconds)" now. It's faster to identify guest in connection list this way so it's better then "username (seconds)". I was concerned about guest lagging off the server then coming back with another nickname (making fast and easy identification impossible) but then i found that lagging off produced a 'Lost connection nickname (username)'. All the info we'll ever need, Thanks

Troy's presentation is good in principle: it solves the main issue about having to manually count bars and guests but it raises two issues. Didn't want to spam-comment until i knew that it's a consideration.
1) It spreads that little bar movement across a wide area. Right side of monitor will be blinking. Seems small but it wont be. Even if it is put into connection menu and not visible all the time it will present a problem with people that want to look connections often or maybe drive with that thing on. Mosquito flying in your peripheral vision sort of feel
If it's made to appear only after shift+f8 is pressed then i would agree, along with 2nd issue being dealt with.
2) It will be very hard to tell who has good or bad connection this way without a detail checking. Bars were all in line before making it easy to distinguish the differences between them. Making these ones go left or right would put them all in line again provided they're close to each other. Maybe i can work up a sketch similar to troy's because it somewhat hard to visualize what i mean. I rather not tho, cause not a single Picasso gene in me

That's all i think, sorry if i go too in-depth too often, making stuff hard to read and/or understand. I do it because i like to be made right the first time. Things believed to be made right but are wrong are hard to change
im not sure if test patch fault but now i get very much fps drops. from 80 to 17 or lower.

this never happen before and i didnt change anything
1) LAG - nickname (sec); good work
link
2) Network debug. She doesn't saw this ping, after finish race. (to this version test patches)
link
When i first time played lfs and clicked on show server list it showed me something about packets (i think big packets dialog) but it is not doing now so it is not problem.

Problem is that i can't connect to my favourite server (TC cruise server). Server always simply refuses my connection. So i installed B7 but i still can't connect and server doesn't want my connection. Other servers are ok.
Quote from Scawen :Well, today's lag bar must be an improvement over yesterday's one, so I assume you are comparing it with the old system.
--snip--

Well yea, I was. I must have missed that part. But you should know that laggers not only caused others game to block certain action but it still affects the movements. Racing (and whatever we do on TC ) is a "full-contact"-sport, and if there is a lagger in the field, its most likely him to cause trouble.

With the old system, admins were able to sort these people out. You may not believe me, but it was absolutely possible to tell whether some person has a slow internet connection, suffers from packet loss, is downloading, uploading, Torrenting, using a WiFi connection, or is Alt-Tabbing in Windows. If you look at those bars for 10 years, you develop some new kind of sense. Other games have technical counter-measures to prevent laggers spoiling the gameplay for others, but on LFS, we arranged with the possibilities and did it manually.

Nevertheless, I see the new system has some benefit over the old one, but please keep in mind that we, sooner or later, need something to handle that situation. Whatever that may be. You know the system the best, so I trust in you doing the right decision.

Thanks
Following Troy's suggestion, what about displaying the lag information numerically in the connections list (N) (see attachment)?
Perhaps less eye candy than Troy's suggestion but more accurate and you can quickly locate the laggers. It would also render lagbars obsolete.

(By the way, connections and disconnections are clearly smoother since 0.6B5 for me.)
Attached images
display lag information.jpg
Well, those bars, compared to the numbers, had the advantage to display whether the packets were received rhythmically, if that's the right word.

On a second thought, I think its possible to "simulate" them. I mean, the game does still receive packets from all clients as it needs them to display the cars. It could simply take the timestamp of the last received position packet of each client and display that as a bar.
A full bar means 0ms since last received packet, and an empty bar means 1000ms. Et voila.
Quote from NoNder :Problem is that i can't connect to my favourite server (TC cruise server). Server always simply refuses my connection.

Does it say the exact words "Host refused connection" ? Because if so that means you are banned from that server.

Quote from chucknorris :Nevertheless, I see the new system has some benefit over the old one, but please keep in mind that we, sooner or later, need something to handle that situation.

My plan is to let this run through my head, though I will not work hard this weekend. Then do something next week with a new packet of info from the host.

The relevant info that I can think of at the moment is, for each connection :

1) How long since the host heard from that connection. Host normallly gets a packet from each connection every half a second, for timer adjustment purposes, just as often as connections get one from the host. This data is an increasing number so it looks like a time bar, something like the B7 bar but one for each player. This shows if a player is likely to time out. I suppose a rising bar indicates packet loss or lack of CPU time (freezing).

2) Average ping. This is just a number, the approximate round trip milliseconds between host and guest over a recent time period. This will obviously be higher for people who are far away and it will be more variable for people with stuttering connections.

This data will not move so smoothly as the B7 bar, because it is info as seen from the host and so will only be updated each time you get the info from the host. I'm imagining that would be every few seconds or so.
Quote from Scawen :I'd like to know how to reproduce this. Which computer is doing the time jumping and which computer is losing the sound? For example, do you have a remote computer on Wine whose time is jumping around and you are losing sound on your local Windows PC that is connected to it? It is forward or backward jumps that make the sound disappear? Or is the time jumping on your local computer? Any way to reproduce this reliably would be very helpful.

It turns out that this is probably another bug in WINE because I can reproduce it even with a patched WINE where sudden jumps of time returned by timeGetTime() should not be a possibility.

However I found a bit more worrying behavior regarding time jumps. When such a jump occurs on a client's machine during online game, LFS appears to be frozen from the client's point of view for quite a while. From server's perspective the client's looks like it's lagging. When LFS copes with the jump, player's car is "released" in a more or less unpredictable state which could cause all sorts of accidents. The difference between this and a classic network lag is that in this case player has no control over his car, so the chances of him "respawning" on a very unfortunate place are much higher.
I realize that odds of this happening on Windows machines are rather remote, but perhaps the client should notify the server when it detects a time jump, giving the server a chance to spectate the client or something?
Attached files
BL1_race_5L_1R_0F.mpr - 43.5 KB - 568 views
Quote from NoNder :When i first time played lfs and clicked on show server list it showed me something about packets (i think big packets dialog) but it is not doing now so it is not problem.

Problem is that i can't connect to my favourite server (TC cruise server). Server always simply refuses my connection. So i installed B7 but i still can't connect and server doesn't want my connection. Other servers are ok.

You have a 3 day ban on TC that ends on the 24th.
http://urs.city-driving.co.uk/banlist.php

Anyway, I've just installed the B7 patch and noticed that my FPS has reduced on multiplayer. Same for B6. I used to get 20-40fps (with NightMod, since normal LFS doesn't like my computer) and now I'm getting 13-17. Apart from that, the reduced connect time is a great improvement. Good job.

Edit: Discovered a very resource intensive program decided to hide in the background. Closed it and LFS is running like it used to.
Seem to have had a weird error in the test patch, only happened once so far as i can tell when the server was at 19 connections 9 of the connections where dropped due to OOS

can see the full reason in the picture:

http://puu.sh/17NAw

insim didnt even recognize it as an OOS tho even tho i have the call backs in place for it.

If you can find a solution to this would be great thanks
Bugs I've had:
Game crashes when ending race (Singleplayer)
Game crashes when changing map (Singleplayer)

Had these happen just once.
Providing crash details (like crash addresses) helps.
Quote from Beaver08 :Seem to have had a weird error in the test patch, only happened once so far as i can tell when the server was at 19 connections 9 of the connections where dropped due to OOShttp://puu.sh/17NAw

I think it's possible this may be caused by the different versions that are allowed to connect at the moment. For example it may be that all the people on a different version from your server were the ones who got kicked. Everyone should use B7.

Quote from hazaky :Bugs I've had:
Game crashes when ending race (Singleplayer)
Game crashes when changing map (Singleplayer)

Had these happen just once.

As cargame said, crashes can often be tracked down very easily if you get the crash address. Windows provides the address or offset when a program crashes. If the crash is in the LFS module, it can lead me to the line of code where the crash occurred, and hopefully the cause (but not always). You normally need to click "see more information" or something like that in the crash report dialog, depending on your version of Windows.
Scawen, Where will I can see on error log in Windows 7?(86 bit)
I have am lag display! The display off on 1-2 sec and off module from this Nvidia, but then restores its work. So was in 0.6B version LFS.
Display - LG T711B
Video card - GeForce Nvidia GTS 250
Video card driver - last version 8.17.13.142
Like I said with my link, it's 306.23 now and WHQL certified. You have old drivers.

I'm afraid it's your system anyway. 0.6B has no known video issues.

0.6B7 gets reported as having lower FPS though (also in chat online on the servers, not every posts here). Haven't tested it myself yet.. Maybe later. My new laptop is too high end to detect the differences without actually benchmarking it.
Quote from cargame.nl :Like I said with my link, it's 306.23 now and WHQL certified. You have old drivers.

I'm afraid it's your system anyway. 0.6B has no known video issues.

0.6B7 gets reported as having lower FPS though (also in chat online on the servers, not every posts here). Haven't tested it myself yet.. Maybe later. My new laptop is too high end to detect the differences without actually benchmarking it.

2 min after it was the same
Quote from Beaver08 :Seem to have had a weird error in the test patch, only happened once so far as i can tell when the server was at 19 connections 9 of the connections where dropped due to OOS

I've looked into this a bit more, trying to make sure it wasn't a bad bug. In our logs I found 9 people getting OOS at the same time from your server yesterday early evening, and they all had a different version from the server. The log doesn't say which version they were, but it this does suggest the B6 -> B7 fixes are to blame as they were not really compatible. This Out Of Sync is most likely to happen when one player takes over another's car. If that happened just before the multiple kick event then that is basically case solved, and not a problem. Test patch users and hosts really must use the latest version!

Quote from cargame.nl :0.6B7 gets reported as having lower FPS though (also in chat online on the servers, not every posts here).

This is quite a common thing when there is a new patch, people reporting lower frame rates, even when absolutely nothing has changed that could affect it.

I normally have to disregard that information, unless comparative tests are done between the old and new versions. Some people just say "I've lost 10 fps" or "I've lost 300 fps" without actually going back to the old version and testing it again, in exactly the same reproducable situation.

Nothing has changed in the graphics or physics code. The packet exchange code is lighter and that saves a little CPU time but I'm sure much too little to measure any frame rate increase.
Quote from Scawen :I've looked into this a bit more, trying to make sure it wasn't a bad bug. In our logs I found 9 people getting OOS at the same time from your server yesterday early evening, and they all had a different version from the server. The log doesn't say which version they were, but it this does suggest the B6 -> B7 fixes are to blame as they were not really compatible. This Out Of Sync is most likely to happen when one player takes over another's car. If that happened just before the multiple kick event then that is basically case solved, and not a problem. Test patch users and hosts really must use the latest version!

This is quite a common thing when there is a new patch, people reporting lower frame rates, even when absolutely nothing has changed that could affect it.

I normally have to disregard that information, unless comparative tests are done between the old and new versions. Some people just say "I've lost 10 fps" or "I've lost 300 fps" without actually going back to the old version and testing it again, in exactly the same reproducable situation.

Nothing has changed in the graphics or physics code. The packet exchange code is lighter and that saves a little CPU time but I'm sure much too little to measure any frame rate increase.

ok well thanks for the reply, i can tell you that 1 person had pitted before the oos happened but it was missed out in the screen shot i will try bring up the logs for it, but i would also assume it is the B6 -> B7 patch as a few people are still running B6
Well, my fps not only have not gone down, but seems a lot faster and stable now. Maybe it's my impression and it is the same with 0.6B, but yesterday at a full xfg/xrg grid I had playable-to-perfect fps with a pretty old pc (athlon xp 2000 '02, 1GB DDR ram, geforce fx5700 '03).
Scawen, in case you accidentally missed it, check out post #59. Might be a cheap alternative for those lag-bars.
This thread is closed

FGED GREDG RDFGDR GSFDG