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).
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.
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.
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.
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).
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.
Some cards can fail the security checks, for reasons that we cannot control in any way.
One way past this situation can be to pay through PayPal. So you select PayPal payment then follow the instructions to pay through PayPal with your credit card. You should not need a PayPal account to do this.
About the purpose you describe, I won't delete all those hotlaps without some kind of preservation, at least of the world records, I guess.
I certainly would have to discuss with the hotlappers what to do.
When the new version is first publicly available, it will be in alpha or beta so uploading hotlaps will not be allowed at all, until a new table is in place.
I don't know yet how to preserve the old hotlaps but there could be one archive file of WRs like you say. I guess we shouldn't try to preserve all the hotlaps ever done, but I am just guessing that as it sounds too much, though I haven't actually looked into it. E.g. what is the actual data size and if a full archive could be kept online.
A vague memory suggests that Victor kept an archive of old hotlaps the last time something changed... not sure if anyone knows about that, and it it is true, how it is accessed?
A separate thought about clicking on hotlaps. I think it would be nice if at some point it could be changed to work more like the "Test a mod" button. So clicking the hotlap link would request LFS to play that hotlap. LFS would check if it already exists locally and play it from there if it does, or download it if it doesn't. It sounds like a better system but I'm not sure if it's worth the effort. I wondered if it would reduce one of the use cases of the WR pack? But I still think the WR pack is not often wanted. You are the first to mention it since I removed it some weeks ago.
Hey gu3st, please use the "REPLY" feature instead of "QUOTE". It's usually the best as it just includes the first line, up to about 80 chars I think. Obviously we don't need to read my whole post again!
The REPLY has proved a popular feature and I'm so happy it is used because it means these pointless "whole post" quotes are seen less often.
I think I removed this as it looked like something that needed some proper updating.
I discovered it as it was one of the things spamming up the error log, which I was trying to bring under control. I didn't ask for the job of website maintenance but I got it anyway, and to my mind, part of that job is reducing excessive server load and error spamming.
My memory may be a little vague but I think it was recreating this world record pack every so often (can't remember exactly but... too often) and each time it did, there were many errors. I thought, this large file can't really be downloaded that often so why is it recreated so often. It seems like a "sledgehammer to crack a nut" type of solution and I really would prefer the web server to run more lightly, not constantly creating large files that people rarely want.
It seems to me that if there is really demand for such a file, there must be a better solution, that could be implemented at some point. Maybe some kind of solution that creates something more relevant, when required.
Anyway, although I am veering off topic a bit, after my recent efforts I am quite happy that there is around 10 KB of error text each day, quite an improvement over the 30 MB per day I inherited.
As discussed on the other thread the skin and mod downloads are not https but plain old http and I wondered if BT doesn't like that.
It may be complicated by the fact that it goes through cloudflare too. I really have no idea.
I came up with a test, people who have the slow download problem could use their browser without https to see how that works to our website. There are some old pages of our site that can be accessed without https. The idea is to see if the same problem that you experience in LFS, is also reproduced in your browser when you use http.
BUT you have to use Firefox browser for this test! Other browsers do funny things so the results are unpredictable.
So, I wonder if people with slow connection can or cannot see this part of our site at good speed (using firefox).
In there you can visit the skinning competition and there are skin thumbnails to click on so you download skins, and can see if that is slow / doesn't work, etc.