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.

I think they have to register again.

Hello Racers,

Unfortunately there was an email problem today. It is now fixed but I believe all emails sent in that time are lost.

So you will have missed out on post notifications, and new users could not complete their registration.

Also any unlock codes would not be sent if you had requested one. In that case you can request another unlock code.

Sorry for the inconvenience.

This is now fixed.

I believe that emails already sent will not arrive, so you need to request an unlock coed again.

Sorry about the inconvenience.

Unfortunately I didn't get the notification of your error report, because notification emails were not sent, due to the email issue.

Thanks, I noticed this too, I have asked Victor if he can see why emails from the website aren't working.

Hello,

I am trying to investigate the cause of a strange issue for some users, particularly some of our UK users with BT internet. They have connections that appear to work well, and our website works as expected, but downloads in game run very slowly (skins, mods, mods browser, event list). We are talking VERY slowly: 15 seconds for a small image, 10 minutes for a mod.

If you do have that problem, please visit the special thread on that subject. There are some tests you can try if you set your browser to allow http connections (LFS uses http connections, not https, but this does not seem to be directly the cause of the issue).

Special thread: https://www.lfs.net/forum/post/2137385#post2137385

Last edited by Scawen, Tue 14 Oct 2025, 08:09.

You may also be able to do the test with Chrome instead of Firefox.
How to do it: https://superuser.com/questions/1400200/chrome-persistently-redirecting-to-https-for-http-site

(Link to instructions provided by tankslacno on another thread)

Quote from ScoEzza :

Also getting MOD: Could not connect in chat and mods taking over 10 mins to load...

Hi, please can you check out this thread on this specific issue? I am trying to investigate UK users with slow in-game downloads. There is a test you may be able to do.

https://www.lfs.net/forum/post/2137385#post2137385

Results we are waiting for now:

For those who have got consistent slow downloads of skins, mods, mods browser and event list in LFS:

We are trying to establish what could be the cause. It seems particularly strange in the UK, where connections are good and our servers are located just across the sea in the Netherlands.

Known UK users with the issue are o000o, Zero7, Cimanu, Boypower, ka darai


TEST 1: This test was to see if there is some issue with plain http, between your ISP and our servers.

Using Firefox so you can view http (not https) visit the 'LX skinning competition' and see if the images and skins download at normal speed:
http://competition.lfs.net/lx_skinning/

Results so far: those people who could visit it, reported no issue.


TEST 2: This test is to get closer to what LFS does in game.

Using Firefox again, follow these links that are very similar to what LFS uses in game:
http://game.lfs.net/eventImage.php?name=dOH2RaLx.jpg
http://mods.lfs.net/cover.php?skinId=4FF048

You can create similar links by looking at image links on the event calendar or the skin id of mods.
http://game.lfs.net/eventImage.php?name=BcYGEUfQ.png
http://mods.lfs.net/cover.php?skinId=FC0AAB

We need to know if those images seem to load at a normal speed, or if you see any issues.

Results so far:

User 'o000o' reported a slow download: https://www.lfs.net/forum/post/2137340#post2137340

Quote from o000o :

I tried the http links posted and had to wait 15+ seconds for them to load.

Well that is strange, they are only small files.

Let's see what result some of the other people come up with.

EDIT: If they also get slow downloads of those files in Firefox then it seems like we may have some sort of a clue.

Last edited by Scawen, Mon 13 Oct 2025, 20:16.

I asked Victor but he is also puzzled, we can't really see why something that has been in the game and our site for so many years and has not changed in any way, might start to be a problem for some people. We are using simple http protocol, with no funny tricks.

He sent a couple of example links that you can try in Firefox:
These links are just as they would be accessed from LFS.

http://game.lfs.net/eventImage.php?name=dOH2RaLx.jpg
http://mods.lfs.net/cover.php?skinId=4FF048

Just to see if you have any trouble getting them in your browser (Firefox, so it doesn't complain about http).

You can create similar links by looking at image links on the event calendar or the skin id of mods.

E.g.
http://game.lfs.net/eventImage.php?name=BcYGEUfQ.png
http://mods.lfs.net/cover.php?skinId=FC0AAB


EDIT: One thing I wonder about is if the ISP (e.g. BT) might be doing deep packet searching. If so it would find "User-Agent: LFS" (rather than Firefox etc) and I just wonder if they might be doing throttling or traffic shaping (e.g. they could possibly think the requests come from a bot or crawler and not be legitimate traffic - I'm just making this up, I really have no idea). There's one tiny change you can make in LFS to remove a small item from the URL that it sends to our site. Although I find it extremely unlikely that it would make any difference, if you switch off "Allow regional downloads" it will not include "X-Caps: 1" in the URL (it's just a line telling our web server that LFS can allow redirections).

Last edited by Scawen, Mon 13 Oct 2025, 16:59.

The payment methods are listed on our site and one of them is PaysafeCard, in case that helps.

But I can't advise or help any more than that.

Thanks, fixed typo in 0.7G

I can't see or reproduce any bug. Something appears to be wrong in your code or analysis.

The TextStart byte refers to the actual offset in the original binary representation of the string in the packet, but you seem to be comparing it with some interpreted or converted strings.

Your "to utf16(?)" strings don't mean much to me. For instance, in the original output packet there is no ^c - there is just a plain colon.

To deal with your examples:

1) If you restore the ^c to : then the offset of "test" is 14 as expected.

2) Single width katakana (1 byte for this katakana) again the offset it correct if you replace ^c with :

3) Double width character so it's one more than example (2).

Basically if you look at the original bytes in the packet before doing any conversion into other text encoding systems, you should find the offset points to the first character of the message. I've verified this in my own InSim packet checker.

Thanks, in my version I've added /i and /o to the commands that are excluded from command line splitting.