Seeing the code, I believe Aonio saves PB/TB/fuel on every change, so I think killing it should be a relatively safe process, unless it is writing something right at the time. Myself, I always stop Aonio by pressing Q in its console, which is most safe...
True, and it is a nice trick with button IDs pool and dynamic assignment. Problem is that theoretically someone indeed might want to have all the available Aonio panels/buttons displayed, and really run out of IDs...
Bans by IP are rather controversial, as there is high probability that they'll hit many innocent people and that they will not actually prevent the cheater from connecting. Experienced cheaters can change their connecting IP rather easily and nowadays many IPs are shared and one IP ban could affect dozens of people (using the same provider).
That's why I always refused to add IP bans to Airio, even though many people asked for this. However, there is a domain name ban available, which is almost the same thing as IP ban. It has the same negatives, but if used temporarily while fighting one cheater, maybe you could try that. Look in CFG file under "Refused Hostnames" and in Airio log for the actual hostname.
Ah, right, it should not respond to !safe at all when safety ratings are disabled.
Hmmm, that sounds really strange. It seems that the host (server) somehow lost its default admin rights in Airio, but without log I cannot see how it could have happened. Maybe you could send the Airio log to my e-mail?
Standard positions for LFS buttons (both from server- and client-side applications) are 200x200, if I remember correctly. I really do not know whether it is possible to specify other than the main monitor, but I have my doubts...
Well, in this respect Airio is really unoptimized. At one point or another it uses all the available button IDs. I'm planning to re-number the buttons, so that there is one ID used in several mutually exclusive situations, but this is pretty complicated and error-prone process. So, for now there's no range I could point you to, sorry about that... In the future, I hope Airio will be using "only" half of the available range, say 0 to 127...
OK When I find a little time, hopefully in a few days, I'll make it some kind of an option, so that you don't have to use an older version that almost for sure contains some bugs. (Well, I'm not saying the latest does not, but at least I removed all that were reported and that I noticed.) Myself, I use rather the engine sound to shift gears and I use the beep as an additional notification. The beep delay is good for this purpose, but I see your point.
The nickname code is output into the text file or the database as it is reported by LFS, one-byte values representing some characters depending on other switches. The problem could be that the file itself is then saved as UTF, which can obscure the original meaning of the byte codes. But if the raw nicknames are read as one-byte values, it should work... somehow...
Your estimate of the shift beep delay is absolutely exact, 0.5 seconds. I added it intentionally to eliminate wrong beeps, which can be really annoying and which you experience on jumpy tracks, particularly in rallycross.
Now, the question is, is that 0.5 seconds sound delay important? To me it does not seem to be the case. But if it is, the solution may be to allow to disable the delay, or define tracks where it is applied...
Concerning the version numbers, sometimes my signature and the version available at airio.eu go slightly out of synch when I forget to update one or the other. Usually, my signature contains the latest.
I am announcing new Aonio version only when they contain something substantially new. Recently, versions 1.5.5, 1.5.6, and 1.5.7 contained basically just bug fixes and minor things solving some undesired behavior (such as the beep delay), so I was not announcing them, I just changed my signature to point to the latest version...
I'm really not sure how this could work. The country data are gained from LFSW (usually quite reliable) and IP addresses (sometimes), so it probably can be used, but... uhm...
Partially. Some items will be translated, some will not. Soon I plan to contact the translators again with an update.
That means Airio is NOT connected to your server, it is connected to your client. And it cannot work in that mode, it needs to be connected to a dedicated host. Typically, people think that when they connect as admins to a server and type /insim=29999, they are setting up server insim port. But instead they're just opening local client insim port. Server insim port needs to be set in the server configuration file or directly in the server console.
Sorry, but this is so vague that it actually borders on a political statement. At least we here have loads of such. But we may move forward. I believe this all is happening at CG, where replays are being stored on the server. So, next time a supposedly wrong lap invalidation happens to you please ask Dave to send me the race replay. I will run it through Airio and see what is happening.
Aaah, correct, sorry for misinformation. You actually need to leave something as DragLines value, but it can be either a track you do not use (DragLines=BL3) or an inexistent track (DragLines=NONE). Then sending to pits for false start should work.
Path check is not connected with other cars on track. It would be the near cars check that could make a hotlap invalid. Please turn on path info, and it will always give you the reason for lap invalidation. But no, lagging cars should not cause lap invalidation.
Actually, no, there's no such info available. But it can be solved anyway. Airio keeps connection IDs (people) assigned to player IDs (cars), so when it sees a car joining from the same conn ID, it may spectate it. The question is whether this is not too extreme. True, multiple cars from one CID cause weird things, but it causes no real harm... I need to think about it.
I do not want to mess with conditions for storing lap times, they're complicated enough. But you can disable false start spectate for drag lines anyway. Search in TCD file for an item that defines drag lines and delete its contents. No false start spectate then, but all drag times will be stored in stats.
LFS itself does not have this unified. Sometimes, names with no color show as gray, sometimes they're white. I'm not sure now why I've chosen to keep the original name color when replicating a command. I'll try to watch this more closely.
I updated a bit the above quote. As you can see there's quite a lot of checks that make an online hotlap invalid. Online hotlaps are most often invalidated for the following reasons: cars (near you), object (hit), ground, path. This makes me wonder if Skagen's complaints were really about path check, because saying that it fails in 90% of cases is simply unbelievable. Since new LFS patch with ground/wall reporting the path check is set quite loosely and I simply cannot believe it would fail so much. It is rather rare to see invalid lap because of path, in large majority of cases other checks kick in first, such as cars near or ground. So, while being on a decently filled server then for sure 90% of hotlaps will fail because there is always someone near you. But that's not because of path and faulty clean laps check. It is by design and it is correct. If you want to hotlap, find some empty Airio hotlapping server, that gives you all tracks and all cars, such as & GenR HotLapping.
I base this on my own experience. Above 90% (in fact close to 100%) of my lap invalidations are perfectly correct. It seems we have radically different experience then. I wonder if there are more people seeing it your or my way?
Simply put, Airio does not support several cars coming from one connection (that is several AIs or you and some AIs). When you try that, weird things will happen, such as what you describe. I do not plan to change this behavior.
False start spectate in drag races was implemented long time ago to stop wrong times being stored in stats. I'm not sure if there are now other reliable mechanism to prevent this if false stat is allowed.
PS: The bug that was leaving some buttons displayed in !sb (!top) output and elsewhere is corrected in version 2.5.8.
I do not agree. And quite strongly at that. Airio uses what it is possible to use and in what level the server offers/knows it.
If it gives you invalid lap because of path, then you were really seen by the server (for some time) at a place outside the valid race path. The question is whether the used paths are always correct. I adapted many, created new ones, but most for the standard tracks still remain as designed by LFS developers.If you can fly over some bumpers, then 1) you are outside the path for just a short while, and 2) LFS did not report your car as touching the ground.
Now there is a contradiction. On one hand you feel the lap should be invalid even when leaving the path for a short while, on the other there should be some allowances for delays of car position updates. So, I'd say that the detection of clean laps is flawed. But I deeply disagree with a statement that it is very flawed, maybe almost unusable. It is as good as the data that are available are, finding a balance between being too strict and too lenient.
Surely it is different from the HLVC. But it is simply not possible to get that precision. It works differently, it gives different results than HLVC, but it is the same for everybody, as much as possible Due to lags some good/bad luck will always come to play (with new LFS checks this is diminished). But there's nothing I could do about that on server-side.
Interesting about that text, I'll try to recreate the condition and see what could be done about it. The safety rating is always instance-specific and it depends on local Airio configuration for the instance or the specific server. With default values the highest rating is 99.50%. But it could be somehow less or slightly more under different Airio configurations.
Hmmm, that's a pity. I consider the AIRW good online laps one of the best Airio features. It is basically one-way communication, the good online laps are not used for time checks etc., they can just be displayed. What is the reason to turn off path check and with that most of the AIRW functionality?
I'm afraid this all would require much too effort, whole new principles to add (postpone stats saving, display disputed times, allow to discard or confirm them). I guess we're talking here about demo people/combos. For that I would suggest to define strict time limits for the demo combos/servers. Limits, that would still allow real fast people to pass, but that would kick cheaters immediately. True, it will not be based on experience but applied generally, still it would be a very good protection.
Thanks! Just let me suggest once again what I already proposed above. K34 with that chicane is a nice challenge. Why not extend the challenge even more, forcing cars to slow down at one more place on that very long (over 10 kms) track? So, I suggest creating one more narrow chicane, in the middle of the map, inside the oval. The appended pictures show what I mean. Of course it is just rough layout, more/different objects would be needed, but it captures the idea...
OK! Just note that Airio 2.5.7 has K33 without restricted zones in that chicane and changing it now is basically not possible. So maybe K33 could be without the restricted chicane and K34 then the harder, slower alternative? And to make K33 and K34 different in more that one place, maybe another chicane could be planted somewhere else too? Lets say to the middle of the KY2 part, to slow people down... Just an idea though.
Well, the 8 above mentioned tracks are now added and supported in the final version of Airio 2.5.7 available now. The layouts were not changed, except F31(R) or F32(R) (not sure which one), where I moved one of the splits. Concerning K33, I did not change the layout. That means the hard chicane is there, but anyone can remove the objects and still have K33(R). Appended are all the currently supported LYTs.