Pete Dowson

You have Button AND Axis Event logging enabled? It certainly isn't assigned then. Show me the Buttons section of your FSUIPC INI file and the LOG. You can paste the relevant sections here, into a message. Maybe you are only logging normal events, not Axis events? These aren't normally logged because, with your aileron, elevator, rudder, throttle, changing so frequently, the log gets huge quickly. It's a separate option. Pete

That's okay. If they are not assigned they do nothing. In that case it must be getting assigned. If not in the PFC options, you must have, at some stage, assigned it in the FSUIPC options. (As with PFC buttons and switches, the axes can be assigned in FSUIPC). The PFC driver doesn't use keystrokes for anything. Keypads use INC and DEC controls, not proper analogue axis controls. Not the same thing. The logging in FSUIPC is wuite useful. Enable Event and Axis logging and it will log everything which is happening. If you cannot figure it out I'm sure the A2A folks will be able to. Regards Pete

Why are you moving a lever assigned to spoilers with a Piper Cub? Surely that doesn't have spoilers? Maybe the creators of the aircraft have used the spoiler axis for some other purpose? Why aren't you assigning a correct quadrant set for use with the cub, so that you have the throttle and mixture, and presumably nothing else on the quadrant? You do know you can do what you like with the quadrant, or even swap them for more realism with different aircraft? If you've assigned the lever to the spoiler axis, then my PFC driver would be writing the values directly to FSUIPC's offset 0BD0, which is the FS spoiler control.This will cause FSUIPC to send FS the "KEY_SPOILERS_SET" control with a parameter derived from the axis value and your calibration. If the value is within the "ARM" range it will send the "KEY_SPOILERS_ARM_SET" FS control. You can see this sort of information by enabling Event logging in FSUIPC. The logging might also then show any events that in turn triggers in the Piper Cub coding. For a Piper Cub? Huh? What are you trying to do, exactly? The throttle control in my PFC drivers is standard, and works for all known FS aircraft. It uses KEY_THROTTLEn_SET controls. It is sounding rather as if you have a 6 lever throttle quadrant and haven't set it up and calibrated it for a single engined basic prop aircraft. Try selecting the correct type in the driver, enabling and assigning it to the aircraft so that it will automatically be selected when you load that aircraft. If you haven't enabled it, it won't currently be auto-selected even though the PFC driver will be detecting the aircraft type. Regards Pete

Those are controls, not offsets. The maximum percentage of spoiler allowed for speed brake use in flight will vary somewhat from one aircraft to another, but around 60%-75% would be the sort of zone. The parameter can be computed as the correct percentage of 16383, the maximum. Right, so you know it then. 11451 is almost 70%, so I presume they meant it to be 70%. 11451, as you just said. Regards Pete

The FSUIPC documentation does tell you that you need the personal details to be the same, and SimMarket will deal with it if you ask them. As it is, now you've got this far, I think the quickest fix is probably to raise a Problem Ticket with them and explain the situation. Give them the FSUIPC details. They'll be able to replace the key for you. Get back to me if that doesn't work, but it usually does. Regards Pete

Okay. They operate the flags related to buttons 1,25 1,26 1,27 and 1,28 respectively. That doesn't matter. Each combination is doing a different thing, turning on and off a different flag. Sorry, I don't understand that question. Note that although you have 4 keypress assignments listed, operating buttons 1,25 to 28, you only use two in your button conditions: See? You are only currently using 25 and 26. When flag 1,25 is NOT set, lines 17, 19, and one of 20/21 are active, the latter depending on flag 1,26. When flag 1,25 is set, only lines 16 and 18 are active. If that is what you want, fine. It you who is programming your buttons. Regards Pete

Why do you think that only 20 and 21 should be active? If Flag 1,25 is set then 16 and 18 are active, if it is clear then 17 and 19 are active. That's how you've set the conditions as you can see: There are no other conditions preventing any of those! So what logic are you using to deduce your assertion? Pete

You can have up to 16 conditions, and whether any of the 16 refer to flags or button states isn't relevant -- thery each can be either. Those examples are fine. This is all explained more at length that I am doing here, in the Advanced User's guide. For example, here is an extract: I've emboldened the important parts relating to your question. I do notice though, where it says "None, either or both conditions.." it should really say "Any of the ...". I think the wording in that line dates from the time when the limit was 2 not 16. Regards Pete

If you are using another button you don't need to use its flag -- checking the button directly would work (i.e. no "F"). You solution only works because the button flags are toggled each time you press the button. What have you tried regarding keypress? My suggestion was to use a button flag which isn't associated with any real button -- i.e. one on a joystick number you don't have (in the range 0-15. There are FSUIPC controls you can assign to a keypress or a button to set, clear or toggle a flag. The parameter these controls take is 256 x joystick number + button number. For example, Joy 15 button 31 would be 256x15 + 31 = 3871 (or hex x0F1F). [LATER] Oh, I see my reply to clarify this crossed with your "Eureka" moment! ;-) Regards Pete

Yes, that's fine -- except for the inconsistency of using FS controls for strobe. I think you must have that Taxi light button assigned elsewhere as well, possibly in FSX itself? Probably to the all-lights toggle control. Assigning button and axes in FSUIPC doesn't stop FS assignments from also operating. I can't stop that. Are you not referring to the documentation? If not where did you get those you are using? Here's the relevant part of the Offsets table: 0D0C 2 Lights, a switch for each one (bits from lo to hi): 0 Navigation 1 Beacon 2 Landing 3 Taxi 4 Strobes 5 Instruments 6 Recognition 7 Wing 8 Logo 9 Cabin In hexadecimal notation bits are in groups of 4, with single bits shown as 1 2 4 and 8 respectively, from low bit number to high. So, strobe being bit 4 is x0010 (the first bit in the second group of 4). Easier, use decimal when entering the parameter in the FSUIPC Button Assignments dialogue (FSUIPC will convert to hex). For decimal bit equivalents it is simply 2 to the power of the bit number. So: bit 4 = 2 x 2 x 2 x 2 = 16. Regards Pete

It sounds like the calibration isn't right. Maybe you've not left enough room for one of the positions. Can you show me the [JoystickCalibrations] part(s) of your FSUIPC4.INI file, please? (It is in the FSX Modules folder). Pete

You only show the INI lines for switching on -- show me the whole set please. Which aircraft are you testing it with? Maybe it is a function of the panel you are using? Certainly FSUIPC4 internally interprets each bit separately. Incidentally, why are you using bits in 0D0C for most then an FS control for Strobe? There are FS controls for Landing lights on/off as well, but you've used the 0D0C bit for that. x0010 is the parameter for Strobe. Do you know you can use FSUIPC logging to help find out what is happening? On the logging tab, enable the Event log, which will show any resulting FS controls, and for the lights try using the right-hand side of that tab: Offset 0D0C, type U16, check "Normal log" below. If you run FSX in Windowed mode you can see the logging in real time by checking the Console Log option. Regards Pete

Does it see Caps Lock? Seems unlikely -- the problem with using caps lock is that you can't stop it changing the code the A-Z keys supply. Why are you avoiding using easy keys? Regards Pete

Sorry, no, not using built-in FSUIPC facilities. This is because the Control, Shift, Alt, Tab, Windows and Apps keys are all used as "shifts", to make available many keypress combinations available, especialy when you think those can be used in combinations too. When they are used as shifts the software has to wait to see what "main" key is pressed. In other words it sees the shifts and notes them, then the main key acts as the actual "press" and the combination is known. If these shift keys were also to be usable alone, there's would have to be a delay whilst waiting to see what other keys might be pressed. This would obviously make the whole thing impractical, especially when you consider they may be activated via hardware interpreting buttons -- keyboard emulators, used to build a lot of sims. In other words, allowing all the keys to be used individually stops them being used in combination, and that is unacceptable for those who build things using keyboard emulators rather than buttons. Regards Pete

Sorry, you confuse me. You were having problems, but not now? Or you still are? If they are resolved, what it is you want to know? What has the "numeral 4" got to do with anything? That seems to pop into your question without reason or reference that I can see. Registration is by the exact name, email (or address) and Key, exactly as notified to SimMarket and confirmed by them. Nothing different will work. Don't place any of these details here. If you definitely have a problem, tell me what it is first. Regards Pete

Well, it possible with any version of FSUIPC, but it involves a little thought, and different keys to Shift and Control. Buttons actions can have Conditions -- the technique for conditional or compound actions from button pressing is by editing rather odd-looking parameters in the INI file. The Advanced User's guide details this, with some examples. To get the conditions acting from a keypress, said keypress (not shift or control which are only programmable in conjunction with other keys) needs to be programmed to set or clear a Button flag. Such flags are then testable as conditions on Button parameters. The Button flag controls are assignable in the normal FSUIPC controls dropdowns. They need a parameter computed to say which button flag should be changed. The button concerned doesn't need to actually exist. So you could choose two other keys -- say the UP and DOWN arrow keys. Providing you aren't using them for other things in FS -- programming a keypress in FSUIPC removes its use from FS (unlike button and axis assignments). Regards Pete

I don't know either program, but Niko's pretty good at helping folks. Regards Pete

Yes, just follow the instructions for calibrating, step by step, in the user guide. You need to set the minimum throttle position in the calibration to some place a little away from the backstop of the throttle lever or rod so that you can be sure the resulting value reaches zero when you pull it back. For FS idle is always zero throttle. If your calibration produces an output value of 0 that's as good as it gets. Incidentally, 4.52 was superseded by 4.53 the week before last, and there is an update for that already in the Announcements above. Regards Pete

I won't, actually, as I can't get that far. The FSX version is fine, no problems with mouse macros. The Wilco 767 I appear to have installed in my FS9 test system is either corrupt or is incompatible with FS9 -- maybe it dates back to FS2000, as I have just found a Wilco 767 PIC original CD dated 2000! No, I just checked. Whilst the panel bitmaps are all dated 2000, the Gauges fitting to them are dated 2002, go I guess it was made for FS2002, not FS2000. Maybe it nearly worked in FS9, once. But I can't find the original to try a re-install, and even if I could the real FS9 version is probably substantially re-coded. I'm afraid without the actual aircraft to work on I'm not going to be able to do anything about this problem. Sorry. Regards Pete

Which version of FSUIPC? The latest version, 3.93, is supplied as an Installer in a ZIP file which includes a short document which does actually tell you, right near the start, what is installed, and where! The installer currently puts FSUIPC and all of its documentation into your FS2004's Modules folder (I like to keep everything together -- but after some feedback, because there's already such a lot of stuff in the FS2004 modules folder, I shall change that in the next version). All previous versions were supplied with everything in the ZIP file, and no installer -- you put them where you liked. So in that case it is up to you where they might be. Soit depends which version you are asking about. Regards Pete

No. The log isn't at all useful. Sorry. Look: Showing me buttons being pressed whilst you are programming them in the options dialogue cannot possibly show me why they may or may not do anything when actually applied in the program! You need the logging for the actions which are failing, not things which you already said were working! There's a lot there. Is it only the landing lights which don't work, or are all those assignments ineffective? The numbers in those macros look wrong. Far too big. Values like 0x7e61ac0 and 0xbf31b40 should not occur, as these are supposed to be offsets from the start of the Module (B767oh.GAU) to where its fixed, predefined, mouse action table entries are. The module cannot be as big as that, so something is going very wrong I think. Perhaps it somehow generates the tables on-the-fly (unlikely I think), or is compiled in some way which allows the data to be separated from the code. I don't have the LevelD 767 for FS9, only the old Wilco one which doesn't appear to have the same gauge names. I do have the FSX version installed, though I'm not sure whether I can get it working. It is only here for some test I did a while back. Do you know if there's much similarity? I wonder if it is worth my while looking at the FSX version. Even if I found out what was happening, it is likely that the only action i could do would be to take steps to detect the anomaly and prevent the "TAB test" working in the first place, so you aren't misled into thinking there's a solution when there isn't. I think you will probably need to look for more ordinary solutions -- I'm sure there must be others, as no one else seems to ask about this. I know Niko Kaan's interface is heavily used for LevelD aircraft, and I'm reasonably sure most things can be done without mouse macros. Have you looked? I've made a note to see if I can find out what is happening, via the FSX version. If I get anywhere I'll let you know. Regards Pete

I didn't think there was any need to use Mouse macros for the LevelD, what with their open use of FSUIPC offsets and Niko Kaan's nice interface program. Don't they also allow keypress assignments? Enable key/button logging in FSUIPC's logging page and operate the switches. Show me the FSUIPC log file (paste the text in a message here). Also show me the [buttons] section from the FSUIPC INI file relating to these macros, and the Macro file itself. It is all text so you can paste them into messages. Regards Pete

The treatment of each axis is independent and the code path exactly the same, so I really don't understand how it could be different. I've tested everythnig here, and fixed the original bug. Without knowing exactly what you did there I can't really comment further. The only one I found is the one now fixed if you download the update, which is there now. Regards Pete

Okay. I've tested it and fixed it this morning. My "tip" will work. If the axis is assigned as well as having range actions set for it, the data is saved correctly. But I owe you the beer, not vice versa, as it is a definite bug. I will provide the fix in versions 3.932 and 4.532, in the "Updates" announcement above very soon, within an hour. Thanks for the good feedback, & Best Regards Pete

Hmm. The Lua threads are still running when you are in the menu. The question becomes -- do the methods available to send keypresses from Lua to FS manage to get to the menu dialogues? It is actually quite possible, but it would need testing. Certainly, keypresses sent via WideFS from a Client PC work okay in Menus, but WideServer sends the keys directly. I'm not sure that's the case with Lua as it is at present. Could you first just try a short Lua program and see how you get on? Let me know. I would test it myself but I'm really tied up for a few days. If it doesn't work, maybe I can add some extra Lua library procedures to allow it to work just as WideServer's actions do. Regards Pete