Airio was paid software (it had a pro version at least) and afaik, no source is available for the program itself. It appears to be linked against a custom dll, so I guess no source is available for the library either.

Similarly, the LFS External library has no source available, although that is horribly out of date anyway and people have been having problems with it for years. No idea if that'll work... probably not.

AFAIK, all other publicly available libraries are maintained or at least are open source.

Airio hasn't been maintained for a while. I don't understand why unmaintained, closed source programs should hinder Scawen from making improvements to the InSim protocol. Instead someone should give the program maker a wake-up call. If that doesn't work I would consider the project obsolete.

DarkTimes, why not putting up a compatibility table somewhere mentioning which InSim.NET version and LFS version are compatible?

It's only a warning.. When this gets official there is no way back anymore, I have no idea what people use as InSim programs, this affects both server and client side, it will generate complaining.

I did and do still love Airio - not sure anything else out there can do what it does. However it has indeed been dying gradually for a while, and I've more or less abandoned my original hope that EQ Worry would release the source (or resume maintenance). (In contrast, Aonio, which I also loved, does at least now have a mostly-better rival in the shape of LFSLazy.)

Having said that, I would agree that while we shouldn't be forever bound to preserve backward compatibility, we should only make this change for a good reason.

The other concern I have: LFS is not exactly on the crest of a wave of popularity right now. Break some important-but-unmaintained codes and there may not be the hoped-for flurry of activity to fix the situation...

Considering this is going to be a small track update concerning Rockingham the worst what can happen is that people do not update or downgrade again once they realize their favorite InSims do not work anymore and/or their favorite servers still running 0.6K. It can lead to a split up community. It already is, with this S3<->S2 thing, throw this on top of it and I don't know. I have not a good feeling about it, maybe later when S3 has more content.. But this, now, only for a small difference? Sounds weird.

Quote :

There are a huge number of existing InSim apps that represent many thousands of hours of work by many programmers all over the world. I think that effort spent is valuable and should be protected. This efficiency improvement is small and any benefit should be considered against the loss of all that accumulated work.

I agree yet it seems to become harder and harder to move forward without making braking changes. Unmaintained closed source programs quickly land on the road to perdition anyway. It's a bit of a harsh natural filter.
I doubt unmaintained programs are still popular but maybe I'm wrong. Are there alot of popular "out of date" InSim programs?

Perhaps this breaking change could incite for more breaking changes leading to a new INSIM_VERSION = 7 ?

Couldn't we create a packet sniffer/rely that always outputs IS_MSO / IS_III / IS_ACR as full size so that outdated programs still work?

It is an ugly solution, but avoid the problem of Scawen either breaking compatibility or implementing a dual InSim version with a flag as suggested by someone (was it Cargame?).

Tried 0.6K11 with LFSLapper, and most of the code appears to be working - or at least the code I use works.



Unfortunately, LFSLapper is no longer supported, and hasn't been for couple of years now, and I don't see anyone else taking it on either.

The lapper code that us users script is then compiled/interpreted (?) into proper InSim commands, so for the users we don't need to be able to code.

Which is a shame, as, with Airio broken, it appears to be the only free, customisable InSim available that you don't have to be a programmer to use (I'm excluding LFSLazy as it doesn't do the sort of things you can see on my image).


EDIT: Checked, and there are 24 servers (2 of which are mine) currently online that are running lapper.

Quote from Whiskey :

Couldn't we create a packet sniffer/rely that always outputs IS_MSO / IS_III / IS_ACR as full size so that outdated programs still work?

I had thought that some kind of relay would do the trick - it could even be very simple, as it would only need to bother converting packets with known problems.


Interestingly, both the InSim applications that I maintain seem to be able to handle these shorter packets fine (both are custom implementations written independently by different people, no third party libraries).
At first glance at the code, the CInSim (0.7) library should be able to handle them fine as well.

Quote from sinanju :

Tried 0.6K11 with LFSLapper, and most of the code appears to be working - or at least the code I use works.

You know what MSO and ACR is about? Its about chat messages and admin commands. Airio (currently operating on 146 servers) announces itself thats why it directly goes wrong.

Keep in mind only a few people read this topic. When a patch goes global you talk about ten-thousands.. I think not be able to fall back into old mode with a simple config switch would be a bad decision, Most people don't give anything about bandwidth optimization anyway.

But hey it's not my call, just be not surprised when people don't move on from 0.6K, this update is not of any interest for demo users for example.

.

Thank you for the comments, including the deleted ones.

I agree, it seems bad or sad to break programs that can continue to work. I don't want to act like a company such as Oculus.

I didn't want to add an option bit to allow "reduced text packets" or whatever. It seems a silly option. But I understand this problem may come up in future. Sometimes, including this time, it seems I could simply provide backward compatibility.

So how about a small, compatible, addition to the IS_ISI packet? I could change the Sp0 byte to KnownVersion. If it is 0 (as for existing programs) then LFS will assume that means version 6.

To get any of the new packets you will have to specify version 7 (which I'll set as INSIM_VERSION).

So that would mean the old programs should continue to work, for now. I can attempt to retain backward compatibility in future using that number, as long as it doesn't become a burden.

I could write a long story but to summarize; sounds excellent!

Definitely a good idea.

OK, I've done that.

I plan to release an update this evening and it would be great if any of you can check it works with older InSim programs if that is easy.

Quote from Scawen :

OK, I've done that.

I plan to release an update this evening and it would be great if any of you can check it works with older InSim programs if that is easy.

Scawen, could you take a look at this suggestion? It looks quite easy to implement from my side, would like to know your opinion hehe
https://www.lfs.net/forum/thread/89019

I think it may be the right time to implement it, now that we are having a new InSim version.

Scawen, you should add debug print to dcon which prints actual content of that spare byte in IS_ISI, in case some of old insim programs have some uninitiated garbage there instead of 0

K12 is now available : https://www.lfs.net/forum/thread/88999

Changes from 0.6K11 to 0.6K12 :

InSim :

INSIM_VERSION increased to 7 to support new incompatible packets
Backward compatibility system - send INSIM_VERSION in the IS_ISI
Added TINY_ALC and SMALL_ALC to get and set allowed cars

Misc :

No longer stored in message history : /press /ctrl /shift /alt

Fixes :

FF was not initialised when "Input when window is inactive" was set

Quote from Whiskey :

Scawen, could you take a look at this suggestion? It looks quite easy to implement from my side, would like to know your opinion hehe
https://www.lfs.net/forum/thread/89019

It looks interesting and I've added it to my notes along with the related checkpoint suggestion.

Quote from vitaly_m :

Scawen, you should add debug print to dcon which prints actual content of that spare byte in IS_ISI, in case some of old insim programs have some uninitiated garbage there instead of 0

Good idea and K12 does display the version if it not 7.

NOTE : It is important for InSim programs to fill Zero and Spare bytes with zero!

Perfect!

K12 runs Airio in old InSimVer 0 mode while PRISM now connects in InSimVer 7 mode and successfully handling JRR operations. Only thing I didn't test yet is BFN array removal.

One side note; it came to my attention that K11 client can connect to K12 server without getting 'different game code' message. Not sure if someone can get confused by this. Maybe it is intended.

---
Now it's interesting to understand why Airio thinks I am online 6-8 times with 6 FXO and or 7 FXO and 1x XRT... Hhmm, strange stuff.

Thank you for the test.

I can't think of a reason why Airio would think you are on multiple times. I've checked the code in LFS where it sends IS_NPL and don't see any change there (if join requests are not enabled - and they are not enabled with version 6). It should be compatible.

You can receive another IS_NPL if you are already in the race but that was always the case. Subsequent NPL for the same player use the same PLID (if he has not spectated) so the external program knows you are leaving the pits rather than joining.

I don't know if you have any time for a boring test but maybe you could try reproducing it by entering / leaving pits and also spectating. If you get the Airio bug, you could try the same with a public version and see if the same sequence of joins results in the same bug.

Yes.. Well.. I never seen this before;


7 times /spec versus 6 ... So something adds more entries to the array and one gets cleared after CNL ... I have some time to figure this out now, lets see what I can find.. This is abnormal behavior.

---

OK, it's of course handy to just analyze the logs where it went wrong. And it went wrong on the point where I putted some AI on the grid to test out the new clear button on the lobby screen. I totally forgot about those 5 minutes I tried this.

But thats the reason why I get this, three AI joining the grid spectating again and I did that one more run. Creates 6.. Didnt press go, I played with several grid move buttons and that + button. After that I pressed clear, actually two times because like I said I let AI join two times 3... So the grid was empty again; I joined the grid on my own and started a race session without any other AI member.

So long story short, its because of AI.

I have one complaint concerning IS_JRR. When you teleported a car (on a grid for example) the car is moving because the handbrake is not on. This is a problem. Cars spawned on a grid before a race shouldn't move at all.

Am I the only one bothered by this? Scawen, can it easily be turned on by default?

Quote from sicotange :

I have one complaint concerning IS_JRR. When you teleported a car (on a grid for example) the car is moving because the handbrake is not on. This is a problem. Cars spawned on a grid before a race shouldn't move at all.

Am I the only one bothered by this? Scawen, can it easily be turned on by default?

That's a fair point, actually.

OFF-TOPIC:

Thanks to IS_JRR you can easily teleport AI cars. Would it make sense to lift the open config restriction ("AI can't drive on this configuration" message)? In this case the AI car would be spawned with handbrake on and engine turned off.

AI cant drive on open config because it has no path which it can follow.