Jump to content
The simFlight Network Forums

John Dowson

Members
  • Posts

    13,780
  • Joined

  • Last visited

  • Days Won

    288

Posts posted by John Dowson

  1. 7 hours ago, frankj76021 said:

    My SimMarket order number is 3580767

    I have checked your details here and they validate without issues.

    7 hours ago, frankj76021 said:

    I downloaded the re distributables as instructed and disabled antivirus.

    Did you download and install both the x86 and x64 combined (i.e. for 2015, 2017, 2019 & 2022) redistibutables?

    Are you sure all 3 parts of the license (name, address & key) are exactly as specified in your purchase email/simmarket account?

  2. Yes, they look to be the same. 0x0798 was added in v7.2.15, and 0x0818 in v7.2.0. Looks like I forgot to cross it off mu todo list and added it again.
    Unfortunately, now its there I am reluctant to remove one of those, as it may be being used by someone. I will mark 0x0798 as duplicate in the next update of the offset documentation.

    Well spotted!

    John

  3. 4 hours ago, AlMassimo said:

    Hi John, the plane is the Asobo CL 415 "Canadair", for fire fighting.

    I found the Lvar under fs 2024 developers menu using the tool "behaviors" and copying the code. 

    Ah - MSFS2024 - I was looking in MSFS2020...so, the Viking Air CL-415 then? Searching for 'Canadair' returns nothing...

    These are the new 'scoped lvars' - from the MSFS2024 documentation:

    image.png.b1ff5204bfdd6be8a698d2e367fc8ff9.png

    II do now remember hearing about these when they were introduced, but don't know how you can directly read scoped lvars at the moment or if this is even possible. You can use calculator code to set them e.g. '270 (>L:1:EHSI_1_HDG' will set the heading bug to 270.
    To read a scoped lvar, you could just write it to a standard lvar and read that, e.g. execute the calculator code 'L:1:EHSI_1_HDG (>L:EHSI_1_HDG )' will copy the value to the lvar EHSI_1_HDG (and also create that lvar if it doesn't already exist).

    However, in this instance, you can just use the input event INSTRUMENT_HEADING_BUG_LEFT which holds the same value as the scoped lvar. Just add that to an offset - and you can also set that (via an offset if required) to change the heading bug.

    I will investigate to see if these can be made visible. However, if I do this, this will break compatibility with MSFS2020 as I will have to switch to the MSFS2024 SDK, which means a new version of FSUIPC....

    John

    Later: I've looked at the MSFS2024 SDK and done some googling and its still not clear on how to access such variables. In this SDK, there is a new Vars API, but there isn't even a way to enumerate existing lvars (i.e. to discover them) and you need to know the name of an lvar before you can do anything with it. The functions the FSUPC WASM uses (from the old Gauges API) are deprecated with no replacement functions available (e.g. not even a function to execute a calculator code string).

  4. You log and ini files don't match - the log is from 7.5.4 and the ini from 7.5.3...

    I have tried to update  anyway.  Your ini is a bit of a mess as it looks like your GUIDs previously changed and rather than correcting for this you re-assigned.
    If you find that your assignments no longer work, it is usually because windows has assigned a new GUID and so FSUIPC cannot match this new GUID to the one in the ini file. Rather than re-assigning, you just need to update the GUID string of the device entry letter to which your assignments are attached.

    Anyway, I have cleaned-up your ini and update the GUIDs and have removed many duplicate assignments. There are a couple of assignments that need clarifying.

    1.  On your yoke, buttons 18 and 19 had different key assignments - I have left the later one, but kept the earlier one commented out:

    Quote

    ;9=PB,18,K54,24     -{Key press: lalt+6}-
    ;10=UB,18,K54,24     -{Key press: lalt+6}-
    ;11=PB,19,K51,10     -{Key press: lctl+3}-
    ;12=UB,19,K51,10     -{Key press: lctl+3}-
    13=PB,18,K87,10     -{Key press: lctl+W}-
    14=UB,18,K87,10     -{Key press: lctl+W}-
    15=PB,19,K69,10     -{Key press: lctl+E}-
    16=UB,19,K83,10     -{Key press: lctl+S}-

    You can edit this to keep the ones you want and remove the others,

    2. On your throttle quadrant, button 4, you have an assignment to both Gear Down and to send keypress lshift+C:

    Quote

    19=PE,4,C66080,0     -{GEAR_DOWN}-
    ;20=PE,4,K67,9     -{Key press: lshift+C}-

    I have commented-out the sending of the key press.  You can either re-activate this or remove it.

    Let me know how it goes with this. Any issues, please re-attach both the updated ini and the latest log file.

    John

    FSUIPC7.ini

  5. 7 hours ago, John Dowson said:

    And what do you mean by 'the default Canadair'? Which aircraft is this - there is no such default aircraft as far as I am aware...

    Do you mean the DHC-3 Beaver?

    7 hours ago, John Dowson said:

    I am pretty sure FSUIPC would pick it up, even with a name like '1:EHSI_1_HDG' - it is only a string after all...

    I can create an lvar with this name and this is then picked-up by FSUIPC:

    Quote

     28603640  [DEBUG]: Calculator code sent: 1 (>L:1:EHSI_1_HDG)
     ...
     28616422 Lvars received: 474 L:vars & 0 H:vars now available
     28651328   [INFO]: We have 474 lvars: 
     28651343   [INFO]:     ID=000 A32NX_DEVELOPER_STATE = 0.000000
     28651343   [INFO]:     ID=001 A380X_RMP_1_BRIGHTNESS_KNOB = 0.000000
    ...
     28651437   [INFO]:     ID=471 GPS_Current_Phase = 0.000000
     28651437   [INFO]:     ID=472 Glasscockpit_DmeSource = 1.000000
     28651437   [INFO]:     ID=473 1:EHSI_1_HDG = 1.000000

    So if such an lvar existed, it would be listed.

    So I am confused about this issue...

    Maybe ask on the MobiFlight Discord server about this... Please report back, or provide further details.

    John

     

  6. Please show me / attach your FSUIPC7.ini, FSUIPC7.log and FSUIPC7.JoyScan.csv files nd I will take a look. Most probably your joystick GUIDs have changed and these will need updating, but this should not affect key assignments.

    Finishing now for the day, will take a look tomorrow.

    John

  7. It is not possible to read the location of the aircraft.cfg file in MSFS2020/2024 if the file is encrypted, which is usually the case for paid add-ons. In MSFS2024, aircraft are 'streamed' - I haven't checked if the aircraft.cfg is readable for such aircraft. I will take a look on Monday, or possibly later today if I have time.

    John

    Later: Looks like it doesn't work either for streamed aircraft (i.e. all aircraft in MSFS2024) - see https://devsupport.flightsimulator.com/t/simconnect-requestsystemstate-aircraftloaded-returns-partial-path-of-aircraft-cfg/9041/7

    I will still check this though and report back.

  8. 1 hour ago, AlMassimo said:

    the AP heading of the default Canadair is 1=1:EHSI_1_HDG
    I can't understand what is this format... maybe is an array?

    No - lvars can only hold numeric data. From the Adobo documentation:
          IMPORTANT! "L:" vars can only hold numeric data and nothing else, eg: no strings, no binary values, no structs, etc...

    Are you sure there is an lvar with this name? Are you sure it isn't just 'EHSI_1_HDG' and the '1:' is some MobiFlight syntax?
    How do you read this in MobiFlight?

    And what do you mean by 'the default Canadair'? Which aircraft is this - there is no such default aircraft as far as I am aware...

    1 hour ago, AlMassimo said:

    calling these events I see the Lvar changing properly, but only on Mobiflight. If I add this Lvar to Fsuipc.ini like this :
    1=1:EHSI_1_HDG=UWA030
    nothing is written in A030.

    This Lvar isn't even visible under wasm list Lvars.

    Nothing is written as no such lvar exists. I am pretty sure FSUIPC would pick it up, even with a name like '1:EHSI_1_HDG' - it is only a string after all...

     

  9. Please don't attach the events.txt file (I have removed those) - that is the file that holds the presets, is installed by the installer and doesn't change.  It was the FSUIPC7.log file that you should also attach.

    On 7/27/2025 at 12:33 PM, Kimchi said:

     I thought about sticking the Logitech Joystick into another USB port. And now i see that my USB Pad is missing, which was detected before. 

    Did you change the USB port for the USB pad? Or is it in the same hub as another device, or was the logitech joystick connected to the same hub as the UDB pad? If using hubs, are they powered?

    Your joyscan csv shows the device is detected twice, with the same GUID, but with different vendor and product ids:

    Quote

    ,,, HIDscanning completed

    N, x00, x0417, x0130, , -1, -1, 0, {NULL}, {NULL}, {A81689A0-4715-11F0-8013-444553540000}, Y, N
    N, x00, x28DE, x11FF, , -1, -1, 0, {NULL}, {NULL}, {A81689A0-4715-11F0-8013-444553540000}, Y, N
     

    ,,, REGscanning completed

    N, x00, x0417, x0130, usb pad, -1, 3, 0, {NULL}, {A81689A0-4715-11F0-8013-444553540000}, {A81689A0-4715-11F0-8013-444553540000}, Y, Y
    N, x00, x28DE, x11FF, , -1, 3, 0, {NULL}, {A81689A0-4715-11F0-8013-444553540000}, {A81689A0-4715-11F0-8013-444553540000}, Y, Y

    Not sure why its doing this - looks to be a strange usb issue - especially as this was previously the problem with your logitech joystick but now its with the UDB pad. You could try ignoring that dodgy entry with the empty name by adding:
        IgnoreDevice=0x28DE,0x11FF
    to the [JoyNames] section of your FSUIPC7.ini file.

    If that doesn't work, please show me the files again, but include the FSUIPC7.log and no the events.txt file (if you cannot see the log file, it is because you have windows explorer set to hide the extensions of known log files - change this setting).

    John
     

  10. The log file you attached is from 7.4.17, where you say everything is working. Although that log file does contain errors.

    7.4.17 is also quite old now - there have been 6 release since that version. You should update more often....

    One change that was introduced in 7.5.0 that could affect some third-part add-ons is the offset that holds the sim version (0x3308), Some add-ons expect a value here on start-up, and prior to version 7.5 this was always set to 13. With the introduction of MSFS2024, this offset is now only populated once FSUIPC has a connection to the FS so that it can determine the version being used. For add-ons that need this offset populated earlier, you can add the following ini parameter to the [General] section of your FSUIPC7.ini file:

         init3308=13

    So please try that. Any issues, please set logging for IPC Reads and IPC Writes and show me / attach your FSUIPC7.log file. Also, please always exit FSUIPC7 before attaching logs.

    12 hours ago, chasbruce said:

    another program, Opencockpits SIOC v8.1B8, which has been rock solid for a very long time, also registerd in event vwr a stopped responding immediately after I installed 7.5.4

    Many people use SIOC with FSUIPC - I would have expected a lot more support requests if there was an issue here.

    If you still get issues with that change, after saving the log file from 7.5.4, can you also please try the attached version below, which is 7.5.3 (just rename your current FSUIPC7.exe and save the attached to your FSUIPC7 installation folder). Also show me / attach the log file from this version.

    John

    FSUIPC7.exe

  11. Peter retire > 5 years ago now.

    It looks like the name  has disappeared from the registry entry for your Saitek X-56 stick. Can you please attach your files - your ini, log and JoyScan.csv files and I will take a look.

    John

  12. To assign to presets, check the Select for Preset checkbox in the top-right of the Buttons & Switches Assignments dialog box. You can then click the Find Preset... button to find the relevant preset, ordered by provider, aircraft, subsystem etc. A more complete search interface can also be found at https://hubhop.mobiflight.com/presets/.

    Please also take time to read the User and Advanced User manuals. You will find more details on using presets (as well as lvars, etc) in the WASM section of the Advanced User guide.

    When I get time, I will make a FAQ entry on how to determine what to assign to using FSUIPC's logging facilities as I am continually explaining how to do this. For the time being, try using the support forums as such questions on assignments have been asked many times before.

    Let me know how it goes and if you have any further issues.

    John

  13. Please use the FSUIPC7 sub-forum for all issues/questions regarding FSUIPC7. I have moved your post.

    Many of the standard controls do not work for add-ons (or even some Asobo aircraft), especially complex ones, and you have to investigate other methods, such as lvars, custom controls, input events or presets.

    For the FSLabs lights, try presets:

    image.png.41a079c5f3ef1121d1a0a334ddab8e88.png

    As you see in that image, there is a Beacon ON and Beacon OFF preset you can use.

    In general, if standard controls don't work, check for a preset. If there is no preset, use FSUIPC's logging facility to determine what is being used. For The FSLabs, many buttons/switches can be controlled using custom control, via the standard FS control Rotor Brake, where the parameter indicates the switch. For example, see the following post where I explained how to do this for the APU Master switch in the FSLabs: 

     

    John

     

     

  14. I don't know why you pasted both your log and ini in your last post - I have removed them. They did not add anything new. I was just reminding you to exit FSUIPC7 before showing me files and did not need to see the same one again. And if a file is more than 10 or 20 lines, please attach it rather than pasting it - and this does not mean that I want you to attach them now. Only attach if you have followed my instructions and it is still not working.

    As for your issue, please re-read my last comments and report back, As I said, try starting FSUIPC7 after MSFS has started and arrived at the main menu, or use the auto-start feature. And if you get the same connection issues, read that FAQ entry and manually configure the initial connection parameters - and read the section on auto-tuning of start-up parameters in the Advanced User guide.

    John

  15. As I said, can you please exit FSUIPC7 before attaching log (and ini) files.

    But your log shows that FSUIPC7 couldn't establish a connection to MSFS.

    First, you started MSFS manually, and it looks like you did this before MSFS was running. If starting manually, you should start FSUIPC7 after starting MSFS, and one MSFS has arrived at the main menu. However, it is far better to use the auto-start feature so that FSUIPC7 is started by MSFS when ready. To use auto-start, please re-install and leave the selected components (to install) as they are.

    For details on tuning the start-up parameters for preventing connection issues, see the following FAQ entry.:  

    Note that once you have configured the DetectToConnectDelay DetectToConnectDelayAuto parameters correctly, you can also set the InitialStallTime parameter to 0 which will then instruct FSUIPC7 to wait indefinitely for a response to the connection request.

    Also see the section Auto-tuning of initial start-up ini parameters on page 11 of the Advanced User guide.

    John

  16. 2 hours ago, electricclay2000 said:

    I notice that the Aivlasoft  EFB v2 Client moving map doesn't move anymore ,after I added the    Init3308=13    to the FSUIPC7 .ini file.

    Is FSUIPC7 actually connect to MSFS? Maybe you can show me / attach your FSUIPC7.log file (from a session when you get this error, and please exit FSUIPC7 before attaching the file).

    If FSUIPC7 is connecting to MSFS and there are no error in your log, you need to contact Aivlasoft about this issye - I only support FSUIPC and not third party clients.

    John

  17. 18 hours ago, Braudoux said:

    I have double-checked the assignments within P3Dv4.5 and removed all default assignments...

    It is better to disable  controllers completely if assigning in FSUIPC, as P3D has a habit of re-assigning controllers which can cause issues.

    18 hours ago, Braudoux said:

    While attempting to calibrate the throttles, I noticed that the curve for each is working half way only, and not all along the curve (See screens). Consequently, if my controller's levers are on idle and I move them forward, the first half is not generating any action and the levers in the cockpit start moving when I reach the second half, which gives me a very short range to manage the power. 

    This is nothing to do with the curve, it is due to your calibration.. The minimum value calibrated is 4534 for throttle 1, and 3272 for throttle 2. Axis ranges usually go from -16384 to +16383, so you are losing more than half your axis range. Calibrate the minimum value correctly.

    The reason you only see the right-hand part of the slope is explained in the User guide:

    Quote

    For axes with no centres you only get to right-hand part of the slope, but the same variety is available. For axes with “off-centred” centres, such as the separate throttles with a small reverse zone below an off-centred idle position, the left hand part is kept linear in order to be sure that the very extreme left position can be reached. The slope changes apply only to the right-hand or positive part of the lever movement.

    Also, for future reference, please always attach your FSUIPC ini file when you have any issues with assignments - this tells me a lot more than images do (including which version of FSUIPC you are using, which you didn't mention!).

    John

  18. 1 hour ago, Pitter said:

    I will do as you suggested, and if it not work  -which I don´t think-  I will come back to you.

    As you have no assignments in FSUIPC that could cause such behavior, it mut be coming from somewhere else.
    First, just disable controllers in P3D and see if you get the same behavior - if not, the issue is with your P3D assignments. If you do get the same behavior, please show me another log file bit with logging for Buttons & Keys as well as Events (non-axis controls) activated.

    John

  19. 3 hours ago, Hollis said:

    I re-entered the license number and now it's working fine again. 

    Ok, but that is strange - you shouldn't need to re-enter or re-register your license on an update (unless you have changed your installation folder).
    When you update, the license page of the installer should be pre-populated (from your FSUIPC7.key file), and you should just skip the registration.

    John

×
×
  • 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.