Pushed a few more changes to the repository, although not made a proper release yet.

Breaking Change:

As it's still a beta I've introduced a breaking-change, namely that you now send messages to InSim a bit differently. I really missed the old style of sending formatted messages, so I've reverted it back to the InSim.Send(string, params object[]) method of old.


Here is a most general list of changes in the repository.

Changes

• Can now set your own IPacketFactory and ISocket on the InSim class again, if you need to implement your own packet code (this is kinda advanced stuff, but very useful)
  
• Improved and optimized the string handling code (yay more fun!)
  
• Improved InSim.Send(IEnumerable<ISendable>) method, which allows you to batch send packets for improved performance (useful if you need to send lots of buttons or messages in one go) (see below)
  
• Rewrote BindingCollection, making it cleaner and faster (although not something most people will notice)
  
• Can now save/load InSimSettings (see below)
  
• Fixed a few really big bugs in OutSim and OutGauge code.
  

To save the InSimSettings:


To batch send packets (for extra network performance):


It is almost finished now, I only have a couple of small changes left to consider before I release InSim.NET 2.0 final. As always I invite and encourage people to pull the latest revision from CodePlex and let me known of any issues before I push it out to the world.

Last edited by DarkTimes, Tue 29 Mar 2011, 22:51.

I'm not sure I can answer your question, however I just tried running TV Director and InSimSniffer at the same time, and I was successfully getting STA packets. In fact, I can't think of any way that another program could *stop* LFS sending packets to your app, unless there was a bug in LFS (unlikely). This would suggest to me that this is the manifestation of a bug in your own code, rather than an issue with TV Director.

Last edited by DarkTimes, Tue 29 Mar 2011, 21:08.

Quote from JPeace :

I hope you mean Perez?

Typo sorry.

It was a solid race, not a stunner by any stretch. Some great performances by the rookies, sad to see Perez lose his position, but happy to see Di Resta get some points for his first race (I'm biased of course ).

Last edited by DarkTimes, Sun 27 Mar 2011, 15:41.

From reading the docs

Quote from InSim.txt :

You can send [IS_REO] to LFS before a race start, to specify the starting order.
It may be a good idea to avoid conflict by using /start=fixed (LFS setting).
Alternatively, you can leave the LFS setting, but make sure you send your IS_REO
AFTER you receive the IS_VTA. LFS does its default grid reordering at the same time
as it sends the IS_VTA (VoTe Action) and you can override this by sending an IS_REO.

So basically wait until you have a received a IS_VTA, then send your REO packet, which should successfully overwrite any order LFS has decided. When your app first connects to a host it can send a /start=fixed command for good measure, but from reading the docs it seems it won't matter much.

Note that IS_VTA does not exist as a packet (this seems to be an error in InSim.txt), instead it's a IS_SMALL with a SubT of SMALL_VTA and a UVal of VOTE_RESTART.

Quote from DarkTimes :

I've lost the original source for this program, so I've started to write it again from the beginning. I've no idea when it will be finished, so I can't say when I will be able to release it. I am going to focus first of all on recreating it for MPR files first, then I will start to think about the InSim version again. I'm writing it for .NET 4.0, as the new version of .NET has some interesting data-structures which will make everything a lot easier. I think that .NET 4.0 final will be released by Microsoft before I am finished, so it should all work out OK.

OK - so it's only taken me a year, but it's almost finished. As I mentioned I no longer have the original source for the program, so the idea behind this next release is to recreate the original functionality of 2.4, with a few tweaks and improvements. Once that is released I can then see about adding some new features, such as the long, long, long awaited InSim support, for which I have a better, simpler idea of how to implement than I did before. I'm not sure exactly when it will be finished, but we're talking days or weeks, rather than months or years.

I'm actually quite happy with it, it's vastly more polished than the old version, also the source code is much better written, which will make it easier to expand and maintain in the future. Just the result of an extra four years learning about programming since I wrote the initial version.

Last edited by DarkTimes, Sat 26 Mar 2011, 14:57.

Not really, except for disassembling the library and recompiling it with a couple of changes. What you need to do is change:


To...

Last edited by DarkTimes, Mon 21 Mar 2011, 13:36.

It's because IS_NPL.Plate does not end with a NULL character, like normal C-style strings. LFS_External must be popping off the last character of the string somewhere, which is perfectly fine for all other InSim strings (which end with a NULL char), but not for Plate.

Uploaded version 1.2.4 to CodePlex:

Changes

• String encoding support for double-byte charsets (e.g. shift-jis, trad chinese etc..)
  
• Can restore app from notification tray by left-clicking notify icon and balloon tooltip
  
• Improvements to the way menus are shown
  
• Fixed several issues with dialog boxes when main window is in always on top mode
  
• Fixed bug with disconnecting from InSim while sniffer is paused
  

Note: The new string encoding stuff is a little experimental, but hopefully it shouldn't explode. Adding it to InSimSniffer seems as good a way as any to test it.

Last edited by DarkTimes, Sun 13 Mar 2011, 21:52.

OK - good to hear it's working OK. What you all won't be glad to hear is that I've just completely rewritten all the string encoding code! Yay, more bugs!

I suddenly had a brainwave about how to implement full string encoding support and it seems to be working well. I've pushed the changes onto the repository, but I'll hold back on pushing out a release until I've made sure it's all working OK.

The new string encoding now correctly handles all LFS codepages, including single-byte and double-byte character sets, which means full Japanese, Korean, Simplified Chinese and Traditional Chinese support. I had talked about this before, but in the version of the library I release I only included support for single-byte character sets. Obviously that sort of thing is not good enough.

In my previous attempts to write this code I had been performing the lookup myself (with giant hash tables), which was proving problematic, but I'm now p/invoking the WideCharToMultiByte function in kernel32.dll, which seems to provide a simple and fast lookup for the various encodings. It is slightly slower than the old string encoding, but we're still talking about fractions of a millisecond for even complex strings.

I'd appreciate it if anyone would be willing to pull the latest revision from the repository and report back if it's working OK.

OK, thanks - I've uploaded a fixed version to CodePlex.

http://insimdotnet.codeplex.com/releases/view/62453

OK, I think I've fixed the bug with the BTN text. What was happening is the BTN code wasn't correctly taking into account the NULL terminator when figuring out the length of the string. Because there was no NULL terminator LFS was discarding the string and not showing it, which is why some buttons appeared to not be sent.

I've uploaded a new release of the BETA to CodePlex.

Note: Entertainingly this fix required the change of only a single-character in the source code, changing a 2 to a 3.

Last edited by DarkTimes, Sat 12 Mar 2011, 17:19.

Quote from broken :

Ok, the admin pass seems to be perfectly fine.

But I have 2 more reports:
1. The color codes I send to LFS, are being shown as text. I send ^1red, and I get a normal, green ^1red.
2 (better version of that explanation is available below). I might join povo's club about the button length. At some random points, my Queue thing (in case you are wondering, yes, Queue thing is how I like to call it :razz shoots out random errors when sending a button. At first I thought that was happening, because of my poorly-tested loop (which deletes buttons from a list after it hands them over to insim.net). But now, I suspect it's because of the length of the text on that button. There's this button of them all, that shows a typical car list (cruise insim style, because it's a cruise insim). And when I surrounded the Send code in a try expression(if it's an expression, if it's not I'm looking stupid, and I'm happy someone can have a laugh at my bs ;d) - that very same button was the only one that didn't show on the screen. (I'm going to need to rewrite that... All done, there it is - below!)
BETTER VERSION of 2: I am suspicious that buttons with long text sometimes don't get sent. I receive this when that happens:

[B]Message[/B]: Index was outside the bounds of the array.
[B]Source[/B]: InSimDotNet
[B]StackTrace[/B]: at InSimDotNet.EncodingHelper.GetBytes(String value, Byte[] buffer, Int32 index, Int32 count)
at InSimDotNet.Packets.PacketWriter.Write(String value, Int32 length)
at InSimDotNet.Packets.IS_BTN.Pack()
at InSimDotNet.InSim.Send(ISendable packet)
at Dizplay_Cruise.Button.Processor.QueueProcessor_Elapsed(Object source, ElapsedEventArgs e) in D:\Loran\Programming\C#\Live for Speed\Dizplay\Cruise A.0.1\Dizplay Cruise\Dizplay Cruise\Button\Processor.cs:line 35
at System.Timers.Timer.MyTimerCallback(Object state)


Ok, after actually reading, and not just scanning through all of the values of the error, it looks like there's a problem with the color codes' encoding, not the length. Maybe, because something evil happened to the '^' char, which could have something to do with the admin passwords being all OK? But... I'm guessing it's something you would have found out before even reading this, and I might just be wrong as well, so, whatever.

PS: Sorry for the messy post.

I've pushed a bug fix onto the repository (not ready to make a release) with a small fix for the color codes. It would be helpful if you could actually post an example of a button that doesn't get sent, as I'm not sure exactly what the problem is. The fix I've made should help things.

You can download the latest changeset from the repository.

http://insimdotnet.codeplex.co ... ceControl/list/changesets

You need to send a BFN packet with a SubT of BFN_DEL_BTN to delete one button, or BFN_CLEAR to delete all of them.

So, has anyone had a chance to try those changes I made? I think it should be working OK, but don't want to declare it so until povo and broken have signed off on it (as it was their bugs I was fixing).

Hey, sorry for not posting for a while.

I uploaded a new version of the library with some changes I made a while ago but didn't get around to uploading. I think I may have fixed the bugs with the string encoding.

When you go to the garage screen a PLP packet is sent (I think that is the only time that packet gets sent). When in the garage the car is not actually changed until you click OK, in which case a new NPL packet is sent with the new car info. There is no way, as far as I know, to detect which car the player has selected on the UI. LFS does not report the car being changed until you click OK to leave the garage.

Instead of writing your own news system maybe a better idea would be to integrate some sort of off-the-shelve CMS such as WordPress into your site. That is unless you want to learn how to code PHP.

It would be helpful if you called it InSim.NET and not Spark 2, as the Spark name will disappear once it goes out of beta.

I don't mind what you do with the videos, you can rename them or whatever.

Anyway in the interests of balance here's one for pyinsim.

http://rapidshare.com/files/442246363/pyinsim_example.7z

I switched to 7zip as it makes the files so much smaller.

OK - I was bored, so here is a test that shows how to quickly create a InSim program using C# and InSim.NET (which is Spark 2.0).

http://rapidshare.com/files/442188514/insim_example_1.zip

It's not a perfect video, still fiddling to try and get it right, but hopefully it should work OK. It's the first time I've made something like this, so feedback may or may not be appreciated.

Here is an example that shows InSim.NET (Spark 2) running under IronPython. It's just a simple example that shows maintaining the connection list.

Last edited by DarkTimes, Thu 31 Mar 2011, 15:17. Reason : Updated to reflect recent changes in codebase.

Well you can use anything for small fixes and hacks, you'd be nuts however to throw away the productivity benefits that using a good IDE can bring you. Syntax-coloring, auto-completion, code analysis, code generation et al. Get a good IDE and learn it, learn all its features and keyboard shortcuts, because it'll make programming easier.

That being said, I did learn to code on NotePad, but these days I use NotePad++ for small stuff (right-click Edit with Notepad++ is win), and Visual Studio and Aptana Studio (which is based on Eclipse) for most proper development. I've been known to use NetBeans and Code::Blocks as well.

Last edited by DarkTimes, Tue 11 Jan 2011, 16:33.

I've used NetBeans before, it seems like a very solid IDE. For your other questions I'd advise just reading the documentation and searching for Java tutorials with Google.

OK change this:

to