Just Tested the windowed mode bug and I reproduced it too while spectating a race (0.6B6), cars appeared as (LAG...), by the way after a while cars appeared again but then the on-track cam bugged for some of the cars (some parts of the Track were missing and the on-track camera stayed focusing on the cars but from one single point of the track , confusing but thats what just happened to me), made it go back to normal by switching to chase camera and waiting for the cars to drive onto a loaded part of the track, after doing it on the bugged cars the on-track camera worked fine again.
Just been on the test server, and near the end of a lap, the screen went black and stuttered in a blank playback mode (sound clip of engine repeating itself).
Screen eventually came back, but there was a text message reading "TIMER BOUNDED".
Replay shows 2 separate periods of lag during time my screen went black.
I see (or imagine I see) a difference when spectating a relatively laggy car:
It seems that with B6 the car is jumping around (a few virtual cm) much more often than with the previous version. It could be the side effect of an improved netcode, making the updates to the car position more frequent because independent - or it could be only in my confused brain.
Could someone else observe and confirm?
Edit: attached replay, watch rim66 car
Apart from that quick connect / disconnect / spectate with no issue, even while uploading stuff to cripple my connection.
I also get "TIMER BOUNDED" when I switch from windowed mode to fullscreen (I do that pretty often). It took about 10 seconds for the screen to display everything again (on B I would time out if it took that long). Is this "TIMER BOUNDED" message supposed to come up?
If you download the MPRs from Cargame.nl it is smooth as usual. I am lagging aswell in your MPR, but not in the MPR from the server. So I think it is you that was lagging while your MPR was 'recorded'.
That is quite a common problem, even on very old versions. It is some problem related to particular players, when spectating them, the track is not shown in some views (onboard and chase iirc). That problem usually solves itself when the "affected" player leaves and rejoins the track (pit/spec) or you (the viewer) reconnect to the server.
No idea if the new LFS increases the problem of whether it was just a coincidence.
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.
I'm thinking about this. I realise that all we see now is everything seems to be fine then someone either loses connection or times out, and that's the first we knew about it, so that's a bit disturbing.
Is that the host message or the local message? The one from the host says "> HOST : TIMER BOUNDED" and the local one is just "TIMER BOUNDED". Which operating system is the host running on and what about your local computer? The reason I ask is that this is the result of a fix for servers running on Wine that sometimes have a problem where the reported time jumps around (Wine bug : elapsed milliseconds reported by the timeGetTime function is affected by Linux system time changes). When this happens you should see the message and hopefully things recover on the guests in a while.
I'm thinking that maybe this timer bounding should only take place on non-graphical hosts. I'm surprised it takes so long to switch to full screen. Are you using a full screen resolution that is different from your desktop resolution? On my computer it's much faster when they are the same. But anyway, there is no benefit in this case of the timer bounding coming into action. The bounding takes place any time that LFS is told that the time step is 6 seconds or more. So if LFS is not given any CPU time for 6 seconds, the bounding will take place. And that is even if there has not been a Wine style timer error.
Anyway, I realise now that 6 second hangs (from LFS's viewpoint) are quite common and don't usually need any timer adjustment action, so I think I should disable that code when LFS is running in graphical mode - or maybe allow up to 30 seconds or so before bounding the timer. But in dedicated hosts (or normal LFS running in dedicated=nogfx mode) it seems like quite a good idea.
Though people who get this on their dedicated host should look at finding a solution. Timer bounding is not really good, it just avoids disconnections due to timeouts. You should really fix your system time adjustment setup or the timeGetTime function.
I see why this is happening. It's a mistake I've made. Let's say player B takes over player A's car. But just after the takeover packet was sent, but in that split second before the takeover actually takes place, player A sent a packet related to that car's state. Now the takeover takes place, then the car state packet arrives from player A, now relating to player B's car. The host thinks this is bad and kicks A.
I'll figure out a solution to that and hopefully release an update today.
I'd like to mention another problem (bug) on single player. I have LOTS of textures for Blackwood. Over 400 MB of them, so loading track takes a while and when race starts after loading track "preloading" takes some time and race already started when I first see track, time is usually at about 5 seconds.
Rather simple and elegant solution would be to leave it as-is and move the connection bars for all guests into SHIFT+F8 network debug.
Reasoning behind it is that screen remains less 'cluttered' for players while they can still observe their own connection quality. It's not of vital importance that they see connection quality of everyone while driving 200 km/h, especially cause it is impossible to tie particular bar to a driver few meters away of you. We do that visually so no change there.
A quick overveiw of the situation is rather necessary however, mostly for admins who watch over us . Simple glance in shift+f8 and then more thorough if the situation calls for it. Players could check it too to see if it is acceptable for them to drive on that particular server.
Also, network debug is sufficiently 'annoying' that most people would turn it off after they asses the situation. Saving host's CPU time and bandwidth (if that's the main reason connection bars got removed - I have no idea only guess ) that way.
Bit off-topic, but more to add to this: maybe later, when there is time and will there could be a more conveniently made connection quality overview. Such as there is no need to manually count bars & guests to tie them. Something in the connection list while network debug is on perhaps (but don't take my word for as i don't have any visual designs capabilities).
O-T 2: currently when a guest on track is lagging there is LAG (seconds) instead of his nickname, informing us of his lag. What about replacing it with: username (seconds). I don't know of any other way to identify who is the person who is lagging but to manually click through the connection list until i get to that person. Most know that when seconds in brackets appear it is lag, that's why i suggested to put username in place of LAG and save some space
I have no problems to report but I would like to see some more information to the user as well concerning network performance.
Its quite weird that displaying FPS is widely accepted but if you want to know if your connection to the server is good you have to ask somebody else 'to watch you'. (with shift-f8). Its rather important, lots of (very bad) crashes occur on the track due to unstable connections.
If we're talking about moving stuff already, I do think it would fit rather well into the nameslist (N) too, so you could easily figure out the player that is lagging. Usually you have to count lagbars, go to the player list, count players then you know who it was. Would cut down workflow quite a bit. (Mock-up attached)
Of course I got no clue how much work is actually involved in doing this, but I do think it would be a better solution then the current lagbars on the bottom left.
If Lag bars etc are being looked at, Would it be a good idea to have the latency that is normally shown above a car in Shift+F8 put into the players list under the Ctrl+Shift option? (ideally so you can see your own latency as well) thereby not having to spectate from tv cam or another car nearby
I have a problem with ping bar in left corner. Look like it always keep the same state. When every car around the track for me have a "lag", bar keep good state and show me that i have good ping. in 0.6b it comes to the red zone and show to me that i am lagging and may dc. it may be caused manually by starting some download that uses all speed of your internet channel. also, even airio says to me that i am lagging but ping bar never have behaviour like it have in 0.6b with same situations.
FIX : Guests were often kicked after another took over their car
Instead of "LAG (seconds)" now "username (seconds)" is displayed
Timer bounding increased to 30 sec for normal LFS (graphic mode)
Timer bounding stays at 6 sec for non-graphical dedicated hosts
AND the lag bar is more useful. It's the other way up from the old one and gives one piece of info : how long since you heard from the host. So it stays there, gets taller and turns red if you aren't getting info from the host.
There is still no info about the other players and no info about whether the host is hearing from you! So it's only telling half the story, but that's better than half the story half of the time.
A version that gives you info about the state of all players and how you look to the host (small lag bars beside user names, maybe ping info, etc) I like the sound of - thanks for the suggestions - but it will require a new info packet sent from the host and another incompatible version. That's ok but it's a longer job. Today's update fixes the serious problem and a minor problem and adds two improvements.
, confusing but thats what just happened to me), made it go back to normal by switching to chase camera and waiting for the cars to drive onto a loaded part of the track, after doing it on the bugged cars the on-track camera worked fine again.
. Simple glance in shift+f8 and then more thorough if the situation calls for it. Players could check it too to see if it is acceptable for them to drive on that particular server.