I'll look into this, it might be a bug, not sure yet.
Yeah, I read about this. From a InSim.NET point of view it means you won't need to use Mono to run it on Linux and Mac anymore, there will be an official .NET runtime you can use. Also Visual Studio Community is very interesting as well, as it has all the same features and functionality as Visual Studio Professional, which is normally very expensive. It's basically like they are going to give away Professional for free now.
OK - that is a bug, thanks! I've fixed it and uploaded a new release to NuGet and GitHub.
I made a mistake with the last NuGet release, the binary was 2.1.0 when it should have been 2.1.1.
To fix this I have released InSim.NET 2.1.2, which is just the previous version with a couple of very small tweaks.
The release on GitHub wasn't affected.
To fix this I have released InSim.NET 2.1.2, which is just the previous version with a couple of very small tweaks.
The release on GitHub wasn't affected.
Yeah I improved the Mono support a lot in a recent release. It should work identically except that on Mono the string encoding is a bit slower. Glad it works anyway.
Last edited by DarkTimes, .
I finally got around to moving the tutorials over to the new GitHub site!
https://github.com/alexmcbride/insimdotnet/wiki
https://github.com/alexmcbride/insimdotnet/wiki
I think that every single person makes this mistake when they first start TCP programming. 
I believe the drivers have lights on their steering wheel that advise them of yellow or blue flags.
I released InSim.NET 2.1.1 onto GitHub and NuGet.
Changes
Alternatively I added a new HandicapHelper class to the Helpers namespace which makes it easier to use:
You can also set CarFlags.All to set the handicap for all cars:
Changes
- Added new IS_HCP packet and HandicapHelper class.
- Added ContinueOnCapturedContext property to InSim, OutSim, OutGauge, TcpSocket and UdpSocket. Setting this to false prevents InSim.NET from marshalling packet callbacks back onto the calling thread e.g. in UI apps.
- Fixed bug that allowed players to crash InSim.NET by typing characters in LFS that were not translatable into unicode.
- TcpSocket and UdpSocket now expose their underlying .NET Socket objects for convenience.
var hcp = new IS_HCP();
// Set handicap for XF GTI
hcp.Info[0].H_Mass = 50;
hcp.Info[0].H_TRes = 20;
// Set handicap for XR GT
hcp.Info[1].H_Mass = 20;
hcp.Info[1].H_TRes = 30;
// etc.
// Send packet.
insim.Send(hcp);Alternatively I added a new HandicapHelper class to the Helpers namespace which makes it easier to use:
// Create packet.
var hcp = new IS_HCP();
// Set handicaps for specified cars.
HandicapHelper.SetHandicap(hpc, CarFlags.XFG | CarFlags.XRG, H_Mass: 50, H_TRes: 20);
// Send packet to LFS.
insim.Send(hcp);
You can also set CarFlags.All to set the handicap for all cars:
HandicapHelper.SetHandicap(hpc, CarFlags.All, H_Mass: 50, H_TRes: 20);
Last edited by DarkTimes, .
It's not a bug as it doesn't change the behaviour of the program, but it is clearly a mistake. I've updated the code on GitHub, thanks!
I agree, I would like to keep the packets as close to LFS as possible and use the helpers for this kind of extra stuff.
The alternative would be to create some kind of helper like this:
It's late tonight, I will think about it and figure something out tomorrow.
Edit: BTW I have noted the problem with updating number plates and will look into it before the beta is released.
The alternative would be to create some kind of helper like this:
var hpc = new IS_HPC();
HandicapHelper.SetHandicap(hpc, CarFlags.XFG | CarFlags.XRG, T_Mass = 50, H_TRes = 20);
insim.Send(hpc);It's late tonight, I will think about it and figure something out tomorrow.
Edit: BTW I have noted the problem with updating number plates and will look into it before the beta is released.
Yes I'm thinking about some kind of helper method on the class like:
Maybe you could combine them in order to set multiple cars at a time.
Or it might be better to add this as a helper class. I'll think about it.
hcp.SetHandicap(CarFlags.XFG, T_Mass = 50, H_TRes = 20);Maybe you could combine them in order to set multiple cars at a time.
hcp.SetHandicap(CarFlags.XFG | CarFlags.XRG, T_Mass = 50, H_TRes = 20);Or it might be better to add this as a helper class. I'll think about it.
I added the new packet and pushed it to GitHub, not massively tested it yet so might still have some problems, seems to work OK though. I will add it to the beta tomorrow as it's a bit late tonight.
Here is how you use it:
There might be a better way to specify which car you want to modify as remembering the index for each one will be very difficult.
Here is how you use it:
var hcp = new IS_HCP();
// Set handicap for XF GTI
hcp.Info[0].H_Mass = 50;
hcp.Info[0].H_TRes = 20;
// Set handicap for XR GT
hcp.Info[1].H_Mass = 20;
hcp.Info[1].H_TRes = 30;
// etc.
// Send packet.
insim.Send(hcp);There might be a better way to specify which car you want to modify as remembering the index for each one will be very difficult.
Last edited by DarkTimes, .
That version of InSimDotNet.dll is from back in August, did you try it with the updated DLL in my last post?
The DLL in my last post is an updated one with a fix for this exploit, if you could try that one in your project and report if the issue is fixed or not. It seems to be fixed in my tests but I need someone to confirm it.
The DLL in my last post is an updated one with a fix for this exploit, if you could try that one in your project and report if the issue is fixed or not. It seems to be fixed in my tests but I need someone to confirm it.
Is this with the latest code from the GitHub repository? I have been able to recreate this bug (finally) but only in the current stable release, it doesn't seem to happen for me in the updated code I pushed to GitHub.
Last edited by DarkTimes, .
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.
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.
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.
Last edited by DarkTimes, .
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.
Last edited by 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.
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.
FGED GREDG RDFGDR GSFDG