airforce2
-
Posts
204 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by airforce2
-
-
Pete;
I don't see anything specific on the topic.
The aircraft-specific assignments are made when you press the "assign to aircraft" button in the driver dialogue window. It places an entry in the Aircraft Quadrants section of the ini file:
aircraft_title=Uxx where Uxx is one of the 15 quadrant definitions, yes?
The question is, can I use a substring, e.g.
Feelthere A3=u15
to catch every aircraft that starts with "Feelthere A3", for example:
Feelthere A318IAE
Feelthere A320CFM
Feelthere A319CJ
etc etc
Cheers
-
Hi Pete;
Are Short names (aircraft title substring matches) enabled in the PFC driver Aircraft Quadrants section like they are in FSUIPC? My Aircraft Quadrants section in pfc.ini is immense...shortnames could cut that down to size considerably.
Cheers
-
OK, thanks Pete. I did previously check the .dll digital sig per the docs. However, before I run FS I use always Ken Salter's FSAutoStart utility, as many others do. In FS AutoStart I discovered that I had the Cryptographic Service selected to be stopped per the program's recommendation. FYI for the future...may be a good idea to test that the service is running and throw an error code if not, given the wide usage of FSAutoStart and the fact that it explicitly recommends people stop the crypto service. Your call, of course.
But...the problem was indeed intermittent...however that error was coming from FSLook, not from FSUIPC directly.
Cheers
-
Pete;
When using FSUIPC 3.72 and FSLook from the v27 SDK, I am getting intermittent errors from FSLook complaining about the version number of FSUIPC. It's a sporadic thing, but almost always comes up, especially with more complex aircraft.
I recently saw a post on AVSIM with another guy using 3.72 seeing a version error reported by the PMDG 737 panel.
Reverting to V3.70 stops the behavior.
Cheers
-
Pete;
The electrons are streaking your way now.
Cheers
-
Pete;
Having trouble trying to program my PFC yoke buttons in FSUIPC in a new FSX installation. Programming buttons within the PFC driver works OK, but if I go to FSUIPC Buttons+Switches tab, and press the PFC button, nothing happens. Have repaired SimConnect, and tried 4-5 versions back from 4.03/4.065...same thing each time.
Regards
-
Hi Pete;
Yes, it's true that FS9 does not compute EPR in any meaningful way...EPR values coming from the FS9 FDE engine are generally nonsensical...like seeing 1.6 EPR at idle on the ground. Much has been written on the topic in the AvHistory.org FDE forums among others. Indeed, some competent panel programmers do in fact get it right with custom programming in their gauges...PMDG, Dreamfleet, even my own gauge work in the TinMouse II 737 (shameless plug alert!). But I'd love to be able to divert the indirection in FS, making it write the flawed EPR values to some unused corner of the data area, and replacing the data at the address used to access EPR with externally generated data in lieu of the flawed EPR values that are being read from FS by a number of otherwise decent panels written by guys that simply didn't get that part right.
Anyway, the project at hand right now is to make a working EPR gauge for the JT3D-7 in the CaptainSim 707...they, unfortunately, use a single massive multigauge panel (the entire main panel is a single gauge) that doesn't lend itself to replacing one errant gauge, and they are utterly hopeless when it comes to fixing things once they consider a product to be close enough to done.
Cheers
-
Pete;
Is there any way that you could put a feature into FSUIPC 3.xx that would allow a programmer to write an EPR value to an FSUIPC offset and have that value poked into FS9's extern data table (overriding the flawed FS-derived value)? As you know, the EPR computations in FS9 are hard broken...but there's a lot known on how to derive valid EPR values from other parameters such as CN1. In an ideal world, each panel developer would do this, but the world isn't ideal. I'd like to be able to write a piggyback program to compute and write valid EPR data that would override the FS value and be retrieved when a lookup of the FS EPR value is performed by otherwise salvageable panels like the CaptainSim 707/727 for example.
Anyway, I figured if anyone could work that sort of magic it'd be you.
Happy Holidays from sunny central Chile!
-
Have a look at the GAUGE_KEY_EVENT_HANDLER function in gauges.h.
The reaction to an FS control by this function is immediate. You can use it to completely inhibit user control over the flaps (or any other control surface for that matter.)
Drop me a PM or e-mail if you want help with it.
Thanks Doug...I'll do that.
Cheers
-
Eryou mean MOVE the detentes? Change the number of flap detentes or change the angle?
No, I want to move the flap handle through the detents, but without necessarily moving the flaps.
I'd like to know how to do that in order to make my flap operation mask facility work better. Please, tell me how you manage to separate these things.
The flap handle position set & displayed with the make_slider macro uses an internal variable rather than the flap handle position in FS. The FS flap handle position (which seems inextricably linked to the actual flap position) is set by the gauge based on the internal flap handle position variable and the other conditions necesary to move the flaps. Changing the displayed flap handle position is done currently by writing a value to offset 0x6D11...2 for raising, 3 for lowering the flap handle position. Users map buttons via FSUIPC to control the flap handle (like my PFC quadrant's double-throw spring-centered switch) What I want to do is allow a hardware lever's position (mapped via FSUIPC so a user can use any lever FSUIPC can detect via a common interface) to be used to set the flap handle variable in the same manner.
You are doing this from an external program, or is this a Gauge or DLL?
gauge now...but access to the joystick values by an external program via FSUIPC would be useful.
If you are actually writing a program to do these things, why not just read the relevant joystick axis yourself, using joyGetPosEx, same as FSUIPC does?
The problem is that the relevant axis will vary from user to user. What I want to do is allow users to map any hardware lever to control the function. The lever on a CH yoke will be different than a PFC lever. FSUIPC does a nice job of detecting a hardware device and allowing it to be mapped to where needed. In this case I want to allow a user to select any FSUIPC-detected lever and have it send its position directly to a specific FSUIPC offset which is used to control the custom flap handle pos.
If this is from a Gauge or DLL internal to FS actually controlling your own graphics lever, why not simply assign your flaps axis to a different, otherwise unused FS axis control, monitor that via the built-in PANELS facility for doing such things (register_key_event_handler), move your lever accordingly and IF the flaps should be working okay, send on the appropriate flaps operation by trigger_key_event?
I did that for the spoilers using PROP1 and PROP2 axes. But I don't see a lot of usable but unused axes.
I think RAW values are more usually in the 0-255 sort of area. Check by setting the RAW option in FSUIPC Axis Calibrations. Scaling is part of Windows calibration, scaled values are those read normaly. The joyGetPosEx facilities will only provide RAW or Calibrated for all 6 axes on a joystick, you can't mix them, so you might be limited as to which mode according to how the others are being used.
I can use any scale...0-255 works fine.
Anyway, after sleeping on my idea I decided it was too messy. If I were to do it (if I could see the need, which now I can't), now that I know it is for programmatic use, not for some existing interface program, I think I would opt to implement is all via offset writes and reads, like the FSUIPC HotButton facility. You would register an intrest in an axis and FSUIPC would scan it for you and return regular updates.
That'd work fine. The desired endstate is to have a user use FSUIPC as the single routing function for key/button/axis assignments, and to be able to select which hardware joystick axis will be used to make the input to (in this case) an internal flap handle position variable via an FSUIPC offset used internally.
Hope this is clearer.
Cheers
-
Hi Pete;
What I am trying to do is read a raw joystick axis value and, based on the value, control flap detent settings. I have to do it apart from the regular flap axis because I want to separate flap handle movement from flap position. This allows the flap handle to be moved, and if system configuration is not appropriate (hydraulic press, electrics, no assymetry etc) the flaps won't move with it. I've used the mask feature, but it tries to move the flaps initially before your code catches it and puts the lever back...and which also triggers sounds etc. I can think of other uses for such a feature as well.
What you described...a special value for Parameter that would cause the axis raw value (scaled 0-16384?) to be sent to the offset if it has changed, is exactly what I had in mind. That gives a panel programmer direct access to hardware lever position data that can be used to perform proportional control over other than established FS axes...like operating an externally programmed engine supercharger, as one example.
My current project (the TinMouse II B732 panel) is still FS9-only, but my intent is to port it to FSX at some point.
As always, many thanks for your wizardry and help
Cheers
-
Pete;
Is there a way in FSUIPC to assign a hardware axis to send its value straight to an offset? I need to be able to take a joystick lever raw value and access it via an offset without trying to assign it to an FS axis...I'm out of usable FS axes.
Thanks
-
I had something similar going on, and finally tracked it to a change that had occurred in my FSUIPC.ini that had removed the line:
RemoveATC=Yes
This caused the old ugly atc.dll CTD to come back and haunt me for the majority of one very frustrating weekend.
No idea how the ini file was changed, but I went back to my saved copies and it looks like the change happened around the time I upgraded to 3.70 There had been a few random dumps...but a few weekends ago I found a flight profile that really tickled the atc.dll bug and it was a steady stream of midflight CTDs. Once the param was put back...voila.
Regards
-
You might try changing var names...you are using same vars as defined in the functions (i.e. "Param"). The scopes look OK at first inspection, but could be a var is being mis-cast...in particular, Param cast as type Byte could have this effect.
Also, given that these are defined as functions, calling them as subroutines looks strange to me...
Agree with Pete that you'll need to engage in some more involved debugging to see more precisely where this overflow is occurring.
Regards
-
OK, Pete, I'll try zapping those pesky joystick sections from the FS9.cfg
Understand about letting FS9 rebuild it, but I have probably 3-4 man-weeks invested in tweaking the blasted config, and am less than cheerful about the idea of re-mapping the FS9 genome... :wink:
Cheerio
-
Pete;
I tried disabling the joystick and got an even worse storm of registry thrashing.
Understand that PFC does nothing with the joystick...but I did think it important for PFC users to know that if using a PFC flight control with no joystick attached to the PC (I mean with a PFC unit at one's disposal why *would* one want a joystick on the PC?), FS9 will still be busily looking for a joystick in the background even while it's getting control inputs from the PFC driver via FSUIPC. My rather inelegant solution is to plug in a cheap joystick as a sort of FS9 pacifier. If you give Bad Billy what he wants, he shuts right up. I didn't know if (but was hoping) you had some wizardly way to head off DirectInput at the pass...as you often do with these things.
Cheers
-
Pete;
Was watching FS with Mark Russovich's RegMon utility, and noticed a steady stream of unsuccessful hits for joystick settings on a registry key for DINPUT.DLL (see screenshot). Hit frequency was something like 30-50 times a second. I use a PFC yoke and throttle combo without a regular HID joystick connected to the PC.
After seeing this registry thrashing, I plugged in a USB joystick in addition to the PFC combo, and disabled all the axes of the USB joystick in FS9. The registry thrashing stopped, and frame rate excursions have smoothed out some.
Not sure there's anything that can be done in the PFC driver, but it's a curiosity worthy of a look.
Cheers
-
OK, well then I'd be looking hard at something like an IRQ or address conflict. Make sure the USB adapter isn't using the same I/O address as the onboard ports, or that there aren't two devices trying to be the same serial port. I've found that serial I/O does not always coexist peacefully with other devices doing interrupt-sharing, even though Windows PnP seems to think it should.
Have you tried other serial devices on the ports in question...like a modem, perhaps?
Cheers
-
I'd start first by reseating both ends of the cable, and if that doesn't work, then try a different serial cable.
If that doesn't do it, try monitoring the serial port with a simple terminal program.
Otherwise it's probably time to send 'er back to PFC.
I like your sound sets, BTW.
Cheers
-
Hi Pete;
The LDS team released an SDK with the 767 add-on which gives access to a variety of extern variables, including one with the A/T state (via an IPC DLL they provide for their panel). If you don't have it already, hopefully a member of their team will provide it to you shortly.
Cheers
-
I could envision a few uses for such a beast...
Cheers
-
Lots has been written in the F1 ATR forum on the interaction of FS throttle inputs and the auto-torque on the F1 ATR. For the F1 auto-torque to work, the throttle input needs to be at 0 (idle). Any throttle movement...even the fidgety back-forth drift caused by a noisy pot, will cause interference with the panel's auto-torque control. That, unfortunately, is a panel programming characteristic, not an FSUIPC problem.
I got around the prop beta (reverse) problem by assigning reverse to a separate lever on my PFC quadrant. Probably not an option on the CH unit.
Regards
-
Interesting...but what's it used for? Are you building a sim with real avioncs boxes? Sounds kinda expensive...
Cheers
-
The keplerian elements that describe the orbits of the 24 GPS birds are readily available in multiple venues on the internet. It's a relatively straightforward process to compute the azimuth and viewability of the sats for any given date/time (epoch). But...that said, it's a lot of computing power being devoted to a really esoteric piece of background data that one would almost never look at in real day-to-day ops.
Regards
Eaglesoft Citation X 2 with FSUIPC.
in FSUIPC Support Pete Dowson Modules
Posted
Hi Ed;
My suggestion is, in addition for testing for presence of a DirectInput throttle axis, to also test the single byte FSUIPC offset 0x3373 for a nonzero value, which indicates that a PFC control system is present and active. My understanding of your control methodology leads me to believe it will work unmodified with the PFC systems, as the PFC throttle control inputs will be present at offsets 3330 and 3332 no differently than a joystick axis, and right where you watch for them in your code now.
There is a fairly sizeable group of us that use these (pricey) high-end flight controls, so the small effort to include us in your coding considerations will result in enough sales to make it worth doing.
Regards
Bob Scott
Colonel, USAF (ret)
ATP IMEL Gulfstream II-III-IV-V
Colorado Springs, CO