Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    168

Posts posted by Pete Dowson

  1. 8 hours ago, 73MAX said:

    PROSIM 738MAX Suite
    FSUIPC Paid 

    I Have a FDS MIP an and when i go into FSUPIC to say Buttons & Switches, FSUIPC doesn't recognize the button presses on my MIP?

    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

     

     

  2. 15 hours ago, neil-uk said:

    Is there some kind of test I can run to make sure everything is talking to eachother?

    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

     

  3. 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

     

  4. 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

    • Like 1
  5. 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

     

     

     

  6. 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

     

  7. 18 hours ago, bcarson said:

    I am trying to determine how parking spots are removed from stock airport data when a new addon airport is modifying an afcad file. I use ADE to modify airports. When removing or relocating a Gate,  The resultant afcad bgl/xml is correct, however looking at the bglcomp documentation and FSDeveloper forum bgl file format  information,  I can't find in the BGL format or xml file how it indicates to delete the stock airport parking spots.  The <DeleteAirport    has a deleteAllTaxiways="TRUE" ... />    just says deletes taxiways.....

    Makerwys   is indeed omitting the stock parking spots/gates,  but I couldn't find anything in fsdevelper or p3d doc that eludes to the specifics of what is actually included in that deleteAllTaxiways

    Is it fair to assume that since a parking spot ( GATE, PARKING, etc) is specified as TaxiwayParking,  that the deleteAllTaxiways  will include taxiways, taxiwaypaths, and taxiwayparking

    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

     

  8. 16 hours ago, khalfaoui patrick said:

    In addition I have a home cockpit with PROSIM 737 

    My planes are IFLY 738 739 AND 747 IFLY 

    Prosim supplies their own 737 model. It isn't compatible with others.

    16 hours ago, khalfaoui patrick said:

    After having flown with the 747 I close the pc with an update. 

    The next day I fly 737 again and my nd pfd fmc are black I changed, returned FSUIPC with my codes, those you provided nothing to do, and I also have the wheels that are half sunk in the ground.

    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

     

  9. 14 hours ago, sludgypilot said:

    How do you assign toes brakes in p3d v3 with pro sim V1 for the capt and first officer?  Fsuip only show axis setup up for one?  thanks

    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

     

  10. 21 hours ago, Mike Franklin said:

    How do I get the program to look in the right place?

    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

     

  11. 20 hours ago, JoeFremont said:

    The problem I found is that for the above airport, MSFS reports its ICAO code as BW314 but in the runways.xml file its reported as BW31, I did verify that I am using the latest version (5.13)

    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

     

  12. 13 hours ago, SWA4420 said:

    Hi - I just updated to P3D v5.4, and could not run makerunways....here is the log - 

    Anyone else report this access violation problem?

     

    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

     

  13. 14 hours ago, Egyptair said:

    John, as far as I have understood, the result of these 5 variables are written into the bin file:

    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

     

  14. 18 hours ago, Egyptair said:

    Then I will get in touch with them and hope, they can provide me with the information about the file

    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

     

     

  15. 1 hour ago, Egyptair said:

    I mean the file, which is created by fsuipc, when you have ASNwxRadarPath=c:\radar.bin set .

    I thought, this file (radar.bin) is a matrix or something like that.

    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

     

  16. 21 hours ago, Fiorentoni said:

    It doesn't seem to work (latest version 5.13). I am absolutely positive that many of my airports have airline codes assigned in the .bgl, I even double checked in the sim (e.g. FlyTampa  KBOS or Aerosofts EDDB). Still none of these airline codes get read by MakeRwys, the g5.csv has no airline assignments at all, nowhere. Can you check if it works for you?

    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

     

     

     

     

  17. 42 minutes ago, Fiorentoni said:

    Does MakeRwys read airline gate assignments from the .bgls? I imported some bigger airports (3rd party, definitely have gate assignments set) for testing into P2ATC, and while everything else was imported correctly, airline gate assignments were not.

    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

     

  18. 19 hours ago, zfehr said:

    But I have tried assigning the swap frequency command to the button on the hardware and in doing so many of the hardware functions no longer work correctly for the ADF in the radio stack.

    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.

    19 hours ago, zfehr said:

    In the PFCCom64.ini file I see entries for COM, NAV, and ADF1 ADF2 with alpha-numeric codes. Do those have anything to do with how FSUIPC sends their function to the sim?

    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

     

  19. 13 minutes ago, zfehr said:

    The COM and NAV radios function correctly sending the frequency to the active frequency in the sim when you press the swap button

    Because the frequency being set was written to the Standby, and the Swap does its job.

    13 minutes ago, zfehr said:

    It is just the ADF that sends to standby in the sim unless the radio in the sim doesn't have a standby frequency feature in it.

    Which implies that the Swap button isn't doing the right thing, as you seemed to be saying and what I am calling odd.

    13 minutes ago, zfehr said:

    Is there a choice in the programming that allows one to choose between the ADF hardware sending to the active or standby?

    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

     

  20. 1 hour ago, zfehr said:

    I copied and pasted the commands from my FSUIPC.ini file into the PFC.MCRO file. Those commands work in FSUIPC but do not seem to in PFChid64. Is there another way to input the commands so they will work?

    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

     

  21. 16 minutes ago, zfehr said:

    The problem only seems to be if the aircraft one is using is equipped with an ADF that has a standby frequency so I am not sure how this is a PFC tech support problem.

    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

     

  22. 3 minutes ago, zfehr said:

    I had to leave out the ENCODER_430_530_ or BUTTONS_430_530_ part of the name.

    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.

    5 minutes ago, zfehr said:

    I only get the CDI button to work but that is using C66375 which is native to MSFS for swapping between NAV and GPS.

    Because you programmed it that way, here:

    13=Cdi=C66375,0     -{TOGGLE_GPS_DRIVES_NAV1}-

    7 minutes ago, zfehr said:

    The C3#### codes for the Mobiflight.AS530 don't seem to do anything.

    Sorry, I know nothing about Mobiflight. Perhaps they have a support forum?

    Pete

     

  23. 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

     

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.