spokes2112

Look in fltsim root\modules\FSUIPC Documents\FSUIPC4 Offsets Status.pdf for the standard flight sim offsets. If using the PMDG for your sim you may have to look at the SDK for offsets that are custom.. See ->

I believe this is the way to do it, new at profiles myself. Can't believe it took this long.. [General] ShortAircraftNameOk=Substring <-- Sets FSUIPC to find only part of the Title=" " (aircraft.cfg) name for profiles Go through your aircraft.cfgs to find a common keyword for each aircraft type and append to the list below. [Profile.TwinTProp] <-- General name of the profile 1=Twin Otter <-- List of "keywords" to match in the aircraft.cfg title in order to load the profile 2=DHC-6 3=King Air 4=B350 5=B90 6=C90 7=An-28 8=Do 228

Hi Joan, Just retried the lua code above to see if there was a copy/paste problem. No - works fine. Said before I am still on FSX with FSUIPC v4.974b, anyway there is a setting in this version to change the affinity mask for lua scripts - LuaAffinityMask=0 It was stated in the history document for 4.974 but nowhere else, maybe consult your documents and see if it it is available for v5.xxx. If available maybe give it a try. Good luck with you Roman

Joan, You are welcome. I just hope I can help. BTW - I am testing in FSX with the stock MS B737 and the original code above just did not work. It has now been updated with new code. Some really weird things going on. Give that one a try instead. If the AS Airbus uses SDK compliant variables it should work. If they're using some highly custom coding then it may not.. Roman _________________________________________________________________________________________________________ Pete, Some really weird things going on here.. vers - 4.974b, tested on MS B738 0x0BBA - SW, Rudder control input: –16383 to +16383 0x0C0A - SW, Rudder input value, -16384 to +16383, if calibrated 0x332C - SW, Rudder Axis input value, post calibration, just before being applied to the simulation (if allowed to by the byte at offset 310A). 64103 - fsuipc rudder 65764 - rudder axis set 65696 - rudder set The joystick axis for rudder was removed in the axis assignment & joystick calibration pages to test - keep from interference. 1) The FSUIPC "internal" command 64103 doesn't seem to work at all regardless of any of the 3 read offsets listed above. (Big questions here!) Used at the end of function "moveRudder" -- ipc.control(64103, rudderPos) replacing the offset write as shown above, all other code was the same but trying all 3 read offsets. 2) The command 65764 is weird, for the 0x332C & 0x0BBA reads it seems the read gets reset to zero after the command, therefore travel is limited to -2048 to 2048. The read at 0x0C0A just gave completely unreliable results altogether. 3) With the command 65696, the reads at 0x0C0A & 0x332C seems the read gets reset to zero after the command, therefore travel is limited to -2048 to 2048, same as above with different reads while 0x0BBA gave completely unreliable results altogether. In the end just read & writes to 0x0BBA were used reliably... (so confused!) Roman

Joan, That seems correct. This particular script is a "run once", meaning each time the command is given to move the rudder the script also kills ( ipc.exit() ) itself then reloading on the very next command, and over & over... Looking at the version number this was made back in 2012. Back then it was probably the only way to make this script work and is very inefficient. Similar to killing a windows program by using the Windows task manager and ending a process forcefully. Since then Pete has incorporated event "listeners" where the script is loaded via [Auto] or [Auto.<profile>], it stays running, listening for commands. I am assuming a rewrite would help alleviating the stutters. Here is a new script, not tested "yet" (a very busy morning) - -- USER ADJUSTMENT, AMOUNT TO MOVE RUDDER local rudderStep = 2048 -- END USER ADJUSTMENT local rudderPos = 0 function centerRudder(flag) ipc.writeSW(0x0BBA, 0) end function moveRudder(flag) rudderPos = ipc.readSW(0x0BBA) -- RUDDER LEFT if flag == 2 then rudderPos = rudderPos - rudderStep rudderPos = math.max(rudderPos, -16383) -- RUDDER RIGHT else rudderPos = rudderPos + rudderStep rudderPos = math.min(rudderPos, 16383) end ipc.writeSW(0x0BBA, rudderPos) end event.flag(1, "centerRudder") -- CENTER event.flag(2, "moveRudder") -- MOVE LEFT event.flag(3, "moveRudder") -- MOVE RIGHT STEPS 1) Get the lua running by either using [Auto], [Auto.<profile>] or a key command via the FSUIPC interface "Lua <lua name>" 2) Center rudder - Assign the command via the FSUIPC interface "LuaToggle <lua name>" with a parameter of 1, repeat is optional 3) Left rudder - Assign the command via the FSUIPC interface "LuaToggle <lua name>" with a parameter of 2, repeat is checked 4) Right rudder - Assign the command via the FSUIPC interface "LuaToggle <lua name>" with a parameter of 3, repeat is checked Hopefully this works for you. Will test later this afternoon when I return. If this new lua does not get rid of stutters then the AS Airbus is overloading simconnect in some fashion. Roman

Hi Pete, Can't believe after all this time I haven't used profiles. With all my lua files (30+) made for specific aircraft it was starting to become a nightmare - not any more! 👍 One thing I noticed, and was the assumption it would work, is the use of [General] ShortAircraftNameOk=Substring along with UseProfiles=Files. I have in the main .ini - [Profile.T-6 Texan] 1=A2A North American T-6 Texan RTW_9 2=A2A North American T-6 Texan RTW_5 [Profile.Bearcat] 1=F8F-2 Bearcat FSX V2 Worn OD RTWR Panel 2=Grumman F8F-2 Bearcat VF-61 RTWR Panel [Profile.SHRS] 1=22_SHRS_YFB-111A 2=17_SHRS_F-111F If I select any other SHRS, Bearcat, T-6 Texan other than what is listed specifically, the profile doesn't engage. Otherwise it works for the specific listed aircraft. Is this the way it is supposed to work? Just realized something but don't have time to test, is the following the key to it working? [Profile.T-6 Texan] 1=T-6 Texan [Profile.Bearcat] 1=Bearcat [Profile.SHRS] 1=SHRS Thanks, have a great day.. Roman EDIT -- The latter was true.... 👍👍👍😄

Hi Pete, He posted over at Avsim, it's another case of Microsoft using custom code for the mach/speed/co buttons. Not only did they use L:vars but also G:vars!! That means lua is not available unless the AP is recoded slightly. Just FYI Roman

Hi Pete, Xml gauges use RPN (reverse polish notation) for arithmetic, just to make it more fun.. LOL! 1st subtract 180* from the radial. Radials go outbound from station, we need inbound. (A:NAV1 radial, degrees) 180 - dnor = is a degrees normalize operator.. It automatically does - If greater than 360 then subtract 360, if less than zero then add 360. (A:NAV1 radial, degrees) 180 - dnor Send it to the VOR1 OBS control. (A:NAV1 radial, degrees) 180 - dnor (&gt;K:VOR1_SET) Just FYI.. Have fun with XML :) but what you do / use is much more powerful!

Hi Pete, Yes it should all be in the SDK / PDK. A short explanation to start - A: vars = Aircraft variables: read P: vars = Program variables (eg Sim Rate) sometimes included as E: type vars: read E: vars = Environmental variables (eg Time) : read G: vars = User vars 1-9 local to the gauge only: read / write L: vars = User vars global to all gauges: read / write M: vars = Mouse parameters (eg location XY, click type) : read K: vars = Key code (eg commands to sim): write There are a couple more advance ones, R:vars & C:vars, the latter used in the GPS xml to interface with the gps.dll When writing to vars - G: L: K: in xml - &gt; is the same as > just like in html Have a great day!

Hi Pete... The G1000 is in xml so all the L:vars should be visible to lua. All the rest can be done with offsets - (A:GPS drives NAV1, bool) --> 0x132C (P:Absolute time, seconds ) --> 0x0230 (A:NAV1 radial, degrees) --> 0x0C50 (&gt;K:VOR1_SET) --> 0x0C4E (A:NAV2 radial, degrees) --> 0x0C60 (&gt;K:VOR2_SET) --> 0x0C5E Val, if you need any help with a lua I'd be willing to. Perfect little project to go with the morning coffee 😉 Roman

A lua file will definitely have to be used as there are some L: vars involved. Below are the mouse click scripts for each of the commands you require. The heading bug & OBS inc/dec also have additional code on top of the FSUIPC inc/dec commands to highlight the G1000 window area when values have changed. Heading bug to current - 1 (>L:pfd HDGKnob pressed, bool) (A:Plane heading degrees gyro, degrees) (>K:HEADING_BUG_SET) (P:Absolute time, seconds) (>L:time hdg bug changed, seconds) OBI to current - (A:GPS drives NAV1, bool) if{ quit } (L:CDI source selected, enum) 1 == if{ (A:NAV1 radial, degrees) 180 - dnor (&gt;K:VOR1_SET) } (L:CDI source selected, enum) 2 == if{ (A:NAV2 radial, degrees) 180 - dnor (&gt;K:VOR2_SET) } (P:Absolute time, seconds) (&gt;L:time crs changed, seconds)

If my memory serves correct - no.. The commands left/right/up/down overwrite the axis values.. (?) I'd take that with a grain of salt without testing.. (lol) It was so long ago and have no reference (or sim) in front of me..

This is either a bug or designed as is..(internal sim, not FSUIPC) When using a pure "set", not "axis set", if the value is unchanged from the last time "set" was used it does nothing.. Dealt with this on throttle set gauge. Try these instead. AXIS ELEV TRIM SET 65766 For aileron & rudder keep using your compounds but on press set them to a value of 1 then on release set to zero. An alternative... A lua may be a little better for these 2. Should work for you.

Answered over at AVSIM --> https://www.avsim.com/forums/topic/532223-beechcraft-baron/?do=findComment&comment=3818424

Search for "ButtonRepeat" or pg 19 in the FSUIPC4 for Advanced Users.pdf. That should do it for you.

Dave, You need to use "listening" code or a loop to keep the lua alive. The best way is a listener, it's all part of the Event Library in the Lua Library.pdf. The one drawback is that it should be started via the [Auto] section in the .ini . Although it could be started in some other fashion. There should be no need for a query since the flag can only be 1 (sound playing) or 0 (sound off). Maybe this will help - taken from a previous code project (it works) and not tested in this example. Roman -- Use (LuaSet "lua name") to start the sound and (LuaClear "lua name") to stop it. -- The parameter for the FSUIPC UI in this code example is zero -- The lua should be started via the [Auto] section in the FSUIPC#.ini -- OPTION, adjust path as needed, if wanted -- sound.path("G:/FSX/Modules") local flagged = 0 function Sound_Control(flag) flagged = ipc.testflag(0) if flagged == true then -- OPTION, play sound once -- MySound = sound.play("ElectricPump.wav") -- OPTION, loop the sound continuously until turned off MySound = sound.playloop("ElectricPump.wav") else sound.stop(MySound) end end event.flag(0,"Sound_Control")

Pete is away until the 15th.. Looked at the .ini, doesn't seem like anything is awry. Best thing is start FS for a very short period, up to showing the bad pitch trim, correct the trim, then shut down. Attach the FSUIPC#.log Roman

Hi Pete, Went through the tests again. It seems that the write within the original while-do wasn't fast enough, too many other things going on. Tried a while-do in it's own thread and the result is that the write occurs - sorry 'bout that.. But, the updates are factors slower than XMLTools. while 1 do ipc.writeDBL(0x2020, 123) end Yes that is exactly what's happening. XMLTools seems to have a fast enough update to make it usable. Tom Taguilo's .dlls are here - http://www.fsdeveloper.com/forum/search/13164829/?q=XMLTools&t=resource_update&o=date The P3Dv4 package does not include documentation, refer to the P3Dv3 package for the docs. The XML interface to his .dll is there, also included are some other things that are way over my pay grade ;-), specifically "XMLTools.h" & "XMLTools Class for C++ projects.pdf". Maybe that will help. Roman

Hi Pete, Been putzing around with a little trick found on FSDeveloper regarding corrected fuel flow & keeping turboprops running away during start and other conditions. It uses (>C:SIMVARS:TURB ENG CORRECTED FF:1, pounds per hour) through the XMLTools.dll interface. It works well but needs gauge coding per aircraft. I was trying to get this to work using lua by writing to 0x2020 (& the 3 others) so it could work globally on all turboprops. The feedback is --- doesn't work. The following code was inside of a while - do loop which does work perfectly but there was no return as wanted via logging. ipc.writeDBL(0x2020, 200) Tested some others too w/ ?-SimC in the write column - no go. I guess "it is what it is", just feedback is all. I know you're busy with all the P3Dv4 stuff, but if you ever get around to looking into it, getting the "Turbine Engine # corrected fuel flow" & "Reciprocating engine # starter torque" (another trick) working, both ?-SimC for writes, would be "the cat's meow" ;-) FSX Acceleration / FSUIPC v4.971b Regards, Roman

IIRC if it's not a "green line" type message you can, once it's open, drag, resize & undock the window and move it over to where you want. It should work if GSX does not supply the location/size when opening the window. All my development LUA's which use the non-green line message displays are put in certain locations using the drag/size fashion and they are remembered by FSUIPC between sessions. ex. FSUIPC4.ini snippet - [Window.LUA display] Docked=7354, 2810, 3545, 1704 Undocked=2446, 208, 312, 134 They are also entered within a saved flight (FSX) although it looks like there is some "cleanup" problems ex. Test.flt snippet - [WAR EMERGENCY POWER] Undocked=False ScreenUniCoords=0, 122, 819, 0 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 0 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 0 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 0 UndocCoords=0, 0, 0, 0 [AUTO COORDINATION] Undocked=False ScreenUniCoords=0, 122, 819, 0 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 0 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 0 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 0 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 0 UndocCoords=0, 0, 0, 0 [WATER RUDDER] Undocked=False ScreenUniCoords=0, 122, 819, 404 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 404 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 404 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 404 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 404 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 404 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 404 UndocCoords=0, 0, 0, 0 Undocked=False ScreenUniCoords=0, 122, 819, 343 UndocCoords=0, 0, 0, 0 [LUA display] Undocked=False ScreenUniCoords=5627, 616, 1782, 707 UndocCoords=0, 0, 0, 0 Since this P3D and you use GSX I could be all wrong... No harm in trying. Roman

Try updating to version 4.959 (you have 4.958). Just about every time P3D is updated FSUIPC requires the newest version.

Dave, Sent you a PM. Roman

I can bet that they are using L:Vars with logic to control the audio panel. ex. ( the L:Var "(L:ADF_IDENT, bool)" is just made up as an example ) (L:ADF_IDENT, bool) (A:ADF IDENT, bool) != if{ (&gt;K:RADIO_ADF_IDENT_TOGGLE) } Or even worse, code similar to this which would cause "command flooding" (L:ADF_IDENT, bool) if{ (&gt;K:RADIO_ADF_IDENT_ENABLE) } els{ (&gt;K:RADIO_ADF_IDENT_DISABLE) } You're going to want to "see" what's going on by using ( at the same time) the facilities in FSUIPC to monitor L:Vars and the commands sent to the sim to figure this out. For commands use - FSUIPC | Logging Tab | "Events (non-axis controls)" | "Send to console window" For L:Vars use (for ease) - Using these will sort out what is going on. If my suspicions are correct you will need to use LUA to interface in the long run. Wish I could help more but I do not own the BK-117. EDIT - If the gauges are the XML/.CAB style, you could also go through the code to see what they're doing. If it's a .GAU/.DLL you may be out of luck dealing with possibly poor programming. (Seen it before, the ABC F-8F Bearcat has this problem, of all things -- ADF Ident too!) The last resort may be to use the original artwork and then recode properly.

Maybe ?? - f:write("\r\ <DienstBeginn>" .. DienstBeginn .. "</DienstBeginn>" ) As a full string you would write the xml tag followed by the contents (as already a formatted string) of the variable "DienstBeginn" followed by the string of the ending xml tag. Concatenate command for strings = ..

If calibrating through FSUIPC make sure there is no assignment in FSX-SE for the aileron (and any others) axis. Clear them if so.