Man, surely that's worth mentioning! Stupid me, I never thought of races with total time longer than 1 hour. Well, to say the truth I cannot imagine how the behaviour you describe could be possible, but certainly hours will be cut from display. Latest compile (still called 2.3.2) contains a fix.
You asked about 5 times for the past month so there it is. Sorry for the delay!
PTH support needed some after-release updates to be more reliable/usable, that's why the delay. Mail to FULL version users (and to Franky of 500servers) will follow shortly (minutes) after this post.
The initial 2.3.2 release had some small deficiencies. I did a quick update, meanwhile adding one more feature, the possibility to check correct pitlane entry, not only pitlane exit. Ah, also incorrect entry/exit can be now penalized as you wish. To get the new things, just download 2.3.2 again...
Yes, you are right in this point. The changes in the configuration files normaly can be done in a few minutes, not five, but in a few minutes.
But this is only on thing whats to do. (From my point of view).
There a a lot more to do if you are operate these systems on servers which are integrated in other systems. Believe me, i know what i'm talking about. And: Yes i know about the handling with a diff tool ;-)
Be sure, we have done so.
That's the point, for me. It looks like that you are more interested in implementation of features, making sense or not, than of bugfixing. This will maybe results in a little bit of confusion (losing the red line) or in a quality problem of the software.
I'm missing the strait concept of development as it was present at the beginning.
For me it would be more interesting to have a good documentation, what happens exactly by changing parameter x,y,z. Also it should be possible do download it, let's say as PDF-document.
I'm missing a concept overview maybe as a roadmap.
I'm missing a change log as text-file in your updates.
I'm missing a bug tracking system, so that bugs and feature requests can be easy tracked.
And i'm missing some more things, but these are from minor importance. ;-)
Don't understand me wrong. In my opinion, your lapper is the best i have seen in the past! And this should remain. ;-)
Yes, i know about this. But i mean a manual in PDF-Format which is a little bit more informative what happens, for example, when i find messages in the log-file like this:
09.07.30 11:10:17 AIRIO WARNING : Global stats not sent... 09.07.30 11:11:07 Global stats sending recovered...
I think that a changelog is also a part of the software as the software itself. It makes it easyer to manage versions and so on.
But it's only some suggestions by me. Nothing more.
LFS is an online racing simulator and Airio is an online tool for this online Racing simulator.
So why is there a problem with an online changelog and online manual???
If you need a PDF then install a free PDF printer and print the Airio website as PDF.
Ok the manual is not up to date atm but the changelog says enough in my point of view.
And believe me: I updated enough Airio versions (the common ones and a lot of test version before the next release became public). It never took me more than 5 minutes... And Airio itself was offline for about 10 seconds while updating the exe and pdb.
So I really can´t follow your way of discussion!
I see a straight line: implementing useful requests as fast as possible, testing, bugfixing, testing and bugfixing... Finally releasing the next version.
This is no Microsoft Windows that is full of bugs and takes years until the next version is released.
Oh? Sorry, this is a bit surprising view for me, for several reasons:
1) All recently implemented features make sense, there's always someone using them to full extent. What I'm strugling with are some principles introduced at the beginning, such as the total/champ data.
2) If there's a bug found (either by me or reported), I usually correct it at once. That is also partly the reason for so many updates. And the most important - currenty known bugs: NONE. Bugfixing is my primary task, I hate any kind of bug, however small.
3) The red line is to offer as complete and as flexible admin/driver system as reasonably possible, all that without scripting, just through described configuration items.
Uhm. About 18 months ago when I started developing Airio from scratch, I was just experimenting, having fun trying to add this and that, all hard-coded. Then suddenly it was possible to use the tool on AirAttack servers and I was adding more things. There was never any plan where it should go.
Some 12 months ago it was clear external configuration is needed, even if used just one one site. Then common stats, localization, all this was coming suddenly, as suggestions for improvements. When I wanted to make Airio public, because I thought it could be used also elsewhere, I had to add more customization options and change internal arrangements.
All this was done intuitively, based on experience of what is good and usable. When Airio went public some 6 months ago, many deficiencies were pointed out, many requests made, some bugs reported. All this was processed and today Airio is, in my opinion, pretty complex system, yet very stable and reliable, while still admin and user friendly.
The concept is to go forward this way... I'm no development manager having milestones set and a plan to follow. I'm just an amateur programmer having fun introducing new concepts at a time when serious LFS developemet has to a large extent (sadly) stopped completely.
Yes, documentation is my weakest point. It is in version 2.1, but the 20 intermediate releases changed many things. Problem is updating or rewriting docs takes so much time and is so boring. It is much easier to keep good changelog and reasonable decriptions in configuration files. But of course I want to update documentation. One day...
While it may seem as easy thing to add changelog into every new release, it is always some additional work, requiring synchronization with hard-to-update results. I really prefer the online version.
As mentioned above, there are currently no known/reported bugs. Concerning accepted requests there is the TODO list at the end of the changelog page. It tries to show the order in which things may be implemented in the future, but it is very inaccurate at times.
Well, I'm trying to keep it that way, both the FREE and the FULL version. Also this is expressed in the number of updates, with each one also adding some extensive new/original things. But I guess I can see your point, to a certain extent. I think it could be summarized like this: FFS, stop this update madness, give it some time to settle, to show what's good and what's bad. OK, I'll try to do that, but you know, I'm driven... like the snow... pure in heart... driven together... and driven apart. (Anyone recognizes this one?)
Ouch, come on Crady, this was a bit like a blow below the belt. True, I prefer to call Airio a tracker, but we all know what we're talking about.
If you drive an outlap (out of the pits) you get a message saying:
"Invalid personal stats from this lap were not saved" (line 256)... I think this text is quite confusing... So I changed the text to "This was not a complete lap"...
This should be better in my mind.
There also is a text: "KICKED FOR SECURITY" (line 182)... well should be "KICKED FOR SAFETY" in this case...
There are a lot of texts in the German translation that are too long for the 64bit limit. So I had to change some of them in to a sorter version.
Perhaps there is a way for Airio calculating the length of a chat output and separate them 2 lines if needed like this:
You are doing this with available layouts (!axi) too atm which works good.
If Airio gives me a Drive Trough because of cutting the pit exit, I am not able to remove this penalty.
As soon as I remove it, I get an other penalty for not "Drive-through penalty not executed properly"... I think I should be able to remove any penalty.
You're right, this message causes some confusion, I will change it a bit. Note that you may turn off this message for yourself (just as the yellow flag announcement) by deselecting Private data personal option (in 2.3.2+).
I don't think you're right here. It is indeed kick for security, because impossible speed could be achieved by hacking. So kick is for security, spectate would be for safety, but i'm not sure if there should be admin option to choose between the two, because this filter doesn't fire as much.
Right, thanks! I'll go through the language file and if nothing of 2.3 is missing, I'll make it available in language pack and complete distribution.
Well, I was trying to evade this solution, for quite some time now. Of course splitting the message is possible, but I felt translators should try to use short items that fit into one line, because otherwise this may increase spamming.
But by many people this LFS limitation is seen as Airio defect, so I've given up. Into 2.3.3 I've implemented global message (such as speed, split, spec) splitting in case it cannot fit into one line. This is of course language-dependent, so some people may see one line while oher will have two, if they have that info display selected at all...
Aaaah, you're right, that is a bug! I'll try to provide the solution ASAP. Thanks for reporting this, it is a side effect of one added feature.
EDIT: The solution was simple, the Airio 2.3.2 archive now contains updated EXE and PDB files and clearing the DT penalty should be possible without side effects.
The pitline thingie does not work properly, at least for us...
Tested it on severall tracks (apart from BL1R, because of its bugs) and it´s always the same. We tried different settings with the offtrack-parameter but that unfortunately didn't work out.
Maybe its possible for you to widen up the whole thing by adding 2-3meters, like some sort of offpath-parameter for the pitlines...?
Suggestion: adding "PitPathDelay" ...don´t know if thats possible, just noticed "RacePathDelay" in the changelog.
Another weird thing is that you get a penalty when you "pass" the line at the outside of the track, e.g to give some extra room for the cars on track...
Attached some pics, done with FXO with less than 25Km/h...
Right, I guess this is a result of some misunderstanding. Pitlane exit/entry check works in conjunction with entering/leaving proper racing path as defined by LFS developers and as seen e.g. in Remote (the Track option there).
On some tracks the on/off path info can be used to improve pit exit/entry practice. But it is not a perfect solution, because sometimes the racing path intersects with pit lines (blend lines, called by some). So what you need to find is the earliest track node where a car can enter racing path when exiting pits or leave the racing path when entering pits.
This is not the same as driving to the end of pitlines, the check can be used to prevent pitlanes cutting only to some extent, depending on specific track. For example on BL1 the pit lines end exactly on the racing path, the check runs ideally there. On AS2 the racing path crosses drawn pitlines in about half of their length, the rest cannot be enforced by this relatively simple check.
The good news is that proper node settings can be made just once. Crady has created initial settings. (Thanks a lot!) They are not all tested thoroughly but they should be good for default track layouts. Add the contents of the appended file somewhere to the end of TCD file and then try some heavy, medium and none cutting on pit entry/exit. Just note that bad pit entry warning appears only after you actually enter the pitlane, not immediatelly.
Ehm? I'm not sure what you mean, pitlane entry/exit penalties are always just question on entering/leaving proper race path.
Hmm... VoID and me had a test session yesterday and we came to the conclusion that the pit exit and entry check only works good at a few tracks... (BL1, KY1, KY2)
At all other tracks the painted pit exit/entry line crosses the normal race path. So we need to set the last/first pit node that early/late that it makes no real sense because nobody would enter/exit the pits that early/late.
So I was thinking and thinking what could be done...
And the only solution coming into my mind is that there should be 2 checks. First you have to pass the last pit node coming out of the pits, but then you also have to pass a defined area on the track located exactly at the end of the painted pit exit line (coordinates like the restricted areas).
But then there also must be a check if the car passes a node just behind this area. So you could prevent cars crossing the line without passing the defined area. Or cars that just stop or go slow after passing the last pit node.
Entering the pits should be a bit easier: Check if the car passes the defined area, check if it passes the first offPath node and if it enters the pits then.
Well I am no programmer, but it sounds quite complicated for me and might be a lot of work for all Admins too to define all these nodes and areas...
This comment is so true for many of us. Even though something a great there is always a way to make it better. When making it better comes issues and are always fixable.. There is never is finished product for some. And some just get bored like me and have to achieve and challenge.
Anyway.. EQ if you need help updating the manual let me know. I will attempt the task and also I was thinking a quick reference guide- that may help some of the new hosts diving into this great product. Willing to try to make that also.. Let me know, its the least I can do to help..
EQ Worry i report a bug.
In command !topqual in first page i have 20 ppls and they are the ppls that i specified in srv files but if i switch in second page ... airio display all the ppls that had some lap in server.
But if i use !topqual 20 or !topqual 40 airio works fine.
@ VoiD & Crady : You're right about limited usability of the current pit entry/exit check, it works good only on some tracks. For a perfect check support for some polygon the shape of pit lines would be necessary plus the first/last node. Possible? Yes. Hard to implement? Not really. Hard to configure? Quite, but only once. I guess I will put this on my TODO list, overall it could be a nice touch.
@ jvalley : Man, thanks for your kind offer. I'm afraid I will have to update docs myself, but any attempt to make a quick reference guide is most welcome!
@ michele : Of course you're right, my bad, I forgot about the option to use Previous and Following buttons. I did minor correction, it should be OK now. Please download again the 2.3.2 archive, check the EXE has today's timestamp, and overwrite the old EXE/PDB file. Test and let me know if it is behaving correctly. Thanks!
Aaahhh, grrr, you cannot. Can you wait say a week for 2.3.3 then? I could ask Franky to update the update , but this is really minor thing... I'd like to wait a few more days for any bug reports or smaller feature requests and then make 2.3.3 a "stable" release, as it was required by some...
Well there are a few things I would like to see in the !tr display:
- the current amount of laps to be driven at the current track
- mustpit on/off
(I know both of them are only reported at race start - but if you use FULL track rotation you could take these values from there?? )
- A complete list of the current track rotation would be nice... Then you can see which track is coming next, after the next and so on...
An other thing is that I would like to have a command like !now to just print the current date/time into the chat. Then you shortly can check the time while racing without having to click to remove the !ver buttons.
A variable to print out date/time to use in custom text, race start message, custom command would be nice too
Then you could create a welcome text like:
Hello! Welcome at our server. The server time is ..... Race clean and have much fun!
Or you could create a race start text like
Race start at <Date/time> @ <track> have fun and drive clear!
oh... then I would need a track variable too...
Some calculations would be nice to for the !event command:
I Was hoping you could help with small issue. I'm having trouble importing Lapper's PB.txt file into Airio. Typing the command !imp and !exp just logs the command in the log file, but nothing further. The automated export WILL work (ExportLapperData=true). I've also tried to import the airio created pb.txt (by automated export), but this didn't work.
Other admin commands all work, like !state, !reload, !players, !recent, !aini etc. I've tried changing "ClearLapperData= " to both true and false. I've issued the command from the console and from an admin user. I've tried setting up a new server on a new machine and it didn't work there either.
Attached is the log from a clean install. I'd appreciate any ideas.
Well, to say the truth I cannot imagine how the behaviour you describe could be possible, but certainly hours will be cut from display. Latest compile (still called 2.3.2) contains a fix.
You asked about 5 times for the past month so there it is. Sorry for the delay! 
It is much easier to keep good changelog and reasonable decriptions in configuration files. But of course I want to update documentation. One day...
(Anyone recognizes this one?)
