spokes2112

Simone, It has been a while.. Quite busy. There is a completely redone "string style" FGCP lua in this package. If there is no power the strings become blank. As long as mobiflight accepts everything possible in the MAX7219 chipset then this should work fine. It also includes some of the new l:vars you requested plus some new "helpful" offsets for integration. Also includes options so it can be configured for your current hardware and possibly new hardware. Unfortunately the offset addresses for the displays have changed... again 😞 Must tell you - If this Maddog_X lua is to be expanded any further it should be re-written and all offsets changed. The use of a 32 bit dword for a single boolean is just absurd, should be able to stick 8 l:vars into just 1 byte with the use of mobi flight masking, just my thoughts. Roman

The gauge can/would output lvars for you. From there you could do a lua to display of the values - but - Setting the lookup radius would have to be done via the gauge - or - a default value in the lua. Thinking more, just may run with it as a "fun" type project to do.. An extra "wake me up" for the morning. Will start tomorrow morn - to darn nice outside, finally!! 😉 Roman EDIT - An exe just may/could be made. ( or at least experimented with ) Just checked FSUIPCClientDLL code examples and it "looks" like everything is there. Will go the gauge route 1st to get the code flow then maybe go the exe route.. (it would take a while for the exe)

Ray, This may be a perfect project for a gauge rather than a ipc/simconnect lookup. Using a gauge allows an easy user interface such as distance from current location, etc.. Downside of course is that the gauge needs to be installed in each of your testing aircraft. Since it is just for performance testing, not really a bad downside. All the variables needed are there.. (Referencing FSX, but checked the P3D SDK, all good) P3D References - http://www.prepar3d.com/SDKv4/sdk/references/variables/custom_variables.html FSX References - FSX SDK (not ESP SDK) FSX\SimObjects\Misc\ControlTower\panel FSX\Gauges\Radar.cab ______________________________________________________________________________ C CLASS | CLASS NAME | UNITS | SETTABLE | DESCRIPTION ITrafficInfo | Radius | meters | Yes | The radius from the user aircraft (or tower) to use to collect data on nearby aircraft or vehicles. ITrafficInfo | Latitude | radians | Yes | The latitude of the point the search is to be made from. ITrafficInfo | Longitude | radians | Yes | The longitude of the point the search is to be made from. ITrafficInfo | Filter | enum | Yes | One or more of the following values combined: TRAFFIC_FILTER_AIRCRAFT = 1, TRAFFIC_FILTER_GROUND_VEHICLES = 2, TRAFFIC_FILTER_TOWER_CONTROLLERS = 4, TRAFFIC_FILTER_ON_GROUND = 8, TRAFFIC_FILTER_IN_AIR = 16, TRAFFIC_FILTER_SLEEPING = 32, TRAFFIC_FILTER_AWAKE = 64 ITrafficInfo | ListSize | number | No | The length of the list of vehicles returned after a search. The index numbers of the returned list will be from 0 to ListSize - 1. ______________________________________________________________________________ If you are interested I may be able to help in creating one - a perfect morning coffee project. 😉 ☕ Roman

Even if another brand it should be highly unlikely to use some special commands to do this since they are all on/off and must integrate into flight sim as the sim provides the sound. "Some" of the commands, most likely the ones you would need. from --> \Modules\FSUIPC Documents\The 2016 List of FSX and P3D Controls.pdf ( or similar) RADIO VOR1 IDENT TOGGLE FSUIPC Control # = 65842 RADIO VOR2 IDENT TOGGLE FSUIPC Control # = 65843 MARKER SOUND TOGGLE FSUIPC Control # = 66477 RADIO DME1 IDENT TOGGLE FSUIPC Control # = 65844 (OPT) RADIO DME2 IDENT TOGGLE FSUIPC Control # = 65845 RADIO ADF IDENT TOGGLE FSUIPC Control # = 65846 EDIT - These may be better in your case using on/off toggle switches although it doubles the commands. ie - switch on = a separate button press, as does switch off. Will keep things in sync. RADIO VOR1 IDENT SET FSUIPC Control # = 65847, Switch ON: Parameter = 1, Switch OFF: Parameter = 0 RADIO VOR2 IDENT SET FSUIPC Control # = 65848, Switch ON: Parameter = 1, Switch OFF: Parameter = 0 RADIO DME1 IDENT SET FSUIPC Control # = 65849, Switch ON: Parameter = 1, Switch OFF: Parameter = 0 RADIO DME2 IDENT SET FSUIPC Control # = 65850, Switch ON: Parameter = 1, Switch OFF: Parameter = 0 Switch ON: RADIO ADF IDENT DISABLE FSUIPC Control # = 65836, Switch OFF: RADIO ADF IDENT ENABLE FSUIPC Control # = 65841 Unfortunately the marker sound does not have a "set, enable or disable" so the control above (66477), or a lua to incorporate on/off discreetly, can be used. Hope helps, Roman

Simone, I looked through the topics over at mobiflight and did some studying.. May have found something that will work but you would have to make some compromises. Much, much easier than going to a 14 or 16 segment display. By going back to strings in the lua I would be able to take care of the following: 1) VS - negative sign with preceeding zeros 2) the power problem! NO MORE PRECONDITIONS :), the 7 segment using MAX7219 allows blanks. 3) no more paddings or preceeding zeros 4) ALT - an alternative to the "==" instead use "--", the MD doesn't have negative altitude so no big deal 5) VS - instead of "S, M, P or V" it would be "5, 5, P, H" ( note.. a 5 in a 7 segment is the same as "S" ) the H would represent "height". Below is a chart of the legal characters in a 7 segment display using the MAX7219 chip. Before I start - would you like to go in this direction?

Does the "output value" column (main page in mobiflight) for FGSP_Pwr show correctly? 1 when powered 0 when cold and dark If it does then it is all mobiflight then, cant help much more - dont have it. Just went through another complete test, toggling the left AC bus on each step, the lua seems to work fine. Cold & Dark --> Batt On --> Ground Connect --> APU start --> Ground Disconnect --> Engine(s) Start --> Generators --> AC/DC bus ties --> Engine Stop --> APU --> Ground Connect --> APU Stop --> Ground Disconnect --> Batt Off --> Cold & Dark

Simone, Attached is the new power lua, fully tested and now includes APU or Ground Power affecting the left AC bus - sorry about that.. 😞 Note - If both APU and Ground Power are available, left ground power switch is on, left APU switch on, then you toggle the left APU switch off it may cause a reboot of the AP, FMA & FGCP. No real way to get around this - it is because one relay opens and one relay closes, not exact timing.. In real life I believe the same thing would happen. In reality not a normal procedure anyways. Also the timing is already set to 1 second for you.. Good luck with the mobiflight thing - I believe you are really close to getting this working. Next week I will search for the APU needles for you.. Roman MD_FGCP_PWR.lua

6914 is correct. Do not use the APU for testing! Start left engine and use left generator until I get the lua fixed. It may not be until early next week. If it still doesn't show in mobiflight then the lua isn't being started. Roman

Simone, I think you are getting close but missing one point.. You are applying the/a condition to FGCP Power Interface! A condition to itself.. 1) Keep FGCP Power Interface as a mapping.. (main screen, you will only need 1) 2) Select the properties of FGCP Power Interface --> Precondition tab. REMOVE ALL PRECONDITIONS! - click apply then OK 3) On main window select 7SEGMENT TEST --> Edit 4) In the Precondition Tab remove all preconditions you have now, just in case. 5) Add a new precondition -->Logic = AND, Type = Config Item, Choose config = FGCP Power Interface, Current Value = equal, 1 6) Click Apply then OK 7) Repeat steps 3 thru 6 except using the properties for 7SEGMENT TEST2 --> Edit --> Precondition Tab Did you adjust local timer = # in the MD_FGCP_PWR.lua so you do not have to wait 22 seconds for FGCP boot up? If not, change temporarily to 1 for easier testing. I also missed something, the left AC bus being powered by APU.. For testing make sure you have the engines running and toggle left generator on/off. Will have a modded MD_FGCP_PWR.lua to include the APU only in a short time. Roman

Simone, I edited this post above .. Mainly added a new MD_FGCP_PWR.lua with proper bus use. Here is my question.. Why even worry about the V, S, P, M, ==, or = when mobiflight does not support any thing greater than a 7 segment display? (that is probably why mobiflight shows a "?" in the value fields) There will be nothing to show. That is why I took out all the strings in the lua, in this post and returned to just numeric, leaving it up to mobiflight to zero precede or padding. Another question.. Are you using any other part of the MADDOG.lua other than the FGCP things? Roman

Simone, I have re-checked all the offsets to make sure they work properly - they do.. It is now up to mobiflight to set up properly. Looked at the online manual again. I think it has to do with the precondition tab, without having the software it is difficult to tell. Referring to the online manual I think (??) your setup should look like the following picture.. Also.. I made a mistake - oops. Spent a little time actually flying that hound dog. :) The FGCP is actually powered by the left AC bus not the left DC - the FMA relies on the left DC. That means both left AC & DC buses must be powered for proper AP, no matter though, if the left AC bus is powered in any way so will the left DC. But... The left DC can be powered without left AC if the right AC is powered and the DC buses are tied. In this case only the FMA is powered, the FGCP is not. A new, tested lua is attached. A tip.. In the MD_FGCP_PWR.lua, change the timer setting to 1 for easier testing with the left AC bus. Return it to a value as wanted (22 ?) afterwards. Ex. local timer = 1 Sorry, can't help much more.. Roman MD_FGCP_PWR.lua

What you have will work nicely.

Simone, Looked at the mobiflight documentation.. It seems it does not have support for greater than a 7 segment display. (???) That means using the string build in lua will not work.. Neither will the "substring" settings in mobiflight. I did however, reassign the offsets again.. 😞 This was in order to keep the lua available to anyone with all features, offsets in order and not conflicting, they can mod as wanted. The offsets for the FGCP are now as follows - SPD = 0x6908 as UD HDG = 0x690C as UD VS = 0x6910 as SD ALT = 0x6904 as UD In mobiflight use them as integers and use the built in settings for any padding or preceding zeros as needed. --------------------------------------------------------------------------------------------------------------------------------- As for the FGCP being powered a separate lua is provided with an adjustable timer. (my boot up time was 22 seconds) The FGCP is on the left DC bus and it monitors that regardless on how it gets powered up (l, r gens, ac bus tied or not, apu tied or not etc..) It must be on a separate lua because of the time delay, otherwise it would cause the MADDOG_X lua to become unresponsive in that time period. Use [Auto] in the fsuipc5.ini to have it start automatically. FGCP POWERED UP = 0x6914 as UD (1 = powered and ready, 0 = not powered) I believe you can use the mobiflight software to configure this --> FSUIPC --> (each display set - SPD, HDG, VS, ALT) --> Pre-Condition Tab Do not use the the "string" version of MADDOG_X.lua with this.. It will interfere. Roman MADDOG_X.lua MD_FGCP_PWR.lua

John, May you have meant? - "hide extensions for known file types". Control Panel -> Appearance and Personalization -> Folder Options -> uncheck - hide extensions for known file types That will give the ".log" extension back to the text file. Roman

Simone, L:vars do not support characters at all. But.. If your software to hardware interface accepts strings then this version may work for you. The strings are built up in the lua then written to the offsets. Ran into big problems, there were some duplicate offsets in the lua causing complete havoc so the main FGCP offsets have been re-assigned. Also needed some extra room for the strings. ALT was 0x68F0, shared with Fire Agent 1, now it is at 0x6904 as a STRING with a length of 5. SPD was 0x68E8, shared with Fire Agent 1 Low, now it is at 0x6909 as a DWORD (unchanged type) HDG was 0x68EC, shared with Fire Agent 2 Low, now it is at 0x690D as a STRING with a length of 3. Changed to string in order to format as "001, 023, 359" etc.. VS was 0x68F4 (big problems with this one), shared with Fire Agent 2, now it is at 0x6911 as a STRING with a length of 6. The next available offset for other things is 0x6913. Here is a video showing the string build in action - https://www.dropbox.com/s/ygu0lj9mnl6tj81/MD80_FGCP_LUA.mp4?dl=0 MADDOG_X.lua Hope this may do it for you, Roman

Simone, It is because of the [Auto] entry in your FSUIPC5.ini - [LuaFiles] <-- This is the inventory of all your .lua files in the modules folder, do not change.. It is automatic. 1=MADDOG_X [Auto] <-- This will auto start the lua (and other) files, as entered below, when the sim starts. In this case it is the wrong name. 1=Lua MADDOG If you want to go with the original MADDOG_X.lua name then.. With the sim closed rename the lua file to --> MADDOG_X.lua Open up your FSUIPC.ini file in a text editor and change to the following --> [Auto] 1=Lua MADDOG_X Restart the sim. Glad the lua works for you !! 👍 Roman

Wrote a little VB program to convert Simone's original lua to the new style. That took care of a lot of the work quickly :) Yes a lot of events. During logging, watching it load, it took quite a few seconds. Then once it loaded the event listeners took over updating everything - a couple more seconds.. After that it was smooth & responsive. :) I have never seen L:var names change between 32 & 64 bit sims.. XML stays constant between the 2. Ooops.. Yes, that is what I meant. I just hope that the new lua will help Simone. Roman

Pete, I think this is how he's doing it - MaddogX custom values (non-FS) --> Lua --> FSUIPC Offsets --> Mobiflight <--> Arduino --> Hardware Looked at the Maddog L:vars in the model using a hex editor to find data type to "try" to reduce FSUIPC offset use. It was found that there is too much data to use the "user" available offsets. The original offsets are being used in the "reserved" area. ( they worked before, not correct though!) It is unknown if the Mobiflight/Arduino software will read anything other than a double so the data types remains unchanged. Simone, Reworked the complete lua file & updated all the lvars to MaddogX, tested and it works (see FSUIPC.log) writing to the same offsets that you originally provided. The lua has a plethora of notes within. Attached below. Hope it helps, Roman MADDOG_X.lua MADDOG_LVAR_LIST.txt FSUIPC4.log

Is this the full lua script? Probably not as there is an "end". Might be better to show the whole script. Are you using "event" listeners? If not you should. "Event" listeners will trigger only when the value has changed. It seems like you are loading script this each time any l:var is changed or it is on a constant loop, either will cause delays. The free to use offsets are 0x66CO - 0x66FF. (Modules\FSUIPC Documents\FSUIPCx Offsets Status.pdf) Another thing noticed is your offset types, maybe(?) use the following to save available user space - - UB for the cautions - UW for speed and heading - UD for altitude - SW for VS Just an example of using listeners and proper offsets. Load this lua using [auto], leaving it running while flying the maddog. --GLARESHIELD ---------------------------------------------------- --WING function md_warn (varname, value) ipc.writeUB(0x66C0, value) end function md_warn (varname, value) ipc.writeUB(0x66C1, value) end --GUIDANCE IPC function md_speed (varname, value) ipc.writeUW(0x66C2, value) end function md_hdg (varname, value) ipc.writeUW(0x66C4, value) end function md_alt (varname, value) ipc.writeUD(0x66C6, value) end function md_vs (varname, value) ipc.writeSW(0x66CA, value) end event.Lvar("L:masterwarn_adv1", 100, "md_warn") event.Lvar("L:mastercaut_adv1", 100, "md_warn") event.Lvar("L:md_ipc_ap_spd", 100, "md_speed") event.Lvar("L:md_ipc_ap_hdg", 100, "md_hdg") event.Lvar("L:md_ipc_ap_alt", 100, "md_alt") event.Lvar("L:md_ipc_ap_vs", 100, "md_vs")

A shameless plug 😞 .. You could always use this little kit, nothing more than a mod of Pete's included lua examples. Just monitor the L:Var you want - if it is not there the lua will die gracefully, otherwise if the var is there a window will show it's status. Basically all you need is the "LVAR_SPECIFIC" portion of the kit since you know the L:Var name.. Assign a key to start it repeatedly until you get a value. Roman

Gene, You could, as an option, use the available "LuaValue <my lua name>" assignment under "Type of action required" field on the left side of the "Axis Assignment" tab of the FSUIPC user interface. Basically you are assigning the values of the slider to be applied to the lua. Any slider value change is caught by the event facilities in the lua library and sent to the called function. BTW, the event facilities are the "cats meow" . 👍😸 Have the lua be autostarted via [Auto], preferably in profiles. Then, in the lua - function carbHeatAxis(val) val = val --[[plus any required math to get the correct values]] ipc.writeLvar("Eng1_CarbHeatSwitch", val) end event.param("carbHeatAxis") Hope this helps, Roman

Ummm.. OK :) Favorite album of all time... In high school, my locker was #112 on the second floor During a very long hospital stay, many moons ago, i was on floor 2, room 11, bed 2. O - U - BETCHA! RE: problems.. I always try for the single lua. Saying that, you may want to take a look at the COM functions in the lua library.. Using those to "pre-run" a script to get everything synched to your switches, followed by another lua to detect switch changes after the "pre-run" synch. Never used the COM functions so it is way above my pay grade. Using a loop to actively check the states of your hardware, all the time, would probably be out of the question, bringing flight sim to a stuttering crawl. BTW.. when is spring? hehe

In the FSUIPC dialog you can type in search params in the dropdown text box to get you where you need in the drop down. IIRC it takes the first 3, maybe 4, max letters typed in - "lua" - gets you to the root lua listings "luat" - may get you to the root of lua toggle listings

Hi all, 3 of the 4 lua's I wrote or helped, 2 are hardware interfaces to specific aircraft where L:Vars are necessary to interface (E2CECU.lua, DC_F14D_CMDS.lua) and 1 is a selectable axis via a button. (MAxisThrottle.lua) The rest of the log is all from poor, very poor, gauge coding.. Flooding the sim with commands. They should be getting the current state before writing a new state. In pseudo XML syntax they are doing -- blah blah blah if{ 12 (>K:FUEL_SELECTOR_SET) } when they should be doing -- blah blah blah (A:FUEL TANK SELECTOR 1, number) 12 != and if{ 12 (>K:FUEL_SELECTOR_SET) } Being Captain Sim, it is likely (don't know, don't have) that nothing can be done as they usually use C++ type gauges. A2A is another company that floods the sim quite often. A shame.. Roman

Nothing that you would like.. Either you can have have F11 (or whatever) as a spot view or as a pedestal view, not both. The reason is that AS is using the STOCK "spot view" ( "View Camera Select 3" ) as the pedestal view, overriding the stock spot view. This is also hard coded in the view select window as you showed. Clicking on the pedestal (#8 picture) provides the command "View Camera Select 3". Either have a button/key for spot view and use the "Sim" view menus for a pedestal view - or- keep AS's view setup and use the "Sim" view menus for spot view. There is one way to get both to work but it will globally change your entire sim. Not worth it. Another way is to recode the AB_Panelbar gauge (the view select window) to use the only (they used 9 of the possible 10) unused view command - "View Camera Select 4" and reconfigure the pedestal camera definition to - Hotkeyselect= 4. Doing this may render another unknown stock view command useless too. Did these tests using my friend's sim, sorry, cannot help anymore. 😞 Definition #s do not apply to the "view select #" commands, the definition entry "Hotkeyselect=#" does this. On the other hand, Definition #s do provide the order in the sim's view menu. Roman