n4gix

Pete, the Citation X v2.0 uses FSUIPC to intercept the hardware throttle input(s), pass them through the FADEC system, then forwards the massaged values onto the sim. Ed Wilson chose to use a user's registered FSUIPC since the same gauge module had to be compatible with both FS9 and FSX. :cool: The CX is still "flyable" without a registered version of FSUIPC of course, albeit without the finesse of FADEC support.

Pete, I just wanted to say just how much I admire and respect your ever-so-helpful attitude! That's going well beyond the normal bounds of support. Bravo Zulu, sir! B)

Your Registry entry is screwed up... HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator\9.0 INSTALLATION FOR FS9: EXE Path="D:\Program Files" That path is incomplete at best... It should be something like this: D:\Program Files\Microsoft Games\Flight Simulator 9

Why not simply read the aircraft.cfg file for the data you need? It's not that difficult to do... :mrgreen:

Very nicely done, Raimund! Might I suggest that you edit the spelling of "breaks" though? The proper spelling is "brakes". :)

Well, congratulations on achieving a new level of maturity. It speaks very well for your integrity that you took the effort to come here, create an account, and make such a public apology! :D Don't be discouraged however if your "teacher" shows little or no understanding of the harm he's causing by his poor example. If one doesn't learn moral values during puberty, it's unlikely to happen after reaching the age of adultery (er, I mean adulthood of course!)... :lol:

Thanks, Pete. I'll crack open your SDK then and begin reading. Odd that I didn't think to search for "plan," usually I'm better at researching things for myself... :oops:

Pete, I'd like to ask a simple question, knowing full well that I could eventually find the answer by studying the SDK carefully enough. Time being at a premium for me however, doesn't allow me that luxury. What I'd like to do is write a freeware module that would allow any XML scripted GPS or FMS to access and display stored FSX flightplans, then load them into the sim at the same time they are loaded into the gauge's own fp database. I see that FSX FSUIPC's toolbar has that ability, so my base question is really this: is this facility available programmatically from such a custom interface module? If so, then I'll gladly invest the time studying your FSUIPC SDK. If not, then I'll seek another solution. :mrgreen:

I hope some other Citation users will come to help you here, because I don't know. From the response you got from Eaglesoft it sounds like they actively intercept the generic single throttle and use that, which really prohibits having reverse on the same lever. Of course you can retain your existing throttle setup for other aircraft and have the Citation done differently by making the assignments and calibrations in FSUIPC aircraft or profile specific. But that doesn't help with the Citation. Regards Pete Just to be clear, one CAN use the multiple throttle facility to have separate L and R throttles. What is not supported is the "reverse thrust" feature. As mentioned already, one would need to create a named profile specifically for this aircraft, and would need to edit the Citation_X.ini file to specify 2 throttle lever operation. The reason Ed uses the calibrated output from FSUIPC is simply because the FADEC algorithims require, consistent, predictable, and jitter-free values for throttle lever position(s). The reason reverse is not supported is likewise simple. How could the algorithims used know what specific value to use for IDLE, were the user allowed to set it arbitrarily? :lol:

It occurss to me Pete that between FSUIPC and SimConnect, there already exists the possibility for someone, or some group to build a sim-outside-the-sim using FSX only as a "base platform," sort of like what ESP was supposed to be... :wink:

Step 1: Go here - http://www.schiratti.com/dowson.html Step 2: Read instructions Step 3: Download correct version, run the auto-installer program Step 4: For freeware features, you are done Step 5: If you want the full features, you need a key, so go here with credit card in hand - http://secure.simmarket.com/product_infts_id=2068

Strange response, to be sure. I've used my Visa Debit card at SimMarket several times over the past few years... ...after all, that's the entire point of having a card with either Visa or MasterCard backing, so the vendor can treat it as if it were a credit card if they don't support direct debit support...

I don't know what M$|ACES "broke" with regards to the taxi lights on the default FSX aircraft but I noticed this afternoon when flying Dave Maltny's excellent BAC 1-11 500 that both the taxi lights and landing lights work just fine in FSX. This isn't really the forum for this discussion (as it has nothing to do with Pete's FSUIPC support!), but briefly... FSX and FS9 use two entirely different methods to create landing and taxi lights. When FSX was released, the code to support the "FS9 lighting" was broken. FSX SP1 has fixed the broken code, so now any model that uses the FS9 type lighting works. FSX on the other hand, never had "taxi lights" implemented, thus they don't work on any of the default models. I have no idea why this happened, but nevertheless, that's what we have. However, it is a trivial matter for developers to ADD the "missing XML code" to their modeldef.xml file so they can have both landing and taxi lights. As you've stated though, there's nothing at all anyone (other than ACES) can do to "add taxi lights" to the default models.

Not to worry, Tim! I certainly saw the intention behind your post as merely being one of reporting a possible problem with the latest version of FSUIPC reading and reporting the TAS variable. The second paragraph being then only a tongue-in-cheek comment regarding alledged support response... ;)

Actually, Gary... the only relevant information in the OP was that the latest version of FSUIPC caused a previously working gauge to quit working, as demonstrated by replacing said version with the previous version. Hence, the problem is properly one of continued FSUIPC integrity, and one of which Pete needs to be made aware. After all, what is "broken" for one, will be "broken" for all FSUIPC users... :lol: Please understand that given the present circumstances, the nerves of nearly all developers, customers and yes - even ACES folks - are stretched tighter than high C on a piano, so it's hardly a surprise that there are times when one's posts and/or replies might be seen as something other than what they are actually intended.