macwino

Pete, thanks for pointing me in the direction of a solution. I had checked out this button previously, and it was shown to be working in the Windows controller settings dialog. I had forgotten, however that in order to get this button recognized in fsuipc, I had to disable a Saitek file in the Windows32 folder. What appears to have happened is that when I plugged the USB cable into the wrong port, Windows automatically reinstalled the drivers from its cache. This reinstall added the disabled file back into the system. I should have caught this when I went ahead and yet again reinstalled the drivers myself a few days later, but I'd simply forgotten that I needed to pull this file. I've now removed the problem file and my buttons all work within fsuipc as before. Thanks, Robert

Pete, as you requested, here is the button section from my test ini generated by default by fsuipc. The 3 lines that are remmed out - I think that’s the proper term - were entered first using the fsuipc Options interface. All worked just fine. I then modified the default ini by remming out the 3 default lines and adding the next four lines, which represent my usual coding for the first two of these buttons that I've been using for years. I got no response from these buttons with this coding. [buttons.C185F SKYWAGON TUNDRA N9916] //0=P1,6,K50,9 //1=P1,7,K51,9 //2=P2,0,K52,9 40=CP(+1,8)(-1,0)1,7,K50,9 ; RXP GNS WAAS(Shift+2) 41=CP(+1,8)(-1,0)1,6,K51,9 ; RXP GMAGTX (Shift+3) 42=CP(+1,8)(+1,0)1,6,K53,9 ; Control Window (Shift+5) 43=CP(+1,8)(+1,0)1,7,K52,9 ; Manual (Shift+4) I also thought I would include my JoyNames section from this test default ini, in case it's also relevant. It is identical to the one that is in my original customized ini that no longer works. [JoyNames] AutoAssignLetters=No 0=Saitek Pro Flight Rudder Pedals 0.GUID={B4F04430-91B4-11DF-8006-444553540000} 1=Saitek Pro Flight Yoke 1.GUID={B4F04430-91B4-11DF-8007-444553540000} 2=Saitek Pro Flight Quadrant 2.GUID={B4F04430-91B4-11DF-8008-444553540000} In addition, over the weekend I had rewritten my original post to clarify exactly what is going on and was going to post it this morning - my time - but you responded before I did so. It might clarify things so here it is anyway. It would have been re-titled “My manually-programmed buttons no longer work; but my axis assignments are fine.” Pete, this is a revised posting of an earlier post that I made while you were away. It fine tunes the problem and eliminates matter that might have confused the exact issue involved. However, should you want to look at my earlier post, it is here. Feel free to delete it to avoid any duplication. I manually program all of my controller button assignments in fsuipc. I do not use the fsuipc Options window for this purpose and instead manually enter the code in the fsuipc.ini. This is because my buttons are all coded using CP or CR type entries. Through a stupid error, I have lost the use of all these buttons. Strangely, however, my axis assignments and axis calibrations, which I did not manually code, but instead entered through the fsuipc Options window, are still working. My error was to unplug from my machine the USB Hub to which all of my controllers are attached, and then errantly plug the Hub back into a different USB port. When I discovered I was getting no controller button responses in FSX, I checked my connections and saw that I’d used the wrong USB port for the Hub. I switched back to the usual USB port but I still had no button responses. I then tried replacing my fsuipc.ini with a backup from a few days before. But this made no difference. Still no button responses. And, BTW, the backup and current ini files were identical in all respects except for the History line at the very top. Most importantly, the JoyNames entries and device assignments were identical. I then tried removing my fsuipc.ini and allowing the program to generate a new one. This default fsuipc.ini had the exact same JoyNames entries and device assignments as my backup and current ini files. I then used the fsuipc Options window to program a few buttons using the fsuipc GUI. These buttons worked. I then went back to the default fsuipc.ini, disabled these new button entries, and manually entered my coding for these buttons. But the manually-programmed buttons didn’t work. I then tried reinstalling the drivers for my controllers, but this didn’t solve the problem. I also re-installed fsuipc and the latest updates but it made no difference. So I find myself in a position where I can no longer use my custom fsuipc.ini with my manually-coded buttons, and I am also unable to manually re-code my controller buttons using a default fsuipc.ini. I am running Windows 7 Ultimate 64 and FSX Acceleration. I am using 3 devices: Saitek pedals, a Saitek yoke with an attached throttle quadrant, and a separate, additional Saitek throttle quadrant. The pedals work fine. The levers on both throttle quadrants also adhere to their fsuipc assignments. However, the buttons on the throttle quadrants (both the TQ associated with the yoke and the separate TQ) do not recognize the fsuipc assignments. Nor do any of the buttons on the yoke recognize the fsuipc assignments. My backup fsuipc.ini file and the one created after the USB input error both use the same device assignments. Thus, 0 is assigned to the pedals, 1 is assigned to the yoke and its associated TQ, and 2 is assigned to the separate TQ. I wasn't using the letter assignments recommended in the "Keeping track of multiple control devices" section of the User Guide. For what it’s worth, however, I did create a test ini using the letter assignments. This ini followed the same assignments as noted above. Of course, the pedals were now assigned A, the yoke and its associated TQ were assigned B, and the separate TQ was assigned C. This ini also didn’t allow me to manually code any button assignments. Your assistance will be greatly appreciated. I’d like to be able to again program my controller buttons using fsuipc. Thanks, Robert

Paul, thanks for the suggestions. Indeed, it looks like I'll have to wait for Peter's return. In the meantime, I did try creating a new fsuipc.ini and entering buttons using the fsuipc GUI. These entries work. But the relevant assignments and parts of the new fsuipc.ini are identical to the one that no longer works for me. And as far as doing a careful comparison of my full ini file - both before and after the USB input error, I did this to begin with using WinMerge and it finds the files identical. So there's not much more that I can do. Thanks again for your assistance and I look forward to seeing what Peter has to say. Robert

Paul, thanks so much for the detailed explanation about how to proceed. Before proceeding, however, let me provide some further details about the situation that suggest to me that something more may be involved that needs to be addressed. First, it is only my button assignments that are not being recognized by fsuipc. All my other fsuipc assignments are being properly recognized. This suggests to me that the current Windows device assignments may not necessarily be out of sync with what fsuipc was previously using before my USB input error. Specifically, I have 3 devices - Saitek pedals, a Saitek yoke with an attached throttle quadrant, and a separate, additional Saitek throttle quadrant. The pedals work fine. The levers on both throttle quadrants also adhere to their fsuipc assignments. However, the buttons on the throttle quadrants (both the TQ associated with the yoke and the separate TQ) do not recognize the fsuipc assignments. Nor do any of the buttons on the yoke recognize the fsuipc assignments. Second, my backup fsuipc.ini file and the one created after the USB input error are identical in every respect, except for the History line at the very top. In particular, the assignments shown for my 3 devices are the same in both. Thus, 0 is assigned to the pedals, 1 is assigned to the yoke and its associated TQ, and 2 is assigned to the separate TQ. Third, I created a test fsuipc.ini file assigning letters to the devices, and this ini follows the same assignments as noted above. Of course, the pedals are now assigned A, the yoke and its associated TQ are assigned B, and the separate TQ is assigned C. In sum, I see none of the device number assignment changes that you encountered. Also, my fsuipc assignments for the levers on my devices are being recognized correctly - it is just the button assignments that are not being recognized. Might something else be going on here that needs to be addressed? Thanks again for the input. Robert One further thought. All of my button entries in the fsuipc.ini file were entered manually. I never used the fsuipc Options dialog box for these entries.

My yoke, pedals and throttle quadrant are plugged into a USB hub which is then plugged into my machine. I had to unplug the hub from the machine and errantly plugged it back into a different USB input. As a result, I lost all of the connectivity between fsuipc and my controllers. In short, none of my fsuipc button settings work. I have read the "Keeping track of multiple control devices" section of the User Guide and am now aware that this can happen. I wasn't using the letter assignments recommended in that section. I have tried switching the USB cable back to the USB port that I used to use, but it doesn't correct the problem. I have compared my current fsuipc.ini file with the backup one that I was using before this unplugging, but they are identical. Is there any simple remedy for this situation? If not, what do I have to do to get all my settings working again? Will I have to modify each entry referring to a specific controller, and if so, how do I know what changes to make and to which entries. Virtually all of my ini entries were manually entered over the last 10 years and comprise many hundreds, if not thousands, of lines. Also, is there some system file that I can restore from one of my backups that would reinstate whatever it is that Windows altered when I errantly used the wrong USB input? Thanks, Robert

Terrific! I look forward to giving it a try when released. In the meantime, I've gone almost 24 hours now and neither the throttle or flaps problems have reappeared. But I still cringe every time I load a new flight after a fresh launch of FSX. It will be nice when I can get over that. Thanks, Robert

Pete, I'm happy to be a sounding board for this; I just didn't realize you were using me for this as I hardly feel competent for such an undertaking. Be that as it may, ping away. Your current proposal (the 0/Y/Z -> X/Y/Z -> 0/0/0 -> X/Y/Z system) seems just fine. Let me just clarify it with some real numbers to be sure we're on the same page. Assume 0/60/20 to start and your parameter is 60. Activating the toggle will change it to 60/60/20. Activating the toggle again will change it to 0/0/0. Activating the toggle again will change it to 60/60/20. And so forth. Is this correct? If so, the concept is fine. As far as Principle 3 is concerned, I based this on two factors. One is the egocentric one that I generally fly at 100 or 0. So for me 100 is the desirable parameter. But that doesn't explain why I said it should always be 100 even for those who choose to use a starting density lower than 100 other than 0 such as yourself. That conclusion results from some of my testing over the past 4 days that I unfortunately didn't document. This conclusion may have been reached before you made the v4.253 adjustment. Or it may have arisen from my also experimenting with some Traffic Density Set commands as well as the toggle and any resultant confusion that may have created. In any event, I had found that exercising the toggle was giving me proportional densities, not direct densities. In other words, if my density was set at 50 and I applied a toggle parameter of 100, I got 50. But if I applied a toggle parameter of 50 I got 25, or 50% of 50. I'm not able to repeat this now, however: 100 gives 100 and 50 gives 50. I was also getting a proportional reduction in Ship traffic density as well. A parameter of 75 would leave me with a density of 15 assuming a start point of 20; a parameter of 60 would give me 13, etc. In my testing now I found this to still be a little wacky. I tried a parameter of 60 when starting from 20 and wound up with 33, or 160% of 20. Again, I think I'm just probably making too many changes - perhaps without first clearing the fsuipc toggle memory or something like that - and that's why I'm getting these strange results. But here's a series of results that I just got with clean boots of FSX that may be of interest to you. In a sense it confirms the behavior I noted above that led to the proportional results I once obtained, and may explain why I reached the conclusion (only partially erroneous as you will see below) that the parameter was providing proportional and not direct results. I set the parameter to 60 in the ini. I then launched FSX and set the traffic for 100/100/20. I then loaded a flight and it displayed the traffic as I'd set it before loading, namely 100/100/20. I then ran the toggle. The traffic changed to 0/0/0. So far so good. Then I ran the toggle again. I got 60/60/12. In other words, the Ship traffic of 20 was reduced to 60% of 20, or to 12. Query whether the Airline and GA traffic are truly being set to 60 directly by the toggle, or are also being set to 60 indirectly as a percentage of the original traffic density of 100? To test this, I shut down FSX and re-launched it leaving the density parameter set at 60 as before. I then set the traffic levels at 50/50/20 and loaded a flight. I confirmed that the traffic levels had stuck and then I ran the toggle. I got 0/0/0 as I should. I then ran the toggle again. I got 60/60/24. So it looks like the Airline and GA traffic density is being directly and not proportionately set. (I think this is a fair conclusion, but I might be wrong. It's always possible, I suppose, that fsuipc is comparing 60 to 50, determining that 60 is 20% greater than 50, and entering 60 on the basis of the comparison and not directly. I don't know how to test this hypothesis, but you probably do.) But again the Ships traffic is obviously - at least to me - definitely being set proportionately by the toggle. It seems that the 20% increase in the Airline and GA traffic density mandated by the toggle parameter - although perhaps as a direct increase and not as a % increase - is being applied as a % increase to the Ships traffic, with 24 being 20% greater than 20. I ran this same test again starting at 40/40/20 with the parameter of 60. I wound up with toggle settings of 60/60/30. So the 50% increase mandated by the toggle was again translated into a 50% increase in the Ships traffic. I think that what this all means is that before running the toggle, you should be sure the density settings are where you want them to be and then the switch will toggle correctly between 0 and your designated parameter. Pete, I hope this is of some assistance and that I'm not too far off base. Robert

Pete, no need to program any special cases for me. The fix you added to v4.253 is more than adequate for my purposes. Now that I understand how the toggle is designed to work, I adhere to three principles that comport with the design of the toggle and I'm fully satisfied with its operation. Principle 1 is that it is okay for Ships to be reduced to 0 when Airline and GA are reduced to 0, and may indeed be desirable. This principle is premised on the framerate hit you called to my attention, and I can now accept the toggle reducing Ships to 0 when Airline and GA are being reduced to 0. Therefore, my apparently unique approach to the Ships slider is no longer an issue that need be accounted for. Principle 2 is that I should always insure that the density level of Airline, GA, and Ship traffic is greater than 0 before activating the toggle the first time during a flight, unless, of course, I desire that category to remain at 0. This is easily done, if necessary, or confirmed in the setup screen before any flight is launched. Principle 3 is that the parameter for the button should be 100, assuming that you want to maintain the starting density levels for the 3 sliders as one set of the toggle, the other set being 0. Again, by following these two principles, the toggle works like a charm. So no need to devote any further time on this - for me anyway. Thanks again for your efforts. Robert

Call it what you will - quagmire, nightmare, whatever. Two and a half days wasted. Ouch! Robert

Well, I've come up with what might be a solution. It came about when I decided to see if the flaps problem could be eliminated by resetting everything by just using FSX for the axis assignments without any involvement by fsuipc, and then reintroducing fsuipc back into the picture. This worked! I'll have to see how long it lasts and if it can be repeated if the problem arises again. Here's what I did: I eliminated my fsuipc settings from the picture entirely by removing its ini file. Then I launched FSX and assigned all my axes from within FSX. (I had previously been assigning them in fsuipc.) Then I loaded my test flight and the flaps didn't move on loading and were properly set in the Up position. So all was as it should be. I then went into fsuipc and calibrated the flaps axis as it definitely needed calibration. So did the Elevator Trim axis. And all was still working fine. I then exited FSX, relaunched FSX and loaded my test flight. The flaps didn't move on loading and were properly set in the Up position. So the setup survived a relaunch. Then I exited FSX. I swapped the pristine fsuipc.ini that I'd just created for a previously created pristine one with just my fsuipc axis assignments. I launched FSX and went to Controls and deleted all of the FSX axis assignments. Then I launched my test flight and the flaps didn't move on loading and were properly set in the Up position. Then I closed FSX, relaunched it, and loaded my test flight. The flaps didn't move on loading and were properly set in the Up position. So this setup survived a relaunch using a pristine fsuipc ini with axis assignments. Then I exited FSX. I swapped the pristine fsuipc.ini with the axis assignments for the one I'd been using when the flap problem first arose and that I thought was corrupted. Then I launched FSX and loaded my test flight. It loaded properly without any flap problem. I closed FSX and performed a relaunch and reload of the test flight and all still worked fine. So it's apparently fixed - at least for now. I'll have to see how it goes from here. Robert

Pete, what worked with the throttle didn't work with the flaps. In other words, when I had the throttle problem, a rebuilt pristine fsuipc.ini file resolved the problem. However, when I rebuilt the fsuipc.ini this morning by having fsuipc create a new ini file and then adding my axes and calibrating them, the flap problem still remained. So unfortunately I've got nothing to send you that would be meaningful in troubleshooting this problem. I'll keep experimenting and keep you posted. Thanks, Robert

OK, now I understand why you included Ships and not the others. I didn't appreciate the difference, but now it makes perfect sense to me. Sorry about my strange setup. My practice has been to set the 3 ancillary sliders - including Ships - at 20% and leave them there, and vary the Airline and GA traffic depending upon the plane I was using or whether I was in a rural or urban area, but always keeping the Airline and GA in synch. I didn't realize that when in a coastal region Ships might have a significant impact on my frames. Now I know and will act accordingly! Thanks for making this all so clear. Robert

Mtjoeng, I tried your suggestion of shutting down, removing the USB cables, booting up, and then re-inserting the USB cables and checking the calibration, which was fine. Then I installed one of my backed up fsuipc.ini files that had worked properly at one time and launched FSX. I checked to insure that all the FSX axis and joystick controls were deactivated. Then I launched a flight. Unfortunately, the flaps were still being lowered at startup. I also went through the same process again, but this time I tried copying my button and calibration settings into a pristine ini, but got the same result. So for me, anyway, there seems to be no point in making an ini backup every time any changes are made. The only solution seems to be a tedious rebuilding of the fsuipc.ini from scratch, one plane at a time. And so far I've been unable to accomplish this, as I eventually run into a problem before I'm even half done - first with the throttles, then with the flaps, and who knows what next. This is all very frustrating, to say the least. Thanks for the input. And I'm glad to see that the backup ini files are working for you. Robert

Pete, here's the clarification you asked for, and I apologize for not being more explicit the first time. The problem indeed only occurs upon the initial launch of a flight after a fresh launch of FSX. In other words, it occurs when you launch FSX, then load a saved flight (of course, with throttles at idle and flaps up) or a new flight created in the Free Flight window. And just to cover all bases, the axis levers are at the idle and flaps up positions. The problem does not occur if you change the aircraft once the initial flight is loaded, or if you quit the initial flight and load another flight that's either saved or created in the Free Flight window. So long as you do not relaunch FSX itself, the problem does not seem to recur on any subsequent flights. Again, the problem only happens with the first flight loaded after a fresh launch of FSX. I checked Device Manager and turned off the Power Management for all my USB Hubs. It had been activated for all. The problem still remains after making this change, but perhaps this kind of change will take time to have any impact in preventing this in the future. In the meantime, I still need to get things back on track by rebuilding my fsuipc.ini, which so far appears to be the only fix available, albeit a temporary one at that. I understand how the fsuipc.ini can theoretically have no bearing on this problem. But the fact remains that my experience has been that once the problem arises, using a pristine fsuipc.ini file and then building it up from scratch appears to be the only way to eliminate the problem - for several hours at least. Don't get me wrong. I'm not questioning your conclusion or judgment. I'm just reporting what my experience has been so far. I'll leave it to your expertise to try and explain my observations. As always, thanks for your willingness to look into this. I greatly appreciate it. Robert

Well, Pete, how well this works all depends where you start from. Let me explain. I installed v4.253. And I again started from my manual settings of Airline and GA at 0% and Ships at 20%. (I didn't note before - and this will become relevant later - that I have Road Vehicles and Leisure Boats also set for 20%.) When I activate the toggle key, I get the exact same series of results that I reported in my previous post. So v4.253 is no improvement. However, if I manually set the traffic to 100% for Airline and GA, and 20% for Ships, and then activate the key, I get what is apparently supposed to happen. Thus I get 0% for Airline and GA. I also get 0% for Ships. Then, if I activate the key again, I get 100% for Airline and GA, and 20% for Ships. And continued key activations will follow this pattern. So for the command to work properly, it seems that you have to start with a traffic setting of 100% for Airline and GA at least. I tried the process again starting with a manually set traffic density of 75% for Airline and GA, and it worked fine, reducing it to 0% and then increasing it to 75% - all the time, remember, that my fsuipc density parameter was set for 100. So it appears to me that what's going on is that a parameter of 100 means 100% of the then existing traffic density, which will toggle to 0%, and then back to 100% of whatever density level you started with. And so long as you don't start with a density level of 0%, all will work as intended. Now let me mention Road Vehicles, Ships, and Leisure Boats. I have all these sliders set manually for 20%. It is noteworthy, however, that only the Ships slider is affected by the traffic density toggle command. The other two categories remain at 20% throughout all my tests. My personal preference would be for none of these 3 ancillary sliders to be affected by the toggle. But that's neither here nor there. What's important, I think, for you as the programmer of all this, is that these 3 ancillary sliders should also probably move in unison with the toggle - or, as I would prefer, not move at all with the toggle. Just an observation for what it's worth. Thanks for all your assistance on this. This is a very workable solution and I appreciate your courtesy and responsiveness. Robert

This is a follow-up to an earlier post by John Veldthuis concerning this problem, for which no resolution was ever reported by John. See viewtopic.phpf=54&t=67491&p=418952&hilit=plane+moving#p418952. I have experienced a similar problem that has vexed me for several days now. I too am using a Saitek yoke and 2 throttle quadrants. I am running XP SP2, FSX SP1, and fsuipc 4.25. I have not loaded the Saitek drivers because I want fsuipc to see the Mode key on the yoke which I use for my button programming. I was setting up the yoke and TQs for my various planes and all seemed to be going well. Then, all of the sudden, any plane that I loaded was loaded with the throttle at a level above idle that caused it to accelerate down the runway. The TQ's throttle lever was in the idle position and there was a wide idle range in my calibration so there could be no confusion here. An infinitesimal nudge of the throttle lever would reset the RPMs to idle and the plane would eventually roll to a stop on its own or under my braking pressure. This happened with both single and dual throttle planes. I tried all of the fixes mentioned in John's thread: Redoing my default startup flight, redoing my calibrations, insuring there were no FSX conflicts, etc. I also performed a Registry tweak that was supposed to remedy any problems with the Saitek settings. Nothing worked. And remember, I had set up perhaps 5 or 6 planes in fsuipc before this problem suddenly arose. And the problem just didn't affect the plane that I was working on. It affected all planes that I'd previously configured with buttons, axes settings, config settings, etc. Now all of my planes would load with high RPMs such that they careened down the runway unless I was attentive enough to have my feet on the brakes and nudge the throttle a bit so as to reset it to idle. I finally decided to rebuild my fsuipc ini file from scratch, one plane at a time, and testing after each plane was added. This seemed to eliminate the problem. I thought that my fsuipc ini file might have become corrupted and that incremental rebuilding was solving the problem. I was simply re-entering the same settings as I'd used before, although the calibration settings might naturally be slightly different but not in a material sense. When I was done with about 6 or 7 planes, the problem re-appeared - but in a different context. Now it was that any plane I loaded was lowering its flaps to the first position. And, again, the TQ's flaps lever was in the full up position before loading the plane and a slight nudge on the flaps lever would cause the flaps to return to the Up position where they should have been on loading. This time, however, I had saved a copy of my fsuipc.ini file after configuring each plane. So I tried using these saved ini files to see if something I had done in a subsequent ini had caused the problem. But it made no difference. Even if I went back to the very first ini file I created - with my global settings - any plane loaded immediately lowered its flaps to the first position. The only way I could avoid this happening was to allow fsuipc to create a pristine ini and then start rebuilding the file again plane by plane. Obviously, this is not a viable long-term solution. While I can live with the flaps situation, if the throttle situation were to suddenly reappear - which is not unlikely - that would be a problem for I often am doing other things while a flight is loading and can easily miss the point where the plane has finished loading and the brakes need to be applied and the throttle lever nudged to prevent it from taking off down the runway. Any thoughts on what is happening here and how it can be remedied? Thanks, Robert

Pete, here are the results of the tests you asked me to run. The fsuipc log file is attached. I set the key command Control+1 for the Traffic Density Toggle. I set the parameter to 100. I manually set the traffic density in FSX to 0% for Airline and GA and to 20% for Ships. I then ran the key command. I wound up with Airline at 100, GA at 0, and Ships at 0. (On an earlier test for which I didn't create the log I got 20 for the Ships at this stage, not 0, although I've not been able to repeat this result.) I then ran the key command again and got all 3 at 0. I then ran the key command again and got Airline at 100, GA at 0, and Ships at 0. I then ran the key command again and got all at 0. I then ran the key command again and got Airline at 100, GA at 0, and Ships at 0. Let me know if you need any more information. I know these results are different than those I posted earlier. So there's no consistency to my past experience. I ran this series of tests several times, however, and all the results were consistent with what's set forth above, except for the Ship traffic anomaly that I've noted in the parens and for which I don't have a log file. Thanks, Robert FSUIPC4 log.zip

Pete, I just ran a few tests with the Traffic Density Toggle set to a parameter of 100. It doesn't work as intended. First, I manually set my airline and GA traffic to 0%. I then ran the toggle and it reset my airline and GA traffic to 100%. So far so good. I then ran the toggle again and my airline and GA traffic stayed at 100% instead of returning to 0%. I also noticed that my Ship traffic was at 0% and I always keep it at 20%. I reset the Ship traffic to 20% and ran the toggle again. Again, the airline and GA traffic stayed at 100% when they should have changed to 0%. Interestingly, my Ship traffic was boosted to 100%. So it seems that the multiple sliders in the FSX Traffic window are interfering with the intended operation of this control. I'll just have to make do with the Set controls which work somewhat better, although they also adjust the Ship and ferries traffic at the same time as the airline and GA traffic. So there's some confusion with the numerous new sliders in FSX even with the Set controls. Thanks for your assistance. Robert

John, thanks for the input. I see what you mean. I've just been very careful, and haven't experienced the problem you mention. But I've just been testing, not really flying and it may well become a problem when reducing to zero thrust when under the pressure of a difficult landing. Pete's tip about how to eliminate reverse thrust from the axis works just fine, and combined with your proposed use of this axis button, will definitely be worth implementing if I find I'm errantly pulling the throttle lever past the detent. Have you found any uses for the other axis buttons? Thanks, Robert

Pete, now that I have a clearer understanding of how this command is supposed to work, let me play with it awhile and see if my problems are resolved. If not, I'll send you the anomalies I'm experiencing. No reason to bother you with this now until I do further testing. Thanks again for the assistance. Robert

Pete, thanks for the prompt reply and the tip about axis programming. I'm sure one of these days it will come in handy. Now it will be interesting to see if any users of the Saitek TQ chime in with some creative uses for these buttons. Robert

I have been manually programming 2 Saitek throttle quadrants with fsuipc. I've read all the posts here concerning this piece of hardware, and I'm a bit confused about the utility - if any - of the buttons that are triggered when you pull an axis lever all the way back past the detent. While this function might be helpful when using the Saitek programming software - which I've not looked at - I don't understand why I would want to use these buttons when programming the TQ with fsuipc. Yet I see that some people on this forum are doing just this, although the complexities of their posts are beyond my programming skill level. Am I missing something? Please bear in mind that this is my first attempt at using a TQ and programming it with fsuipc. Let me explain my thoughts a bit further. With fsuipc, I think I am able to calibrate an axis to do what I would want it to do without making use of this button feature. Let's take the throttle axis as an example. With fsuipc I can calibrate the axis so that reverse thrust is activated once the lever is pulled past the detent. And if I calibrate a wide idle area just above the detent, I can easily disable reverse thrust by pushing the lever forward just past the detent. So why would I want - as some people seem to be doing - to program a button below the detent that uses the throttle lever to activate reverse thrust when triggered and deactivates it when released? It just seems to make no practical sense to me. In addition, if there were some benefit to setting up this button, I've not yet figured out how to eliminate or override the fsuipc calibration that almost seems to require that there be an axis area devoted to reverse thrust if available on the plane, although perhaps this can be accomplished by reducing the span of the reverse thrust area to 0. I have found a similar experience with the other 5 levers on the TQs. I just can't see a use for these buttons when using fsuipc. If anyone has some thoughts on how these buttons might be used, I'd appreciate their insight. I'm a novice at this. And buttons are so precious, I hate to see any go unused. Thanks, Robert

I've read all the manuals and posts and experimented for several days now with the Traffic Density Toggle command (C1009), but I can't seem to get it to work as I think it should. When I'm expecting 100% traffic, I sometimes get 50%. And I sometimes only get a change in the airline traffic but no change in the general aviation traffic even though I always keep the two of them in synch. I am manually programming this command because I want to have multiple uses for the assigned button. Again, the button works; I'm just not getting the response I'm desiring or expecting. I may be desiring or expecting too much. But let's see. In its simplest form, I would like this command to change both my airline and GA traffic density to 100% if they're presently at 0%, and to 0% if they're presently at 100%. I can easily accomplish this using the Traffic Density Set (C1008) command and assigning it to two buttons, one set at 0% and the other set at 100%. But I'd like to use just one button and I thought that the C1009 toggle command could accomplish this objective. Perhaps I was incorrect. The syntax I am using is "C1009,x", where I've tried both "0" and "100" for the "x" parameter. I have assumed that if "0" were the parameter, then it would toggle between "0" and "100", and that if "100" were the parameter it would similarly toggle between these two settings. I have tried both these settings, and sometimes nothing happens, sometimes it works, sometimes only the airline traffic density changes, sometimes I wind up with 50% traffic density for both airline and GA. So what am I doing wrong? Also, it is not clear to me how the toggle ought to work if the present traffic setting was, for example, 50%, and I pressed the toggle button which had been programmed to toggle between "0" and "100". Should nothing happen, or should the traffic density change to "0" or "100", and if so which one and why? Also, if I wanted to have a button that toggled, for example, between "0" and "25", would "C1009,25" do it, or would this syntax wind up toggling between "25" and "100"? I'm running XP SP2, FSX SP1, and FSUIPC v4.25. I am not a programmer, so please excuse any inappropriate terminology that I may have used in describing this problem or what I am doing. Thanks, Robert

Hi Peter, I'm getting confused again, but here's where I think we are. I understand that AutoSave is working exactly as it was designed insofar as the save function is concerned. But that is not the problem. The problem is that installation of AutoSave in its default configuration appears to have reconfigured my FS 2004 Reset Flight command so that it reloads the current flight at its then current point, and not at the flight's start on the runway or parking spot. If I remove AutoSave, the Reset Flight command works as intended by Microsoft. So, is AutoSave in its default configuration intended to alter the functioning of the Reset Flight command? If so, all is normal. If not, then something's causing it to do so on my setup. You seem to indicate that AutoSave ought not to be altering the default parameters set by Microsoft for the Reset Flight command. This suggests that I've got some addon or setting that is causing AutoSave to act in this unintended manner. If that's the case, then I'll just have to decide to live with the situation (which I will do) or reinstall fs9 and do an addon by addon and setting by setting test to determine what's the problem (which I will not do). Thanks, Robert

Peter, attached is a copy of the saved flight file that was the last one created before I executed a Reset Flight command. I trust this is what you wanted to look at. Also enclosed as part of the Zip attachment is the AutoSave.cfg file reflecting this saved flight. Thanks, Robert Files.zip