Thankyou... I know that it is plain text...
But what is the field "#1"? Is the number server that Airio is connected? And the codes as "C52P01, C25P31, C50P45"? Is the code assigned to players? What is his meaning?
In LFS each instance which have connected to a server, has an individual connection-ID and an individual player-ID. But one connection can have more than one player-ID associated to the connection.
For example: If you connect to a LFS-Server than you get one connection-ID. If you join to the track, you get the first player-ID. If you add a bot to the track, this bot get your connection-ID and get an individual player-ID. The next bot you added, get another player-ID but also your connection-ID.
The connection-ID's and the player-ID's are handled dynamicaly in LFS. That means: the range of connection-ID's and player-ID's are each within 0 and 255. Connection-ID zero, and if i remember right, the player-ID zero ist reserved for the host (the LFS-Server) himself.
For more info, refer to the Insim-documentation (called insim.txt), normaly shipped with your LFS-Instance.
What is reported by Airio, is the combination of used connection and player-ID (C50P45 Connection-ID 50 / Player-ID 45), from my point of view.
But remember: The connection- and player-ID doesn't say anything about how many connections or players are in actualy use!
Hm, interesting idea. But you should realize the system log is sort of internal file very handy for discovering bugs and also for admins to see in retrospect different actions of some drivers. Into the file various server events and Airio actions are recorded. While there is a general structure to info presented (see below), I'm basically sending there what I consider of general interest and also what is necessary for some debugging. This means the items can change - not by much, sure, but there may be changes over time, although mostly new additions. All items have this format:
On some lines the C, P, and name is not applicable, so it is not stored. Some other lines omit even server number, because they apply to whole instance. I believe the descriptions are short but sufficient, anyone interested in the system log should not have troubles reading it and understanding the sequence of events. It gives nice insight. Hope this helps.
Very right in all respects. On dedicated servers the host is connection 0 and player 0.
On another note, Airio 2.3.3 beta 3 is available solving some issues with LFSW host data used on Airio servers page and also adding BName item into CFG files allowing to define permanently banned usernames. This list may be made external using IncludeFile option.
I hope this is good news for jvalley and others: Airio 2.3.3 is released, because no bug reports from testers were coming for some days now. This update is already sent to Franky of 500servers, hopefully it will be available soon. EDIT: It is already, good work!
The final version reverts some additions from beta 2 and beta 3. It removes from Airio host info reading using LFSW. On second thought it is much more logical to read the data just once a minute on the Airio website and apply them on server page. Also the CFG option to hide hidden servers is removed, servers not found on LFSW list are now always marked as hidden, no configuraton necessary.
Ah, just a while ago I discovered a serious bug in the ASP.NET code gathering and displaying global Airio usage stats. It is corrected now and I believe this will significantly improve the servers page availability...
Here´s a new suggestions, don´t know if it possible to code...
I´ve noticed some "grid-cheating" in the last days... Told by some trusty drivers but very hard to get proofed in the logs...
This is how it works:
Do a few laps on TBO (or any faster class) to "earn" the pole. Then, when the grid is sorted out (all cars on track, start lights not on), switch from TBO to STD (or any slower class)...of course you´re still on pole, because that´s the method lfs is doing it for ages (grid fills up from start to end)...
Is it possible to add some cmd to avoid this..? It should not be possible to switch cars when the grid is already sorted out...
Let´s say add some "rejoin-timer" like the 12 seconds in lfs...
Drivers who pit when the grid is sorted out (lights on) should not take part of the race...just my 2 cents
Eh, people can be very inventive when searching for some kind of advantage for themselves. Well, I guess it would be possible to prevent car type switching when pitting after sorting the grid. I'll look into this and try to come up with some simple solution soon.
Aaah, good one! Thanks! It is indeed a bug, not very serious, but still a bug. Fortunately easy to solve, I'll be updating the FREE version in a few minutes, FULL version a bit later tonight.
Generally Airio catches all internal errors, stores them into its log and continues in processing. But there should be NO errors reported, so I'm grateful for reporting all such ocurrences - best way is just as VoiD did, together with pertinent part of the Airio log.
lol... have the same errors since days and always though it was because I ran Airio remotely on Storm servers to connect to our servers at 500server (because I have no rights to upload exe files at 500Servers)...
Hi Highway and thanks for the reports. The first one is actually some kind of bug. Even after detailed check of the code I'm still not sure how it could happen. But to be sure it doesn't repeat I added there range conditions.
The 2nd one is intended behavior. I added these messages to fight some clicked button issues appearing sporadically. For now they're always stored, I'll remove them soon. The strange thing is why there is 13 clicks on the same button within 2 seconds... Hmmm... Maybe holding down the button? Must check...
Yes, as i write before: It's not a great thing. In the first moment, i thought you have overlooked something, and i want only to notice you that there is someting curious in the logs.
Next courios thing i have found in the logs: I'm wondering about the following issue.
These are the last lines of a log from 2009/08/21. The log contains nearly 100% of loglines from 2009/08/21, but the log is labeled as Airio.log.2009.08.22.txt
No a great thing, but this results in "missing" logfiles in the history. That means: I have a logfile from 2009/08/18, 2009/08/20 and 2009/08/22. But no one from the 19. and 21. of August, if a follow the filenames. But there is a logfile for the 19. - only saved in the file labeled for the 20. In other words: there are gaps in labeling the logfiles.
It's a little bit confusing.
Maybe you can correct this - only for a perfect Airio.
Well, althought it does not directly influence function of the system, I consider it as a not-quite-small bug. It is corrected now, no logs in FREE version should be lost anymore. All corrected bugs are included in the latest 2.3.3 release available on the download page. And thanks for such reports - you experience something strange, just let me know. Correction usually is not complicated, sometimes discovering the issue is the hardest part.