Jump to content
The simFlight Network Forums

John Dowson

Members
  • Posts

    13,034
  • Joined

  • Last visited

  • Days Won

    267

Everything posted by John Dowson

  1. For the 737 reversers, rather than sending Throttlen_Cut on the reverser release: try sending an F1 key press instead: Otherwise there are two presets that you can use to kill reverse thrust (i.e. to assign on reverser release): PMDG B737 Eng 1 Reverse Thrust Kill PMDG B737 Eng 2 Reverse Thrust Kill These use the PMDG custom controls: #define EVT_CONTROL_STAND_REV_THRUST1_LEVER (THIRD_PARTY_EVENT_ID_MIN + 680) #define EVT_CONTROL_STAND_REV_THRUST2_LEVER (THIRD_PARTY_EVENT_ID_MIN + 681) so you can use them directly instead if you don't want to use the presets. John Later: Ah, ok. They seem to work here... Try them anyway, and if not working switch to using those presets.
  2. Also, please activate logging for Lua Plugins, so that I can se the timestamps of the lua calls to see what is taking time - no other logging necessary, especially NOT Lua Plugins Separately.
  3. The PMDG 737 has always used throttle cut followed by throttle decr to activate reversers - I don't think there are lvars (or custom controls, which is what the PMDG normally will use if the standard controls don't work). But I will take a look later. To diagnose an issue, I always need to see the .ini and .log from the same session/flight, so I will have to look at your previous files. If you update the ini, and would usually need to see the log generated from using that ini. You can opt to not log/ignore such controls (i.e. ones that are continually sent) using the DontLogThese ini parameter, e.g. Those timestamps do not correspond to the log file you have posted.... Please see the following (long) topic on how to assign to the reversers in the 737: I also have this set-up on my Bravo on my flight system for the PMDG 737. I will check if that is working and send you my Bravo config. John
  4. Looking at that ini, there is no axis assigned to throttle1: ?
  5. This seems rather strange, as you are sending the left/right brake controls on the R (rudder) axis, and are also repeatedly sending BRAKES_RIGHT or BRAKES_LEFT when the rudder is more than approx 2/3rds full left or full right.
  6. I am not sure I understand this - and I don't have this aircraft. Do you have a reference on how this works or can you provide further details? How is the "brake handle" recognised - is that an axis or button, and is any control logged when used, or maybe an lvar is changed? You will probably need to use lua if you want an axis condition. You would write the axis values to an FSUIPC offset, and have a lua script monitor these offsets, calibrate the value and send the appropriate control depending on the brake handle position, which would also need to be monitored. There is a User Contribution for something similar, where a brake lever is used to control differential braking on a rudder axis - not the same I know, but shows the technique of how to send different controls on an axis depending on another lever: I can see if I can get hold of this aircraft and take a look, but this may take a while. John
  7. Can you please make sure you are using the latest released version of FSUIPC7, 7.4.11, or even better try the latest beta release, available from: and show me your FSUIPC7.log, FSUIPC7.ini and csv files. As I said, I only see this here when FSUIPC7 is started by MSFS via the EXE.xml file, and I have no idea why this is. I will look at you files to see if I can see anything, but there is not much I can do. What is the load like on your system? What aircraft do you have loaded - if using an airliner, have you tried with a GA aircraft? John
  8. Controls that go from external apps via SimConnect do not go through the same route as internal controls. This has already been raised with Asobo - see https://devsupport.flightsimulator.com/t/xml-key-event-bindings-do-not-intercept-key-events-via-simconnect/8320. I am not an aircraft developer/gauge programmer, so cannot really assist you with this xml code. Can you see the Input Event in FSUIPC (Log->List Input Events)? If so, you can use this directly. However, you can only assign to Input Events for buttons, keys and when entering/leaving axis ranges. To assign an axis to an Input Event in FSUIPC, you have to assign the axis to write to an FSUIPC offset, have a lua script that monitors the offset (using event.offset), calibrates the axis value to the Input Event range, and then send the Input Event using ipc.execInputEvent. It is also not clear to me how Asobo determine what Input Events are available via the SimConnect Input Event interface/functions. This would also be a question for Asobo. Sorry I can't be of more assistance - as I say, I am not a gauge programmer and you would get more help with this on the Asobo forums. John
  9. The MF Hub-Hop resource/website is the community-driven effort for discovering and publishing presets. I am certainly not going to create a 'proprietary' set of presets - these should be available to the community. And from what I have seen of the C510, it seems to mainly use Input Events for a lot of external control. It is NOT possible to use input events via presets, which is why a presume there are no presets yet available on the MF Hub Hop site for this aircraft. This has been requested before and I have already spent quite a while looking into this. It turned out to be too problematic for several reasons, and I am not going to look at this again, at least for the time being. I am just too busy. I don't see a need. If you just want to know what input events are available, use Log->List Input Events. Just switch on Input Event logging when you want to see if an input event exists on a certain button/function, and to see what parameters it is using. No - there is no distinction between where key presses come from, I just get a key press/release events (not the source), so this is just not possible.
  10. There will be no radar facilities available in the first release of AS for MSFS, but they are working on it. I will look into adding this to FSUIPC7 when available in AS. Regards, John
  11. Pete is on holiday at the moment. I will ask him to take a look when he returns next week, but I doubt he will still have any technical information for this. I have no knowledge of CockpitSonic hardware and so cannot help, sorry. John
  12. That is an A-var (a simvar) not an lvar. Why not just use offset 0x0BC8 (A:BRAKE PARKING POSITION)? I have added A:BRAKE PARKING INDICATOR in the attached version at offset 0x028D (1 byte). However, in the FBW A320 I do not see this offset change when I set the parking brake, but offset 0x0BC8 does. Are you sure the FBW A320 uses this simvar? John FSUIPC7.exe
  13. Can you try the attached version please: FSUIPC7.exe
  14. Unfortunately the title isn't yet available when I am reading the aircraft.cfg file, so this is not that straight-forward. I will see if I can read the aircraft.cfg file for this after the TITLE is received.
  15. FSUIPC gets the title from the TITLE simvar. This may originate from the aircraft.cfg file, but it is not read from there by FSUIPC for exactly the same reason - it would not know which FLTSIM.x section to load it from. So I would need to check the title in the FLTSIM.x sections until I found one that matches the TITLE as received from the simvar, which is why I can only do this if this simvar is available BEFORE I read the aircraft.cfg file. All other data read from the aircraft.cfg file is read from the GENERAL section. It isn't that complicated, but I do need to check the order of things to see if this is possible. If the title isn't available in offset 0x3D00 by the time I read the aircraft.cfg file, then I will not be able to read the FLTSIM sections and will not add the icao_airline string (even if there is only one FLTSIM.0 section). I will check this and get back to you, but most probably tomorrow now. John
  16. What am I looking for in that log - which button presses weren't working, and which were? I just cannot tell just from the log file. Please try with the logging console open (Log->Open Console), and let me know the timestamp of a button press not working, and also one where it is working. I see you have the flaps assigned to an axis using direct to FSUIPC calibration and calibrated in your PMDG 737 profile. This can cause issues with the climb rate - please see John
  17. But how do I know what x is? Do you expect me to read the title in each FLTSIM section, and then read the icao_airline from the section that has a matching title? I could possibly do this, but I need to check if the TITLE simvar has been received by the time I read the aircraft.cfg fille - it may not yet be available. Of course, as it is currently only read from [FLTSIM.0]. Also, it seems that some strings are enclosed in double-quotes, others not. Will the icao_airline string always be enclosed in double-quotes, or can it also be without these? John
  18. Yes, I saw that. So you want this read from the [FLTSIM.0] section? Other ICAO strings are read from the [General] section - e.g., for the C208: [GENERAL] atc_type = "TT:ATCCOM.ATC_NAME CESSNA.0.text" atc_model = "TT:ATCCOM.AC_MODEL C208.0.text" Category = "airplane" pilot = "Pilot_Female_Casual" copilot = "Pilot_Male_Casual" instructor = "Pilot_Male_Casual" performance = "Maximum Speed\n175 kts 324 km\/hr\n\nCruise Speed\n164 kts \t 305 km\/hr at 20,000 ft\n\nEngine\nPratt & Whitney Canada, Inc., PT6A-114A Free Turbine Flat Rated at 675 Shaft hp \n\nPropeller\nThree-Bladed, Constant Speed, Full Feathering, Reversible McCauley, 106-inch diameter\n\nMaximum Endurance\n5.1 hours maximum cruise at 10,000 ft\n6.6 hours maximum cruise at 18,000 ft\n6.4 hours maximum range at 10,000 ft\n7.2 hours maximum range at 18,000 ft\n\nService Ceiling\n22,800 ft 6,949 m\n\nFuel Capacity\n335 gal 1,268 L\n\nEmpty Weight\n4,575 lb 2,075 kg\n\nMaximum Gross Weight\n8,785 lb\t 3,985 kg\n\nUseful Load\n4,000 lb\t 1,814 kg\n\nLength\n41 ft, 7 in 12.7 m\n\nWingspan\n52 ft, 1 in\t 15.8 m\n\nHeight\n15 ft, 5-1\/2 in 4.8 m\n\nSeating\nUp to 14" icao_type_designator = "C208" icao_manufacturer = "CESSNA" icao_model = "208 Grand Caravan" icao_engine_type = "Turboprop/Turboshaft" icao_engine_count = 1 icao_WTC = "L" Please try the attached version where this is read from the [FLTSIM.0] section and added to offset 0x062C. Note that this will not be available if the location of the aircraft.cfg file is not available in offset 0x3C00 (possibly due to the aircraft being encrypted). I can switch to reading from the [General] section if needed, or possibly try both. Cheers, John FSUIPC7.exe
  19. Do you know of an aircraft (preferably an Asobo/default one) that has this identifier? I have checked several and cannot see this. Looks like the ICAO airline is always 3 characters. I can add as a 4-character string (3 chars + 0 terminated, at offset 0x062C s this offset is no longer used in FSUIPC7.
  20. That depends on whether AS for MSFS2020 provides an interface for this. I will contact HiFi to see what they are providing and what can be done. John
  21. The fsuipc,com website is using the http protocol, not https. I will change this when I get time - its been on my todo list for a couple of years! Its not an issue though, you just have to accept the insecure connection, and all the downloadable files are on https anyway. As for the virus detected issue, this is a false-positive. See John
  22. Sure, I can look into adding that. I will let you know when ready to test. John
  23. It was probably due to the calibration - some aircraft don't play well with post calibration (i.e. calibrating the values received from the FS). Also see @Falcon49's post above if you want to use FSUIPC7 to control the rudder/ailieron for this aircraft. John
  24. Finished for the day now and just about to eat... but try the attached ini where I have made a few minor adjustments (removed calibration for aileron and rudder for PC12, adjusted aircraft names in profiles). I will look further tomorrow. I think I know why DontLogThese isn't working as expected, but I will check further tomorrow. John FSUIPC7.ini
×
×
  • 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.