Quote from Scawen :

Two more OT pics for you. Slow progress trying to be able to switch off mains water supply.

One, this pavement tap won't turn, even with these two spanners on my socket set extension... if i turn any harder i think the pipe will break! :mad:

Had the same problem when i tried to shut the water to my house off, shortly after we moved in. Completely rusted in place. Tried Liquid Wrench, everything. Finally I noticed that the previous owner added another tap to the main pipe by the house. It shuts the water off real easy. I guess it was rusted shut even when he lived there.

Act Labs Force RS wheel & pedals, although i've been curious about the DFP and it's 900 degrees.

Just a question on how you set up the camera. When i tried this a while back, the camera wouldn't set up vertically, but always with just a nudge of an angle and large FOV gave way too much distortion.

If i could get around that, i think i can automate the capturing using InSim and some win32 programming. basically programatically move the shift-U camera along the drive line and snap pics, so it would become a lot easier to do.

Of course getting a non-perspective view camera would be nice. It's easy enough in D3D, but has to be done by the devs (i think).

Quote from (SaM) :

BTW, anyone got the vector expansion? Doesnt work with LFS right? only with some flightsims.. or are there any racesims that are compatible with the vector expansion?

I bought the vector expansion, because I'd been told that it improves head tracking a lot, providing smoother movement even if you don't get 6DOF in a game.

I do like the extra axis in GTR and GT Legends. It's not that you really see all that more, but it feels less constrained and you're less likely to try to hold you neck stiffly as you do when you only have 2DOF.

1969 911E w/ 86 3.2 Carrera engine on the slow and painful road to become a RS replica.

First pic is the car as i got it, second is with the new engine in, last is me trying to keep up with the competition coming back from Laguna Seca

Quote from rwkeating :

sdether, I'd experiment by putting other things over the window to see if you can get around that limitation. Try a large black plastic bag. Cut it so you get on big sheet and toss that over the window and see if it helps.

Heh.. It's the picture window in our living room. Attempts to cover it with black plastic bags could seriously cut into the marital bliss

It's fine, anyhow. There aren't a lot of daytime hours I have available for racing anyhow.

Quote from rwkeating :

As far as acting up, I found it is sensitive to other light sources. Mine was messing up every once in a while. I found it was from a bit of sunlight coming through a window and was based on the time of day (the angle of the sun.) I made sure the curtain was well closed and now the only time I need to reset it is if my hat (with the reflectors) moves (or if I move it).

I got that problem. And since it's IR, it's not just light. I got a window behind me that has curtains but during the day even the curtains heat up enough for the trackIR to register them. Means, i can't race during daylight hours.

Quote from bobvanvliet :

I was looking at the TrackIR a while ago, but it seems a bit unnatural to me. You move your and and the picture on the screen follows, but you gotta keep your eyes on the screen... Isn't that annoying? Or does that just take getting used to?

It becomes surprisingly intuitive quickly. I don't even think about using it. I just "look around" as if it was the natural thing to do now, not thinking about the mechanics anymore.

I've got my trackIR with Vector Expansion and love it. I don't necessarily think that it makes you a better driver, but like switching from a regular wheel to a forcefeedback wheel, it increases the level of immersion. This, IMHO, is always a good thing.

It does seem to act up from time to time. Always have the reset key handy, so you can recalibrate it. I was doing some racing the other night, first in a UF1000 where it worked perfectly. Later that night I swiched to my usual FZR racing and suddenly the response was real sluggish. I had to move my head more than usual and the lag between me moving my head and the screen moving made it more distracting than useful. Maybe it was a fluke, maybe it was related to switching cars without restarting LFS. Dunno.

But on the whole, it's an awesome product.

Quote from GhostVE :

Maybe I did not express my question well (english is not my native language).
What I am asking is whether there is some other structure where you can pull out from OutSim information about engine RPM, currect gear, how much fuel left and so on... What I want to do is hook up a few gauges with servo motors and have my program read these values from LFS in order to drive the gauges....

You are quite correct. A lot of telemetry information is not currently available. Outsim is primarily for physics data, supporting motion simulators and the like.

What is missing (and plans are unknown) is technical data about the car's state such as current gear, rpm, tire condition, brake condition, pedal positions, steering wheel position, fuel level, etc. All data that's available to the driver, but not in a data format outside the game.

[offtopic]
I can think of two reasons why this information doesn't yet exist:

1) It would open up all sorts of new aids that could be programmed and might be considered undesirable. I doubt this is the reasons, since the existing data already opens up a lot of possibilities

2) Of all the data in LFS, this is the most volative, just looking at what all
has changed since S1 alone. I can see not wanting to define packets for this information until car features are more locked down.

I would love that data however. One application that I would try to undertake if I could access it is either create an interface to feed the data into a real Motec HUD to be used on the steering wheel for the FOX and FO8, or build a Motec replica that does the same thing.

While I'm babbling about this, I would like to see this data as a subscription based set of packets, so you could tell InSim which set of data you want to listen to (all data could be a lot of data) and what player you want to listen for. Since a large number of applications for telemetry would be client side, it would be nice to be able to just get info on the active car.
[/offtopic]

I've got the "not recommended" option of saving all replays turned on. If i spend an hour or two on servers it usually racks up about 10-20MB of replay files. I go in once a week to clean up the replays i don't want to keep, but considering the size of disks, i think always saving replays isn't that horrible an overhead.

Quote from mrjo :

well. I think there is so much diference to have a full sens of virtual freedom when you want to look to any point or when you want or rotate you head or body position [...]

I completely agree. 6DOF support would be wonderful. I downloaded the GT Legends demo last night and the 6DOF felt completely natural. With 2DOF the trackIR feels like an artificial aid, while in GT Legends, i just looked around as if i was in the car.

However, I didn't enjoy the driving so much, so i switched back to LFS. And spent an hour or so on a UF1 only server. Now that rocked.

You will be sorely missed, especially in the Programmer's forum. Good luck with your chosen course of action.

Quote from Bruce314 :

Can someone tell me where I could find the protocol specification? As Linux user, a .net library doesn't please me too much, I was thinking of java or perl but I'd like to have a look to the protocol before speaking of my ideas ;-)

As has been pointed out the full docs are in the zip file for LFS. However, may I suggest taking a look at Mono (www.mono-project.com). You may not be able to use the tester application (yet), since Windows.Forms isn't complete yet, but the rest is fine under linux.

I was a perl programmer on linux for about 8 years before I started with C#, so i wanted to make sure that I didn't tie my future career to MS with accepting a .NET position. My experience with Mono makes me believe that it's a very viable platform on unix. Novell's been doing an excellent job supporting it and a lot of smart people from various Open Source projects are working on it.

Of course, having said this, someone building a good Perl library for InSim would be quite nice as well, and a worthy addition to CPAN.

Edit: Or you could take my lib to Java (it's GPL after all). There's some esoteric stuff in there, mostly all the Sequential layout structs for loading the data, but it may be easier to take the C# and translate it to java than starting from scratch.

Last edited by sdether, Wed 17 Aug 2005, 13:59.

Quote from Messiah :

As far as I know, yes. VB's "Type" is similar to a struct, and like C, no forward references. The only datatype missing, afaik, is the signed byte that may be put into a signed 2-byte integer datatype.

.NET can also manage the precise order of structs. I personally barely use structs and prefer classes. There's a major difference between structs in C and C#. For example, they can yield performance gain if the data chunk is <= 16 bytes in size (by Microsoft).

What DLL are you trying to import. I know that dealing with DLLs in C# is a pain and it sure doesn't give you a clue as to why it's not working when it doesn't, but i've had pretty decent luck with using a variety of user32.dll functions, including ones that pass structs in and out. Of course this was after lots of trials and cursing. Maybe something i learned along the way can be of assistance.

Quote from Messiah :

I can either provide your with support and contribute to a .NET assembly if you're going to create one or a descent article about what someone should know when moving from a C major to a C sharp ^_^ (musician joke :P). And I bet sdether would contribute as well if he got the time to do so

Otherwise I'd wrap the DLL into a C# class rather than using the DLL directly with all programs. Because you'd still need to convert the returned data into proper C# datatypes. It's less work than porting the whole functions but I guess it needs maintenance as well if the DLL changes. <insert :scratch: here>

I'm definitely in favor of wrapping whatever DLL is used in a C# class. Even when I use an outside DLL, i always write a wrapper to it. But i'm also a devout OO weenie.

I know cross-language tools can save people some work, but when you're interfacing with someone else's system, like LFSW, I find it better to have each language write the interface in a way that feels native to the language. IMHO, if I were to interface with LFSW (not on my schedule yet), I'd write it natively in C# because I'd rather have it fit directly into an object model, rather than wrap a procedural model to a third party system.

Not trying to discourage the_angry_angel's work here, I just don't think you should alter your design because of the potential use by another language. Design it the way that best fits the language of choice and anyone who wants to use it can write an adapter around it, or roll their own.

Last edited by sdether, Tue 16 Aug 2005, 16:28.

Quote from DodgeRacer :

actually...no, the 350z is emulating the heritige of the z with the basic shape of the 240Z...not "copying" the 911 , they both just so happen to have a sloped back

I'm fully aware of the z heritage, and my comment was mostly in jest. I'm sure that Nissan said to themselves, "take the 240 and adopt the aerodynamics to be better at high speeds and more modern lines." and voila 350z.

However, from my observation, if you superimpose silhouettes, the new z has a more 911 slope than a 240z. But I'm a P-car weenie, so my eyes are predisposed to that.

LFS Content: When i see the FZ250, i see 911 lines and engine with Ferrari tail lights and 350z snout. All in all a very respectable shape without being too derivative of any existing car.

Quote from BlueShaun :

Seems more like a 350z with a better looking body to me.

The better looking body that the 350z was copied from was the 911

Those coming over from the RSC programmers forum are likely already aware of this, but since this is a nice clean new board, i figured I'd just point out that there is a .NET wrapper around InSim, for those working in .NET and not wanting to have to figure out the InSim protocol.

Current version is 0.06b

Current NDoc

Release Notes

Source Release

Binary Release w/ Sample