The online racing simulator
InSim/OutSim/OutGauge lib in .NET
1
(34 posts, started )
#1 - sdether
InSim/OutSim/OutGauge lib in .NET
Since my previous version of the library did not support activating OutGauge via InSim, I went back to integrate my two libraries into a single library. While I was at it, I also added OutSim.

The result is a new library, LFSLib.dll, providing handlers for OutSim, OutGauge and InSim including the ability to get OutSim and OutGauge via the InSim handler.

I've also changed the namespace from LiveForSpeed.* to FullMotion.LiveForSpeed.* so as to not monopolize the LiveForSpeed root namespace

Info, docs, binaries, etc. are all here: http://www.claassen.net/geek/lfs/

Details on what code changes are required between the new and old versions can be found here
#2 - GeForz
insim.txt: You can identify an OutGauge packet by its size (92 bytes) and 4th byte : zero.
your code: else if (bytesReceived == 96 && received[3] == 0)

So it doesn't work like that And if you wold have run your Tester application you would have noticed it
Nevertheless good work


Edit:
I think something is wrong with outgauge

The packet in the file is 96 bytes big, but if you request outgauge through insim you only get 92 bytes whioch means the
"int ID; // (optional ID - if specified in cfg.txt)" is missing => check packet size of 96 and 92.
But if you use outgauge together with insim you receive at least two packets which are "size (92 bytes) and 4th byte : zero". The outgauge packet and the IS_LAP packet!

So I would suggest to move the OutGauge/Outsim check into the switch (receivedId.ToString())'s default part and check both outgauge packet sizes.
#3 - sdether
Ok... I'll go back and check. I did run the Tester and a separate command line tool and things seemed to be working, although i didn't scrutinize the values too closely.
#4 - CrazyICE
nice to see things are going forward
#5 - sdether
Quote from GeForz :I think something is wrong with outgauge

I just tested OutGauge both as standalone (using the tester app) and via InSim (separate console app) and both looked fine. I sanity checked time and ID (first and last bytes) and they came up right and the text values came out right as well.

edit: I just saw your comment that IS_LAP can be mistaken for OutGauge. I'll fix that.

more edit: Also, i saw that you were saying that if optional ID is not specified, it returns no bytes. I always just tested with the ID set and assumed that if it wasn't set i'd still get 4 0 bytes. I just took the Id out and yeah, that breakes my OutGauge. That explains why i always got 96 not 92 bytes like insim.txt said. I just figured it to be a typo. Ok, expect 0.11b today or tomorrow.


OutSim does seem to be broken as well, since i don't get the proper Id. I'll get that done as well by 0.11b
#6 - sdether
I assume this is proper behavior, but i can't seem to get any delay between packets larger than 1 second to work for either outsim or outgauge via insim.

Anyone able to confirm this?
#7 - sdether
0.11b release
#8 - Squelch
This is great work sdether. I'm learning so much from your code.

May I request a downloadable Doc package for us on dialup? Excellent documentation btw
#9 - sdether
#10 - Squelch
That's great. Thank you very much sir.
#11 - Decibel
Any help for a noob ?

I can get the tester app to work with Insim data, but I get nothing using the Outgauge form tester. Do I have to set anything in the LFS cfg.txt for outgauge, or is it handled through Insim (which I assumed) ?

If I need to edit the cfg.txt file, what are the settings ?

Thanks for taking the time
#12 - sdether
Quote from Decibel :Any help for a noob ?

I can get the tester app to work with Insim data, but I get nothing using the Outgauge form tester. Do I have to set anything in the LFS cfg.txt for outgauge, or is it handled through Insim (which I assumed) ?

If I need to edit the cfg.txt file, what are the settings ?

Thanks for taking the time

The OutSim and OutGauge testers are both meant for standalone mode. I think port 30002 and 30003 respectively, using 127.0.0.1 as IP.
#13 - Decibel
Thanks sdether.

I seem to be getting an error ...

"FullMotion.LiveForSpeed.OutGauge.OutGaugeReader: OutGaugeReader started
FullMotion.LiveForSpeed.AbstractLfsPacketReader: A Socket Exception has occurred!System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted
at System.Net.Sockets.Socket.Bind(EndPoint localEP)
at FullMotion.LiveForSpeed.AbstractLfsPacketReader.Listen()
FullMotion.LiveForSpeed.AbstractLfsPacketReader: Started Listener Thread on port 30003
Tester.LFSTesterForm: appender created"

I've set outgauge in the lfs.cgf to IP 127.0.0.1 on port 30003 and i've confirmed it's active using netstat -a.

I can usually persevere with this kind of stuff and get it working, but i'm stumped this time
#14 - sdether
Basically that means something else is already bound to that port. I know I had some trouble on one of my machines that if the Tester didn't shut down properly, it wouldn't release the port. See if the problem continues if you reboot. And make sure you don't have your LFS insim bound to 30003 as well.
#15 - Decibel
That was it ! I had the tester crash on me once (because I restarted LFS while the tester was running) and hadn't rebooted. It was obvious in hindsight DOH illepall Thanks sdether.

The only thing that concerned me was that LFS started to stutter quite badly once the communication was working (the tester was pulling 99% cpu).

If you have a remedy for this or any suggestions, please let me know, otherwise i'm going to break out my VB installation and start playing
#16 - sdether
Quote from Decibel :The only thing that concerned me was that LFS started to stutter quite badly once the communication was working (the tester was pulling 99% cpu).

If you have a remedy for this or any suggestions, please let me know, otherwise i'm going to break out my VB installation and start playing

Can't say I do. I've seen Visual Studio get very hungry in debug mode, but haven't had it happen with the Library tester. I can see it happening if you are limited in RAM. Mind you, the Tester is by no means a best practices approach to writing Windows Forms. Best suggestion I have is try out the lib in a console application and see if the same happens. I certainly wouldn't build your own application based on the GUI code in the Tester, it's just a harness that was thrown together with total disregard for design.
#17 - Tanuva
Is there a little tutorial available, f.e. how to make a program connecting to lfs using the library?
I can't manage to get or set the configuration variables - possibly because I have insufficient knowledge of C# ...
#18 - sdether
Quote from Tanuva :Is there a little tutorial available, f.e. how to make a program connecting to lfs using the library?
I can't manage to get or set the configuration variables - possibly because I have insufficient knowledge of C# ...

At this time the only tutorial is the Tester app, but being a hacky winforms application, that's liable to be more confusing than helpful. I'll try to post a quick console app in the next couple of days
#19 - wabz
very quick example
Here's a snippet of code that connects (doesn't use an xml config file, just hardcoded values) and sends a message. Might get you started:

using FullMotion.LiveForSpeed.InSim;
<snip>
InSimHandler handler = new InSimHandler(true, false);
Configuration config = handler.Configuration;

config.LFSHost = "127.0.0.1";
config.LFSHostPort = 29999;
config.AdminPass = "adminPass";
config.UseSplitMessages = true;
config.UseKeepAlives = true;
handler.Initialize(3); // 3 is the number of seconds to wait for a version reply
handler.SendMessage("Hello world!");
handler.Close();

Note that there exists a bug where the reader thread doesn't stop if the connection fails. Here is a small, stupid patch against InSimHandler.cs which provides temporary relief:


@@ -360,7 +360,12 @@ namespace FullMotion.LiveForSpeed.InSim
{
initWait = wait*1000;
}
- CheckVersion();
+ try {
+ CheckVersion();
+ } catch (InSimHandlerException.NoVersion) {
+ reader.Stop(); //this is the wrong way to fix this, but this non connection kind of error really should have happened a long time ago.
+ throw new InSimHandlerException.NotConnected();
+ }
CheckState();
CheckForKeepAlive();

#20 - Tanuva
Hey, thats good to start from, thanks
-
(MonkOnHotTinRoof) DELETED by MonkOnHotTinRoof
#21 - sdether
Quote from MonkOnHotTinRoof :Very nice library with clear interface. I thought of using it for CityLife project instead of my ugly insim library from LFSLapper, but I am stuck at some problems:

Those are definitely all oversights and things I need to fix.

Quote from MonkOnHotTinRoof : 1 - Library does not support LFS code pages (you are using ascii encoding in all cases which yields wrong conversions with question marks as result ?)

Yeah, i wrote it before the non-latin support (or are accents and umlauts broken as well?) I need to properly evaluate the language support and get the changes in there

Quote from MonkOnHotTinRoof : 2 - Does not compile in Mono (doesn't work in Linux) ?

Do you have the errror you get? It used to compile a couple of versions ago. I'll get mono up to date one of my servers and figure out what I changed.

Quote from MonkOnHotTinRoof : 3 - Sometimes (will try to find out more) while running test, LFS completely freezes and I have to kill it from Task Manager.

LFS or the insim app? I've not seen this myself and have had apps running for over 24 hours.
-
(MonkOnHotTinRoof) DELETED by MonkOnHotTinRoof
#22 - sdether
Quote from MonkOnHotTinRoof :Here is my quick patch for code pages support. 1 new function (and one replaced) in byte2string class, and one-line changes in other 3 files dealing with conversion.

Mono compiler gives errors about interface not implemented in some classes. See attached file (open with Wordpad not notepad). I didn't try to resolve yet...

Thanks. I'll put the patches in for the next release. I'll also figure out why its not compiling under mono. It runs under mono, though. I took my compiled console test application moved it to my linux box and was able to connect back to LFS on my windows machine. While i'll get it working under mono (and provide a nant build file), it is possible to use the binaries that come with the release in the meantime.
#23 - wabz
Omg Plagiarism@!*&
Quote from MonkOnHotTinRoof :Here is my quick patch for code pages support. 1 new function (and one replaced) in byte2string class, and one-line changes in other 3 files dealing with conversion.
.

Parts of this patch look EXTREMELY similar to code given in getLFSString.txt in the BFS 0.6 thread over in unofficial addons. While it had no copyright/license attached, I think it's a bit rude to not give credit .

I left out ^G in there, which is Greek, which is missing from your patch too. You might want to add it.
#24 - MonkOnHotTinRoof
Quote from wabz :Parts of this patch look EXTREMELY similar to code given in getLFSString.txt in the BFS 0.6 thread over in unofficial addons. While it had no copyright/license attached, I think it's a bit rude to not give credit .

I left out ^G in there, which is Greek, which is missing from your patch too. You might want to add it.

OMG, mate, calm down. The only thing I looked for in your code was code page numbers (and comments near them ), because I didn't want to look for them in docs. Sure I was mislead for missing greek then...
sdether, can you add missing greek line (and add in beginning license a comment: This code includes 4 numbers and 5 comments copied from wabz's code ).
#25 - wabz
Heh, sorry if I came across too angry - I thought the "Omg Plagiarism@!*&" thread title should have been sufficient to show I wasn't that serious Just would've been nice I think, because it is so different (and so much less) to the code you gave in that thread.

No comments in sdether's code required....
1

InSim/OutSim/OutGauge lib in .NET
(34 posts, started )
FGED GREDG RDFGDR GSFDG