I pushed out a release of InSim.NET 2.1.0 to GitHub and NuGet. Let me know if there are any problems.
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.
Last edited by DarkTimes, .
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.
Last edited by DarkTimes, .
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.
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.
Last edited by DarkTimes, .
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.
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.
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.
insim.BytesReceived
insim.BytesSent
insim.TcpSocket.BytesReceived
insim.TcpSocket.BytesSent
insim.UdpSocket.BytesReceived
insim.UdpSocket.BytesSent
I pushed the changes to GitHub.
Last edited by DarkTimes, .
Reason : typo
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?
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?
Last edited by DarkTimes, .
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. 
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.
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.
Last edited by DarkTimes, .
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.
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!
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!
What do you mean, is there a problem with the socket code?
Right now I'm just planning to fix bugs and get it working on Mono.
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.
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.
Last edited by DarkTimes, .
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?
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?
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.
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.
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.
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.
Last edited by DarkTimes, .
I haven't touched SparkCruise for years, it was intended as an example program, nothing else. It uses an old version of InSim.NET that isn't supported anymore, and I don't even think I have the source code for it. As MadCatX says there must be a bug in the IS_STA handler that causes it to crash.
I don't understand the question. Please explain exactly what the problem is with as much detail as possible.
I don't know what the problem is. Does this piece of code work on its own?
Just create a new console application, paste that into the main method and run it.
<?php
var ts = TimeSpan.FromSeconds(123.456);
Console.WriteLine(ts.ToString(@"mm\:ss\.fff"));
?>
All times in InSim.NET are represented by .NET TimeSpan structs, so you can specify a custom format for them.
For instance if you wanted to output the lap time, you could do:
That would output the time the same way as LFS does in game, which would be "1:23.374".
For instance if you wanted to output the lap time, you could do:
<?php
void LapCompleted(InSim insim, IS_LAP packet) {
var lapTimeStr = packet.LTime.ToString(@"mm\:ss\.fff");
Console.WriteLine(lapTimeStr);
}
?>
I don't need a credit for that fix, it was just an observation. I didn't actually fix the bug, I just noticed it when I was trying to figure out how to implement something similar in pyinsim. I think I probably do have a GitHub account, but I don't know how to use it.
The unreleased stuff in the repository is untested and buggy, so I don't recommend using it unless you're keen to help deal with these sorts of issues. It may be that the WeakReference stuff is implemented incorrectly, it was an experiment and I guess I'll have to reevaluate it. I thought I was using it correctly, but frankly it's been a while since I worked on it and I must have been wrong. In general I suggest using the source code from the last released version of the library, as that should be relatively bug free. Alternatively you could copy back in the old version of the BindingManager.cs file, but I think you might have to make a few other changes to the code in order to get it to compile correctly.
You probably have controls on the form. The form never gets focus if there are controls on it, as the focus gets automatically passed to the first control in the tab index. Instead you should use the form's Activated and Deactivate events.
Crisis averted. If I'm reading through all the marketing speech correctly.
http://blogs.msdn.com/b/visual ... -for-windows-desktop.aspx
http://blogs.msdn.com/b/visual ... -for-windows-desktop.aspx
Sadly, it has been confirmed. They outlined details about the different product lineups on the Visual Studio blog a couple of weeks ago.
http://blogs.msdn.com/b/visual ... and-platform-support.aspx
Also you only need to look at the Express Edition product page to confirm it.
http://www.microsoft.com/visua ... 11/en-us/products/express
It lists only Metro and Web Express for download, then says at the bottom, "To create desktop apps, you need to use Visual Studio Professional 2012, or higher."
http://blogs.msdn.com/b/visual ... and-platform-support.aspx
Also you only need to look at the Express Edition product page to confirm it.
http://www.microsoft.com/visua ... 11/en-us/products/express
It lists only Metro and Web Express for download, then says at the bottom, "To create desktop apps, you need to use Visual Studio Professional 2012, or higher."
FGED GREDG RDFGDR GSFDG