Pete Dowson

I don't know the Pro 2, so couldn't swear that all of its switches and functions are supported in the PFChid driver. Do PFC supply a driver for XPlane? I know they changed focus to XPlane, away from MS, some time back. Which manual is that? The manual supplied with PFChid certainly doesn't. It will be loaded and run by FSUIPC automatically after the Sim is in a "ready to fly" state. On the Cirrus I seem to remember that the Yoke is a normal joystick device and seen by Windows and the Sim, not needing any attention from a driver. The rest of the functions on the Cirrus do need a registered FSUIPC and then you can assign switches and quadrant levers as desired. A log is produced (PFChid64.LOG) when the driver starts. This will be is the same folder -- check for it. Pete

Not a direct thread link, just The reference to an ActiveSky workaround in the Prosim forum.

Hi John, That’s good news, but I wasn’t aware ActiveSky had such specific support for MSFS. Last I knew, Damian declined to do anything whilst MSFS had such a closed weather control interface. I shall need to refer to the thread the OP referenced, to see what the ‘workaround’ is.

The point is you assign an offset in Prosim, not a control axis. It’s one of the options for every control axis. If your controls are true axes then you can assign them in FSUIPC to a user offset, and use that in Prosim. Pete

1 comes as a big surprise, as the cloud map from P3D used for the radar is part of the complete weather system supported by P3D but not, as far as I know, by MSFS. In P3D, Activesky needs a module running in the P3D process to obtain this data. I did not know that HiFi simulations had now produced a version specifically for MSFS. Seems I should send congratulations to Damian if so. Otherwise the map will be of the cloud positions intended by ActiveSky but not actually achievable with MSFS. They may show approximations but not in any sense accurate enough for navigation. In P3D the radar actually shows when you are in one of the rain clouds or can see one ahead. On 2, I am saying you can use Prosim In SimConnect mode via FSUIPC offsets for controls. I’ve got no more to say on this really, so I shall butt out now. Pete

I don’t know how 1 can be right, unless MSFS now provides the data. It didn’t when I last looked. For 2, I have used Simconnect mode with almost all my controls coming from PFC devices through FSUIPC. You only need to make the assignments in Prosim, specifying the offsets correctly. Prosim only overrides assignments made to the sim controls themselves. Pete

But, as I said: 1) I don't think the weather radar so produced is of any real use in relation to the simulation in MSFS. 2) You can use SimConnect mode for inputs whether from FSUIPC or elsewhere. The SimConnect/FSUIPC mode selection in Prosim is to do with how Prosim controls the Sim, not the inputs . Pete

I use Prosim too, in FSUIPC mode, but I think the FSUIPC/SimConnect choice is only concerned with how it controls FS/MSFS, nothing to do with inputs. I only use FSUIPC mode because of some problems I have otherwise with trims. As I said, I can't see how any radar image from ActiveSky is going to be of use in MSFS because it really has no control over the cloud placement. BTW I saw that the latest Prosim update (3.23B2) lists separate Tiller/ Rudder in its change list. Pete

Although ActiveSky will run for MSFS, I don't think it is able to control the weather, and it certainly isn't able to create a usable rain cloud map! Pete

Sorry, I don't know. That's really a question for MSFS support, or possibly specifically for the authors of the flight model you are using. I'm a P3D user, but I don't know how the nose wheel turns in that, either, because when the aircraft is moving I'm always in the cockpit. Pete

You can use any of the offsets in the PFC list for any axis, and just assign it however you like in FSUIPC. The annotated usage in the list is just how PFC COM devices are added. With the regular axis controls, assigned in FSUIPC, it is up to MSFS and the flight model what happens. The regular controls are AXIS_STEERING_SET and AXIS_RUDDER_SET. Have you used those? Pete

I've only just noticed this, and I can add something. If SIOC scripts can write to FSUIPC offsets (which I think they can), then an alternative, without vJoy, is by writing to one of the offsets originally designed for PFC COM devices: 3BA8 to 3BC4. See the FSUIPC Offsets Status document for details. Pete

Sounds like MS has messed up the language files providing this data. Sorry, but I'm not able to maintain MakeRwys these days. I've offered the source to anyone (needs to know C/C++) who wishes to take it on, but I have fully retired from programming. Pete

I managed to look at it this morning. First, some questions about the files you posted: Neither WideClient..LOG actually shows a crash -- they both show a normal shutdown requested by the server (the Sim). They also show you were using UDP, not TCP. So, does this mean you changed to UDP and then got no further crashes? The Windows error event shows that crash occurred on the 5th, but both LOGs are for the 4th. So, did you change back to TCP on the 5th? Both logs show block sequencing errors occurring. That is a typical symptom of a bad connection. Running on UDP means blocks can go missing as there is no checking -- the error logged by WideClient is through its own checks built into its data formats. Confirming that the problem appears to be purely down to a bad connection, the Windows event crash location is within either the select_open or tcp_open function in the Windows network package. It is not in WideClient code which I have any control over. MY TESTS I set up an FSX-SE session on my laptop (a Microsoft Surface running an up-to-date Win10). WideClient was running on my main development PC. If I could induce your crash this would enable me to use the Debugging facilities in Visual Studio. This PC is also running an up-to-date Win10. I was running with TCP protocol, and let it run for an hour whilst manipulating controls in FSX-SE which would result in highlighted entries showing in your WND-based window. It is still running now, and shows no sign of any errors -- and the log is clear of block sequence errors (as I would expect when using TCP, or when using UDP with a good reliable connection. So, I'm sorry, but I can't see there's anything I can do. You might need to try to improve your Wifi setup. Pete

Thanks. That's much more informative! Pete

Thank you. I notice there's no Windows crash log -- does that mean one was not produced? It won't be till Monday that I can get to this again. Pete

See this paragraph in the first section of the WideFS documentation entitled Configure your Network: The Server automatically operates with any clients which connect, whether they be using TCP, UDP or SPX. You can mix them, to suit the specific individual client PCs. Better, leave the protocol choice out of the Client INI file altogether and just use “ProtocolPreferred= …” in the Server INI to select your choice. Details of these parameters are given below. Hmm. I'm not at all sure that IPX/SPX is supported anymore. When it was removed from Windows the code became somewhat redundant and an unnecessary complication. On this: I would make these comments: * There's no relation between any function in the WND library and the Network connection, so the crash must be related to something else in your Lua script. * There's no way WideFS even knows whether you are using Wifi or a wired connection. There may be a way to determine this, but as there's no need to know I've never investigated it. The code is just Network code. So, I need more information to investigate this: 1. The Lua file which generates the problem 2. The full WideServer and WideClient LOGs at the time of the crash. 3. If one exists, the WideClient crash details from the Windows Event Viewer. I can test here with a Wifi connection, but I need the exact Lua code which leads to the error. I also need you to be using the latest (current) version of WideClient (7.160) so the addresses etc match. Thanks Pete

Sorry, I have no plans to further update MakeRunways. I am now fully retired. I can share the code, convoluted as it has become, with any C / C++ programmer wishing to take it on, with the only condition that is shall remain freeware. Pete

The Delta value, in the Axis assignment options, determines the minimum change which will be used. It defaults to 256 which, for a Windows calibrated axis (-16k to +16k) gives 128 steps. You can reduce the Delta value if you wish (read the description of this value in the User Guide first). The PFC throttle quadrant I have (a very early COM-based one, not recognised by Windows) used axes with 0nly a range of 0-127 at best. They work fine for me. But perhaps PFC have improved the pots they use by now. The same low res pots were used in their flight controls (rudder, aileron, elevator, tiller) but I had those replaced by higher resolution ones and connected them via Bodnar USB boards. Pete

Hi Pelle, My MSFS is woefully out of date, from disuse for a long time. So could you please show me the relevant part of RUNWAYS.TXT and ZIP and attach the runways.xml. Thanks, Pete

They are files to be read by whatever program it is that you used MakeRunways for. Normally you leave the files where they are and point that program to that location. If you aren't using a program which asked for MakeRunways, then why did you run it? Pete

Without registration, FSUIPC is merely receiving stuff from SimConnect and writing stuff back at the request of application programs using it. Therefore the problem must either be a corrupted FSX, affecting the SimConnect interface, or, possibly more likely, a misbehaving application. You can check for the latter by trying with no FSUIPC applications running at all. for the former, do a re-install of FSX. BTW If FSX is crashing, why are you not showing us the Windows crash report (from the Event Viewer)? Pete

Well, yes. But all of the default taxiways are deleted explicitly. I don't know why MakeRwys only gets one path with a name -- there are evidently more names than the one it sees. It maybe that the other named parts don't actually join up. I downloaded the add-on and tried analysing it using the well-respected Aircport Design Editor (ADE) but it didn't even find any airport records, giving a failure I don't understand. I'll try to trace through MakeRwys to see why no other named taxiways are found, but I'm not sure when I can do it or even if I'll be able to -- I retired because my coding and debugging abilities were deteriorating fast as I aged (I'm 79). I suggest the best course for you is to run MakeRwys whilst the add-on is disabled (as I suggested) and use the results it produces before re-enabling the add-on. Pete

The "EFHK only" section of the Runways.txt file you provided is for the default EFHK scenery, not the add-on: Official\Steam\fs-base-genericairports\scenery\0601\APX54100.bgl Search down further in the file for the add-on EFHK. It'll be near the end, with any other add-on sceneries. I suspect that the add-on is deleting most of the default and not replacing it. The file will show. Try disabling the add-on EFHK and see if MakeRwys then generates the file correctly for you. I think it will. Pete

That's fine -- with Version 2 it was also recommended, but not mandatory, to assign and calibrate all the main aircraft control axes in Prosim itself. Those facilities are actually mostly unchanged in V3. Yes, I think so. But by all means ask on the Prosim forum. Pete