Pete Dowson

Don't know why it "only seems to work sometimes", as it isn't going to be changing the way it operates, but a small drop in fps would be something I would be afraid of with any changes to the way it was setup. I get neither problem here with a virgin FSX install -- no measurable difference in frame rates at all, but nor in axis "smoothness", But then I am using Windows 7. Are you restricting FSX to only using one core on your PC? I really can't see how a minor change in one thread can have anything but a miniscule affect on FSX performance. Anyway, i'll discard those changes. I'll upload one more version, something less drastic than the last. After that I can only think that your problem just isn't soluble. Pete

This rotary knob with 7 'settings' -- do you mean "positions". Does it look like 7 buttons, then? How do keystrokes come into this? Keystrokes don't have 'parameters', so I don't understand what you mean by a parameter of 1. Perhaps you need to explain more fully what it is you are using and what you are trying to do. Are you using FSUIPC? Er, this is even more confusing. Is this "knob" not a real knob, but a graphic on screen? What are you assigning a key to, exactly? Pete

Judging by similar previous reports, it's probably due to PMDG's way of freezing the simulation each time it saves a flight. I think it may have to do this to make sure all the values it is saving are correct for one specific time so they can be reinstated if you reload the flight. I think you will have to disable the FSUIPC autosave option, if you've enabled it, or the same in whatever other program you have saving flights at intervals. Pete

I don't really know. I'm a little surprised it's made such a difference, as it's about the same here. As i say, I just simplified the way in which it works out how and when to poll the joysticks. it can't just loop as fast as it can because it needs to let FS do other things. Even in a multi-processor PC like everyone has now, you can't let one thread take 100% of the time in its processor, it has to allow others in too. I just changed the way it did that, as an experiment really. Anyway, glad it worked okay! Pete

I've changed the way the polling limiter works inside FSUIPC to see if it helps. this is a device to ensure smooth polling without adversely affecting FS performance. Over the years it has become quite complicated to achieve such harmony, but i think I've simplified it somewhat and it may well be better on your system. I've tested the changes here and they make little difference on my system, but try it on yours and let me know: Download FSUIPC4934cTest.zip, and placed the DLL in the FSX Modules folder, replacing your 4.934. Regards Pete

Hmm. I'm wondering then if Win8.1 is the reson for the problem in the first place. One thing to check for -- make sure there are no extra DirectX DLL modules in the FSX folder. Folks have had problems with FSUIPC not even being able to connect to devices because of some add-ons installing extra DX8 modules. Oh, but you said you'd not added anything yet? A "virgin" FSX apart from FSUIPC? I really don't know what to advise. FSUIPC uses the standard Windows DX8 API calls, same as FSX. I really don't know why FSX disconnects and FSUIPC doesn't -- presumably something slightly different in the way the calls are made or timed. But it is the same interface, and the results should be the same. There is nothing in FS or in FSUIPC which will make things jitter or stutter assuming only one of them is reading the values. It should be perfectly smooth. I'll do some checks here and see if I can add anything to tell me what is going on on your system. Pete

I'm sorry, but I am at a loss to understand this. Assuming you have controllers disabled in FS (which otherwise have always been the cause), it happens no where else and has never been reported at all before you, so i can't really help at all. I suggest you assign in FS -- in any case, judging from your posted settings, you aren't really utilising the axis assignment facilities in FSUIPC for anything useful at all. You would accomplish the same thing with FS assignment, and, according to you, with better performance. Pete

Well it was a pot luck sort of try. No reports at all for P3D 2.2 and none previously for PFCFSX. I think these faiiures are very time critical -- on other systems (mine is an example) there'll be no such problem. It's all to do with the order in which things happen in different threads. The good thing is that they don't occur during a session, and end up just being a bit of an annoyance. As I say, I put up with them throughout P3D development until 2.2, which is the first one for me which doesn't crash on exit. Pete

I've re-ordered the PFCFSX closing sequence slightly in a test version of FSUIPC4 for you to try. It makes no difference here, and I'm doubtful, but let me know. Download FSUIPC4934bTest.zip Pete

NTDLL is a major part of windows which supports a majority of the API calls made by any program. I think probably as many as 90% of all of the P3D crashes on exit were in NTDLL, and are possibly due to call backs occurring from P3D's SimConnect into a module which has already send a close notice to it and which is in fact no longer in memory. At least that's one main possibility that I can think of. Please report the problem to L-M and supply the Windows error details as above -- not the FSUIPC or PFC logs as they don't show anything wrong. Meanwhile I will certainly have a look at the ordering of closure events in FSUIPC for the PFCFSX module -- maybe a little re-ordering will help, i don't know, and since the problem doesn't happen here it will be difficult to tell. One question: does it crash on exit no matter what you do in P3D? For instance, if you just load it up, get to the ready-to-fly stage then close it, does it still crash? Pete

There's really no need to worry. P3D os very very prone to crashes on termination and L-M have been fixing them gradually, but some still occur. The only ill effect you may get is that changes to the P3D settings made during that session might not get saved to the P3D.CFG file because this tends to be done at the last moment. Without any crash information there's really nothing I can do. If the crash information is in one of my modules then I can take a look, but if not then it has to be reported to L-M. I had 100% consistent crashes on termination in P3D is all versions up to 2.2 -- 2.2 is, in fact, the first version for me which doesn't actually crash on exit! I reported the earlier ones of course, and evidently L-M did manage to fix them. There's no difference in any of my programs for P3D except the changes dealt with in FSUIPC, because all the others use FSUIPC. The PFCFSX module is totally independent of the underlying version of FS., it just depends on FSUIPC version 4. All the details I need are text, so just paste their contents into a message here. The can encompass them in <> parentheses (see on of the edit buttons about the typing area), and this retains formatting etc. I primarily need to see the Windows event viewer details for the crash, the FSUIPC4 log and the PFCFSX log. Pete

Because you appear to be using integer arithmetic, and in integer arithmetic, where all fractions have to be discarded, the value (3600 / 65536 / 1852) is zero. In fact even just (3600 / 65536) is zero. I suggest you do all your arithmetic using floating point values, like this (in C): this.gs = (this.fs_gs.Value * (3600.0 / 65536.0 / 1852.0)); or, if you really have to stick to integers only, at least do the multiplications before the divisions, and also make the rest look more sensible (after all, does "/ 65536 / 1852" mean "divide by 65536/1852" or does it mean "divide by 65536 and then divide by 1852"? The compiler might know, but it isn't clear in normal school arithmetic, is it? this.gs = (this.fs_gs.Value * 3600) / (65536 * 1852); Applying this to 2681613 you see you will get 79 (or roughly 79.539 is "this.gs" is a floating point variable, not an integer). Pete

Okay, but i must admit that talk of using strings when the value being talked about is a 16-bit binary number, not a string of any sort and especially not a C string, is very confusing. There are offsets which have strings, but most are just numbers, be it 8-bit, 16-bit, 32-bit, or 64-bit. Some are in floating point format, some, like this one, are just plain integers. Pete

You've never even looked at the FSUIPC documentation? The ZIP you downloaded containing FSUIPC includes an Installation and Registration document. it tells you exactly WHAT gets installed, AND where it is! Did you never even bother to look at that? All the documentation and lots of extra stuff is installed in a folder mysteriously called "FSUIPC Documents", right next to FSUIPC itself in the Modules folder. FSUIPC is doing nothing else. There is no code in FSUIPC at all to connect to anything except FS itself. There is no internet connection whatsoever. It busies itself populating the offsets for client applications to use, and responding to their requests. That's it's no.1 task, it's prime reason for being, dating right back to FS98 days. The joystick calibration came later, then button and key programming , and then axis assignment, which was added to allow folks to have different axes for different aircraft types -- eg sidesticks for Airbus, yokes for Boeing, G-sticks for helicopters, and so on. I think you must have something wrong. If you really have disabled controllers in FS, and don't have the Saitek software running ands spoiling things, then I can only think you have a corrupt installation of FSX. The facilities you are using are used by hundreds if not thousands of users without problems, I've no idea what you have going on there. Sorry. BTW, judging from your INI file you have no good reason to make axis assignments in FSUIPC in any case, so I still don't know why you are doing that. The axis assignment facilities were a late addition to FSUIPC. As I said before, you can still calibrate in FSUIPC if you wish, no matter where you assign. But you ought to make a better job of it, following the instructions, as I said, or that is also really a bit of a wast of time too. Regards Pete

There are no specific controls for add-on aircraft built into FS. FS only knows about its own internals. If there are 777 controls there it can only be because you have installed a macro file for a 777 into your Modules folder. The drop down lists include: 1. All FS controls, as listed in the supplied Controls List. 2. A large number of FSUIPC-implemented controls, as listed in the FSUIPC Advanced User's guide 3. Lua, LuaValue, LuaSet, LuaClear, LuaToggle and LuaKill controls for every Lua plug-in installed in the Modules folder 4. Macros denoted by a name formed from the macro filename then a : and the macro name from inside the file, foe every .MCRO file installed in the Modules folder. So, it sounds like you have a macro file for your 777 but none for your 737. Pete

Not a lot very wrong there. But there are a few oddities. Looking at calibrations, for instance, in all cases you have You don't want both the generic throttle and the two separate throttles calibrated. I see from your axis assignments you only have the generic throttle (i.e. one lever) assigned and it isn't shown as being mapped to the two separate throttles, so if i were you I'd delete all of the "Throttle1=" and "Throttle2=" lines in each Calibration section. On the other hand, if you'd intended to map the generic throttle to the separate throttles, so you could have a reverse zone, then you need to enable that mapping after by pressing the 'reset' button on the generic throttle on page 1. If you do retain the separate throttle calibrations, the /8 on those lines means that you have the Filter option enabled on them. As I said earlier you don't want that unless you are happy with the slow response it might give. Filtering is very rarely needed on any modern devices with decent power supplies. (The option was originally put in to help a user with a very variable power supply somewhere in the countryside in Asia). Additionally, on those calibrations, you do seem to have a very large idle zone. using up pretty much half of your entire throttle movement. Why is that? You have filtering on the toe brakes as well ....? Also, for ALL of your calibrations you don't really seem to have followed the advice (the numbered steps) in the user guide. The minimum and maximum values for every axis are pretty much the actual minimum and maximum you can possible get. This leaves no room for minor variations which are bound to occur even in the best controls (which I'm afraid Saitek are a long way from). I suggest you get out the FSUIPC User Guide and re-calibrate all your axes carefully, following the steps as advised in the Calibration chapter. I see nothing which would particularly make the operation of the main control axes -- aileron, elevator, rudder, at all "jerky" -- unless you do have dual assignments after all. Do you actually disable controllers in FSX? It isn't usually suffiicent to just delete the assignments, as FSX has the habit of remaking them. Pete

Sorry, I don't understand your code. Please instead use the FSUIPC logging facilities. In the Logging tab enter the offset as type U16 and check the "hex" box, on the right-hand side. Then check "normal log" below. Repeat your test -- set the frequency first the normal way, via the cockpit screen (so its value will be logged), and then show me the log file. You can also play with reading and writing offsets using FSInterrogate2 (from the SDK), which will show you that it works fine. Regards Pete

Well, I would like to know too, because i can think of no reason and it simply isn't a normal problem. Perhaps you can find your FSUIPC4.INI file (in the FSX Modules folder) and paste its contents into a message here and I'll check your settings in case there is anything strange. Pete

There's no difference as far as FSUIPC is concerned between any of the aircraft. It simply passes through the values it receives at the rate it receives them. If you assign to the FSX controls it will be slightly longer because it will be sending controls to FSX first then intercepting them for calibration -- assuming you are also calibrating in FSUIPC? For better efficiency you should use the "direct to FSUIPC calibration" option which bypasses FSX. But that doesn't apply to Pan View which isn't a calibratable axis, and it sometimes cannot be used with add-on aircraft -- such as the PMDG 737NGX which also processes controls by intercept. Also, if you are calibrating, try to NOT use the "F" filter option, as that does make response slower as it needs to sample values to operate the filtering. The filter option is only for extreme cases of jittery actions usually caused by poor power supplies in remote parts of the world. Finally, If you find FSX assignments better (which goes against what most users find), why on Earth are you using FSUIPC for assignments? You do realise that you can assign everything in FSX and still calibrate and so on in FSUIPC? The only point of assigning in FSUIPC is if you want different controls assigned for different aircraft. Pete

In that case there should be no problem. I can only think there is something wrong with the controls themselves? Pete

All SimMarket keys are obtained from your account on SimMarket. I have never had a key sent to me! The term "deleivered" simply means you need to go to your account to retrieve the details, and, for some products, do the download. Pete

What are you writing for 120.0? It should be just the 16-bit value 0x2000 There's no "string", so nothing to terminate. It is just a simple 16-bit value, a number, not a string! Pete

There's nothing which makes FSUIPC "run at too slow data transfer rate". It deals with inputs from devices when inputs from devices arrive. If all of your controls are "stuttering" I think you must have a problem with your USB system. Maybe you are routing them all through an unpowered hub, or similar? Try connecting everything direct to the PC. Many folks have said that, but when they checked the version number they were well out of date. Only version numbers mean anything. "newest version" means nothing. Pete

FSUIPC does not work properly in P3D2.2 (and could actually cause it to crash) unless you apply the P3D patch to get it up to build 10438. This is clearly stated in the top pinned thread in this Forum and in the download Links subforum where you will also find a link to where you can get the P3D update. Pete

FSUIPC is sending PAN_VIEW controls to FS at the same speed at which it sees changes, and is smooth here, just the same as when assigned in FS. Maybe your "delta" is set incorrectly? It should be 1 for a POV hat. The value is displayed in the axis assignment tab, and it's the first number after the axis name (i.e. the first number after the first comma) in the assignment line in the INI file's [Axes] section. FSUIPC will ignore changes in the axis value less than the Delta. BTW make sure you are using a current version of FSUIPC -- 4.934 is the oldest supported for FSX. Pete