Picked kebrum.com at random. Found this in their terms:
"If you violate any of our terms that involve criminal activities, you will forfeit all the privacy and confidentiality privileges that our service provides."
I doubt that any clueful black-hat hacker would pay for VPN services of this kind.
Firstly, jeez Dave, did you get out of bed on the wrong side this morning??
Secondly, your link shows how a paying customer of a VPN vendor can connect to stuff from lots of different countries. See my comment about "legit account" above? This is not how hackers roll, because the VPN provider could (and in this case probably would - based in the UK, lol) give their details straight to the authorities if a complaint was made. This doesn't really anonymise him at all if what he has in mind is illegal...
Finally, who contradicted Scawen?? Not sure what you mean by that.
On the proxying point - there is actual evidence of multiple countries being used? Because while you can do anonymous web proxying from countless servers out there for free, I didn't think the same was true for VPNs or any other methods of proxying. Thus he'd surely have to have actual control of (via a legit account or maybe a trojan) the machines that are acting as middle-men...
But hey, if he has packed up and gone, then great, game over
Huh - LFS works with proxy servers?!? HTTP over proxy - sure. But UDP position updates?
Meh, the issue - whatever it is - is likely there for everyone. It could be that a slower PC highlights the issue/bug/feature... for which we should be grateful, right? Cos then we can squash it
Well obviously because the trauma of zeroing your > 1yr uptime is just so devastating!
(PS: can't you just use a kernel debugger to bump the jiffy count right back up there?
)Mmmm, does that imply that a bunch of folk are trying out a (fixed) cheat?
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...
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.
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.)
(My hosting a/c doesn't have Wine... Quick search failed to find official "no" on native linux version.)
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.
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, .
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.
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?)
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.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?
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...
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
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
FGED GREDG RDFGDR GSFDG