This not directly related to InSim, but driver can't see RCM while being shown yellow/blue flag? Blue flag can be on for long time, so basically there's no guarantee that message will be seen?
In a normal race you get 30s penalty for a false start, but in autox race you get 1min penalty. I think they should be the same (30s?).
Also in autox false start you don't get IS_PEN, which is bad in my case. But on the other hand there is currently no 1min penalty
defined in PENALTY_... enum, so you would need to either add a 1 min penalty in the enum or change the penalty to 30s (better?).
New InSim is so good that I just had to finally start coding. So far everything I have tried works as InSim.txt says, no bugs encountered. Had a little idea though.
How about making interval of LFS sending keepalive TINY_NONE customizable? Perhaps max (and default) 30 sec as it is now, min 1 sec, set with small packet if needed. Lazy me would like this a lot. This way InSim client could have timing without any extra effort, just with packet reading loop. I think it makes sense if "master" program provides timer for "slaves", no?
Edit: well, I guess it's silly suggestion, caused only by my lazyness... Have implemented nice timer myself now.
I can confirm that it now works as expected. However, I now have another question about this IS_REO feature. When I connect InSim directly to the server, it works. When I connect InSim to a client connected to the server (logged in as admin) it does not work.
Is this by design?
EDIT: using W24 host and W24 client. By "does not work", I mean, nothing happens, no errors no nothing including no packets back from LFS.
I'm not sure what kind of timing you would need, but network packets are not an accurate way of measuring time because of the latency involved...?
I would just like to say a thank you to good old dictionary.com
From what I can see Insim development seems to have reached a pretty stable level now so I will be sinking myself into the new CTRA system this week, i'm just curious as to the latest prediction on a live date so I can figure out how long i've got (and therefore what features to implement)?
Mostly though, i'm just making this post to say thank you for the updates . Oh, and to mention how long it took to figure out what the hell ephemeral meant!
I was originally intending to get X out on Friday 25th.
But we want it to be on the new servers, due to the increased bandwidth due to website visiting and downloading as always with a new patch and the new skins system must be well supported, but Victor's having some issues at the moment with the new boxes, hopefully to be resolved in a reasonable amount of time. Not only that but some of the remaining bugs I've been solving, like SPR OOS bugs and other weird bugs, sometimes take nearly a day each to figure out and fix - quite boring work but it's got to be done.
So the current plan is for patch X to be released on 1st of June, that will give me enough time to get it properly stable and for the community to give it a good test and hopefully our website will be fully moved by then and running on our new hardware.
Thank you. 2 questions:
1) Is the new message echo command there which replaces the MST with /echo?
2) What about the question I posted last time (quoted below). Is the IS_PEN sent in that version in autox false start too? At least it doesn't seem like a big thing to do.
No, it's not in there yet. I will make a post here when I add something to InSim.
Your other comment is also on my notes to look at it. I can't answer without setting aside a little time to look into it.
I don't really need reminding, I haven't forgotten anything and I'm working as fast as I can.
And sorry, I didn't mean to hurry you. I just wasn't sure if you had noticed the last point. And if you had noticed, I didn't know if they are coming in X.
OK - in my version the MSL (MSg Local) is done, allowing up to 127 chars and a sound effect if you want.
About the autocross penalty - it does not use any of the race penalty code - autocross penalties are time based only, so that's why there is no IS_PEN.
What is it you really need to know? Are you saying that you need some kind of autocross penalty notification? At the moment I think you know if there is a penalty, because there is a difference between lap time and total time. But you don't know if they hit 30 objects or they got a false start. And if you do need a notification, what do you need, only the false start and maybe the wrong route / illegal area things? Or each cone that is hit as well? I think each cone would be a bit excessive as the driver could really spam insim by hitting every cone.
Well I suppose I will add a special notification of wrong route / illegal area or false start in autocross.
InSim programs now should be able to ignore any unknown packets (this wasn't possible with the old tracking system) so it should be fine to add new packets and this won't cause any imcompatibility issues.
There were actually 2 points in this. 1) The 1min penalty might be bit excessive as in normal race you get only 30s (this is not insim related but point 2 is). 2) You do not get IS_PEN (or any other packet).
Ok, I was thinking that false start is the same even if you make it in autocross.
So where do I need IS_PEN for a false start? There are events (stage rally) where autox layouts are used, but penalty from cones etc is not counted. But clearly false start is such thing that you have to count that. My app reduces the penalty from cones (if set that penalty doesn't count), but should not reduce the false start penalty. This wasn't issue before as you couldn't make a false start but now... And currently I cannot catch these false starts in autox, only in a normal race.
To put it in a nut shell... I want only a way to catch a false start in autox too (IS_PEN or some other). I personally don't care about individual cone penalties (at least currently) or illegal areas, but I guess some people could find use for them too.
Since we are now in the subject... In the race result packet it would nice to have a separate time for the included penalty (eg. unsigned PTime). Like you said the penalty time is the difference between total time and best lap for 1 lap autox race. For multiple lap races I have to sum all the lap times together and compare that for the total time. Not a big job, but it would be easier.
MST ignore the '\n'-character, will MSL do the same? (will save some bandwith when you want to print many short lines if you can just send one MSL with \n in it)
And uhm, not sure if you have confirmed this (yes I did search), but will the programmable buttons be in X already?
And uhm (crap, stop the uhm'ing and behave like a grownup nikka!), I had a crazy idea.. how bout making separate text input boxes for /i and /o messages, you know, simular to the 't' input box? For example, you press.. uhm (doh!) 'i', a text input box appears, and the message you enter is sent to insim as a III.. and same for MSO_O ('o' or something) (maybe these text input boxes should be default disabled and have to be enabled via insim to stop confusing people if they hit the wrong key when they wanna type a message and writes it in the wrong text box).
Maybe this will just cause a lot of confusion. I dunno. Just a thought.
And speaking of IS_III, W24's insim.txt have a typo... I guess IS_III's Type should be ISP_III, not ISP_MSO (the comment).
Hmm... I ment autox races. Suppose I have 2 sec penalty for hitting cones, how can I see that I have 2 sec penalty included in the end time with those?
I don't mean to be pushy, but I get the feeling that you missed my last post (quoted above). If you did notice it - then I am really sorry, but I don't want to keep coding this the way I am doing if it is not going to work.
Sorry, yes I did read your post and was going to get back to it after thinking a bit. But an unreasonable time has passed with no reply from me.
IS_REO is host only, yes. It would be a bit dangerous to allow guests to do this... and if they could it would be admins only. And if admins can do it then there is a possibilty of conflict with the host. I couldn't see any reason for a guest to send an IS_REO so that's why it's host side only (all race reordering has always been host controlled).
But what is the reason for allowing guests to do it? I think it would be quite easy to allow admins to reorder the race, if there is a good reason and if no-one thinks of any problems with it.
Phew, I am glad you understand my reasons for re-posting.
The reason I ask for this is because I am writing a race control app which will be used for the hosts that watch and manage league races. By the term "host" I mean a guest connecting to the server with admin rights who then just spectates the entire race and ensures that rules etc are followed. In our league, the "hosts" are not hosts in the LFS sense of the word, they are guests who log on with admin rights. (I hope this makes sense so far).
Currently, re-ordering a race to start in the correct order is done by everyone joining in the correct order. The IS_REO function would simplify this immensly and streamline the hosting process.
I would be perfectly happy for an admin to be able to re-order the race, but I can see that there could be issues if there were multiple admins all trying to re-order the race at the same time. Perhaps only the first admin to connect could do the re-ordering or the admin with the lowest UCID only.
If not, then I will have to get the hosts to know the IP address of the server they are "hosting" and connect as the proper host.
I think that is enough uses of the word host now!
Can anyone else think of any issues this may cause?
In fact re-ordering the grid is currently a problem for league management.
Immagine qualifying system based on hotlaps or simply doing quals in a different day from race.
I think the simple solution of having admins able to reorder the grid would be good enough. If you (league manager) fear multiple admins causing trouble, just make sure only the "correct" admin (the "host") has the admin password for that race.