Quote from Blade3562 :

Almost like one packet from one IP and the next from another. Can his mac address be tracked down and blocked?

I would have thought that LFS used the IP address as the primary way to identify which user a packet is from (and thus would not be able to accept packets for that user from another IP). But am guessing here.

MAC address blocking: 'fraid not - firstly it's trivial to forge a new MAC address; secondly MAC addresses don't get transmitted across the internet...

If it turns out not to be a local hack on the [AA] servers, I am guessing that packet capture would help...
And, since the capture file could get rather large (!), perhaps you (Scawen) could advise on what filtering could best be used to catch potentially incriminating packets but still keep the capture size under control.

I guess at least some server admins have adequate access to try this, and could thus potentially run a rolling set of captures in the background until he shows himself...

Wow, that's impressive, if rather cheaty...

I guess Scawen will immediately know how the little beggar did it, and with luck will immediately know how to prevent it.

Interesting... It also suggests that if clock sync could be achieved (so that LFS was confident about the age of the packet when it finally arrived), then the path prediction ought to be able to cope with ping fluctuations. OK, sorry, going off topic now, will take this up elsewhere

Um, teeny hop skip and jump from here to native linux dedi?
(My hosting a/c doesn't have Wine... Quick search failed to find official "no" on native linux version.)

Quote from cargame.nl :

Its ping and its a lag indicator. Values under 100ms are acceptable but it mustn't fluctuate. If it fluctuates with more then 20ms you become dangerous for others (and yourself), heavy so called 'lag crashes' are going to happen when there is too much fluctuation.

Really? I thought that the most important thing was having a modest ping time, not whether it fluctuated. I'm stunned to hear that (for example) 50ms ping variation (on, say, a 100ms ping) could be a problem.

Pfff, I clearly didn't RTFM hard enough. It is in fact not in the keys.pdf file, but it was added to the wiki the same month I bought my S2 licence

Always good to learn a new hotkey

Edit: Incidentally, the longer explanation for what this key does makes it clear that it isn't what bavorak asked for. LOL
(As I read it, the request was for something that blocked the server info messages but not chat...)

Edit^2: I forgot to say (like anyone gives a toss) that I support both of the improvement suggestions made by adamshl, and also bavorak's in fact.

Last edited by Neilser, Mon, 26 Nov 2012 19:21.

Quote from Scawen :

Yes, this is done differently now. Your message is sent back to you from the host and displayed the same way as everyone else's messages, instead of being displayed locally and the host avoiding sending it back to you.

Wooo, I thought it was always that way, because Airio commands don't get shown on the screen if Airio doesn't feel like showing them (e.g. admin cmds). Perhaps the client treats msgs beginning with "!" as special? And also msgs beginning with "/" for other insims? (Apologies if this is already documented!)

Good idea to change it.

Quote from JasonJ :

"shift" + "-" to hide server info messages.

OMG, who knew? I thought I had RTFMd but never spotted that one. Where did you find it? Nice...
(Unless you're suggesting that as an improvement?)

Quote from DANIEL-CRO :

I finally understood why my local ping was so high. Its because my FPS was limited to 10 (LFS instance only for testing on laptop). Without FPS limit (about 40 fps) I got maximum ping of 30 ms

This reminds me about Scawen's comment (http://www.lfsforum.net/showthread.php?p=1755308#post1755308) about decoupling the physics & redraws from the packet handling in B11. But that should have meant that you wouldn't have seen this high ping behaviour since B11 came out, and the way I read your posts, you did see it with B11. Maybe this is a clue that there is still a problem lurking.

Or... maybe the high number you saw was purely "local" info and wouldn't be reflected in what other people see for you? Scawen will know I guess. (Does 10 FPS mean the physics loop really only runs at 10Hz too? Surely not.)

And as for loading more slowly with low FPS, that sounds like an accidental (and pretty surprising too! ) side-effect. Funny though.

Quote from three_jump :

I understand that too big might be distracting, but I have trouble seeing them

EDIT:
As you are saying that the new lag bars and the numbers are the same... I suggest that we could ditch the bars completely as they are redundant then

The point would surely be that if they are invisible it's cos the connection is good and therefore you don't need to see them
Any bar that you can see flags a player with a problem, and then you can check the numbers against the players... No?

Quote from Bigbob1993 :

I understand that Ip6 may mean nothing interesting for you but for more technical people it will make some things easier

Gosh, I consider myself a techy person but I'm massively unkeen for Scawen to spend time on ipv6 any time soon.

What's the most important thing that would get easier for you if LFS supported ipv6?

Looks like the stats were retained too...

Nice one - hadn't realised that info was there.
That explains a lot about how the torque (&power) curves are modelled within LFS...

Is that an actual example of the values of the units? They may be some nonsense internal thing, or maybe they are SI (like kW and Nm)?

That's good to know, thanks - basically it seems like at least a few people are using it without problems...

Well, the speed is likely to be excellent, but that's not what concerns me - it's the traffic management. In plain English, traffic management means that certain packets get priority and others can be badly delayed or dropped.

When Plusnet brought in traffic management, they took care to ensure that time-critical stuff got prioritised - e.g. gaming, iPlayer, other streaming video, Skype, other phone/videoconf stuff, that kind of thing.

Packets which can be delayed without pain include ftp, torrents, etc.

While their traffic management mostly worked OK, the problem for me was that they could not succeed in educating their systems about how to recognise an LFS connection. I can't now recall if it was the UDP or TCP traffic which had the biggest issues, but they said at the time that the port usage behaviour made it hard to recognise a consistent game signature... It sometimes worked beautifully but more often than not it was awful. After months of trying, I found a new ISP.

Doesn't matter how good your max downlink speed is - if traffic management kicks in at peak times and delays packets by a few hundred milliseconds (and drops plenty of them too) then LFS is unplayable.

So, I was kinda hoping to have a flurry of happy Infinity users saying that LFS was still working fine for them

Handicapping: it has belatedly occurred to me that the XFG is nearly 20% lighter (including driver) than the XRG.
I'm guessing, possibly wrongly, that the XFG will be disproportionately handicapped by the current rules with equal ballast for both cars.
So maybe for every 10kg of ballast for an XRG, we should only add around 8kg to an XFG?

(Clearly I'm talking about future seasons here )

Hey there...
UK users only for this one I guess.

I used to be a Plusnet ADSL customer, until their traffic management killed LFS. They tried hard to fix it for me - I sent them a whole bunch of packet dumps, but no dice. They claimed it had some behaviour (port usage) that made it hard for their systems to recognise (and prioritise) the packets. Long story short - I changed to Xilo (partial LLU, C&W ADSL2+) - happily ever after.

Now BT have put fibre in my neighbourhood, and I'm very tempted, but it comes with an 18-month contract. So if it's not good for LFS, I'd be screwed. They have NOT claimed that it doesn't use traffic management (even for the package which has unlimited download).

So I'm hoping there are happy customers here who are using it already?

ta!

thread title typo

6 laps!
Lowest feature race lap-count in LFS history?

(And is this the longest open track btw?)

Quote from andRo. :

I know that 2nd race earns more, but if it was allowed the way you were saying, you could also come to the first race, crash on purpose and spectate, then start 2nd race and finish in good position. That was my point.
Anyway, I understand why you are confused, at first I also thought I would be doing the way you asked, assuming that if you don't finish you would be considered as finishing last, but after I checked it out, I understood that it could make an unfair advantage over other drivers in future if someone would have noticed it, so yeah...

Umm, do you really want it like this? You prefer that people drive slowly for the second race, rather than crash out and spec?
Perhaps it could be argued that if someone has the patience to drive slowly for the full race duration, then they deserve to have their handicap reduced by a lot...

Anyway, while I don't have a brand-new recipe for a superdooper handicap system for you, I will say this: I think a points & handicapping system within which it is truly advantageous for a driver to deliberately fail (crash/drive slowly/skip a race) is broken...

(Yeah, and clearly this whole issue is never going to affect me personally :razz

Hmm, not seeing that 32kg is so bad for you Joe.
How badly did you do with 30kg in R2? (Answer: P2, P3, and 0.01 off pole... You're too damn fast! )

So you'll maybe have one bad round, and if it's truly awful then you'll drop back to 32kg and be right back on the podium...
Sounds pretty bloody close to a perfect ballast system to me

Thanks for the info Ben.