Now I think I should put this as a quotation into my signature. Talking about me, the bug. Well, many (or at least some) would agree. Pity my signature space is spent already. But I get now what you meant.
Indeed I did, a week ago or so. But in fact version 2.4.9 is almost ready. And it brings one feature that was requested for some time and that I personally like a lot! Be sure to read the Airio changelog, that I was finally able to complete.
No idea. Just a question though: Does it concern display of good splits? When yours are shown but other people's are not? If so, it is not a glitch in fact and I'll explain in more detail here.
Nice one! Using speed in Airio is tricky, because data reported by server are constant for substantial periods (one second or even more), and then there's a sudden jump. Because of this delay, speed checks are not quite reliable for braking (as was the intention), but they can be safely used for accelerating, so what you gave us is a very good application of an existing feature. Thanks!
Well, I guess there will come a day when both are included. BabyOnWheels already has a code to do the GP stuff, and it is available, maybe I could look for inspiration there. For the rolling start I'd still need to gather all the requirements, especially in weird conditions (e.g. someone lagging/timing out) and convert them into some applicable structure. But certainly this would be a great addition.
You need to see that now it is a basic framework - graphical selection, showing number of votes, choosing site and then track based on user left-clicks (to give vote, multiple options allowed, but only one vote for each from one connection) and right-click (to cancel an earlier given vote). I believe it works as it is supposed to, which is important. But people already express some doubts or reservations, mention possible abuses.
And the objections may be correct. But I think we may wait a bit, see if the undesirable actions happen in reality. By this I mean a bunch of people always voting for one track, majority voting to end race right after rotation to call new voting, generally moving just between two or three tracks.
When 2.4.9 is released (soon) and used for a time, we'll know more. I already have some relatively simple mechanisms in mind that could be used to fight the possible negative sides of voting. For example: 1) Prohibit race end voting for at least one race start on newly selected track, or better for a set time. 2) Keep rotation stats and prefer not much used tracks.
This could be done by e.g. assigning them negative number of votes from the start. Say we go from AS3. AS as a site will be given e.g. -2 votes, while other sites will start with 0. Same for AS3, if AS is actually selected. And the negative numbers may rise in time. Or other sites/tracks may be given positive votes (e.g. +2 votes for the track that is actually already loaded, next in defined rotation).
The options are there, but I think time will show if it really is necessary. Admins should also know they can cancel the vote just like any other, using !cv. We'll see, but I have to say when there were about 20 people on the & Genuine GT Racing server, which is currently used for testing, it was great fun to see how the votes were raising and how people voted in the last second to switch to some other track.
Fatal, if you think you know about a bug, it is maybe best to post it here.
Okram, I'm not sure how this could work. Where would the PHP request be sent? To LFS server, using InSim connection? No such framework is implemented now and I do not see an easy and obvious way to implement one.
The servers list is generated based on information sent every minute from each running Airio. Information is compiled, summarized, tabularized. May be I could create a procedure there that would make some very simple document/file with server name, Airio version, and perhaps number of connected/racing people, maybe also some state data (not sure). Your script could ask for this file, and parse/process it.