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.

Download

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

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

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.)

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).