aua668

Hi, Really a nice setup which you have built ;-) I tried to avoid right mouse clicks at all in my panels, which I adopted for my touch screen setup. I use special touch screen drivers from Touch Base: http://www.touch-base.com/ With these drivers I can better control the touch settings. Not cheap but worth the money. If the panel doesn't allow to avoid the right click, I also have no idea, how to avoid the context menu. Rgds Reinhard

Hi, Have a look at that post: http://forum.simflight.com/topic/72045-inhibit-dragging-of-panel-windows-in-fsx/ This should solve your problem with your touch screens. I have a similar setup (3 screens for the outside view and two touch screens for the panels). And I never would fly different. No mouse, no keyboard anymore. Rgds Reinhard

Hi, You might implement these requirements by a simple LUA script using the "mouse" and "event" functions provided in the LUA library. As this is a very specific request for one plane (and in addition depends on your screen setup), this would be the better solution. The mentioned functions should fulfill all the requrements (checking mouse movements, moving of the mouse, etc.). Rgds Reinhard

Hi, I never have tried it. But with a parameter in the scenery.cfg you might control, if this is done once or at every start: I think, this can be useful in multi-PC setups to synchronize scenery from a server across several PCs to get a consistent installation. Just an idea but in no way proved. Rgds Reinhard

Hi, Out of the ESP SDK for the scenery.cfg: http://msdn.microsof...y/cc526966.aspx Rgds Reinhard

Hi, Quite some time since I used FS9 together with ASV. You should search for RenderToTexture in combination with DXT clouds. Don't remember, which combination was necessary and which created flickering and which resulted in CTD. But by searching for these terms you will find the solution. But is has definitely nothing to do with FSUIPC. Rgds Reinhard

Pete, I just want to point you to a topic, which I am currently discussing with OpusFSX: http://www.simforums...topic44662.html I am opening, closing and setting the window state of OpusFSX (FSXServer.exe) via LUA commands of the ext LUA library. And there is a small glitch (I think at least so) on the OpusFSX side with setting the window state. I just want to check, if you have a possibility to verify the behaviour described, if you are using OpusFSX too. Just maximize and minimize FSXServer.exe multible times via LUA and check, if there appears a hidden broadcast window in the tsakbar. If you haven't instaled OpusFSX, please just ignore. Rgds Reinhard

Hi, I reopen this topic, as with version 4.855 (FSX+Acceleration Pack, WIN 7/64 bit) this seeting to zero only worked for the first time for me. If you are then trimming in the default C172, the trim wasn't reset anymore by just setting 0 via the ipc.control(65706,0) function. To reset the trim reliable every time, you must first set it to a different value from zero (e.g. to 1) and then set it to zero again. In LUA the code for resetting the elevator trim would look like this: ipc.control(65706,1) -- set it to a value different from your taget first ipc.control(65706,0) -- and then to the target value By using this sequence, the trim is set to zero always. I don't know, if this is by design in that way or if this is a small bug. With this workaround I could solve the problem for me. Maybe this helps other users having a similar problem. Rgds Reinhard

Hi, You should look for this program. By that software you get offsets of the Wilco Bus: http://emarciano.fre...IPCExporter.htm It's from Eric Marciano, who is one of the developer of the original plane). When you have this program installed, then you are able to access the offsets described in the supplied documentation. And you can access, which status the landing light switch has. It's also very usefull to access these offsets in LUA plugins. Rgds Reinhard

Hi, Register the buittons via the event.button function in one single file and execute the necessary function directly instead of registering seperate LUA calls via the button dialogue. Look also at the other event functions. They are VERY powerful. Check also the enclosed example plugins. Rgds Reinhard

Hi, You need this program to get the offsets in your list: http://emarciano.free.fr/En/FSUIPCExporter.htm It's from Eric Marciano, who is one of the developer of the original plane). When you have this program installed, then you are able to access the offsets documented in the supplied documentation. Rgds Reinhard

Hi, I think you just should add this to the next release notes. Maybe you find some releases later the root cause and then this just could be removed. Otherwise it would stay in the user contribution although it's already fixed. Most people with problems first will look here in this forum in any way. So they will find it by searching. Rgds Reinhard

Pete, The installer did the entry for me and I was not immediately recognizing, that the dll.xml was changed to use the loader. Now I know, that I have to check, that there must be no loader DLL in the FSUIPC directory before installation, to avoid the configuration change in dll.xml. I think I got the loader DLL with an older installation, where this feature was already enclosed. I didn't realize it earlier, as I have not been flying the DA Fokker for some weeks now for several reasons (holidays, work, ...). It also showed no side effects in other products. Yes - of course there must be something strange. But also FSUIPC doesn't behave the same way loaded directly or via the loader. You also experienced, that by just changing the installation procedure some unwanted side effects can occur (from the installation manual): So there are differences in the two starting methods, which are not known completely at the moment. And one of the detected differences is, that by using the loader method you can control the autopilot and autothrottle as usual, but the control of the aircraft in the DA Fokker is broken for some unknown reason. I just wanted to inform you and other DA Fokker users about that finding. Rgds Reinhard

Pete, The FSUIPC_Loader.dll seems to inhibt the Digital Aviation Fokker Autopilot to work. I am using WIN 7 64bit, FSX w/ Acceleration Pack and FSUIPC 4.855. I installed the 4.853 and upgraded to 4.855. Today I did my first flight after the upgrade with my DA Fokker and suddenly the Autopilot didn't control the plane as before. I could steer the plane with the yoke although the AP was engaged. There is a similar observation in the AVSIM FSX forum, where a person stated, that the DA Fokker AP isn't working anymore. So I tried a lot of things. And when I changed back to load FSUIPC 4.855 directly (w/o FSUIPC_Loader), it suddenly worked as normal. So my hint to all users of the DA Fokker: Don't use the FSUIPC_Loader at the moment, if you experience similar problems. I have no idea, how these two programs interfere, but for me it was the solution (after 4 hours testing). Rgds Reinhard

Hi, Definitely the ShortAircraftNameOk=Yes is broken in 4.85. I can confirm, that's the same here, since I have upgraded. But It's not a shame, that Pete doesn't supply old names. This would lead to complete confusion. You should keep old versions in case something doesn't work for you as expected ;-) But how I know Pete, this soon will be fixed. In The meanwhile you can add the complete profile name of the aircraft you are flying and that works. Rgds Reinhard

Hi, As Dirk asked me per PM to post similar code samples for CRS, ALT etc. here are some examples. They follow all the same scheme. CRS: -- FSX_IncDecCrs.lua -- V1.0 -- FSX generic implementation of the CRS increment by ipcPARAM steps local lCRS = ipc.readUW(0x0C4E) lCRS = lCRS + ipcPARAM lCRS = math.floor(lCRS / ipcPARAM + 0.5) * ipcPARAM if lCRS < 0 then lCRS = lCRS + 360 end if lCRS > 360 then lCRS = lCRS - 360 end ipc.writeUW(0x0C4E, lCRS ) [/CODE] ALT: [CODE] -- FSX_IncDecAlt.lua -- V1.0 -- FSX generic implementation of the ALT increment by ipcPARAM steps local lAltitudeFeet = ipc.readUD(0x07D4) / 65536 / 0.3048 lAltitudeFeet = lAltitudeFeet + ipcPARAM lAltitudeFeet = math.floor(lAltitudeFeet / ipcPARAM + 0.5) * ipcPARAM if lAltitudeFeet < 0 then lAltitudeFeet = 0 end if lAltitudeFeet > 60000 then lAltitudeFeet = 60000 end lAltitudeFeet = math.floor(lAltitudeFeet * 65536 * 0.3048 + 0.5) ipc.writeUD(0x07D4, lAltitudeFeet) [/CODE] By using the offset documentation provided by Pete it should be easy, to extend this to other functions if necessary. Rgds Reinhard

Hi, Using this technique with the Eaglesoft Citation X 2.0 didn't work for the electric panel on the left tilt. I had to change the "LeftDrag" to a "RightDrag". And by this also the ES C750 now works fine. Just for information if someone experiences a similar problem. Rgds Reinhard

3.A00a - and by that we have plenty of new versions for FS9 :razz: :razz: :razz: Rgds Reinhard

Hi, For the fuel quantity gauges you should think about the interval, how often you are checking the Lvars. I don't believe, that the value will change within 100 msec so dramatically. So I would suggest to select for the slow moving gauges a longer interval to reduce load of the system. Rgds Reinhard

You must have the latest version of FSUIPC installed (from the download section in this forum) as Pete implemented this function end of July. Yes - as you easily can guess from my account ;-) Rgds Reinhard

Hi, You could use the great new event.Lvar function, which Pete implemented with the last release. This event function checks in a given interval every change of a Lvar variable. Check the latest documentation. Your code could look like this: -- define Lvar to offset mapping functions function setVerticalSpeedRight (lvarname,value) ipc.writeUW(0x66B1,value) end function setFuelQuantityLeft (lvarname,value) ipc.writeUW(0x66C0,value) end function setFuelQuantityRight (lvarname,value) ipc.writeUW(0x66C1,value) end -- initialize offsets setVerticalSpeedRight ("NEEDLE_VERTICAL_SPEED_RIGHT",ipc.readLvar("NEEDLE_VERTICAL_SPEED_RIGHT")) setFuelQuantityLeft ("NEEDLE_FUEL_QUANTITY_LEFT",ipc.readLvar("NEEDLE_FUEL_QUANTITY_LEFT")) setFuelQuantityRight ("NEEDLE_FUEL_QUANTITY_RIGHT",ipc.readLvar("NEEDLE_FUEL_QUANTITY_RIGHT")) -- register Lvars to check (100 msec is the minimum interval) event.Lvar("NEEDLE_VERTICAL_SPEED_RIGHT",100,"setVerticalSpeedRight") event.Lvar("NEEDLE_FUEL_QUANTITY_LEFT",100,"setFuelQuantityLeft") event.Lvar("NEEDLE_FUEL_QUANTITY_RIGHT",100,"setFuelQuantityRight") [/CODE] Very easy to implement now Lvar changes with this new function. Rgds Reinhard

Hi, Merry Xmas. It works perfectly !!! I have just done a first test. I reduced my code and modified it to the new event.Lvar function. And immediately this did work. Now your August vacation is near ;-) Best regards Reinhard

Hi, FSInn doesn't use the SB3 offsets but has it's own SDK to provide access for external programs (like gauges). sb3gaugebridge.dll closes the gap between panel designers (XML based or *.GAU based), SB3 offsets and the FSInn SDK by synchronizing changes between these worlds. By using this, DLL transponder gauges could controll FSInn and SB3 with one mechanism. I did detailled research yesterday and obviously this DLL doesn't work for FSInn in the FSX / WIN 7-64 environment. At least with my possibilities I wasn't able to get it working. But during my investigations I stumbled across a much simpler solution, which I wasn't aware of: On The FSX PC in the FSCopilot menu you can use the "Settings" menu to define hotkeys for several FSInn functions. And BINGO: there is also the possibility to define hotkeys for squawkmode Standby/Charlie/Ident ! And the good messageis: This also works, if the FSInn UI is not running on the FSX PC but on the second PC, which handles the VATSIM, weather, etc. stuff in my environment. FSCopilot transports this to the FSInn UI via the FWInn framework. So I defined three keys, and now I can control the squawkmode from LUA, with buttons etc. just by sending these three special keypresses to FSX. So the problem is solved and I can include these commands into my transponder code for my GoFlight device. And it's an easy solution. Thanks for sharing your ideas to overcome this problem. :razz: :razz: :razz: Rgds Reinhard

Hi, The sb3gaugebridge.dll has the following function according to Jose Oliveira: This module allows to gateway between SB3 FSUIPC SDK/FSINN SDK/XML vars. It's necessary for making all my SB3 plugins to work with FSINN. It also allows gauge developers to use FS vars instead of FSUIPC. Just drop the dll in modules directory. For developers: Interfaces: FSUIPC based as adopted by SB3 Offset 0x7b80, 1 byte, SB3 State, 0 = not running, 1 = running as an external app, 2 = running as a Flight Simulator module Offset 0x7b91, 1 byte, Transponder mode, 0 = normal, 1 = standby Offset 0x7b92 1 byte, ATC activity indicator. This value is normally set to 0. When SquawkBox receives a ping from a nearby ATC, it sets this value to 1. If you want your gauge control to flash your ident light you should check this value periodically. As soon as you notice the value is set to 1, you must reset it to 0. Offset 0x7b93 1 byte, Transponder Ident pressed. When the user presses the ident button on your transponder gauge, you should set this value to 1. When SquawkBox notices it is set to 1, it will transmit an ident on the network and reset the value to 0. BOOL32 named var as adopted by FSInn FSCOPILOT_TRANSPONDER_MODE, BOOL32 named var transponder is client, Transponder mode 0=Standby, 1=Normal, 2=Ident FSCOPILOT_INN_MODE, BOOL32 named var transponder is client, 1=FSInn running, 0=FSinn not running XML L:VAR 859Mode: XML L:VAR, Transponder mode 0=Standby, 1=Normal 859ID: XML L:VAR, Transponder ident pressed, 0=Not pressed, 1=Pressed 859ATCInd: XML L:VAR, 0=No interrogation from ATC, 1= interrogation from ATC 859VFRMode: (optional), XML L:VAR, 0=IFR,1=VFR, The module will put in FS the transponder code indicated in the file sb3gaugebridge.ini at FS root directory under section and indicated by vfr= Note1: The FSInn interface doesn’t support ATC activity indicator so there is no mapping between XML/SB3 interface to the FSInn interface for this. Acknowledgments Pete Dowson for FSUIPC and the key; Joel DeYoung for SB3. Any problems doubts please mail to jcboliveira@flysplash.org Thanks for using my work José Oliveira [/CODE] So it's necessary for some transponder gauges to use the FSUIPC/SB3 offsets. FSInn never used for its communication with the FS9 the FSUIPC interface but they had their own communication via FWInn etc. But obvoiusly FSInn reads the FSUIPC offsets either direct or via WideFS to change the squawkmode. For testing purposes I logged the 0x7B91 offset and I see, that's correctly set by the controls and that's transported via WideFS to the second PC running FSInn. It really looks like, that FSInn in the 64bit environment now doesn't react on this offset any more. Rgds Reinhard

Hi, I typically used with FS9.1 your controls according to the "Advanced Users" documentation: 1119 Xpndr stby (sb3) 1120 Xpndr on/mode c (sb3) 1121 Xpndr toddle (sb3) 1122 Xpndr ident (sb3) I used the sb3gaugebridge.dll in the Modules folder with FS9.1. And that's it. It worked perfectly. Therefore I assumed, that this should be no difference with FSX. My personal feeling is, that this is not related to FSUIPC but to the 64 bit environment (.NET etc.), which might not fit perfectly to the unmaintained FSInn. Some aircrafts also did set the offset 0x7B91 directly when triggering the correct actions on the panel with mouse macros, and then FSInn squawkmode was automatically set without the need of the controls. But with FSX on Win 7 64bit I tried all these methods (offset, controls, etc.), but I didn't get this feature working. Rgds Reinhard