Yes, these are button ID collisions. If you have similar "tabulated" output and then other buttons appear (timings, pitboard), some data may disappear. I'll try to optimize button ID usage, but it is a lengthy and risky operation...
I'm getting spectated for "Required LFS experience index to join : 200 [0.00]", the cause seems to be if I change the nickname before joining the race, I still had my league name on, changed to troy and then it spectated me all the time with the above message. The whole thing was on ironhorse but I think the problem is airio.
The problem does not concern nicknames, it happens when there's a broken communication with LFS World or airio.eu site. It was a known weak point in Airio 2.3.9 (what IHR uses) - if LFSEI cannot be received, certain setting could make racing impossible. Try !exr (experience refresh), wait a few seconds for EI update. This weak point is diminished in Airio 2.4.0 because it remembers your last LFSEI locally and uses it by default until it gets update.
Currently an alternative solution could be used, maybe. Defining some benevolent time lock (WR + 5% or even a bit more) and applying the lock only during race using LockOnlyRace=true. After race anyone can join, in race only people with good enough time.
Another option requiring small update would be to define e.g. AllowUnlock item with specifiable limad level for which lock is ignored. Hm, but that's not exactly what you need. Rather needed would be some item ignoring race rejoins...
Not quite a bug, in fact an intended behavior, so a feature, I guess. Missing textual EI descriptions in this case mean the index was not updated, last locally known number is used instead.
I recycled airio.eu application pool, I think it works again. It seems once number of people's data held in memory reach over 2500 the Web application/script stops responding. I'll try limiting people held in memory to 1000 best, to see if it helps.
It's also an 'award' for correctly blue flagging. A time lock isn't and I notice that still a lot of racers don't understand how Airio InSim works. If it gets too complicated, people give up.
Now you lost me there. What do you mean by "award for blue flags" and what is the complicated features that make people give up their attempts at something?
Have no money...I would just only need the class system and points to need for earning new class...Becuase we have planned about 20 different classes with 38 different cars. But now I just do something else.
People have to wait till race finishes but if someone showed proper blue flag handling I want to award those racers with the capability to always mid join a race.
Racers who have set a good PB doesn't necessarily have to be good in proper blue flag handling.
Lets make it short, locking a server on PB timing is deadly. I know it works on demo but that is just demo. Can't compare that with the real thing.
Too many cars, too many tracks. I want to promote that people try all cars, not prevent it.
Sorry, I still do not understand what is proper blue flag handling and how it could possibly be connected with race rejoins? By proper handling you mean the flagged drivers should be pitting/spectating? Well, in my view that would be a very weird definition.
Proper handling, I think, means let pass easily at the closest suitable place and be predictable, show clear intention of letting go and the side to take. But then there's no relation to race rejoins...
OMG, we should delete the last six posts at least, because it was pure confusion. Now I get what you meant, you were just explaining how a feature that we already agreed on could be used - by manually selecting people with unlimited rejoin capability...
As it is coded now, no, it is not possible to raise/report blue flag earlier. Theoretically it could be done, e.g. based on lap/node difference, but I'm not sure how well it could work...
Hm, right, actually the data where nationality (if specified) is shown are already downloaded in PROS version, so it is just a question of assigning them to people. The slight problem is the countries are written in full name, not ISO codes (which I would prefer), but maybe the name could fit into e.g. !pls output. I'll try...
Missing textual EI descriptions in this case mean the index was not updated, last locally known number is used instead.
