Jump to content
The simFlight Network Forums

spokes2112

Members
  • Posts

    320
  • Joined

  • Last visited

  • Days Won

    17

Posts posted by spokes2112

  1. John,

    Agree with you 100%
    It looks to me, from logs, that the command / param C68066 and the read offset 0x0298 work just fine. 
    At one point the thread went on a small tangent (below) and I replied to that plus missed your suggestion in a reply.
    Sorry for wasting your time!
    Although, for knowledge sake, I wonder if updating the current aircraft speed to the autothrottle speed window cured it. 

    Roman

    On 8/22/2021 at 4:16 AM, Sergiohst said:

    there is a caveat and is that when set to "selected" this way, actual PFD speed is Ok, maintains the same speed as when managed, an AP stays in that speed, but the AP PANEL Speed showed is always 100.   When you start to adjust speed it starts in that 100 stated.

    On 8/22/2021 at 6:57 AM, John Dowson said:

    Which offsets (or lvars) are you using for this? Maybe try the following offsets to see what they contain:
    .... continued - Otherwise, it may be worth asking about this on the FBW support/discord channel.

     

  2. Been reading this thread with interest even though I do not own MSFS.
    Just wondering, are you actually flying the aircraft when testing?
    Many advanced aircraft will act the same way, not broken, if going from managed to selected speed and not moving. Think about it, going to managed speed the autothrottle speed is taken care of... IE the FMC is injecting "a" speed for the autothrottle to follow whereas going to selected speed it does not. The autothrottle has no idea what speed you are flying at. This portion "might" be taken care of with internal logic embedded within the autothrottle button push code in the model ( something you might have to take care of yourself ). The 100 is coming up as a autothrottle lower limit "AND" as a warning to the pilot. It may work correctly if you are flying the plane.?.?.?.

    Here is the logic behind it, written in human terms.
    On press/pull of the auto throttle speed knob :

    If "speed slot" equals "selected" then  // ((A:AUTOPILOT SPEED SLOT INDEX,Number) equals 1)
    	Send FS control #68066 with a parameter of 2 // Managed is commanded, this part is done
    Else
    	Send FS control #68066 with a parameter of 1 // Selected is commanded, more code might be necessary 
    	// Do the following code only if flying AND a "100" comes up on the speed window
    		If INDICATED AIRSPEED (0x02BC) > 100 kts then
    			INDICATED AIRSPEED (0x02BC) send to --> AUTOPILOT AIRSPEED HOLD VAR (0x07E2)
    		Else
    			a value of 100 send to --> AUTOPILOT AIRSPEED HOLD VAR (0x07E2)
    		End
    End

    Just another set of eyes looking at it, hope it might help.
    Roman

     

  3. 24 minutes ago, Pete Dowson said:

    It looks like a bad character somewhere.

    Specially if the code snippet is copied directly from the lua library .pdf, then modified for your use.  
    In a lot of cases ( not all ) the quote symbols used are of a MS Word type ( forward & reversed pairs ), not plain text type. That will trip up the lua.
    Just checked the v4 version of the lua library pdf, and sure enough - reverse paired quotes.
    OFC, attach the lua so it can be looked at.  

    Roman
     

     

  4. Chakko & Pete,
    I wonder if this would work, using a lua & offset 0x0D70.. It may be worth a test 😉 to see.
    The premise is that if the [Auto] section accepts an included folder within the name string than maybe, just maybe, 0x0D70 will too.

    A possible test lua to kill all the 747 luas is below, OFC not tested. Use the command window logging. Could've, but didn't, add a display to inform you what's going on. 

    If this works you could then run a single lua under [Auto] and within that lua are  the commands to start your specialized luas. OFC if this works you could also make a fully automated setup for each of your specialized folders using ipc.ask to select the specialty folder to use. It could become very easy to start/stop specialized luas that are within a folder group.

    Fingers crossed for you,
    Roman

    
    -- Kill [Auto] #1
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3inputsL")
    ipc.sleep(150)
    
    -- Kill [Auto] #2
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3inputsR")
    ipc.sleep(150)
    
    -- Kill [Auto] #3
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3outputs1")
    ipc.sleep(150)
    
    -- Kill [Auto] #4
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3outputs2")
    ipc.sleep(150)
    
    -- Kill [Auto] #5
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Overhead")
    ipc.sleep(150)
    
    -- Kill [Auto] #6
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Captain")
    ipc.sleep(150)
    
    -- Kill [Auto] #7
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Copilot")
    ipc.sleep(150)
    
    -- Kill [Auto] #8
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Centre")
    ipc.sleep(150)
    
    -- Kill [Auto] #9
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Quadrant")
    ipc.sleep(150)
    
    -- Kill [Auto] #10
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3RearPedstl")
    ipc.sleep(150)
    
    -- Kill [Auto] #11
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3_RN1")
    ipc.sleep(150)
    
    -- Kill [Auto] #12
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3_RN2")
    ipc.sleep(150)
    
    -- Kill [Auto] #13
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3RNinputs")
    ipc.sleep(150)
    
    -- Kill [Auto] #14
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3lights")
    ipc.sleep(150)
    
    -- Kill [Auto] #15
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Panels")
    ipc.sleep(150)
    
    -- Kill [Auto] #16
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3MotorQuad1")
    ipc.sleep(150)
    
    -- Kill [Auto] #17
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3MotorQuad2")
    ipc.sleep(150)
    
    -- Kill [Auto] #18
    ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3ATstate")
    ipc.sleep(150)
    
    
    --[[ 
    THE [AUTO] ENTRIES JUST FOR MY REFERENCE
    1=Lua LuaB747v3\\b747v3inputsL
    2=Lua LuaB747v3\\b747v3inputsR
    3=Lua LuaB747v3\\B747v3outputs1
    4=Lua LuaB747v3\\B747v3outputs2
    5=Lua LuaB747v3\\B747v3Overhead
    6=Lua LuaB747v3\\B747v3Captain
    7=Lua LuaB747v3\\B747v3Copilot
    8=Lua LuaB747v3\\B747v3Centre
    9=Lua LuaB747v3\\B747v3Quadrant
    10=Lua LuaB747v3\\B747v3RearPedstl
    11=Lua LuaB747v3\\B747v3_RN1
    12=Lua LuaB747v3\\B747v3_RN2
    13=Lua LuaB747v3\\B747v3_RNinputs
    14=Lua LuaB747v3\\B747v3lights
    15=Lua LuaB747v3\\B747v3Panels
    16=Lua LuaB747v3\\B747v3MotorQuad1
    17=Lua LuaB747v3\\B747v3MotorQuad2
    18=Lua LuaB747v3\\B747v3ATstate
    ]]--

     

  5. According to the spreadsheet provided in the documents provided 0x0230 (Absolute Time) responds but in another column it states "Not Working". 0x0274 (frame rate) has no notes in the sheet whatsoever so it probably doesn't work.

    You may want to try the Local and/or Zulu time entries,  Zulu minutes is noted as working, you could use that but ofc your resolution will be 1 minute 😞, maybe others work, although "Local" seems buggy from the notes provided.

    In the end though, an offset providing the connect info or a response to FSUIPC.Process() (its equivalent for FSUIPC7) would be optimal. 

    Roman

     

  6. It isn't just Carenado, many other reputable designers have the same thing - constant control firing.
    2 reasons why this may happen :
    1) Unavoidable, the logic behind the system requires constant updating, an example. Many years ago I programmed a terrain following radar tied to the AP. In order for it to work correctly I needed to send vertical speed & altitude commands to the AP as fast as possible.
    2) Poor programming. Many many times this is the cause.

    In the case of the Phenom, I can see the MIXTURE#_RICH being used. Yes in jets it can be (and is) used, in the core of the sim it is basically the same as fuel valves.
    The firing of AP_PANEL_SPEED_OFF, whoah! That really looks like bad programming, in this case it should be something like : 
    (A:AUTOPILOT AIRSPEED HOLD, bool) 0 != if{ (>K:AP_PANEL_SPEED_OFF) } 
    Basically, if the AP speed should be off, and it isn't, well then, turn it off! In the case above it just isn't checking if already off.

    When it comes to constant firing it really isn't that bad (wasting resources) as long as it doesn't constant fire dozens (>36) of different commands.
    There is 1 command, the exits, (shift-E + #) that will always be affected by constant firing. When the exits command is used (other than #1) it will not work because the second part of the command, the number, is interrupted by the background constant firing of commands. A good sign that the aircraft programming is guilty of constant firing without actually checking for it.

    I see John has replied also. DontLogThese, that is one .ini entry that I just cannot live without, specially when it comes time for logging, be it lua programming or button/key/hardware checking. If interested, you could look here, I provided proof of constant firing for other reputable designers. (A2A, PMDG, Leonardo, Iris)

    Roman

  7. John,

    59 minutes ago, John Fee said:

    May I ask where you found the "P40_Hyd.mcro" file? Just in case i want to try something similar again.

    Unlike the FSUIPC built in macro maker for C+ type gauges, macros for L:Vars have to be handmade.  (~pg 43 FSUIPC4 for Advanced Users.pdf, "Macros to change Lvars")
    The macro facility to operate Lvars can only be used by editing macro files and building them manually. The format is: N=L:name=ACTION
    Note, not a big worry as the .mcro files are no more than text files with a .mcro extension. Use Notepad or some other plain text editor to view/edit them.
    BTW, I attached a bunch of zipped up .mcro files as examples you can look at. They will serve no other purpose for you.

    The difficult part is finding the correct L:Var variable name, once you have that, the .mcro making part is easy.
    As Pete mentioned here
    "To find LVars you can use the supplied Lua plug-in to log Lvars.  Run that plug-in my assigning it to a keypress, then operate the button and see if an LVar value changes."
    There are other ways such as using a hex editor to inspect the interior model (.mdl) file and such but that is way beyond the scope here.

    That's about it, hard = finding the L:Var name, easy = making the .mcro file itself.

    Strange that the macro doesn't work on the keyboard, it should.. As for the modules folder location, yes, sorry about that, just used to it being "old style", contained within the simulator folder structure.
    Glad you got it working! 


    Roman

    macro examples.zip

    • Thanks 1
  8. John,

    We are controlling only 1 L:Var here, therefore using Lua would be overkill.. Yes, Lua could be used, specially if controlling more than 1 L:Var and/or incorporating some kind of logic behind it. In this case there is no logic, it is either pressed or not pressed. In this example we are just using a .mcro file to inject a custom control to be used by FSUIPC. 

    1) Flight Sim closed.
    2) Unzip the attached "P40_Hyd.zip" and place the "P40_Hyd.mcro" file into the <flight sim>\modules folder
    3) Start FS and assign your joystick button as shown in the image below.
    Note - to use a keyboard key would be very similar, just use the "Key Presses" tab instead.
    4) Done

    Good luck,
    Roman

    P40_HYD.jpg?dl=0

     

    P40_Hyd.zip

    • Thanks 1
  9. John,

    This has been tested in FSX using the "C" model P-40, A2A Wings of Power III.

    Constructing a L:Var macro with the variable name - L:HydraulicPumpControl will control the control stick button. Assigning the macro on button press with a parameter of 1 will be a button push, 0 will be a button release. Ex.
    #=L:HydraulicPumpControl=Set 

    You could get a slightly different action by assigning the macro with the action - TOGGLE  (press once for ON, press again for OFF)
    ~pg 43 FSUIPC4 for Advanced Users.pdf

    Roman
     

    • Like 2
  10. Hi guys,

    The script I wrote for FSUIPC v3.x/4.x was done so some prerequisites could be used to turn on/off the auto save. Because the auto save in these versions of is basically a fixed function in FSUIPC I had to write a full save routine - requisites, save files, file name format, increment files etc.. The stock FSUIPC (v3/4) autosave works brilliantly already, it is just the problem that it is either on or off, switched within the UI of FSUIPC.

    FSUIPC v5+ now has a control (C1151) to toggle on or off the built in excellent, extensive autosave. All that is needed is a little lua to tell when to  turn it off for performance explicit operations. ex.. If gear handle is down then disable auto save, else keep autosave on.

    My full lua would be overkill in this situation, even if it did work. 

    Roman

     

     

    • Like 2
  11. A calculated guess here, but I do believe FSUIPC can automatically do that for you as long as the following is true in your FSUIPC7.ini ( default) :

    [JoyNames]
    AutoAssignLetters=Yes

    As stated in the v7 Lua Library for event.button :

     “joynum” is a joystick number, the same as shown in
    FSUIPC’s Button assignments tab. If you use joystick
    lettering, you can put the letter here instead but it must be ""
    quotes, as a string. Note, however, that the function is called
    with the translated number as its first parameter.

    With that you could change just 1 line in TripleUse.lua -
    joy = 1 -- around line 21
    - change to -
    joy = "A" 

    If you really need the number for your specialized coding, maybe you could use an "initialization" lua (or placed in your current code) to put the joy number into a user offset or variable within your lua. It does however, require that you press the assigned initialization button at least once to populate the offset/variable before using your own specialized triple use.
     

    jn = nil
    
    function getJoyNum(joynum, button, downup)
    	ipc.writeUB(0x66C0, joynum)
      	jn = joynum
    end
    
    event.button("A", 0, 1, "getJoyNum") -- button 0 on alpha  (assigned "A") is the trigger

    0x66C0 or the variable "jn"  will now hold your actual joy number for any of your uses.

    Just an idea...

    Roman

  12. John,
    Was working on a reply the same time as you were. 

    1 hour ago, John Dowson said:

    v=logic.And(n, 0x4)

    and v will hold 1 if the landing lines are on, 0 otherwise.

    Wouldn't the value of v be 4 if on? OFC "true" boolean is 0 or not zero, so it would work if checking for 0.

    v=logic.And(n, 0x4)
    if v == 4 then
     -- landing lights are on
    end

    - or -

    v=logic.And(n, 0x4)
    if v ~= 0 then
     -- landing lights are on
    end

    _____________________________________________________________________________________________________________

    Here's another way to look at it..
    Refer to this chart:
    bit.jpg.c5dbef4dc0f5cd32cbef86b1977b189b.jpg

    Here is an example if you were to use a loop to check, not recommended at all... An example just to show how you can manipulate the checking of bits.

    a = ipc.readUW(0x0D0C)
    
    -- Landing Light is ON
    if logic.And(a, 4) == 4 then
     -- Do something
    end
    
    -- Landing Light is OFF
    if logic.And(a, 4) == 0 then
     -- Do something
    end
    
    -- BOTH Strobes & Logo lights are ON ( add up bit values )
    if logic.And(a, 272) == 272 then 
     -- Do something
    end 
    
    -- BOTH Strobes & Logo lights are OFF ( add up bit values )
    if logic.And(a, 272) == 0 then 
     -- Do something
    end


    Another example, using a recommended event listener to call a function only if the bit value that is masked has changed. This is so much more efficient.

    BeaconDetect(offset, value)
    	if value == 2 then -- the bit value
    		-- turn ON led code here
    	else
    		-- turn OFF led code here
    	end
    end
    
    StrobesDetect(offset, value)
    	if value == 16 then -- the bit value
    		-- turn ON led code here
    	else
    		-- turn OFF led code here
    	end
    end
    
    LandingOrTaxiDetect(offset, value) -- this detects the landing OR taxi lights being ON (1 led)
    	if value == 4 or value == 8  then
    		-- turn ON led code here
    	else
    		-- turn OFF led code here
    	end
    end 
    
    event.offsetmask(0x0D0C, 2, "UW", "BeaconDetect") -- detect if bit #1 (value = 2) changes
    event.offsetmask(0x0D0C, 16, "UW", "StrobesDetect") -- detect if bit #4 (value = 16) changes
    event.offsetmask(0x0D0C, 12, "UW", "LandingOrTaxiDetect") -- detect if bit #2 (value = 4) -or- bit #3 (value = 8) changes


    Roman
     

  13. @Eliagh, as mentioned here you can use only 1 L:Var in a .MCRO file.
    Using buttons, in this case, 1 button, you can cycle through the ranges and repeat :
    1 = L:B747_8_MFD_Range = Cyclic,11
    This will give 0,1,2,3,4,5,6,7,8,9,10,11,0,1,2 .... On each button press.
    See FSUIPC# for Advanced Users.pdf, "Macros to change Lvars" section.

    For an increment/decrement you would have to use lua. Something like this, NOT TESTED :
    Use [AUTO] in .ini to start the lua then assign buttons or encoder as such -
    Decrease = LuaToggle <lua_name> with a parameter of 1
    Increase =  Lua Toggle <lua_name> with a parameter of 2

    Function mfd_adjust(flag)
    	a = ipc.readLvar("L:B747_8_MFD_Range")
    	if flag == 1 then
    		a = a - 1
    		if a < 0 then
    			a = 11
    		end	
    	else
    		a = a + 1
    	end
    	a = a % 12
    	ipc.writeLvar("L:B747_8_MFD_Range", a)
    end
    
    event.flag(1, "mfd_adjust")
    event.flag(2, "mfd_adjust")

    Roman
     

      

  14. 2 hours ago, rojo2021 said:

    I'm not too clear what you'd like me to do as a favour.

    No worries Roger, what I was asking for is a stock cameras.cfg file.. I have 1 highly modified one, and 5 backups. None of my backups were of the bone stock one. 😒 Alas, after reading thru the SDK it was found that FSX keeps a stock, unmodified one in the FSX root folder.. Now I have 2 stock ones just in case.

    With that,  I can be 100% certain of the hot keys used by the master cameras.cfg file. 1 thru 4.. That leaves 0 & 5 thru 9 available for your own use.

    3 hours ago, rojo2021 said:

    Are you wanting me to test it?

    No, already done & tested - thanks. I like it as it gives a full view of all the avionics close up ( GPS specially ) so my weary eyes can see it better. Plus it shows, as a bonus, the Nav 2 OBI & the ADF Indicator, a nice extra specially if the yoke is visible.

    Glad it is working out for you 👍   
    Roman

  15. Good news Roger !

    1 hour ago, rojo2021 said:

    Do you think I'll be pushing my luck to use Camera 7 for a hotkey for another view which would be useful. 

    I believe you could do it.. Although, just to make sure, go to C:\Users\<USER>\AppData\Roaming\Microsoft\FSX\Cameras.cfg and check that file for all the HotKeySelect= entries. If 7 is not used in any of them then it is free to use with no side effects. 

    May I ask a favor? I noticed my backup Cameras.cfg files are not good backups.. I don't have a stock backup.
    In lieu of attaching yours here (path above) I did a little work & setup a view that shows the garmin, nav/com 2 & the adf, all without seeing the quadrant levers.. ( kind of tough )
    This replaces the mostly useless 2nd Row Passenger camera.

    [CameraDefinition.007]
    Title = "Garmin, NAV/COM 2, ADF"         // "2nd Row Passenger"
    Guid = {0456199A-99D4-11DC-B263-66CC55D89593}
    Origin = Virtual Cockpit
    MomentumEffect = Yes         // You could optionally change this to No
    SnapPbhAdjust = Swivel
    SnapPbhReturn = False
    PanPbhAdjust = Swivel
    PanPbhReturn = False
    Track = None
    ShowAxis = YES
    AllowZoom = TRUE
    InitialZoom = 0.30         // 0.40
    SmoothZoomTime = 2.0
    ZoomPanScalar = 0.4
    ShowWeather = Yes
    XyzAdjust = TRUE
    ShowLensFlare=FALSE
    Category = Cockpit
    PitchPanRate=20
    HeadingPanRate=60
    InitialXyz=0.3, -0.275, 0.555         // 0.6, 0.1, -0.65
    InitialPbh=0, 0, 0        // 2, 0, 345
    HotKeySelect=7

    Roman

  16. Roger,
    An edit after another test..

    22 minutes ago, spokes2112 said:

    On release of the button it goes back to default VC view, not where you may have been before with zoom, position etc..

    When the button is released, using VIEW CAMERA SELECT 1  "should" return you to the original direction, position, zoom etc.. in the VC
    "Should" = I cannot be 100% positive with this view select number, my master camera.cfg file is highly modified, checked my backup and it was 1 also.
    If it doesn't work try VIEW CAMERA SELECT 0, VIEW CAMERA SELECT 2, VIEW CAMERA SELECT 3 etc.. One of the numbers will get you back.

    Roman

  17. Hello Roger,

    Noticed you posted this on Avsim too, hopefully this will help.

    Alabeo provided camera definitions for the fuel selector panel in the aircraft.cfg :) This will make it easy.

    1) First you need to provide a "hot key" entry & number to your aircraft.cfg camera definition for the view "Fuel Selector". I have modified mine as such. Make a backup of the cfg if wanted.
    Warning! Do not go "willy nilly" on the hot key numbers. Numbers 0-4 (i believe) are reserved in the master camera.cfg file. I used 9, the max, as the value just in case you use some other kind of camera software IE ez-dok. ( don't know, dont own ) 

    [CameraDefinition.003]
    Title = "Fuel Selector"
    Guid = {195EAB58-9E4A-2E2A-A34C-A8D9D948F079}
    Origin = Virtual Cockpit
    MomentumEffect = No
    SnapPbhAdjust = None
    SnapPbhReturn = False
    PanPbhAdjust = None
    PanPbhReturn = False
    Track = None
    ShowAxis = FALSE
    AllowZoom = TRUE
    InitialZoom = 1.00 //0.45 I optionally put in 1.0 for ease of reading the fuel selector panel, originally 0.45
    SmoothZoomTime = 2.0
    ZoomPanScalar = 0.75
    ShowWeather = Yes
    XyzAdjust = TRUE
    ShowLensFlare=FALSE
    Category = Cockpit
    PitchPanRate=20
    HeadingPanRate=60
    InitialXyz=0.25, -0.1, 0.1
    InitialPbh=80, 0, 0
    HotKeySelect=9 // This is the  new entry
     

    2) In FSUIPC assign your rocker as such:

    "Control sent when button pressed" = VIEW CAMERA SELECT 9, parameter 0 or leave blank
    "Control to repeat while held" = unchecked
    "Control sent when button released" = VIEW VIRTUAL COCKPIT FORWARD, parameter 0 or leave blank

    It works great except... On release of the button it goes back to default VC view, not where you may have been before with zoom, position etc.. ( not really a big deal )

    Hope this helps,
    Roman

  18. Completely agree with you John, in fact I can almost bet 100% that the Logitech installer is using text string based logic rather than using the XML DOM & imports to their program such as system.xml to do the work. ( the tab spacing seems to give it away )

    4 hours ago, John Dowson said:

    If I can duplicate here with you EXE.xml I can update the installer to handle this more gracefully.

    An idea for "gracefulness" when improper <Launch.Addon> additions are made by a program that is not doing it properly IE using text strings to figure it out.  
    Use line breaks in key locations.. This should help when a text string based program is trying to add to what you already have. XML doesn't care about whitespaces whereas text string based logic does.

    Old :

    <?xml version="1.0" encoding="Windows-1252"?>
    <SimBase.Document Type="Launch" version="1,0"><Descr>Launch</Descr><Filename>EXE.xml</Filename><Disabled>False</Disabled><Launch.ManualLoad>False</Launch.ManualLoad><Launch.Addon><Disabled>False</Disabled><ManualLoad>False</ManualLoad><Name>FSUIPC7</Name><Path>C:\FSUIPC7\FSUIPC7.exe</Path><CommandLine>-auto</CommandLine><NewConsole>False</NewConsole></Launch.Addon></SimBase.Document>

    New:

    <?xml version="1.0" encoding="Windows-1252"?>
    <SimBase.Document Type="Launch" version="1,0"><Descr>Launch</Descr><Filename>EXE.xml</Filename><Disabled>False</Disabled><Launch.ManualLoad>False</Launch.ManualLoad>
    <Launch.Addon>
    <Disabled>False</Disabled><ManualLoad>False</ManualLoad><Name>FSUIPC7</Name><Path>C:\FSUIPC7\FSUIPC7.exe</Path><CommandLine>-auto</CommandLine><NewConsole>False</NewConsole>
    </Launch.Addon>
    </SimBase.Document>

    Just an idea....

  19. One of the the 2 installers/dameon is providing its own closing </SimBase.Document> closing tag which is part of the "root" document - not good.
    The file will not parse, therefore not load due to the error.
    Mistake shown shaded below. 
    example.thumb.png.3857fe58eaa46c3591d6e401d65d098e.png 
    This should work by either removing the highlighted selection above from your own file or,
    Copy the complete code below and replace all the code in your file with this, save it.

    <?xml version="1.0" encoding="Windows-1252"?>
    <SimBase.Document Type="Launch" version="1,0">
    	<Descr>Launch</Descr>
    	<Filename>EXE.xml</Filename>
    	<Disabled>False</Disabled>
    	<Launch.ManualLoad>False</Launch.ManualLoad>
    	<Launch.Addon>
    		<Disabled>False</Disabled>
    		<ManualLoad>False</ManualLoad>
    		<Name>FSUIPC7</Name>
    		<Path>C:\FSUIPC7\FSUIPC7.exe</Path>
    		<CommandLine>-auto</CommandLine>
    		<NewConsole>False</NewConsole>
    	</Launch.Addon>
    	<Launch.Addon>
    		<Name>Logitech Microsoft Flight Simulator Plugin Steam</Name>
    		<Disabled>False</Disabled>
    		<Path>C:\Program Files\Logitech\Microsoft Flight Simulator Plugin\LogiMicrosoftFlightSimulator.exe</Path>
    		<CommandLine>-r</CommandLine>
    	</Launch.Addon>
    </SimBase.Document>

     

  20. Gustavo,

    Most, if not all the switches/buttons you are referring to have logic built in to the VC click spots, mainly timers. Much like interfacing the AP, there is no real way to do this via L:Var macros & lua is out of the question too.
    Just returned home after some time away and continuing on your AP interface ( some FMC too 😉 ). If you take some screenshots highlighted with all the buttons & switches you need , I can add those too. (send via our PM thread)

    Roman

    P.S. Here's an example of the APU code needed just to make it work -

    (M:Event) 'LeftSingle' scmi 0 == (M:Event) 'WheelUp' scmp 0 == or if{  
    	(L:ASD_SWITCH_APU_MASTERSTART_DIR,number) 2 &lt; if{ 
    		1 (>L:ClickSoundCar,number) 
    	} 	
    	(L:ASD_SWITCH_APU_MASTERSTART_DIR,number) ++ 2 min (>L:ASD_SWITCH_APU_MASTERSTART_DIR,number) 
    	(L:ASD_SWITCH_APU_MASTERSTART_DIR,number) 2 == if{ 
    		(P:local time,seconds) 05 + (>L:ASD_SWITCH_APU_MASTERSTART_TIMER) 
    	} 
    }
    		
    (M:Event) 'RightSingle' scmi 0 == (M:Event) 'WheelDown' scmp 0 == or if{
    	(L:ASD_SWITCH_APU_MASTERSTART_DIR,number) 0 > if{ 
    		1 (>L:ClickSoundCar,number) 
    	} 
    	(L:ASD_SWITCH_APU_MASTERSTART_DIR,number) -- 0 max (>L:ASD_SWITCH_APU_MASTERSTART_DIR,number) }
    	(L:ASD_SWITCH_APU_MASTERSTART_DIR,number) 2 == if{ 
    		1 (>L:APU_START,number)	1 (>L:APU_GENERATOR_SWITCH,number) 0 (>L:APU_STOP,number) 
    	}  
    	(L:ASD_SWITCH_APU_MASTERSTART_DIR,number) 0 == if{ 
    		0 (>L:APU_START,number)	0 (>L:APU_GENERATOR_SWITCH,number) 1 (>L:APU_STOP,number) 
    	}
    }

     

  21. 6 hours ago, Luke Kolin said:

    After the sim was running for a few minutes, I plugged it in. It was detected, and matched my Joystick letters. Except none of my axis or button assignments were recognized by FSUIPC!

    Definitely a non-standard way of using the sim.
    When this happens, did you try going to the FSUIPC dialog -->  Axis Assignment Tab --> Click the "Reload all assignments" button?
    That should fix it for you without restarting the sim. 1 extra step for your non-standard SOP.

    Roman

  22. Have it going & it works, just to give an idea of the background logic here's just the press of the VS button. There's also the release.
    The AP master and VNAV are even more complicated! 

    			<!-- VS Press, Param = 5 -->
    			(L:XP850_HW_IF, number) 5 == if{ 
    				1 (>L:BUFFER_BTN_FMC,number)  
    				0 (>C:carenado:AutoPilotAltitudeEnabled) 
    				(A:AUTOPILOT MASTER,BOOL) 0 != (C:carenado:AutoPilotAltitudeEnabled) 0 == and if{ 				
    					1 (>L:ASD_BTN_850XP_VS,number) 
    					(A:Autopilot Nav1 Lock,bool) (>L:NAV,bool) 
    					(A:Autopilot Heading Lock,bool) (>L:HDG,bool) 
    					(L:AUTOPILOT MASTER, BOOL) 1 == (L:ALT_VS_SEL_ON) 0 == and if{ 
    						0 (>L:CUSTOM_AUTOPILOT_AIRSPEED_HOLD, number) 
    						(>K:AP_ATT_HOLD_ON)	
    						(>K:AP_PANEL_ALTITUDE_ON) 
    						0 (>K:AP_ALT_VAR_SET_ENGLISH) 
    						(A:AUTOPILOT VERTICAL HOLD VAR, feet per minute) (>K:AP_VS_VAR_SET_ENGLISH) 
    						(A:AUTOPILOT VERTICAL HOLD VAR, feet per minute) (>L:AP_VS_VAR_SET_ENGLISH) 
    						1 (>L:ALT_VS_SEL_ON) 
    						1 (>L:ALT_SEL_ON) 
    						
    						0 (>L:CUSTOM_AUTOPILOT_AIRSPEED_HOLD_ALT, number)  
    						0 (>L:ALT_ARM_SEL_ON,number) 
    						1 (>L:GAUGE_ALT_ALERT_MODE, number) 
    						(A:VERTICAL SPEED,ft/min) 100 / near 100 * (>K:AP_VS_VAR_SET_ENGLISH) 
    						(A:VERTICAL SPEED,ft/min) 100 / near 100 * (>L:AP_VS_VAR_SET_ENGLISH) 				
    					} els{ 
    						0 (>L:ALT_VS_SEL_ON) 
    						(>K:AP_ALT_HOLD_OFF)	
    						(>K:AP_ATT_HOLD_OFF) 
    						0 (>L:ALT_ARM_SEL_ON,number)  
    						0 (>L:ALT_SEL_ON)								
    					}
    					(L:NAV,bool) 0 != if{ 
    						0 (>K:AP_NAV1_HOLD_ON) 
    					}
    					(L:HDG,bool) 0 != if{ 
    						0 (>K:AP_HDG_HOLD_ON) 
    					}  					
    				} 				
    				0 (>L:XP850_HW_IF, number)						
    				quit
    			}

     

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