Just one other request actually Scawen, if I may.

The new /i command is brilliant, but because i'm using it for PM's and channels (live on STCC2b already! - i'm such an addict) I end up having to get people to type two headers...

/i talk user message

It would be great if I could abbreviate this to $talk user message

Is it possible that the config file could specify a non-echo prefix, like:

/noecho=$

would make any message starting with $ non-echoed?

It would make the whole system a little less cumbersome for my end users if that is possible

Thank you.

Will "shifter type" and "clutch type" fields be added in patch X, since the whole InSim system is being redone, or will that be added later? I know that several of us are looking forward to this, and thought now might be the time to do it since you're revamping.

Quote from MoHaX :

If you remove PlyNum field, how is it possible to get start order of players?

Good question. Normally it comes from the REO packet, but that is only on a restart, I think, when it is actually reordered, not when you first come in from the entry screen. I think the solution is for LFS to send a REO on every race start, even if no reordering takes place.

Quote from Cue-Ball :

Will "shifter type" and "clutch type" fields be added in patch X, since the whole InSim system is being redone, or will that be added later? I know that several of us are looking forward to this, and thought now might be the time to do it since you're revamping.

That was already added to the player flags in W9.

Quote from Scawen :

That was already added to the player flags in W9.

How the heck did I miss that?

Great to hear! Looks like now I have to get off my butt and work on that league I've been talking about so long. Thanks! :bowdown:

OK, here is the first test of the new InSim which uses a unique identifier UCID for connections (still different from the player unique identifier PLID). This allows many of the packets to be more compact, and you don't need to track things through the User Name. Your programs will work on LAN and Demo as well as online S1 / S2 - and that helps tsting and development.

This rewrite is designed to be suitable for TCP packets (needing a size byte at the start of every packet). Currently it only works on UDP, because I haven't got to the TCP listen and send yet - but if you update your programs to use this new version, then when the TCP is done you'll only need to change your connect, send and receive functions. This current converted version should do all the old version could do, but without the acknowledgment packets and guaranteed delivery system. That is scrapped now, we'll use TCP for guaranteed delivery.

By the way, I've also just changed it so the IS_REO is sent at the start of every race. It specifies the order every time, regardless of whether it was re-ordered or not.

DOWNLOAD : EXE and DEDI (to be used in an already patch W10 folder)
[ EDIT : link to W11 removed, as W12 is now available ]
http://www.lfsforum.net/showthread.php?p=400729#post400729

NOTE 1 : This is 100% compatible with W10 and there are NO OTHER CHANGES - so don't get this unless you are testing InSim.

NOTE 2 : The InSim buttons and response functions have not been done yet, although they are a large part of the inspiration for the move to TCP.

NOTE 3 : ISPackets.txt is attached, this includes all documentation and is actually a C++ header file (.h) renamed to .txt so I could attach it. Please read with a TAB size of 4.

NOTE 4 : This is mainly untested though I did connect with a test program and start sending a few packets, so I know that it does basically work, I just can't say for sure that all packets are working 100%.

GOOD LUCK And let me know about any problems you have come across.

@Scawen, how far away are we from the TCP version please?

I'm going to try and quickly do it this morning before I have my day off.
Should be ok, it's mostly a bit of cut and paste from some other code.
I'll need to do it in my test program as well so give me a few hours.

Quote from Scawen :

I'm going to try and quickly do it this morning before I have my day off.
Should be ok, it's mostly a bit of cut and paste from some other code.
I'll need to do it in my test program as well so give me a few hours.

Your a machine! New insim looks great - Can't wait to see what people can do with it.

hehe Scawen, I know those days off only too well. I had one Friday, was trying to get home and the boss was phoning me! Then I spent all night coding my LFS Private Messaging system, and woke up Saturday morning and did the channels... I took yesterday off whilst you updated insim

All right, done and briefly tested, here is the version which can accept TCP.

It's the same as yesterday's version except that it allows you to connect using TCP. It obviously replies to you on that same socket using TCP, if you connect via TCP. The Port member of the IS_ISI (InSimInit) packet is ignored in that case (unless you start OutGauge or OutSim). I plan to allow NLP and MCI to be sent over UDP even if you connect via TCP - but that is not implemented yet, in this version they'll come over whatever protocol you connected with, just like all the other packets.

[ EDIT : link to W12 removed, as W13 is now available ]
http://www.lfsforum.net/showthread.php?p=401002#post401002

For anyone who is not familiar with TCP programming, or have not used it to receive "packets" before, please remember it is a STREAM - you do not get exactly one packet, for every "recv" like you do with UDP. Even though it might seem like you do for a while - do not trust that! You might get two packets in one "recv" or you may get half a packet, while the other half comes along in the next call to "recv". The way to deal with this is to store your received info in a buffer, adding on to the end whatever you receive, and don't process the first part of the buffer unless there is a complete packet there (i.e. you've already read at least as many bytes as the first byte in the buffer - packet size). Then after reading that packet you can shunt down your buffer and carry on (i.e. read the next packet if there is a complete one, or do a recv if there is data there, etc...)

Thank you Scawen, it's much appreciated that you did this on your day off because it means I can really get going now - I was a bit hesitant to have rewritten SRA with UDP and migrated.

It's been a long time since I did any TCP programming, so if anyone needs me i'll be in that dimly lit closet over there...

*dissapears into darkness with a cup of coffee*

I've removed this post because I was asking a technical question on a problem I had - only to realise I had been a complete idiot and spotted my problem.

I would like to thank all those who don't ever talk about this ever again !

Few questions...

1. (from ISPackets.txt)
"// The regular packets IS_NLP and IS_MCI are the only exceptionss - not sent via TCP."

So I need to listen UDP too? I have to implement TCP communication, but still listen UDP too?

2. Is this decided that TCP is the future and UDP is abandoned in the (near?) future? (if so, what about IS_NLP and IS_MCI then?)

TIA

W12 Bug: Restarting via shirt-r or /restart command puts the server into qualifying mode even if /qual=0. Host type, client based 'start new game'.

Quote from MonkOnHotTinRoof :

Basically I have same questions as Aquilifier (I don't see any point in having 2 types of communication - gateway, anyone? ), and in addition:
1.UDP no long works in W12, specification says connection will work with protocol started...
2./i command yields unknown command, am I missing something here?

@Becky: you can delete post, it's easier than editing it, and write it's deleted

This post will self-remove in few hours to reduce spam (and decrease my posts again )

To your two points. I haven't tried W12 with insim yet, because I haven't done anything to my insim prog yet.

Your point 2. I got that answer when I tryed the /i command when there was no insim prog running in the same computer (non dedi server). But worked as soon as I run insim program (W10). It's bit misleading and it should say no insim prog running. I didn't try how it works if you type it in a guest computer.

Like Monk said I don't like the idea of having both TCP and UDP either (at the same time). If somebody didn't get it from my 1st post. It is good that UDP is kept at least in the beginning but it's just confusing need to have both running at the same time.

There is a Bug in W11 and W12.

Shift+R starts Qualification - not Race
Tested in single/multiplayer

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

I regard UDP + TCP simulatenously as essential. Imagine my position, before the year is out i'll have over a dozen LFS server applets all talking to 1 central control program from 2 dedicated boxes. TCP data being reliable is great, but the packet header is around 30 bytes larger, so for MCI data UDP is by far the better choice. I'm sure Scawen will make it optional, when he does I for one will be very thankful , so please - dont complain it out of existence *hug*

Quote from Aquilifer :

1. (from ISPackets.txt)
"// The regular packets IS_NLP and IS_MCI are the only exceptionss - not sent via TCP."

So I need to listen UDP too? I have to implement TCP communication, but still listen UDP too?

2. Is this decided that TCP is the future and UDP is abandoned in the (near?) future? (if so, what about IS_NLP and IS_MCI then?)

1) No, that is wrong in the documentation. It will be your choice, you can have NLP and MCI by TCP or UDP. For many applications if the InSim program is on a different computer, it's best to have them sent by UDP because they are regular, and not vital, so you save bandwidth - you do not need guaranteed delivery, just like car pos packets in LFS, if you miss one, you just want the next one, you don't want to know what the car's position was some time ago.

2) There are 3 ways to do race tracking :

a) UDP for all
b) TCP for all except NLP and MCI
c) TCP for all

I've updated the document and attached it here.

Quote from MonkOnHotTinRoof :

Basically I have same questions as Aquilifier (I don't see any point in having 2 types of communication - gateway, anyone? ), and in addition:
1.UDP no long works in W12, specification says connection will work with protocol started...
2./i command yields unknown command, am I missing something here

1) UDP and TCP seem to work just fine, but you must use the new packets.

2) /i only works if you have InSim connected to the host, otherwise it's an unknown command.

Quote from Becky Rose :

W12 Bug: Restarting via shirt-r or /restart command puts the server into qualifying mode even if /qual=0. Host type, client based 'start new game'.

OK, fixed here in W13

[ EDIT : LINK REMOVED - new update available - http://www.lfsforum.net/showthread.php?p=402972#post402972 ]

Quote from Becky Rose :

@Scawen: ISI_SPX - Could you add player flags back in again please? They appear to have been removed and I use them to prevent drivers cheating my driver aid system.

It seems unnecessary now because you receive an IS_PFL immediately if the flags ever change. Let me know if there's a problem with that.

About your other request, about a custom prefix, I was thinking it would be better if you could define custom commands, like /talk or whatever, and any custom commands would be passed right through to InSim, just as they are.

Quote from Scawen :

...
2) There are 3 ways to do race tracking :

a) UDP for all
...

So this is now verified to stay like this for a distant future? My program is ment to be used over loopback so TCP communication is not really needed. I hope this option won't be removed. I have used guaranteed delivery, but I have no idea when the packet could get lost when talking to localhost (queue overflow?). So maybe I can live w/o it.

I guess in that case most insim programmers like me, just need to
1) change the packet formats
2) remove guaranteed delivery (stop ACKing packets) if used

ok thanks for info.

I spotted the PFL packet a little while after (deleted my post et all - I guess you still see it though ), cheers for that .

Quote :

About your other request, about a custom prefix, I was thinking it would be better if you could define custom commands, like /talk or whatever, and any custom commands would be passed right through to InSim, just as they are.

This is very good, I would like that.

I can see a drawback though, if you added a command in the future this could cause problems both in terms of software compatibility, and in user 'training'. The only way around it would be if we used a tag phrase on our commands (ie: /sraTrack) - but that would defeat the purpose of using the '/' prefix in the first place.

With a different prefix we solve these problems, for instance I have a command for $track. LFS has /track.

My $track command tells people when the next track change occurs. For admins, it'll return the next track change unless they do $track=fe1, then it gets passed to LFS as a /track command - so both track commands exist in parallel without any conflicts.

Whilst you are looking at this, i'm expecting III packets but they are coming in via MSO. I'm not sure if this was intentional or not? (I'll hold off working on that for now).

Hmm when I enter a /i command in lfs I get both. MSO and III packets

TCPReader - reading 136 bytes
TCPReader - reading 72 bytes
Received MSO_Packet(ISP_MSO)
Received Unknown_Packet(ISP_III)

(unknown equals not implemented )

That sounds like a bug, I'll fix that tomorrow and continue with the remaining features.

Yay! One in the back of the net for me then
Scawen 8 Becky 1

lol