Pete Dowson

No. Windows default core scheduling should be as good if not better. Most of what FSUIPC has to do must be run in the main FS thread or it won't work. In fact 95% of what FS does in in one main thread, and there's no way of splitting it. FSUIPC does use a few separate threads, but apart from those dealing with Networking (for WideFS) they a very small and do very little. Anyway trying to assign individual threads within a single process is generally not a good idea -- things can get much worse that way. It's other processes you want to keep off. Most of the Windows base processes run in core 0 so with FSX use an affinity mask setting which avoids core 0. If you want better sharing out of cores you'd be better off moving to P3D where they have made some improvements in that area, as well as shifting graphics work to the GPU. . FSX was never designed to take much, if any, advantage of multiple cores. Disconnects are not anything to do with FSUIPC and nothing it can do about. They seem very very prevalent with Saitek devices. I don't know if that's just because they are so popular and therefore used a lot, or if they are really so bad, but I rarely if ever see anyone saying any other makes disconnect. I don't use Saitek at all and have never ever had any disconnection problems. Of course i am using Windows 7, which is probably the most important difference. Pete

Version 4.911 is well out of date and unsupported. You need to update. Version 4.934 is the oldest currently supported. Why "on the Internet"? What is wrong with using the documentation supplied for FSUIPC? Do I waste my time writing it all? What performance, exactly, would you expect? An outer marker is a transmitter. You RECEIVE a signal, not SEND one! It's an input not an output to be controlled by a button! You said Surely lights are lights, not buttons? How does programming buttons deal with warning lights? You seem to have things backwards. To drive warning lights you need to READ values from FS and WRITE to your hardware boards to light the lights! Yes, and all of those are read-outs, values which tell you the state of that thing, be it a signal, setting or whatever. What do you hope to happen by WRITING to those offsets by pressing buttons? Don't you see, it makes no sense! You can certainly use the offset setting controls to send INPUTS to FS, for controlling things you can control. How you expect to use buttons and switches to make warnings happen, i don't understand. The warnings and so on are results of other things going on, they are OUTPUTS from FS, there in the offsets for you to read and take action upon (like lighting a light, for example). Obviously, in order to do that you'd need to READ the offsets values and use the result to WRITE to your hardware. This needs a program. Yes, it can be done as a Lua plug-in, or it can be written in Basic, or C, C++, and almost any programming language. The Lua facilities are explained in the installed documentation you already have, and the main programming interface is explained in the FSUIPC SDK. Regards Pete

The PFC.MCRO file is just another macro file and abides by the rules for those as described in the FSUIPC Advanced User's guide. I'm afraid the .MCRO file format, and the internal tables these files generate, don't cater for Lua plug-in execution. The problem is that there's really only room for one name, the macro name (which can be an L:Var name, distinguished by the L: part). I suppose it would be conceivable to have another name format for macros -- which would need to be something different from "Lua name" because that entry would occur in the drop-down list for assignments already. However, it would be a complex change which I'm not really willing to undertake at this stage. If you really want to run a plug-in (or use any Lua-related controls, like LuaValue or LuaSet) from a macro file entry the only way I can think of achieving this would be to use the controls to send a unique key press combo and program that in FSUIPC's Keys tab to execute the relevant Lua function. Sorry, I know it isn't very elegant. If i can think of an easier way to implement this I'll do so, but it's not cropped up before. And I'm afraid the code for processing Macro files is now so old I'd be scared stiff of wrecking it if I started messing now. Regards Pete

That's odd, because FSUIPC does do a re-scan when you enter the relevant options screen, whilst with FS once a control is disconnected it is normally necessary to restart FS to get it seen again. The calibration tab works with FS controls, no matter where they come from, so if you assigned things in FSX the calibration is still active. It is nothing to do with assignments, they are two distinct functions. Is the AutoScanDevices parameter in the INI file set to "Yes"? I also ALWAYS need to know the version number of FSUIPC please. If not the latest try updating. Not similar if nothing, neither FSUIPC nor FSX saw them. I'm afraid I am very doubtful that FSUIPC can "fix" bugs in Windows 8 and Saitek drivers. I don't know who's been spreading such rumours, but none has ever emanated from me. FSUIPC does virtually the same thing as FSX, using the same Windows interface etc. I really don't see why there could be any difference. Pete

Try FSUIPC4934dTest.zip. It is somewhat between the original and the last one. You can also vary its polling rate yourself, to try to get better than the default. The parameter PollInterval=10 in the main [Axes] section tells FSUIPC to poll all axes at 10 mSec intervals (i.e. 100 times per second). That's always been the default. You can try faster polling (minimum value here is 5 mSecs, or 200 times per second), but you may be better to try any higher value to poll less frequently. On my test system, '5' definitely impacts frame rates, but I see no difference in axis smoothness nor frame rates between, for example, 10 and 20 (100 pps and 50 pps). I think FS's poll rate is a lot slower, around 20 pps or less (a value of 40 or 50 here). BTW there is also a separate PollInterval parameter in the main [buttons] section, which controls the button polling rate, defaulting at 25 mSecs (=40 pps). You can change these values, to experiment, whilst FS is running Just edit the INI file, then go to the FSUIPC Options, and tell it to reload axes (a button on the Axes tab) to force it to re-read all of the [Axes] sections. Similar method for buttons. After this i've run out of ideas I'm afraid. Pete

Rather than pictures, why not just say what you want in the first place? It seems all you want are PMDG command to increment or decrement the ND range. Correct? Don't PMDG provide any keyboard assignable facilities for such things? It would seem very remiss of them if so. Have you checked? FSUIPC provides access to all FSX commands, and a number of extra ones which are added for convenience, but it cannot provide commands for every single differently-implemented add-on for FSX. The facility you are using is designed to send custom controls -- I assume you got the number from the PMDG document listing all of those. That same document should tell you what sort of parameters you can use. I would guess (it has to be a guess because i don't use any PMDG aircraft) that the knob is normally turned by left or right mouse clicks. See if there are parameters which do that. There are some solutions for controlling the PMDG 737NGX in assorted threads in the User Contributions subforum. You might find what you want there. Otherwise you need to go to the PMDG forum where there will undoubtedly be folks who have already done this. Pete

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