The first time I used it (free version) Netherlands was one of the few options (also Japan and USA I think). I think the second time I used it, there were fewer options, maybe even none, but the available one was Netherlands.

I'm not used to these things but it was easy to use, just starts up with a click and you can stop it with another click.

They didn't spam me with emails or anything, seems fine.

I know and it could be worth testing but I'm back to the same thing I keep saying.

I can't stop and deal with this. I've already wasted more than half a day dealing with this. I have to develop the full version.

I can't keep stopping my development which is extremely mentally challenging, and start researching how to successfully make LFS pretend it is Firefox or whatever (which is a 'lie' that I am uncomfortable with anyway).

I'm afraid this is a problem between customers and their ISP.

The good news is that anyone can get around this with a free VPN (e.g. Proton). If the selected VPN server is in the Netherlands (which is a very common place for VPN server to be located) maybe there's very little extra ping (as it's so near to our servers). I'd suggest that is better than me stopping and starting development every day.

VPN at Proton: https://proton.me/

Maybe other people have better recommendations.

Last edited by Scawen, Sat 1 Nov 2025, 18:17.

OK, I'm still convinced your ISPs are blocking you.

I believe their algorithm detects what it thinks is a suspicious pattern and then blocks packets that match that pattern. They don't want their customers to be using bots to browse the internet.

By changing the user agent and getting no better results, we show that the problem probably is *not* that "LFS" is on a list of user agents to block. It's more likely a dynamic thing blocking patterns temporarily.

Unfortunately they have too many dodgy customers and so they don't trust you.

In my opinion it is a new thing they have introduced recently to reduce the amount of bot traffic they are facilitating, but unfortunately they are blocking legitimate traffic too.

I can't think of many ways round it. Hopefully the ISPs might change their algorithm to allow perfectly legitimate traffic, but only if they get enough pressure from customers. But from my experience, the main aim of such large companies is to keep taking your money and avoid doing their job if at all possible.

One other possibility is I could remove the whole concept of LFS using http to communicate with our website. It could communicate using custom protocols, in the same way that communications take place with LFS hosts. It's really a big job though, that would take a lot of planning and coding on the web server side.

That may never happen. There is no way I can promise to do that, we have a perfectly good working system that I believe has been broken by the incompetent actions of large ISPs. They have one job - provide you with a proper internet connection - and they are not doing it despite you paying for it every month.

Did you try entering a different user agent?

If you don't then it is identical to the previous version so won't affect anything.

I've made a quick test patch in which you can enter any user agent up to 7 characters. I don't really like this, I believe that LFS should use its true identity when connecting.

This feature is just a test and may be removed in future.

If it really is that your ISP is blocking the "LFS" user agent (for example they might think indicates a bot) then maybe if you try some other random sequence of characters then it's possible that it could bypass their blocking.

https://www.lfs.net/file_lfs.php?name=LFS_PATCH_7G_TO_7G2.zip

Quote from o000o :

It's my ISP forums and I want to ask them for help, only I wouldn't know what to ask.

OK, in case you are able to get through to a technical person there, here is what you could ask:


We would like to know if they are blocking plain http requests with certain user agents, in particular the user agent "LFS".

More information: The game "Live for Speed" makes plain http requests with user agent "LFS" for in-game downloads from the domain "lfs.net" which is a legitimate, low volume use of your internet connection and should be allowed.


EDIT: From my point of view, everyone who has this problem (LFS online working fine but skins, mods, event list, mod browser not working) is welcome to contact their ISP and quote the bold text above or some version of it. Unfortunately I don't have a developer's hotline or anything like that. Their technical people are welcome to contact us if they like.

Last edited by Scawen, Fri 31 Oct 2025, 20:29.

I've now disabled both:

- User Agent Blocking
- Browser Integrity Check

But fairly sure now it won't make a difference. It didn't really make sense anyway, as people from other UK ISPs can connect fine, not blocked by Cloudflare.

Thanks, I misunderstood your previous post, sorry. I'm not sure what to say, if anything.

Has the new Cloudflare setting I changed a few minutes ago (skip Browser Integrity Check) made any difference now?

Thanks for the answer.

To be honest I have no idea what the Plusnet tech forums are and I'm not really interested at this point.

I'm super busy at the moment as I keep saying.

Anyway, as you have replied with a negative result, I've switched to skipping the "Browser Integrity Check" instead. Let's see if that does anything.

TEST REQUEST for BT customers who have already reported experiencing the failure to download mod images, skins, mods, etc:

I've changed a Cloudflare setting. We need to hear from the BT customers that reported a problem above, if it helps their mod list etc.

If not, I can try one more setting.

Short version of test request:

I've changed a Cloudflare setting. We need to hear from the BT customers that reported a problem above, if it helps their mod list etc.

If not, I can try one more setting.

Quote from Flame CZE :

There may be a Cloudflare setting to allow all traffic through if user agent is "LFS".

Well... there's something similar.

I've now set a rule to skip user agent blocking if user agent is LFS.

But although I looked around for a while, I can't see any evidence that user agent would have been blocked, so I have very low confidence that this will change anything.

Anyway, at least it didn't break anything for me. Let's see if this helps our BT users.

EDIT:

Attached image, showing some options. I've selected to skip "User Agent Blocking" but I don't think we have any user agent blocking enabled so skipping it probably won't affect anything. Maybe if the current change doesn't help at all I can try another option, e.g. "Browser Integrity Check" in case that might do something.

Still, I don't see why Cloudflare would only apply blocking rules to BT customers.

Last edited by Scawen, Fri 31 Oct 2025, 11:10.

Quote from MicroSpecV :

>>> timeouts, mod loading frame stutter, and long mod loading times are repetitive yet random for an unpredictable subset of user - Irregardless of their nation country, be it Turkey, Singapore, UK, France. There is a trend here of increasing destability in client connections that you are ignoring simplu because it seems, to us, that it is too much of a hassle.

It's more because I am just a game programmer. I'm not the overlord of the internet.

I'm just one guy sitting in a house trying to make a nice game. There's no way that I can be expected to increase the stability of the global internet in the face of ever increasing usage, attacks and political instability. Maybe the best times of the internet are now in the past, for a while.

Quote from Flame CZE :

I wonder if it's Cloudflare blocking or slowing down traffic from some locations when it sees it's not coming from a regular browser due to the special user agent string. Maybe Cloudflare falsely thinks it's coming from a bot or a suspicious source. There may be a Cloudflare setting to allow all traffic through if user agent is "LFS".

But this is just a speculation

I thought as much too but seeing as the UK issues are 100% BT customers, and the rest of us also go through Cloudflare, it seems to point at BT more than Cloudflare.

Quote from MicroSpecV :

[...] I'm not even in the UK - so the "affecting just BT net users" is not applicable.

[...] If it's not due to the updates and also not solely BT (or any particular ISP) then it just leaves the master server provider...

Faulty analysis.

First of all you are confusing two completely separate issues.

Issue 1) British users at BT who have absolutely no problem at all with any of LFS services apart from one very specific type of traffic: http requests from LFS.exe to our web server, downloading images, mods or mod list.

NOTE: These users have no other issue between their computer and our servers. This currently points to BT traffic shaping as the only thing I can think of. Once again, I cannot and will not stop developing the new full version, at this time, to deal with BT traffic shaping or whatever it is that doesn't affect anyone in Europe other than BT users in the UK.

Issue 2) You are having problems with all types of connection to LFS servers, from Singapore to the Netherlands. There is no way that this can be explained by a problem with the i3d internet connection that is working fine for most people. It's a long way between Singapore and the Netherlands and we cannot be held responsible for the behaviour of multiple internet routers around the world.

REPEAT: You are talking about a separate, unrelated issue.

Last edited by Scawen, Thu 30 Oct 2025, 15:58.

Thanks for the further research and explanation.

I think I'll just leave this thread as not "answered" so I can have a look when I have some time.

I am serious busy working 12 to 14 hour days trying to finish the new version - and nothing has changed in LFS code pages in recent times.

So, please. before I look into it at all can you have a look to see DIRECTLY the output from LFS? Special Japanese characters are output as double-byte characters from Windows code page 932

LFS.exe has absolutely no knowledge or implementation of anything to do with UTF-8 etc.

It only knows single byte ASCII and code pages (including double-byte code pages for Chinese Japanese and Korean). It does not do UTF-8 or any kind of UTF.

LFS doesn't do any kind of conversions like that, and this forum is purely about LFS bugs.

Please can you discuss on an InSimDotNet thread?

There was something similar recently. https://www.lfs.net/forum/post/2120244#post2120244

This forum section is purely to let me know about LFS bugs, for me to fix. But people are reporting issues with text strings that other programs have already converted.

To be clear:

Again, this is NOT because of the update. Nothing changed in the update. If you get the old version, you still have the issue.

One person proved that above: https://www.lfs.net/forum/post/2137324#post2137324

It has also been proved that if you use a different internet connection, the problem goes away.

So the problem, for the UK users, appears to be BT. The only possibility I can think of is that they are restricting http traffic from sources they don't understand. LFS connects with a "user agent" called "LFS" rather than "Firefox" etc. So maybe BT suspects it is a bot or web crawler. This is speculation.

Seeing as it's pretty much only BT users that have this issue, the ideal people to fix the issue would be BT, if they would kindly avoid traffic shaping that would be appreciated.

Alternatively we can try experimenting, so that LFS 'spoofs' its user agent to try to appear like Firefox. But I am seriously much too busy, currently working on average 12 hour days to try and get this release finished, so I can't start messing around now trying to get around BT's traffic shaping.

Round info page has the original start times:
(says 18:00 UTC, should be 19:00 UTC)
https://www.lfs.net/leagues/885/season/1316/round/5767

We don't know if a prepaid virtual visa card will work through our credit card system. We think probably not.

If you know they work on PayPal then we think you can probably pay through PayPal.

But we can't provide any guarantees as that is all out of our hands.

It's not clear to me what you are saying.

Basically I would like to know if:
1) replays saved after you restart your host, now have the correct date?
or:
2) You restarted your host but new replays recorded after the restart, still say 20 July?

My test: I started a host and recorded a replay. Restarted the host on a different server and saved another replay. Both have the correct date.

Restarting the host will not correct the replays that were already recorded in the past, but hopefully new replays have the correct date.

OK, I can't really understand how this has happened.

It seems like something might have happened on that server at that point in time, probably affecting all hosts running on that server, so the function "GetSystemTimeAsFileTime" always returned the same value, and that value was implanted into the replays.

It seems that it will be fixed if you restart your host, and that's what I suggest at this point.

Thanks.

I've never seen this screen before, but I suppose it's the "Replays" tab for a selected host.

For a clue, when I've got some time to look into this, do you know where the 20 July date comes from?

Good to hear your friend got their email in the end. I don't know why it would have been delayed but email can be like that sometimes.

Anyway, the original issue has not returned after Victor fixed it.

New users who tried to register will need to register again, and this time they will receive the email with the confirmation link.