I assume the Model byte in IS_NPL going to take up one of the spares? If not, can we rev the InSim number? Just want to make sure that if packets are incompatible, we can adjust on the fly.
thanks
thanks
I haven't used the Relay before, but want to include it in the next version of LFSLib.NET. Is it currently up and running for patch X, using the old relay packets or should I be waiting for the relay to catch up to X?
thanks,
sdether
thanks,
sdether
One change I'm considering in 0.13b is creating sync and async models for InSim Requests. Especially since we now have requestId's to match up responses. Currently all methods that cause an event handler to fire as reponse follow the naming convention of Request<action>(). For each one of those, I'd add a method or property (if no arguments are required) that operates synchronously. For example:
I'd also add a timeout param to the config so you can prevent blocking your app in case of a communication snafu. Anyone else find this useful or is listening to events asynchronously better for the way you work as is?
// current, async way to get Camera Position
inSimHandler.LfsCameraPosition += new CameraPositionEventHandler(cpHandler);
inSimHandler.RequestCameraPosition();
// and then you get cpHandler() called with
// the results on a different thread than your request.
// proposed synchronous equivalent
CameraPosition pos = inSimHandler.CameraPosition;
I'd also add a timeout param to the config so you can prevent blocking your app in case of a communication snafu. Anyone else find this useful or is listening to events asynchronously better for the way you work as is?
I think I worked myself into a corner of over-complication and have withdrawn the request. But I just wanted to make sure I am reading this right. The ^L or ^8 before the TextStart are just resetting things, because anything after textstart can always be assumed to be default color and Latin-1 and if it's not the color and codepage wil be explicit after TextStart.
Ok, 0.12b is out. It's just 0.11b with patch X compatibility. Docs are not updated (switching to Sandcastle by 0.13b) and i haven't exhaustively tested it, but it at least should allow 0.11b people to get up and running against path X with only a few code changes.
More info is here and the zip is here.
Can't give a timeline for 0.13b, but i'm actively working on it and I have time set aside for it for the foreseeable future.
Wabz -
I tried your code and had some problems with some of characters working others not. I've settled on a lookup table from Unicode to codepage/bytevalue instead, which also has the benefit of being nice and fast.
As for the relay server, it's on my plate, but i'm also waiting to see if the protocol for its extra packets gets revved for the new patch X packet header.
More info is here and the zip is here.
Can't give a timeline for 0.13b, but i'm actively working on it and I have time set aside for it for the foreseeable future.
Wabz -
I tried your code and had some problems with some of characters working others not. I've settled on a lookup table from Unicode to codepage/bytevalue instead, which also has the benefit of being nice and fast.
As for the relay server, it's on my plate, but i'm also waiting to see if the protocol for its extra packets gets revved for the new patch X packet header.
never mind. been staring at MSO packets too long
Having spent most of the weekend trying to marshal Lfs encoding into Unicode and back, there are a couple of encoding related things I'd like to request:
1) As wabz mentioned, it would be nice if LFS could strip out extraneous encoding markers:
2) A couple of things about encoding that I noticed that could be classified either as bugs or as unexpected behavior. I hope the following makes sense. It's a bit hard to write off. It's basically stuff about extra control encodings, difference between color and no color and unobvious TextStart placement
In the following, I use | as a marker where TextStart is located, C0 means ISF_MSO_COLS is off and C1 means ISF_MSO_COLS is on
Mixed encoding username, latin-1 text
C0: ^JDsd^LÆther : ^L|d
C1: ^7^JD^1sd^L^7Æ^4ther ^7: ^8|d
What's weird?
- CO has an extraneous ^L before the message, C1 does not
- The text color in C1 or the ^L in C1 is before TextStart
Stripped out the high Latin-1 char from username
C0: ^JDsdether : ^L|d
C1: ^7^JD^1sd^7e^4ther ^7: ^8|d
What's weird?
- CO has an un-needed ^L before the message, C1 does not
- The text color in C1 and the ^L in C1 are before TextStart
Made Text Japanese
C0: ^JDsdether : ^L|^JD
C1: ^7^JD^1sd^7e^4ther ^7: ^8|^JD
What's weird?
- CO has an un-needed ^L before the message, then requires an immediate ^J
- C1 has an extraneous ^J
So these are the problems this causes me:
Having spent most of the weekend trying to marshal Lfs encoding into Unicode and back, there are a couple of encoding related things I'd like to request:
1) As wabz mentioned, it would be nice if LFS could strip out extraneous encoding markers:
2) A couple of things about encoding that I noticed that could be classified either as bugs or as unexpected behavior. I hope the following makes sense. It's a bit hard to write off. It's basically stuff about extra control encodings, difference between color and no color and unobvious TextStart placement
In the following, I use | as a marker where TextStart is located, C0 means ISF_MSO_COLS is off and C1 means ISF_MSO_COLS is on
Mixed encoding username, latin-1 text
C0: ^JDsd^LÆther : ^L|d
C1: ^7^JD^1sd^L^7Æ^4ther ^7: ^8|d
What's weird?
- CO has an extraneous ^L before the message, C1 does not
- The text color in C1 or the ^L in C1 is before TextStart
Stripped out the high Latin-1 char from username
C0: ^JDsdether : ^L|d
C1: ^7^JD^1sd^7e^4ther ^7: ^8|d
What's weird?
- CO has an un-needed ^L before the message, C1 does not
- The text color in C1 and the ^L in C1 are before TextStart
Made Text Japanese
C0: ^JDsdether : ^L|^JD
C1: ^7^JD^1sd^7e^4ther ^7: ^8|^JD
What's weird?
- CO has an un-needed ^L before the message, then requires an immediate ^J
- C1 has an extraneous ^J
So these are the problems this causes me:
- The extraneous or unneeded encoding markers hark back to wabz comment. I.e. once you convert it to Unicode, you can never get back the exact string
- Different strings between color and no color just compound the first
- And this one is the real issue for me and contradicts my complaints in about the first two in a way
I'd like to have all the necessary encoding explict in the Text section. I.e. currently, in order to expose playername and Text, I can split the byte array on TextStart. But if I then decode the byteArray of just the text, I've lost the context of encoding (and color) that was set up by parsing the player. But if I decode first and then split, TextStart is no longer accurate, since the encoding markers have been stripped. So this means, I can't use a generic decoder function, but have to decode and split in a state machine specific to MSO that can keep track of the current encoding and color state and put them into the respective playername and text strings. I would really prefer not to do that.
- Prefix text with both the appropriate color and encoding sequence and have TextStart point at the first control sequence
- Other than the above case, strip any extra encoding markers (this is internally consistent, since the only time 1-to-1 conversion is really important is for echoing a message exactly.. the player prefix isn't likely to be echo'ed
Last edited by sdether, .
Reason : revoking request
When you say it doesn't support loopback on windows, do you mean just 127.0.0.1? If not, have you tried connecting to LFS via the public IP of your machine (if your on a LAN likely something like 192.168.0.x)
So this is taking longer than I thought. For ease of future support, I ripped out my internal packet representation and replaced with with data structures that mimic the Insim header file as much as possible. So the guts were entirely replaced. At this point I have the entire protocol implemented, but not exposed. I plan to release a stop-gap version by Monday that at least provides what was previously possible with relatively minor code changes for people using the lib (some packets changed beyond the ability to maintain the API).
Then I'll implement all the new features and TCP mode and release the full version.
The one thing that I'd been punting on for a long time and still don't like the solution to is I18N text. My internal string representation is unicode, so I can easily parse mutli-encodings coming from LFS. But I haven't found a way to take unicode and determine what codepage to use on a per character basis so i can construct a proper LFS string. Even once i figure that out, I plan to leave it as a config option whether to do any encoding processing or not and maybe even add the ability to input/output encoding via the html entity encoding model.
Then I'll implement all the new features and TCP mode and release the full version.
The one thing that I'd been punting on for a long time and still don't like the solution to is I18N text. My internal string representation is unicode, so I can easily parse mutli-encodings coming from LFS. But I haven't found a way to take unicode and determine what codepage to use on a per character basis so i can construct a proper LFS string. Even once i figure that out, I plan to leave it as a config option whether to do any encoding processing or not and maybe even add the ability to input/output encoding via the html entity encoding model.
You should still be fine. Your callback receives an array of bytes or you passed one in and it tells you how many bytes it actually filled up. Either way you now have some bytes to consume. You start walking through the array identifying packets and digesting them. Finally you will either be at the end of the set of bytes or you will reach the end before you got the bytes specified by the Size of the packet. If that happens, you just copy that partial packet into another array and wait for another callback. Then before processing the new bytes, you prepend the new bytes (or in C, create a new array that fits both old ones and copy both into the new one) and process as normal.
The one packet per receive is the one think I like about UDP. The worst thing about TCP receive is that not only can you get more than one packet, you may also get partial packets and you so kind of have to keep a queue of received bytes around. Not sure if that's a scenario that's likely with InSim TCP, because the way each packet is sized they are unlikely to be split up into multiple tcp packets. I just had to deal with that a bunch on larger object serialization that didn't necessarily worry about 4-byte multiples.
That said, I'm still likely to use TCP for all my InSim uses, if for no other reason than the multiple connections. Previously I wrote a single InSim daemon that then used .NET remoting to let my various progs talk over that one connection and that was a pain to debug.
That said, I'm still likely to use TCP for all my InSim uses, if for no other reason than the multiple connections. Previously I wrote a single InSim daemon that then used .NET remoting to let my various progs talk over that one connection and that was a pain to debug.
RaceLaps question
Ok, rather then setting up a race with over a hundred laps, I figured I'd just ask here real quick.
I am assuming that the RaceLaps (rl) data type is only used in IS_STA & IS_RST since those are actually a byte. The other places where laps are reported, NodeLap, CompCar adn IS_LAP are stored in a word and in the case of IS_LAP there is even total time, so I figure those must be actual lap counts. Is that correct or does anything resembling a lap use the rl data type?
thanks
I am assuming that the RaceLaps (rl) data type is only used in IS_STA & IS_RST since those are actually a byte. The other places where laps are reported, NodeLap, CompCar adn IS_LAP are stored in a word and in the case of IS_LAP there is even total time, so I figure those must be actual lap counts. Is that correct or does anything resembling a lap use the rl data type?
thanks
Last edited by sdether, .
Reason : forgot about IS_STA
It's open source, so you can fork it and do whatever you want with it, but it's not a community project. The copyright still lies with my company and has to for separate non-gpl licensing, which is also, unfortunately, why I can't accept patches unless the copyright is assigned to me.
It won't compile for .NETCF in its present form. There are a couple of things it does that .NETFC doesn't support. I have a branch on my local machine that compiles on runs the basic tests on my phone, so it is possible. (not over activesync.. no UDP support on activesync)
LFSLib.NET update in the works
I've been getting a number of emails and private messages about this, so I figure I should post here.
I know the lib is a couple of revs behind the InSim protocol and I do intend to catch it up to the current state. I don't have a timeline as rl issues have kept me from even trying out the latest patches of LFS. I hope to get some cycles from my other tasks this week to at least determine the scope of the changes I need to undertake and will update this thread once i have more information.
I know the lib is a couple of revs behind the InSim protocol and I do intend to catch it up to the current state. I don't have a timeline as rl issues have kept me from even trying out the latest patches of LFS. I hope to get some cycles from my other tasks this week to at least determine the scope of the changes I need to undertake and will update this thread once i have more information.
Very cool proof of concept. While I don't have a need for it myself, prefering to stay in compiled land as much as possible, the possibilities of this are fantastic and could open all sorts of new Insim based mods to different set of users.
PSP would be the nicest display. But as has been pointed out, it's a pain to program. Now Windows Mobile is dead easy, imho. I got an OutGauge app running on my HTC Apache over office wifi as a proof of concept and that worked well. There are other WM5.0 devices that aren't phones with larger displays that should work well. Of course this option is rather expensive if all you need to do is display some stuff. But if you need to do computation as well, it's cheaper and cleaner than dedicating a PC to it.
Ok, I don't to VB.NET, so this is going to be in C#, but it should at least be close enough to get you going.
There are two ways to use OutGauge, by itself or via InSim.
To use it by itself, you need to configure it in the cfg file, such as:
And then the setup code in C# would be
If you are getting OutGauge via InSim, start lfs with /insim=30000 and the consuming code in C# would be
How you just need to create the event handler that receives the OutGauge events, which is the same in both scenarios:
Hope that helps,
sdether
There are two ways to use OutGauge, by itself or via InSim.
To use it by itself, you need to configure it in the cfg file, such as:
OutGauge Mode 2
OutGauge Delay 100
OutGauge IP 127.0.0.1
OutGauge Port 30001
OutGauge ID 0
And then the setup code in C# would be
OutGaugeHandler handler = new OutGaugeHandler(30001);
handler.Updated += new OutGaugeHandler.GaugeEvent(outGauge_Updated);
Console.WriteLine("created handler");
while (true)
{
//clearly you'll want to handle this loop some other way,
//or in the case of Windows.Forms, don't even need to
//worry about a loop like this.
//The point is, after you start the handler, your OutGauge events
//are received by another thread, so do whatever you need with
//thread that started the handler
}
If you are getting OutGauge via InSim, start lfs with /insim=30000 and the consuming code in C# would be
handler = new InSimHandler(false, false);
Configuration config = handler.Configuration;
config.LFSHost = "127.0.0.1";
config.LFSHostPort = 30000;
config.ReplyPort = 30001;
config.UseKeepAlives = true;
config.UseSplitMessages = true;
config.GuaranteedDelivery = true;
handler.Initialize();
Console.WriteLine("LFS info:");
Console.WriteLine(" Product: {0}", handler.Version.Product);
Console.WriteLine(" Version: {0}", handler.Version.Version);
Console.WriteLine(" Serial: {0}", handler.Version.Serial);
handler.GaugeUpdated += new OutGaugeHandler.GaugeEvent(outGauge_Updated);
handler.StartOutGauge(100);
while (true)
{
// same story with this loop as in the above case
}
How you just need to create the event handler that receives the OutGauge events, which is the same in both scenarios:
void outGauge_Updated(object sender,
FullMotion.LiveForSpeed.OutGauge.Events.Gauge gauge)
{
Console.WriteLine("OutGauge -----------------------");
Console.WriteLine("Time: {0}", gauge.Time);
Console.WriteLine("ID: {0}", gauge.Id);
Console.WriteLine("Car: {0}", gauge.Car);
Console.WriteLine("RPM: {0}", gauge.RPM);
Console.WriteLine("Speed: {0}", gauge.Speed);
Console.WriteLine("Message1: {0}", gauge.DisplayMessage1);
Console.WriteLine("Message2: {0}", gauge.DisplayMessage2);
}
Hope that helps,
sdether
MaximUK:
A couple of things.
1. You do have LFS starting with \insim=29999 ?
2. you never set .ReplyPort, which just happens to default to 29999. Now, it should be possible to listen and send on the same port (never tested it myself), but not if who you are communicating with is on the same machine. I.e. LFS binds to port 29999 so when you try to bind the replyPort to 29999, you'll just block. Try setting .ReplyPort = 30000 . I assume this blocking prevents the exception to be thrown and that's why you are hanging.
3. If you really just want outsim, use OutSimHandler instead and make sure that outsim is properly configured in LFS's cfg.txt
Hope that helps
A couple of things.
1. You do have LFS starting with \insim=29999 ?
2. you never set .ReplyPort, which just happens to default to 29999. Now, it should be possible to listen and send on the same port (never tested it myself), but not if who you are communicating with is on the same machine. I.e. LFS binds to port 29999 so when you try to bind the replyPort to 29999, you'll just block. Try setting .ReplyPort = 30000 . I assume this blocking prevents the exception to be thrown and that's why you are hanging.
3. If you really just want outsim, use OutSimHandler instead and make sure that outsim is properly configured in LFS's cfg.txt
Hope that helps
Wow.. The entire video card industry can't come up with a decent triple screen solution and you just hack up some DLLs? Seriously, you need to get with Nvidia and have them create this as an official solution. I got a th2g for some testing and while it's works great for games, it's still pretty hacky of a solution and doesn't even do DVI.
I'm sorry it's taking so long, but the last two months have not given me any time to finish up the bug fixes and code page additions i've been working on. I don't have a date right now, except that it is on my list of things to do.
I have not looked at what is required to change transparent support for the relay server, but it's on the list after above changes go out.
I have not looked at what is required to change transparent support for the relay server, but it's on the list after above changes go out.
Full Motion Racing on Local TV
http://digg.com/motorsport/vMi ... atured_on_Fox_6_San_Diego
The local fox affiliate paid us a visit to talk about the business we're building using LFS and the Force Dynamcs 301. Now I know that whenever you see a story on the news, you're getting a lot of quotes out of the overall context. The way it was cut I feel it does make us sound like idiots in places to anyone who is into racing. Ho hum.
Don't get me wrong though, I think the piece was really well done and they did use a part of me talking about Live For Speed.
The local fox affiliate paid us a visit to talk about the business we're building using LFS and the Force Dynamcs 301. Now I know that whenever you see a story on the news, you're getting a lot of quotes out of the overall context. The way it was cut I feel it does make us sound like idiots in places to anyone who is into racing. Ho hum.
Don't get me wrong though, I think the piece was really well done and they did use a part of me talking about Live For Speed.
This kind of thing is why I never patch my code directly with provided source, but use that source to understand the solution and roll my own. I'll gladly give credit to all sources that helped me, but I don't want to have my codebase infringe on anyone else's copyright, whether permission is granted or not.
Anyway, i'm playing with the codepage stuff now, but I have a ton of things on my plate, so it may still be another week until I release a new version of LFSLib.
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.
Those are definitely all oversights and things I need to fix.
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
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.
LFS or the insim app? I've not seen this myself and have had apps running for over 24 hours.
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
FGED GREDG RDFGDR GSFDG