Fixed OutSim and OutGauge bugs and added and OutSim form to the Tester app. Tested both as standalone and via InSim.

http://www.claassen.net/geek/lfs

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?

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

Last edited by sdether, Fri 19 May 2006, 15:38.

These three form a vector pointing in the direction that the node is "facing", i.e. that vector would point towards the next node


all these values are points on a line drawn through the the node perpendicular to the direction vector above.

Basically you need to do is use some trig to draw determine the vector, its perpendicular vector and then you can find the absolute coordinates of the limit and drive lines.

HTH,
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.

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

Ok.. Finally the pics i promised (looks like i can't embed the images in the post):

The Intel Ad
Small version
Large version

The VRX chair used in the Intel booth w/ rFactor F1
Small version
Large version

The Logitech triplehead2go setup
small version
Large version

CrazyICE,

I'm trying, i'm trying Seriously, I hope to have the new version with single lib InSim, OutSim and OutGauge finished in a matter of days. It's just other tasks keep intruding.

Quote from Hollywood :

Yeah... lots of little tricks to log4net. Do like it though, sure better than the Microsoft "logging". :/

Sweet Jesus.. i know, i shouldn't keep this back and forth going--sounds like it could go on for a while--but, at my other gig, we initially tried the Logging Application Block from MS. Hey, the system we were building was supposed to be a proper MS enterprise application and all. I finally just pulled rank, instituted log4net and, really, everybody's been a lot happier and productive.

Quote from Hollywood :

Took a look at the .NET library, looks really good and quite solid although I haven't done an in-depth look at it; but glad I checked here first before I started to bring my old InSim.NET up to .NET 2.0.

I actually have my stuff in 2.0 and have been backporting it to 1.1 for release, since i didn't want to force people to go 2.0 quite yet.

Quote from Hollywood :

Just from a quick-hit standpoint, I'd be a bit concerned about the foreaching through the InvocationList and calling BeginInvoke on it. Otherwise at least quick glancing most of my objections are cosmetic (i.e. the #s in the regions are a bit much, and I always use the underscore prefix to differeniate member variables from local variables, etc.)

The reason i use the InvocationList and BeginInvoke is to allow asyncronous event handling. I think i set it up so you can choose via config whether you want that behavior, but basically i didn't want some process receiving events to be able to block the reader thread from receiving more data. And i don't want event handler exceptions to kill the event sending.

Quote from Hollywood :

Oh, a trick with Log4Net is do the following:

private static readonly ILog log = LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

That way you can just macro the line and plop it at the top of any of your classes easily.

yeah, found that trick a couple of months after i started the insim project and never went back to clean it up

Quote from Hollywood :

Have you run it through fxCop yet? If not, I highly recommend it.

Honestly, I've been afraid of what it would bitch at me about

Quote from Hollywood :

Gah, you would use the viral GPL license. Its probably fine for a project such as this where there are is absolutely no real excuse for not sharing the source of applications that make use of the framework. However, there *are* far better open source licenses out there.

Basically, i use the GPL to put things out there. Doesn't mean I am not open to other licenses if someone wanted one. It's just if someone wants to use it and not deal with me, then they get the GPL.

Quote from Hollywood :

As far as Managed DirectX, no one should be fooled into thinking that it is anything more than a managed wrapper to the DirectX COM objects since its not (quite check using Reflector shows this to be the case). This *may* change to some degree with DirectX10 (interesting to note that WPF will wrap some DirectX10 functionality, and actually does wrap some DirectX9 functionality in the beta in a more 'managed' fashion, but also limits your ability to use all of the DirectX functionality).

Yeah, i was switching things over to MDX 2.0 to get all the lovely generic stuff, and then they did the XNA announcement and pulled the rug from underneath me. So until the plans for XNA firm up i'm stuck with the slower MDX 1.0 stuff which has some issues under .NET 2.0, but for my uses, it's plenty fast.

Quote from Hollywood :

Yes, actually architecting and developing large n-tier systems is a time consuming process no matter what technology you use but performance on the other hand is very good if the hardware has been spec'd out correctly based on predicted loads, etc. But all sorta off topic.

I agree.. It's just 99% of the "enterprise" systems I've dealt with were built as a magic bullet to let developers write EJBs without knowing anything about the system and without enforcing proper architecture on the whole system, which ended up with amazing resource hogs that were never planned for and sysadmins constantly having to reboot the jvm because it wasn't tuned right for the new component that was just deployed.

What the heck.. I wasn't going to jump into the language arguments, but they are so much fun What follows is off topic and just my reasoning for using the languages I like to use.

I like C# and java, but both as languages, not as religions. Coming from LISP, C++ always gave me headaches with its syntax. If i have to do my own memory management in an OO language, I try to use Objective C instead, however fringe it is now. That said, writing code in a modern framework without a GUI with an object browser would drive me back to C any day, rolling my own terse code. Verbosity in frameworks is only good if the computer takes over the book keeping of what exists and how to call it.

I haven't had a need for the speed of C or C++ in ages. If perl and php are fast enough for webapps, then the java's speed is not an issue. Java isn't slow. Building giant black-box EJB, n-tier systems is slow and would be in any language.

C# is nice and fast (comparatively) and with managed DirectX, i can do full 3D programming without having to switch to a lower level. I'm not saying LFS could be done as efficiently in Managed DirectX.. maybe it could, probably it can't... But so far I've not had the need for that kind of performance in any of my jobs or hobbies.

AdamW: Ah, never played much GT4, since i don't have a PS2. I guess all i can say is that this one looked like a movie of a car racing on the ring. It was impressive looking.

Just got back from E3. If LFS was used anywhere on the floor, I couldn't find it. It was a very sparse event for racing, overall.

There was a giant poster from Intel with the BMW Sauber F1 car in one of the halls advertising racing simulations in their booth. That poster had the rFactor logo on it. I checked out the booth and they were running the rFactor F1 mod on VRX racing chairs with the DFP. Don't know if the wheel wasn't working right, but it felt sloppy.

Logitech had two openwheel racers outfitted with the new Logitech G25 wheel and shifter and running triple LCDs using the Matrox triplehead2go. That display system was beautiful. I stood in line for the racing and it was ok. Also running rFactor, but just stock using cars with logitech skins.

GTR was not on the main floor. There was a big screen running a video for Xbox 360 GTR in the THQ booth, but no presence. Simbin was doing closed door demos of GTR2 in the 10tacle booth downstairs in Kentia. I had the opportunity to attend one of the demos and it looked good. No idea how it feels, but they did say that they received a lot of feedback that GT Legends was too arcady, so GTR2 supposedly has a strong sim focus again, but offeres racing school to make it accessible for non-racers.

Also in Kentia, VRX had another one of their chairs running GTR.

GT5 was shown at the Sony booth in 1080p (not 1080i, but p!). It was basically photo realistic. Gorgeous.. Nordschleife even had all the grafitti on the road that you see in videos. But without a wheel, i can't pass judgement on it. It was also marked as 20% into development.

Finally, MS announced Forza 2, but if they had anything at all, it was behind closed doors and I was unable to get at it.

I'll have a couple of pics later on, once i get settled back into things.

The rest were arcade things like Test Drive Unlimited (which was fun, but not a sim in any respect), Flat out 2 and some others.

Quote from Tanuva :

eehm... if possible, how do I get this code loaded correctly in VC++ ExpressEdition? I always get an empty solution... Or can I get it somehow loaded into Dev-C++?

Or doesn't it work in C++ at all and I have to learn C#?

It's C#, so it probably won't load up in the C++ Express edition. The DLLs should be usable from C++ though.

Quote from inCogNito :

maybe this could be added to outgauge as well.
some cars have warning lights for flags in RL (at least they have in GTR, and the cockpits are quite realistic)

That is a good question. Do race status messages like that belong in OutGauge or InSim, since insim does race tracking already. I see it fitting both in a way.

Doh! I just looked at the changes for the existing packets. I didn't even see the SSG InSimPack. I guess 0.10b is just around the corner.

Just realized something else reading the docs. When you init OutSim and OutGauge from InSim, the packets come to the same port, right? So my InSim reader needs to be able to recognize and handle those packets. Right now i keep InSim and OutGauge completely separate.

Just released the latest version of my insim .NET library to match the changes in 0.5S and above.

I also added a new lib for handling OutGauge data.

The tester has a small window forms example of how OutGauge works.

Main info: http://www.claassen.net/geek/lfs
InSim Lib: http://www.claassen.net/geek/lfs/InSim-0.9b.zip
OutGauge Lib: http://www.claassen.net/geek/lfs/OutGauge-0.9b.zip
Tester: http://www.claassen.net/geek/lfs/Tester-0.9b.zip

Quote from CrazyICE :

nice...
i'm currently starting with c#!
i use delphi 7 atm...
so, i'm not used to c#!

thx!

Hope you'll enjoy it. I started using it a couple of years ago and being and OO bigot, have found it to be very enjoyable. My mainstay for the 5 or so years before that was perl and with the odd java in there as well. Before that was C/C++ and before that was LISP. Started in Turbo Pascal about 20 years ago, which i guess is an ancestor of Delphi.

I created a separate DLL for OutGauge. Figured there was no reason to force dependence on the InSim DLL. Ihave not done one for OutSim. But really creating OutSim should be trivial based on OutGauge.. Basically just a matter of swapping out the data structures and accessors. I will package it up and post it tonight, dll, source and test app.

Quote from Tweaker :

All I can remember is that he was in need of something that can take UDP packets and connect with some other form to connect properly with his LCD. I could ask him. I told him to post here in this thread, but he figured he would wait for someone to make some program or something to make it less of a pain for people trying to figure this all out.

I got my OutGauge object working yesterday, but i still need to do some clean-up before I'll release the next rev of my lib. With it, all you have to do is create an instance with the port to listen on and subscribe to the Gauge event. Every time LFS sends a new packet, a Gauge object with all the data exposed as named members (like obj.Speed, etc.) is provided to your event handler. That code in turn could write out selected pieces of that information to a serial port in whatever format your friend needs.

I'm at exactly the opposite end of the problem. I can talk to Serial, USB, Parallel and I can do whatever munging of the data I receive, but building the circuit board that interfaces one of those lovely cheap LCDs to serial/usb/parallel, is beyond me. Have your friend contact me, maybe we can completement each other's skills.

Last edited by sdether, Mon 1 May 2006, 20:10.

Yeah, saw the spec for OutGauge. Awesome. I hope to have a new version of the my lib out in the next week that has the packet changes for S/T/U in insim and adds OutGauge support

Been looking for good sources for LCD that could then be mounted in the steering wheel motec style. The one i got from crystalfontz is the ideal form factor, but not being much of a hardware guy, figuring out how to hook it up has been a bit of a challenge.

Found a place that has USB/Serial graphic LCDs, so I might give these a try:

http://www.matrixorbital.com/p ... mp;cName=lcd-graphic-lcds

Anyone know any other sources for graphic LCDs that come with a serial, parallel or USB interface?

cheers,
sdether

I've looked the spec over a couple of times and the only thing that's not in there (and strictly speaking not Guage info anyway) would be the info from F9-F12 with emphasis on F9 and F10. Adding that would be icing on the cake. Either way, that information is going to fantastic. I've got a serial LCD that I've been toying with and I'm also looking into using a WinCE device (way overkill, but it opens up so much). I think outGauge will spawn a lot set of new unofficial add-ons.

Thanks Scawen!

So, is this state of the car thing true for mpr's as well? After all in mpr's you get a lot of network drop and cars jumping around. So is that positional data then, or just a lossy form of car state?

I know it would be weird if spr and mpr would have different replay behavior, but if mpr's would be easier to convert to rewindable, i think people would be quite willing to accept that. I know most of the replays i watch are ones where i want to see what other people were doing when i was doing X.

Also, is it just my hardware or does everyones machine drop back to 1x after a couple of seconds of trying to run at 4x or higher?