The online racing simulator
Tool - InSimSniffer
(113 posts, started )
Tool - InSimSniffer
InSimSniffer is a InSim packet sniffer for the racing simulator Live for Speed. It connects to the game and displays the contents of each InSim packet that is received. This is useful both as a debugging aid and also in learning about how certain operations are handled by InSim.

Getting Started

Download the latest version InSimSniffer and unzip the archive, double click the InSimSniffer.exe executable to run the program. InSimSniffer can automatically launch LFS and configure it for InSim. To do this follow these steps.
  • Go to InSim > Options and select the General tab
  • Set the location of LFS.exe and make sure the Auto-connect after launching checkbox is enabled. Note: the location of LFS.exe should be filled in automatically if you have a normal LFS installation.
  • If your LFS client requires a game admin password, you can set this option under the InSim tab.
  • Click Save to save the options to settings
  • Go to InSim > Launch LFS to automatically start the game and connect. InSimSniffer sets the correct InSim port argument when starting LFS, so you don't need to do this yourself.

You can download the latest version of InSimSniffer from the official CodePlex page.


A lot of the discussion in this thread applies to old versions of the program that had different features.

Attached images
#2 - KuHS
Good work
#3 - amp88
Quite interesting. An improvement suggestion would be to display the player's actual name along with the PLID value as it would be a bit more human readable.
Yes that's already on the todo list, along with a few other things. I need a better way to display the packets first, but I have a couple of ideas for that.
#5 - amp88
Ah, OK.

Here's an error. With the default Host Address of "localhost" I got the following error:

Date: 12/08/2009 14:29:43
OS: Microsoft Windows NT 6.0.6002 Service Pack 2
Culture: en-US
Message: None of the discovered or specified addresses match the socket address family.
Parameter name: context
Source: System
Target: Void EndConnect(System.IAsyncResult)
Stack Trace: at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
at LFSPoints.InSim.InSimClient.ConnectCallback(IAsyncResult r)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.ContextAwareResult.CompleteCallback(Object state)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.ContextAwareResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.LazyAsyncResult.InvokeCallback(Object result)
at System.Net.Sockets.Socket.DnsCallback(IAsyncResult result)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.ContextAwareResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.Dns.ResolveCallback(Object context)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
Inner Exception:

With Vista Home Premium SP2. Changing the address from "localhost" to "" sorted the problem.
OK thanks for the report. Strange as 'localhost' works fine for me.
Thank you very much! I was going to make that for myself but you were faster! Thank you again!

Uploaded 1.0.1 to the first post.
  • Fixed bug with PLIDs in IS_REO packet
  • Changes to options dialog to prevent invalid info from being added (host IP, admin pass etc..)
I'm still trying to settle on a good way to display the packets, everything I've tried has been a bit crap. The current ListBox flickers too much, and I'm having issues fixing that, a ListView appears limited to 260 characters, which isn't long enough, and any custom controls I've tried have been slow and clunky. I'm seriously considering switching to WPF and rendering the packet info myself.
I can do it on a ListView, the 2nd method works great, but that simply does not work on a ListBox. With the ListBox you need to go into OwnerDraw mode and render the items yourself, but I'm having nightmares getting the horizontal scrolling to work. Anyway, I have a better idea for how to display the packets now.
Ah right, but isn't the listview able to perform the same tasks (and more) than the listbox? IIRC you can make it look pretty much the same. Of course I don't know if it's capable of handling thousands of items, though. In general I have the impression that .NET win form controls can be pretty shit in regards to performance.
Something in the back of my head says I read around 10,000 items for a ListView once, before its performance starts to really suffer. I did try to use a ListView earlier, but it appears (although I cannot find any confirmation of this) that items in a ListView are limited to 260 characters in length. The packets can be longer than that.
Just tested it and it seems to be true that it's limited to 200something characters. Though, could it maybe make sense to simply use multiple columns then? It's not like you have to display the properties as comma separated list
Yeah, well it's 260 characters exactly, I counted them.

Anyway, the problem I realised was not with the WinForm controls, but really with the way I was displaying the packets. As you said it doesn't have to be a comma-delimited string.

I've uploaded a new version (and a new screenshot) to the first post, with a new layout. It makes viewing the packets much more readable, and importantly lends itself much better to future features. Obviously I still have work to do here though.

Only other interesting change is that the packet reflection code now deals correctly with packets that contain arrays, such as Tyres in NPL and other similar instances.

Note: I have actually disabled MCI/NLP updates, as I really haven't figured out a good way to handle those yet, but I have a few ideas. More ideas than time.
Yes, much nicer . I see the newest packets are now added at the bottom? If so an auto-scroll functionality would be very nice. (I haven't had a chance to actually try it out, so sorry if I'm suggesting things that are already implemented.)
Another new version updated to the first post. Also I renamed the program InSimSniffer.

It's funny, I've actually learned a lot during the testing of this, it gives you a much better feel for what's going on when you can see all the packet data in a nice little window.

The new version will have some bugs.
Great application DarkTimes, I sure will use it!

I'm sure this will help (new) programmers encovering new packets and more information.
Uploaded 1.0.4 to first post.
Nice improvements

A small suggestion. If the user has auto scroll enabled but they have moved the scroll bar on the scroll pane to look up at previous packets the application shouldn't auto scroll to the bottom. It should only scroll if the scroll bar is at the bottom already.
OK - a good suggestion. I think what I'll do is if the user selects a packet or scrolls the bar themselves, it will turn those features off automatically. I think only auto-scrolling when at the bottom would be confusing though.
I think autoscroll only at the bottom is a pretty standard feature of similar log tools, though turning it off when the user scrolls is probably OK too (since you can clearly see the option there and notice immediately if the checkstate changes).
Really nice

1.0.5 uploaded.
Spent the day working on LFSPoints and needed to make some changes to this, so I've uploaded 1.0.6 with some small updates.

Tool - InSimSniffer
(113 posts, started )