Hmmm, I must ask Failure to send me the log and check closer what kind of trouble this was. Basically "improper DT" means you've spent in the pitlane surprisingly short time, something less than 5 seconds. It is there to prevent nasty DT cheating possible most notably on BL2. Maybe it could misfire in situations when there's a lag while entering pitlane, or the lane entry packet is lost somehow, and the pitlane is also very short. I'll check and try to correct this...

Four weeks ago I noticed this weird behaviour on LR|#1 too... Track was FE1.
After crossing the pitout-line Airio instantly gave another DT...for nothing. No speeding, car was on racepath, no crossing pitlines...
Noticed this in the race before and checked myself (see attached mpr)

Another bug report (v. 2.3.3l) I´m pretty sure it was caused by lag...

Please take a closer look at deacon1985. As a rookie he tried several times to join the race (bl1) with an untrimmed FXO, of course he was sent to spec everytime. He received an auto-kick for repeated tries.

After track changed to so4r he managed it somehow to join the race.

At 12:33:17 AIRIO sent him to spec, but he was still on grid as the race started...

Four weeks ago I noticed this weird behaviour on LR|#1 too... Track was FE1. After crossing the pitout-line Airio instantly gave another DT...for nothing.

Eh, yes, it looks like FE1/2 pitlane is really short, and if there's a small delay when entering pitlane (and that is very often), the exit follows less then 6 seconds later and it is seen as DT cheating. New code limits the check to BL2 only as it is probably the only track where DT cheat can be done to unfair advantage.

Another bug report (v. 2.3.3l) I´m pretty sure it was caused by lag... Please take a closer look at deacon1985. As a rookie he tried several times to join the race (bl1) with an untrimmed FXO, of course he was sent to spec everytime. He received an auto-kick for repeated tries. After track changed to so4r he managed it somehow to join the race. At 12:33:17 AIRIO sent him to spec, but he was still on grid as the race started...

I guess you're right. Certaily the /spec command to send him off the track was issued (maybe you can check this in server log?), unfortunately LFS server ignored that command. It happens sporadically, especially with /restart and /end commands. For these two I added special timers checking if the command was actually carried out, repeating it several times if necessary.

Up till now I've never seen /spec command being ignored, but obviously it may happen. A solution would be to check some 5 seconds later whether the driver was really specced (or kicked, I guess /kick could be also ignored), repeating the command several times to be sure the required action is carried out. Eh...

Data offered by InSim contain no information about IPs of connections. The FULL version of Airio can listen to changes in server log files (if server directory is correctly specified in Airio config), grab IP addresses from there and assign them to connections. Currently only checking for doubled IPs (and kicking for that) is supported.

Earlier people asked me if banning by IP would be possible. Well, yes, to a certain extent and with some limitations. First, the listening mechanism is not guaranteed to always capture the correct address. I'd say it would work in 99 percents of connections, but when actions align badly it may fail.

Also many different people use one privider and are seen as using one IP. Banning by IP may hit many people that just happen to use the same provider as some stupid crasher. A possible solution would be to ban IP e.g. for just one hour, so that the crasher cannot connect back immediatelly with different username, but others are not excluded for too long.

All in all, FULL version of Airio can capture IP addresses. The usage is currently limited though due to other considerations. Still, the possibilities to display IPs and do more actions based on IPs are open, adding such things would not be too complicated.

What´s this? ... I guess PID means PlayerID. So I checked the whole log but the two PID´s appeared to be unique...

Basically, warning say some state or condition was not expected, but it is nothing serious. In this case people disconnected without first leaving the race. This was caused by the fact they disconnection from lobby after end race was called. Airio expects that all disconnecting people have PID (player ID, yes) equal to zero. This was not the case, that's why the warning. I did a small update in Airio code, replacing /clear command carries out on race end by !sall, spectating all people. Some testing would be necessary though to see it is OK...

Strange in your output is this line:

09.09.12 12:10:45 #1 This command needs a parameter

It would be good to see what LFS command it was and then see why it had no parameter (see server log, optionally turn on server logging to capture all / commands into Airio log for easier debugging). My guess is this was /track= command. Note that there's no message about track being loaded in your output. People waited for some 30 seconds, nothing happened, and they disconnected.

This means a character code was not found in internal LFS <-> Unicode conversion tables. You may ignore these warnings. In time I want to fully support conversion of LFS character codes to Unicode and back (!), including Asian charsets, but it is a tricky matter...

I think it was correct. A driver pitted, remained in pits. Yet Airio specced him like he was still on track, which was not correct. The driver would see only a little change, Join button would turn to OK. (And if midrace join is disabled, he would not be able to join.) I hope I corrected this behavior now.

Something weird seems to be happening. Racers are reporting if they win the race or place in the top couple they get spectated during restart countdown or directly after they finish. I have not seen it but its coming from a few more racers now. Here is a log of a time it happened. Look at Joku123

As for spectating on next race start (if you use reversed grid, it could be the last winner that is spectated), it is connected with "limit overcome" feature. 12th on grid is spectated if there are 13 or more connections. If then 2 or 3 cars join at approximately the same moment, then it is possible to have 13 or even 14 cars on track even in demo. A little bug in 2.3.3 caused the spectate to always happen, regardless of LimitOvercome setting. It is corrected now for some time.

The idling check always runs only during race. I cannot believe someone was spectated for idling after race, I see no way that could happen (but I can be blind of course). Very rarely someone could be spectated during race while he is driving. This is mostly the case when for some (unknown to me) reason the server does not see the driver moving. His arrow is not moving in the little map, his car stays in pits in Remote, yet the driver says he was moving, leaving pits. But no one can se him, not even Airio, so he gets spectated after a while. This is very exceptional condition, but I can't do anything about it.

First, when having some people in the NDR server, when the combo was on an autocross, it would spectate drivers for idling on track, even though they were clearly moving. Has this been brought up to you before or is this due to the fact that there are no pth files ? It gets annoying to get the warning when you're quite clearly to the human eye moving on track.

Second, I was attempting to set our track roation to do timed races, but I was thinking it was something like SO1|-15 for 15 minutes, but that didn't work. What is the correct format for that ?

First, when having some people in the NDR server, when the combo was on an autocross, it would spectate drivers for idling on track, even though they were clearly moving.

Heh, no doubt that looks very stupid, sorry! If I remember correctly there was this idling bug on tracks with 0 nodes (such as AU1 or BL3) in a very early release of 2.3.3, but I think the compile available now already solves it. If you can, please try downloading 2.3.3 again and see if the problem is still there. Also I plan to release 2.3.4 today, so maybe you can wait a few hours and get the latest... Also there's always the option to disable idling check (in SRV, CheckIdling).

Second, I was attempting to set our track roation to do timed races, but I was thinking it was something like SO1|-15 for 15 minutes, but that didn't work. What is the correct format for that ?

The format of track rotation is track|cars|time, you can omit time (laps) or also cars, but not just cars. So the entry track|time is not recognized, try putting also cars in the middle, then it should work...

Heh, no doubt that looks very stupid, sorry! If I remember correctly there was this idling bug on tracks with 0 nodes (such as AU1 or BL3) in a very early release of 2.3.3, but I think the compile available now already solves it. If you can, please try downloading 2.3.3 again and see if the problem is still there. Also I plan to release 2.3.4 today, so maybe you can wait a few hours and get the latest... Also there's always the option to disable idling check (in SRV, CheckIdling).

The format of track rotation is track|cars|time, you can omit time (laps) or also cars, but not just cars. So the entry track|time is not recognized, try putting also cars in the middle, then it should work...

I can wait till 2.3.4 comes out and gets up on 500servers. I did a clean reinstall of 2.3.3 on there late last night, so all the old crap I had was gone, but I can live with a temporary fix I have (max time between splits, crude, but should work until overnight).

And dangnabbit, fix the documentation then ! Funnily though, even with just track and laps, it IS still rotating, even though it apparent'y shouldn't.

But well... just to give you some more work I had some brainstorming yesterday...

To prepare an event it would be handy to be able to turn on/off the RName lock bye time - just as it works with the "normal" lock too. So I could prepare the event settings a day before and activate them automatically - or could this be done bye a scheduled command?

Using and LFS-Admin Slot would require the admin pass. Couldn´t this be done by Airio too? Checking new connecting guest if they are a at a decent limad level, and if there are no more slots left then the guest would be kicked for "server is full"

Ok, and there is one question I have - had not time to test it yet:

If I lock the server by the RName, are limads able to drive too, or are only RName listed guys are allowed? (Limad is set to "allow join") If I lock a currently running server by RName, will currently racing but not listed guys be speced or does Airio only check if someone wants to join the race?

Hmmm, I must ask Failure to send me the log and check closer what kind of trouble this was. Basically "improper DT" means you've spent in the pitlane surprisingly short time, something less than 5 seconds. It is there to prevent nasty DT cheating possible most notably on BL2. Maybe it could misfire in situations when there's a lag while entering pitlane, or the lane entry packet is lost somehow, and the pitlane is also very short. I'll check and try to correct this...

To prepare an event it would be handy to be able to turn on/off the RName lock by time - just as it works with the "normal" lock too. So I could prepare the event settings a day before and activate them automatically - or could this be done by a scheduled command?

What you basically need is to manipulate with LimitToRegistered item in SRV file. There are several ways you can do that: Using !cfg command manually for temporary change. You may also put such command into a SET file together with other settings required for an event and call all at once using !si x. Scheduled commands (in FULL version) will also work, both !cfg and !si. Just beware that doing !rld reverts server settings back to defined defaults, erasing all changes done by !cfg commands.

Using and LFS-Admin Slot would require the admin pass. Couldn´t this be done by Airio too? Checking new connecting guest if they are a at a decent limad level, and if there are no more slots left then the guest would be kicked for "server is full"

Interesting idea, surely. Also possible, I think, but requiring two, maybe three new items in SRV file. And also two new messages, one saying privately to the additional connection being kicked why this action was taken, one announcing the reason (optionally) to everyone else on server. Question is what can be done about repeated connects, I guess nothing. Banning anyone for trying to connect to a server with slots limited by limad level is not an option. So in the end you may see MANY kicks from virtually full host, which could become tiresome for everyone connected and trying to connect.

Connecting people will have no way to know if they will not be kicked suddenly, which may lead to desparation, later to hatred (no doubt towards the stupid tool that's kicking them for stupid reasons). So I'm kind of reluctant to implement this feature, I see it as too limiting and not exactly transparent. So, maybe not so interesting idea after all.

If I lock the server by the RName, are limads able to drive too, or are only RName listed guys are allowed? (Limad is set to "allow join") If I lock a currently running server by RName, will currently racing but not listed guys be speced or does Airio only check if someone wants to join the race?

Limads will be able to race if they have level at least equal to AllowJoining in CFG file (or higher). With sufficient level the following joining checks are skipped for them: registered names, time lock, repeated joining, licence level, rank level, safety level. Defined intake/mass restrictions and prohibited cars are always applied to everyone, no exceptions.

Preferential race join to certain number of people with best session times, e.g. !sa 24.

Server and LFSW lap times overview commands, !pbs and !prs.

Possible spectate for car reset in race, while free reset is allowed in practice/qual.

Almost every new version brings some new issues, caused by the fact not all situations and configuratings can be fully tested. I'll be grateful for any strange behaviour descriptions and obvious bug reports. Enjoy.