Hello programmers. There are a few small changes in W20, so you'll need to update your W17 InSim programs.

First, a link to the old thread, for anyone who needs to catch up from an older version that W17 :

http://www.lfsforum.net/showthread.php?t=23372

Next, the incompatible changes :

The biggest change : MSHT times are gone - all times are now in milliseconds
Related : Hours field removed from FIN and RES packets (no longer needed)
Elapsed Time : an extra field in the SPX and LAP packets, now 4 bytes bigger
FIX : ReqI in the keep alive packet was 255 and is now 0 as intended
MSO : Three possible values for the User byte of the MSO packet

Finally a few small compatible changes to the interface :

The /mso command is now simply /o
More informative warning on connecting with the wrong password
More than one UDP connection is supported (all 8 can be UDP or TCP as they wish)

I think that's it, anyway you can find the new InSim.txt in the W20 downloads in the test patch section.

http://www.lfsforum.net/forumdisplay.php?f=66

Did something change in the initialize packet?
After reading the changes and looking at insim.txt i can't see any changes in IS_ISI, but my insim can't connect to a w20 host, it just says "InSim: packet received before ISI packet"

It worked fine with W17 and haven't changed anything at the init.
I'm using UDP.

Uhm...
my insim app is connecting to my lfs "client" (not host), and I want it to send a message only visible to me. This worked perfect in W17, I just sent a MTC to CCID 0 (host). Now I can't ("IS_MTC - only for multiplayer hosts")..
And a MST makes everyone see it (obviously).

How can I do this in W20? Am I missing something here?

Quote from nikka :

How can I do this in W20? Am I missing something here?

MST using the /echo command?

Granted you use 5 characters in doing that, but it works.

Quote from Shizzle :

Did something change in the initialize packet?
After reading the changes and looking at insim.txt i can't see any changes in IS_ISI, but my insim can't connect to a w20 host, it just says "InSim: packet received before ISI packet"

It worked fine with W17 and haven't changed anything at the init.
I'm using UDP.

I just checked and my old IS_ISI packet works fine without any changes, so I don't think your problem is caused by W20.

Thanks for the update Scawen. These changes are great, especially giving all the times as milliseconds, which will make a big difference for me!

Quote from DarkTimes :

I just checked and my old IS_ISI packet works fine without any changes, so I don't think your problem is caused by W20.

are you using UDP too?
well then its just some weird thing.. need to figure it out, thanks for that response

Yup, I checked with UDP and TCP and it works the same on each, with no changes. Of course after that point things start to get a little iffy, so I'll need to spend tomorrow updating all my old packets.

Quote from the_angry_angel :

MST using the /echo command?

Oh.. never heard of /echo..

Quote from the_angry_angel :

Granted you use 5 characters in doing that, but it works.

6.. don't forget the space.
But yes, it works indeed.. sorry bout my noobieness. I'll shutup for a while now

Quote from nikka :

6.. don't forget the space.
But yes, it works indeed.. sorry bout my noobieness. I'll shutup for a while now

I always "forget" the space :doh: Hey, we were all "noobs" at some point, and we're all still learning

Hi,

i have a problem with the NCN and CNL packets.
If i connect with TCP sometimes i receive the packets and sometimes not.
On UPD i receive all packets.

May it's a problem with my application, but i don't know. I attached some logs.

Greetings,
WolleT

I have been trying to figure out this Insim Init problem.
I put W17 in another folder and tried the very same insim program in that, works like a charm, but it won't init neither in W20 nor W21.

When i start insim program, first lfs says "Insim - UDP : OLT-Insim (port x)", which i means it did receive IS_ISI and everything is ok. It got the name and port right from the packet. Password also works and i get "password doesn't match" if i put a wrong password on purpose. So i recon that initialize works.

The problems arise with the following packets, any packet i send after init, result in "Insim : packet received before ISI packet". (in W17 packets go through and work)

It is likely that I'm to blame for the bug, but after hours and hours of head scratching I can't figure it out. If there are no changes in insim prog or LFS, it should work, right? :sppalpati

Quote from WolleT :

Hi,

i have a problem with the NCN and CNL packets.
If i connect with TCP sometimes i receive the packets and sometimes not.
On UPD i receive all packets.

May it's a problem with my application, but i don't know. I attached some logs.

The usual mistake when using TCP, is to assume that you receive one packet, with one call to "recv". That is not the case, because TCP is a "stream" and does not return individual packets. It returns any amount of bytes that were convenient to return at the time. So you can receive more than one packet in your receive buffer, with one call to "recv". You can also receive half a packet, and the other half of the packet can come in your next call to recv. So you need to store what you receive at the end of a buffer, and read from the front of that buffer, when you know you have at least one complete packet.

In short, you are probably receiving a few packets at a time and you are reading only the first one, so that's why you think you have missing packets. Please check the return value of "recv" (how many bytes you received) with the packet lengths.

Quote from Shizzle :

I have been trying to figure out this Insim Init problem.
I put W17 in another folder and tried the very same insim program in that, works like a charm, but it won't init neither in W20 nor W21.

When i start insim program, first lfs says "Insim - UDP : OLT-Insim (port x)", which i means it did receive IS_ISI and everything is ok. It got the name and port right from the packet. Password also works and i get "password doesn't match" if i put a wrong password on purpose. So i recon that initialize works.

The problems arise with the following packets, any packet i send after init, result in "Insim : packet received before ISI packet". (in W17 packets go through and work)

It is likely that I'm to blame for the bug, but after hours and hours of head scratching I can't figure it out. If there are no changes in insim prog or LFS, it should work, right? :sppalpati

I suspect your UDP reply address keeps changing. It's almost as if you are initialising your UDP port every time, so your OS is assigning a new ephemeral port (the reply port in your UDP packets) each time.

The result is LFS thinks your second packet is coming from another InSim program.

There should be only one initialisation of your UDP socket, then I guess a single call to "sendto" each time you send a packet.

Quote from Scawen :

There should be only one initialisation of your UDP socket, then I guess a single call to "sendto" each time you send a packet.

That might be it. I do create a new socket in my send function and then close the socket. It seemed like a quick, simple and working way earlier. I love cutting corners outside the track too. Thanks.

:noob:

I'm currently working on updating my insim tools, and I encountered a problem. I'm trying to get a IS_CPP from LFS by sending a tiny packet as discribed in the InSim.txt with the following values: type = 3, request info = 1, subtype = 6, but I don't get a response package.
If I send a version request tiny packet (values: type: 3, request info = 1, subtype = 1), than I get the IS_VER packet as answer.

I'm using the W21 patch and all packets are transmitted via UDP. In LFS I have started a single player race with 3 laps and the car is standing on the start finish line.

I try to find an error in my code for some time, but I have no clue.
Has anybody a hint, or is it maybe a LFS bug?

Thanks Brilwing. I've looked into the code and tried to test it.

It's definitely an LFS bug, it doesn't send a CPP, it just sends some random data the size of the CPP packet.

I'm sorry about that and I've fixed it in my code.

:d

OK, I don't want to slow down your development so here's a special exe with that quick fix. It's exactly the same as W21 apart from that one fix. Note : you can't unlock with this because it's too much effort to get it on the master server, and most people don't need this. It uses your W21 unlock - just keep your W21 exe in case you need to unlock again.

Thanks, now with W22 it works.
You don't slow my development down, because I'm updating the Java insim libraray JInSim, and there are lots of other things to update and test.

About this no MTC in offline mode thing.

I don't like it. I managed to go around it somehow without needing to redo much. But it reduces max string length to 64-6=58 (needs to use MST with /echo) and basicly cuts short many lines. Especially those where I have used colors become often impossible to make fit. I would need to recalculate how long all lines can possible grow and then if too long maybe split them into 2 lines or restructure them. That is a very big job in my case.

In earlier insim versions server and offline versions could work the same way. Why can't it allow to send MTC with UCID 0 offline? It should work always as there is always #0 connection (host). If there is some good reason could you then consider increasing the max string length from 64 to maybe 80?

So far the insim changes have been good, but this really causes problems for me.

Well... maybe I should just add a new packet, you can send to LFS to output a message on the local computer? It could be up to 128 characters, I guess.

MTC was always supposed to be a host only message, it was just a bug that allowed "host" to mean "the local computer". I'd prefer to add a special packet for this.

Is there any other data that would be useful in that packet, or is it just simply a 128 byte message to be displayed on the local computer screen? And would there be any reason to may that shorter, like 96 or so to reduce bandwidth? Maybe 128 is too much? Let me know your thoughts, if any other options should be added... it's really an easy packet for me to add and doesn't affect anyone's InSim programs so easy in that way too.

Ahh yes that would be very welcome, ah command displaying a message in the chat.
mtc with /echo was really bad an 58 characters (-5 for /echo and one for termination) were too less.
I don´t think 128 characters are too much because you don´t send them so often (I can´t think of).
I wouldn´t need more, but it would be nice to remove the need of the 0 in the very last byte because that was a BIG problem for me in the past and I read of the need in the last week in one of these threads. If you want it and don´t work with counter please document that behaviour.

Quote from Scawen :

Well... maybe I should just add a new packet, you can send to LFS to output a message on the local computer?

Oh yes. Pretty please. With sugar on top.

Quote from Scawen :

Is there any other data that would be useful in that packet, or is it just simply a 128 byte message to be displayed on the local computer screen?

The only option I can think of that might be useful is whether displaying the message should cause lfs to play the system message sound or not (or maybe even the user message sound). If you don't add this option, please make it quiet like the MST /echo is.. (the MTC 0 made this annoying system message sound)

Quote from Scawen :

And would there be any reason to may that shorter, like 96 or so to reduce bandwidth? Maybe 128 is too much?

Doesn't "local computer" usually means "same computer" in non-host insim apps? No bandwith issues there.

Thank you. I would be very happy with the new packet. I cannot think anything else to put into it right now.

The 128 char array is certainly enough. It is usually the driver names with many color changes and char set changes which can make the 64 char array small very fast. It wouldn't be bad if even 80 chars could be used in MTC too. I don't think it would take too much BW as the text packets are not sent constantly.

OK, firstly, I am really loving the new TCP InSim stuff

I am particularly interested in the ISP_REO packet that can be "sent" to LFS to reorder the grid. This will be great for league races!

Unfortunately, it does not seem to work and I think I have done everything right (I have checked and searched already). All I get when I send the packet is:

InSim : unknown packet (36 bytes) - InsimTest

I am initialising the bytes first (from 0 to 35) with 0's and then putting the following in the 36 bytes:

byte(0) = 36
byte(1) = 36
byte(2) = 0
byte(3) = 3 (from a variable)

then a loop to fill in the next three bytes with PLIDs.

I have put the bytes in manually (ie taken out the fact that it could be variable conversion problems even though it works elsewhere).

I am using VB6 and can successfully send ISP_ISI and ISP_VER etc using the same methods etc.

I have tried this on W21 and W22 but nothing earlier. (EDIT: W16 is the same!)

I have also read all the notes with the ISP_REO struct and have put LFS in /start=fixed mode.

Please could someone confirm it is not just me. (I fear it is, so sorry in advance if it is!)

Thanks
Tim

I just changed the packet size to 32 (ie 28 cars) and I don't get the error any more. It doesn't reorder the grid for me, but that may be that I am not doing it at the right time.

The InSim.txt definately says 36 bytes for this struct.

EDIT: Packet size changed (using 32) and then connected to multiplayer host and it works!

Hopefully, this will help you Scawen!

Thanks
Tim