Hello all,

Obviously it has been a few years since I last posted here or since I updated InSim.NET. I was spending too many hours online and had to sever some connections in order to return to a semblance of normality.

After some consideration I decided that I would like to create a new version of InSim.NET. It's one of the most popular programs that I wrote and probably the most in need of some updates. There have been quite a few improvement suggestions made in this thread over the years and I plan to go through each one and consider it in turn.

That will take a long time and not every post can be replied to, so if you have a pet issue or improvement then please repost it so I can take a better look. Obviously not all problems need fixing, a cursory look at the last couple of years show mostly general programming problems rather than actual issues with the API. That said there are also some pretty big errors with the API that need fixing too.

There is a donation page on codeplex which no one has ever used. If you find the library useful or want to make its development more attractive then feel free to donate. No pressure. Bare in mind that people in the past have sold programs for money that contained open source code that I wrote without any acknowledgement. Decompiler's don't lie. Just saying.

If anyone experienced in C# and InSim would like to help with development then that would be awesome. Note: InSim is simple to learn.

TL;DR: I'm planning to make a new version of InSim.NET, so now is the time to get your personal bug or feature sorted.

Thanks,

DT.

Welcome back!

Great news! I'm still smitten with InSim.NET and have been coding plenty features around it for the past few years. Get ready for some requests, suggestions and general coding help inquiries. I will make a small (sadly small) contribution once I get home but might consider a bigger one when InSim.NET S2 is reality.

Glad you are back in business (right on time for upcoming LFS patch(es))!

OK - I look forward to hearing any suggestions you may have,

First thing I decided to do was to move development over to GitHub, as that seems the easiest place to do things at the moment, and also because Visual Studio now has git support built in. All future development will happen there.

https://github.com/alexmcbride/insimdotnet

I uploaded the latest release which was 2.0.14b.

Wellcome back

Quote from DarkTimes :

I uploaded the latest release which was 2.0.14b.

Nice. I like to see you will continue from 2.0.14b and I hope you keep compatibility without need to rewrite our insims..

Some suggestions, I already have them in my compiled version:

1º Remove kernel32 dependency to be able to run under mono / linux, https://www.lfsforum.net/showt ... php?p=1787806#post1787806
2º Repair minor bugs reported in https://www.lfsforum.net/showt ... php?p=1818728#post1818728 and https://www.lfsforum.net/showt ... php?p=1819666#post1819666
3º In TyreEnums, add TYRE_NONE and set values to enums.. http://pastebin.com/Bw771mkf
4º AXM minor bug, http://insimdotnet.codeplex.co ... ol/changeset/0e087537e78b that you already fixed in a later 2.0.14b version
5º And finally, http://insimdotnet.codeplex.co ... ol/changeset/2ebde9135b8f add this too.
6º http://insimdotnet.codeplex.co ... ol/changeset/9911c0d34bbd

I think this six changes would be a nice start point to continue improving the insim..

Regards

OK thanks. I have fixed those bugs that you mentioned and pushed the changes to the GitHub repository. I will create a new release when I have confirmed that they are working correctly.

In terms of the Mono fix I'm not too sure about that yet. The reason I didn't implement the code in that way originally was because it's insanely slow, also using exceptions as flow control is really messy and not something I'm happy doing. The interop method using WideCharToMultiByte is literally one hundred times faster than throwing an exception for every character. I'll need to think carefully about how I'm going to fix this as I would like the library to work on Mono but I'm not a fan of this method.

One change I might make is to ditch the .NET 3.5 version and just focus on .NET 4.5. Is anyone really attached to the .NET 3.5 version?

My 2 insims are in 3.5 but I think I could change it to 4.5 without problem..

About mono, a possible temporal solution could be instead of throwing an exception when linux/mono try to execute that function, use the one slower but compatible?

Looking at the proyect, I see the file "LfsEncoding.cs", that file didnt exist in 2.0.14b, Are you sure you uploaded 2.0.14b? Checking http://insimdotnet.codeplex.co ... ceControl/list/changesets

Regards

Quote from NeOn_sp :

About mono, a possible temporal solution could be instead of throwing an exception when linux/mono try to execute that function, use the one slower but compatible?

Yes, this is what I'm going to try. I have already implemented this in my own local repository, but I will need to download Mono to test it before I'll know for sure if it really works. Detecting if you are running on Mono is actually very easy.

Quote :

Looking at the proyect, I see the file "LfsEncoding.cs", that file didnt exist in 2.0.14b, Are you sure you uploaded 2.0.14b? Checking http://insimdotnet.codeplex.co ... ceControl/list/changesets

The source code on GitHub is the latest source code from Codeplex. I cloned the Codeplex repo and then pushed it to GitHub. The LfsEncoding.cs file used to be called EncodingHelper.cs but was renamed back in June 2012.

I don't mind ditching .NET 3.5 at all. I'm looking for a file which contained notes about InSim.NET I took over the years. It was a long list but only recently, a few months ago I started having instability issues. Because I'm not sure yet what causes the crashes I can't blame InSim.NET. A foolproof/bulletproof socket would be neat.

Do you already have a vague idea of what you are planning to improve or what you are willing to achieve with the new version?

Quote from sicotange :

A foolproof/bulletproof socket would be neat.

What do you mean, is there a problem with the socket code?

Quote :

Do you already have a vague idea of what you are planning to improve or what you are willing to achieve with the new version?

Right now I'm just planning to fix bugs and get it working on Mono.

I have pushed the changes to the string encoding to GitHub. The library now detects if it's running on Mono and uses the slower form of string encoding throwing exceptions, on Windows it still uses the much faster WideCharToMultiByte method.

I have tested it on Mono using Ubuntu 14 and it seems to work correctly. It needs more testing though so I'm not going to create a new release just yet. If someone who uses InSim.NET on Mono could clone the repo and test it out that would be great!

Quote :

What do you mean, is there a problem with the socket code?

So far I'm not really sure, I'm merely speculating. It would be nice to have a more elaborate "DisconnectReason" to know why exactly the connection was lost although "InSimErrorEventArgs" is already pretty useful.

Quote from sicotange :

So far I'm not really sure, I'm merely speculating. It would be nice to have a more elaborate "DisconnectReason" to know why exactly the connection was lost although "InSimErrorEventArgs" is already pretty useful.

Sadly there isn't that much information about why it disconnected, all you can say is that the socket closed, it doesn't give you a reason.

Perhaps unrelated to InSim.NET but it would be nice to have a button "manager". At the moment I'm breaking my head to find a way to deal with buttons accordingly. My InSim app has many button calls and it can impact performance as well as stability (LFS dedi reporting INSIM LIMIT).

A neat way to buffer buttons and manage ID's as well as ButtonClick flag events would be nice. Perhaps a feature in InSim.NET reporting bandwidth usage could help too. It would help making stable InSim apps.

I have been working on .NET about 2 years, But still can't get complete cruise InSim, then i restart from 0.

Can you just add to that 'Great' Sample you made long time ago save system pls, i will be so thankful!

I know it's not time for that DK, but we are just bunch of nubs, and you are our coding leader, so help us little ^^

Regards..

I didn't make that sample. I'll look at adding a save system to it at some point but as I've never looked at it before I don't know how hard that will be. I think you mean that DarkKostas is your coding leader.

Quote from sicotange :

Perhaps a feature in InSim.NET reporting bandwidth usage could help too. It would help making stable InSim apps.

Hmm, that's not a bad idea. Certainly it would be easy to keep track of how many bytes had been sent and received. Then you could check the bandwidth usage over time, warn if it goes over a certain amount etc.. I'll take a look into it.

Quote from HonzaQ4 :

I have been working on .NET about 2 years, But still can't get complete cruise InSim, then i restart from 0.

Can you just add to that 'Great' Sample you made long time ago save system pls, i will be so thankful!

I know it's not time for that DK, but we are just bunch of nubs, and you are our coding leader, so help us little ^^

Regards..

Hello mate and thanks for your kind words. These days i don't have much time so i can't just go and post my MySQL based saving file, but i think i had posted some detailed information somewhere on how to make or even that file as well. I'll do a quick search on my posts and say if i find something. You can PM me in ~a week if you didn't find a thing and i may be able to help you further

Quote :

Certainly it would be easy to keep track of how many bytes had been sent and received. Then you could check the bandwidth usage over time, warn if it goes over a certain amount etc..

That's exactly what I meant but explained better It would help to see "bursts" of bandwidth usage in order to identify bottlenecks etc.


I still haven't fixed my button "overflow" issue. Finding the best way to send a page of 100 buttons to each player at the same time isn't easy. Batch sending packets progressively using a buffer is more likely more your cup of tea than mine

I updated the GitHub repo with some internal changes to TcpSocket and UdpSocket. I refactored both to use the async/await pattern which reduces the complexity of the code with little or no performance reduction. This means that the code no longer compiles without .NET 4.5. Again if anyone has a major objection I can go back, but I'd like to maintain the tradition of targeting the latest version of .NET.

I also added BytesSent and BytesReceived properties to the InSim class, which track the total number of bytes transferred since the connection was initialized (for both TCP and UDP). I'm not sure whether to provide just these properties and let users figure out how much bandwidth they're using themselves, or if there is some standard way people would like this information presented. It seems that once you have the raw data (bytes sent/received) what you do with it is up to you, I'm not sure there is a one size fits all implementation, unless anyone has a better idea?

Great stuff I will look into it once I get the opportunity to do so. In hindsight it might be wise to leave this up to us but perhaps somewhere in between, providing documentation or an example on how to make use of it instead.

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...

Either way you are the best placed to suggest how to use it elegantly and whatever you decide I will gladly make use of this new possibility

Quote :

I also added BytesSent and BytesReceived properties to the InSim class, which track the total number of bytes transferred since the connection was initialized (for both TCP and UDP).

I have now tested these changes:

1) Could it be useful to separate TCP and UDP? I suppose not otherwise you would have done so.


2) If someone happens to know what these mean exactly (reported in the LFS dedi log file)? I presume it is related to the buffers?

Quote :

Jul 30 16:05:14 TCP ERROR : MESSAGE LIMIT
Jul 30 16:05:14 TCP ERROR : MESSAGE LIMIT
Jul 30 16:05:14 INSIM ERROR : MESSAGE LIMIT
Jul 30 16:05:14 TCP ERROR : MESSAGE LIMIT
Jul 30 16:05:14 TCP ERROR : MESSAGE LIMIT
Jul 30 16:05:14 INSIM ERROR : MESSAGE LIMIT
Jul 30 16:05:15 TCP ERROR : MESSAGE LIMIT
Jul 30 16:05:16 TCP ERROR : MESSAGE LIMIT
Jul 30 16:17:25 TCP ERROR : INSIM LIMIT
Jul 30 16:17:25 TCP ERROR : INSIM LIMIT
Jul 30 16:17:25 TCP ERROR : INSIM LIMIT

OK - I made TcpSocket and UdpSocket available as public properties on the InSim class. That means if you want to access them separately you can do all these:


I pushed the changes to GitHub.

Can i receive players ping info? skins names? or when someone turns off his engine?

Quote from HonzaQ4 :

Can i receive players ping info? skins names? or when someone turns off his engine?

No, Yes, No(you can through outgauge, if rpm <500 or something).
For skinname

I haven't had any reports of any issues with the latest changes in the GitHub repository, so unless anyone has any objections I'll push out a beta release later today. I'd like to get a release out before the end of the week as I'm going to be quite busy after that for a little while.

I plan to produce just a single DLL compiled for .NET 4.5. I will also look at creating a pre-release version for NuGet, although it's been so long since I created that package I don't remember how to do it.

I'm not sure what the version number will be, I suppose as this only contains minor fixes it should be 2.0.15, although I'm tempted to make it 2.1.0 just because so much time has passed since the last release.