Sign in to follow this  
Guest TheSpecialist

FSUIPC look-a-like for Fly!

Recommended Posts

HiI'm currently developing a program that interacts with the flight simulators on the market, I'm using FSUIPC to get to FS98/2000/2002 CFS1/2, but now my question is: Is there such a software for Fly! also?I'd prefer the access via Visual Basic (my knowledge of C++ is not very much currently).Thanks,

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Many of the core functions of Fly! are exposed through the SDK interface. There's no need for an add-on module. Programming is either Fly!Scripts (a friendly front end for the SDK), Python or C++.Andrew Luck18 miles SW EGSH

Share this post


Link to post
Share on other sites

it). Then, too, you would have to find someone willing to actually implement it. I suppose it would be interesting to have, but am uncertain of the necessity.Hope this clarifies...Cheers, Tony

Share this post


Link to post
Share on other sites

Actually, the way the Fly! subsystems are implemented, there would be a great difficulty in writing an FSUIPC-type linker library. The reason is simple: Each developer names their subsystems according to their own needs and wishes. For example, the PMDG engines could be named 'eng1' and 'eng2', with subsystems 'n1n1', 'n2n1', 'n1n2', n2n2' for N1 and N2 indications respectively. Other developers' systems could have different names for their subsystems, so an FSUIPC-like linker library would not know where to get each piece of information.Make sense?

Share this post


Link to post
Share on other sites

Hi Lefteris,That's true. However, for an encore, god created XML (seems he had nothing better to do with his time and was sloping around for extra programming work). With a little ingenuity, a relatively straightforward translation schema could be constructed. Given this schema, most systems and aircraft could be mapped to the FSUIPC structures. Wouldn't be exactly perfect, but could come reasonably close. Since the messaging system within Fly! II is quite elegant, I think it could be done. On the other hand, your point is well taken. Someone would have to hunker down and work up the translations--not my idea of a particularly good time. Just look at my Mapper.DLL, for instance. My goal was to create a generic axis mapping schema that the Mapper.DLL would load so as to work out how to map unconventional systems. To this point, I've designed the schema, but can't seem to find the motivation to implement it (I wonder why). The upshot is that I stand by my original statement, but concede you the point. I've no desire to start hacking that mess out, to be certain. I guess we'll have to give FSUIPC a miss, eh? Cheers, Tony

Share this post


Link to post
Share on other sites

Hi TonyI am looking forward to someone to make this DLL. The reason is, there is a interesting home-cockpit projekt on Internet (www.fsbus.de), which is based on this DLL.Several years ago i built a device, based on a 80c535 microprocessor to set the radios and switches via switches and rotary dials, emulating key strokes. It worked fine with FS98 and FS2000, but never really with FlyII.Maybe this would be a solutions.Harald

Share this post


Link to post
Share on other sites

You know Harald, you're a trouble-maker. I was so looking forward to not trying to implement it. Oh well, no rest for the wicked... :-lolI've actually given this a bit of thought, but it's a big job. I'm not sure I'll actually be able to pull it off. The biggest problem is implementing the translation schema and it's a biggy, too. What on earth is wrong with me? :-)Cheers, Tony

Share this post


Link to post
Share on other sites

HaraldLooks like I missed the point in the question here. Apologies.I too was looking at a similar project to yours a while back using one of the new parallel-USB interface modules that are now available. It all fell apart when I looked at the programming complexity of using it with Fly! though. I'll have to take another look when I get back from the Avsim conference.Andrew Luck18 miles SW EGSH

Share this post


Link to post
Share on other sites

Hi Andrew,Can you send me the programming specification for your USB interface module? I may be able to help with some of the programming here. After working on the Mapper DLL, I have found that talking to Fly! isn't as hard as it seems. The biggest problem is knowing what you want to talk to (and sometimes this can be a real unknown), but if you can figure it out, it's quite easy. As I've said, the messaging interface is really quite elegant.Cheers, Tony

Share this post


Link to post
Share on other sites

Harald,This could be done quite easily with the SDK, and with a home cockpit it would be even easier because typically you are attempting to model a specific aircraft, so you can hard code the message tags (the problem Lefteris referred to).On top of that, I added full EPIC card support to Fly!, but never got a chance to test it on a cockpit. You should be able to use the EPIC SDK commands to trigger EPIC scripts or memory locations, so a home cockpit would certainly be an interesting project.As for FSUIPC, Lefteris correctly points out the problem. FSUIPC operates by mapping fixed global memory blocks in FS2K2. In FS2K2, ever plane is identical; i.e. each plane can have 4 engines, 2 tanks, 2 COM radios, etc. Pete is able to simply map to this fixed memory map regardless of what plane is being used, and pluck (or set) values directly.In Fly!, each plane is actually wired and built like the real vehicle, so you have to know the mapping yourself. And, unlike FS2K2, the user aircraft in Fly! is no more special than any other aircraft. There is no "global" memory block for the user plane; it exists as an airplane object in the world just like any other object, and has it's own traits, variables, and simulation. This makes direct mapping impossible for all aircraft. On a vehicle by vehicle basis, however, you can use the SDK block commands to define messages for a range of different aircraft values, and then update the entire "block" of values in one easy call. You could use this once per frame to update a local memory mapping of values you care about in the "outside" world (SDK side) and read those values during your callbacks.Rich

Share this post


Link to post
Share on other sites

Hi Richard,I agree with what both you and Lefteris said (well, I would have to, wouldn't I? Since you're the grey-bearded founding father of our...err, wait...let's not get needlessly messianic here! :-lol); however, my (admittedly, blue sky) FSUIPC solution would permit a client program to link to Fly! II, submit its requests via FSUIPC_Read and FSUIPC_Write, and when the FSUIPC_Process method is invoked, pause while the FSUIPC.dll for Fly! II processes the individual requests, one per DLLIdle invocation. When the FSUIPC.dll is finished, the results would be marshalled (the FSUIPC mechanism uses file-mapping objects) and the FSUIPC_Process method would return control to the client program. Consequently, Fly! II would see no real impact as only one APISendMessage call would be made per DLLIdle iteration. The real trick is to know what APISendMessage parameters are required for a given aircraft. As Lefteris (and then you) pointed out, it is thought that there is no "easy" way to do this. I happen to disagree. Having a doctorate in linguistics (semantics really) and working as a software engineer in research and development for the past 20 years gives me a rather unique (though some would say "warped") perspective: in short, everything is a document and every document can be translated.Using the flexibility of XML, I believe that I can construct translation tables that would permit the efficient mapping of FSUIPC offsets to APISendMessage parameters. Doing this on a plane-by-plane basis, would make such a mechanism a "global" solution. Mind you, I don't believe that this is an easy job. It isn't--quite the opposite, in fact. I just believe it is achievable in a way that avoids the problems outlined by Lefteris.I intend to try creating a mock up of the FSUIPC interface just to see how it behaves and will report my findings to this forum.If I succeed in creating a reasonably efficient IPC mechanism, the majority of the work would come about in the form of creating the XML translation schema. And as I've already indicated, I would probably rather jab a screwdriver in my eye. After all, I may believe that every thing is a document and can be translated, but it doesn't mean that I believe everything should.Anyway, I mean to give it a whirl.Cheers, Tony

Share this post


Link to post
Share on other sites

Hi Andrew, Hi RichThank you for your response.By now i don't exactly know, how i would like to build my new home cockpit.The old version was switched in between keyboard and computer and the 80c535-mikroprocesser was1.) emulating the keyboard protokoll2.) syncronize the input from the keyboard and the switches3.) did the translation from the switches to keystrokesBut tuning the radios and flight instruments via keystrokes (on my installation)never worked for Fly in way I really liked. (but - I am sorry to say - worked fine with fs98 and fs2000).But - as a (freelance) flight instructor - I like the complex panels of fly and fly2. So I removed my home cockpit and started with scenery design for FlyII.But last month I found this FSBUS-Project (www.fsbus.de) on internet and the home-cockpit virus attacked again.This project does all the the communication via a bus-protocoll on the com-port. You find there all the drawings, the microcode and everything you need to build the necessary hardware (with LCD-panels) for the radios.And all is freeware.So it would be nice to use this equipment for fly2 too. This project communicates with MSFS via fsuipc-dll, so my idea was: why not simply use a similar dll for fly.But I see your point and maybe there is an easier solution. thank youHarald

Share this post


Link to post
Share on other sites

If you guys could pull this off I will convert my full scale A320 simulator from FS2002 to FLY2. You guys just work I would be glad to test it for youRegardsHenrik

Share this post


Link to post
Share on other sites

TonyThere's nothing particularly obscure here. The module from http://www.ftdichip.com comes with a driver that emulates a serial port. I briefly looked at using a Python serial I/O module but Python doesn't run with my particular install of Fly!2 and working from a knowledge base of zero here didn't help either (I'm an electronics engineer by training).The circuits that Harald is refering to could be easily modified to replace the RS-232 driver with an FTDI USB module, the supplied driver means that there should be no change to the serial software supplied.But... The most impressive hardware being displayed at the Avsim Conference for me was the AeroSoft 747MCP panel. Now if we could get that working for the 757 I'd order one tomorrow. The icing on the cake is the two expansion ports on the back that can be used to interface additional switches, rotary encoders, LEDs etc. All the complicated electronics stuff is done for you.I had a brief chat with Andrew McLean from AeroSoft on this subject. At present it works with FS2002 via FSUIPC. However, as we're only really concerned with getting it working with the 777 and 757 the problem of Fly!s object orientation becomes lessened as Rich has explained in another post. If it can be done for the GoFlight kit then it can be done for this.And another thing...AeroSoft are working on a CDU as well :-jumpy Andrew Luck18 miles SW EGSH

Share this post


Link to post
Share on other sites

Andrew-since you mentioned you discussed this with Andrew McLean, he might have mentioned that a 747MCP is on its way to me, so I can program the interface for the 757 and 777.I have an email sitting on Andrew's desk waiting for him to return to Australia... ;-)As soon as I receive the unit, expect more news regarding this interface (which might be forsale or free - I haven't decided yet ;-) ).

Share this post


Link to post
Share on other sites

LefterisHe didn't mention you by name. He did say he was in discussion with PMDG, I guess that's you :-)With the degree of interest expressed at the conference, he's going to get to work clearing the order backlog. Best give him a day or so first though. I just slept for 14 hours straight after the trip back from Tahoe :-dohAndrew Luck18 miles SW EGSH

Share this post


Link to post
Share on other sites

Hi Tony,Was wondering if you had any success on building the FSUIPC like interface?The reason I ask is I've downloaded SpeechBuddy2 and would like to extend it's FlyII capabilities by being able to tune NAV/COMM's, etc. via voice.SpeechBuddy2 translates speech into keystrokes and since Fly!II does not have keystrokes for setting NAV, COMMs, HDG bugs, etc. I was hoping this interface would be beneficial.Regards,Bob Lyddy

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this