That would be a nice addition. I was planning a pitboard app for on my laptop (which I keep next to me while I race), but such a field would make it very easy and simple.
I also got 2 questions about OutGauge. What is the difference with OG_FULLBEAM and OG_HEADLIGHTS, and shouldn't OG_SIGNAL_L and OG_SIGNAL_R both be enabled when you've pressed 9 (hazard lights on).
LAZY PROGRAMMERS! None of us can do the work if we don't have the information to do it with. The flag packet is needed, we can't really do that by our selfs (Let's keep this with in reason) we could find out if the player has pitted, or is pitting in, ect. But we would have to map out an polygon for each pit entrance, exit, and pit area. It would take far more time that Scawen to wip up an InSim packet for it. I would not say that any one around here is lazy. Their are some things we simply can not do with out some of the insim packets. Please, don't call any of us lazy. I take a real issue with that.
Lap and Node of each car is sent in MCI pack. So you have the position of each driver in the race (Lap * 1000 + Node f.e.). Simply store this information with the time and you can calculate the gap when ever you want to.
No need to add up the times of all driven laps.
In principle you are right. And I agree that Scawen should not waste time by implementing things that we can calculate ourself. And I would calculate absolute time myself if I could but I can't. So an exact explanation only for you:
- to calculate gap times you need absolute times.
- to calculate absolute times you need to add up all past laps.
- to add all past laps you are required to be connected at the start of the race
- if a spectator tool (eg. LfS TV director) connects during the middle of the race, it has missed all past laps and therefore no chance to calculate the absolute time.
Maybe I have missed a differnent way how to do this, but if you know it better, then kindly please tell me instead of just calling me lazy. Also I have not asked Scawen to implement gap calculation. Read my post again and think before you write, but never call me lazy.
you mean the arrival time of the MCI packet? Well, indeed a very exact calculation.
This seems to be a good idea, having thought about it I can't see any problem with allowing 127.0.0.1 to connect without password. It's not a security risk as any program that can connect with that IP, already has access to your hard drive. Are there any other IP addresses than 127.0.0.1 (as you said 127.*) ?
It seems like a reasonable request, it's only an extra 4 bytes in a lap packet. You mean : a number in there : total time since the race started?
I was thinking about the times, MSHT is very wasteful. Should I convert to a simple unsigned "milliseconds" for all the MSHT times? I feel bad for doing this now as it's another change, but if that is to be done, now is better than later... what do you think? MSHT is inefficient, you cannot do maths with it, and it cannot represent times longer than an hour (which can cause bugs in some cases). It is in LAP / SPX / PSF / FIN / RES - and the FIN and RES also have an hours byte that could be removed in that case.
I'm not sure what you mean. You can get the current race time in a SMALL_RTP packet. Hmm, that is in hundredths. Maybe that should be milliseconds as well, I want InSim to be clean and consistent now, and that's why all the changes have been made.
No, Soeren is only asking for the "elapsed race time" at the point when the player passes a lap or split. It seems reasonable and won't cost in bandwidth. LFS of course knows the elapsed time but that isn't send in the packets.
Now is the time to get it right. I don't want to cause an upset by an InSim rewrite in future. This had to be done once now that InSim has "grown up" from just a local camera positioner with a few race tracking packets thrown in. It needed the rewrite, and it's looking a lot better now.
The whole 127.0.0.0 - 127.255.255.255 range is reserved for local loopback (~16 million addresses just for that, and now they complain about running out of free addresses :tilt. 127.0.0.1 is the most commonly used though and that alone would propably be enough.
Thanks Scawen good to know and my post you quote was an answer to Soeren because I don´t think adding the current total time to SPX or LAP is necessary. And yes RTP is what he needs, hadn´t it in mind for this.
time in ms:
I would prefer it because you have a faster access and I also have to convert it to milliseconds sometimes. Convert it back to MSHT is the easier part and you mostly only need it for output, so only one time.
I totally agree with you, putting milliseconds into a double word is sufficient for 49 days until overflow. And we could do maths with it. So if you do not deal with MSHT internally, then change to milliseconds, in other words: as a programmer I would just use, what I use internally and copy it into the packet (for other readers: this is an opinion, not a request). But there might be a lot of insim developers now crying, so the decision is yours.
The person with UCID=0/PLID=2 should get it, but since I send it with PLID=0, LFS should use UCID, which is 0 here. Right? It is really annoying as it happens only 1/100 messages I send and rest work ok. The same message works in most cases but sometimes I get that.
It would be nice if LFS also printed the UCID/PLID values in the error message if it cannot match anybody. Like...
"IS_MTC - could not find destination (UCID=0, PLID=0)"
1) Are you using UDP or TCP?
2) Is the message text filled with zeros all the way to the end of the packet? It should be as LFS probably checks that the end byte is zero.
1) all UDP
2) Hmmm.. nope. It just puts the end zero and leaves rest of it. So it must be full of what ever nonsense there is in the memory. It could explain why it fails so rarely, if the end byte happens to be zero usually.
I try that fix tomorrow...err today (is the clock that much?).
It's just that from the error I got impression it cannot find the connection where to send it. Very hard to confirm if it works after that (if it works). You can test very long but still cannot be sure that it never happens. (=easier to prove if something fails than proving it never fails)
BTW: Is this the case with all the char arrays in insim packets? (except the license plate)
Yes having looked in the code this is definitely the error.
"Could not find destination" was a misleading message, as it just didn't bother to look for the destination after finding the message was invalid. I've fixed that now and changed the message to say "last byte of message must be zero". This is the same in IS_MST and IS_MTC. It's a safety check so your program can't make LFS crash when it does a string copy.
By the way, I plan to make UDP multiple connections acceptable, which will be helpful for people making local computer InSim programs, where UDP should usually be lossless.
To All Programmers :
A note about timing, it will definitely not be released fully this week, there is too much to do still. Patch X release should be around Friday 11 May or a week later on Friday 18 May.
I will do those small InSim changes I've mentioned and give you a hopefully final InSim version this week. But the changes will be small :
Change MSHT times to milliseconds
Add elapsed time to LAP / SPX
Allow >1 UDP connection
127.x.x.x no password required
Small documentation bug
Ah lol had this error many times in older versions of LFS mainly in the debug version of my program.
Never understood it
Those things should been documented
No, I'm just waiting for a couple of days spare to do them. That system isn't so much a "change" but something new added. I've got a lot to do and get tested as quickly as possible, bug sheet to clear, etc. Hopefully there's time after that to do the programmable buttons.
Half of the 127.* range (and also 128.* range) used to be reserved for LAN use, but a few years ago the specification changed to free the range up for use in the future as internet WAN addresses. It will probably be a few more years until they are used though - however, in light of that, I would limit loopback to 127.0.0.1.
The only two remaining LAN addressess I can think of are 10.*.*.* and 192.168.*.*
One issue with no password from 127.* would be shared hosts. Hosts that have multiple instances of LFS running on different ports for reselling purposes specifically. User permissions (should) prevent users from reading each others password but unless each instance of LFS runs in its own chroot jail, they would share the loopback.
According to that document my post is slightly innacurate, to save you the hassle it says 127.0.0.0/8 (or 127.*) should be loopback. I was confused with the 128.* range.
Anarchi-H does raise a valid point for the dedicated host though, local loop back needs to be secure for shared hosters like Franky.
In insim v3 if you typed e.g "/mso test", you would get into insim mso message "/mso test" (well actually another mso with "test" too). In insim v4 you get only mso with "test". This is not really a big problem as you can test that there is no player name before the actual text. But it would be better if the following flag was added...
Maybe a flag could be put into the MSO packet to tell if it came from the 'owner' of the LFS which is running this insim? Or even better if the connection (NCN) had an "IOwnYou" type flag for similar purpose. Or is there some other easy way to tell which connection owns this insim?
(in server use you could assume host is always the 1st connection, but not so in client tool)
Can we clarify the 127.0.0.1 no password situation.
Currently InSim listens on the specified IP or 0.0.0.0, thus what's being proposed is the checking the source IP is 127.0.0.1 and ignoring any password, yes?
I'm not sure this is really a good idea. It's going to cause security problems for hosters (such as myself and many others) that run multiple LFS instances on the same server (IP) under different security contexts for different admins.
If anything it would be better to have a dedicated InSim password IMHO.
I couldnt decide quite where the best place was for this, but..
Is anyone else having "fun" with the SMALL_VTA? Specifically when a vote occurs and goes through, I /appear/ to receive a SMALL_SSG instead Another dumb moment, I suspect?
. 127.0.0.1 is the most commonly used though and that alone would propably be enough.
Another dumb moment, I suspect?