Pete Dowson

Earier you said "the effected devices are identical (VRInsight Toggle and Tact Switch Panel)." I see you have these lines in your INI file: [VRInsight] 1=COM5, COM2 2=COM6, COM4 which seems to suggest that the affected devices aren't normal USB connections but serial devices handled completely differently. So I'm a bit confused where earlier you said: "several commands move from a device to another (i.e. commands assigned to device F move to E and viceversa)". You do have joystick type devices E and F. Their names are both "usb pad". This is the [joynames] section (rearranged for clarity): [JoyNames] AutoAssignLetters=No A=Saitek Pro Flight Rudder Pedals A.GUID={28EBBAA0-829A-11E5-800C-444553540000} 0=Saitek Pro Flight Rudder Pedals 0.GUID={28EBBAA0-829A-11E5-800C-444553540000} B=Saitek Pro Flight Quadrant B.GUID={28EBBAA0-829A-11E5-800E-444553540000} 6=Saitek Pro Flight Quadrant 6.GUID={28EBBAA0-829A-11E5-800E-444553540000} C=Saitek Pro Flight Yoke C.GUID={28EBBAA0-829A-11E5-800D-444553540000} 5=Saitek Pro Flight Yoke 5.GUID={28EBBAA0-829A-11E5-800D-444553540000} D=Saitek Pro Flight Quadrant D.GUID={28EBBAA0-829A-11E5-800F-444553540000} 7=Saitek Pro Flight Quadrant 7.GUID={28EBBAA0-829A-11E5-800F-444553540000} E=usb pad E.GUID={28EBBAA0-829A-11E5-8002-444553540000} 1=usb pad 1.GUID={28EBBAA0-829A-11E5-8002-444553540000} F=usb pad F.GUID={28EBBAA0-829A-11E5-8003-444553540000} 2=usb pad 2.GUID={28EBBAA0-829A-11E5-8003-444553540000} G=usb pad G.GUID={28EBBAA0-829A-11E5-8004-444553540000} 3=usb pad 3.GUID={28EBBAA0-829A-11E5-8004-444553540000} H=usb pad H.GUID={28EBBAA0-829A-11E5-8001-444553540000} 4=usb pad 4.GUID={28EBBAA0-829A-11E5-8001-444553540000} K=<< MISSING JOYSTICK >> L=Pro Flight Cessna Trim Wheel L.GUID={4F45C0A0-7B6A-11E6-8001-444553540000} Now that's a lot of devices. But they all seem well-idenitifed. There are 4 "usb pads" including your E and F devices which you said swap over. Is that right? I ask as now you said So what is the truth? What is actually the problem you are experiencing? All seems in order in your INI file, except that you don't seem to have the Cessna Trim Wheel connected at the time, and you have at least one entry in the INI (or the PMDG one) referring to a non-existent device 'K'. Oh, and originally you said: but the whole point with joy lettering is that you don't need to do that. If things do go wrong (and certainly a Windows reinstall can cause GUID reassignments, or sometimes maybe even windows updates if they are serious enough). All you needed to do is to change over the letters so that they refer to the correct name and GUID. I might be able to help more if you explain EXACTLY and clearly what the problem really is, because the previous reports conflict. Pete

I just had a quick look at the files you appended, but there's not enough information. Oddly, in the PFChid64 log "without Altair mcro", there appear to be no Alt macros either! No macros in fact -- or at least none invoked! (The Alt inputs received are operating normally, via the P3D4 offsets). Pete

That's more normal. X=Aileron, Y=elevator, R=rudder, Z=Throttle. Are you assigning it is FSX or FSUIPC? Either way, unless movement in the values it is sending is detected, neither would see it. they both take note of changes, not simply the presence, of an axis! So, it must be working, it is just that the movement is not enough. Have you gone to Windows Game controllers and calibrated there? That's the first step. Then you can calibrate in FSUIPC. But if you assigned in FSX make sure the null zone slider is set to minimum, and the sensitivity to maximum. So, it IS working! It just needs proper calibration. Follow the numbered steps in the Calibration chapter of the FSUIPC User Guide. (Note that it is normal for some axes to need reversing, don't worry about that). Pete

I won't have time to look at this before next week. Can you remind me on monday, say? Pete

By "not work" what exactly do you mean? Can you ASSIGN throttles? In FSX for instance? Doesn't that see them? If it doesn't, it is unlikely FSUIPC will. Both use Windows directinput. I don't know the videos you refer to. Have you tried using the FSUIPC User Guide? I know it isn't a video, but it does have some pictures. Pete

I don ‘t know about batch files, but I don’t think you should include the parameter in the “”. Try the easier way. Make a shorttcut and add the parameter in its Properties . That’s what I always do. Pete

What version of MakeRunways are you using? If it is not 4.863 please update!!! There have been assorted changes to the command line facilities. Yes, I think your problems must be due to an old MakeRunways program. Here's what I get for your file (using />1400): ============================================================================= TestScenery\Scenery\FSSR_ADEX_AB.bgl ============================================================================= Airport FSSR :S05:07:01.8785 E053:18:44.1328 10ft Country Name="Seychelles" State Name="" City Name="Remire" Airport Name="Remire Island" in file: TestScenery\Scenery\FSSR_ADEX_AB.bgl Runway 14 /32 centre: S05:07:01.6194 E053:18:43.9077 10ft Start 14 : S05:06:56.8574 E053:18:39.5673 10ft Hdg: 135.8T, Length 1411ft Computed start 14 : Lat -5.115678 Long 53.310895 Start 32 : S05:07:06.7053 E053:18:48.5069 10ft Hdg: 315.8T, Length 1411ft Computed start 32 : Lat -5.118555 Long 53.313495 Hdg: 138.000 true (MagVar -4.200), UNKNOWN 128, 1411 x 43 ft *** Runway *** FSSR0140 Lat -5.115678 Long 53.310894 Alt 10 Hdg 142 Len 1411 Wid 43 *** Runway *** FSSR0320 Lat -5.118555 Long 53.313496 Alt 10 Hdg 322 Len 1411 Wid 43 COM: Type=6 (TOWER), Freq=118.30, Name="SEYCHELLES" Taxipoint #0, type 1 (normal): S05:06:56.4687 E053:18:39.2454 -- Forward Taxipoint #1, type 1 (normal): S05:07:06.8025 E053:18:48.5682 -- Forward Taxipoint #2, type 1 (normal): S05:07:04.0489 E053:18:46.0818 -- Forward Taxipoint #3, type 1 (normal): S05:07:03.9194 E053:18:46.2411 -- Forward Taxipoint #4, type 1 (normal): S05:07:03.4658 E053:18:45.5555 -- Forward Taxipoint #5, type 1 (normal): S05:07:03.3363 E053:18:45.6971 -- Forward Parking Park1 [#G0]: S05:07:03.2715 E053:18:46.9653 Type 1 (GA Ramp), Size 12.0m, Hdg 49.1T Parking Park2 [#G1]: S05:07:02.6884 E053:18:46.4391 Type 1 (GA Ramp), Size 12.0m, Hdg 49.7T Taxipath (Runway 14): Type 2 (Runway), Start#=2, End#=1, Wid=13.00m Taxipath (Name #0): Type 4 (Path), Start#=2, End#=3, Wid=14.00m Taxipath (Name #0): Type 3 (Parking), Start#=3, End#=G0, Wid=14.00m Taxipath (Runway 14): Type 2 (Runway), Start#=0, End#=4, Wid=13.00m Taxipath (Runway 14): Type 2 (Runway), Start#=4, End#=2, Wid=13.00m Taxipath (Name #0): Type 4 (Path), Start#=4, End#=5, Wid=24.38m Taxipath (Name #0): Type 3 (Parking), Start#=5, End#=G1, Wid=24.38m Taxiname: #0 = TaxiWay : 2-3-G0 TaxiWay : 4-5-G1 FSM A/P FSSR, lat=-5.117203, long=53.312260, alt=10 Note the *** Runway *** lines. And here's the results in Runways.csv, for example: FSSR,0140,-5.115678,53.310894,10,142,1411,0 FSSR,0320,-5.118555,53.313496,10,322,1411,0 Please ALWAYS make sure you are using current versions of programs before reporting problems. Thanks, Pete

AND you are using Joy Letters? If not please do so -- that will solve that problem -- in fact that is precisely what that facility is for. When you talked about devices F and E in your first message I thought you implied you were already using Joy Letters, in which case this is a very odd problem if the devices have different names and GUIDs. That would imply a serious Windows problem, as those things are the only ways to identify a device. Maybe it is time now for you to show me your FSUIPC INI file. Pete

Okay. That narrows it down considerably. I'll have a look at those areas of code. So there will be one more update to check, WITH the Logging, just to make sure I've fixed it. Later today. Pete

The PMDG comes with an SDK listing all the controls you might need, and of course FSUIPC does read all of its variables, register values, even CDU contents, into offsets for you to read (though not write). So it depends how ambitious you are. For just controls I don't think you need a programmed solution any case, though perhaps you have more in mind. Pete

I don't know. i don't have either. Best ask other users. Pete

Results on default scenery: FSSR,0140,-5.114945,53.295757,10,140.000,1568,0,75,-4.200,-5.116487,53.297264,0,, FSSR,0320,-5.118028,53.298771,10,320.000,1568,0,75,-4.200,-5.116487,53.297264,0,, 1568? Results with />0 parameter: 24768 airports, 62536 runways Results normally: 24768 airports, 58938 runways. So, only 3,598 extra runways as a rresult of that parameter. The "runways.txt" includes runways if they are there no matter what parameters you use. That file is a complete log of the entire decoding. The parameters only affect the result files, not the Log file! Here's a log example of an airfield with a VERY short runway: Airport MT62 :N47:04:41.2116 W114:26:11.7920 3197ft Country Name="United States" State Name="Montana" City Name="Huson" Airport Name="Ted Luark Private" in file: Scenery\0201\scenery\APX17150.bgl Runway 16 /34 centre: N47:04:41.2116 W114:26:11.7920 3197ft Start 16 : N47:04:43.5764 W114:26:11.9143 3197ft Hdg: 178.0T, Length 500ft Start 34 : N47:04:38.8144 W114:26:11.6698 3197ft Hdg: 358.0T, Length 500ft Hdg: 178.000 true (MagVar 18.000), Dirt, 500 x 80 ft FSM A/P MT62, lat=47.078117, long=-114.436607, alt=3197 The runways are listed, but they are not included in the resulting files normally. When they are, the Log contains additional lines, thus: Airport MT52 :N47:04:39.7214 W114:24:45.4340 3363ft Country Name="United States" State Name="Montana" City Name="Huson" Airport Name="Nine Mile" in file: Scenery\0201\scenery\APX17150.bgl Runway 16 /34 centre: N47:04:39.7214 W114:24:45.4340 3363ft Start 16 : N47:04:52.2904 W114:24:46.0795 3363ft Hdg: 178.0T, Length 2640ft Computed start 16 : Lat 47.081322 Long -114.412806 Start 34 : N47:04:27.1200 W114:24:44.7886 3363ft Hdg: 358.0T, Length 2640ft Computed start 34 : Lat 47.074081 Long -114.412435 Hdg: 178.000 true (MagVar 18.000), Grass, 2640 x 100 ft *** Runway *** MT520160 Lat 47.081322 Long -114.412804 Alt 3363 Hdg 160 Len 2640 Wid 100 *** Runway *** MT520340 Lat 47.074081 Long -114.412437 Alt 3363 Hdg 340 Len 2640 Wid 100 FSM A/P MT52, lat=47.077702, long=-114.412621, alt=3363 So, your ADE-modified airfield has an error. Pete

Of course you have to enter the whole parameter! How do you think half a number can be the same as the whole number? Do you think $1 is the same as $1000? You can't use part of a number and have it mean the same thing. What are you thinking? I've said several times how to find the parameter. The parameter is the parameter is the parameter. Half a parameter is not a parameter, it is meaningless! You can enter it in decimal, as shown, or in hex (the form starting x. If it says 0x leave off the first 0. As I already explained! Pete

As I said earlier, EITHER! You don't need to "understand" them! They are just numbers. It you want to understand Windows mouse encoding, look at the PMDG document I pointed you to, the one installed with your aircraft! I don't use any PMDG aircraft. This thread is getting very repetitive. I seem to keep explaining the same things over and over. Pete

I've had one thought. One of the changes made especially to try to find the problems with macros was adding extra logging to the parts of the code devoted to setting controls to repeat. In the end it turned out to e something different. But the flaps switches are repeating ones, so it is exercising new code added just for logging the repeat tables. Just in case there's an error in my logging code, could you (temporarily) disable all the logging options and see if that fixes the flaps problem? Pete

No. FSUIPC5 is a new and different product, just as FSUIPC4 was different from FSUIPC3, and P3Dv4 is a different product to P3Dv3, etc. Pete

They don't sound identical. Same GUID and same Name, exactly? That seems so unlikely, but if so then Windows cannot differentiate between them and neither can FSUIPC. You'll need to leave them connected all of the time, powered up properly 9powered hub0. Pete

Really? You looked for Errors (marked with a red icon) in the Application Logs list? Without that information I really have little chance of finding what is going on. There's nothing special about how those switrches are treated. The code for the flaps operation is just 8 innocuous lines. Meanwhile, if there truly is no crash information, I'll try adding log lines to track through where the code goes when the flaps switch is activated. it'll be a temporary version of the DLL from which i'll need the log. But take another look first, please. Pete

If, as I think, those PMDG controls do "turn left" and "turn right", rther than select a specific position, then of course if you never visit one of the other positions, you can assign your switch to the "turn left" and "turn right" variants. So you can switch back and forth between any two positions. GND and OFF (the two usual ones) are easy as they would be one left and one right. Not sure why you'd use GND and CONT instead, but for those you'd do similar but duplicate the assignments so that you turn two left or two right. That would mean editing the settings,file to duplicate the assignment lines with different line numbers. Well. simpler than that as I just mentioned. No need for a third switch. If the switches are spring-loaded then maybe more realistic, you'd have to hold it the GND position till the engine fires (after switching the fuel on of course -- starter lever to 'idle' -- then let it return to GND. In the real aircraft the position is magnetically held. The parameters are shown and I told you which they were already. One of those is probably a mouse left click and the other a right click. This will be stated in the PMDG data you already have -- a file with a .h filetype in its SDK folder. Or you can just tell by testing of course. Pete

Oh, some further clarification. The PMDG controls are all oriented around using the Mouse, and those parameter values are actually mouse action codes -- like left click, right click, drag, etc. Basically I think the functions you are interested in aren't suitable for multiposition switches. A right click probably moves one position to the right, a left click one position to the left. Since FSUIPC can actually read most switch and other values from the PMDG Boeing aircraft, it is actually possible to write a program to determine whether a "right click" or "left click" (and how many) is needed to reach any one position from another. This can even be done using a plug-in to FSUIPC programmed in Lua. But it isn't a trivial task, and not for beginners. Maybe this has allready been programmed, possibly by something like LINDA, another add-on which uses FSUIPC -- but I don't know. Again, it might be worth visiting the User Conttributions subforum above to see what other folks have done. There must be quite a few PMDG users. Pete

Okay, now I understand. These are private PMDG controls, not FSX or P3D ones. The <custom control> number is the number shown after Cntro =, and also in the <> parentheses. The parameter value is the one after Param=. It is in English, albeit abbreviated. The parameter is actually more meaningful in its second form, the 0x ... value, as that format is the one shown in PMDG’s own list which you already will have. You can use either, but the second would be x... not 0x ... Pete

Where are you reading all this? If you a looking at the Log file and you don't understand something in it, show me it here. It is a text file after all. You can cut and paste text from it. The information i thought you'd find most useful was the NAMES of the controls being used, not some numbers! Why are you using "custom controls"? You were talking about FSX controls before. Perhaps you'd better start again, this i just all confused. Yes, as I told you yesterday! I cannot, not without you saying where you are reading and what you are doing! Pete

The current version, 5.14? Or the latest interim update 5.141e? Assignments in P3D? Or in FSUIPC? If in FSUIPC, via "Send direct to FSUIPC ..." or "Send to FS as normal axis"? And if the latter, to which controls? The "Axis elevator set" and "Axis aileron set" controls, or the "Elevator set" and "Aileron set" controls? And are you looking at page 1 of 11 in the calibration tab? I need these details to see if I can reproduce problem. Also, it would help if you could go through each "page" 1 to 11) of the Calibration tab display, just using the Set button on each to see which ones, if any display the Slope button. some shouldn't anyway (like flaps and reversers). Just press the SET button on the top left one on each page, note whether there's a "slope", then press "Reset" to return it to uncalibrated. no need to touch any other buttons. Thanks, Pete

I don't know. I'd need a lot more information for that, like version numbers 9flight sim and FSUIPC) to start with, and also the actual control being calibrated and how assigned (i.e. what to and where). Pete

Looking at the log, EVERY instance of Magneto1/4 was certainly triggered by the receipt of the indication 4 from the hardware. I assume the same is true for Magneto2, though the log indicates that at that time your mcro file didn't cover that. So in this case the DLL is only doing what is asked. A matter for PFC? Both Alt+ and Alt- macros are invoked correctly, so i think this is something to do with your aircraft. I'd need the FSUIPC logging to check that further. But I'd still like to know why you needed the macros as the default action should work. Test with a default aircraft as well please. As already said, without the crash log I can't do anything with this report. When there's a crash the crash data is ALWAYS needed. Get it from the Windows Event Viewer. (I have looked at the code for flaps, and there's precious little. And I looks like it hasn't been changed at all since first written let alone between 5.01 and 5.11). This is all I can do for now ... Pete