Am I right in thinking that to display a simple 'server status' and/or 'racers on server' page requires pulling in the data for every server and then discard the unwanted stuff?
I second that request. What would also be good is if we can filter the host name irrespective of the colour options that are placed inside the hostname text.
Additionally, would it be possible for us to filter the teams action too? It's a similar situation to the hosts issue raised above, where I want to display information about my team (as entered into on LfsWorld) but I have to transfer information about all the teams (currently there are 889) just to get to mine. Possibly a filter on the Id or the name.
What I miss most is the ability to get player's status - Demo, S1 or S2. I see this was not necessary in the past but since even Demo players now have (or will have officially in [hopefully] very near future) LFSW stats available the licence info would be useful - e.g. it would be possible to see if a Y18+ server in demo config can be safely switched into S1 or S2 mode without anyone losing connection.
One more small thing I miss in the stats is date/time in WR table saying when that record was made or uploaded. Still, the stats are very nice indeed.
Hello, one question: Is possible to get someone's identification key without asking me? EDIT: No, no... my bad. Now I already see. I don't need id keys of the others...
Encoding problems with JSON (s=1) for hot lap charts (ch)
Hi,
while fetching hot laps charts I discovered an encoding problem in racer names when using JSON-style. The LFSW nickname is "Jörg Baumgarth" for the KY2/FXR.
Does not like non standard characters. I had that same issue with FireFox and XML files. It did not like Kimi Räikkönen's name at all. So I replaced the ä with an a, and the ö with an o.
I'm going to conclude it's a bug in the json_encode function, although on the other hand I also made a mistake - strings in JSON should be UTF-8 encoded, but aren't atm. However i tested it with UTF8 strings but the name cutoff in the json output still remained. That's why I think there's a bug in php's json encode function.
Not sure what to do about it at this point. I could write my own json encoding function, or i could replace such accented characters with their unaccented ones - though that may not be the best solution.
Something like that should do the trick ... I am missing some, I just took up the Character Map and copyed all of the ones that where to do with each letter according to the Windows Character Map. That said, you should be able to this programmatically ... some how. (If the Character Map knows this information then it must be some where.)
yeah actually i had a bug in my json_prepare function. The json_encode function is fine.
But now i wonder if i can just make the json output unicoded. I don't know if that's going to break some applications. So maybe i need to increase the version number for this fix?
Hi, im having a little problem. I'm new to php and the pubstat system, so my code probably needs a little touch up.
Ok, when I upload my page to my server, it won't show if i'm offline/online etc. However, on my WAMP server, it all works fine and displays the way i want it to.
PubStats via Web are great, I use them a lot in the AIRIO tracker. However I dare to come forward with a few suggestions. I posted some of those already in June last year, but without response. First the most troublesome matter:
1) After a bit of testing I came to the conclusion that the PubStat service is checking IP address the requests are coming from and if "tarpitted" (meaning limited, not paid) service is used, it will refuse requests from one IP coming faster than with 5 seconds delay. It does not matter the requests are coming with a key belonging to some other person, they come too fast from the same IP and are refused.
Well, in my view that approach limits usability of the service. There may be different people/applications on the same IP (without knowing the fact) and they may get random refusals. I know a server where Airio cannot download LFSW data in approx. 20 percent of requests, and I believe it is because there is already some other application on the same IP. An admin there can do nothing about it, generating new key for himself will not help, binding it to IP will not help either.
I can understand this is implemented so that people do not generate dozens of pubstat keys for themselves under different names and using many of those at the same time. Still, it prevents also legitimate pubstats usage. Paying for the service may provide only partial solutions, because if one person on the same IP pays for the service and sends many requests, while the other not, well - the one wanting to use free requests once every 5 seconds will be rather seriously damaged, wont he, with many requests turned down for no apparent reason?
My suggestion: Remove the IP check, let it run only on pubstat key basis, but at the same time let only licensed people generate and use the keys. As I see it, all the above troubles will be solved. And I can assure you, they are real troubles. I saw wrong people being kicked in LFS prior to patch Z when IP was used instead of username in demo, and this seems a similar matter to me. Limiting and deciding something based on IP is not good with the lot of shared IPs around the world.
2) What I miss most in PubStat data is the ability to get player's status - Demo, S1 or S2. I see this was not necessary in the past but since even Demo players have since patch Z LFSW stats available the licence info would be useful - e.g. it would be possible to see if a server in demo config can be safely switched into S1 or S2 mode without anyone losing connection.
3) One more small thing I miss in the stats is date/time in WR table saying when that record was made or uploaded.
Thanks for reading this far. I really believe especially point 1 needs serious attention, that is if something obvious did not escape me and I'm not making a big mistake somewhere. I also hope I did not miss some previous post concerning this, but searching gave me no similar results.