Pete Dowson

All FSUIPC's AutoSave does is call the SimConnect function to save a flight. This normally is a neglibible function -- unnoticeable (unless you'd stopped disk caching on the save drive, or the memory in your PC is pretty full). However, when the PMDG NGX sees a save it stops everything while it gathers all of its massive amount of data for saving too. Whether that exercise will ever be smooth enough I really have no idea. Fast PCs, plenty of memory, defragmented drives, and write caching enabled will all help. Regards Pete

L:Vars aren't used for everything. In this case, since those controls are the standard FS contorls, not sepcific to the aircraft add-on, the normal FS current altitude is the value you need, read from FSUIPC offsets: The altitude hold holds at the altitude set on the altimeter, which is not necessarily the true AGL, depending on your pressure setting. So the value needed is the altimeter read-out, which is at offset 3324 -- in feet normally, but meters if you've selected that. Assuming you use feet all the time, i = ipc.readSD(0x3324) Regards Pete

You don't really need a macro for that. Just assign both functionds to the button. You have to do this by editing the INI file, but that way you can have almost as many things assigned to the same button as you like. They are executed in order of the line numbers in the [buttons] section (i.e. the number before the '='). The format is documented in the Advanced User's guide. Regards Pete

You'd need a small Lua plug-in instead of a macro. Just use ipc.control twice with an ipc.sleep between. Regards Pete

But it MUST be unique for each device! Often it is the ONLY unique thing! There's no other way to distinguish identical devices. I don't know how to STOP it doing so! Sorry. Oh, you mean you only plug one in at a time? That explains it. They are all identical so Windows assumes it's always the same device! There's no way that is ever going to work and Leo can advise how to make the USB identity different for each one. Well the load on the PC is negligible. But you need a bigger desk (for Bodnar boards? They're so tiny! <G>). Maybe longer USB cables and keep them underneath or in a drawer? Regards Pete

You most certainly either have double assignments to some levers (i.e. assigned in FSUIPC and also in FS), or your hardware is broken. To deal with the former, go to FS's control assignments and disable all controllers. To deal with bad hardware (and there seems to be a lot about) you need to go to Saitek. Send to FS is FAR more likely to work than Send Direct. If Send to FS, assigning to the controls called "Axis throttle ..." etc (axis as first word) does not work then you most certainly have a corrupted FS installation, because that is the same as assigning in FS. No difference at all. I recommend you delete the FSUIPC4.INI file from the FSX Modules folder so that all your messing about is removed, then assign things in FSX first and get things working there. You still have not yet explained why you are assigning in FSUIPC in any case. Maybe you don't need to. When you explain that maybe we can proceed further. But get things working normally first, else there is no point in continuing. Regards Pete

Thank you Pete

I moved your post because you put it in the FAQ subforum where it won't get answered. Really? How do you work that out? I think they care very much about clients. Otherwise they could not exist! Why can't you change buttons programming? Everyone else seems to manage well enough. Maybe you cannot understand the documentation? Please see the User Contributions subforum where you will find lots of help and examples, especially for the PMDG 737NGX. And SimFlight don't provide information about FSUIPC, I do, here and in the documentation installed. You can always install FSUIPC before paying for it, and read its documentation and browse all the stuff in this Forum before deciding. It is no excuse paying for it and then saying you didn't know what it would do for you! BTW I am on holiday soon, back on May 15th, so please forgive any delays from now on. Regards Pete

The non-appearance of the dialogue window can only be a video driver problem, but I've never ever had any report of it not appearing in Windowed mode. That makes no sense at all, because it is a standard Windows dialogue. Are you sure it isn't getting hidden behind the FS window? I don't know how it could because it will have the keyboard focus -- it is a modal dialogue, which means everything else stops. How are you continuing, pressing ESCape? It has nothing whatsoever to do with any FS modes or screens. The options dialogue is just a standard straight-forward Windows dialogue. It isn't FSUIPC or FS code, it is Windows code. Now THAT confuses me. What "commands" are you entering and where? It sounds like you are talking about something different. The FSUIPC options dialogue has tabs, selections, and drop-down lists. No "commands" as such. See the pictures of it in the User Guide. BTW soon I am departing on holiday, not back here till May 15th. Regards Pete

Try that registry trick I gave above. That was from a Saitek support guy. Pete

Changing the simulator executable name can have all sorts of side effects. What add-ons are you trying which need such a step? FSUIPC has always handled renamed FS main executables. Even back in FS9 days folks used to have different names for FS9.EXE so that it would load a different CFG file for different scenarios. (This was before they realised they could do the same with the "/config:" command line parameter). In order to cope with this, FSUIPC too uses renamed files. You may not have noticed -- look in your P3D modules folder and you will find that it is using FSUIPC4.FSX.INI for its settings and FSUIPC4.FSX.log for its logging. It will be looking for an FSUIPC4.FSX.Key file for its registrations. Copy your key file and rename it so. Regards Pete

As far as I know there is no axis change before that 'notch'. I thought all pulling back further did was press the button. So if that is the case it sounds like either you've programmed at button for throttle decrements, or it has automatically been assigned that way -- maybe via Saitek's own software? Sorry, but I think from now you are dealing with Saitek-specific matters with which I cannot help. Yes, but the reinstalling of something -- Windows? Saitek? Has certainly intriduced it. I'm sure there's a registry change you can make to fix it. There may be a thread somewhere in this Forum which mentins it, but otherwise you certainly need Saitek support or Forum. Aha, so you are trying to use Saitek software for assigning and controlling things AND FSUIPC too? There may be some conflict from using both. I'm afraid I've run out of ideas now. Everything I've told you is correct as far as FSUIPC is concerned. I wouldn't touch Saitek hardware at all, I have a very low opinion of Saitek I'm afraid. But I think you need to get things sorted out first. If the throttles don't work in FSX without FSUIPC there's no chance of them working with it either. It isn't a fix for bad hardware or drivers. [LATER] I searched this Forum on the word "registry" and soon came up with this from one "jase439": Thank you for the tip! I just needed to add "registry fix" to my search and I dropped right in on the solution. I applied the registry "tweak" and it worked like a champ. Also got rid of alot of spurious noise I was getting in the neutral positions on the yoke! In case you aren't allowed in that part of the Saitek forum either, I reproduce the critical part: Try this recalibration fix I think that'll be HKEY_CURRENT_USER on Win7 too, but check both. Regards Pete

Better for what? What does "most reward position" mean? By sending me a PDF I cannot quote parts of your text, but if there are no intermediate values between minimum and maximum then that usually means the levers are set, in Windows, to behave as on/off switches not smooth analogue axes. I seem to remember that this is a bug in the Saitek installers or similar and is fixed by a Registry patch. If this is the problem you had originally, before trying FSUIPC, then I can understand your frustration -- which should actually be vented at Saitek. Check their forum anyway. I'm sure this is a subject which crops up regularly. Incidentally, also in your "pdf" you say you are now "dealing with PMDG". If you mean the NGX, then I notice you've not set the "No reverse zone" option, and you are still assigning "direct", which won't work correctly with the NGX. I told you the three things you'd need to change for that. You say "reverser seems to be working"! On an axis? Different axes? Pete

Use FSRealTime for that. Regards Pete

The points I made in my last reply apply. As far as I know, the first two points (1 and 2) are needed for the NGX in any case. The last, for using the button for reverse, can of course apply to all aircraft -- but then so can the other two. by all means, program it now, for all aircraft, as if you were doing it for the NGX. See if that meets your needs. I can't really make these choices for you, espcially since i don't have the same equipment or add-on aircraft. FSUIPC is a box of tools, a "Swiss Army Knife" application. You use the parts you want in the way you want to use them. Regards Pete

Ah. The PMDG 737NGX is one of those which doesn't like the sort of throttle assignment you are making. For the NGX it appears you need to: 1. Assign to FS controls, not direct to FSUIPC calibration. 2. Either do not calibrate throttles in FSUIPC , or set "UseAxscontrolsForNRZ=Yes" in the INI (i.e. change the "no" to a "Yes"). 3. If calibrating, calibrate with the NRZ (no reverse zone) option set. You'll need to use some other method for reverse as the NGX does not support reverse on any axis at all. I think most Saitek users program the button on the levers (when you pull right back) to operate the "throttle1_decr" or "throttle2_decr" controls repeatedly when 'pressed', and the "thtottle1_Set" (or '2') with a parameter of zero when released. There are some better solutions, but since I am neither a Saitek nor PMDG user I can't really advise further. There have been plenty of threads here with working solutions. Do a search on "NGX", maybe? Pete

Okay. The relevant parts are just these: Your rudder pedals are joystick #0, but you have device 0 axes assigned to 0=0X,256,D,0,1,0,0 ailerons 1=0Y,256,D,2,0,0,0 elevator 2=0Z,256,D,22,0,0,0 spoilers 3=0U,256,D,0,9,0,0 throttle1 4=0V,256,D,0,0,10,0 throttle2 and your joystick #1, the yoke has: 5=1X,256,D,7,0,0,0 left brake 6=1Y,256,D,8,0,0,0 right brake 7=1R,256,D,3,0,0,0 rudder So, it seems you swapped sockets for the two devices, or at least done something which made Wndows identify them differently. To prevent this happening again you would be best using letters for the joystick IDs. FSUIPC then uses those strange "GUID" values, which are unique to each device, to track such changes. There is a chapter in the User Guide about this -- managing multiple devices. But for now I can fix it manually for you. I'll select "P" for pedals and "Y" for Yoke. Okay? Replace these sections: [JoyNames] AutoAssignLetters=No 1=Saitek Pro Flight Rudder Pedals 1.GUID={CFEBAD70-87F2-11E1-8001-444553540000} 0=Saitek Pro Flight Yoke 0.GUID={B0246CE0-87F5-11E1-8002-444553540000} P=Saitek Pro Flight Rudder Pedals P.GUID={CFEBAD70-87F2-11E1-8001-444553540000} Y=Saitek Pro Flight Yoke Y.GUID={B0246CE0-87F5-11E1-8002-444553540000} [Axes] 0=YX,256,D,0,1,0,0 1=YY,256,D,2,0,0,0 2=YZ,256,D,22,0,0,0 3=YU,256,D,0,9,0,0 4=YV,256,D,0,0,10,0 5=PX,256,D,7,0,0,0 6=PY,256,D,8,0,0,0 7=PR,256,D,3,0,0,0 That's the main part sorted. Looking at your Calibrations: Aileron=-16380,-898,2853,16380 That looks reasonable, except that the 16380 values for min and max are the defaults, so you've not really followed the steps and allowed a little leeway.. Elevator=16255,16255,16255,16380 That's totally up the creek. You need to calibrate the elevator properly. The values for minimum, and centre are all the same and so close to the maximum that you have no range or control at all. Rudder=-16319,0,0,16128 That's okay, but i'd recommend a proper null zone around the centre to prevent unwanted rudder movement just because you rest your feet on them or the spring doesn't centre them correctly. LeftBrake=-16384,16383/16 RightBrake=-16384,16383/16 They're okay except you need to allow some leeway -- i.e. you want the brakes to be definitely off with your feet off or only resting, so you need an null zone. The calibration steps in the User Guide advise you exactly how to do all this. Throttle1=-16384,16383,16383,16383 Throttle2=0,16383,16383,16383 Those are very odd. You haven't selected the "No reverse zone" option (NRZ) for throttles, so I assume you want a reverse zone? But Throttle 1 seems to only have a reverse zone and no forward space because the idle area is set to be the same as the maximum. Throttle2 has been calibrated incorrectly too, even more odd. It is only using half of the levers range and again only for reverse for the same reason. Spoilers=-16380,16380/16 Okay, but no leeway for any variation in the lever input values. Those numbers are the defaults, in fact, so you've not actually followed the steps. Please, after correcting the assignments as I suggested above, go through each axis and follow the numbered steps in the Calibration chapter of the User Guide. Proper calibration is essential to happy flying. If oyu don't calibrate correctly there really is no point in using FSUIPC for your controls. I don't know what your original problems were, but the main problems you presumably came here about were all because of the swapping of the two devices. Using letters will prevent that happening again If you add any more controls, assign them a letter too. Once you've calibrated correctly you'll be okay. but note that some add-on aircraft won't like the way you've assigned ad calibrated your controls. You'll then probably need to start using Profiles so you can have specific differences for those aircraft. Regards Pete

Glad you got it resolved! Pete

Battlefield? Sorry, I don't understand where you are coming from. I AM trying to help. It seems you had problems with your controls and were seeking to fix them with FSUIPC. It seems you rather rushed into it, followed all sorts of potentially conflicting, or at least rather advanced, advice, got into deep waters, and the consequences are that you are confused, and are unable to explain enough to me to unconfuse anything. This is why I think the only way forward is for you to explain what the ORIGINAL problems were. Maybe they are not fixable by FSUIPC after all. Once I know what the problems were I can advise on the best way to proceed. Starting from an extra complicated muddle, with me effectively having no real information at all, we are just wasting spce here. That's why the INI file contents would have been so useful -- I could have seen what you have done and at least sorted that out, if not your original problems whatever they were. Unfortunately we are running out of time before my upcoming holiday. I am away from tomorrow evening (Friday 4th May) until Tuesday 15th May. Others may be able to step in and help, but if you want me to examine your INI file you'll need really to do it today, or at latest by early afternoon Friday, UK time. Regards Pete

There are no offsets that I know of for controlling PMDG 737NGX values. The offsets mapped are READ ONLY as clearly stated. They provide information FROM the aircraft, not control of the aircraft! This is made clear in the document. To control the PMDG 737NGX you assign to its controls. Every function and value has a control number, which you can assign. Things like the Heading would be set by a control number and a parameter. As I said in the offset list document, the control numbers are all obtained from the .h file in the PMDG 737NGX SDK installed by their update. Regards Pete

So you had problems before? Oh, that's different! You seemed to be saying that FSUIPC was the cause of all your problems! if you are assigning axes and buttons in FSUIPC you mst not also have them assigned in FS. They will conflict, as i said. that is all that means. In fact because of FS's habit of automatically assigning things if it thinks they are newly attached, it is better to disable the controllers in FS rather than simply unassign everything. Quicker too! However, this is only if you ARE assignbing in FSUIPC. First you need a reason to do that. Most of the benefits of FSUIPC control handling come not from the assignment facilities but from the more precise calibrations you can achieve and the control over axis effectiveness over its range. That can be done with all the standard aircraft controls without any reassignments. Huh? if you think that you are completely misunderstanding things. maybe English is not your main language? Assignments, if needed, are on one tab. They are independent of calibrations, exacty as they are in FS -- FS doesn't even provide calibrations, but leaves that to Windows' Game Controlllers in the Windows Control Panel. Assignment is the process of relating a hardware axis or button to a desired action in FS. FSUIPC offers three distinct ways of accomplishing that for joystick axes -- assignment to standard FS controls, which is just like in FS except FSUIPC uses FS's actual interbal names for those controls, and lists ALL of them, not just those which microsoft exposed in its interface. -- assignment direct to FSUIPC's own calibration interface, bypassing the FS controls and relating them directly to FSUIPC's calibrations only -- assignment to FSUIPC offset changes. This last is very techncal and needs knowledge of the FSUIPC SDK details. The assignment to normal FS controls will operate just like assignment in FS. Whether you then also calibrate is optional. Calibration can be done for axis controls no matter how they are assigned. It is mandatory for the "direct" method of assignment for obvious reasons), but optional otherwise. And because it operates on standard FS controls it is irrelevant whether you assign in FSUIPC or in FSX. This is why they are "separate tabs". They are completely separate functions and separately applicable! How is that "weird"? All this sounds as if you are following some third party advice and not bothering to use the FSUIPC User Manual which I provide for this purpose. Why not use the correct documentation? You seem to have just thoroughly confused yourself. FS doesn't provide any calibration. Calibration for FS is done with the joysdtick makers own drivers, in Windows. I think you must have started out completely wrongly in the first place. Doesn't Saitek supply drivers? Doesn't it provide any documentation? If you start out with a mess then go on to compound it by making a further mess with software you never used before and by reading all sorts of evidently conflicting and misleading advice from third parties, what do you expect to result? My advice is to go back to square one. Find the driver disk that came with your joysticks and things, read its documentation, get it working in FS with the default aircraft. Then and only then maybe improve everything by applying FSUIPC, and use the FSUIPC User Guide. Where on Earth do you find a lack of information? Are you sure you ever looked at the User Guide? It doesn't sound like you did. It isn't in the ZIP you downloaded, it is in the FSUIPC Documents folder inside your FSX modules folder -- in fact in exactly the place the Installation guide (which is in the Zip) tells you it is! If you still want me to look at your settings so I can see what you've done wrong, don't forget to paste that INI file here. But I think you should also explain what the problems were that you were trying to solve in the first place. It sounds to me like that's the key! Regards Pete

Yes, but as I asked, what is it you want to achieve by assigning in FSUIPC instead of FSX? The main use of FS to improve controls is calibration. Assignment in FSUIPC is not necessary for proper and accurate calibration. So not when you assigned in FSUIPC, only calibrated? Is this with default FSX aircraft? How did you calibrate -- following the numbered steps in the User Guide? Assigning or calibrating? You are confusing me now. If you assign in FSUIPC to the FS controls it is exactly the same as assigning in FS. If you assign in FSUIPC "direct to FSUIPC calibration" then you MUST then calibrate -- that's what it means "direct to calibration". Some aircraft need different ways of assigning. You must always state the aircraft if not default. Some, like the Wilco Airbuses and the PMDG series do not respond correctly to all the possible ways of assigning -- throttles especially. Also you must not have the same axes also assigned in FS -- they will conflict! Your description of your problems sounds a bit like such a conflict -- either that or completely bad calibration. BTW the current FSX version of FSUIPC is 4.827, so make sure you are up to date. Then, if you still have problems, show me your FSUIPC4.INI file (from the FS Modules folder) so I can see exactly what you've done. You can paste it here in a message, it is only a text file. Pete

The currently supported version is 4.827. What's is this "Saitek Multipanel" intended to do for you? The PMDG mapped offsets for the 737NGX are only for information OUT of the NGX, not controlling it. What driver program have you got which is able to send that information to this panel of yours? Are you writing one or using someone else's? FSUIPC is not a hardware driver and knows nothing about your "multipanel". If it looks like a reguiar joystick device then FSUIPC can be used, like FSX, to program the buttons and switches, but that would not be using offsets mapped to 737NGX outputs. Regards Pete

If FSX doesn't see your controls then neither will FSUIPC as both use the same Windows' DirectInput facilities. You'll need to ask Saitek support to help. It sounds as if either they are broken or need some proper driver installing. First off, why do you want to assign axes in FSUIPC? That's a facility mainly airmed at those either wishing to have different controls automatically assigned for different aircraft types, or for those wishing to do unusual things with their axes or to assign axes which aren't supported by FS directly. You can calibrate controls in FSUIPC even when they are assigned in FS, and that is the more usual way to proceed. FSUIPC has offered those facilities for a very long time. The axis assignments were added for cockpit builders and those more ambitious users. However, that said, there is nothing to assigning. You simply select the Axes tab in FSUIPC options, move the lever around till FSUIPC sees it, then select and action for it in the drop down list on the left hand side after selecting one of the 4 entries. There are 4 to allow 4 distinct simultaneous assignments to the same axis. I don't see it takes scouring manuals or 300 pages of Forum messages to do something which is so simple, obvious and natural to most users, and expressed in a few short paragraphis in the supplied User Guide. It is certainly no more complex than FS assignment despite being more powerful in several ways. Regards Pete

Sorry, I really wouldn't know how without wrecking performance -- FSUIPC or some other internal DLL would have to constanty pause the sim whilst it checked all the memory allocations, and made sure the freed ones were all collected. And I don't think that would even solve it because it is entirely possible that the memory genuinely is running short for needed assignments and/or there are lots of blocks which aren't really needed any more but which haven't been freed (yet). How can one detect blocks not being used? Only by intercepting the access to every one so that usage counts can be maintained. Imagine how slow FS would run! And suppose one not used for a while was then required again? The program would have to be able to re-assign and restore the data which it had discarded incorrectly. Not sure where it would store it -- in another Process perhaps (for more Process memory), or else in files. Redirecting memory access to such blocks would be impossible so it would have to work miracles with the memory that was allocated. Ugh. I don't think it is possible. the more I think about it the surer I become! The only real solution is recompiling the whole thing as a 64-bit program. I bet that would kill many many add-ons stone dead in any case -- until they were also so treated (FSUIPC included). Oddly, I've only ever experience OOM the once, and that was due to a bug in one of my own programs. I added the OOM detection into FSUIPC to track it down. I've also only ever experienced that G3D crash which I patch just the once, oddly in a standard test flight I use many many times -- EGCC to EGLL, with UK2000 airports. And I fly with pretty dense scenery and just about all of the add-on airports you can get for Europe. I don't fly outside of Europe these days (excepting near the Med coast, and Madeira / Azores / Canaries). Regards Pete