Pete Dowson

Looks like it already checks the ground flag before it starts playing the turbulence wave. It simply doesn't check for ground afterwards, so if you land and there's still turbulence on the ground, it will still play. Is that what you are getting? I'm afraid I'm away now until Monday, so apologies for any delay in further answers. Pete

Fine, well done indeed.! And all this without even bothering to ask me anything! For your information FSUIPC has no effect on any axis sensitivities whatsoever. Sensitivity is a matter for Aircraft CFG files and the like. Axes simply provide numbers to be applied to controls, and all of those are either passed through untouched or subject to calibration to suite the user and aircraft. Carry on flying happily, but don't come here blaming FSUIPC for your woes now you are without it.. That is simply wrong. Pete

You'd need WideFS enabled (i.e. registered) and WideClient running and connected on the PC running ASE. There's no other way FSUIPC can get the weather from ASE. If ASE were running on the same PC as FSX then it could do it directly. On a Network it has to rely on WideFS. No, it will be automatic. Pete

Well it wouldn't have any noticeable impact really., and the loop wouldn't be needed if you merely monitored the altitude with an event.offset. Well, you are already monitoring the "on ground flag" with your event.offset(0x0366, "UW", "logvs") There's no difference monitoring the altitude. The "conditional" part is programmed, in whatever way you wish, in the called function. Could you show me what you tried, please, as I don't understand. How was the Lua program being started -- maybe it simply wasn't running? Only the Lua and LuaDebug controls actually start a plug-in unless you have them automatically loaded via ipcReady.lua or some [Auto] section in the INI file. One of the latter methods is advisable for plug-ins you want running all the time monitoring events. Each time you loaded, compiled and ran the plug-in using the Lua command, you are killing the previous version that was running. so that makes a nonsense really of using events. Running Lua ptrograms on key or button-presses is used for one-off actions, not really something you want to keep running. Yes, as documented. Yes. There used to be only 32 but this was extended recently. I don't know. you put it there I assume. It appears to be running executing the function, which wil be exected again when the next line executes in any case. Why did you put the red line in? The "function" line declares that the code from there until the complementing 'end' is a function (a sequence of code) which will be called by something else (like the event occurring). The parameters for the function must be given names if you want to use them in the function. You cannot declare a parameter as a number, like '0' because numbers cannot be given vslues -- they ARE values already! Probably best to visit the Lua website and browse some of the introductory texts they have there. I see now how you got the red line. That was needed to do the initial call to the function which, when that plug-in was written, was not carried out automatically when the related 'event' line is executed. FSUIPC was changed to do this automatically, so it is no longer necessary. Note that the Lua plug-ins supplied for VRI devices are intended to be run automatically by provisions made explicitly for VRI in the FSUIPC INI file. They were NOT designed to be run by keypress as you are doing. Regards Pete

Yes, thanks for your suggested documentation. I've experimented with an implementation of my solution #2, and I think that might be better -- no need then for any user complications. So far it works perfectly and i really can't see any disadvantages, so I'll probably go with it, pending more tests next week. I'm away from tomorrow morning till Monday in any case. Regards Pete

Anbother thing. I know that until a correction is/was issued for the VRS FA-18, there was a problem in the way it used certain FSUIPC offsets which used to be wrong but which have recently been fixed. I can't see how this can be the cause of these errors, but could those of you who get them please try FSUIPC 4.743 with this line changed in the [General] section of the INI file: AxesWrongRange=Yes Just add the line if the parameter isn't there. Let me know please. Pete

I spent a while today looking for some sort of bug in FSUIPC, without success. Here's what i think happened in your case: Your original (?) code sequence for the display was: ipc.display ("Vertical speed at touchdown = " .. vs.."\nIAS at TD ="..ias) State,x,y,cx,cy = ipc.getdisplay() ipc.setdisplay(2000, 2000, 3537, 2435) If I try this with a "virgin" FSX -- one not having seen a Lua display before -- I get the State, x, y, cx, cy to be all zero initially. I believe this is because at the time the "ipc.getdisplay" function is called, the window has not actually yet been drawn. Then the "ipc.setdisplay" may move/size the Window, if now drawn. If I change the above sequence to: ipc.display ("Vertical speed at touchdown = " .. vs.."\nIAS at TD ="..ias) ipc.sleep(50) State,x,y,cx,cy = ipc.getdisplay() ipc.setdisplay(2000, 2000, 3537, 2435) then it all works as I'd expect. The initial values you then get for State, x, y, cx, cy are for the default position and size (NOT the top left or "home" position, incidentally). By experiment I discovered, on my PC at least, that a "sleep" of at least 20 milllisecs is needed to guarantee getting a proper result. I'm not sure at present what, exactly, to do about this. I can think of three possiiblities: 1. Leave it as it is and just document that the display may not exist immediately after the 'setdisplay' call. 2. After a "setdisplay" call, wait (i.e. do not return to the Lua execution) until the display actually exists and/or is updated.. 3. If when a "getdisplay" or "setdsplay" call occurs the display does not exist, wait up to something safely above 20 miilliseconds for it to appear before returning all zeroes if it doesn't. I'm inclined to implement solution 2 as both the others still exhibit a degree of uncertainly. In most programming you'd expect the window to exist when the function returns. Here it's all a bit asynchronous because the window is not really created by the Lua thread but by a request to FSX. It is an FSX window, and I don't actually get a handle to it -- all I can do is find it as for any other window. Regards Pete

I'm not really sure exactly what you are doing (e.g. why you are using a Flag?), but it looks like you are simply monitoring the radio altitude and acting when it gets to 52 or less. You could of course monitor it by an event.offset on 31E4. However, I see you have a Sleep(50) in the loop, so it is not really a resource hog as it stands. Er, I'm not understanding what you are saying here, sorry. The flag event should certainly be triggered by a LuaSet, LuaClear or LuaToggle action, providing it changes the flag -- that is the main purpose of the event.flag facility, as documented. What exactly do you mean by "Lua and LuaSet on the same keystroke is used to trigger the event"? Are you re-loading and re-running your Lua plug-in each time? That rather spoils the point of using Events. I can help if you can explain a little more of what you are doing, please. Regards Pete

Thanks for your contribution! Regards Pete

What has "uninstalling FSUIPC" got to do with steering and veering? FSUIPC only does what you ask. Ask you need to do if you made a hash of your settings is delete the INI file which contains all of the settings you made, including the bad ones. Since FSUIPC only ever does things when installed and running AND when told to by settings you yourself actually make, and, further, since all the settings are contained within the INI file and NEVER distributed anywhere else in your computer system, this all simply proves that your problems were nothing whatsoever to do with FSUIPC in the first place. Sorry, you'll need to look elsewhere. You've messed something up somewhere else. I could have helped answer questions about what you might have done wrong in FSUIPC settings had you been actually using them and still had the INI file, but as it is you are not (and probably were not ever) using FSUIPC to help with your controls, there's no way that can happen now. Regards Pete

Further to this: It just occurred to me. I'm now reading this as saying you programmed 'a' on the 2nd keyboard to send the letters S, h, i, f, t, then Q? If Notepad displayed "ShiftQ" and not just "Q" then that is what ou've done -- so naturally the first key seen in FSUIPC is the 's'! You need key COMBINATIONS, not SEQUENCES! Please go back and read the HidMacros documentation more thoroughly. Somewhere it will tell you how to add Shift, Ctrl, Alt and maybe other combinational keys (FSUIPC accepts Tab, Win, Menu and App keys too as 'shift' combinations -- the keys on either side of the space bar marked with Windows symbols). Avoid Alt as this will generally open FS menus. Pete

What script? Why not simply test the "on ground" flag at offset 0366? Pete

But that doesn't help find and fix whatever the problem is, does it? And I can't support old versions. Regards Pete

Switcher? I assume you mean a normal Ethernet switch? I'm afraid I can't really help setting a Network up. Please check all the windows help for that. Once you have the network actually operating properly in Windows, then WideFS will have no problems. It just uses standard TCP/IP by default, like everything else. Regards Pete

Not really. It seems it only happens with that VRS Superbug, and I've no idea what is happening in SimConnect to get a standard FS control rejected like that. You could try to get more information by doing as follows: Edit the FSUIPC4.INI file, adding Debug=Please LogExtras=x401 to the [General] section. The log might be quite big, so ZIP is and send it to petedowson@btconnect.com. Might as well get a SimConnect log as welll -- see instructions in the FAQ subforum. And include your FSUIPC4.INI file please. Otherwise, maybe I could try to trap it but I think you should contact the aircraft support folks first to see what they know. If they'd like my help nailing it they'd need to supply a usable copy for testing. If this happens I'd need to see your FSUIPC4 INI file too, to see if it is specific to certain settings. Regards Pete

Oh, I think you did. You just missed out stuff. So that answers my first question " where is what displaying "a" or "ShiftQ"? But you missed the other two, concerning FSUIPC: 1 What does it display? ShiftQ or s? and 2 Have you tried programming FSUIPC by actually using ShiftQ on the 'normal' keyboard? Pete

What "error in the FSUIPC install"? Sounds like the DLL.XML file was corrupted by the Abacus installer, and re-running the FSUIPC installer fixed it for you. From what you say there was no installer error at all. The Add-On menu entry is created by SimConnect on the request of programs interfacing to SimConnect, such as FSUIPC. If the Add Ons entry does not appear it generally means that no programs which use that menu have been loaded. This would certainly occur if the DLL.XML file was corrupted. You seem to write as if you believe the Add-Ons menu is some creation of FSUIPC, which it most certainly is not!!. If I had been able to I would have created a Modules entry instead, for compatibility with FS9 back to FS98! Pete

Okay -- where is what displaying "a" or "ShiftQ"? What does it display? ShiftQ or s? Have you tried programming FSUIPC by actually using ShiftQ on the 'normal' keyboard? Pete

I think, in either mode, if you move or size it manually first, thereafter it obeys the setdisplay. Moving or sizing it seems to fix the bad values. Once the entry in the CFG file is reasonable, it works -- so you could, instead, edit the CFG file entries to be reasonable. I think that's why I've not seen anything wrong after that first test I did -- the CFG file has good values in it now. Pete

You really need to follow the instructions in the HidMacros documentation. I cannot do everything for you, especially not this week when I'm still trying to catch up after my holiday. Surely it tells you that the "script" goes into some file or other you must create? I really shouldn't have to read it out for you, please do that for yourself. Surely building a cockpit and flying an aircraft involves some amount of complication and a lot more so than this little bit!? Pete

I think you'll need to wait till I can fix the original problem, then -- I'm afraid not till next week. Don't know why it affects you this way but not me. maybe it's a difference between full screen and windowed mode FS? I've not had time to test all modes. Pete

It's the FS ID but sign reversed for FS9 compatibility. The ID can be used at offset 2900. A float is a normal 32-bit floating point number, so just print it as such, eg, sprintf with %f and cast to double. All languages surely support both 32- and 64-bit floating point numbers -- they've been standard in Intel processors since way back. No. FS degree units exactly as documented. Please do use the documentation. Regards Pete

Your revised version works fine here. Delete at least the Docked line in the CFG file, which is obviously the result of one of the earlier tests. I suspect that is resulting in the window not being created and therefore not being movable either. Pete

Well, just glancing there I can see two possible ways. One is by using something like to write to the FSUIPC offsets directly. You'd need to download the FSUIPC SDK to find the offsets you need, assuming we are talking about default aircraft or only controls supported by FS itself, not add-on extras, or, probably more flexibly, use which would enable you to use key combinations and program those in FSUIPC, or, maybe, just use those key combinations specific to the add-on aircraft you want to use. Nor I. It isn't programming the way I know. It's more a matter of reading the documentation and following the examples. The keypress method should be easy enough, surely? Pete

Okay. Here's what I found. 1. The ipc.getdisplay function can return incorrect values initially -- until the window is sized by hand, or maybe by sizing the FS window itself. This is when it is docked. I think it is okay when it is undocked. This is strange, so I will investigate this and fix it when I can -- maybe next week now. 2. Your ipc.setdisplay(2000, 2000, 3537, 2435) seems to require a very large display screen indeed. The window is getting displayed off screen. I have two 1920 x 1200 displays side by side, making 3840 x 1200, so even on those your window is way off below them both and of a size which can't be handled. With a docked window, in any case, the position is relative to the FS window which makes it even more impossible. Did you not realise these numbers are in screen pixels? I'll certainly look for and fix problem 1, but you need to select more reasonably values for your ipc.setdisplay call. Regards Pete