Jump to content
The simFlight Network Forums

Gypsy Baron

Members
  • Posts

    278
  • Joined

  • Last visited

  • Days Won

    10

Posts posted by Gypsy Baron

  1.  

    You aren't confusing the 'delay' and 'color' parameters are you? You entry has color set to 1 and delay set to 0.

    ipc.display may not like a delay value of '0'. Try changing that to'1' and see if it works.

     

    Also, there is no need for paran's around the gnd == 1 or gnd == 0 entries in the 'if' statement.

    What is the purposes of the 'return' statement?  There is nothing to return.

    I would write that function like this:

    function runMessage(event)

        local gnd = ipc.readSW(0366)  
        if gnd == 1 then
            ipc.display("you are on the ground and the offset was read correctly", 1, 1 )       
        elseif gnd == 0 then
            ipc.display("Landing Lights ON: .. message here", 1, 1 )        

        end
    end

    Another thing that may be an issue is the use of the ... message here". If that is meant to be some previously defined message then it should read:

    ipc.display("Landing Lights ON "..message, 1, 1)

    This would display whatever the 'message' was defined as. If that wasn't your intent then I would not use the double periods just to insure that they aren't being misinterpreted.

     Paul.

     

    • Upvote 1
  2. Hello Pete. I have a question, or more a clarification, regarding Lua scripts in the Modules folder. I currently see 44 '.lua' files there and my FSUIPC4.ini file lists 57. Obviously I have moved some unused files out of the Modules folder but FSUIPC4 still maintains the list with the previously assigned numbers.

    In an effort to reduce 'clutter' in the folder and the INI file,  I would like to remove several more unused 'test' and out dated files. If I deleted the current list in the INI file I suspect FSUIPC4 would generate a new list with contiguous numbers BUT, would it also 'correct' the numbering throughout the file, changing the previous 'CLxx' numbers to the new numbers?

    I am suspecting that the case for the automatic renumbering all the 'CLxx' entries is 'no' but I just want to clarify that before I start a massive effort to first create a new list, keeping the order of occurrence the same and then doing a massive 'find and replace' series of operations on my 7241 line FSUIPC4.ini file translating the old list numbers to the new list numbers, starting from the lowest number (first entry) to the last.

    My plan is to build the 'new list' by hand by removing the unused entries and then renumbering the entries. Then 'find and replace' all instances of the old 'CLxx' entries with the new 'xx' numbers. Does this seem to be a reasonable approach?

      Paul

     

  3. I use the "HotKeySelect=x" statements appended to the Aircraft.cfg file "[CameraDefinition.00Y]"

    entries for the VC views I want to access with a flick of the thumb on the 2nd hat switch of

    my X-45 stick. Once you add those HotKeySelect statements with "X" = 4,5, 6, 7, 8 or 9

    you then go to the Controls Menu, Buttons / Keys and select the Event Category "Views"

    Near the bottom of that list you will see several "View camera X (select)" entries. Highlight

    the one where X matches your HotKeYSelect number and select "New Assignment"

    Activate the hat switch you want to use for that view.

    I assign my 'left' switch to the default VC view F9 key. Right switch to the Co-pilot

    if there is one.

      Paul

    Example of the HotKey entry:

    [CameraDefinition.001]
    Title = "Co-Pilot"
    Guid = {8ff6c134-098d-409f-baec-caba3f683f98}
    Origin = Virtual Cockpit
    MomentumEffect = YES
    SnapPbhAdjust = Swivel
    SnapPbhReturn = False
    PanPbhAdjust = Swivel
    PanPbhReturn = False
    Track = None
    ShowAxis = FALSE
    AllowZoom = TRUE
    InitialZoom = 0.7         //0.4
    SmoothZoomTime = 2.0
    ZoomPanScalar = 1.0
    ShowWeather = Yes
    XyzAdjust = TRUE
    ShowLensFlare=TRUE
    Category = Cockpit
    Panacceleratortime=0
    PitchPanRate=40
    HeadingPanRate=40
    InitialXyz=0.90, 0.0, 0.0
    InitialPbh=20, 0, 0
    HotKeySelect=5    <========================

     

    • Upvote 1
  4. 6 hours ago, edpatino said:

    Hi Paul. This looks interesting!.

    Could you provide a little help on how to write down this script into FSUIPC (I guess), or some sort of guidance?.

    Thanks in advance.

    Cheers, Ed

     

    Hello Ed,

    To use the script simply copy and paste it into a text document using notepad or any other text editor.

    Then SAVE the file to the FSX Modules folder with the extension '.lua'. You can name it whatever you wish but for an example let's call it VAS.lua. Once saved then open the FSUIPC INI file and add the following lines:

     

    [Auto]
    1=Lua VAS          or whatever you named the file

    This will cause the script to run when FSUIPC loads.

    I use the Windows title bar to display the contents of offset 0x66C0, which is the location that holds my 'mode' number. I have multiple assignments for each of my Controller switches. Anywhere from 8 to 13 or 14 for each switch. Typically over 100 for each aircraft. I have dual Saitek throttle quads and I can take a complex aircraft like any of the A2A Accu-sim birds from cold and dark to getting airborne without having to use the mouse or the keyboard. All done via the conditional assignments made possible by FSUIPC and 10 switches plus 2 to INC and DEC the mode. I also use the pinky switch on my X-45 stick as a further conditional modifier, effectively doubling the number of assignments for each mode.

    This script only displays the VAS when the low limit is reached. It pops up in a small Lua window and remains for 2 seconds. I would never hear the FSUIPC OOM warning dings over the engine sounds of the four radials of my A2A B-17 or the L049 Connie along with the TeamSpeak chatter, since I fly almost exclusively on line. I also have another XML gauge that is always open on my display and a small section of that gauge displays either the current VAS or the wind speed and direction. I make use of Lua scripts to display my current controller assignments when I switch 'modes' or on demand by hitting F10. That way I do not need a 'cheat sheet' to remind me what the current 10 or 20 assignments are for my switches. One other thing, you can define the size and location of the Lua window by adding this line just after the "Function" statement in the script:

      ipc.setdisplay(770, 50, 500, 100)

    Those are the X and Y offsets followed by the X and Y size. I didn't include that in my listing as I actually define this in other scripts that I have for each of my aircraft that always runs.

    Just PM me if you have any more questions or issues.

     Paul

  5. "I think you can actually force Windows to do a memory "defrag", but I think that would cause pausing. Maybe that could be done as an add-on control, so you instigate it and hence expect the pause"

     

    I would be interested in seeing this implemented if it would force a 'recovery' of memory no longer in use by FSX, thus helping to prevent an OOM error from occurring. Currently, when I get the notice of my "LOW VAS" warning which I have arbitrarily set at 500 MB my only recourse is to either 'look up' or somewhere inside the VC until that VAS number increases some or to minimize the FSX window which usuaslly increases VAS somewhat.   After that it is 'Save flight' and 'reload' the flight which induces a very big ;pause'!

     

      Paul

  6. That value is already available via an offfset, 0x024C, an unsigned word.

    I have a small lua script that displays the current VAS when it gets below 500MB.

    I also write it to an L:Var for use in another gauge I have in all my aircraft that gives

    me a continuos readout of the current VAS.

     

    function VAS(control, vas)
    
        vas_in = ipc.readUD(0x024C)
        ipc.writeLvar("L:VAS", vas_in)
    
    	if
    	   vas_in < 500000 then
    	   ipc.display("VAS = "..vas_in,2)
    	end
    
    end
    
    event.offset(0x024C,"UW","VAS")
    event.timer(10000,"VAS")

      Paul

    • Upvote 1
  7. Pete is correct in that A2A Accu-Sim aircraft systems are coded outside the realm of FSX in a great many cases.  Some of the simulation uses the default FSX functions but anything to do with the physics of flight or engine performance is most likely done within the Accu-Sim code.

    In those cases, use of the appropriate L:Vars (local variables) might be required to monitor items of interest.

     

     Paul

  8. Pete, there are a great many folks that appreciate your efforts, even more so now that you fully support FSX:SE and P3D. Being and 'old assembly language' programmer, I can fully appreciate your efforts and it is rather sad that the only time folks come forth with praise is after someone denigrates you and your magnificent product(s).

    Please understand that although the notes of appreciation are not always forthcoming, the sentiment is definitely there.

    I, for one, could not imagine trying to 'fly' my many FSX aircraft without the ability to multiply 10X the functions assigned to my controllers through the use of conditional assignments and Lua scripts. The ability to map 2,3, 4 or 10 or more functions to a single controller button/switch would be impossible without FSUIPC4 and the powerful 'extensions' you have provided us with.

    I encourage others to 'invest' in the registration of FSUIPC4 to 'unlock' the power of the product whenever someone asks about the usefulness or asks a 'how to' question about controllers and assignments in FSX. Thus I am, in effect, showing my appreciation for your efforts in those various other forum posts that I make. Rest assured, Pete, that you are greatly appreciated by a vast majority of the users of FSUIPC4 neven though they, like myself, fail to make that known here.

    Thank you for your continued development and support over all these years, and do enjoy your vacations to the fullest!

     

     Paul

  9. FSUIPC 4.957b which I just updated to earlier after seeing the issue on the version I had been running, which was perhaps 4951.

    Here are the sections I tested. I have been using this technique for years and just noticed the action discrepancy as I began setting up and testing a new aircraft.(Designated by XXXX here)

    268=B66C0=9 CP(-C,6)A,2,CM25:90,0     -{Macro A2A_XXXX: L:FuelDumpLeftLeverState dec}-
    269=B66C0=9 CP(-C,6)A,3,CM25:91,0     -{Macro A2A_XXXX: L:FuelDumpRightLeverState dec}-
    270=B66C0=9 CP(+C,6)A,2,CM25:100,2     -{Macro A2A_XXXX: L:FuelDumpLeftLeverState inc}-
    271=B66C0=9 CP(+C,6)A,3,CM25:101,2     -{Macro A2A_XXXX: L:FuelDumpRightLeverState inc}-

    385=B66C0=1 CR(+C,6)D,14,CM25:102,99     -{Macro A2A_XXXX: L:Eng1_CarbAirLever inc}-
    386=B66C0=1 CR(+C,6)D,16,CM25:103,99     -{Macro A2A_XXXX: L:Eng2_CarbAirLever inc}-
    387=B66C0=1 CR(+C,6)D,18,CM25:104,99     -{Macro A2A_XXXX: L:Eng3_CarbAirLever inc}-
    388=B66C0=1 CR(+C,6)A,0,CM25:105,99     -{Macro A2A_XXXX: L:Eng4_CarbAirLever inc}-
    389=B66C0=1 CR(+C,6)D,15,CM25:106,0     -{Macro A2A_XXXX: L:Eng1_CarbAirLever dec}-
    390=B66C0=1 CR(+C,6)D,17,CM25:107,0     -{Macro A2A_XXXX: L:Eng2_CarbAirLever dec}-
    391=B66C0=1 CR(+C,6)D,19,CM25:108,0     -{Macro A2A_XXXX: L:Eng3_CarbAirLever dec}-
    392=B66C0=1 CR(+C,6)A,1,CM25:109,0     -{Macro A2A_XXXX: L:Eng4_CarbAirLever dec}-

    I also used an spare non-compounded switch pair to test one of those L:Var operations:

    Here is where I saw that a -1 worked OK for the lower limit but not '0' and I reduced the upper limit from 100 to 10 just to doule check that action and it was OK.

    -{========================================================================}-
    611=PE,32,CM25:102,10     -{Macro A2A_XXXX: L:Eng1_CarbAirLever inc}-
    612=PE,36,CM25:106,-1     -{Macro A2A_XXXX: L:Eng1_CarbAirLever dec}-

    Paul

     

     

  10. Just to help clarify, much of the A2A Accu-Sim code is done 'outside' of FSX so the

    standard A:Vars often are not representing what the Accu-Sim engine is doing. The user

    needs to use the L:Vars to obtain the 'accu-sim' data for use in any custom gauge/display.

    Also, reading the L:Var data and writing it to a 'normal' FSX offset may not work if FSX is

    updating that offset. It does appear that the OP is attempting to save the data to user-defined

    variables, which should work, but the lua script is rather 'untidy' and difficult to read so I can't

    really do much in the line of checking for errors in the script without reformatting the script.

    As much as I would like to help, I am about to head to the airport in a few hours for another

    'vacation' I just don't have time to investigate his issue.

    Paul

    Just a quick thought....how is the script in question being launched? I see no 'on event' or

    any other means to launch the script. When I use scripts I use 'functions' that are triggered

    by events, time,offset changes, etc. . This script is just 'hanging there'.

    Another EDIT>

    I just noticed that it appears there is a missing "end" in the script. The single 'end'

    there is not 'bold' in my script editor like all the others that are properly 'paired'.

    Adding an 'end' before the 'sleep' seems to satisfy the situation, then I looked further

    and inserted what appeared to be an if-then-else segment without a terminating 'end'.

    I just can't remember now where I placed it.

    I'll try to attach my edited script here.

    Oh, and please use indentation to differentiate the various if-then-else-end

    segments for easier reading/debugging.

    A2Agauges.zip

  11.  gr8guitar,


    Here is an example of a small Lua script I use to read the VAS data
    at offset 0x024C and store it to an L:Var.

    I then use that L:Var in an XML gauge to display the current VAS so
    that I have a constant readout while flying. The display will change
    color from white text to red text when VAS gets below a pre-set amount.

    When VAS gets below 500000 the Lua script will display the low value as

    well as the XML display turning 'red'.
    =======================================================================

    function VAS(control, vas)

        vas_in = ipc.readUD(0x024C)
        ipc.writeLvar("L:VAS", vas_in)

        if
           vas_in < 500000 then
           ipc.display("VAS = "..vas_in,2)
        end

    end

    event.offset(0x024C,"UW","VAS")

    =====================================================
    The XML code is here, which is part of a gauge that I created to
    do a number of things. Just the VAS postion is shown here. The
    BMP is just a rectangle with labels, etc for the various items
    that I display.

    <Gauge Name="DME" Version="1.0">
    <!-- Version 1.2 29 November 2012  P.D. Strogen  -->
    <!-- Fixed the relative bearing drift correction code 11/24/12 -->
    <!-- Added red outline when the Norden Alert Light is triggered 11/27/12 -->
    <!-- Added Alarm Bell and Gear Lamp to the Alert state 11/29/12 -->
    <!-- Added conditional statement for drift calculation 12/30/12  -->

       <Image Name="Dual_DME_Background.bmp"/>

    //========================== DISPLAY VAS ===================================
       <Element>
          <Visible>(L:VAS, number) 499999 &gt; </Visible>
          <Position X="25" Y="138"/>
          <Text X="80" Y="12" Length="8" Fixed="Yes" Font="arial" Adjust="Left" VerticalAdjust="Top" Color="#EAEAEA"   Bright="Yes">
        <String>%((L:VAS, number))%!07d!</String>
          </Text>
       </Element>    
           

       <Element>
          <Visible>(L:VAS, number) 500000 &lt;</Visible>
          <Position X="25" Y="138"/>
          <Text X="80" Y="12" Length="8" Fixed="Yes" Font="arial" Adjust="Left" VerticalAdjust="Top" Color="#FF0000"   Bright="Yes">
        <String>%((L:VAS, number))%!07d!</String>
          </Text>
       </Element>   
    </Gauge>

    ====================================================

    The Lua  -> XML process is pretty straight forward. You can do all
    your necessary calculations in the Lua script or later, in XML.

      Paul

  12. You can use the FSX Weather tab from the menu in Free Flight to create custom weather....cloud layers, wind layers, visibility layers, etc.

     

    It is fairly easy to do. I have been using this lately tom create custom weather for MultiPlayer flights after having spent a lot of time trying various free weather programs and also the FS2004 SDK "WMaker.exe" program.

     

    All were seriously lacking when it came to having all aircraft in the session seeing the same weather. Particularly wind direction and velocity for formation flying on our WWII missions (91st Bombardment Group).

     

    Now I create a basic weather theme with WMaker, then load that and modify it by setting weather at all the stations along the flight plan route. I then save the flight with a particular name related to the mission. i.e. M133_WX. I then pass the M133_WX.WX file to all the pilots that will be flying and they save a flight with the same name and substitute the WX file that I created.

     

    So far we have had excellent results with everyone seeing the same weather conditions.

     

    For single player/free flight you can open the "Weather" tab and select Customize. Then you should see a map with the weather stations shown. You click on a station and set the conditions for that station. First I would select the option to set all stations and after that is done you can 'tweak' the individual stations.

     

    Paul

  13. For Multiplayer traffic information you can use the "ITrafficInfo" command plus many others in the FS9GPS module  in an XML gauge..

    The FS9GPS functions are in the fs9gps.cab gauge which you should find in your FSX/Gauges folder.

     

    You can download the guidebook from the link below for definitive information on how to use the various features.

     

    http://www.robbiemcelrath.com/fs/guides/gps

     

    I use these to get a lot of info on Multiplayer aircraft for display on a modified radar gauge. Most

    of these radar gauges/maps are based upon the Acceleration ATC radar gauge. Have a look at

    the XM:L code in it to get an idea of what one can do.

     

     Paul

  14. Whenever I had a 'disconnect' on one or both of my throttle quads the 'green lights' were

    either of or coming on for a second and then going off for a few and repeating.

     

    If you have steady green lights that tends to say the quads are being seen. It just may be

    that you have a defective quadrant. Unfortunately it is the one with the proprietary connector

    so you can't move it to another port to test it.

     

    I assume that yur yoke and the buttons on it are seen and working in the FSUIPC4 assignment

    menus (Axis and Buttons  & Switches). If so that sure seems to point to a defective quadrant.

     

     Paul

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