Pete Dowson

Test your switches with a default aircraft. It may be that Carenado don't obey the same standard controls. Maybe they need L:Var control. Did you check your switch programming using the Logging as I suggested? Is that programmed through FSUIPC too? But whether it is or not, see what is sent, again, using the FSUIPC logging. Not sure how it can stop Engine 1 controls operating on a single engine, which is engine 1 too. Pete

You have the log going to: C:\Users\filip\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache which may not be the best choice. Better to direct it to a moreeasily accessible folder, like the one you installed FSUIPC7 to? The FSUIPC log shows a session terminated normally when MSFS stopped running. This was after 2 hours 23 minutes of successful running. There's no indication of any problems at all during that time. It looks more and more like a problem you need to report to MS/Asobo -- but a proper SimConnect log might help -- though for that length of time the log would be ultra-huge, probably larger than any editor or viewer can cope with! Pete

I see these settings: 121=P5,13,C65929,0 -{MAGNETO1_LEFT}- 123=P5,14,C65928,0 -{MAGNETO1_RIGHT}- 122=P5,15,C65927,0 -{MAGNETO1_OFF}- 124=P5,12,C65930,0 -{MAGNETO1_BOTH}- 176=P5,11,C65931,0 -{MAGNETO1_START}- 83=P5,30,C65933,0 -{MAGNETO2_OFF}- 133=P5,28,C65935,0 -{MAGNETO2_LEFT}- 135=P5,27,C65936,0 -{MAGNETO2_BOTH}- 136=P5,29,C65934,0 -{MAGNETO2_RIGHT}- 174=P5,26,C65937,0 -{MAGNETO2_START}- Which seem okay, though I think you need the "Start" action with "Repeat while held" selected. That position is sprung to return to "Both" when released. You need to check that the correct controls are sent when you operate the switches. Enable button logging in FSUIPC the operate the Magneto switches from OFF to Start and check that the correct control is being sent. That's all FSUIPC can do. You can see the log entries in real time if you select the Console window on the logging tab. Note that on the light aircraft I use, the order of the positions is Off, Right, Left, Both, Start -- i.e left /right the other way around. Which aircraft have you been testing with? Pete

No, not really. Pete

How are you assigning these actions? You need to describe what you've done. Using controls, keystrokes, or what? Is it a multiway switch showing button presses for each position? Show us your FSUIPC6.INI file. Note that the 'Start' position is spring-loaded to return to 'Both', so that one has to be repeated until the engine starts.

You shouldn't need the Saitek drivers at all. They could be the problem. The Saitek yoke is a standard USB joystick and can be handled perfectly well by the default Windows drivers. Try uninstalling them altogether. Well the way the Joystick interface works, that should be impossible, as all aspects of the device are read together, as one data block -- buttons, axes and POVs! There's no way of separating them in the interface. I suppose it could be a hardware problem, though that is less likely. Is the USB port you are using a USB3 one? If so try changing the a USB2 port -- some devices do not work well with USB3. The only other thing is could be is a faulty connection somewhere, maybe inside the device. Pete

You seem to have done both at the same time -- changed the IDs and set it to assign joy letters. It was an either/or choice. I hope it isn't now even more of a mess. Please provide the new INI file, not just the one section. Note that I am out of the office now till tomorrow. If you want to help yourself to fix it, follow the logic I showed in my earlier reply to change the ID numbers, but now change them to the letters A to E. Pete

I don't suppose you have the original FSUIPC6.INI file, from before you ran P3D with the new install? That would make this more foolproof. As it is, these are the assignable devices: [JoyNames] AutoAssignLetters=No 0=Bravo Throttle Quadrant 0.GUID={DED29680-1723-11EC-8002-444553540000} 1=TCA Q-Eng 1&2 1.GUID={DED2BD90-1723-11EC-8004-444553540000} 2=Alpha Flight Controls 2.GUID={DEDD1DD0-1723-11EC-8007-444553540000} 3=T.A320 Pilot 3.GUID={DEDD6BF0-1723-11EC-800A-444553540000} 4=CH Pro Pedals USB Rudder Pedals 4.GUID={DEDDBA10-1723-11EC-800D-444553540000} whilst looking at some axis assignments: [Axes.Airbus] RangeRepeatRate=10 0=0X,256,D,1,0,0,0 -{ DIRECT: Aileron }- 1=0Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- 2=0R,256,F,66818,0,0,0 -{ TO SIM: STEERING_SET }- 3=0S,256,D,22,0,0,0 -{ DIRECT: Spoilers }- 4=1X,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 5=1Y,256,D,8,0,0,0 -{ DIRECT: RightBrake }- 6=1S,256,D,3,0,0,0 -{ DIRECT: Rudder }- 7=2X,256,D,9,0,0,0 -{ DIRECT: Throttle1 }- 8=2Y,256,D,10,0,0,0 -{ DIRECT: Throttle2 }- it appears that: * the joystick/yoke ID is now 2 (Alpha Flight controls), not 0. * the rudder ID is now 4 instead of 1 * the throttle quadrant ID is now 0 instead of 2. That leaves the TCA Q-Eng 1&2 (now 1) and the T.A320 Pilot (now 3). Looking further in the INI there are these axis assignments [Axes.747] 10=3X,256,D,1,0,0,0 -{ DIRECT: Aileron }- 11=3Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- Which implies the one of those two as yet determined devices is also a joystick or yoke. If the T.A320 Pilot is a sidestick then my earlier deduction is wrong, and these settings would be more correct: * the sidestick ID is now 3 (T.A320 Pilot), not 0. * the rudder ID is now 4 instead of 1 * the throttle quadrant ID is now 0 instead of 2. * the yoke ID is now 2 instead of 3. leaving just the TCA Q-Eng 1&2 which must have changed from 4 to 1. So I think the settings in [JoyNames] should now be: 2=Bravo Throttle Quadrant 2.GUID={DED29680-1723-11EC-8002-444553540000} 4=TCA Q-Eng 1&2 4.GUID={DED2BD90-1723-11EC-8004-444553540000} 3=Alpha Flight Controls 3.GUID={DEDD1DD0-1723-11EC-8007-444553540000} 0=T.A320 Pilot 0.GUID={DEDD6BF0-1723-11EC-800A-444553540000} 1=CH Pro Pedals USB Rudder Pedals 1.GUID={DEDDBA10-1723-11EC-800D-444553540000} Now you might be successful just changing those lines -- FSUIPC will try to force the ID change in the Registry. But this is not guaranteed. It is probably safer to change the AutoAssignLetters=No parameter to Yes, then run P3D, and afterwards edit the letters in the [JoyName] section instead of the numbers. Pete

You haven't supplied your FSUIPC6.INI and .LOG files, which are always necessary for us to help in such cases. I suspect that you hadn't taken advantage of the facility to assign by Joy Letters instead of ID numbers, but either way a fresh install of Windows and especially motherboard would result in the GUID numbers changing for all connected devices. Re-matching would be easy with Joy Letters, but it can be figured out in any case with the files you need to provide. Pete

No, that's okay -- it would only have been important if it hadn't worked. The SceneryList.txt proves it all okay. I'll release it properly over the weekend. Thanks, Pete

Yes, That should be okay. Pete

I said to enable Event logging, NOT all IPC reads and writes!!!! Please do read more carefully or it will be a waste of effort on my part! Sorry, I've no idea how SIOC does things. You need to ask SIOC people. Pete

As I said, I think Ctrl+E equates to Engine Auto Start. But yu can easily check that yourself using FSUIPC logging, as I also stated. You should refer to the Offsets Status document, as I said. 3110 is 8 bytes, not 4, with the parameter (in your case 1 or 2 for the engine) in the 2nd set of 4 bytes. It says you should write all 8 bytes together, but you can if you wish write the engine number first to 3114 then the control number to 3110. It is the latter which fires the control. Pete

Here is a test version of MakeRwys (5.128). Please try this. It attempts to fix the overlong pathnames problems by changing the current directory before scanning the BGL files. It is working okay here on both my MSFS setups. If this doesn't work then I think there must be something else wrong on your system. But it did all point to pathname length as the crash is occurring when procesing the longest pathname (as far as it gets). Please run it and let me know. I'd like to see the resulting SceneryList.txt (if one is produced) and the Runways.txt file. Please ZIP these as they will be quite large. Pete MakeRwys5128_Test.zip

No, not the registry, but the last line in the UserCfg.Opt file, found within the MSFS setup. For example, in my case the last line reads: InstalledPackagesPath "C:\Users\Pete\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages" That's what MakeRwys looks for to get the path. It is normally set when you install MSFS according to the location you choose at the time. I expect you could edit that to point to the link instead, but I've never tried it. But if you don't mind waiting a few more days, I am working on a version of MakeRwys which uses local paths, changing the "current" directory to the main part of the path first. As I said, it's a bit complicated and quite error prone, so after I've tested it here as much as I can I'll send you a version to test. Pete

They don't. Entirely separate interpreters are used. No. ALL of the functions documented in the FSUIPC Lua library document are local to FSUIPC (and mostly WideClient). They are additions to the standard libraries documented in the Lua.org documentation. I expect the P3D implementation includes some or all of those standard libraries. Pete

I thought PMDG were reputed to provide quite realistic aircraft implementations? Have you asked then for advice on this? The curves available in FSUIPC calibration offer extremes both ways. However, I'm not sure PMDG aircraft very much appreciate throttles calibrated by FSUIPC as the way that works bypasses the inputs the aircraft are looking for. If the PMDG parameters set for their aircraft are really so bad (I see you have that for elevator too) then I would have thought they would have fixed it by now. these things are probably adjustable in the Aircraft.CFG file, but I don't know enough about that. I suspect your best bet is to ask in the PMDG support forum. But first also check that your device is properly calibrated in Windows and, if assigned in FS, the sensitivity and null zones as set properly (max and min respectively). Pete

That is a settings (INI file) line to send Ctrl E on a button push. I thought you needed to work via Offsets? And why send the Keystroke? All Ctrl+E does in the sim is cause it to look at its key assignments list and fire off a CONTROL! You need to simply send the correct control with 1 or 2 as its parameter for the Engine. To do that via offsets please look at offset 3110 in the Offsets Status document provided with FSUIPC. To get the control number to be used you could enable Event Logging in FSUIPC then Press Ctrl+E and see what is logged. Or just look for autostart in the List of Controls document also provided. I think it's called "Engine Auto Start". Pete

I seem to recall that to keep the turbine turning you have to keep writing 1 to offset 0892 (etc). Else it reverts. But I wouldn't swear to that. You can of course use the 0D70 to send whichever control the CTRL+E sends. The choice of engine would be the parameter to go with it. Pete

I'm not too sure either as I've never had a call to use them. John knows about them, so I'll ask if he can help. I've had a look at possible changes in MakeRwys to use relative paths, but it's going to be very difficult, affecting so many different things -- so very error prone. I really don't understand what has changed since you used the same version ofMakeRwys separately. I'm sure it isn't a Windows update. Could you be now using different security settings or anti-virus programs? Pete

I have now updated Windows to 19043.1237, and still I have no problems. I'm sure it must be related to that registry item. Can you check again before I embark on rather complex (and possibly error-prone) MakeRwys modifications? Pete

Hmm. It is working here with the latest MSFS WU6 and Windows 19043.1165. I'll try updating to 1202 (or later?) to see if that makes any difference, but to be honest I'm perplexed. It is definitely related to long pathnames, but what the steps outlined in the Mcrosoft help on that don't help i don't understand. Did you try both suggestions? if not, please do try the other. Meanwhile i'll investigate whether I can "fiddle" it by changing "current directory" and using just the local path, or maybe automatically creating linked folders with shorter names. In fact you could try that manually. See https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/ A symbolic link to "C:\Users\David Hawxwell\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe" might work. Otherwise, the changes I would have to make to MakeRunways to use partial pathnames are rather complex, as the files it generates go locally. I'll have to "tread carefully". So it may take a week or so before I have anything to test for you, but I'll definitely take a look at this. Pete

Thanks. This is identical to a problem reported in the Pilot2ATC forum on AVSIM. The problem is that your Windows 10 (I assume?) appears not to have long pathnames allowed. The normal maximum is 260 characters, but this restriction can be overridden by using the \\?\ prefix. You'll see that in the list of folders to be scanned in your Runways.txt file. I'll reproduce my answer given to that other user. If this turns out to be a common occurrence I will probably have to add this advice to the documentation. ---------------------------------- From Windows documents I'd assumed the \\?\ prefix would work no matter which build of Windows is being used -- it was okay on three different versions on PC's I have. However, comparing the last line logged on your system with the file generated on mine, the very next line which should have been logged would show a pathname longer than 260 (discounting the "" envelope, which isn't used in the actual windows calls). And that's the first path longer than 260, at just 261 characters! Perhaps I should log also the version and build number of the Windows version in use. But could you tell me (use WinVer) please? And maybe try to update. Using Google I have found this: 4.3 Enabling Windows Long Path (Windows 10 - 1803 build) Click Window key and type gpedit. msc, then press the Enter key. ... Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem. Double click Enable NTFS long paths. Select Enabled, then click OK. Could you try that please? There's also a way of editing the Registry instead. See https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/ Let me know please. Pete

So it isn't displaying the actual values in the Sim, is it? Seems little point. Surely when you are using the proper software with it, it is that which changes the displays? Otherwise how are the displays changing differently with FSUIPC running -- after all, all FSUIPC is doing is receiving the button presses from the encoders. It isn't sending anything back unless you've added something like LINDA or your own Lua plug-ins to update the displays. No. It doesn't know what to send or how without additional software. I'm sorry, I can't really help then. It was all designed to work the way it is documented. And that was many years ago. In all that time we've not had any other folks reported the problems you seem to have, but then I expect they are following the documentation. Pete

And what does that say (the clue will likely be in there)? What has changed since it worked for you? Have you added scenery to MSFS since then? And what exactly is this "windows user account control box"? Don't forget -- you must run it "as administrator", otherwise it probably won't be able to access the scenery files (depending how you installed MSFS). Pete