Masterius

I'm running registered copy of FSUIPC4, v4975a, along with LINDA, v3.1.1.854. I usually have no difficulty programming buttons, keys, axis, etc, either through FSUIPC, LINDA, or lua scripts. But I'm encountering a problem with button programming using conditional flags for the Saitek Pro Flight Yoke mode switch. The mode switch is seen and recognized both by FSUIPC (as axis A, buttons 8, 9, and 10) and by LINDA (where I can set UNSHIFTED, SHIFTED ONE and SHIFTED TWO). Here is the relevant section of fsuipc4.ini: [Buttons.B-17] 0=RA,32,C65734,0 -{PAN_UP}- 1=RA,34,C65672,0 -{PAN_RIGHT}- 2=RA,36,C65735,0 -{PAN_DOWN}- 3=RA,38,C65671,0 -{PAN_LEFT}- 4=PA,10,C1003,10 -{BUTTON FLAG Set: Joy A Button 10}- 5=UA,10,C1004,10 -{BUTTON FLAG Clear: Joy A Button 10}- 6=PA,9,C1003,9 -{BUTTON FLAG Set: Joy A Button 9}- 7=UA,9,C1004,9 -{BUTTON FLAG Clear: Joy A Button 9}- 8=PA,8,C1003,8 -{BUTTON FLAG Set: Joy A Button 8}- 9=UA,8,C1004,8 -{BUTTON FLAG Clear: Joy A Button 8}- 10=CP(F+A,9)PA,1,C66507,101 ;//OpenPanel101-DBG 11=CP(F+A,9)PA,1,C66507,1064 ;//OpenPanel1064-Norden 12=CP(F+A,10)PA,1,C66508,101 ;//ClosePanel101-DBG 13=CP(F+A,10)PA,1,C66508,1064 ;//ClosePanel1064-Norden The intention is that when the mode switch is set to "MODE 2" and yoke button 1 is pressed, then panels #101 and 1064 open, and when the mode switch is set to "MODE 3" and yoke button 1 is pressed, then the panels will close. Unfortunately, that's not what happens...which is nothing at all. Any help will be appreciated!

Thanks for the quick response, John! I do use the 'Joyletters', and have since almost Day 1. I think I understand things correctly, so here goes: Controller 1 is a Saitek Flight Yoke, and has assigned to it Letter "A". The ailerons and elevators for that are associated with "A". Controller 2 is a Saitek X52 H.O.T.A.S., whose stick is assigned as 'B'. The ailerons and elevators for that are associated with "B". So although the .ini file might show multiple iterations of "aileron", "elevator", "throttle", etc, each of those iterations will be associated with their respective controllers. The same would occur for button and key assignments as well. Correct? ~Masterius

While I have found variations to this question, I haven't seen anything specific regarding my query . . . so . . . here goes: At the moment I am using FSX:SE with FSUIPC4 and LINDA. My equipment is: (All Saitek) Flight Yoke System (with one throttle quadrant), two additional throttle quadrants, pro flight rudder pedals, switch panel, and radio panel. I would like to, at times, remove the yoke and three throttle quadrants and replace them with the Saitek X52 H.O.T.A.S. Is there a way of doing this without losing key/button/axis/calibrations? I realize that those assignments will not directly carry over from one to another. I just don't want to lose all the programming and calibrations and have to redo those each and every time I swap out controller groups. I guess I have several questions, actually. One is how do I (assuming it is possible; I do seem to recall reading something about having multiple .ini files and/or profiles that allow for discrete controller selections) define one controller group (flight yoke, and three throttle quadrants) independent of the second (H.O.T.A.S)? The other is how do I (again, assuming it is possible) prevent the assignments from getting lost or reset? And lastly, what is necessary to avoid, and to prevent, controller assignments from getting scrambled between disconnection/re-connection? I use the joystick lettering, as advised, but even so, when I'd added the third throttle quadrant several months ago, both FSUIPC4 and LINDA recognized the older, second quadrant as the third, and the newer, third quadrant as the second. I'd rather not go through that again. 😩 Any advice, help and/or suggestions will be greatly appreciated! ~Masterius

I didn't think it had. Negative to both. I'll try and record that. I also use LINDA, which permits real-time observation of button executions. I could see the button operating, see the execution of the script, but not see the Lvar change. However, when I manually switched the magnetos in-game, I could see the Lvar values change. Al

I'm running FSX Steam Edition on Windows 7 using FSUIPC4, Version 4.974 and LINDA Version 3.0.12.810, and have been for some time now. Never really had any problems before, except for a little glitch with LINDA at setup over my throttle quadrants. I've been writing my own lua scripts, and they've been running just fine up until the middle of last week. Now, however, if a newly-created function attempts to write to, or read from, a Lvars, nothing happens. I can see the function called, I can trace the button as it is activated and deactivated, but the LVar value itself does not change. As well, if I remove a function that has been working, make and save any changes to the user.lib, and then paste that function back inside, it no longer works. For example, this function had been working, until I removed it for a revised version. When the revised version didn't work, I deleted it and pasted the original back, but now that one no longer works, either. The function actually runs, because it takes 6 seconds to complete and permit subsequent functions to execute. function All_Magnetos_Off_a () ipc.writeLvar("L:Magnetos1Switch",0) ipc.sleep(1500) ipc.writeLvar("L:Magnetos2Switch",0) ipc.sleep(1500) ipc.writeLvar("L:Magnetos3Switch", 0) ipc.sleep(1500) ipc.writeLvar("L:Magnetos4Switch",0) ipc.sleep(1500) end I've no idea what's up, but it's intensely frustrating.

Perhaps I did not explain better. What I meant was, how do I have certain controls, like mixtures, turbo, fuel pump, etc, start at pre-defined positions? For example, start off with turbo at zero, mixture levers at idle cutoff (zero). Basically, have an .ini file to preset offsets and Lvars.

Thank you both for your replies. I've spread the axis across the board, giving space between them (ex. using 66C1, 66C4, 66C7, etc) and that seems to have fixed the overlapping writes. Now I just need to figure out how to start the offsets at certain values (for instance, mixture at idle cutoff, turbo at zero . . . that sort of thing). Thanks again! Al

Up until this week I've had no difficulties using the offsets 66C0 thru 66FF (although I've only used about 10 so far). However, now it seems I can no longer write values to the unused ones, and in tracking down possible reasons I've also noticed the unused offsets holding values, and also responding to other assigned axis. For instance, I have one axis assigned to 0x66C1, but 0x66C2 also responds, but not not identically: the axis outputs the value of -16383 to 16383 to 0x66C1, but -293 to 63 to 0x66C I'm running both LINDA 3.0.12 and FSUIPC4 4.974 on Windows 7.

I've used "List Local Panel Vars" quite a bit, but didn't think to try Event Logging. It looks as if it might be [VOR1_OBI]. Going to experiment with that now. Update: VOR1_OBI worked!

That is the instrument in question, and the knob that adjusts the heading. Tried them ; didn't work. Or, at least, didn't work how I tried using them (as macros). I really do try and make use of the 14 or so documents that you've provided. It's rather rude and disrespectful to you if I don't take advantage of the large amount of documentation and instructions you've provided. Thanks again for such a rapid, and insightful, reply. I'll keep on working at this. ~Al

I have registered FSUIPC, using FSX-SE, and the add-on aircraft Accu-Sim B-17G Flying Fortress. This seems so simple, yet I'm pulling my hair out at this point. I want to adjust the flux compass (AP) heading using two buttons (one INC, one DEC). I've found numerous references to [HEADING BUG INC 65879] and [HEADING BUG DEC 65880], which do work to change the C-1 autopilot heading, but do not adjust the compass itself. I've also found references to "AP Heading, 07CC 2 Autopilot heading value, as degrees*65536/360", but I haven't been able to get that to work with two buttons. I'm probably stumbling right past the answer, but, for now, any help will be appreciated. ~Al

Thank you for responding so quickly! I was worried more about that being a potential resource hog than I was it "flooding" the event log. (Hey! That rhymed! 😁) Even so, it's nice to be shown a method to block that from being logged. Thanks again!

I was trying to determine codes for selecting radio channels (ex. toggling between NAV1 and NAV2) so I decided to use event logging. Here is just an example of what is being logged: 76921269 *** EVENT: Cntrl= 66508 (0x000103cc), Param= 102 (0x00000066) PANEL_ID_CLOSE 76921269 *** EVENT: Cntrl= 66507 (0x000103cb), Param= 100 (0x00000064) PANEL_ID_OPEN 76921332 *** EVENT: Cntrl= 66508 (0x000103cc), Param= 102 (0x00000066) PANEL_ID_CLOSE 76921332 *** EVENT: Cntrl= 66507 (0x000103cb), Param= 100 (0x00000064) PANEL_ID_OPEN 76921394 *** EVENT: Cntrl= 66508 (0x000103cc), Param= 102 (0x00000066) PANEL_ID_CLOSE 76921394 *** EVENT: Cntrl= 66507 (0x000103cb), Param= 100 (0x00000064) PANEL_ID_OPEN 76921457 *** EVENT: Cntrl= 66508 (0x000103cc), Param= 102 (0x00000066) PANEL_ID_CLOSE 76921457 *** EVENT: Cntrl= 66507 (0x000103cb), Param= 100 (0x00000064) PANEL_ID_OPEN 76921457 *** EVENT: Cntrl= 66508 (0x000103cc), Param= 102 (0x00000066) PANEL_ID_CLOSE 76921457 *** EVENT: Cntrl= 66507 (0x000103cb), Param= 100 (0x00000064) PANEL_ID_OPEN 76921519 *** EVENT: Cntrl= 66508 (0x000103cc), Param= 102 (0x00000066) PANEL_ID_CLOSE 76921519 *** EVENT: Cntrl= 66507 (0x000103cb), Param= 100 (0x00000064) PANEL_ID_OPEN 76921566 *** EVENT: Cntrl= 66508 (0x000103cc), Param= 102 (0x00000066) PANEL_ID_CLOSE 76921566 *** EVENT: Cntrl= 66507 (0x000103cb), Param= 100 (0x00000064) PANEL_ID_OPEN This goes on non-stop, and I've no idea what's driving it. I have registered FSUIPC, using FSX-SE, and the add-on aircraft Accu-Sim B-17G Flying Fortress, with quite a few macros and several LUAs, but I can't see anything out of the ordinary, or looking suspicious. I've tried several other, standard aircraft, and it doesn't seem to happen with them. ~Masterius