Pete Dowson

Surely with ProSim, it is ProSim's FDS driver which controls the device? FSUIPC wouldn't see it if so. I don't know FDS devices -- does Windows see the MIP as a joystick type device? Seems unlikely unless FDS supply a driver to emulate such. Questions about ProSim, which I think this boils down to, are best dealt with on ProSim's own forum. Pete

Prosim has a facility to log inputs it detects. FSUIPC has a lot of logging facilities. But you need to be specific on "the things" which you think are supposed to talk between Prosim/FSUIIPC/Prepar3D. Most of the 737 controls are operated by Prosim -- it simulates the entire cockpit, and all of your controls and switches need to be assigned (and calibrated) in Prosim. PMDG's aircraft have their own cockpit. You use Prosim OR PMDG. You can't use one with the other. That would make no sense. I think you need to be using the Prosim support forum to resolve any problems you have with Prosim. FSUIPC really has little to do with it unless you are setting Prosim into FSUIPC mode -- you should start off using it's SimConnect mode in any case. AND the aircraft model supplied with Prosim, of course. Pete

Controls for Prosim need to be assigned in Prosim. As your FSUIPC is unregistered it is not even looking at the controls. In fact it is doing little except supporting requests from other programs, including Prosim if so configured. You really need Prosim set to SimConnect mode, not FSUIPC mode, unless you plan to purchase FSUIPC and register it. Pete

Here's a version of MakeRunways for testing (5.132). It ignores airport records with an ICAO Id or more than 4 characters. For each one so ignored a message will be seen in the Log ("Runways.txt"). Please try it and let us know. Perhaps you can ZIP up the log (Runways.txt) and send it for me to check. If even the Zipped file is too big, maybe at least show portions flagging ignored entries or any problems you see. Thanks, Pete MakeRwysTEST_5132.zip

I think the problem arises because CAD54 is not a valid ICAO ID. The ICAO system of IDs only allows 4 characters. It looks like MakeRunways is only comparing with the first 4 characters, CAD5. When I get the time I'll have a look to see how easy it is to program around. I'll probably simply ignore (bypass) all entries with more than 4 character IDs. I don't know if this will eliminate anything significant -- perhaps you can tell me? I fear the changes which would be needed to deal with >4 character IDs 'properly' would be more work, and more complicated, than I am willing to tackle. Pete

Take a look at the log ("Runways.txt"). That shows everything it did (and tried to do). You should download the latest Makerunways release too -- yours appears to date beck to 2017! Except with MSFS you should run MakeRwys in the main FS root folder -- the one with the sim's EXE file. And you need the Lorby export program there too -- it is included in the downloadable ZIP. The "scenery.cfg" file is obtained from where it is maintained by FS, and the Lorby program adds whever might be added in Add-on files. Pete

I assume so. If you look at the Deletion lines in the MakeRwys log file (Runwats.txt) if think that's the only likely one. Pete

Prosim supplies their own 737 model. It isn't compatible with others. This is nothing to do with FSUIPC -- you evidently have scenery and aircraft conflicts. Use the Prosim aircraft with Prosim. Try to fix your scenery by eliminating each of your add-ons one by one till you find the culprits. Please also note that FSUIPC3 is no longer supported -- for a long time now! Maybe your Prosim is too, out of support. Pete

You don't. With Prosim you should assign all axes in Prosim itself. Probably this wasn't so important in Version 1 of Prosim -- I don't remember, it was so long ago (it has developed apace since then) -- so if you want to assign in FSUIPC then both Captain and FO toe brakes are assigned to the same single toe brake axis. Same with all the other flight controls. For proper advice on configuring Prosim, whether via FSUIPC or not, you should us the Prosim forums. Pete

You are the only user so far with such a problem. Evidently something went wrong during MSFS's original installation, as it should find it no matter whether it is in Admin or not. Are you running it "as administrator", as instructed? MakeRwys finds MSFS by looking for "UserCfg.opt", which should be in one of these places: %LOCALAPPDATA%\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache or (for the Steam version): %APPDATA%\Microsoft Flight Simulator". so your %APPDATA% system variable appears to be C:\Users\Admin\AppData\Roaming. Try entering %APPDATA% is the Start search entry and see where it takes you. Mine takes me to C:\Users\Pete\AppData\Roaming. If yours doesn't take you to the correct place then something is screwed up in Windows. Development of MakeRunways has long terminated, and the program source made available for any programmer wishing to take it up. I am retired and I now have no way to delve into what could be going wrong for you. I can only offer two ideas: 1. Uninstall MSFS and re-install it. But first: 2. Try placing MakeRwys.exe into whichever of those places where UserCfg.opt is placed, and run it with /LOCAL as a parameter, in Admin mode of course. Pete

ICAO codes are 4 characters. The airport indices I have don't even have any starting BW yet alone BW314. Seems like a fictional airport (?), but they should still keep to 4 characters. Most software, including everything likely to use MakeRwys data, will only deal with 4 characters. Note that, in any case, the BGL format allows one DWORD (4 bytes) only for the ICAO ident. -- see for instance Page 8 in the FSDeveloper Wiki for MSFS BGL formats. BGL File Format - FSDeveloper Wiki.pdf Pete

No one else so far. There are no changes in the BGL layouts and format between 5.4 and previous versions. I am using it on 5.4 with no problems, so it sounds like a corruption in the scenery installation. But you are using an older version of MakeRunways (4.90). The latest is 5.13, so please try that first -- download it from FSUIPC.com, or from the Download Links subforum above. I need to see this file to help further: E:\Lockheed Martin\Prepar3D v5\MakeRwys_Scenery.cfg Pete

So, what did you change in between? We need to see the log -- the "Runways.txt" file in the MakeRwys folder. That will likely show the reason. Pete

No, they aren't related to the radar image. As I have said several times, the Radar.bin file is just an array of cloud vapour density values. These other values are just made available via FSUIPC's offset memory. As I said elsewhere, the radar data is provided by a Call Back for the DLL, set by a parameter for the SetRdrarams function, which has this definition: void (*pSetRdrParams)(long aircraftHeading, long range1, float tilt1, long range2, float tilt2, RadarDataComplete callBack, void *pContext, long optionsFlag) = 0; The CallBack function is defined like this: typedef void (CALLBACK *RadarDataComplete)(long rdrSmallDimSize, void* rdrData, void* pContext); However, the Active Sky DLL is meant to be run inside P3D (like FSUIPC). I wouldn't have thought it worked outside. But surely you should have all the information you need in any case -- didn't you say you had the AS API? Pete

Not a file, just an in-memory array provided via a callback set up via one of the exported functions of the Active Sky DLL which, like FSUIPC, is also running within P3D. The size and scale of the array is set beforehand by calling other exported functions. I've really no idea what Active Sky provide on MSFS whereby ProSim gets such data. Pete

Yes, the Radar.bin file is a copy of the data received from Active Sky -- a matrix of bytes with cloud density as a binary value, and with the current aircraft position being represented by the centre of the base line. The scale is based on the range and settings in the request for the data. But FSUIPC will also turn this into an BMP Image file on request by a line such as ASNwxRadarBitmapPath=C:\WXradar.bmp. HiFi Simulations will provide documentation for developers wishing to take advantage of the data. Maybe you can ask them for the information. I don't feel right providing their documentation to you directly (even if I could still find it!) Pete

I don't have a KBOS add-on airport, but it certainly works for all my add-on European airports. For example, here's an extract from G5.CSV for my P3D Justsim Brussels (EBBR): EBBR,R,149,50.902452,4.484660,21.0,335.4,8,,BRU EBBR,R,153,50.902775,4.485776,21.0,335.4,8,,BRU EBBR,R,157,50.903101,4.486890,21.0,335.4,8,,SAS,GWI,AUA,DLH EBBR,R,165,50.903815,4.489376,21.0,335.4,8,,SAS,GWI,AUA,DLH EBBR,R,169,50.904106,4.490519,21.0,335.4,8,,SAS,GWI,AUA,DLH EBBR,R,205,50.899189,4.486295,21.0,335.4,8,,ICE,TUI EBBR,R,211,50.899644,4.487884,21.0,335.4,8,,ICE,TUI EBBR,R,217,50.899947,4.488936,21.0,335.4,8,,ICE,TUI Not that I think the BGL format has changed in this regard, but I belatedly noticed you are talking about MSFS, not FSX or P3D. I've never had any add-on airports for MSFS so I'm not aware of any changes made in this area. I'm afraid I am unable to undertake any more development of MakeRwys, whether for P3D or MSFS. I am now fully retired. But if you are a C/C++ programmer and are able to delve into MSFS scenery file formats, I expect we could arrange for you to adapt it yourself -- provided the results remained freeware. Note that I still don't think Pilot2ATC uses this information in any case. Pete

Yes. Airlines are listed at the end of each Gate entry in the G5.CSV file. Default airports don't have any, and nor do all add-on airports. You can look at that file in any text editor to check. I don't think Pilot2ATC uses this information however. Best to ask Dave on the P2A support forum. Pete

It shouldn't need assigning as it is the default action. As to the button changing how the hardware functions, that certainly doesn't seem right to me and why I suggested you need PFC tech support. They are just the frequencies which were set last time you closed the Sim, recorded for restoring next time. Convert to hexadecimal to see. eg NAv1 5008 => 1390, giving 113.90 as the frequency. (The Sim stores them without the leading 1). sb = standby, na -= active. I don't remember what xsb means. I wrote this software in 1999, i.e 24 years ago. I don't know why I'm even still supporting it -- there was no income generated, only hardware on loan (just to test it with) and a discount to purchase. And now I am almost 80 years old and retired it is really not in my capability to support it to the level you need. I know PFC switched their support to X-Plane, and are no longer interested in the FS series nor P3D. Sorry. Pete

Because the frequency being set was written to the Standby, and the Swap does its job. Which implies that the Swap button isn't doing the right thing, as you seemed to be saying and what I am calling odd. As it says in the PFC DLL documentation: Note: All of the avionics buttons, knobs and switches can be re-programmed in FSUIPC’s “Buttons” section when using FSUIPC version 3.30 or later. See the section about Button and Switch Re-programming later in this document. So you could program it there. You'd probably need a small Lua plug-in. For a swap just copy the ADF standby offset to the ADF active offset. Pete

The PFC units produced for Elite use a different protocol, proprietary to Elite. You need an Elite driver for them. Our PFC drivers cannot work with that protocol. Maybe PFC will (for a fee) change the units over to PFC protocol. Pete

Sorry, I have no idea about that. The PFC module simply uses FSUIPC to execute the macro, so it should be the same as when they are executed there. Maybe John can help with that. He's away today. Pete

The PFC thing which seems to be wrong is that the ADF swap button changes how the unit functions. It should simply swap between Active and Standby. Pete

They aren't listed as part of the name -- see the supplied MacroIndex.csv file for the names. The "full name" to which you refer are the programmable names, internal to the code. FPFCcom64 uses the abbreviations as listed in the CSV. Because you programmed it that way, here: 13=Cdi=C66375,0 -{TOGGLE_GPS_DRIVES_NAV1}- Sorry, I know nothing about Mobiflight. Perhaps they have a support forum? Pete

Sorry, I don't know what is going on with your ADF. I had exactly the same stack (except all one unit rather than identifying separately), and the ADF swap functioned fine without changing how the unit worked. Are you sure that isn't a malfunction? You probably need to check with PFC tech support. Pete