aua668

Hi, A short question to the community: Is there anybody, who has the following combination running and working: Windows 7 64 bit FSX + Accelleration Pack SimConnect (latest version) FSUIPC 4.84 WideFS 6.977 FSInn on second PC Setting of Squawkmode (S/C) is possible from LUA scripts Before I changed from my old Win XP / FS9.1 combination the setting of the squawkmode worked perfectly without any problem. But since I have moved to my new FSX system, I am not able to get this feature working anymore. I searched many days through a lot of topics but not in all postings it was clear to me, in which combination this has worked and in which not. So if I find here anyone, who can answer this question with YES, then I know, I have to continue searching the error. I installed all products according to the installation guides, which you find on the network, following the guidelines about UAC, installation paths etc. I am a long term FSInn user and therefore I know, how to configure the tool for online flying. And everything is working fine (including PTT, voice, etc.) - but only the setting of the transponder mode doesn't. I also tried sb3gaugebridge.dll and I registered it via dll.xml. And of course a lot of other things. I also run FSInn on my FSX machine only. But also no success. I would appreciate, if one of the pilots, who has this combination running, whould share the method here. And if no one answers, then I know at least, that I am not alone with this problem. Many thanks in advance. Reinhard

Wow - if you rare eally able to do it so quickly, then Xmas is already in August this year :-) Rgds Reinhard

Hi, In my code pieces I typically set the timer between 250 and 500 msec. That's normally enough and reduces load. A minimum could be set to 100 msec for example. Rgds Reinhard

Dear Pete, I kindly ask you, if a function event.Lvar(LvarName, interval, function name) could be implemented in a future release of FSUIPC. This event function should register a Lvar for tracking of changes. Whenever the Lvar changes, the named function should be triggered. The check interval should be configurable for performance reasons. Why would this be useful? Today a lof of panels work with Lvars to expose states to the outside world. So typically this is fine for accessing them with LUA scripts. But as the pattern is always the same for all cockpit freaks, to react on these variables, it would be nice to have a generic implemention which could be called with one simple function call. So what are we typically doing for every single Lvar at the moment: We define a function, which we are calling by an event.timer. This function checks, if the state since the last call has changed for this Lvar. And if so: We are doing something. So a generic solution following this pattern, would be great. Many things today could be solved by monitoring offsets, but a lot of more complex aircrafts (like the DA Fokker) often use their own logic to implement certain functionality. Then typically you might have the chance to react on the Lvars used. And at the moment you have to implement this mechanism for every Lvar you want to monitor. By having one single event function to register the Lvar checking on a timer base would be a great reduction in code necessary to interface with cockpit hardware to such airplanes. Just an idea and maybe my wish for this year's Xmas ;-) Best regards Reinhard

Dear Pete, I have now posted the topic in the user contributions as suggested. There is a good starting point for creating XML gauges here: http://www.fs2x.com/Tutorials.htm And of course in the Microsoft ESP SDK documentation you will find additional information. It's really easy (even for me) to create gauges by XML :???: Rgds Reinhard

Hi, I run a multi-monitor setup with three monitors showing the outside world and two touchscreen monitors showing the panels. With the move from FS9 to FSX I detected, that locking of screen positions via FSUIPC isn't possible anymore. This is extremely bad on touchscreens, where you easily move undocked windows in fullscreen mode with your fingers. Therefore I came across a different solution for inhibiting the dragging of such panel windows, which works very well for my planes. I created a XML gauge which captures LeftDrag mouse commands which are typically produced when you are touching the screen and move your fingers a little bit. I installed this gauge in every panel window stretching the gauge over the complete coordinate range of the panel window (typically defined in the size_mm parameter. Of course right drags easily could be blocked too with this solution. With this gauge in place I could operate all my other gauges as normal, but at places, where typically no clickspot was available, the dragging is now inhibited. So my touchscreen panels never move on my screen anymore. To implement this feature in your panel you just have to create a Folder "FixPanelPos" in your Gauges folder. In this folder create a file NoDrag.xml with the following content: <Gauge Name="NoDrag" Version="1.0"> <Size X="10" Y="10"/> <!-- Inhibit dragging of panel windows by reacting with dummy event (turn the sound on) --> <Mouse> <Area Left="0" Top="0" Width="10" Height="10"> <Click Kind="LeftDrag" Event="SOUND_ON"/> </Area> </Mouse> </Gauge>[/CODE] In the panel window, which you want to protect, you just have to enter the gauge entry: [CODE]gaugeXX=FixPanelPos!NoDrag, 0,0,1024,768[/CODE] For XX take the next free number and adjust the size so that the gauge covers your panel window. That's all. I have chosen the SOUND_ON Event, as typically sound is on, so you wil see no action, if you drag with your fingers/mouse. Only the sound goes on, if you had turned it off. But you can choose any action you want. According to other users in this forum it's also possible to use this method to lock certain areas of complex gauges to avoid closing of windows by masking the LeftClick event. For me this works perfectly and my touch screens are now my only input for my planes (beside my GoFlight panels). This is a completely unsupported version for my own purposes and no further documentation is available. But those people doing similar things know, how to implement this into to their planes. And as I found so many useful things here in this forum, I wanted to give back something to the community. Rgds Reinhard

Hi, I run a multi-monitor setup with three monitors showing the outside world and two touchscreen monitors showing the panels. With the move from FS9 to FSX I detected, that this locking isn't possible anymore. This is extremely bad on touchscreens, where you easily move undocked windows in fullscreen mode with your fingers. Therefore I came across a different solution for inhibiting the dragging of such panel windows, which works for my planes very well. I created a XML gauge which captures LeftDrag mouse commands which are typically produced when you are touching the screen and move your fingers a little bit. I installed this gauge in every panel window stretching the gauge over the complete coordinate range of the panel window (typically defined in the size_mm parameter. Of course right drags easily could be blocked too with this solution. With this gauge in place I could operate all my other gauges as normal, but at places, where typically no clickspot was available, the dragging is now inhibited. So my touchscreen panels never move on my screen anymore. To implement this feature in your panel you just have to create a Folder "FixPanelPos" in your Gauges folder. In this folder create a file NoDrag.xml with the following content: <Gauge Name="NoDrag" Version="1.0"> <Size X="10" Y="10"/> <!-- Inhibit dragging of panel windows by reacting with dummy event (turn the sound on) --> <Mouse> <Area Left="0" Top="0" Width="10" Height="10"> <Click Kind="LeftDrag" Event="SOUND_ON"/> </Area> </Mouse> </Gauge> [/CODE] In the panel window, which you want to protect, you just have to enter the gauge entry: [CODE] gaugeXX=FixPanelPos!NoDrag, 0,0,1024,768 [/CODE] For XX take the next free number and adjust the size so that the gauge covers your panel window. That's all. I have chosen the SOUND_ON Event, as typically sound is on, so you wil see no action, if you drag with your fingers/mouse. Only the sound goes on, if you had turned it off. But you can choose any action you want. For me this works perfectly and my touch screens are now my only input to my panels (beside my GoFlight panels). This is a completely unsupported version for my own purposes and no further documentation is available. But those people doing similar things know, how to implement this into to their planes. And as I found so many useful things here in this forum, I wanted to give back something to the community. Rgds Reinhard

Hi, Here an example for a routine I am using with GF rotaries to set the heading. You can call this routine with different ipcParam values (+1, -1, +10, -10, etc.) for the various speed levels. I am assigning just the LUA script with the parameter for button press and for button release via the FSUIPC interface to the rotary: -- FSX_IncDecHdg.lua -- V1.0 -- FSX generic implementation of the HDG increment by ipcPARAM steps local lHDG = math.floor ( ipc.readUW(0x07CC) * 360 / 65536 + 0.5 ) lHDG = lHDG + ipcPARAM lHDG = math.floor(lHDG / ipcPARAM + 0.5) * ipcPARAM if lHDG < 0 then lHDG = lHDG + 360 end if lHDG > 360 then lHDG = lHDG - 360 end lHDG = math.floor ( lHDG * 65536 / 360 + 0.5 ) ipc.writeUW(0x07CC, lHDG ) [/CODE] Maybe you can use this as an example for your needs. Similar functions can be used for CRS, altitude etc. Rgds Reinhard

Peter, I nstalled the new version and it works perfectly. Many thanks. Reinhard

Peter, I have now tested your version 4.835 and with this modification T8 and RP48 modules now work cmpletely the same way. I tested with the following program the gfd.SetLights, gfd.SetLight and gfd.ClearLight functions. And they showed exactly the same (and expected) output on the LEDs on all of my modules. gfd.BlankAll() gfd.SetLights(GFT8,0,0xAA,0x00) gfd.SetLights(GFRP48,0,0xAA,0x00) gfd.SetLights(GFRP48,1,0xAA,0x00) ipc.sleep(2000) gfd.SetLights(GFT8,0,0x55,0x00) gfd.SetLights(GFRP48,0,0x55,0x00) gfd.SetLights(GFRP48,1,0x55,0x00) ipc.sleep(2000) gfd.BlankAll() gfd.SetLights(GFT8,0,0xAA,0xFF) gfd.SetLights(GFRP48,0,0xAA,0xFF) gfd.SetLights(GFRP48,1,0xAA,0xFF) ipc.sleep(2000) gfd.SetLights(GFT8,0,0x55,0xFF) gfd.SetLights(GFRP48,0,0x55,0xFF) gfd.SetLights(GFRP48,1,0x55,0xFF) ipc.sleep(2000) gfd.BlankAll() lCnt = 0 while lCnt < 8 do gfd.SetLight(GFT8,0, lCnt) gfd.SetLight(GFRP48,0, lCnt) gfd.SetLight(GFRP48,1, lCnt) ipc.sleep(200) lCnt = lCnt + 1 end lCnt = 0 while lCnt < 8 do gfd.ClearLight(GFT8,0, lCnt) gfd.ClearLight(GFRP48,0, lCnt) gfd.ClearLight(GFRP48,1, lCnt) ipc.sleep(200) lCnt = lCnt + 1 end [/CODE] I went back to 4.831 and the difference was here again. Now I am back on your supplied version and as far as I could test all the other functions, which I have already implemented for my modules, they work perfectly. I have posted the bug report also in the GoFlight forum. Many thanks for your great support. Reinhard

Hi, I will test the provided update as soon as possible. I can confirm, that when I am not using 0xFF as the OFF mask, the result is more than astonishing and it's even more astonishing, that by using 0xFF it ALWAYS works. All other values show results, that are not predictable. Very strange indeed. That's why I shared these results with you. I think, they really have a bug in their firmware.Maybe their readlights from device is not consistent. Btw: Would it be possible to provide this readlights from device as a gfd.ReadLights (model, unit) function? This would be a nice new feature. Rgds Reinhard

Hi, I did some tests with the on/off masks, which behave different between T8 and RP48: gfd.BlankAll() onMask1 = 0x0F onMask2 = 0xF0 offMask1 = 0x55 offMask2 = 0xAA gfd.SetLights(GFT8,0,onMask1, offMask1) ipc.sleep(1000) gfd.SetLights(GFT8,0,onMask2, offMask2) ipc.sleep(1000) gfd.SetLights(GGRP48,0,onMask1, offMask1) ipc.sleep(1000) gfd.SetLights(GFRP48,0,onMask2, offMask2) ipc.sleep(1000) [/CODE] These are the results shown as seen on the GF modules (left digit is ID 0, 1=ON, 0=OFF): [CODE] GFT8: 11110000 10101111 GFRP48: 00000000 00001111 [/CODE] As can be seen, the effect of the OFF mask is different. While at the T8 bits set without a corresponding bit in the ON mask, the light is turned off. Bits with zero don't affect. The behavour is strange. I found out, that only with a mask of 0xFF the value provided in the ON mask definitely is shown up. Maybe this helps for your workaround. For my setup I found a good solution to bypass this difference. I used a user offset for each module (1xT8, 2xRP48), where my LUA scripts can clear and set bits as needed and I just have one event per offset listening to changes on this offset, and then I simply pass the value of the offset as the ON mask with the OFF mask 0xFF to gfd.SetLights function for the module. This works perfectly. So a bypass from your side would be fine, as other users might also have problems using the gfd.SetLight function, which doesn't work as expected for that module. Rgds and thanks for your excellent support. Reinhard

Hi, Here is the HIDScanner.log for the GFT8: ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0030#8&13b885f3&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0030 (Version 1.2) Manufacturer= GoFlight Product= GoFlight GF-T8 control module Serial Number= Usage Page: 2 Input Report Byte Length: 2 Output Report Byte Length: 0 Feature Report Byte Length: 2 Number of Link Collection Nodes: 4 Number of Input Button Caps: 1 Number of InputValue Caps: 0 Number of InputData Indices: 8 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 1 Number of Feature Value Caps: 2 Number of Feature Data Indices: 3 Buttons range 1 -> 8 at indices 0 -> 7 ************************************************************************** [/CODE] And here is the HIDScanner.log for my two units of the GFRP48 mouse show up like this: [CODE] ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_00#9&185b7c81&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Multi Media Keyboard Demo Serial Number= Usage Page: 2 Input Report Byte Length: 6 Output Report Byte Length: 0 Feature Report Byte Length: 2 Number of Link Collection Nodes: 4 Number of Input Button Caps: 1 Number of InputValue Caps: 1 Number of InputData Indices: 9 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 1 Number of Feature Value Caps: 2 Number of Feature Data Indices: 3 Buttons range 1 -> 8 at indices 1 -> 8 Value Dial at index 0, range -128 -> 127, using 8 bits ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_00#9&efb9e4&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Multi Media Keyboard Demo Serial Number= Usage Page: 2 Input Report Byte Length: 6 Output Report Byte Length: 0 Feature Report Byte Length: 2 Number of Link Collection Nodes: 4 Number of Input Button Caps: 1 Number of InputValue Caps: 1 Number of InputData Indices: 9 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 1 Number of Feature Value Caps: 2 Number of Feature Data Indices: 3 Buttons range 1 -> 8 at indices 1 -> 8 Value Dial at index 0, range -128 -> 127, using 8 bits ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_01#9&22e783de&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Microchip Technology Inc. Serial Number= Device is a mouse Usage Page: 1 Input Report Byte Length: 4 Output Report Byte Length: 0 Feature Report Byte Length: 0 Number of Link Collection Nodes: 2 Number of Input Button Caps: 1 Number of InputValue Caps: 2 Number of InputData Indices: 5 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 0 Number of Feature Value Caps: 0 Number of Feature Data Indices: 0 Buttons range 1 -> 3 at indices 0 -> 2 Value Y at index 3, range -127 -> 127, using 8 bits Value X at index 4, range -127 -> 127, using 8 bits ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_01#9&2b8b98bf&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Microchip Technology Inc. Serial Number= Device is a mouse Usage Page: 1 Input Report Byte Length: 4 Output Report Byte Length: 0 Feature Report Byte Length: 0 Number of Link Collection Nodes: 2 Number of Input Button Caps: 1 Number of InputValue Caps: 2 Number of InputData Indices: 5 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 0 Number of Feature Value Caps: 0 Number of Feature Data Indices: 0 Buttons range 1 -> 3 at indices 0 -> 2 Value Y at index 3, range -127 -> 127, using 8 bits Value X at index 4, range -127 -> 127, using 8 bits ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_02#9&320eaf6&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Multi Media Keyboard Demo Serial Number= Device is a keyboard Usage Page: 1 Input Report Byte Length: 9 Output Report Byte Length: 0 Feature Report Byte Length: 0 Number of Link Collection Nodes: 1 Number of Input Button Caps: 2 Number of InputValue Caps: 0 Number of InputData Indices: 110 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 0 Number of Feature Value Caps: 0 Number of Feature Data Indices: 0 ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_02#9&b23f799&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Multi Media Keyboard Demo Serial Number= Device is a keyboard Usage Page: 1 Input Report Byte Length: 9 Output Report Byte Length: 0 Feature Report Byte Length: 0 Number of Link Collection Nodes: 1 Number of Input Button Caps: 2 Number of InputValue Caps: 0 Number of InputData Indices: 110 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 0 Number of Feature Value Caps: 0 Number of Feature Data Indices: 0 ************************************************************************** [/CODE] Rgds Reinhard

Hi, How it works is described here: http://goflight.vanillaforums.com/discussion/61/rp46-mouse-module I will do the test with HIDScanner tomorrow and post the result here. I am able to set any combination of lights with the gfd.SetLights function. This works for the RP48 module and for the T8 module if I put the combination for the LEDs I want to set in the "on" mask and 0xFF in the "off" mask. Then exactly those lights are turned on having the correspondent bits set. I will do some tests tomorrow and show you the results and if there are differences in handling of the masks. Rgds Reinhard

Hi, I am using FSUIPC 4.831 at the moment but can try 4.834 too. For the GFDev I use the current version from the GoFlight Website. I will check, when I am at home. There might be one difference to your setup: I ordered the "RP48 mouse" module, which has additional functionality supporting mouse movements, and you might have the "standard" RP48. http://www.goflightinc.com/collections/modules/products/gf-rp48-mouse-push-button-rotary So there might be a firmware difference as you assumed. Rgds Reinhard

Hi, I only use FSUIPC to access my GF modules. I don't use the GF Software. To illustrate, I show some code segments and the result. On the GFT8 the following code: gfd.BlankAll() gfd.SetLight(GFT8, 0, 0) ipc.sleep(1000) gfd.SetLight(GFT8, 0, 1) ipc.sleep(1000) gfd.SetLight(GFT8, 0, 2) ipc.sleep(1000) [/CODE] produces the following result: LED 1,2 and 3 are turned to on with a interval of 1 second and at the end all thre LEDS are on. The same code by just replacing the GFT8 by GFRP48 lights up LED 1. After one second LED 1 turns off and LED 2 turns on and one second later LED 2 turns off and LED 3 turns on. If I use the gfd.SetLights function with the same mask for both modules I am able to turn on all three lights simultaneously. So for me it looks like, that the mask isn't filled correctly for the GFRP48 in the gfd.SetLight function. Should I address this to the GF support as you have checked this already in your code? Rgds Reinhard

Hi, There is a difference in the function gfd.SetLight between using it with the GFT8 and the GFRP48: While the setting and clearing of single lights independetly works on the GFT8, it shows a different behaviour on the GFRP48. There setting one light clears all the other lights. The gfd.SetLights function works the same for both modules. I don't know, if this is by design or if this is a bug. Maybe you can look in the code. I use FSX and Win 7 64 bit and the latest FSUIPC and LUA package. Btw: It would be fine to have a function for reading the LED status. Rgds Reinhard

Peter, I posted it in the SPAD forum. I assumed a similar thing and just wanted to be sure, if there is any other possibility. Rgds Reinhard

Hi, I am using FS9.1 under WIN XP and the latest registered version of FSUIPC. I assigned virtual buttons for a profile for an add-on aircraft (Feelthere Citation X) for my Saitek switch panel using SPAD. It seems, that the buttons 64,7 64,15 etc, are not working. They are not sent to FSUIPC. As soon, as I assign another virtual button in SPAD, they are recognized by FSUIPC. Can someone confirm this behaviour and is the error on the SPAD side or in the FSUIPC module? Rgds Reinhard

Hi, I installed the latest (beta) version and it's working again. Thx Reinhard

Peter, I use FS9 and Version 3.9.66c at the moment. And I have the same problem. With an aircraft, for which I had already made successfully mouse macros, I am currently not able to record any new macro. Even for default MS planes I don't get the popup any more. I have no idea, what might have changed (beside new versions of FSUIPC and some Win XP updates). Rgds Reinhard

You are right - arming of speedbrakes for takeoff is only at the Airbus - at the Boeing they have to be down according to the checklist. So this is no factor anymore. Thanks for the hint. Thanks that's exactly the answer I expected and so now the case is clear. Great support btw! Rgds Reinhard

Hi, Maybe this has been discussed already here (I have not found a reference) but I have a question concerning the spoiler of the PMDG 737-600/700/800/900 under FS 9.1/WIN XP. You can assign the spoiler axis via FSUIPC to an axis on the throttle quadrant (I use the Saitek). By doing this, you can control the spoiler and depending on the calibration you will have a zone, where the spoiler is armed and a zone, where you can adjust the spoiler extraction linear. This is documented on the web and works fine ... ... BUT: By doing so you lose one feature. PMDG has "improved" the FS spoiler functionality by internal coding and you get the standard spoiler behaviour of FS, if you arm it via the axis. This means: If you arm the spoiler on the ground (e.g. before takeoff) the spoiler will extract. PMDG has an armed position for the spoiler handle, which you only can set via the mouse in the 2D cockpit. If you are using the FS internal key commands, you will again get the FS standard behaviour. This can also be found in the forums. So I thought, it would be nice to move the spoiler handle with the mouse as concepted by PMDG by using a mouse macro. So I tried to create two mouse macros: One for arming and one for disarming the spoiler. The recording was easy ... ... BUT: It did't work completely as I thought. The mouse macro were only able to disarm (if you manually armed the spoiler by using the mouse) but never to arm the spoiler. The reason behind is simple: PMDG has created only one mouse sensitive region (R1) for the spoiler handling and they seem to check on a mouse click, at which coordinates within the region you are clicking. If you click in the upper area, then the spoiler is disarmed and if you click within the lower part of the same region, then the spoiler is armed. If they would have created two seperate regions, it would have been easy. And it seems, that the generated mouse event from the macro always hits this region in the upper area (maybe at 0,0 as nothig may be defined - just an assumption). So after this long description of my problem I want to ask, if there is any possibility to provide coordinates in addition to this simple region R1 which is addressed by the mouse macro. With this additional information I would be able to create two different macros addressing the same region but doing different actions ? Rgds Reinhard

Hi Pete, I increased the timeout to 20, adopted the power management (had no influence) and now it's working again. If there are any issues, I will come back. But 20 is ok for Saitek yoke, throttle quadrant and pedal. Rgds Reinhard

Hi, Just one input to the screen flickering with AS: It's the RenderToTexture parameter in the FS9.cfg. If You set this parameter in the display section to 0, then you will have no flickering during update. BUT BE AWARE: You are not able to use DXT clouds in that case anymore. This will crash the FS already at startup (at 76%). This is a known "feature". Rgds Reinhard