[LazyNinja]

I recently purchased a Saitek X52 Pro Joystick+Throttle combo and am looking for ways to display the different parts of the game data such as Escort list, target info, etc. on the MFD. The way I see it, there are two ways of going about it:

1. Modify FSO to transmit the necessary data to the X52 using DirectOutput
2. Get access to the in-game variables through some means, then use an external program to write to the MFD.

I believe #2 is the better choice, as it leaves options for using the data in different controllers (and different environments, like Linux). Now, is there currently any way that in-game data can be exported to an external process, or does this require extensive modification to the existing code base?

Secondly, is there a way to make the external process pass commands that are accepted by FSO? I am currently thinking that the process should generate the appropriate keyboard events, but I'm not sure if that will work.

[Nuke]

i thought about doing something like this with a pda. surplus pdas can be had for a dime a dozen and you could build a few mfd displays with them assuming somone wanted to write the software involved. i dont much like the display on the older x52, though ive never seen what the x52 pro display can really do (i use ch). is it a partial text only display like the old one or is it a full pixed display of a certain rasolution?  one thing i wanted to do is stream rtted panel textures to the pda and display them, then on the pda side you could have defined buttons and other operable controls which will get relayed to the pc and converted to keystrokes.

[LazyNinja]

i thought about doing something like this with a pda. surplus pdas can be had for a dime a dozen and you could build a few mfd displays with them assuming somone wanted to write the software involved. i dont much like the display on the older x52, though ive never seen what the x52 pro display can really do (i use ch). is it a partial text only display like the old one or is it a full pixed display of a certain rasolution?  one thing i wanted to do is stream rtted panel textures to the pda and display them, then on the pda side you could have defined buttons and other operable controls which will get relayed to the pc and converted to keystrokes.

It's still a text grid of 3 rows, 16 characters per row, messages scroll if longer than 16 characters. I know, I'd love a full raster style display, but the X52 pro doesn't support it 

Your idea is almost the same as mine. I wanted to really make a full cockpit simulator for FS2 (http://www.hard-light.net/forums/index.php/topic,55580.0.html), but I'll settle for a way to access the game data. I think that way, modders can use the game data for their own setups. I'm ready to do some coding, but I'm a bit confused as to where to start.

[Nuke]

here is something i posted over on the btrl board you might find intresting, its a rundown of how one could sorta hack multi monitor configurations into freespace. essentially id need the ability to add scriptable borders to the tob bottom and sides of the screen. then youd take 4 screens in a spanned mode (probibly using an sli config, to drive pixels and provide extra places to plug monitors). then you would put one on either side of the "canopy" one up top, and one in front (mounted vertically), essentially puting the monitors where the windows would be in a cockpit canopy (much like that on the pyro gx). then you trick freespace into using all the screens as a spanned monitor (which can be done). you just set borders (much like the ones you get in the death screen) to blot out all screens but the front one. then you rtt textures from different camera angles, and draw them in places where side and top monitors exist. thus simulating the view from the cockpit.

there are other threads where i posted some other ideas i had for cockpit simulators. everything from mfds and joysticks to 3 axis gimballed platforms for motion simulation. alternatively theres virtual cockpits, which can have rtted displays and look around with a track ir. not as fun as a real cockpit but is often close enough and much cheaper to set up..

[LazyNinja]

I think I'm going to have fun with this joystick

I've developed a small standalone application (attached below) which simulates the ETS subsystem of the fighter on the MFD of the X52pro. The ETS code is a bit buggy, but the application is more of a proof-of-concept that you can easily develop a UI for FS2 on the X52pro. You'll need the DirectOutput DLLs (from the Saitek SDK) to run it.

All that is remaining is to actually get the data from within FS2. From within the code itself, it looks like I need to access the ship structure to get the bulk of the information. I'm just unsure as to how to interface this information to an external process. I was thinking of putting the required info into a shared memory region on every frame. FSO folks, do you have any ideas on how to implement this?

[attachment deleted by admin]

[WMCoolmon]

What I'd like to see is some kind of network access where FS2_Open can transmit the information via the TCP/IP stack, which is then received by a program which can do whatever.

This maintains the crossplatform nature of FS2_Open without any more external libraries, and it's also easily expandable if you want to do something with a PDA like Nuke's suggesting. You just have to make a program that can receive the packets from FS2_Open.

For shared memory applications, the idea would be that you have a template application that handles connection to FS2Open and then performs whatever task (eg updating an external display) that you want from it, rather than from FS2Open. This is also a bit more secure, since that way no application has direct access to FS2Open variables.

[karajorma]

What I'd like to see is some kind of network access where FS2_Open can transmit the information via the TCP/IP stack, which is then received by a program which can do whatever.

This maintains the crossplatform nature of FS2_Open without any more external libraries, and it's also easily expandable if you want to do something with a PDA like Nuke's suggesting. You just have to make a program that can receive the packets from FS2_Open

The idea I had for fixing multiplayer SEXPs would actually use a similar format (Which is why I think it can also be used to allow server side scripting with results passed on to the clients). The smartest thing to do would be to make the system generic enough that all three systems (SEXPs, Scripting, external devices) could use it with only minor changes in code. As I envisioned it the code would only sent packets to players who are connected but with some alteration it might be possible to have the option to send to any machine I want to. I'll make the SEXP post public so Lazy Ninja and Nuke can see it. You can find it here.