InSim libraries will need some serious updates with version 5. Thanks for the admin commands stuff, I already feel safer. Hopefully I could test it toning, to see e.g. what "set if user is an admin" actually means, if this byte just uses 0 and 1...
Scawen, I have one incompatibility issue, sorry to bother you again. Almost all the new packet types (layout/hit/contact) are optional, requested on InSim connect. The only exception is the ISP_ACR admin command packet, which is always sent. Unfortunately the library I use is detecting it as bad packet type, assuming communication error, leading to disconnect. Maybe a short-sighted assumption, but it worked very well for 2.5 years.
Of course I updated the library and I will think how to make it better future-proof, but all the current Airio versions will cease to function properly after server update to 0.6, which will happen soon, I guess. So, please, is there any chance to make the ISP_ACR packet also optional, that must be required during InSim connect? It would help help a lot now. Thanks for reading.
PS: I guess the demo/tweaked/private bits of server state did not make it to your intended features list?
No... InSim is specifically designed so that you can continue to read without knowing all packet types. I will not make all new packets optional.
Any programmers out there, please read this post I made on the other thread. Very important in case your code doesn't handle the rare but very real situation of split packets.
I wonder if this could be one of the last-minute small updates for the official patch. I promise, this is the last time I mention it, also I have no more ideas/requests (well, for this patch at least).
Now I remember a long-existing thing, the "unknown car id" displayed sometimes. I wonder if that could be related to the fact that often cars are send to /spec right after pitting (Shift+P) by InSim apps, e.g. to prevent repeated midrace rejoins from pits. Maybe a small lag would cause some LFS pitting routine to be delayed for so long that when it runs the car is not in the pits anymore, but spectating? Just an idea though.
If I see correctly, HLV has no speed, only CON and OBH have it. And, maybe I am too tired, but what use would be the actual speed? The closing speed describes impact severity, which seems to be the perfect measure of contacts with other cars and objects.
These were on my list for a while, but there were a few ways of doing it and I couldn't decide the best way. Some of these flags are stored in different ways. In the end, I came to a point where I couldn't do any more after this 3 months push. I'm tired. Also, in the few days before an official patch I can't take any chances. So... sorry, the flags and demo status are not there for 0.6B.
I thought that was fixed. Though my memory is a bit vague at this point. I thought it was worked out and sorted out. Have you seen that error coming up in any of the recent test patches?
Thanks for getting back to the matter. I understand, it was required too late and it's not as easy as it may seem. It would be great though to keep it as a future feature. The tweaked bit could be used to e.g. disable lap time storing (maybe also for LFSW). Demo bit would allow easy detection of demo-compatible host setup, which is now impossible (or at least complicated). One final thing missing is a report of currently allowed cars on host, many people find it strange this important info is not in fact available. Also, reporting things as vote, midrace join, car reset, etc. only on race starts is not ideal, I think, it all should be part of server state info state (with cars, demo, ...), sent on every change. Just my feeling though.
I'm afraid I did not have as much time to be on patched servers, also rarely some such server got full enough. Last thing I remember was you mentioning that you're not sure why this message appears. Now I believe it happens only after pitting, when the car is quickly sent to spectate by an InSim. Just a feeling though.
Thanks again for all the InSim updates, some look really promising and some make me (and other server admins, I hope) feel safer. But I'm afraid the real hard test will start only when official patch is out and the current applications are extended to apply the new principles. Problems may appear then, when there are thousands of actions taking place. But so far everything looks good to me.
Final note, thanks for mentioning the split packet problem. (A friend of mine also mentioned the opposite may happen, two LFS InSim packets arriving combined.) While my library handled the 2nd case correctly, the 1st was actually not handled at all. Fortunately the code update was not too complicated, if anyone's interested, I could post the few lines of (supposedly correct) split/joined packet handling C# code here for review/discussion.
Sorry, forgot about the thread because I've been quite busy this weekend. Lets check it
I think Scawen wrote something about invalid packet sizes before. Shouldn't they be ignored if not dividable by 4? In my code (which is slightly different) I added this check:
byte[] buff = new byte[256]; // number of bytes read stored in bts int bts = tcp.Receive(buff, 1, SocketFlags.None); // InSim packet length stored in buff[0] if (bts == 0) { return new byte[0]; } // disconnect [COLOR="Red"]if (buff[0] % 4 != 0) { return new byte[0]; } // disconnect (invalid packet size)[/COLOR] while (buff[0] > bts) // read from TCP until packet length bts += tcp.Receive(buff, bts, buff[0] - bts, SocketFlags.None); // read only one packet Array.Resize(ref buff, bts); return buff;
Thanks for the admin commands stuff, I already feel safer. 
Hopefully I could test it toning, to see e.g. what "set if user is an admin" actually means, if this byte just uses 0 and 1...
