Pete Dowson

Flight path angle is controlled by a combination of engine (thrust) control and elevator / elavator trim settings, and is a constant feedback process. Unless your aircraft is actually equipped to do this (and personally I don't know any that are -- autopilots control airspeed or descent speed, but normally not directly the FPA) then you'll need a sophisticated program to do it -- via feedback. Is that what you intend to write? This is of course irrespective of what input control mechanism you provide for the pilot. That is easier. If your "knob" on your USB game controller is recognised in Windows, and therefore flight sim, as a joystick axis, then you can have a continuous adjuster. If it is a digital encoder with, effectively, two button inputs, then it can operate with small icrements or descrements to adjust the results. Pete

Do you assign to the default FS/P3D flaps control (Axis Flaps Set), or Flaps set, or "direct to FSUIPC Calibration" flaps? I had mine set to the normal FS one, "Axis ...". Also it might be worth just monitoring that 1 byte offset 0xBFC, to see if it changes correctly from 0 to 8 or vice versa. You can Moniroe an offset by entering its details on the right-hand side of the FSUIPC Logging tab and selecting a display method or log below. Pete

Okay. I have a Saitek throttle quadrant which I use for testing. I assigned one of the axes to FS control "Axis Flaps Set" and used a direct copy of your calibration settings ... ... snd I have to say they worked perfectly here with the default FSX/FSX-SE 738. When you calibrated, were you doing this with the 737 throttle quadrant showing on screen? I'm not familiar with Sim-Avionics so I don't know even if its 737 has an on-screen cockpit you can see. But you need to do it for the model you are using -- they are not all the same. In particular, for instance, I know the axis values needed for the PMDG 737 flaps are different. And possibly Sim-Avionics has a different method enirely for flap positions? Any chance of you getting a default 737 to test with? I'm not sure if there is one for P3D unless you also have an FSX or FSX-SE installation. I'm also wondering if you might not get more joy from Sim-Avionics support? I use ProSim737 for my cockpit, but my quadrant is part of my original PFC 737 hardware cockpit, with shell, and its flap lever has built-in detentes, calibrated though my own PFC driver (PFCcom64.dll for P3D4). ProSim737 comes with its own 737 model, but no on-screen cockpit display so I can only check by the feedback on the flaps gauge, and of course the "notch" value available in offset 0BFC (one byte, 0-8, 0=up). Pete

The only odd thing I see there is the final setting, for flaps fully extended. Apart from the range allowed being verey small (16383 to 16384) the maximum calibrated value is 16380. However, apart from the fact that this should work in reverse, it looks okay. I'll try your exact settings here. Pete

I understand that. That is why I said "I don't know what is going on with your system" -- because I don't. I can only tell you what FSUIPC can and cannot do. When strange things are happening on a users system I simply do not have enough information about everything else on that system to explain strange happenings. Well, it is a complicated sequence which should not be necessary and which I don't understand. Perhaps you understand something different from that word as you seem to be taking it as an insult! :-( Where on Earth is this coming from? Where did I ever say you were lying??? NO ONE IS BERATING YOU OR YOUR SYSTEM!! Please do read my replies a little more carefully, as you plainly are reading things which are just not there! I try my best to help, but I do not understand everything that may happen on everyone's systems. All I can say it what my own program does. Pete

Thanks for the links. This, from one of them, seems to contradict the idea that it is a "bug", and it is from a contibutor whose opinions I value: Actually, it is not and never has been a 'bug' per se. Even fuel injected engines require an air source, and unless you have some way to heat the air intake, you can and will have ice formation. I'm not sure why you'd want the switch operated by gear up, but if you'd programmed this in the FSUIPC axis assignments using the range part on the right, why not simply reserve a small part of the area representing the movement towards "gear up" as an other zone which is assigned to the so-called Carb Heat switch? (i.e. have three zones instead of one or two). The control assigned to the 'H' key by default is actually known internally in FSX and P3D as "Anti ice toggle" (applicable to jets as well as props, like "Pitot heat toggle", which is Shift+H) and that's what you need to assign to. As it's a toggle you'd need that range applicable to both up and down passage through it. Pete

I’m not at home at present but will send methods when I return, but meanwhile can you tell me what “the P3D fault” is? You seem to be assuming it is general knowledge and is not going to be corrected. It would be helpful if you could find where you read this advice, as it seems very strange to me. Pete

Pictures aren't much help. This one does show two things: 1. The lever is at one extreme (16383) which should equate to fully extended. 2. You've not checked the REV option, to reverse the action. Usually for airliner flap levers you want the lever at furthest position to be 'flaps up' and nearest you to be 'fully extended'. (NOTE: The REV must be selected BEFORE calibration). Either way, either your lever is misbehaving, and giving Max Reading from part way through its travel, or you've done something wrong in the flap detente calibration stage. So, first check that moving the lever from one extreme to the other does change the input value continuously, from something more than 16,000 to -16,000. For the detente settings which you've made, best to show me the [JoystickCalibration] section of your FSUIPC5.INI file, from the P3D Modules folder. (Actual data is always better for me than pictures). Pete

Was that an error when you changed the name? That's a lot of palavah! I don't know what is going on with your system, but FSUIPC will be doing absolutely nothing differently the second time from the first. It wouldn't be looking at FSUIPC4.KEY at all if the FSX was renamed as you have it. There's no way it will work in the one case and not in the other! Well, I hope I'm as good when I'm 84. I am 75 this year and I'm sure my little grey cells are disappearing fast already! Pete

Like all sophisticated add-on aircraft, the PMDG ones do their own systems simulation, not relying on built-in functions for very many things. With the PMDG 737, 747 and 777 models, PMDG have provided their own controls for pretty much every function. These are listed towards thwe end of the .h type file in the SDK folder of the specific aircraft install. Each one needs the actual numeric value calculated -- just by adding a base number to a sequence number. Then these controls can be assigned in FSUIPC as <custom controls>, or send from a program or Lua plug-in. They will all take a parameter of some sort, and generally the parameters use mouse type encodings, derived from the way Windows sends mouse actions, and these too are listed in that document. For more specific PMDG help you will need to go to the PMDG forum. I don't have or use any of the PMDG range. Yes, and if you searched this Forum you'd find the questions and the answer I have provided many times before too! ;-) There might be some thread in the User Contributions subforum above which helps too. Pete

FSUIPC doesn't read any joystick type devices directly itself. It uses Windows' DirectInput. If Windows sees it as a normal Game Controller and can calibrate it, and if P3D can see it, then so will FSUIPC, as it uses the same methods through DirectInput. Pete

That must be wrong. There is nothing anywhere in FSUIPC that can or will delete a KEY file. Nor in the Installer, come to that. It will of course re-write one if you re-register, that's all. Are you sure it isn't a virus checker doing it? because KEY files are also used to change your Registry, and many virus checkers will remove them or put them in their "safe place". Pete

please yourself, but all you need to do is make a copy of the KEY file renamed appropriately, as I said (and as I see Luke reminded you). Note that if you have a lot of renamed FSX.EXE files you'll need a renamed KEY file for each. If you actually use FSUIPC for anything, and therefore have settings saved, you'll need a renamed INI file for each too. Your system is really very unusual and would probably throw a number of installers and add-ons. It's probably unique. I've heard of doing this for different FS settings (because, at least at one time, each would have a different CFG file too, I think), and once upon a time for different FSUIPC assignments and calibrations, but since Aircraft-Specific settings, and then Profiles were introduced this hasn't been needed for FSUIPC. Pete

Thank you! So, first thing I notice is this: So, it seems that FSUIPC is actually running unregistered? Or have you deleted the User Name and Address in this posting? It says "FSUIPC5 Key is provided" may mean the key you entered is NOT valid for FSUIPC5. maybe an FSUIPC4 one? If FSUIPC is not registered it is really not doing anything UNLESS told to by some FSUIPC-using applications. This sequence: shows you pressing Ctrl + Shft + F12 then releasing them. As logged, they were not used by FSUIPC at all. What then happens is up to other programs. So, I'm sorry, but it isn't FSUIPC which is upsetting your GSX invoking. I can only suggest checking other add-ons you are running. In the past there has been the occasional odd issue with other add-ons and FSUIPC involving the order in which they are loaded. Also, it would be worth you trying a different key comibination for GSX. I seem to recall it is assignable. Or maybe it defaults to the setting I have, which does work -- Ctrl+F12 rather than Shift+Ctrl+F12. Try it. (I think that is the default, by the way) Pete

That is a picture of the Log file in a Console window. Earlier you couldn't even find the Logging tab. Now it seems you have found it and have been selecting things rather wildly! Why? What are you trying to show? Why are you choosing a console log? And why are you pressing the "New Log" button? The picture shows nothing useful. I'll lay it out step-by-step. Do this: 1. Start P3D. 2. When P3D is ready, find the FSUIPC entry in the AddOns menu item 3. Select it so that the FSUIPC Otions window appears. 4. Click on the tab which says "Logging" 5. Make sure NOTHING is checked. Uncheck anything which is. Do NOT press any selections or buttons yet. 6. Now select the "Button and key operations" option, 3rd one down on the left, so that it is checked. 7. Click OK, bottom right 8. Press the key combination to invoke GSX. Note what happens. 9. Go back to FSUIPC Logging and UNCHECK the "Button and key operations" option you checked above. 10. Find the FSUIPC5.LOG file in the P3D Modules folder, and show me that. Paste the contents of the file in a message here -- please do NOT show me a photograph or screengrab! I hope setting it out like this will help you understand what to do! Pete

By "linefeeds" do you mean just 0x0A or the more usual CRLF (0x0D then 0x0A)? Because: if the ARDUINO is sending a terminating zero (0x00) after a single LF (0x0A) then the length of each transmission would be a multiple of 5, of course, and 6 in the case of your Y010. Conversely, those lengths would apply also if it isn't sending a 0x00 but is sending CRLF instead of LF. The odd things in your code are these, I think: 1. The event.com action provides whatever was read up to the time of the event. That is given in the datastring parameter, which you then destroy by reading again into datastring. If you read the description of the event.com function it does say that the data is supplied for you. It also says you CAN use com.read but that is for additional data which may arrive if you take some time to process the event data. 2. The event.com call is asking for a minimum of 1 byte, which would be useless to you. You want a minimum of 5 surely (see above)? 3. The event.com call allows up to 50 bytes -- that is up to 10 calls from the Arduino, so you'd need to go around a loop to see if there are more than one. With your function you should have a min and max of 5. 4. Discard the delays. Those will make things worse not better. Pete

Sorry, what was this about? What is the point of this message? It makes no sense at all. Who are "they" and how do you "run" an INI file? It is just a place where your settings are saved, not a program to run. Have you changed the INI settings since you posted the file before, 2 hours before this strange post, repeating what looks to be exactly the same? Pete

What don't you understand? Why send me a picture of the "menu" my program creates? I did actually write the program and designed the menu (actually "Options") window, so I do know quite well what it looks like! Do you mean you don't see the little tab marked "Logging"? I can see it even in the miniature picture you sent! Have another look please! The INI file you sent shows you aren't actually using FSUIPC user features for much, just a throttle calibration with a remarkably extreme slope (sensitivity) change. Certainly no key assignments. We need to see the logging of the key press to see what is going on. By the way, there are some known reported problems related to add-on menus in P3D4.2 which are being resolved by L-M at this moment. Your problem might be a symptom of one of them. But let me see what happens with the logging first. Pete

Have you tried any other key combinations? That isn't the default setting, is it? I thought it was a straight F11 or F12? I don't recall, because here I have it assigned to a button (via FSUIPC of course). FSUIPC and GSX have absolutely nothing in common and they work quite happily together here. It sounds like you have Ctrl+SHft+F12 assigned in FSUIPC, or being used by a Lua plug-in as otherwise FSUIPC doesn't touch the keyboard. Please show me your FSUIPC5.INI file. You can also check these things by enabling Button and Key logging in FSUIPC's Logging tab, then checking the log after you've pressed those keys. Pete

Sorry, I'm so used to typic FSUIPC5 these days it came out automatically. I of course meant FSUIPC5.LOG. Aha! There's the reason: "Running inside FSX Steam Edition on Windows 10... ESP has been renamed as "Kodiak" This is why I asked you "Finally, can we assume that you ARE actually running the FSX.EXE file which is in the D:\Steam\steamapps\common\FSX folder? Please check what you are actually executing." You are NOT running "FSX.EXE"! FSUIPC registration has worked and produced the FSUIPC4.KEY file, but because you aren't running "FSX.EXE", but something named Kodiak, all sorts of odd things happen. Why have you done it? It should never be needed these days. It does allow a different FSX CFG -- using a renamed CFG file, and a different FSUIPC setup (renamed INI, renamed LOG, and, importantly here, renamed KEY!) The KEY file is produced by the installer when you install. It doesn't know and doesn't deal with anything other than FSX. (The INI and LOG are run-time). To make an alternative install work, with a different renamed FSX.EXE, you must copy and rename your settings (INI) and KEY file. It seems you've never even run FSX.EXE normally so there was no original INI file, only the one saved with the Kodiak part. If you had run FSX.EXE you would have seen that your registration was successful. In order to make FSUIPC run in its registered form with a renamed FSX you need the KEY file named like the INI and LOG files, i.e. FSUIPC5.Kodiak.key. Incidentally, there is a chapter about this in the FSUIPC4 Advanced Users Guide, in the chapter entitled "Multiple INI files", where the reason for this renaming is described as being for different settings. I don't know your reasons, but these facilities have been dropped in FSUIPC5 because they are simply not necessary these days and renaming is seldom if ever used. Pete

Also, please show me the FSUIPC5.LOG file from the sim's Modules folder, if there is one. That'll be D:\Steam\steamapps\common\FSX\Modules. After all, that log would show what happened when you actually ran P3D --the Install Log merely shows a normal perfect install (and so far you have shown us what amounts to three identical copies except two for the current version and one for an out of date one). In fact, please tell me what files, if any, you see in that Modules folder. Finally, can we assume that you ARE actually running the FSX.EXE file which is in the D:\Steam\steamapps\common\FSX folder? Please check what you are actually executing. Because the install log shows nothing wrong, the Steam folders are certainly not protected in any way, unlike the "Program Files" folders, the Install log shows everything is perfect, and in fact nothing like this has ever been reported with and FSX-SE installation, so it simply isn't making sense. Pete

Please update to a supported version of FSUIPC, 4.974 or later. Pete

I got a reply back from PMDG straightaway. They think this is the same P3D bug they've been getting other users reporting, and which L-M know about and have in hand. It does only apply to P3D4.2. For now you'll need to do without that display. Add it back and re-test when the next P3D update is available.. Pete

Okay. That's pretty conclusive then. I'll have to ask PMDG to investigate. Maybe they can also test with an earlier version of P3D4 in case it's a new problem. Thanks. For the time being I think you'll just need to run without that display line enabled. If L-M or PMDG come up with anything I'll let you know. Pete

Okay. Try FSUIPC 5.110 please: Install_FSUIPC511.zip This will only install if you delete your later DLL first. And please do get back to the latest supported version after a test. I'm only wanting to narrow the problem down to that one SimConnect call. If it is a P3D bug it might be a problem getting it fixed by L-M, as it is very very specific to that one aircraft. There is one other thing you could do, please. With 5.124 or later, try just a Lua plugin with only that display line, nothing else. If that fails I can ask PMDG look at it first as they could probably identify the exact nature of the problem more specifically, for reporting to L-M. If it doesn't fail that way, the puzzle gets rather more difficult. Pete