Quote from DarkTimes :

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.

If the code is clean, why not! Hell, I need something to use as a base for a plugin programming with PAWN. Granted, I still have alot of work to do with that ... Hell, maybe you could help. It's just that it requires some pretty nuts programming on the module end.

Quote from Dygear :

If the code is clean, why not!

I know what you are saying, but I really cannot justify releasing yet another .NET InSim library (especially seeing as I already maintain pyinsim). Anyway, DarkInSim was created to accomplish four criteria which were lacking in the other libraries, without which InSimSniffer would not be possible:

• Exact representation of InSim packets
  
• Full access to underlying byte data when needed
  
• Support for asynchronous operations
  
• Very lightweight performance
  

If the program you are making requires those parameters to be matched, then DarkInSim may be the right choice for you. Otherwise you are much better off sticking with the old tried and tested libraries like LFS_External and LFSlib.

Note: I will be releasing InSimSniffer and DarkInSim 1.1 in the next few days, so you might wanna hold off for the new versions to be released, as they are even simpler and even faster.

It's more because I want to expose the raw packet data within the context of a struct to the program, that is then handed off to the plugin for interpretation. I've stoped my work on the C++ version of this, as I want to clarify my idea in PHP (My native language if you will.) and then see where the short comings of the PHP project are and do it better a second time with C++ (With both speed, obviously, and implementation.)

I've spent the last week or so refactoring the code for this program and have made a lot of changes and improvements. There aren't really any new features to shout about, except that I now use .NET config files which should work seamlessly on Vista and Windows 7. Aside from that you should notice even better performance and a lot of the packet info has been tweaked and a few weird issues have been resolved. Of course a bunch of old weird issues are still there, but no one ever seems to notice those . The code itself still isn't awesome, it's not an example of perfect code by any means, but I'm definitely a lot happier with it than I was before.

Note: DarkInSim has also moved to version 1.1.0, has been heavily rewritten and now supports InSimRelay.

Quote from DarkTimes :

Note: DarkInSim has also moved to version 1.1.0, has been heavily rewritten and now supports InSimRelay.

You're a superstar, I was going to ask for it.

10 billion points to you sir, excellent upgrade.

Oh crap, I forgot I actually compiled this release without the Relay connection code. I do have working relay code, but I forgot I still need to fix a couple of issues with DNS lookup that I don't understand yet. This release includes the IRP_* packets, but won't currently allow you to connect to the relay server. Sorry, my bad.

Quote from DarkTimes :

Oh crap, I forgot I actually compiled this release without the Relay connection code. I do have working relay code, but I forgot I still need to fix a couple of issues with DNS lookup that I don't understand yet. This release includes the IRP_* packets, but won't currently allow you to connect to the relay server. Sorry, my bad.

you son of a bitch

Yeah, sorry. I have three different version of DarkInSim, at least two versions of InSimSniffer, four versions of pyinsim, plus a new version of LFSPoints on the go. Sometimes I get confused at to what features are available in which version.

Anyway my cool tip of the day, if you use InSimSniffer a lot, is to recompile the source with Visual Studio 2010 beta. The whole programs runs even better on C# 4.0. Everything feels much more responsive and the whole library feels much more optimised.

Quote from tmehlinger :

you son of a bitch

Haha, Awesome.

Quote from DarkTimes :

Yeah, sorry. I have three different version of DarkInSim, at least two versions of InSimSniffer, four versions of pyinsim, plus a new version of LFSPoints on the go. Sometimes I get confused at to what features are available which version.

Excuses!

Quote from DarkTimes :

Anyway my cool tip of the day, if you use InSimSniffer a lot, is to recompile the source with Visual Studio 2010 beta. The whole programs runs even better on C# 4.0. Everything feels much more responsive and the whole library feels much more optimised.

I was thinking about grabbing the Visual Studio C++ 2010 Beta, but I don't know how I feel about writing code in a beta environment.

Quote from Dygear :

I was thinking about grabbing the Visual Studio C++ 2010 Beta, but I don't know how I feel about writing code in a beta environment.

I've not tried Visual C++ 2010, but C# has been plagued by bugs and performance issues. Apparently the new RC1 release has fixed almost all of those problems however, and the new WPF code editor seems to be working very well. To be honest though, unless you are going to be using the new features of .NET 4.0, I wouldn't bother upgrading right now. That said the new .NET 4.0 is absolutely awesome, as with support for Python and Ruby it's completely first class.

Quote from DarkTimes :

That said the new .NET 4.0 is absolutely awesome, as with support for Python and Ruby it's completely first class.

That's pretty cool! Must be making your life easier.

I uploaded a version of InSimSniffer 1.1 compiled for the brand new .NET Framework 4.0 to the first post. I also fixed a very small bug that caused some packet info to be processed twice.

Quote from DarkTimes :

I uploaded a version of InSimSniffer 1.1 compiled for the brand new .NET Framework 4.0 to the first post. I also fixed a very small bug that caused some packet info to be processed twice.

Did you feel any change, does it feel faster?

InSimSniffer already ran pretty fast, I put a lot of effort into optimising it a while back, so it's hard to tell without doing actual tests. The bug fix will have improved performance quite a bit, as it was a dumb error where at one point in the logic I was doing:


And processing everything twice. Which means a lot of performance was being thrown away anyway...

Uploaded 1.1.1 to the first post.

Changes

• Now detects location of LFS.exe automatically
  

I realised that as LFS now uses a proper installer I can grab the location of LFS.exe from the registry instead of requiring the user to configure it. That said, you can still set the location manually if you want/need to.

Note: I have depreciated the old version of this program, I will only support .NET 4.0 from now on.

Uploaded 1.1.2 to the first post. Only a single change:

Changes

• Export now only exports the filtered packets list instead of the full packet list.
  

There is an option to renable the old functionality (export all packets no matter what) in the options dialog. That is all.

This is a great tool, thanks! It really helped me to figure out the InSim traffic, before taking the plunge into InSim programming.

One minor bug: after I moved the location of the LFS installation, InSimSniffer stopped working. It exited with a null pointer exception at startup. (Can send you the details if you want.) Apparently, InSimSniffer assumes that when it finds an LFS registry key, it will also find the LFS install at that location.

Improvement suggestion: Put the filter settings in a different sidebar, so the user doesn't have to switch tabs between filter settings and message list. (Even nicer: apply filter changes immediately, without needing to click "Apply".)

Open InsimSniffer->Options->General->Location of LFS.exe

Can you do that or it crashes before?

Quote from Whiskey :

Open InsimSniffer->Options->General->Location of LFS.exe

Can you do that or it crashes before?

It crashes immediately. I don't even get to see the main screen.

Quote from wsinda :

One minor bug: after I moved the location of the LFS installation, InSimSniffer stopped working. It exited with a null pointer exception at startup. (Can send you the details if you want.) Apparently, InSimSniffer assumes that when it finds an LFS registry key, it will also find the LFS install at that location.

I cannot reproduce this bug, so I would appreciate it if you could send a crash report, if one was generated. Otherwise I need step-by-step instructions on how to reproduce it. I have looked through the code and tried moving the LFS location but I can't see anything that would allow this bug to happen.

This is the crash report:

Might be worth adding that LFS was installed under a different user account than the account that I used when I got the crash.
Running MS Vista, BTW.

OK - I looked at the code harder and saw the bug, which I've now fixed.

Thanks!

I uploaded 1.1.3 with the bug fix.

Note: I also updated the screenshot to show Windows 7 instead of Fisher-Price era XP.

Version 1.1.3 works fine. Bug solved.