Jump to content
The simFlight Network Forums

spokes2112

Members
  • Content Count

    261
  • Joined

  • Last visited

  • Days Won

    10

spokes2112 last won the day on September 11

spokes2112 had the most liked content!

Community Reputation

26 Excellent

3 Followers

About spokes2112

  • Rank
    Advanced Member
  • Birthday 04/03/1967

Contact Methods

  • Website URL
    http://

Profile Information

  • Gender
    Male
  • Location
    -KGRB
  • Interests
    FS Programming, Electronics, Vintage Radios

Recent Profile Visitors

2,924 profile views
  1. An idea for where to look. In the older sims this was defined in the aricraft/sim.cfg under the [autopilot] section.. If the AP master was turned on & no other lateral mode was selected/armed prior, then heading hold would be turned on. default_bank_mode= # This determines the default bank mode when the autopilot logic is turned on. 0 = None 1 = Wing Level Hold 2 = Heading Hold (current heading). If no value is set, Wing Level Hold will be the default Also, use_no_default_bank = # Setting this flag to 1 will cause the default bank mode to be "None". It will actually set the variable default_bank_mode to zero, so that there is no default bank mode when the autopilot logic is activated. The preferred method is to set the default_bank_mode directly. (above)
  2. Just got done testing on the local FS machine, the only way L:Var detection via Lua will work. Works fine except... You should write to the offset as a 32bit float. The frequency values are floats, but they have rounding errors! That can be fixed on the WideFS lua. function writeFDCmdr(varname, value) ipc.writeFLT(0x66CD, value) end event.Lvar("L:CpitCmdrSetValue",100,"writeFDCmdr")
  3. Downloaded and took a quick look at it. Ahh that's it.. My hunch was kind of right. On every one of the click commands (the ones that finalize something) lines 182-366, somewhere in each of those click spots is the command ( an instant reset, faster than 1 msec ) : 0 (>L:CpitCmdrSetValue, number) Your original lua should pick up on each numerical digit as it's pressed and added up only to the point prior to sending to a radio / ap command. Will install his gauge and make a lua for my sacrificial aircraft to test more. Never used excel in FS, probably never will. In all the "weird" stuff i've ever created, either a xml gauge, advanced FSUIPC.ini programming or lua fits my needs. - sorry. Roman EDIT... Are you running this L:Var detection lua on the local or the WideFS machine? If on the WideFS machine it will not work as stated in the FSUIPC Lua Library.pdf. If you run the L:Var detection on the sim machine, then use event.Offset on the WideFS machine it should work then.
  4. This is just a hunch as I have run into this with the MaddogX. I also noticed other advanced aircraft use this procedure. The L:Var "CpitCmdrSetValue" sure does sound like it is a command to do something with the internal programming / logic of the aircraft. EX. Sending the value 12258597 to the L:Var will open the map box, just an example. In the gauge logic it would be something like - ( in XML ) <Update> (L:CpitCmdrSetValue, number) 0 != if{ <!-- Open the map box --> 12258597 (L:CpitCmdrSetValue, number) == if{ <!-- Provide code for animating the map box opening --> } <!-- Close the map box --> 12258598 (L:CpitCmdrSetValue, number) == if{ <!-- Provide code for animating the map box closing --> } <!-- This resets the L:Var --> 0 (>L:CpitCmdrSetValue, number) } </Update> As you can see, if the L:Var is zero it bypasses most of the code. If the L:var is not zero then it will find what value matches, then do something.. After that it resets the L:Var back to zero. This is the key part. The gauge system is much faster (55 msecs) versus the L:Var polling of the lua (100 msecs). What may be happening with you is that yes, the L:Var is changing, but it is returning to zero so fast that the lua is not picking it up. It sounds like you would like to find out what the value is to, later on, maybe do something. IE provide a custom command thru a L:Var or have some kind of indication. If this is the case you could try it in the following Lua. Note - you still may have to toggle the L:Var command a few times before the lua will catch the value, after that, at least, you will have the necessary value. function writeFDCmdr(varname, value) if value ~= 0 then ipc.writeUW(0x66CD, value) end end event.Lvar("L:CpitCmdrSetValue",100,"writeFDCmdr") Again just a hunch.. May be way out of the ballpark too 😉 Roman Yes.. Just assign a keyboard key to the dropdown command "Lua <lua name>" ( not LuaKill, LuaToggle, LuaSet or LuaClear)
  5. Maybe this will help. A few points - - 0x2E80 is 4 bytes = 32 bit = Double Word. Therefore the Offset designator should be a "D" - According to the docs the "0x" for the offset isn't shown in the examples. - Your second entry, 415, is on the release "U", therefore when you press the button it will turn off, if on. Once you will release the button it will turn on again. Avionics already on - Press = 413 turn off, 415 is skipped , Release = 413 is skipped, 415 turn on Avionics already off - Press = 413 is skipped, 415 is skipped , Release = 413 is skipped, 415 turn on This may do it for you - 413=D2E80=1 PF,24,C66701,0 -{AVIONICS_MASTER_SET}- 415=D2E80=0 PF,24,C66701,1 -{AVIONICS_MASTER_SET}- Avionics already on - Press = 413 turn off, 415 is skipped, Release = nothing Avionics already off - Press = 413 is skipped, 415 turn on, Release = nothing Roman
  6. @John Dowson I can only imagine how little hair you have left! 👍😅 @jgoggi Good news! You're welcome. I really like these little projects, even if not for myself. They go well with the morning coffee, it gets the brain cell working again. 😅 This morning I started the version with the landing gear lever, but will stop. 1) If FSL, on the next update, gets this fixed then great! If not, I may revisit the landing gear lever arming. 2) Without the landing gear lever arming the lua above reads these 3 lines every 4 seconds throughout the whole flight. local alt = ipc.readUD(0x31E4) -- get the current RAlt if (armed == 1 and alt > trigger_alt) or (armed == 0 and alt < arm_alt) then -- bypass most of code, nothing valid return It is not much at all in the whole scheme of things but would be nice if it didn't have to read the var / decide for the whole flight. I do have the variable I need to do this but it's output could be reversed, there is no way I can tell, this would make testing a possible "back and forth" chore. ( would the negligible gains be worth it? ) Roman
  7. @John Dowson It is for the FSLabs A320.. Kind of weird problem with this user, maybe others. (here) Just a nice, quick, little project. @jgoggi What is the command for the landing gear lever? Is it the stock P3D landing gear command? If I knew that, it could even get better, if it works in the first place. Right now, the lua is constantly on - getting RAlt values every 4 seconds. Not much really. But, if the landing gear lever was monitored - if the lever was up the lua wouldn't do a thing except listen for the lever being moved. If the lever was down then the lua would monitor RAlt as it does now. Just a little more efficient. Roman
  8. Here's a quick & dirty lua. Maybe someone could put another set of eyes on it or even test it with the Bus. It is far as I can go for the weekend. It has been tested for syntax errors, proper RA conversion to feet & the arm/disarm. Roman -- Special FSL Airbus LL toggle controller, 05SEP20, Roman Stoviak (spokes2112) -- USER ADJUSTMENTS samples = 4000 -- The time between RAlt samples. In milliseconds. wait = 1000 -- The wait time between LLs turning off, then back on. In milliseconds. arm_alt = 2500 -- the altitude (at or above), in feet, where the system will arm. trigger_alt = 1000 -- the altitude (at or below), in feet, where the system will trigger the LL toggle, if armed. -- END USER ADJUSTMENTS armed = 0 -- convert the user RAlt adjustments in feet to the "raw" FSUIPC read RAlt value in meters arm_alt = arm_alt * 19975.3728 trigger_alt = trigger_alt * 19975.3728 function do_it() local alt = ipc.readUD(0x31E4) -- get the current RAlt if (armed == 1 and alt > trigger_alt) or (armed == 0 and alt < arm_alt) then -- bypass most of code, nothing valid return elseif armed == 0 and alt > arm_alt then -- arm it armed = 1 elseif armed == 1 and alt < 998768.64 then -- disarm it if the trigger was never met. IE on, or very close (50 ft.) to the ground armed = 0 elseif armed == 1 and alt < trigger_alt then -- trigger it local l_llit = ipc.readLvar("L:VC_OVHD_EXTLT_Land_L_Switch") local r_llit = ipc.readLvar("L:VC_OVHD_EXTLT_Land_R_Switch") if l_llit == 20 and r_llit == 20 then -- !!! BOTH left and right LLs MUST be ON to trigger !!! ipc.control(66587, 72496) -- turn off left LL ipc.control(66587, 72506) -- turn off right LL ipc.sleep(wait) -- delay between turning off lights, then turning back on ipc.control(66587, 72497) -- turn back on the left LL ipc.control(66587, 72507) -- turn back on the right LL armed = 0 -- disarm the system until next take off / climb end end end event.timer(samples, "do_it") --[[ Notes.. (L:VC_OVHD_EXTLT_Land_L_Switch, number) (L:VC_OVHD_EXTLT_Land_R_Switch, number) LVAR ON = 20 LVAR OFF = 10 LVAR RETRACT = 0 FSL COMMAND = 66587 LEFT LL INC = 72497 LEFT LL DEC = 72496 RIGHT LL INC = 72507 RIGHT LL DEC = 72506 31E4 4 Radio altitude in metres * 65536 ]]
  9. James, Believe it or not I pondered what needed to be done for this with the morning coffee! I also read the thread over at Avsim. I believe it could be done - yes... The problem is, I do not own the FSL Airbus. * If a SDK is somehow available I may be able to help.* With that being said - 1) if the landing light control can be done with L:Vars or stock landing light commands then a XML gauge would be the way to go for sure - if not... 2) then lua would do it, a bit more work in coding, but doable. A hypothesis on operation - Arming - once the aircraft gets above, say, 2500 ft RA the system would arm. ( a cushion for varying terrain ) Trigger - If armed and the aircraft gets below 1000 ft RA then : If the lights are on - turn off the lights and wait for about 1 second or less, turn them back on, then disarm the system. If the lights are off - just wait until they are turned on then do the above. The arm / disarm system is there so the turn off/on procedure is only done once. ( IE not repeating < 1000 ft RA ) * Found the LINDA kit for A3xx-X 1.5 and was able to see what is needed. It can be done in LUA. Won't be able to get into it fully until Tuesday, it is Labor day weekend in the US.. Testing will be tough not owning the aircraft, but again, doable. Roman
  10. The B58 fuel pump hi/lo is fake. In high or low the pump is on, otherwise it is off. It also uses G:Vars (FSX 2D panel) which are not accessible to simconnect/fsuipc/lua. Visual status : (A:General eng1 fuel pump switch,bool) 0 != d (G:Var1) ! * + The click command : (A:General eng1 fuel pump switch,bool) if{ (G:Var1) if{ 0 (&gt;K:TOGGLE_ELECT_FUEL_PUMP1) } els{ 1 (&gt;G:Var1) } } els{ 0 (&gt;G:Var1) 0 (&gt;K:TOGGLE_ELECT_FUEL_PUMP1) } The most confusing code i've ever seen! "If OFF and G:Var is cleared, turn pump ON. If ON set G:Var (for visual HI). If ON and G:Var is true then clear G:Var, finally turn pump OFF " In FS2020 the code in the VC is most likely transposed from the above using L:Vars or S(SP)/L registers. Probably just best to live with OFF/LOW. Roman
  11. Rhys, " I'm using the update nemeth bros model. " Is it one of these: here or here? If so, both use the same logic with the starter. I downloaded both and checked. ( only have FSX here ) Being the case, none of the built in FSUIPC commands will work. You will need to use a lua or .mcro script to do the following : 1 (>L:Eng2StarterSwitch, bool) In XML code, the repeat flag is on so you may want to include that too. It was just a quick look, there is a lot of built in logic ( some very weird ) with these models. If it doesn't work, let me know, can look deeper into it. Roman
  12. Rhys, You could try ( not sure, it depends on the aircraft ) the command "Jet Starter" with a parameter of 1, 2, 3 or 4. ( the engine number )
  13. Not to step on anyone's toes here.. For an interim solution why not use lua? ( available in profiles ) It works pretty good for most programs and is can be timed as wanted ( ipc.sleep(msecs) ). It gets called once, when done, it dies. Some programs can be a pain as they just don't accept a second attribute within the lua for starting ( "start in" ). For those I call a batch file from the lua to do all the work for starting. Works well.
  14. Owen, Yes, exactly.. (page 14-15 FSUIPC Lua Library.pdf) Except, I get the panel name from the panel.cfg to make sure there is no errors caused by display formatting etc.. To see if there are any lua errors you could use the FSUIPC logging, with a second (or more) monitors it is awesome! FSUIPC is the best thing ever created for flight simming )) Roman
  15. In my case (FSX boxed) if the open windows are undocked and placed on primary fs screen when the flight is saved it will work. Prior to saving a flight I have a lua that will do this - -- moves the window titled "GPS /RADIO" to my primary FS monitor, in this case it is monitor 2 ext.position("GPS /RADIO", 0, 0, 100, 62, 2) ipc.exit() Then when I start a saved flight I press a key to run this lua to move it back where it belongs - -- moves the window titled "GPS /RADIO" to my secondary FS monitor, where it belongs in this case it is monitor 1 ext.position("GPS /RADIO", 0, 0, 100, 62, 1) ipc.exit() You can add as many ext.position("name", x, y, cx, cy, screen) commands as needed for each window in each of the luas.
×
×
  • 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.