Hi sicotange. Sorry for the off topic post but did you get the email I sent you today, about French translation? It's urgent as I will get the final translations for 0.6G tomorrow afternoon (not evening) and that will be it.
I confirm that the French translations will be updated before midnight (GMT). Replying to your email asap.
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.
FYI, the translations mentioned in your email (I replied too) have been updated
The 2 (identical) crashes happened using InSim.NET 2.1.0.0 hereby attached. I asked Draggo to explain how I can reproduce it but I didn't understand his explanations much. If I got it half-right typing a special character in combination with '^' in the chat could cause the crash (?).
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.
I tried it now with Draggo. He could make it crash instantly with Old version. With the New version he hasn't succeeded yet, it seems to be fixed
Yay! 
I'm glad you could fix that exploit rather rapidly Not much to report at the moment, hoping the lib is stable in the long run. I think I may have found another bug though but I don't know if it is related to the recent InSim.NET releases. Either way I can reproduce it in 2.1.0 & 2.1.1. I haven't tested in an older version. The IS_CPR Plate string has difficulties with special characters and '^' doesn't seem to be digested well (unicode issue?).
The following string ^ _ ^ results in _ ^8 for example.
Not much to report at the moment, hoping the lib is stable in the long run. I think I may have found another bug though but I don't know if it is related to the recent InSim.NET releases. Either way I can reproduce it in 2.1.0 & 2.1.1. I haven't tested in an older version. The IS_CPR Plate string has difficulties with special characters and '^' doesn't seem to be digested well (unicode issue?). The following string ^ _ ^ results in _ ^8 for example.
Also could you please implement the new InSim packet introduced with 0.6F12: IS_HCP
// HANDICAPS
// =========
// You can send a packet to add mass and restrict the intake on each car model
// The same restriction applies to all drivers using a particular car model
// This can be useful for creating multi class hosts
EDIT: Actually I might be able to update it myself, looking into it
// HANDICAPS
// =========
// You can send a packet to add mass and restrict the intake on each car model
// The same restriction applies to all drivers using a particular car model
// This can be useful for creating multi class hosts
EDIT: Actually I might be able to update it myself, looking into 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.
Works perfectly so far, thanks :-)
It shouldn't be to difficult if we use a simple GetIndexCar(string); or GetIndexCar(CarFlag);
It shouldn't be to difficult if we use a simple GetIndexCar(string); or GetIndexCar(CarFlag);
(sicotange)
DELETED
by sicotange : I should not write codes when I am tired...
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 think I would prefer to distinguish InSim.NET core code from helpers clearly. But that's from my point of view.
Either way this is indeed clean/neat
Either way this is indeed clean/neat
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.
Btw is this a mini bug (duplication) in PacketFactory.cs?
if (type == typeof(IS_PLC))
return PacketType.ISP_PLC;
if (type == typeof(IS_AXM))
return PacketType.ISP_AXM;
if (type == typeof(IS_AXM))
return PacketType.ISP_AXM;
if (type == typeof(IS_ACR))
return PacketType.ISP_ACR;
if (type == typeof(IR_ARP))
I suppose it doesn't affect anything though.
if (type == typeof(IS_PLC))
return PacketType.ISP_PLC;
if (type == typeof(IS_AXM))
return PacketType.ISP_AXM;
if (type == typeof(IS_AXM))
return PacketType.ISP_AXM;
if (type == typeof(IS_ACR))
return PacketType.ISP_ACR;
if (type == typeof(IR_ARP))
I suppose it doesn't affect anything though.
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 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);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.
Great work as always
Some interesting Microsoft news: http://news.microsoft.com/2014 ... and-visual-studio-online/
InSim.NET stability ensured on Linux :-)?
InSim.NET stability ensured on Linux :-)?
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.
Any ideas when this is going to happen?
I think the .NET cross-platform stuff will be released with Visual Studio 2015, although that's a guess, I don't really know. Visual Studio Community is out now.
There isn't much that doesn't work with Mono anyway. PInvoke into Windows libraries is obviously one, and that isn't going to change.
.NET isn't coming to non-Windows platforms, so Mono isn't going to become obsolete; they will just be able to incorporate code from the .NET framework more easily.
.NET isn't coming to non-Windows platforms, so Mono isn't going to become obsolete; they will just be able to incorporate code from the .NET framework more easily.
.NET - InSim.NET - InSim library
(763 posts, started )
FGED GREDG RDFGDR GSFDG