[fsuipc switch allocation]

31 minutes ago, rodder47 said:

I am using the Beechcraft Baron 58 by Carenado. the mag switches on this a/c are OFF/R/L/Both/Start same as the one you use.  It seems strange. 

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?

Quote

The Saitek Switch panel  works fine and in the correct order, but unfortunately only for multi engines, not individual..

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

 

 

[CTD at touchdown]

6 minutes ago, Filipe Spring said:

So... CTD happened again. No SimConnect%01u.Log has been created unfortunately. The .ini file doesn't seem to create anything..

 

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

 

[fsuipc switch allocation]

9 hours ago, rodder47 said:

I use Leo Bodnar boards, BBI 32 & BU0836X. I assign the switch actions using FSUIPC / buttons/switches section and using the preset items listed there. The two switches are 12 position switches but blocked to use only 5 positions. As stated above I have allocated each position on the switch using the preset items found under buttons/switches in FSUIPC.

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

 

 

[FSUIPC4: Yoke 'disconnecting' from FSUIPC randomly]

5 hours ago, viking88 said:

I reset them all and OK except Pitch2 which kept  returning to zero no matter where set, then after several clearing it and resetting it was OK.  Could this be the sim? 

No, not really.

Pete

 

[fsuipc switch allocation]

7 hours ago, rodder47 said:

I am using P3D v 5.1 I want to be able to control the mag/start switches for 2 engines. I can set each switch in fsuipc as follows : mag off/mag R/mag L/mag both/Start...  When I try to use the switch it goes from OFF/R/Both... thats it. It bypasses mag L and will not go to Start. IF I change the mags from L / R  order and try the switch it goes OFF/L/Both and no start  ???  How do I fix this ?

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.

 

 

[FSUIPC4: Yoke 'disconnecting' from FSUIPC randomly]

16 hours ago, viking88 said:

I then unchecked all the power management boxes in Devices and it seemed to do the trick.  Then sometime between checking the operation of the elevator and ailerons at engine start and taking off, the yoke disconnected from FSUIPC.  I was unable to reconnect and the power management boxes are unchecked.  The only way connection with FSUIPC was restored was by upadating the Saitek Yoke drivers.  I have had to do this several times now and it seems random.

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.

Quote

The yoke buttons (flaps. trim) work perfectly

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

 

[v4 to v5 transfer with hardware change]

3 minutes ago, Swissdani said:

I do indeed not have the original ini file with the fresh install, just overwrote ist.

I changed now the JoyNames as suggested by you and yes the T.320 is the Thrustmaster airbus stick. The result after loading the sim is now:

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

 

[v4 to v5 transfer with hardware change]

 

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

 

[v4 to v5 transfer with hardware change]

17 minutes ago, Swissdani said:

Any way to get my old profile back to work without having to assign everything again?

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

 

[Make Rwys not running]

5 hours ago, Tigerhawk said:

Runways.txt is too big to attach, even after zipping (67.3mb), I've attached the scenery list. I Could send you a OneDrive link for runways.txt if you need to see it?

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

 

[CTRL+E+1/2 offset creation (FSX / FSUIPC4)]

47 minutes ago, NicHer said:

1.turn the switch physically,

2.sw registers this movement and sends fsuipc on offset 3114 parameter 1 (if we are discussing ENG1) ,

3. sw sends fsuipc on offset 3310 parameter 66224.

Does anything look wrong in this approach? 

Yes, That should be okay.

Pete

 

[CTRL+E+1/2 offset creation (FSX / FSUIPC4)]

20 minutes ago, NicHer said:

Yes I explored this option (all IPC read and writes activated). It showed 100s of lines of offsets over 10 seconds. I was unable to narrow down exactly which line showed the starter switch movement. I would be pleased to send this log to you for an experts perusal, but perhaps a more efficient way is to just try it. 

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!

21 minutes ago, NicHer said:

I appreciate SIOC is not your SW, but should you be in a position to peruse it and see if to you it makes sense I would greatly appreciate it. In essence, we turn the switch physically, then sioc sends fsuipc on offset 3114 parameter 1 (if we are discussing ENG1) , then on offset 3310 parameter 66224.

Sorry, I've no idea how SIOC does things. You need to ask SIOC people.

Pete

 

[CTRL+E+1/2 offset creation (FSX / FSUIPC4)]

48 minutes ago, NicHer said:

Thank you for your response. 

CONTROL NUMBERS

I have found the following control numbers, could you kindly identify which would be most appropriate? For me, it would be toggle starter 1 and toggle starter 2 , but perhaps you see it differently? I am mindful you talk of using parameter 1 to show the SW what engine we are talking about.

ENGINE AUTO START 66224

JET STARTER 65572

TOGGLE ALL STARTERS 66304

TOGGLE STARTER1 66300

TOGGLE STARTER2 66301

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.

51 minutes ago, NicHer said:

I am mindful of your words "FSUIPC will fire the control when you write to 3110" and "You write the control number there as a 32-bit integer (i.e. length 4 bytes)" found on other threads.

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

 

[Make Rwys not running]

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

[Make Rwys not running]

6 hours ago, Tigerhawk said:

But what I don't understand is what type of link I need, nor how MakeRwys would then use the "D/New Link" rather than the original as I assume MakeRwys gets the location of MSFS from the Windows registry.

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

 

[P3D Lua imbeded in XML gauges]

3 hours ago, DrDave- said:

I am not familiar with where the Lua compiler and execute does its buiness and how FSUIPC Lua and the P3D Lua may interact, if at all.

They don't. Entirely separate interpreters are used.

3 hours ago, DrDave- said:

Are functions universal? Could I execute a FSUIPC function (e.g. ipc.xxxxx) in an XML and would Lua recognize it assuming P3D uses the universal Lua package?

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

 

[Small movement of joystick throttle should give large movement of aircraft throttle]

1 hour ago, draci said:

In the PMDG747 I realise that I need to move the joystick throttle unrealistically far forward until the aircraft starts moving,

I thought PMDG were reputed to provide quite realistic aircraft implementations? Have you asked then for advice on this?

1 hour ago, draci said:

I would like to get the effect that a small movement of the joystick  throttle on the lower end of the axis corresponds to a larger movement of the PMDG747 throttle. I imagine that I can do that by simply creating a suitable sensitivity curve (is there another way?) but somehow I haven't been very successful so far.

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

 

[CTRL+E+1/2 offset creation (FSX / FSUIPC4)]

51 minutes ago, NicHer said:

Thank you for your response. Working from page 20 on your advanced users guide, could you kindly confirm this is correct ascii code for for CTRL+E? I then write the parameter as 1 or 2 depending on the engine to be started as you say.  

P1,3,K69,2 (ctrl plus e)

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

 

 

 

 

[CTRL+E+1/2 offset creation (FSX / FSUIPC4)]

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.

6 hours ago, NicHer said:

Then I found that if i try to start the engines using the FSX default CTRL+E solution they spool to 25 percent - which is exactly what I want. After 25pc i could then introduce fuel. 

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

 

[Make Rwys not running]

1 hour ago, Tigerhawk said:

I've had a look at the symbolic link instructions.  I don't know if I'm being dense, but I'm afraid I haven't a clue how to do this to enable MakeRwys to use the link, or even how to even create the link or which type!

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

 

[Make Rwys not running]

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

 

[Make Rwys not running]

1 hour ago, Tigerhawk said:

I am on Windows 10 Pro - build 19043.1202

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

 

[Make Rwys not running]

8 hours ago, Tigerhawk said:

Hope this helps.

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)

1. Click Window key and type gpedit. msc, then press the Enter key. ...
2. Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem.
3. Double click Enable NTFS long paths.
4. 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

 

[VrInsight Combo with FSUIPC]

5 hours ago, MarkStallen said:

f you just put it on with no other software at all and you turn for instance the heading button, then the display is showing 001 to 359 degrees without sudden movements. It does that on its own, without getting inputs of other programs. It's in the hardware of the Combo.

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.

5 hours ago, MarkStallen said:

So the question is: does FSUIPC send things to the combo without any LUA -scripting or assignements to the combo?

No. It doesn't know what to send or how without additional software.

5 hours ago, MarkStallen said:

I don't use VriSim or SerialFP2. I don't need them.

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

 

[Make Rwys not running]

10 hours ago, Tigerhawk said:

The only file generated in the MakeRwys folder is the Runways.txt file.

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