Think of it as a learning/diagnostic tool. New users (and experienced users!) can see exactly what packets are being sent through InSim quickly and easily.
Uploaded 1.0.12, which contains some extremely large optimisations to the packet receive code, resulting in packets being decoded several hundred times faster.
Internally I'd been using reflection with a lookup table to instantiate the packets, and while I knew this was slightly slow, I didn't realise how slow until I started doing some tests. I switched the lookup table to a giant switch statement, and while it looks messy (huge switches always do), it has resulted in a colossal performance improvememt.
In addition to this I also rewrote socket buffer code, as a I knew a lot of performance was being lost there through heavy use of generic lists. Again, the code doesn't look as nice, but it runs many times faster.
To sum up, the program now updates far more responsively than it did before, and it's very noticeable. Obviously these are some quite large changes to the core of the app, so there may be a couple of new bugs or three in there. Because of this I've left 1.0.11 up as well, which is the stable/slow version of the program.
Fantastic! I always wondered myself what is better, pretty code or fast code? I'm not sure that's a mutually exclusive statement, but it always feels that way.
I don't have any problems with flickering any more, now that I'm using a double-buffered ListView (well not on my machine anyway ). I will have a look at using a GridView, or actually just data-binding in general, as at the moment I'm just updating the lists programmatically.
I've uploaded 1.0.13 which contains improvements to the packet filter. I've moved the filter from the options dialog onto a second tab on the main GUI. This means you can filter packets on the fly while the program is running. It doesn't let you filter previously received packets yet, but that is something on the todo list.
I also spent more time cleaning up the InSim library, so hopefully things should be running even smoother.
I've uploaded V1.0.17, which adds a couple of new view options, such as keeping the window always on top, and making the window transparent. I realised that for the most part you are always using the program alongside the main LFS window, and I hope these options make doing so easier.
In addition I have decided to make both InSimSniffer and the DarkInSim library open-source, and so have uploaded their source-code to the first post. InSimSniffer is released under the GPL, and DarkInSim is released under the LGPL. I hope someone finds the source useful, and that no one thinks it's the most horribly coded program of all time! It's definitely not perfect in any way, but it works and, well, is what it is.
A few notes on the DarkInSim library included with the source code. Basically this is my own InSim library, which started out as an experiment to see how accurately I could port pyinsim to .NET. It turns out - pretty accurately. DarkInSim has a very similar API to pyinsim and a lot of improvements.
Edit: All this is now obsolete, you should have a look for the Spark/InSim.NET thread.
I downloaded the latest version of this (about 20 minutes ago) and was doing a check to see what ^[a-z] was for each of the code pages. When you choose some of the code pages, the datapacket's message area is some times empty even tho the message has content. Can anyone else confirm this?
When I read the contents of some of the packets (Such as MSO) that have been sent using the ^J tag to change the format to Japanese, the contents of the message is blank on the packet sniffer screen even tho there is content to the message in LFS.
How are you setting the ^J tag? If I change the encoding to Japanese and send a message with Japanese characters, it's displayed correctly as Japanese in InSimSniffer.
Could you give step-by-step instructions as how to do this please? I've tried lots of different combinations of changing the encoding, but they all work correctly as far as I can see. I can't get the message to be blank.
You know what it might be then, I might not have that character map installed on my computer. If you can see it, but I can't that might be it. (Leads me to wonder, does LFS uses it's own character sheets for this, or is it rendering based off the Window's character maps. My insinuation assumes that LFS uses it's own build in system.)
(Basically, I'm not meeting a dependency requirement for the Japanese Language to be displayed in Windows.)
I realised that I was doing a lot of unnecessary array copying in the socket buffer code, so I have rewritten the code to reduce as much of this as possible. This should yield a fair performance improvement.
I also added the ability to delete packets from the packet list, both by pressing the DEL key and also by selecting the delete option from the right-click menu. By default you must click through a confirmation dialog before deleting them, but you can disable this in InSim > Options.
The changes to the options means that you must make sure you delete your old settings.dat file (or make sure you unzip to a new directory), otherwise you will see some complaining messages when you first start the new version.
I've been using DarkInSim a bit too and it's absolutely wonderful. Beats the pants off LFS_External and LFSLib.Net... much cleaner, clearer, and easier to use.
As I've said DarkInSim started out as an attempt to port pyinsim to C# and I think it turned out pretty well really (although I could have spent more time on it). I've always had half a urge to release is as a proper InSim module, but I know that what the world really needs right now is another .NET InSim library.