In my experience, it is usually the client's load times that cause the disconnects on track change, although IIRC occasionally people with very bad connections do get taken out by others who are loading slowly.

Quote from misiek08 :

It's why I said he should do it.

cargame.nl meant that there is literally no way of detecting whether someone has rolled their car, it's impossible to program - InSim doesn't give that kind of information.

Information about roll & pitch is only available through OutSim, which is client side only.

Quote from MadCatX :

This also didn't trigger any disconnections so it looks like the problem is only if the host and InSim app run on different machines?

Yeah, that's what I figured - I doubt the OS will be a significant factor. It's probably down to local connections usually having vastly lower latency, so the buffer is being emptied much faster. So fast, it never actually gets full. It also means that internet clients will be susceptible to problems with much fewer buttons than on a LAN.

Using MadCat's ButtonBomb, I got a client disconnect every time I've tried so far, except for a local server + client + InSim. Considering the amount of data being sent (over 54KB of button text alone) I'm not really surprised.

Client & InSim: Windows 7 64bit
Servers tested:
Windows Vista 32bit (LAN) - lost connection
Wine on Ubuntu 10.04 (LAN) - lost connection
Windows 7 64bit (local) - connection OK

Server log:

Interestingly, when testing with localhost, the buttons didn't get displayed on screen if the client was already on the server when the InSim connected. When the client joined with InSim already running, the buttons displayed fine, but the text in the chat history went missing - probably to do with the many overlaid buttons.
On the LAN servers, the buttons caused a disconnect whichever connected first.



I'll try do some more tests later with my own test app, hopefully with some more OS & network combinations as well as different numbers of buttons etc.


BTW MadCatX, the "Packet count" option in the ButtonBomb is never used in your code, so it sends out 238 buttons every time.

Quote from MadCatX :

If this is the case, wouldn't installing LFS into "Program Files" lead to malfunctioning installation anyway unless LFS was run with admin rights?

IIRC, that's correct and is the reason why LFS defaults to a non-protected location.

Just a thought, it's possible that your PSU can't quite cut it. It's an older, cheaper design (shown by the max currents - noone's ever needed 300W of 3.3 & 5V, those high currents are simply a way of making it seem more powerful than it really is).

The manual isn't clear if the PCIe power connectors are on the same 12V rail or not (another sign of the quality level of the PSU). If they're on the same rail, then it's very possible that the GPU is overloading that rail.

Download some software that will display the voltages (eg speedfan) and see if they drop significantly when the GPU is under load. This might also explain why it started behaving when Fraps was running - Fraps caps the framerate, potentially reducing the GPU workload.


Something else to note regarding the SSD partitions - 20GB is not enough for a 64bit windows installation. My c:\windows\ directory alone is 30GB.

Quote from chucknorris :

If a player renames himself while somebody is connecting, LFS used to block the OK-key with a message like "please wait someone is connecting". But, he can still press Esc. The GUI closes, he appears renamed to himself but not to anyone else.

To expand on this, IIRC the player does get renamed in some places, but not all, causing the name shown in the player list/chat/over car to be different. This discrepancy can be detected in the InSim packets, which is why several InSim applications try to deal with the problem, usually by kicking the player.

Quote from cargame.nl :

In the current situation I cant customize that for everyone because it leads to 32 x (32x4)= 4096 TCP packets (rougly) .. As I understand now it only leads to 32 TCP packets... About the same I think as I'm doing now by announcing just a global array of data for everyone (or maybe even less then what I currently transmit with this 'buttonforeveryone' InSim option)

If I understand you (correct me if I'm wrong) each client - assuming 32 clients - sees 32 rows of 4 buttons before a race start?
If so, the server still sends all 4096 packets to clients even if you're sending the (32x4) buttons once to the global UCID=255, as the server still has to send separately to each client - even if the different clients are receiving the same button ID+Content.
Each single button sent to UCID=255 actually sends 32 packets total (or whatever the current number of connections - could be up to 47).

If you were to make each of those 4096 buttons unique, there would only be extra packets sent InSim -> Server, but the same number Server -> Client.

Example:
(32x4) buttons sent to UCID=255
128 packets InSim -> Server
128 packets Server -> each Client
4096 packets Server -> Clients in total.

(32x4) buttons sent to each client in turn
4096 packets InSim -> Server
4096 packets Server -> Clients in total.

Assuming the InSim is local to the server, the number of packets InSim <-> Server should be a lot less sensitive than Server <-> Client as latency is near zero, so AFAIK it shouldn't matter much if you're sending 128 or 4096 packets locally.


The above is the case in the current 0.6B version, of course the new patch could vastly reduce the number of packets in all cases - except a single button (global or unique) sent to all clients, which would still be 1 packet per client.


tl;dr
In the current version, it doesn't matter whether you're sending a global or unique button to all clients, the server still sends out the same number of packets:
Total packets = buttons per client * number of clients

Quote from rickk2010 :

To answer Scawen, I believe I initially installed it in the default C:\LFS. It is now installed in C:\Documents and Settings\"my user name"\LFS

Will this cause any issues if I find the need to unistall?

That should be fine, as it would only delete the ...\LFS folder.


If anyone's not sure if the location they installed LFS is safe from deletion or not, just untick the "Remove Live for Speed folder" box in the uninstaller and it won't delete anything other than shortcuts and file associations.
You can then manually delete whatever LFS files you need to.

My skins_x/ folder alone is nearly 3.5GB. If I'd had high resolution skin downloads on, skins_y/ could be 4 times that size.
Then there's skins/, high resolution modified textures, autosaved replays etc.

The amount of space a long running LFS install uses can easily mount up.

I have LFS on a 1TB data drive, so I don't really care if it gets big after a while (I do purge mprs occasionally though)
However, if I uninstall a program I don't expect it to be taking up any significant disk space at all - that's usually the only reason why I'd uninstall something in the first place. And by significant space I mean no more than a few MBs for user settings.

Last edited by Degats, Mon, 15 Oct 2012 23:46.

Quote from edge3147 :

Couldn't you just have the uninstaller remove only the files the installer originally installed I.E. make a list of all the files LFS uses and have the uninstaller remove only those filenames?

AFAIK it can already do that, but LFS generates so many files (including many large ones like skins, replays etc) that the uninstaller won't know about but you may not want taking up space, which is why the 'delete everything' option is there.

Quote from Scawen :

Maybe with these four possibilities and subsequent actions, there is no need for special cases such as Program Files / Windows / Desktop, if "\LFS" would be forcibly appended to non-empty, non-LFS folders.

That's probably the best way to do it, as you're never going to be able to include all the possible special cases because they could be named pretty much anything (symlinks can be a very good way of getting yourself into trouble)

I'd hazard a guess that most people who don't read what the uninstaller says it's about to do won't have read the readme or the wiki.

It's not uncommon for an application to delete the folder it was installed to, although most that do (including LFS) ask you first.

If the user doesn't click through the installer and goes out of their way to choose a non-default install location, doesn't notice that it's being installed to the root of Program Files, then doesn't bother reading what the uninstaller says it's going to do - even though there's a check box which is always a warning that it's about to do something you might not want it to - then quite frankly it is user error if the directory gets hosed.


Now, here's a real example of programmer error:
The uninstaller for Test Drive Unlimited deletes every file (but thankfully not folder) it has system permissions for in the root of C:\. One of those files is boot.ini, without which, many windows installations can't boot, rendering the computer unusable.
The really sad thing? They knew about this problem in the Beta, didn't fix it for release and didn't tell anyone about it.

I've had something similar sometimes (in 0.6B) when my router forgets what UDP is for a while.
I press ctrl+t to switch to TCP position packets, which makes it so I can see other players. InSim then knows where I am, but (some?) other players still can't see my car.

This could be similar to what Chuck described above, as I've seen this happen sometimes with others: somehow the timing to a player goes out of sync, which causes LFS to show lag when the packets actually arrive on time or impossibly low lag (eg 0.01 between Europe and Australia). What's really strange is that sometimes the amount it's out of sync drifts, causing the reported latency to slowly increase past 0.5 and eventually drop back down to 0.00.
No idea if this is still possible in the test patch though.

Just wondering whether there was supposed to have been a newsletter email sent out regarding this, as I didn't get one?

If not, I guess it would be a good idea to send out an email so that the people who don't frequent the website/forum can get advance warning.

Quote from cargame.nl :

I'm not the one with a Youtube movie calling it "3D", do I? Only thing I said is that I've already seen exactly this stuff on a cruise server.

He's not just scaling proportionally to distance though, he's also doing horizontal scaling based on the relative plane angle to fake the impression of looking at it from the side.

TC does have buttons that are scaled based on distance (easy) and others that physically track the location/position of other cars (not particularly complex trig).
I don't know if any other cruise servers have done anything similar or taken it further. AFAIK, one or two race InSim programs have implemented buttons that track a specific point on the track, but no scaling.

What MadCatX is doing (so far) is a further step that's a little more complex still that gives a bit more of an impression of '3D'.

Quote from Scawen :

...Do tell me though if it doesn't really seem needed. I know chucknorris feels it is important, though I'm still convinced it is less important now than it was before this multiplayer update.

It is indeed less important as far as checking the overall server health is concerned.
However, IMO it is still very important to be able to easily monitor actual latency of individual players somehow, especially when there is close quarters racing going on as a laggy (although I suppose jitter is just as important) player can easily cause havoc.
It's quite surprising how much useful connection info the dancing of the old lag bars could show to the experienced eye.

Quote from Scawen :

Which operating system is that? I think you should take a look at the cause of that timer bounding...

The UI looks like Win 7/Server 2008 R2 (NT6.1)

Quote from DarkKostas :

@struct CompCar
byte Info; // flags and other info - see below

#define CCI_LAG 32 // this car is lagging (missing or delayed position packets)

Not sure when exactly this is sent, but it can be useful.

From my tests, It's sent whenever a position packet from the player arrives so late (or not at all) that the car is made invisible and the "lag (0.00s)" thing shows in place of the player name above the car.
Every MCI packet that's sent while the player is in that invisible/lag state (or has been since the last MCI) has the CCI_LAG bit set.

Why would it be necessary to use the same folder/lfs.exe for all those servers? I guess it could be convenient like that, but lfs dedi takes up hardly any disk space, so having one folder/lfs.exe per server or ban list shouldn't cause any problems.

I'm not saying it's a bad idea to have it as an option in the config, but it should be an easy problem to solve without the config option if you need separate ban lists.

Quote from Zac86 :

how do I calculate my % off the WR times?

Your time in seconds ÷ WR time in seconds × 100

Quote from F1 mainiac :

who cares what is it in the FOM TV Coverage ?

Pirelli, Formula One Management and the 500+million people who watch their coverage I guess.

I made this for anyone who's interested, not just for you, so I did it in the most logical order.

I don't see why it's so vital to be in that specific order?

The order is the same as on the official FOM TV coverage, I figured that would make sense to most people.

Something quick I knocked up:



Cromo_Plain: Blank
Cromo: Supersoft
Torro: Soft
Michelin: Medium
Evostar: Hard
Bridgestone: Inter
Avon: Wet

The Pirelli logo follows the curve of the tyre, because it's probably not possible to make it straight like the originals :/

PROBLEM: Master ban by LFS world.

AFAIK, the ban only "counts" as far as the master server ban goes if the user is actively banned while actually connected to the server. If the user is already in the server's ban list when they try to connect, then it's not counted. This would explain why there are relatively few global bans because of this - multiple connections to a server where you're already banned don't increase your tally. It's presumably also protection to stop some random server repeatedly banning and unbanning a user to get them LFSW banned while they're not even on the server.

You'd only be LFSW banned if:
a) you're stupid enough to do something to get banned on x different servers
b) a malicious server bans and unbans you multiple times and you're stupid enough to keep connecting only to get banned again
c) you're testing a banning system on your own server

SOLUTION:
If that's correct, you could avoid the master server counter entirely by kicking the player on connect, then issuing the /ban command as soon as the user has fully disconnected. That way, the next time the user tries to connect, they're already on the ban list so it won't count towards an LFSW ban.



Edit:

I also have a suggestion that I think would make this useful to a lot more servers.

Ideally, as well as only subscribing to bans made by admins you trust, you'd be able to subscribe to specific pre-defined ban reasons. Specific rules would be referenced by ID within the system, so it wouldn't cause significant network overhead.

Pros: Different servers have different rules - a destruction derby type server probably isn't going to mind if people who've been banned for wrecking on a race server join theirs; similarly a race server admin probably isn't going to care about people who've been banned for breaking many of the obscure, weird and wonderful rules that cruise servers have. I'd assume that most server admins, regardless of the type of server, would want to subscribe to bans for being abusive to other players etc.

Cons: It makes the system more complicated and less automated, particularly when it comes to adding bans to the system in the first place.


This isn't really a necessary feature and can probably be added in a later version if enough people want it, but I think it would help the popularity of the system.

Last edited by Degats, Sat, 25 Aug 2012 00:02.

Quote from cargame.nl :

Would be nice if the server logging is a little bit altered also, with the IP address mentioned in the drivername connected (lfsname) announcement. Currently its a little messy to keep track what IP address belongs to who. Especially on busy servers.

Therefore I am now the only one which can block IP addresses, while, if the log is a little bit more structured I could make a web interface for other admins.

After looking into this a few days ago, it turns out it's actually quite simple for a program to parse the log file and reliably* link IP addresses to usernames. I believe Airio already does something like this and it could fairly easily be integrated into an InSim app/cron job/whatever to populate a database.

*It's worked so far in my tests - it's successfully found my IP every time in a log file containing nearly 10 days worth of connections (3944 total) on a busy server, including a connection queue 7 players long. I've still got some more tests to do to be 100% sure though.