Sure feel free to have a go. 
If not then I'll do it tomorrow.
If not then I'll do it tomorrow.
Still haven't looked enough into GitHub but I can still make 1 small contribution (see attachment). The files attached are those I made or modified. The other files remain untouched.
NOTE: Can you check IS_TTC.cs in debt? I have tested my implementations and IS_TTC seems to work well (replied by IS_AXM etc.). Can you still double check as I am not 100% confident of what I modified.
I'm almost certain BulbInfo is still bugged. Setting main start lights works half but certainly not correctly.
NOTE: Can you check IS_TTC.cs in debt? I have tested my implementations and IS_TTC seems to work well (replied by IS_AXM etc.). Can you still double check as I am not 100% confident of what I modified.
I'm almost certain BulbInfo is still bugged. Setting main start lights works half but certainly not correctly.
OK thanks, I just had a quick glance at it, but it looks fine. You missed one little thing though, before InSim.NET will handle that packet you need to add it to the PacketFactory. I'll look at it in more detail when I get home this evening.
I reckon the BulbInfo works fine, if you set Red1 it enables the innermost light, Red2 turns on the middle light, Red3 turns on the outermost light, and Green turns on the green light. You need to remember that these are bit flags, so if you want to combine lights you'll need to combine flags.
So if you wanted to turn on all lights at once you'd do:
If you wanted to turn on just the inner and outermost red lights you'd do:
That's how it seems to work for me anyway. I'm not sure about the AutoX lights, I might need to ask Scawen to explain exactly how they're supposed to work.
I reckon the BulbInfo works fine, if you set Red1 it enables the innermost light, Red2 turns on the middle light, Red3 turns on the outermost light, and Green turns on the green light. You need to remember that these are bit flags, so if you want to combine lights you'll need to combine flags.
So if you wanted to turn on all lights at once you'd do:
Data = BulbInfo.Red1 | BulbInfo.Red2 | BulbInfo.Red3 | BulbInfo.Green;If you wanted to turn on just the inner and outermost red lights you'd do:
Data = BulbInfo.Red1 | BulbInfo.Red3;That's how it seems to work for me anyway. I'm not sure about the AutoX lights, I might need to ask Scawen to explain exactly how they're supposed to work.
Ok that seems to work well! However I don't understand the use of:
I still haven't found the issue with IS_OCO for autocross startlights. I was hoping to get this ready for tonight. Anyway, perhaps you will quickly find the problem.
I still haven't found the issue with IS_OCO for autocross startlights. I was hoping to get this ready for tonight. Anyway, perhaps you will quickly find the problem.
The IS_OCO packet works fine, I tested all aspects of it. I don't know what your issue is so you might need to go into more detail. The problem I was having was that I wasn't optimising the layout before trying to use the lights.
Just curious, when a new version of release will be out?
Whenever Scawen releases the new patch. Probably this weekend.
Confirmed, I wasn't aware of that. Somehow never thought of that. It works fine now, but I still have to check when optimising through InSim IS_AXM. I just tested an optimised LFS layout.
Release Plan
I should probably talk about the release plan a bit more fully. Basically whenever Scawen brings out the next patch for LFS I will bring out InSim.NET 2.3.0.
After that I will have to stop working on the library for a bit. I am at college at the moment and I have numerous essays and assessment to complete, as well as having to create working prototypes for two android apps by the end of the month.
I have messed around with a lot of things over the last couple of weeks (EventHelper, BatchHelper etc..), but truth is all that stuff needs much more testing and I don't have the time to do it. So I will remove those classes from the library at the moment. The next release will just be all the new InSim updates.
String Encoding Update
One thing I've not mentioned is the string encoding, I'm happy with my new way of encoding strings but it's complicated at not tested fully, so I don't want to drop it into the library proper yet. Instead what I've done is made it so people can implement their own string encoding. It's always been a large area of contention, everyone seems to think I'm doing it wrong in some way, so I figured I'd let people make their own.
So: LfsEncoding is now an abstract class that implements two abstract methods, GetString and GetBytes. GetString is called when packets are received and converts an array of bytes into a unicode string. GetBytes gets called when packets are being sent and converts a unicode string into an array of bytes.
Once you have implemented your own encoding you can make InSim.NET use it by assigning it to the new LfsEncoding.Current static property.
You should probably do this at the start of your program before you init InSim. All this is optional, if you don't supply a custom encoding InSim.NET defaults to the old one.
The default encoding is called LfsUnicodeEncoding, that's the one people have been using for years (albeit with the big bug fix I talked about last week). However, I also added LfsUnicodeEncoding2 which is my new reworked string handling, so that's there if people want to try it out.
Anyway, that's the plan.
I should probably talk about the release plan a bit more fully. Basically whenever Scawen brings out the next patch for LFS I will bring out InSim.NET 2.3.0.
After that I will have to stop working on the library for a bit. I am at college at the moment and I have numerous essays and assessment to complete, as well as having to create working prototypes for two android apps by the end of the month.
I have messed around with a lot of things over the last couple of weeks (EventHelper, BatchHelper etc..), but truth is all that stuff needs much more testing and I don't have the time to do it. So I will remove those classes from the library at the moment. The next release will just be all the new InSim updates.
String Encoding Update
One thing I've not mentioned is the string encoding, I'm happy with my new way of encoding strings but it's complicated at not tested fully, so I don't want to drop it into the library proper yet. Instead what I've done is made it so people can implement their own string encoding. It's always been a large area of contention, everyone seems to think I'm doing it wrong in some way, so I figured I'd let people make their own.
So: LfsEncoding is now an abstract class that implements two abstract methods, GetString and GetBytes. GetString is called when packets are received and converts an array of bytes into a unicode string. GetBytes gets called when packets are being sent and converts a unicode string into an array of bytes.
Once you have implemented your own encoding you can make InSim.NET use it by assigning it to the new LfsEncoding.Current static property.
LfsEncoding.Current = new MyCustomEncoding();You should probably do this at the start of your program before you init InSim. All this is optional, if you don't supply a custom encoding InSim.NET defaults to the old one.
The default encoding is called LfsUnicodeEncoding, that's the one people have been using for years (albeit with the big bug fix I talked about last week). However, I also added LfsUnicodeEncoding2 which is my new reworked string handling, so that's there if people want to try it out.
Anyway, that's the plan.
Sounds great 
I like this flexibility and LfsUnicodeEncoding2 being optional. Will test it once I get to it.
(Thanks for the IS_SLC update by the way, I'm implementing it to my program right now)
I like this flexibility and LfsUnicodeEncoding2 being optional. Will test it once I get to it.(Thanks for the IS_SLC update by the way, I'm implementing it to my program right now)
OK - another small update. I have implemented something I had intended to for a long time, namely InSim.NET now fully supports the .NET async/await pattern.
So you can do:
And you can do:
The async methods are non blocking and useful when doing things like making GUI apps. All the send methods have been updated to optionally use this pattern.
So you can do:
await insim.InitializeAsync(new InSimSettings {
// init settings
});And you can do:
await insim.SendAsync(new IS_TINY { ReqI=1, SubT=TinyType.TINY_NCN });The async methods are non blocking and useful when doing things like making GUI apps. All the send methods have been updated to optionally use this pattern.
Is any way to know if the car is in gear r or in gear 1 ?
InSim.NET 2.3.0 release out on GitHub and NuGet.
- Updated for LFS 0.6M - a very large number of new packets and changes (see lfs\docs\insim.txt for details)
- Library now uses InSim version 7
- InSim object no longer throws ObjectDisposed exception when being reused to connect to LFS
- Fixed encoding issue that occasionally caused garbled strings to be sent to LFS
- Changed InSim.Send(IEnumerable<ISendable>) method to InSim.Send(params ISendable[]) which provides better syntax
- Fixed missing VIEW_ANOTHER identifier in ViewIdentifiers
- Added new StringHelpers: StripLanguage(string), Strip(string), Unescape(string), and Escape(string)
- Added Rockingham to TrackHelper
One valid complaint I've received in the past is that there aren't many good example InSim.NET programs, so I've written a small one. It is a Windows Forms app that connects to either a local client or a host and outputs all the laps which are completed. As I say very simple stuff. I'll probably try and write some more examples at some point, with more involved stuff like commands and buttons.
You can find the code on GitHub: https://github.com/alexmcbride/insimdotnetexamples
You can find the code on GitHub: https://github.com/alexmcbride/insimdotnetexamples
Many thanks for updating InSim.NET! Now it's up to me to update all my tools... Quite a lot of work waiting for me.
Updated to V2.3 a few days ago. Nothing to report so far I'm eager to play with the new helpers. Thanks for the continuity!
I'm eager to play with the new helpers. Thanks for the continuity!How do I respawn a car using the JRR packet?
Docs say:
So I try this:
But I get the message that StartPos is read-only. The docs say I am supposed to set the StartPos with an ObjectInfo value, but how can I set the value if it's read-only?
I must be understanding something wrong, right?
Docs say:
// IS_JRR can also be used to move an existing car to a different location
// In this case, PLID must be set, JRRAction must be JRR_RESET or higher and StartPos must be setSo I try this:
insim.Send(new IS_JRR { JRRAction = JrrAction.JRR_RESET_NO_REPAIR, PLID=car.PLID, StartPos=<something here> });
But I get the message that StartPos is read-only. The docs say I am supposed to set the StartPos with an ObjectInfo value, but how can I set the value if it's read-only?
I must be understanding something wrong, right?
I faced the same issue. As workaround I composed the packet manually and then I sent it:
var Packet = new IS_JRR();
Packet.StartPos.X = 0;
Packet.StartPos.Y = 0;
Packet.StartPos.Zbyte = 255;
Packet.StartPos.Heading = 0;
Packet.StartPos.Index = 0;
Packet.StartPos.Flags = 0x80;
Packet.PLID = car.PLID;
Packet.JRRAction = JrrAction.JRR_RESET_NO_REPAIR;
insim.Send(Packet);
I don't know if it is the best way to do it, tho.
var Packet = new IS_JRR();
Packet.StartPos.X = 0;
Packet.StartPos.Y = 0;
Packet.StartPos.Zbyte = 255;
Packet.StartPos.Heading = 0;
Packet.StartPos.Index = 0;
Packet.StartPos.Flags = 0x80;
Packet.PLID = car.PLID;
Packet.JRRAction = JrrAction.JRR_RESET_NO_REPAIR;
insim.Send(Packet);
I don't know if it is the best way to do it, tho.
Thanks, that's a good solution for now!
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.
Hi, DarkTimes
insim.net my program by using the library of km drive do you have a sample code I'd like to add?
my english very bad sory
insim.net my program by using the library of km drive do you have a sample code I'd like to add?
my english very bad sory
Someone will have a semaphore in InSim, if I would share it with source to learn how to modify would appreciate!
Good morning. Is possible to know what skin is using a player(skin name) via command(!skin username) ?
Check this: http://en.lfsmanual.net/wiki/InSim.txt
I s3 cruise insim do
I would like to add the bonus money, distance
InSim.Net can help the authorized expert for Admins?
.NET - InSim.NET - InSim library
(758 posts, started )
FGED GREDG RDFGDR GSFDG