No, I meant a .NET 6 version of InSim.NET 2.x.x, which basically already exists in the core branch.
It's not a question of having different nuget packages, it's about having to support different versions. Each time there is an InSim change I will have to update four versions, which I'm not going to do. I don't see any point in supporting any other version than .NET 6 from now on.
It's not a question of having different nuget packages, it's about having to support different versions. Each time there is an InSim change I will have to update four versions, which I'm not going to do. I don't see any point in supporting any other version than .NET 6 from now on.
I've merged the PR and made a new branch for net6.
There's too many versions now though, so I want to simplify it as I don't see a reason to support anything other than .NET 6.
Currently there are:
There's too many versions now though, so I want to simplify it as I don't see a reason to support anything other than .NET 6.
Currently there are:
- master - .NET 4.5 version of InSim.NET 2.x.x (nuget package)
- core - .NET Core version of InSim.NET 2.x.x
- core-version-3 - .NET Core version of InSim.NET 3.x.x
- net6 - .NET 6 version of InSim.NET 3.x.x
- master - .NET 6 version of InSim.NET 2.x.x (nuget package)
- version3 - .NET 6 version of InSim.NET 3.x.x
- legacy - the current master which will no longer receive updates
Also I haven't coded in .NET for years, I'm a Java developer these days, so I don't really understand all the different versions of it and how they fit together anymore.
To test out the changes to support mods I would need to buy S3, which is not expensive of course but still trying to figure out whether I want to buy an update to a game I don't play anymore. 
Yeah that's fine.
I was going to update the nuget release at some point once it was stable.
I was going to update the nuget release at some point once it was stable.
OK I've merged it. You better check it looks alright as the process was a bit confusing!
Ah, would it be better to branch from a different version?
Hey, thanks for your work on this.
I have made a new branch called net5 that you should be able to make a PR for.
https://github.com/alexmcbride/insimdotnet/tree/net5
I have made a new branch called net5 that you should be able to make a PR for.
https://github.com/alexmcbride/insimdotnet/tree/net5
So I started porting it to Python 3, at least a bit. I made a new branch and got it basically running with packets being both received and sent. There are some issues to work out, specifically how it should handle string encoding. As always with LFS it's the major blockage. Converting everything to 'latin1' doesn't work as LFS supports more types of encoding than that. Right now in my branch you need to make everything a byte string, by putting a 'b' in front of it e.g. b'Hello'.
Anyway, I spent a worryingly long amount of time on the issue with the IS_ACR packet throwing an error on line 2024. Seems like it was a Python 3 error.
Should be:
That works for me in my branch.
https://github.com/alexmcbride/pyinsim/tree/port-to-python3
Anyway, I spent a worryingly long amount of time on the issue with the IS_ACR packet throwing an error on line 2024. Seems like it was a Python 3 error.
self.Text = struct.unpack('%dsx' % self.Size - 9, data[8:])Should be:
self.Text = struct.unpack('%dsx' % (self.Size - 9), data[8:])[0]That works for me in my branch.
https://github.com/alexmcbride/pyinsim/tree/port-to-python3
I don't have time sorry. I do accept pull requests if anyone wants to contribute their changes.
It's worth noting that InSim does not change often so InSim libraries do not need to change often either. 
I feel like it's fairly up to date, as last year I merged in a bunch of updates from Degats and also fixed some bugs. Exactly what is included vs missing I couldn't say for sure. If there is anything important needed it should not be hard to add.
OK - I've fixed that IS_MSO bug in pyinsim.
Someone pointed out that the NuGet package was massively out of date, so I updated it to the the latest code on GitHub. Let me know if there are any problems.
OK thanks - I fixed that error and updated the repo on GitHub.
OK thanks, I've fixed that error on Github.
Last edited by DarkTimes, .
OK - cool.
I noticed there was an update for VS, so I updated it to the latest version, and that seems to have done the trick. Not sure what was going on before.
I'm on VS 2017 15.1 (26403.7) and it's working now.
I noticed there was an update for VS, so I updated it to the latest version, and that seems to have done the trick. Not sure what was going on before.
I'm on VS 2017 15.1 (26403.7) and it's working now.
I don't know, I get the same error now, but no idea why. It was working for me when I created it, now it doesn't work at all.
I have to say, I absolutely hate .NET Core, I find it so confusing and hard to use.
I have to say, I absolutely hate .NET Core, I find it so confusing and hard to use.
Someone was asking a while back for a version of InSim.NET compatible with .NET Core. I recently made the changes needed to get it working on .NET Core.
You can find it here: https://github.com/alexmcbride/insimdotnetcore
This is not super tested or supported, but I will obviously fix bugs or issues people have. If you don't know or care what .NET Core is then don't use this!
There are a few breaking changes in this version, mainly that you can no longer call InSim.Initialize(), you have to use InSim.InitializeAsync(). This change is because TcpClient.Connect() was removed from .NET, for some reason.
Additionally I decided to switch the string encoding over the new one that I had written, which was/is not massively tested. Basically this string conversion stuff still converts bytes to unicode and back again, but it does not otherwise mess with the strings, so it leaves language, colour, and escape codes in there. You can use the StringHelper Strip() and Escape()/Unescape() methods if you want to display strings in your own UI. I didn't want to have multiple different versions of the string encoding stuff to maintain. Also I needed to make some changes to how the strings worked to make sure it ran without problems on Mac and Linux, as I wanted to ditch the interop stuff once and for all.
As I say, use at own risk.
You can find it here: https://github.com/alexmcbride/insimdotnetcore
This is not super tested or supported, but I will obviously fix bugs or issues people have. If you don't know or care what .NET Core is then don't use this!
There are a few breaking changes in this version, mainly that you can no longer call InSim.Initialize(), you have to use InSim.InitializeAsync(). This change is because TcpClient.Connect() was removed from .NET, for some reason.
Additionally I decided to switch the string encoding over the new one that I had written, which was/is not massively tested. Basically this string conversion stuff still converts bytes to unicode and back again, but it does not otherwise mess with the strings, so it leaves language, colour, and escape codes in there. You can use the StringHelper Strip() and Escape()/Unescape() methods if you want to display strings in your own UI. I didn't want to have multiple different versions of the string encoding stuff to maintain. Also I needed to make some changes to how the strings worked to make sure it ran without problems on Mac and Linux, as I wanted to ditch the interop stuff once and for all.
As I say, use at own risk.
I missed an InSim release last year, which is why this packet wasn't included. I don't check the forum often, so had been relying on people notifying me when any InSim changes are made.
I released a new version of InSim.NET (2.3.2) which lets you set the car switches like this:
There are more options available in the LocalCarSwitches class. Hope it works!
I released a new version of InSim.NET (2.3.2) which lets you set the car switches like this:
<?php
// Turn siren on
insim.Send(new IS_SMALL
{
SubT = SmallType.SMALL_LCS,
UVal = LocalCarSwitches.LCS_SIREN_SLOW
});
// Turn multiple switches on (horn & flash) with bitwise OR operator
insim.Send(new IS_SMALL
{
SubT = SmallType.SMALL_LCS,
UVal = LocalCarSwitches.LCS_HORN_1 | LocalCarSwitches.LCS_FLASH_ON
});
// You can turn switches off as well
insim.Send(new IS_SMALL
{
SubT = SmallType.SMALL_LCS,
UVal = LocalCarSwitches.LCS_HORN_OFF
});
?>
Hey all,
It seems I missed a patch last year, which added the SMALL_LCS packet, plus the ISS_DIALOG and ISS_TEXT_ENTRY options for StateFlags. I have added SMALL_LCS to the SmallType enum, but I also added a class called LocalCarSwitches, that helps you with setting these options. It is just constants for the various values, which you can set for UVal.
Which will sound the horn and flash the lights etc.
I've updated GitHub, will put out a new version soon.
Edit: new version out on GitHub and NuGet.
It seems I missed a patch last year, which added the SMALL_LCS packet, plus the ISS_DIALOG and ISS_TEXT_ENTRY options for StateFlags. I have added SMALL_LCS to the SmallType enum, but I also added a class called LocalCarSwitches, that helps you with setting these options. It is just constants for the various values, which you can set for UVal.
<?php
// Turn siren on
insim.Send(new IS_SMALL
{
SubT = SmallType.SMALL_LCS,
UVal = LocalCarSwitches.LCS_SIREN_SLOW
});
// Turn horn and lights on
insim.Send(new IS_SMALL
{
SubT = SmallType.SMALL_LCS,
UVal = LocalCarSwitches.LCS_HORN_1 | LocalCarSwitches.LCS_FLASH_ON
});
// Turn horn off
insim.Send(new IS_SMALL
{
SubT = SmallType.SMALL_LCS,
UVal = LocalCarSwitches.LCS_HORN_OFF
});
?>
I've updated GitHub, will put out a new version soon.
Edit: new version out on GitHub and NuGet.
Last edited by DarkTimes, .
It looks to be more than just the timers, here's a report from the portability analyser, looks like everything with an X in the .NET Core column would need changed.
I'll look into what can be fixed, but I can't promise anything, I'm not prepared to sink a lot of time into this to be honest.
I'll look into what can be fixed, but I can't promise anything, I'm not prepared to sink a lot of time into this to be honest.
Make sure your project targets .NET Framework rather than .NET Core (check project properties).
.NET Core has just been released, I've not taken any time to look at it yet, but from that message it appears InSim.NET doesn't support it.
.NET Core has just been released, I've not taken any time to look at it yet, but from that message it appears InSim.NET doesn't support it.
That's the way that packet was designed to be used. I have pushed a commit to the repo that makes IS_JRR.StartPos publicly settable if you want to go that route, it will be in the next release whenever that may be. But anyway, the example a couple of posts up is correct.
In answer to the other question you PMed me, the async methods are useful because they do not block the thread they are called from. Network operations can often take some time to complete, and so calling an async method allows other work to continue while waiting for a network operation to finish. They are most useful inside of GUI apps which operate on a single thread, using async prevents the main UI thread from hanging while waiting for a network response. Lookup the .NET async/await pattern if you want to know more about this important area.
In answer to the other question you PMed me, the async methods are useful because they do not block the thread they are called from. Network operations can often take some time to complete, and so calling an async method allows other work to continue while waiting for a network operation to finish. They are most useful inside of GUI apps which operate on a single thread, using async prevents the main UI thread from hanging while waiting for a network response. Lookup the .NET async/await pattern if you want to know more about this important area.
I'll look into it, maybe not for a little while though, I have a lot on right now.
FGED GREDG RDFGDR GSFDG