Interfacing software to FS2002?

[Guest LeoL]

I'm a newbie wrt FS2002 and I'm trying to find info on how to interface my software/hardware with it. I would like to read values such as gauges and stuff and send this info to my hardware.I know you can communicate with X-Plane easily through UDP packets, but does FS2002 have something similar where you set it up as a host and connect to it through an IP address and port no. to read various values?Yes, I do know about FSUIPC, but I would like to do something specific for my hardware.-Leo

[PeterR 9]

Hi Leo,You'll still need FSUIPC in order to access detailed data in the sim. To get that data from another PC over the network, you can use WideFS (also on Peter Dowson's FSUIPC site). WideFS makes the client PC on the network appear to be the one running FS.Without FSUIPC, you can only get basic info such as position, orientation, speed, and aircraft. And to get it, you'll have to build a DirectPlay server (ala FSHost) to get FS to communicate with you.Peter http://bfu.avsim.net/sigpics/PeterR.gifBFU Forums Moderator[table border=2 cellpadding=0 cellspacing=1][tr][td][table border=0 cellpadding=8 cellspacing=0][tr][td bgcolor=#540000]http://bfu.avsim.net/sigpics/logo75t.gif[/td][td align="center" bgcolor=#FFFFF6]Bush Flying Unlimited"At home in the wild"Looking for adventure? Come join us! * [link:bfu.avsim.net|Web Site] * [link:www.cafepress.com/bfu,bfu2,bfu3,bfu4|BFU Store] * [link:bfu.avsim.net/join.htm]Join!][/td][/tr][/table][/td][/tr][/table

[Guest MikePowell]

Hi Leo,I am not aware of any Microsoft utility that handles hardware IO with FS2K2. (Other than the obvious keyboard/mouse/game controller route, which I gather is not what you're looking for.) The only Microsoft accessibility to simulator state is what is described in the panel/gauge SDK. As far as I know that only allows one to read values, not to write. I have seen only one post by a cockpit builder who indicated he had used the SDK information to export state values. By far the most popular avenue is using FSUIPC. This gives you access to state data and allows you to write to many, though not all, of these internal variables. You are left to develop your own communication link, be it com port, USB, network, etc.If you run across any other means of reading and writing FS data, please post it here.Mikewww.mikesflightdeck.comInfo for simpit builders

[Guest LeoL]

Thanks for the input guys.Peter: Basically what I'm asking for is how does FSUIPC programmatically communicate with FS? Using some kind of "shared mem", UDP through winsock, through some DLL perhaps, etc.?I

[Guest MikePowell]

Leo,FSUIPC is a descendant of FS6IPC which was originally developed by Adam Szofran. My meager understanding is that FS6IPC read a block off FS's heap and formatted the result to be useful. Specific variables were accessed through offsets in this block. Mr. Szofran has moved on, and Peter Dowson now maintains this utility. As FS has been upgraded, the actual memory positions of the MSFS simulation engine variables have moved about a bit and are no longer accessible as simple offsets. Nonetheless, Mr. Dowson has kept on top of new FS releases and has enhanced FSUIPC so that it continues to present the same (or very similar) interface to the lib user.Bottom line is that Peter Dowson is very likely the most knowledgeable person outside of Microsoft about getting cozy with FS state information. An email address for him is available on Enrico Schiratti's site.Keyboard emulation is not the only way into FS. FSUIPC manages to write. In the FSUIPC documentation there are a few variables ("offsets") with notes cautioning writing, indicating undefined results. Most variables do seem to offer the capability of write access.The MS panel/gauge SDK offers access to proxy variables that, as I understand it, provide read-only access. A caveat; I have read the SDK but have not tried to use the knowledge myself. Please don't take my limited knowledge as the final word.Mikewww.mikesflightdeck.com

[Guest LeoL]

Thanks for the backgrounder Mike.I took a closer look at FSUIPC and I'm amazed that this was done essentially by "hacking" MSFS! I thought MS provided some kind of SDK for this sort of thing, but I was surprised to discover there are non!I also found that they have an excellent FSUIPC SDK, which explains how it all works including code samples. I was under the impression that I had no choice but to use their application. Seems I can use a dll with my own application to read / write directly to the sim variables. That's good enough for me.Looks like I have lots of reading to do.It's too bad MS doesn't provide documented SDK for this stuff and allow the enormous pool of third party developers a chance to enhance their product.-Leo

[PeterR 9]

Leo,Yeah, lots of the excellent add-on stuff for FS is the result of hacking. The SDKs only scratch the surface of the sim and don't reveal a lot of the internal workings. A more recent example are XML gauges.FSUIPC isn't an API, per se. What appears to be directly reading/writing sim variables is actually your application/DLL using the offsets in FSUIPC's memory block. In other words, FSUIPC emulates (via interprocess communication with FS) the sim state variables as if they were FS98 memory offsets. So you would still be interfacing to FSUIPC.To bypass FSUIPC, you'd have to build your own FS module and find all the state data for the various versions of FS (they tend to change and move around in different versions). I don't know how you go about making a module for FS. Never got around to digging into that.As for controlling things in FS, if you write a DirectInput driver for your hardware, then your device will appear to the Windows system, and hence the simulator, to be a game controller. Functions in the sim can then be assigned to "buttons" and "sliders" on your device using the controller configuration dialog in FS.Regarding creating your own gauges to get info and control the sim, I don't think that's the way you want to go because then your gauge would have to be added to every aircraft on the user's system in order to function. That's not something you want to have to deal with for an add-on hardware device.Peter http://bfu.avsim.net/sigpics/PeterR.gifBFU Forums Moderator

[Guest LeoL]

Yup, I read the FSUIPC SDK and the fog is starting to clear. ;) I agree that the FSUIPC dll is a plug-in for FS and not a direct link, but I see no problem with this approach at this time. Originally, I was under the impression that FSUIPC was an executable that I had to interface with. I was concerned with lag times using this approach. Since the interface is through a dll, I'm pretty sure interfacing performance will be the same whether I go through the fsuipc dll or I make my own plug-in dll.I don't intend on creating gauges that drive the sim as you indicated. Off hand I can't think of a reason to do so, but I do intend on driving gauges from FS and feeding device inputs (switches, rotaries, etc.) wherever possible to FS variables in order to eliminate KB emul.I've decided long ago to stay the hell away from writing devices drivers! I've read a couple of books on the subject and all advise to do it only as an absolute last resort. When you consider the shear number of OS versions and service packs per, each driver has to be tailor made for all these variations...I will likely spend the rest of my days making sure I keep up with all MS changes and service packs!That's why I'm currently working on an Embedded Ethernet solution for all hardware interfacing. This way all I need to do is read from FS->fsuipc->MyApp and send UDP's to the Ethernet hardware to drive gauges, lights, etc. Likewise for the reverse, writing inputs to FS variables. The result, no gameports, no USB, no KB emulation!Thanks for all your input guys!-Leo

[Guest steve_j]

Hi!I use FsCommunicator for communicating with my EPIC. With this program you can easily read and write every FSUIPC offset!You get it here: www.flightsimulator.atI hope it helps...steve---------------------------------------------------------------------Do you know the A320 Flightdeck Project? Visit www.a320flightdeck.com

[PeterR 9]

Embedded Ethernet sounds cool. How will the IP address of your hardware be set up? I assume it'll be some kind of central "brain" from which all your devices will be driven.Peter http://bfu.avsim.net/sigpics/PeterR.gifBFU Forums Moderator

[Guest LeoL]

So far, I've only found solutions with preprogrammed fixed IP's. I don't like that so I'm going to adapt the code for DHCP and have an IP dynamically assigned to it by a host....if it's not too complicated. Luckily, TCP/IP stack code samples abound, so most of the work has been done.Actually, it won't be a "brain" at all. All the brains will be the app running on the PC that interfaces with FSUIPC that I've been talking about. The Ethernet module will only pack/unpack UDP data and send the info onto a parallel data bus (maybe PC104 standard, not sure yet). The I/O modules attached to this hub will know what to do with the data.-Leo

[Guest LeoL]

Thanks for the link Steve, but from what I gather it's used to communicate with the serial port. I won't be able to use this with my hardware since it will be Ethernet based and communicate via UDP packets.I basically need to create the equivalent of FsCommunicator but for Ethernet communication.Thanks again.-Leo

[Guest]

Leo,What embedded ethernet solutions are you using? How many IO lines do they provide? I'm looking for something similar.Chris

[Guest LeoL]

I'm looking at creating my own based on the RealTek 8029 chip and either a Motorola Micro or an Embedded 486 module. Why? Because most are too slow to make them worth while and others only provide you with a serial connection to your hardware...which defeats the purpose!How many I/Os? If I do it right, more than you will likely ever need. You just add more IO modules as needed, but don't hold your breath. I'm looking at a solid 3-6 months dev time!Were getting off topic with this, but if you need more info, just PM me and I'll send you some links.-Leo

[Guest MikePowell]

A few links here: http://www.mikesflightdeck.com/ethernet_1.htm Mikewww.mikesflightdeck.com