The online racing simulator
I do hope you will be around to update InSim.NET with the (hypothetical) new InSim packet(s) and other InSim improvements Scawen may introduce in upcoming patches.
I will still develop the library in the future, I just want to get the current changes out into the open as the next few weeks are going to be pretty busy for me.

Anyway, I had to make a couple of small fixes to the UdpSocket code to get it to work correctly, but I've fixed that now and pushed the changes to the repo.

I've created a new release called InSim.NET 2.1.0-beta and pushed it to GitHub and NuGet. It is marked as pre-release so you will need to tell NuGet to allow pre-release libraries before it will show up you for you.

InSim.NET 2.1.0-beta Changes
  • InSim.NET now requires .NET 4.5 or better
  • Added missing leave reasons
  • Fixed string encoding issues that prevented the library from working on Mono
  • Fixed incorrect remote property in IS_NCN
  • Fixed bug PLT_REMOTE in PlayerTypes was incorrect
  • Fixed TyreCompound enum and added TYRE_NONE
  • Fixed issue with IS_AXM Info list being set to wrong size
As I said earlier I rewrote the socket code to use the .NET async/await pattern. This means that if you are using InSim.NET inside a UI app such as WinForms or WPF you no longer need to call Invoke or BeginInvoke before updating the UI from a packet handler, that is now handled for you behind the scenes. If you are using the library from a console app then it's up to you to deal with any possible threading issues that might occur.

Download

You can download the beta from GitHub or using the NuGet Package Manager.

Please let me know if you have any problems.
Cool, will play with BytesSent and BytesReceived more seriously once I get a few things sorted out with my app.


Quote :If you are using the library from a console app then it's up to you to deal with
any possible threading issues that might occur.

Found this out the hard way


It might be nice to have a basic example on how to make the socket connection bulletproof (from your own code). I found ways to kill the connection somehow and wish to have the connection code as stable as possible so that I can fire things at it without losing connection.
InSimDotNet / InSimDotNet.csproj

<Project ToolsVersion="12.0" ....>

Some IDE's can work only with ToolsVersion <= 4 (SharpDevelop 5 beta)
Quote from denis-takumi :InSimDotNet / InSimDotNet.csproj

<Project ToolsVersion="12.0" ....>

Some IDE's can work only with ToolsVersion <= 4 (SharpDevelop 5 beta)

OK thanks, I'll need to look into this and figure out what to do about it.

Quote from sicotange :For instance, currently I removed the helpers from InSim.NET (the rest remains untouched) as I have my own helpers classes in my InSim app. The InSim.NET helpers are partially copied into my own helpers classes. It probably doesn't make much sense but I know each programmer has his habits...

One thing I had previously considered was moving InSimDotNet.Helpers into its own DLL that you could add separately if you needed. So for instance on GitHub and NuGet there would be two packages, InSimDotNet and InSimDotNet.Helpers. This way if the InSimDotNet.Helpers.dll clashed with your own code then you didn't need to install it. Also it would make it easier for people to fork the code and add their own extensions and helpers without affecting the main library.
It doesn't seem to be a bad idea to separate the Helpers. I use some of the InSimDotNet.Helpers but have written plenty of my own. I may have written some helpers which could be of use if integrated with InSimDotNet.Helpers.

Somehow I feel that adding more documentation or making examples on how to make use of multiple InSim instances could make InSimDotNet more popular but it is probably not the most fascinating thing to write.
Sorry I've not been about but I just finished my first week back at college and I don't have a massive amount of free time. Of course if the beta has been confirmed to work correctly then I can push out a release version without much trouble. One benefit to being back at school is that I have free access to Visual Studio Professional again! Hooray!

Edit: I'll try and fix the tools issue before then as well, sorry I forgot about that.
So far so good! I have been working on my InSim app franticly recently and haven't encountered issues with 2.1.0 so far
Quote from denis-takumi :InSimDotNet / InSimDotNet.csproj

<Project ToolsVersion="12.0" ....>

Some IDE's can work only with ToolsVersion <= 4 (SharpDevelop 5 beta)

I've looked into this. If you look at the help files for SharpDevelop 5 beta it clearly states you need to install Microsoft Build Tools 2013 in order to open Visual Studio 2013 solutions. This isn't really a problem with InSim.NET, if you cannot open the solution you can just change the ToolsVersion manually.

Edit: I'll put out the final version tomorrow, I'm a bit too hungover to do it tonight.
Good work DarkTimes, nice to see you active with this again
I pushed out a release of InSim.NET 2.1.0 to GitHub and NuGet. Let me know if there are any problems.
Is this any different from the BETA?
No, it's the same.
I've got a report of an interesting exploit where people are able to make InSim.NET's string handling code crash by typing certain characters (and are then able to use that to grief servers). I'm struggling to reproduce it here but I have a few ideas for what's causing it.

Can I ask, has anyone had any of these sorts of problems running InSim.NET on Windows? I have a feeling that the issue lies in the new Mono code (and by extension the old Mono hack people had been using). I would like to confirm no Windows users have had these sorts of issues though.

I could be on completely the wrong track.
If you ever used my patch, that has some bugs... I'm using this code to do character set conversion now, but it's not for InSim.NET so you'll probably need to adjust bits.

http://fuzzle.org/~petern/CodePage.cs

(There's also an issue with different symbols in different codepages resolving to the same unicode codepoint. I decided to ignore that.)
Quote from DarkTimes :I've got a report of an interesting exploit where people are able to make InSim.NET's string handling code crash by typing certain characters (and are then able to use that to grief servers). I'm struggling to reproduce it here but I have a few ideas for what's causing it.

Can I ask, has anyone had any of these sorts of problems running InSim.NET on Windows? I have a feeling that the issue lies in the new Mono code (and by extension the old Mono hack people had been using). I would like to confirm no Windows users have had these sorts of issues though.

I could be on completely the wrong track.

You could be onto something about the whole Windows/Mono thing. I used this library on Windows for years and didn't have much problems.

I was then using the library on Mono for a while a few months ago and I had strange crashes and I didn't get much info out of the stack traces. It happened with your release and also PeterN's fix for Mono.

I'm not sure exactly what was wrong but there was something happening when I ran it on Mono.
OK - I'll look into it later this week in more detail. I've made a small change to the repo which might help with the exploit I'm working on. I changed the DecoderExceptionFallback to ReplacementFallback, which should stop the GetString method from throwing an exception if it finds a character it cannot decode. That was the original intention of that code that somehow got lost along the way.

On another matter...

In 2.1.0 I rewrote the socket code to use async/await, a side-effect of this is that the sockets now reuse any existing SynchronizationContext when returning from an async call. Basically what this means is that if you use InSim.NET in a WinForms or WPF app then you no longer have to worry about threading problems as .NET automatically marshals the packet callbacks back onto the main UI thread. That being said I realised that you may actually not want this behaviour, so I added a new property called ContinueOnCapturedContext to the InSim class that allows you to set false to return to the previous functionality.

var insim = new InSim();
insim.ContinueOnCapturedContext = false;

I picked the name ContinueOnCapturedContext because that's how .NET describes it, however I may change it to something more friendly such as SyncToUIThread.

These changes are both in the repo, but as usual they might be buggy.
With the changes to the async code it now makes it a very good idea for newbie coders to write InSim.NET stuff inside of a WinForms app (or WPF), because the marshalling is now handled automatically and you won't have to deal with any threading issues. In the past you needed to deal with lots of things like Invokes and delegates, but now it should all just work without any of that. I will create a small demo of InSim.NET running in a Windows Forms app soon.
Quote from PeterN :If you ever used my patch, that has some bugs... I'm using this code to do character set conversion now, but it's not for InSim.NET so you'll probably need to adjust bits.

http://fuzzle.org/~petern/CodePage.cs

(There's also an issue with different symbols in different codepages resolving to the same unicode codepoint. I decided to ignore that.)

Thanks for this. I'm looking through the code and I see the changes you've made but it would be useful if you could tell me what these changes are supposed to do. I can see what the code does but I don't understand its intent.
Quote :I've got a report of an interesting exploit where people are able to make InSim.NET's string handling code crash by typing certain characters (and are then able to use that to grief servers). I'm struggling to reproduce it here but I have a few ideas for what's causing it.

Can I ask, has anyone had any of these sorts of problems running InSim.NET on Windows?

On Windows server 2012 I encountered the following causing InSim.NET to crash:

Quote :24/09/2014 15:59:22 CHAT: ^7☆^4Nitro^1Circus^9☆ ^8(onecheque) ^7: ^2
24/09/2014 15:59:41 CHAT: ^7☆^4Nitro^1Circus^9☆ ^8(onecheque) ^7: ^2
24/09/2014 16:00:14 CHAT: ^7☆^4Nitro^1Circus^9☆ ^8(onecheque) ^7: ^2put uoru ramp here
24/09/2014 16:00:23 CHAT: ^7☆^4Nitro^1Circus^9☆ ^8(onecheque) ^7: ^2your(
24/09/2014 16:00:33 ERROR: 9/24/2014 4:00:33 PM System.Text.DecoderFallbackException: Unable to translate bytes [81] at index 14 from specified code page to Unicode.
at System.Text.DecoderExceptionFallbackBuffer.Throw(Byte[] bytesUnknown, Int32 index)
at System.Text.DecoderExceptionFallbackBuffer.Fallback(Byte[] bytesUnknown, Int32 index)
at System.Text.DecoderFallbackBuffer.InternalFallback(Byte[] bytes, Byte* pBytes)
at System.Text.DBCSCodePageEncoding.GetCharCount(Byte* bytes, Int32 count, DecoderNLS baseDecoder)
at System.String.CreateStringFromEncoding(Byte* bytes, Int32 byteLength, Encoding encoding)
at System.Text.EncodingNLS.GetString(Byte[] bytes, Int32 index, Int32 count)
at InSimDotNet.LfsEncoding.GetString(Byte[] buffer, Int32 index, Int32 length)
at InSimDotNet.Packets.IS_MSO..ctor(Byte[] buffer)
at InSimDotNet.PacketFactory.BuildPacket(Byte[] buffer)
at InSimDotNet.InSim.TcpSocket_PacketDataReceived(Object sender, PacketDataEventArgs e)
at InSimDotNet.TcpSocket.OnPacketDataReceived(PacketDataEventArgs e)
at InSimDotNet.TcpSocket.HandlePackets()
at InSimDotNet.TcpSocket.<ReceiveAsync>d__0.MoveNext()
24/09/2014 16:00:33 ERROR: 9/24/2014 4:00:33 PM InSimDotNet.InSimErrorEventArgs

Could this be related to that infamous exploit?

EDIT

I suppose this wont be of much help?
Quote :
Problem signature:
Problem Event Name:CLR20r3
Problem Signature 01:clavico.exe
Problem Signature 02:1.0.0.0
Problem Signature 03:541452ec
Problem Signature 04:mscorlib
Problem Signature 05:4.0.30319.18449
Problem Signature 06:528fdb6a
Problem Signature 07:3511
Problem Signature 08:8a
Problem Signature 09:System.Text.DecoderFallback
OS Version:6.2.9200.2.0.0.400.8
Locale ID:1033
Additional Information 1:5861
Additional Information 2:5861822e1919d7c014bbb064c64908b2
Additional Information 3:1a2a
Additional Information 4:1a2aa8e38ac8adbb6fe1e594fa623c2e

onecheque say "☆SORRY☆☆NO PROBLEM☆". He bind that.
In LFSLazy log its look like this (in LFS Japanese code page 81/82):
Quote :^J™‚r‚n‚q‚q‚x™^™‚m‚n ‚o‚q‚n‚a‚k‚d‚l™

this part
Quote :™^™

is the problem


and sorry sicotange i kill your insim when i try to reproduce this bug
Quote from Draggo :onecheque say "☆SORRY☆☆NO PROBLEM☆". He bind that.
In LFSLazy log its look like this (in LFS Japanese code page 81/82):
Quote :^J™‚r‚n‚q‚q‚x™^™‚m‚n ‚o‚q‚n‚a‚k‚d‚l™

this part
Quote :™^™

is the problem


and sorry sicotange i kill your insim when i try to reproduce this bug

OK thanks, that's really helpful actually, hopefully that will let me reproduce the bug as well.

Quote from sicotange :
Quote :I've got a report of an interesting exploit where people are able to make InSim.NET's string handling code crash by typing certain characters (and are then able to use that to grief servers). I'm struggling to reproduce it here but I have a few ideas for what's causing it.

Can I ask, has anyone had any of these sorts of problems running InSim.NET on Windows?

On Windows server 2012 I encountered the following causing InSim.NET to crash:

Could this be related to that infamous exploit?

Yes I think that's the same bug as it's also a DecoderFallbackException that's being thrown. I presume you're using the last proper release of InSim.NET, have you tried using the latest changeset in the repository? I recently made some improvements to the LfsEncoding class to try and prevent that exception being thrown. If not I'll test it later today myself.

There is still another bug that PeterN posted a fix to but I don't think it's related to this. I still don't know what bug his fixes are designed to correct.
It fixes incorrect decoding of multibyte characters, which could cause a crash, IIRC. However, I ditched the GetByteCount() stuff as I didn't need it.

It also fixes the wide non-ASCII versions of alphanumerics being substituted with their plain ASCII variant, which is not necessary but nicer.
Ah OK - cheers thanks!
Exact same crash / exploit:

Quote :Sep 25 00:09:08 Repaired Mesh
Sep 25 00:09:08 ^J™›œ›™ ^Lreset his car (FXR)
Sep 25 00:14:48 ^H¡¸¡³¡·¡´¡·¡³¡¸ : ^Lr
Sep 25 00:15:28 ^H¡¸¡³¡·¡´¡·¡³¡¸ : ^L...
Sep 25 00:19:20 Draggo^L took over from ^H¡¸¡³¡·¡´¡·¡³¡¸
Sep 25 00:19:33 Repaired Mesh
Sep 25 00:19:33 Draggo ^Lreset his car (FXR)
Sep 25 00:19:57 Repaired Mesh
Sep 25 00:19:57 Draggo ^Lreset his car (FXR)
Sep 25 00:21:51 Draggo : ^L¦jj¦¦¦¦¦¦¦^E¢¢¢¢¢•••¢¦0•,,,,,¦
Sep 25 00:27:10 Draggo : ^L^J™‚`‚a‚b‚c‚d‚e‚f‚g‚h‚i‚j‚k‚l‚m‚n‚o‚p‚q‚r‚s‚t‚u‚v‚w‚x‚y™
Sep 25 00:31:56 Draggo : ^L^H¢á¢Ý¢à¢à¢ç ^S£Á£Â£Ã£Ä ©–^K¢À¢Á¢¾¢¿ £Á£Â£Ã£Ä£Å£Æ£Ç£È£É£Ê£Ë£Ì£Í£Î£Ï£Ð£Ñ£Ò£Ó£Ô£Õ£Ö£×£Ø£Ù£Ú
Sep 25 00:32:48 Draggo : ^L!menu
Sep 25 00:39:11 Draggo : ^LÂ^J‚r‚n‚q‚q‚x ‚r‚n‚q‚q‚x ^K£Ó£Ï£Ò£Ò£Ù¡Ù ^J™
Sep 25 00:40:07 Repaired Mesh
Sep 25 00:40:07 Draggo ^Lreset his car (FXR)
Sep 25 00:42:10 Draggo : ^L^J™ ‚r‚n‚q‚q‚x ™ ‚m‚n ‚o‚q‚n‚a‚k‚d‚l ™
Sep 25 00:42:13 Repaired Mesh
Sep 25 00:42:13 Draggo ^Lreset his car (FXR)
Sep 25 00:57:09 Draggo : ^L^J™ ‚r‚n‚q‚q‚x ™ ™ ‚m‚n ‚o‚q‚n‚a‚k‚d‚l ™
Sep 25 00:59:07 Draggo : ^L^J™ ‚r‚n‚q‚q‚x ™^H¡¸^S¡î^K¡Ù ^^^J™ ‚m‚n ‚o‚q‚n‚a‚k‚d‚l ™
Sep 25 01:00:04 Draggo ^Lreset his car (FXR)
Sep 25 01:02:04 Draggo : ^L^J™š ‚` š™ ^H¡¸¡¹ ¢Ð¡¹¡¸ ^S¡î¡ï £Ã¡ï¡î ^K¡Ù¡Ú £Ä ¡Ú¡Ù
Sep 25 01:02:40 Draggo ^Lreset his car (FXR)
Sep 25 01:19:49 Draggo : ^L^J™‚k‚`‚k‚`™ ™‚k‚`™
Sep 25 01:20:00 Draggo ^Lreset his car (FXR)
Sep 25 01:23:11 Draggo : ^L^J™‚k‚`‚k‚`™ 2^^2™‚k‚`™
Sep 25 01:27:03 Draggo ^Lreset his car (FXR)
Sep 25 01:27:07 Draggo : ^L^J™‚k‚`‚k‚^™ 2^^^™‚k‚^™
Sep 25 01:27:07 InSim guest closed : ClaViCo
Sep 25 01:37:54 Leave @ 2262791 : Draggo
Sep 25 01:37:54 Draggo^L disconnected (Draggo)

This bug is paradise for trolls, I hope you will fix it soon

FGED GREDG RDFGDR GSFDG