Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
Collapse
Just Flight Community Forum
  1. Home
  2. Just Flight
  3. MSFS Products
  4. Black Square Add-Ons
  5. Piston & Turbine Dukes
  6. Duke (Piston + Turbine) LVAR for MobiFlight

Duke (Piston + Turbine) LVAR for MobiFlight

Scheduled Pinned Locked Moved Piston & Turbine Dukes
72 Posts 8 Posters 9.6k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Black SquareB Black Square

    @Tailhook Three lines? I only see two. Also, when you say you tried it, do you mean that you tried your previous homebrew solution, or you tried incrementing/decrementing L:BKSQ_IgnitionPosition_1 0 -> 1 -> 2 -> 3 -> 5?

    J Offline
    J Offline
    jmarkows
    wrote last edited by
    #63

    @Black-Square said in Duke (Piston + Turbine) LVAR for MobiFlight:

    @Tailhook Three lines? I only see two. Also, when you say you tried it, do you mean that you tried your previous homebrew solution, or you tried incrementing/decrementing L:BKSQ_IgnitionPosition_1 0 -> 1 -> 2 -> 3 -> 5?

    So when the patch comes out, or we put the fix in manually, we should skip a value of 4?

    1 Reply Last reply
    0
    • T Tailhook

      @Black-Square Lines 5256 and 5298 were the '3rd' for each. ¯_(ツ)_/¯

      I reverted those lines and tested again. Setting ignition to 5 does crank the starter now. But this change is not realistic because the knob only counts to 0-4 when using mouse.

      Instead, I replaced:
      (A:GENERAL ENG STARTER:1, bool) if{ 0 (>A:GENERAL ENG STARTER:1, bool) }
      with
      (A:GENERAL ENG STARTER:1, bool) if{ 0 (>K:STARTER1_SET) }

      and

      (A:GENERAL ENG STARTER:2, bool) if{ 0 (>K:SET_STARTER2_HELD) }
      with
      (A:GENERAL ENG STARTER:2, bool) if{ 0 (>K:STARTER2_SET) }

      NOW the magneto switches go to START when in position 4, like they should.

      Black SquareB Offline
      Black SquareB Offline
      Black Square
      Black Square Developer
      wrote last edited by
      #64

      @Tailhook said in Duke (Piston + Turbine) LVAR for MobiFlight:

      But this change is not realistic because the knob only counts to 0-4 when using mouse.

      I'm sorry if I'm missing something, but how is setting a value of 5 to get what you want "unrealistic", just because that's not what happens when you use your mouse?

      T 1 Reply Last reply
      0
      • Black SquareB Black Square

        @Tailhook said in Duke (Piston + Turbine) LVAR for MobiFlight:

        But this change is not realistic because the knob only counts to 0-4 when using mouse.

        I'm sorry if I'm missing something, but how is setting a value of 5 to get what you want "unrealistic", just because that's not what happens when you use your mouse?

        T Offline
        T Offline
        Tailhook
        wrote last edited by
        #65

        @Black-Square Because manually manipulating the starter variable through devmode by forcing an abnormal value just to achieve a desired effect is not realistic. Everyone using external hardware or software with the Duke, Baron, and Bonanza are currently suffering from this issue. I provided the fix for simconnect to get both engines started externally, and the animation now works correctly when setting the Lvar and starter event simultaneously.

        1 Reply Last reply
        0
        • Black SquareB Offline
          Black SquareB Offline
          Black Square
          Black Square Developer
          wrote last edited by
          #66

          Please bear with me again, because I want to make the correct decision for everyone here. Can you explain how setting an L:Var and the correct starter event simultaneously is more desirable than just setting one L:Var? There's nothing "abnormal" about the value five. It just allows us to bypass the spring return of the four position in code.

          T 1 Reply Last reply
          0
          • Black SquareB Black Square

            Please bear with me again, because I want to make the correct decision for everyone here. Can you explain how setting an L:Var and the correct starter event simultaneously is more desirable than just setting one L:Var? There's nothing "abnormal" about the value five. It just allows us to bypass the spring return of the four position in code.

            T Offline
            T Offline
            Tailhook
            wrote last edited by
            #67

            @Black-Square Because magneto switches do not have 6 positions. This would require a custom intercept of receiving the Lvar value of 4 and then forcing the value of 5.

            1 Reply Last reply
            0
            • Black SquareB Offline
              Black SquareB Offline
              Black Square
              Black Square Developer
              wrote last edited by
              #68

              I'm not the most adept with hardware and the various 3rd party applications to bind them, so maybe that's the problem here, but... my users bind all sorts of complex behaviors with my aircraft using L:Vars. What is so complicated about setting the value to five when you turn your hardware switch to the start position? Please don't misconstrue my questions for resistance to change. If I have to explain a change to all my users in the future, I would just like to understand why it was the best choice to make at the time.

              1 Reply Last reply
              0
              • T Offline
                T Offline
                Tailhook
                wrote last edited by Tailhook
                #69

                Understandable. Just note that you are using the wrong event for the starter variable. _HELD is primarily for starter buttons, not switches. For more, see here: https://devsupport.flightsimulator.com/t/set-starter1-held-sdk-info-needs-slight-update/5366/3

                1 Reply Last reply
                0
                • T Tailhook

                  @Black-Square Lines 5256 and 5298 were the '3rd' for each. ¯_(ツ)_/¯

                  I reverted those lines and tested again. Setting ignition to 5 does crank the starter now. But this change is not realistic because the knob only counts to 0-4 when using mouse.

                  Instead, I replaced:
                  (A:GENERAL ENG STARTER:1, bool) if{ 0 (>A:GENERAL ENG STARTER:1, bool) }
                  with
                  (A:GENERAL ENG STARTER:1, bool) if{ 0 (>K:STARTER1_SET) }

                  and

                  (A:GENERAL ENG STARTER:2, bool) if{ 0 (>K:SET_STARTER2_HELD) }
                  with
                  (A:GENERAL ENG STARTER:2, bool) if{ 0 (>K:STARTER2_SET) }

                  NOW the magneto switches go to START when in position 4, like they should.

                  Black SquareB Offline
                  Black SquareB Offline
                  Black Square
                  Black Square Developer
                  wrote last edited by
                  #70

                  I agree, and I think the discrepancy that you've noticed was me "shotgun" testing multiple possible solutions back when I was developing this system. The STARTER_SET event would be the most correct to use, but I also want to make sure that people have a way to access the magneto switch via L:Var without the spring return, which has been a sticking point for the majority of hardware questions in the past.

                  Now, reading your original post to figure out the best combination of things to do here, the real question is why I haven't had any problems with starting the engines (with the proper visual switch position) by using the native starter events from the in-game controls menu.

                  1 Reply Last reply
                  0
                  • T Offline
                    T Offline
                    Tailhook
                    wrote last edited by Tailhook
                    #71

                    @Black-Square Good update for the Baron. But for some reason I still have an issue with Bonanza only liking _HELD, however I think it is a problem on my end and not the plane itself. Yayy

                    I did some snooping to try to find a cause but couldn't so I'm quite confused. I did however notice Bonanza XML does not have the "starterInUseSeconds" Lvar compared to the Baron XML, but that might be a leftover dead-code now because I see the logic for it was removed in the Pro versions. And I don't know if it means anything but I also noticed the BonanzaProfessional_Templates XML does not have <ModelBehaviors> at the top and bottom similar to the BaronProfessional_Templates XML.

                    So probably just ignore this post anyways.

                    Black SquareB 1 Reply Last reply
                    0
                    • T Tailhook

                      @Black-Square Good update for the Baron. But for some reason I still have an issue with Bonanza only liking _HELD, however I think it is a problem on my end and not the plane itself. Yayy

                      I did some snooping to try to find a cause but couldn't so I'm quite confused. I did however notice Bonanza XML does not have the "starterInUseSeconds" Lvar compared to the Baron XML, but that might be a leftover dead-code now because I see the logic for it was removed in the Pro versions. And I don't know if it means anything but I also noticed the BonanzaProfessional_Templates XML does not have <ModelBehaviors> at the top and bottom similar to the BaronProfessional_Templates XML.

                      So probably just ignore this post anyways.

                      Black SquareB Offline
                      Black SquareB Offline
                      Black Square
                      Black Square Developer
                      wrote last edited by
                      #72

                      @Tailhook said in Duke (Piston + Turbine) LVAR for MobiFlight:

                      "starterInUseSeconds" Lvar compared to the Baron XML, but that might be a leftover dead-code now

                      That's correct. It's from before I simulated battery temperature more accurately. Let me know if you find the issue, or have any more suggestions! Everything seems to have gone well in this respect with the last update, so I am now less afraid of making changes in this area 🙂

                      1 Reply Last reply
                      0
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users