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 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
Download
You can download the beta from GitHub or using the NuGet Package Manager.
Please let me know if you have any problems.
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
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.
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.
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)
<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.
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.
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.
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
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.
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.)
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.)
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.
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.
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.
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.
On Windows server 2012 I encountered the following causing InSim.NET to crash:
Could this be related to that infamous exploit?
EDIT
I suppose this wont be of much help?
onecheque say "☆SORRY☆☆NO PROBLEM☆". He bind that.
In LFSLazy log its look like this (in LFS Japanese code page 81/82):
this part
is the problem
and sorry sicotange i kill your insim when i try to reproduce this bug
In LFSLazy log its look like this (in LFS Japanese code page 81/82):
this part
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.
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.
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:
This bug is paradise for trolls, I hope you will fix it soon
This bug is paradise for trolls, I hope you will fix it soon
.NET - InSim.NET - InSim library
(759 posts, started )
FGED GREDG RDFGDR GSFDG