About the speedcheck-filter:

After catching our first victim we adjusted the filter...

AllowedSplitTime=9850

Quote from Okram :

I make TimeAdjustment for UFB, FX2, XR2 and FZ2. based on CTRA best lap time and WR time in LFS. I'm not sure, is this correct. ...

Wow, nice numbers, Okram! One thing baffles me though: In your calculations the FZ2 time adjustments are around 10 percent. But what restriction was used on CTRA? I know that with 20 percent intake air restriction the FZR -> FZ2 time adjustmets are 5 or 6 percent, not 10%.

Quote from michele0676 :

If i use:
LapsPoints=0
All peoples take point?

LapsPoints defines how many laps (in percents) must people complete in race comparing to winner to get some points for the race. If you use 0, then even people completing just 1 lap may get points. Default setting is 80 meaning that to get points for a race for 5 laps you need to complete at least 4 laps.

Quote from michele0676 :

There is a simple "way" to use ONLY the intake restriction with Airio ? Without Airio is impossible force the restriction, right ?

I'm not quite sure what you mean... Without InSim (such as Airio) you cannot force people to use certain restriction, except by displaying restrictions (F11, I think), listing (TAB) through people and telling everyone what they should do.

Quote from VoiD :

After catching our first victim we adjusted the filter...

Yes, oval racing is known to breach the "possible lap/split/sector time" quite often, due to heavy drafting. However, by default the time-check filter does not run (see CheckTime in SRV file), it is just ready as a means to fight speed hacks, if some appear.

Two possible solutions: Do not run the time check on the server, or use lower possible split/sector times, just as you did. However, even with allowed time of 98 percent of WR there's a strong risk someone would be kicked. So I'd suggest to turn off the filter completely.

Quote from EQ Worry :

...Yes, oval racing is known to breach the "possible lap/split/sector time" quite often, due to heavy drafting. However, by default the time-check filter does not run (see CheckTime in SRV file), it is just ready as a means to fight speed hacks, if some appear...

KY1 on Race Center...? Are you serious?? ...it was on KY2R.

Quote from EQ Worry :

Two possible solutions: Do not run the time check on the server, or use lower possible split/sector times, just as you did. However, even with allowed time of 98 percent of WR there's a strong risk someone would be kicked. So I'd suggest to turn off the filter completely.

The filter is very handy to kick some retards pushed by a mate from behind for a whole lap...
There is/was a ridiculous pb @ AS3/XRG (RB4 pushed XRG) and another @ BL1R/XFG (RB4 pushed XFG).
With time check the problem is solved! We can check the log and both will be perma-banned...easy as making p*ssholes in snow!

Quote from VoiD :

KY1 on Race Center...? Are you serious?? ...it was on KY2R.

OMG, so sorry. It was a bit surprising though. I didn't read the link properly, there was just a mention about oval...

Quote from VoiD :

The filter is very handy to kick some retards pushed by a mate from behind for a whole lap...

Ah, that's good, nice usage! I know other people use the time filter to disallow drafting even with oval races... I guess also the maximum allowed speed filter can be used for that.

Quote from EQ Worry :

...I guess also the maximum allowed speed filter can be used for that.

Yeah, but then you have to tweak it for every combo... I´m too lazy for this!

IMO reading logs is easier too. The pushed car gets the kick and the pusher must be close behind. Using "my logic" it must be the car after the kicked one...

:bump:|kick

Quote from VoiD :

IMO reading logs is easier too. The pushed car gets the kick and the pusher must be close behind. Using "my logic" it must be the car after the kicked one...

Yes, good logic. It may be worth to check a few previous splits as well to see if the slower (XFG) and faster (RB4) cars were one right after another. I believe Airio system log is not as hard to comprehend and it really allows you to look back in time and deduce many things.

Hi!

I discovered a problem rotating several BL3 layouts with Airio:

I set up the rotation like this:


I also set the races to rotate to 4. But if I type !tr I only see this:

"Races after the track was loaded: 5, Next track: BL3_layout2/5/MRT".
The text "Races after track was loaded" grows and grows and grows...but a rotation does not happen - I have to end the race manually!

At "normal" rotation I see : "Races after the track was loaded: 5/6, Next.....".

Any idea what I am doing wrong?

I also discovered that PBs are deleted if I we return to a layout we raced before

Quote from Crady :

I discovered a problem rotating several BL3 layouts with Airio: ... I also set the races to rotate to 4. But if I type !tr I only see this: "Races after the track was loaded: 5, Next track: BL3_layout2/5/MRT".
The text "Races after track was loaded" grows and grows and grows...but a rotation does not happen - I have to end the race manually!

Aaaahhh, right. After some testing the cause is clear - wrong string case handling. I did a small update fixing this and also the same max speed reported 4 times in layouts...

Quote from Crady :

I also discovered that PBs are deleted if I we return to a layout we raced before

Oh? I really hope that would not be the case, because when I was checking this last time it was working OK. Also I tried this on your server and it seemed OK to me, my stats were correctly reported and saved.

Quote :

Oh? I really hope that would not be the case, because when I was checking this last time it was working OK. Also I tried this on your server and it seemed OK to me, my stats were correctly reported and saved.

Hmm... strange... I did a quite good lap at one of the layouts, then we changed the layout by ending the session. We did some other layouts and when we came back all PBs were gone...

Well OK... as we raced this layout the first time I just loaded it in SHIFT+U menu from my home computer. Later we uploaded several layouts via FTP and I created the track rotation.. maybe this was the problem.

Quote from Crady :

Well OK... as we raced this layout the first time I just loaded it in SHIFT+U menu from my home computer. Later we uploaded several layouts via FTP and I created the track rotation.. maybe this was the problem.

I'm not sure, but maybe layouts loaded from client behave differently, maybe only layouts stored on host and loaded from there are reported by server as Airio expects. You can always type !track and see if Airio sees a layout loaded. In that case it will start to store stats for this new "track"...

Quote from EQ Worry :

Wow, nice numbers, Okram! One thing baffles me though: In your calculations the FZ2 time adjustments are around 10 percent. But what restriction was used on CTRA? I know that with 20 percent intake air restriction the FZR -> FZ2 time adjustmets are 5 or 6 percent, not 10%.

In CTRA was:
FXR-GT2 - 32% Intake Air Restriction
FZR-GT2 - 28% Intake Air Restriction
XRR-GT2 - 34% Intake Air Restriction
FJR-Formula Junior (FO8) - added mass 70kg and 20% Intake Air Restriction
UF-BR (UFR) - 45% Intake Air Restriction

Added FJR Formula Junior TimeAdjustment. Now is all data in this post and here

Layouts again...

Well as Airio admin I can list and load layouts.

But I don´t see a command to save a layout... Normally as Server admin I can load a layout from my home computer and it is available for all users at this moment. I also can use the /axsave command to save a layout on the server.

Would it somehow be possible to create a !axs command for Airio enabling to save layouts? Else we always need an server admin to upload new layouts...

I also would like to view the list of available layouts as buttons (!axi command). We have 6 layouts atm and listing them as chat does not work because of the 64bit limit...

I wouldn't think Airio would be able to do that.

Quote from Crady :

We have 6 layouts atm and listing them as chat does not work because of the 64bit limit...

mine works fine...

Quote :

/axlist bl3
:fun, themaze, speedcross, pitofdespair, jturnalley
:hardcross_extreme_section_2, hardcross_extreme, hardcross
:figuratively, daredeviloval, bustersprint2, bunnyhop
:allpoints

Quote from Okram :

In CTRA was:
FZR-GT2 - 28% Intake Air Restriction

Ah, that explains the different time adjustments. Note that Airio by default uses different GT2 cars restrictions, lower ones. Anyone is free though to change those as needed and create completely new custom cars. And good job, Okram, with the calculations.

Quote from Crady :

But I don´t see a command to save a layout... Would it somehow be possible to create a !axs command for Airio enabling to save layouts?

Done, !axs command is implemented, requiring one parametr, name of the layout.

Quote from J@tko :

I wouldn't think Airio would be able to do that.

Quote from Crady :

I also would like to view the list of available layouts as buttons (!axi command). We have 6 layouts atm and listing them as chat does not work because of the 64bit limit...

Well, actually there was a little bug in the !axi command output, cutting 1st line and completely hiding others. Corrected now. Output still goes to chat, but it is complete, uncut.

nice

Hi EQ Worry,

first of all thank you for the software you developed "Airio"!

A request. Is it possible to reduce the frequency of software updates. The frequencie (round about all 3 to 5 days) with which new versions are created by you. There is always a lot of effort for implementation.

In particular, when multiple servers must be updated.

I would suggest the build greater releases as a summary of minor releases. That would, from my point of view, considerably reduce the effort.
Especially when so many changes are done in the configuration files, and partially must be undone as in the past occured several times.

No complaints - only a suggestion ;-)

Regards,

Highway

My Website

Otherwise another suggestion.

U could define when a release is "stable".

For example if 2.3.1 is a stable (no bug) versione then when u launch the 2.3.2 u explain if it's only an improve version with new functions.
Or not ?

Or what if you had a stable version, say 2.30, with its config settings set in stone. Then for all the little updates, until the next stable release, lets say 2.40, airio would read the 2.30 config file, and also the update configs.

So when you install airio 2.35 for example, it would read cfg.txt (same as in 2.30) then also read cfg.35.txt, which could have default values on install of the updated airio. This way, us server operators would not have to change anything at all, unless we wanted to use the new features.

Is it possible with the current version to disable yellow-flag-rating-counts for BL1R...?

I was fiddling with

Track=BL1R
RateStability=100000000 (high value to "disable" yellow flag counts)

in AIRIO.tcd-file, but that didn´t work...

Quote from GmiRacing :

Hi EQ Worry, first of all thank you for the software you developed "Airio"!

Hi! You're welcome. Thanks for using this tool!

Quote from GmiRacing :

A request. Is it possible to reduce the frequency of software updates. The frequencie (round about all 3 to 5 days) with which new versions are created by you. There is always a lot of effort for implementation. In particular, when multiple servers must be updated.

Hm, I realize there's been too many updates recently. So many it may be tiresome to be up-to-date constantly. But you know, I'm receiving requests for features and bug reports, and when I add something substantial or asked for, naturally I try to make the new things available immediatelly. Some people are always waiting for them. Then occasionally some bug reports start to come back and always ideas for improvements and a new cycle starts.

Recently (I mean last 12 updates or so) the config changes were always minor, usually some items added, rarely some moved to another file or removed completely. All these config updates can be done in 5 minutes, you just need a file comparison tool and compare your current config with new default config, which will show you nicely what new items are there and where.

I am myself updating configs of 2 server groups and I'm always done in 5 minutes or so. Download current used configs, open CFG, TCD and SRV files one by one in PSPad, compare the files with new defaults in Airio achive, copy new items to old configs, save, upload, reload. It really takes just a few minutes, including EXE and PDB files update. If you have several servers under one Airio, you are updating CFG and TCD files just once, also SRV, only sometimes copying new items into SRV.X files is you require different setup on a certain server.

Now if you run multiple Airio instances, then of course the effort multiplies. In that case consider if it would not be better to combine the servers under one or two instances, updating will be much faster then.

I personally do not see any advantage in having one BIG new release say once a month, instead of 4 smaller ones every week. If you'd prefer that, just ignore some 3 smaller releases and make a jump say from 2.2.8 to 2.3.2 once a month. The faster releases allow me to quickly solve all discovered troubles, correct some inconsistencies, implement small improvements and such.

Consider my very current situation: Some people asked for possibility to penalize/spectate drivers for cutting pit exit lines. So, in order to make this available I implemented a new feature reading proper racing path from PTH files (supplied by LFS developers). Then I added routines checking if the car is on the racing path. If not, a PB done in that lap may be ignored, because it was achieved by some cutting. In my view, pretty cool feature.

With additional definition it is possible to make sure cars return from pits to racing path in proper places as shown by pit exit lines. Also nice and requested. Knowing racing path also allows to let people idle when off the path, e.g. when struggling in gravel to get back to track. Also usable.

Using PTH data also some additional info can be output using !track command – exact length, path width, height changes. Some people suggested !grid command showing expected restart grid when custom sorting is used. So I added this including data usable for checking why the grid looks that way. Someone else requested a command mimicking Lapper's !topqual. So I added this as well.

With all the above and some fixes I think this makes a nice new release. I see no point in delaying this release for another 3 weeks just not to be so active. If you do not care about that features, ignore the release, wait for features or fixes that are important or interesting to you. Then do the update, changelog always mentioned all thing fixed, changed. If you like the features and want to test them, then you need to update some files. But really, it takes just 5 minutes.

Quote from michele0676 :

U could define when a release is "stable". For example if 2.3.1 is a stable (no bug) versione then when u launch the 2.3.2 u explain if it's only an improve version with new functions.

Well, the intrinsic problem is new releases fix old bugs, but introduce new things as well, that may contain new bugs, so then comes next release with fixes, but also new features and there we go... I tried to make 2.3.1 and upcoming 2.3.2 as fixes-only, but see where it ended. I guess my forward momentum is too strong, but when I have a request and I see the way to go, I'm trying to implement it.

Quote from jasonmatthews :

Or what if you had a stable version, say 2.30, with its config settings set in stone. Then for all the little updates, until the next stable release, lets say 2.40, airio would read the 2.30 config file, and also the update configs. So when you install airio 2.35 for example, it would read cfg.txt (same as in 2.30) then also read cfg.35.txt, which could have default values on install of the updated airio. This way, us server operators would not have to change anything at all, unless we wanted to use the new features.

Problem is there are really no special stable versions. Every release is in my eyes stable, or I would not make it available to everyone. There may appear bugs, of course, as in every software, but such may be contained in any version, regardless for how long it has a "stable" mark.

I'm not sure I understand the config files idea. There's one thing I could do, I guess, and that is to make special Airio.cfg.xxx.txt and Airio.srv.xxx.txt files where xxx is current version number. These files will contain all new config items and you may copy them into current configs or include them using IncludeFile directive.

Personally I wouldn't use the files as includes, because it time you can have several config files with items spread more or less randomly, but it may be an improvement for some. Update can be done fast, consolidation left for some other time.

One more note: When doing regular updates it is sufficient to replace EXE and PDB files, Airio will then use its default settings (usually reasonable) for any items not found in config files. Currently any 2.2.x -> 2.3.x update should be done by comparing config files. With versions 2.1.x and earlier basically complete reconfiguration using new files is necessary, there's been substantial changes in their structure...

Quote from VoiD :

Is it possible with the current version to disable yellow-flag-rating-counts for BL1R...?

No, that is not possible. The rating settings are server-specific, not track/car specific.

Bad news (for some), good news (for others): Airio 2.3.2 is released. All updates are summarized in the changelog, but here's a few interesting things:

• Added support for path data (supplied by LFS developers). Proper racing path can be checked now (with definable allowances), proper entry from pits (on some tracks) and also idling outside the track may be allowed.
  
• 14 common spectate reasons are now shown also in big buttons. Their default messages can be detailed using custom localizable texts. Good for providing e.g. additional info on tyres required, how to make better online PB or what car class to start with.
  
• Added !grid command displaying expected restart grid (incl. data used for sorting). Added !rsb and !rtb commands showing PBs only of registered people (similar to Lapper's !topqual).
  
• There are three additional personalization options (allowing among other things to turn on/off the much hated "You have caused yellow flag" message).

Looking at the changelog some may be scared by the number of added items, especially into SRV file. But note that 14 of them are textual items grouped into one new block. So the config files update really isn't complicated. Hopefully.

Enjoy or ignore.

Something I noticed in an older version that we are still running, and I;m not sure that it has been previously reported so may still exist.

The total time is shown in one of the buttons at the top of the screen, however when this passes 1hr it goes wrong.

The first lap completed after 1hr appears to be correct, eg 59.30.25 + 2.19.23 = 1.01.49 (hundredths dropped from display)
Subsequent laps are added incorrectly, eg 1.01.49 + 2.19.30 = 3.20.79 (should be 1.04.09)

As I said, I noticed it in an old version, but thought it worth mentioning in case it has slipped through the net.

Added !grid command displaying expected restart grid (incl. data used for sorting). Added !rsb and !rtb commands showing PBs only of registered people (similar to Lapper's !topqual).

Oh Eq, i love u !

Personally I get more excited about the PTH-support.

But still no mail from Worry.