rustam

Hi there, I'm trying to map 'Next View' / 'Prev View' ('S' and 'Shift + S' keys in FSX) controls on my Saitek X52 Pro POV1 hat-key using FSUIPC combined buttons. But for some reason they don't work. I've checked the INI entries (see below), but I can't find anything wrong with them. These combinations for buttons 32-38 are used for views only and I've specifically checked that they aren't mapped on other buttons. Interestingly, 'Next Sub View' and 'Prev Sub View' ('A' and 'Shift + A' keys in FSX) controls work OK. Maybe someone has better eyes than mine? Kindly appreciated! 48=CR(-0,0)(-0,14)(-0,15)0,34,C65672,0 -{PAN_RIGHT}- 49=CR(-0,0)(-0,14)(-0,15)0,38,C65671,0 -{PAN_LEFT}- 51=CR(-0,0)(-0,14)(-0,15)0,32,C65734,0 -{PAN_UP}- 52=CR(-0,0)(-0,14)(-0,15)0,33,C65856,0 -{PAN_RIGHT_UP}- 53=CR(-0,0)(-0,14)(-0,15)0,35,C65857,0 -{PAN_RIGHT_DOWN}- 54=CR(-0,0)(-0,14)(-0,15)0,36,C65735,0 -{PAN_DOWN}- 55=CR(-0,0)(-0,14)(-0,15)0,37,C65855,0 -{PAN_LEFT_DOWN}- 56=CR(-0,0)(-0,14)(-0,15)0,39,C65854,0 -{PAN_LEFT_UP}- 57=CP(+0,0)(+0,14)(-0,15)0,32,C65875,0 -{PAN_RESET}- 58=CP(+0,0)(-0,14)(-0,15)0,34,C66153,0 -{NEXT_SUB_VIEW}- 59=CP(+0,0)(-0,14)(-0,15)0,38,C66154,0 -{PREV_SUB_VIEW}- 60=CP(+0,0)(+0,14)(-0,15)0,34,C65827,0 -{NEXT_VIEW}- 61=CP(+0,0)(+0,14)(-0,15)0,38,C65828,0 -{PREV_VIEW}- 62=CR(-0,0)(-0,14)(+0,15)0,34,C66526,0 -{EYEPOINT_RIGHT}- 63=CR(-0,0)(-0,14)(+0,15)0,38,C66527,0 -{EYEPOINT_LEFT}- 64=CR(-0,0)(-0,14)(+0,15)0,32,C66528,0 -{EYEPOINT_FORWARD}- 65=CR(-0,0)(-0,14)(+0,15)0,36,C66529,0 -{EYEPOINT_BACK}- 66=CR(+0,0)(-0,14)(+0,15)0,32,C66524,0 -{EYEPOINT_UP}- 67=CR(+0,0)(-0,14)(+0,15)0,36,C66525,0 -{EYEPOINT_DOWN}- 68=CP(+0,0)(+0,14)(+0,15)0,32,C66530,0 -{EYEPOINT_RESET}-

Hi there, I know, it's an old topic but I'm putting it here not to spoil the forum with yet another similar topic. Please feel free to relocate it as appropriate. Anyway, I'm trying to get the values for Prop RPM percentage (%) and Torque pressure (psi) for Aerosoft Twin Otter DHC-6-300 and to display them on the screen via a LUA script. The script works OK but I'm not sure if the offsets I'm working with are correct - the values match with the aircraft's gauge indicators only if divided with certain 'guesstimated' scalars , as shown below (e.g., 386.45 and 327.66). So, is there any elegant solution to get correct values for the above parameters? PS: FSX Acceleration with FSUIPC v4.972a propRPM1 = round (ipc.readDBL(0x2400) / 386.45) propRPM2 = round (ipc.readDBL(0x2500) / 386.45) torque1 = round (ipc.readUD(0x08F4) / 327.66) torque2 = round (ipc.readUD(0x098C) / 327.66) Thanks!

Thank you, Thomas! That's exactly what I was looking for. It works! :)

Hello everybody, I'd like to display heading and course degrees on Horizontal Situation Indicator (HSI) through FSUIPC. I can see the tool-tips regular way (mouse hovering) but it's inconvenient during flight. E.g., I've tried to use the offset 0x0580 further converted to magnetic heading and displayed at each inc/dec of the heading bug but what I've got is aircraft's positional heading, not the one selected on HSI. Basically, what I want to achieve is a sort of 'tool-tip display using FSUIPC'. So, I wonder if one can successfully retrieve these values using FSUIPC on each turn/press of the HSI rotary button? Thanks!

OMG, it was so obvious... This one works finally: function Armrest_Toggle() ipc.writeLvar("L:Twot_Armrest", nToggleVal(ipc.readLvar("L:Twot_Armrest"), 0, 1)) end Thank you VERY much for the hint, Thomas!!!

I tried this to no avail yet... function nToggleVal(nCurrVal, nVal1, nVal2) if nCurrVal == nVal1 then return nVal2 else return nVal1 end end function Armrest_Toggle() ipc.writeLvar(nToggleVal(ipc.readLvar("L:Twot_Armrest"), 0, 1)) end if ipcPARAM == 0 then Armrest_Toggle() end FSUIPC.ini is unchanged - FSUIPC recognizes the button OK. The problem is associated with function call I think. But I don't know why the above syntax doesn't work... :(

Thank you, Thomas!!! Strange, I thought calling functions was just a matter of proper environment definition (local or global), but direction of declaration is smth new for me... I'll try your suggestion and return to this thread. And Happy New Year!!!

Hi there, I'm trying to call the function 'Armrest_Toggle' with a button assigned through FSUIPC as follows: if ipcPARAM == 0 then Armrest_Toggle() end local function Armrest_Toggle() ipc.writeLvar(nToggleVal(ipc.readLvar("L:Twot_Armrest"), 0, 1)) end local function nToggleVal(nCurrVal, nVal1, nVal2) if nCurrVal == nVal1 then return nVal2 else return nVal1 end end I'm tracing the changes in LVars and when I press the assigned button, I get this error: 273111 *** LUA Error: ...Games\Microsoft Flight Simulator X\Modules\dhc-6.lua:26: attempt to call global 'Armrest_Toggle' (a nil value) And here is the content of FSUIPC.ini, as relates to the particular aircraft I've loaded into the sim: [JoyNames] AutoAssignLetters=No 0=X52 Pro Flight Controller 0.GUID={A1946F60-C51A-11E6-8005-444553540000} [Profile.DHC-6] 1=Aerosoft DHC-6 [Buttons.DHC-6] 0=P0,1,CL1:R,0 ; armrest toggle -{Lua dhc-6}- [General] ShortAircraftNameOk=Substring [LuaFiles] 1=dhc-6 2=ipcReady 3=linda I wonder what can cause this error? Thanks in advance!!! FSUIPC4.log

Thank you VERY much, Sir!!! I took the liberty to translate your LINDA script to "basic" Lua language since I don't use Linda with FSX. And it works pretty well! I hope you don't mind... :) Cheers, Rustam

The power of C libraries... :) Amazing solution, thanks a million!!! I took the liberty to slightly modify your code - otherwise I see a blank spot instead of a zero: adf2_main = string.format("%03X", adf2_main) Thanks again, Roman!!!

Simply brilliant! Thank you!!!

Since on aircraft I'm flying the ADF frequency is barely visible, especially the fractions part, I've written this piece of "dirty" code to display it on the screen: -- Converts decimal values stored at offsets 02D4 & 02D6 to hex function dec2hex(num) local a = {} local b = {} local i = 0 num = tonumber(num) while num > 0 do local q = math.floor(num / 16) -->> find quotient local r = num - q * 16 -->> find remainder if r == 10 then r = "A" -->> this IF part is not required anyway due to offset limits but it makes the converter sort of complete! elseif r == 11 then r = "B" elseif r == 12 then r = "C" elseif r == 13 then r = "D" elseif r == 14 then r = "E" elseif r == 15 then r = "F" end num = q i = i + 1 a[i] = r end -- reverse the array elements for j = 1,i do b[j] = a[i] i = i - 1 end -- join the array elements to a string return table.concat(b,"") end adf = ipc.readUW(0x02D4) adf_f = ipc.readUW(0x02D6) if adf_f == 0 then -->> Do I need to modify this IF part?! adf = dec2hex(adf) elseif adf_f == 256 then adf = dec2hex(adf) + 1000 elseif adf_f > 256 then adf = dec2hex(adf) + 1000 + (adf_f - 256)/10 elseif adf_f > 0 and adf_f < 256 then adf = dec2hex(adf) + adf_f/10 end ipc.display("ADF = "..adf.." kHz") ipc.sleep(50) The code goes into a WHILE loop and so far works ok. What I really wonder is how I can modify the IF section indicated above to read hi / low bytes at offset 02D6 properly (instead of doing this "dirty" hex / decimal addition) and amend to the value of offset 02D4 converted to hex? I'm sure the answer is really simple but I can't figure the better approach yet... Thanks!

As far as I can trace in the event log, by default the controls 65607 and 65615 has max step of 31. Therefore, I'm trying to implement the following code to bypass default values with step 256/16384: -- Elevator Trim ------------------------------------------------------------------------- if ipcPARAM == 890 then -- Up local val = ipc.readSW(0x0BC0) local newval = val + 256 if newval > 16383 then ipc.writeSW(0x0BC0,16383) ipc.writeLvar(soundSet,0) else ipc.writeSW(0x0BC0,newval) ipc.writeLvar(soundSet,10) end end if ipcPARAM == 891 then -- Down local val = ipc.readSW(0x0BC0) local newval = val - 256 if newval < -16383 then ipc.writeSW(0x0BC0,-16383) ipc.writeLvar(soundSet,0) else ipc.writeSW(0x0BC0,newval) ipc.writeLvar(soundSet,10) end end But it seems strange that when I reach 0 (zero) trimming down the elevator, instead of switching to negative values, the offset values start counting down from 65536, as shown in the image below, whereas in the List of Offsets it's clearly stated that elevator trim control input at offset xBC0 ranges from –16383 to +16383 being of type signed word (SW). Or, am I getting smth wrong?! :) Thanks! Rustam

Thank you, Michael!!! Very helpful and generous of you indeed...

Roman, Thanks a lot! I followed your tips and guess what - it works, although a bit unexpectedly! :D I see your point... The lesson learnt: the key, as you have also mentioned, is the state of all buttons involved in compound button programming, not what one expects them to do even if the syntax I posted in OP is pretty much logical... Have a nice day! Rustam