Hi,

I am currently looking for a suitable racing simulator for a master thesis work. LFS seem to fit my needs very well, but there are some additional details i would like to here your thoughts about.

DESCRIPTION: The project is simply put based on a simulator, steering-wheel and some additional hardware. What we do is that: first the steering wheel (G25) is moved and sends it's new steering data to the additional hardware where the steering wheel data (steering angle) is manipulated. This manipulated data is later sent back to our computer running a simulator (Like LFS) that receives the new steering data. We then take the steering data from the simulator and transmit it to a hardware gauge interface.

QUESTION: Hope i haven't bored you yet, because here comes what i would like to discuss. Is there any possibility to send data from say, an user created application, that LFS then receive steering data from and use in-game, like a "setter"? This is the preferred case cause it would make our life easier. If this is not possible we have an idea of creating a virtual steering wheel in Windows that receives the new manipulated data which the simulator then listens to just as if it was and ordinary steering wheel. But that option is way more time consuming than being able to set the data right away.

The functionality of "getting" data from LFS and transmitting it to the gauge-hardware should be easy with all additional applications created for this, like OutGauge etc.?

I would be very thankful for any thought and recommendation about this subject!

Regards,

I think you need to be a bit more precise with what data you actually need to read and "set." OutGauge is really only useful for getting the gauge (rpm, speed, pedal state) data, but not the steer amount.

Reading the G25 axes itself is not really a problem and can be easily achieved with DirectInput. As for overriding the steering input, you'll have to use a virtual HID (as I guess mouse steer or keyboard steer is not an acceptable alternative). However you don't really have to write that yourself, as there's already PPJoy that creates virtual joystick devices. These devices are usually meant as controller adapters (so that you can for example connect console controllers to your COM port and use them or similar), but there's also an IOCTL controlled virtual device that you can simply access programmatically.

Quote from AndroidXP :

I think you need to be a bit more precise with what data you actually need to read and "set." OutGauge is really only useful for getting the gauge (rpm, speed, pedal state) data, but not the steer amount.

Reading the G25 axes itself is not really a problem and can be easily achieved with DirectInput. As for overriding the steering input, you'll have to use a virtual HID (as I guess mouse steer or keyboard steer is not an acceptable alternative). However you don't really have to write that yourself, as there's already PPJoy that creates virtual joystick devices. These devices are usually meant as controller adapters (so that you can for example connect console controllers to your COM port and use them or similar), but there's also an IOCTL controlled virtual device that you can simply access programmatically.

Thank you for the answer,

You seem to have understood my question correctly.

The "setter" idea is all about setting the data input to the simulator like with PPJoy but without the virtual joystick in the middle (i.e. without the HID interface in between). Data we want to set is steering-angle, speed and buttons pressed. The thing is we are not really sure if PPJoy can be used (license) in our context but maybe there are more alternatives we haven't seen and we are trying to mail the creator of PPJoy. We are receiving the data from G25 through direct input already so that works great.

The easiest way for our system to work is to be able to "set" data directly to the simulator, but i guess this isn't possible and was mostly a long shoot hoping for the best .

The getter data needs to be the speed in LFS and the gauge values. Speed is the most important part because we need this sent to the additional hardware. But i think i saw someone getting speed data etc. from LFS in their InSim (or was it OutSim) application.

Regards,

Quote from Pettor :

The easiest way for our system to work is to be able to "set" data directly to the simulator, but i guess this isn't possible and was mostly a long shoot hoping for the best .

Indeed, it is unfortunately not possible to directly send steering/pedal input to LFS without a virtual HID in between.

Quote :

The getter data needs to be the speed in LFS and the gauge values. Speed is the most important part because we need this sent to the additional hardware. But i think i saw someone getting speed data etc. from LFS in their InSim (or was it OutSim) application.

Depends, if you need the actual speed, you can get it with OutSim and use the "Vel" vector's length as speed in m/s. Or align it with the car's heading/pitch/roll and use the Y axis if you strictly need the forward speed only.

If an inaccurate speed reading is enough, then you can get this information with OutGauge. Keep in mind that this will really give you the value of the speedo, not the actual car speed. The gauge value is inaccurate due to the needle lag, tyre diameter differences (due to wear and/or tyre pressure) and wheelspin.

I don't know what data you actually need to get, but as AndroidXP pointed out PPJoy works for inputting data from a virtual steering wheel. A few things I've noted while working on my AIRS project using the LFS racing simulation as it is retrieving information from LFS and inputting it back in through PPJoy:

1) PPJoy is likely someone as a casual user would not be able to simply download, install and go. They need a bit of technical knowledge to do this, and the ability to trust unsigned hardware, by clicking "install without certification".

2) I personally had some issues with PPJoy to LFS as a form of input. It took me a few days to get this setup. Within the first day I had input in LFS, but it seemed to me that all axis controls did not center themselves right. For all I know I did something idiotically wrong with the programming interface, though I tried to make it right, in the end I just hacked it so that it moves it offcenter and allows LFS to think it is centered. Enough to the point where the car stayed within 5 inches of the white line down the dragstrip.

3) Getting information from LFS is the easy thing, and I don't know of anything else that supplies the information like LFS (or as much/detailed). If you haven't found it yet Insim.txt in the documents folder would deserve a look over for you. There are three protocols:

3a) InSim Protocol: This is useful for almost everything you would need. When a race starts, what mode LFS is in, are you connected to a server. There is some information available about the car position and orientation. Lap times / split times / qualifying times, etc the list goes on.

3b) OutSim Protocol: Admittedly I haven't been using this like I thought I would need for my AIRS project. Though I may need to in the future, it give more detailed information about the currently spectated / driven car and the motions it goes through. As with my AIRS project though, tabbing to spectate other cars will mess up the 'data output'. Which might not be important to your project.

3c) OutGauge Protocol: This gives you all the information that the driver could get from the gauges and controls of the car; what gear is it in, what location are the pedals / steering wheel actually at? Headlights / indicators on? Fuel level (for player only), speed, rpm etc the list goes on. Again, tabbing to spectate other cars mess this output up, at least for my AIRS project which the AI driver depends on the information!

4) To control LFS, LFS _requires_ focus. Meaning if your application requires focus to get steering wheel input and send it to LFS you will not be able to drive in LFS. Your application will need to run in the background, silently collecting information from the G25 and feeding it back to LFS which is in focus. Otherwise you won't move the car.

5) What about FFB I don't think there is any output of this from LFS, so it might be hard to apply FFB to the wheel. Although, during my AIRS project I believe if the FFB in LFS was still on that my G25 would thrash around even if a PPJoy virtual controller was being used as well. So maybe this is a moot point that will go away.

Finally good luck on the project, although I don't know anything about how you will be manipulating the data. I hope my post is helpful since I've had a bit of experience with things your trying to do, at least it seems.

Thank you for both your replies,

AndroidXP: An inaccurate speed would be enough so i think OutSim would be suitable, but very good notice that it's not totally accurate, certainly something that must be considered.

BlackBird: Really good information. Seem LFS suits all our needs but will need some modification to work perfectly. FF will be used, but totally controlled by us and no need to get from the simulator. You say you made a AIRS project. Is that the company AIRS and if so, is PPJoy ok to use in non-commercial purpose? We are doing a project that will be used in demonstration purpose for the hardware and I think we will need the creators permission.

We will maybe need to modify the interface (make it disappear) somewhat also, but there seem to be a lot of settings for this ingame. But it would be nice if it was possible to be fully configurable.

Regards,

I don't know about the licensing behind PPJoy, although I would believe free. It is something the end-user would need to install, or if you're creating special sim-pod type thing you would install it, in which case you might need to look into the legal side. As far as end-user support, I stick to the fact that PPJoy should not be expected for the general public to download, install and use. It can be confusing and not "plug and play" enough for public use. The AIRS project is still in development, although I may need to change gears a bit and develop a simulation world for testing my AI. AIRS stands for: Artificial Intelligence in Racing Simulations. It is a project more for simulation AI Drivers instead of GAME AI drivers which I strongly believe there is a difference. Games are meant to be fun, while the simulation is meant to _simulate_. See the A.I.R.S. thread for more info about that particular project. Beware the length and discussion that has taken place so far.

For the most part I am sure you can do what you need to with the LFS interface just with LFS itself, there are numerous options available from custom camera views to virtual gauges and so on.

Thanks for the answers once again,

We actually got in touch with the creator and it seems we can make a deal of using PPJoy so that is probably what we are going to do. What's good with that solution is that any simulator could be steered with our application, not only LFS. The same calibration problem maybe will occur for us too, and if we fix I can tell you.

The AIRS project sound very interesting indeed. It's a really cool and engaged community around this game that I think "bigger" developers should learn from. This also makes me want to use LFS

Regards,

I'm trying to do something similar to o.p.

I have PPJoy working, and am now trying to get the sample app in the PPjoy docs working.

I'm actually trying to get it working with MASM32, as I don't have MS C++ installed.

I'm stuck trying to figure out what the value of IOCTL_PPORTJOY_SET_STATE
is supposed to be.

From reading the PPJIoctl.h file it would seem to be 0x0.

When I run the program, nothing is getting sent though.