aua668

Sorry for having been unclear: I just wanted to point you to the forum, as you asked. I don't use SPAD anymore as I did use it only with FS9. Last year I switched to FSX and by that I also have eliminated my Saitek Panels. It was just to point you to the site of SPAD and the forum. Rgds Reinhard

Hi, There is a forum here: http://fstools.weebly.com/index.html But in fact the product reached only version 0.5.1 until now. I used these drivers too, when I was on FS9 as this was a fine possibility to integrate the Saitek hardware via LUA with some payware aircrafts. The standard Saitek drivers for FS9 only integrate with the stock aircrafts. In fact I also wrote here in your forum about a minor bug in this software: http://forum.simflight.com/topic/69445-virtual-button-715-and-spad/ I got a fix after 9 months ;) At that time I switched already to FSX with new hardware (GoFlight). Beside this small error I was quite satisfied with the tool. Rgds Reinhard

Hi, Download the latest Lua Package from the download section. You will find there a lot of useful sample Lua scripts included, which might be taken as a reference. Rgds Reinhard

Hi, I didn't want to open a new thread for this small issue with the dynamic friction: In the Lua Library documentation there is a typo: It shows the function "Ypc.RestoreFriction()"instead of "ipc.RestoreFriction()". Maybe you correct this at the next version. Rgds Reinhard

Hi, It' simple math: 1 - 0 = 1 1 - 1 = 0 So with every call you are flipping between the two values. Rgds Reinhard

Hi, I added an alternative template for the FD using explicit values. Replace the variables and values acording to your need. But as these are basic programming tasks, I would suggest to read the LUA reference manual and especially try to understand the includes samples with the LUA package. Rgds Reinhard -- toggle FD button function toggleFD (joynum, button, downup) local lFD = ipc.readLvar("L:AB_MPL_FD") if lFD == 0 then lFD = 1 else lFD = 0 end ipc.writeLvar( "L:AB_MPL_FD", lFD ) ipc.writeLvar( "L:SmallOverheadPushButtons", 1 ) end [/CODE]

Pete, I understand your argument and killing of course is a hard measurement. The function might be useful in a home cockpit, where you have several hardware components (like GF modules), which you want to enable / disable with a single button. For the GF radios for example there exists a known bug, that under WIN 7 64bit they freeze from time to time. No solution was presented by GF so far despite several reports in their forum. And if this happens during a flight, you lose some important functionality. Then it would be fine to terminate the LUA script monitoring these devices. Then you can unplug/plug them (which solves typically the freeze) and you could enable the LUA controlling of these devices again with one single button. And buttons typically are rare in a cockpit, as you have to cover so many functions. So following your hint I will implement this handling into my routines by using flags. And I will use seperate buttons via my WideFS client to start/stop the hardware LUAs. I think your argument about stability is stronger. Therefore I will add coding to realize the disabling of my LUA routines. Rgds Reinhard

Hi Pete, Sometimes you have the need to run or kill a LUA program by a button in your cockpit. You can either implement the Lua or the LuaKill function for this button. It would be useful to have also a LuaStartStop function for a given LUA program. This function should start the LUA prorgam, if it is not running and should kill the LUA, if it is currently running. This would allow, to activate and deactivate certain functionality with one single button. Of course there are some other methods, which can be coded, but I think, this would make it easier, to activate/deactivate functions in a cockpit by a single button press. How are you thinking about such a function ? Rgds Reinhard

Hi, I found it: Replace the "end if" statements by a simple "end". That should fix it. Rgds Reinhard

Hi, Maybe some typo. Check the FSUIPC.log file for errors. It was late yesterday. I have no chance to test it. But must be a small correction. Rgds Reinhard

let's try something like this: function incdecHDG ( pDiff ) -- increment or decrement HDG by pDiff local lHDG = ipc.readLvar( "L:AB_AP_HDG_Select" ) + pDiff if lHDG > 359 then lHDG = lHDG - 360 end if if lHDG < 0 then lHDG = lHDG + 360 end if ipc.writeLvar( "L:AB_AP_HDG_Select", lHDG ) end function incHDG ( joynum, button, downup ) incdecHDG ( 1 ) end function decHDG ( joynum, button, downup ) incdecHDG ( -1 ) end function incHDGFast ( joynum, button, downup ) incdecHDG ( 10 ) end function decHDGFast ( joynum, button, downup ) incdecHDG ( -10 ) end -- register the buttons of your joystick triggering the functions -- replace joynum by the actual used number, also replace button by the actual button number event.button(joynum, button1, 1, "incHDG") event.button(joynum, button2, 1, "decHDG") event.button(joynum, button3, 1, "incHDGFast") event.button(joynum, button4, 1, "decHDGFast") [/CODE] I prepared the code for registering four buttons. Two for normal incrementing decrementing by 1 degree and in case yor hardware delivers other buttons if you turn the knob quickly then the increment will be in steps of 10. But this depends on your hardware. GoFlight for example does it like that. Rgds Reinhard

Let's try something like this: function incFPAorVS ( joynum, button, downup ) if ipc.readLvar("L:AB_AP_HDGTRK") == 1 then -- 1 = TRK/FPA local lFPA = ipc.readLvar( "L:AB_AP_FPA_Select2" ) + 0.1 if lFPA > 9.9 then lFPA = 9.9 end if ipc.writeLvar( "L:AB_AP_FPA_Select2", lFPA ) else -- 0 = HDG/SPD so set VS local lVS = ipc.readLvar( "L:AB_AP_VS_Select2" ) + 1 if lVS > 60 then lVS = 60 end if ipc.writeLvar( "L:AB_AP_VS_Select2", lVS ) end end -- register the buttons of your joystick triggering the functions -- replace joynum by the actual used number, also replace button by the actual button number event.button(joynum, button, 1, "incFPAorVS") [/CODE] Not sure if it works, as I have no way to test it. And the code for decrementing could easily be done by copy/paste and edit I assume. Rgds Reinhard

ToggleXXX is just a function name. You can use whatever you like. Rgds Reinhard

Hi, You can keep AutoAssignLetters at 0 and manually assign them. For example Y for the Yoke etc. The problems will come, when you unplug the USB and plug it to a different port. Then a different number will be assigned. But the letter will stay. Think about hundred of modules, where you have to change the number. There are a lot of people, who learned this by pain. So it would be better to use the letters. It's all in the documentation. Rgds Reinhard

Hi, In the code above the joynum, button, downup are just parameters handed over to the called routine. They are not used in that specific case but there might be cases, where you want to identify, if the button was pressed or released and might do then different things. So the only thing to change in the example are the two lines at the end with the event registrations. Just replace joyletter and button1 resp. button2 with the items shown in the dialog, where you normally register button presses. I also would suggest to use letters instead of numbers for the joysticks. Details can be found in a different thread about lost assignments in this forum. And as these are basic concepts, how to create LUA programs, I would suggest that you look in the documentation provided with the LUA package. There are a lot of very useful sample scripts included, which you should try to understand. And if you have understood them by also studying the LUA library documentation, I think, things will be clearer. I am sorry but I am not able to provide LUA support more then given so far. I think by adopting the two lines and by starting the script automatically when your plane is loaded (look for the Auto section in the documentation), these two functions should work immediately without any further change (if you basic code brovided on the beginning was working). Get these two functions up and running and the rest will be easy. Rgds Reinhard

Hi, If you combine a lot of such functions in one LUA file, which you then trigger by several buttons just by changing the paramater, you will run into a problem, if you have some more time consuming statements included in several branches. Why? You will find in the documentation, that with every starting of a LUA script, all potential current running instances of the same script are killed immediately. So imagine you must for example wait in one of your script until the panel is reacting, before you trigger the next action. And if the user presses another key during the previous script is running, you might get unwanted results. When I started to implement some LUA scripts for buttons I first came also to your solution. But believe me, the event driven version is much better. Because the several events can be fired quite quickly without disturbing each other. And by utilizing the visibility of variables you can define global things for all functions. Maybe you check the LUA concepts at http://www.lua.org/manual/5.2/ And by defining the logic in the LUA file with events, you nothing have to define anything in the buttons section. This might be helpful if you add planes and want to reuse the code. So don't forget to delete the assignments you made for the buttons, as they are handled by the LUA startet once when the simulator is ready. Rgds Reinhard

Hi, And to be sure, that you get it running: Start this script automatically (e.g. via ipcready.lua or by some AUTO entry in the FSUIPC.INI according to documentation. This script must be run only once and is then sitting an waiting for the button events. Rgds Reinhard

Hi, My code would look like this: -- toggle FD button function toggleFD (joynum, button, downup) ipc.writeLvar( "L:AB_MPL_FD", 1 - ipc.readLvar("L:AB_MPL_FD") ) ipc.writeLvar( "L:SmallOverheadPushButtons", 1 ) end -- toggle ATHR button function toggleATHR (joynum, button, downup) ipc.writeLvar( "L:AB_AP_ATHR", 1 - ipc.readLvar("L:AB_AP_ATHR") ) ipc.writeLvar( "L:SmallOverheadPushButtons", 1 ) end -- register the buttons of your joystick triggering the functions -- replace joyletter by the actual used letter/number, also replace buttonX by the actual value event.button("joyletter", button1, 1, "toggleFD") event.button("joyletter", button2, 1, "toggleATHR") [/CODE] For details look in the LUA library reference document. Rgds Reinhard

Hi, You are limited in the overall number of LUA files you can use (limit was 128 - not sure if this has changed in the meanwhile). Therefore it's always better to combine these things and have fewer LUA files. And in terms of performance I would assume, that the difference isn't that big. But this is a question for Pete. If you have the functions in one LUA, you also can share variables, if you have global settings for example. Otherwise you have to work with LVars to share information across functions. So I would suggest to go for the proposed method. Rgds Reinhard

Hi, Write your small pieces of LUA code as functions in one single LUA file and register events for the GoFlight buttons in tha script triggering the correct function. Have a look in the LUA library for examples. That works perfectly. Rgds Reinhard

Hi, That's not true for me. I have tested it with the DA Fokker. I have added the gauge as gauge00. And I was able to right click on the Xpdr gauge for example but not in areas in between. I don't know, which gauge you have used. Some aircrafts have one gauge covering the whole window and are bypassing the FSX logic in own DLL code. This might be a problem. You could also experiment with the DrawOrderXX parameter in the panel.cfg. See the Microsoft ESP documentation for details. Rgds Reinhard

Hi, I have now tested and you have been very near. The only mistake you made was, that you used RightClick. Here is a list from the Microsoft ESP manual about the click events: LeftAll RightAll MiddleAll RightSingle MiddleSingle LeftSingle RightDouble MiddleDouble LeftDouble RightDrag MiddleDrag LeftDrag Move RightRelease MiddleRelease LeftRelease WheelUp WheelDown Leave So if you replace RightClick by RightSingle you have won. I implemented this in my cockpit and it works in windowed mode and in full screen. I get no context menu anymore by using this method. You even can combine this by using both events in the NoDrag gauge: <Gauge Name="NoMove_TouchScreen" Version="1.0"> <!-- inhibit movement via touchscreen via dummy command (turn sound on) --> <Size X="10" Y="10"/> <Mouse> <Area Left="0" Top="0" Width="10" Height="10"> <Click Kind="RightDrag+RightSingle" Event="SOUND_ON"/> </Area> </Mouse> </Gauge>[/CODE] Rgds Reinhard

Hi, Copyright Pete from another thread: Please check the section in the FSUIPC user guidle about Joy Letters. If you change to using the Letters for joystick identifiers rather than numbers then FSUIPC will take care of matching the assignments for you [/CODE] Check the excellent documentation and you will find the solution. Rgds Reinhard

Hi, I am running my cockpit in full screen mode with several undocked panel windows moved to the touchscreens. And I had to implement the NoDrag gauge in every single window in my panel.cfg file, as otherwise the windows might be moved by holding and dragging. Therefore I have in every window of my panel the gauge implemented covering the complete window area. By that clicking outside of the defined gauges I have no problem with moving the windows by accidence. Maybe you should overlay all your windows with the NoRightClick gauge too. The DA Fokker has a mouse interface, based on XML. So I isolated those gauges, needing right clicks in a seperate MyFokker XML gauge set. There I split up the regions in two halfs and I accepted left clicks only. And in the panel I replaced those gauges then by my own modified version. The DA Fokker is here very open. With other aircrafts having gauges implemented as .GAU files (or using DLL implementations), this typically is no option of course. So I understand your point. Rgds Reinhard

Hi, Another idea: Have you tried to combine the NoDrag and the NoRightClick in one single gauge already? You can listen to both events in one single gauge. Maybe this works better than having two seperate gauges covering the complete window. Not tried it out but maybe an option. In this tutorial you can see, how to realize this: http://www.fs2x.com/Tutorials_files/XML%20Gauge%20Programming%20for%20FS2004.%20Chapter%202.%20Interaction%20Sections.pdf Rgds Reinhard