Pete Dowson

If you mean as a separate reverser from the throttle, then it sounds like the actual throttle lever is not in a stable position and is sending occasional values ("jitter"), so resetting the FS throttle position. You might need to enlarge the throttle idle "dead zone" on the throttle calibration. Pete

If it starts earlier than you want you can still put a sleep in to delay it. I just couldn't figure out why you were making it a never-executed function, that's all. Regards Pete

No. If there's cloud near at all it's then all FFs. I tested with few and scattered clouds, makes no difference. It's rubbish, really. Not really -- it seems to not know where the cloud tops are, same as I don't except visually. I think it is just going by cloud bases in the area. It ignores cirrus by the look of it as well. I really don't think it is useful for anything. Pete

I wrote a bit of extra code just to read the cloud array now and then and tried it with different weather patterns. It doesn't work. Well, it sort of does something. The only values ever provided in the array are 0 for no cloud and 255 for dense cloud, and the patterns in the 64x64 array are always great rectangular swathes. The array might as well be 64 x 64 bits, not bytes. It really isn't good enough for any sort of weather radar, and, for your purposes, it is certainly worse than simply using the weather reported at the aircraft. I'm not implementing a facility using such an unfinished SimConnect option. Sorry. Regards Pete

You can't set offsets "right after FSX started", only when it is ready to fly. Since the ipcReady.lua is automatically run when FSX is ready to fly, why not simple have just the one line: ipc.setbitsUB(0x56BD, 192) -- switches and save it as "ipcReady.lua"? If it only wants to happen when a WideFS client has connected, save it as a Lua file in the same folder as Wideclient instead. What calls the function called "Anything"? If those lines are all there is then nothing will happen, will it? Why are you inventing a function with nothing calling it? What is the significance of the two minute wait (120000)? Why 2 minutes? Two minutes from when? How are you running this Lua? Why are you making it so complicated every time? Pete

Everything you need is in those manuals. Just look at the INI file -- you can match the entries in that to what it says in the Advanced User's manual. It is all designed to be easy to use via the options dialogue. If you want to mess with settings in more detail, or do advanced programming with buttons and so on, then you have to edit the INI file, which is a text file and easy to read and edit in any text editor such as NotePad. I can of course answer specific questions here, but there is no way to provide a general tutorial on all of the thousands of things folks might want to get up to. That's one of the problems with a "toolkit" like FSUIPC -- you don't get instructions with Swiss Army Knives either. Tools are to be used in whatever way you find them useful. Regards Pete

Again, though, if your Lua program is executed before FSUIPC has been running for 50 seconds, or after 70 seconds, that won't match anything. How are you starting this program, watching the seconds hand on your watch then clicking an assigned button when you think you might catch it? I really don't understand what you are trying to do. It makes no sense to me. Sorry. In that case you'd need to either name it "ipcReady.lua" so it loads when FS is ready, or have it called by a "runlua" statement in such a plug-in, or possibly run it via an [Auto] section in the FSUIPC INI file. And then the easiest thing to do is work out how many seconds you want it delayed after FS is "ready to fly" and use ipc.sleep to wait that long before doing anything. Testing elapsed time really isn't that useful when all you want to do is wait a while. It's for determining the time between events, and stuff like that. Regards Pete

32x32 only needs 1024 bytes of course. If I were to re-use the B000-B3FF METAR writing area for reading this array, I could do 2 x 32x32 arrays, one front and one behind, making effectively a 64 x 32 with the aircraft in the middle. But it would mean two separate calls to SimConnect and I'm not sure how the timing would work. I might have a look at it when I have a free moment. No promises -- I hope you have something else to occupy yourself! Regards Pete

No, I don't like that idea. But I could consider doing a lower resolution version. Instead of 64 x 64 values of 0-255, either 32-32 (each being an average of 4 neighbouring areas), or, probably better, 64 x 64 4-bit fields giving a density range of 0-15 instead of 0-255. Note that it wants parameters for: float minLat, float minLon, float minAlt, float maxLat, float maxLon, float maxAlt, so you could offset the loss of resolution at one scale by asking for a smaller area. with that thought a 32x32 with averaged values would be more flexible I suspect. If the only application is always an area of x nm around the aircraft -- or, better, ahead of the aircraft, the the lat/lons could be worked out in FSUIPC, leaving only three parameters needed -- range, min alt and max alt. I don't even know if the facility in SimConnect works -- I've never used it and I don't know if any of the WX radars do. I suspect RXP especially of implementing theirs via direct hacks into FS. Regards Pete

I can't force programs which might be reading the METAR read area to wait until something else has read the cloud data or timed out. And I can't tell whether whatever is reading it is wanting METAR data or cloud data. One wanting one could crash if the other was there instead. It might be different if the whole 4k were a write area which I can separate. Pete

No. Not really -- I'd really be loathe to add it now. It's a SimConnect function only and has no similarity to anything in FS9 and before, which is really where FSUIPC's job lies -- providing compatibility. I know I've added some FSX only stuff, but only where it fitted in with the FSUIPC way of doing things. This doesn't, and it not only needs another one of those horrible multi-user interlock and timing mechanisms, which I swore I'd never do again, but it also needs 4096 bytes of valuable offset real estate. The latter is limited to the current 65k because if it ever exceeds that i have a massive WideFS rewrite to do. (When all this first started, with a 2k global area defined for offsets, no one would ever have dreamed that (a ) the whole interface system would still be alive and delveloping, now and (b ) the 16-bits allowed for offset identification would ever be a serious limit). It's sounding to me more and more as if you should be using SimConnect rather than FSUIPC. I'm sure you'll be finding a lot more you need and I'm really not developing FSUIPC in those directions any more, but concentrating only on user facilities. For FSX interfacing I always expected all new programs to use SimConnect directly, as Microsoft intended, of course. Neither, but by doing what you could have done, reading the layers in C000-C3FF and determining which is the most likely to be the one containing the aircraft. That's how you'd do it if you wanted compatibility with FS9. Regards Pete

Not surprising really, is it? What are the odds of that line in Lua (inittime = ipc.elapsedtime()) being executed just at the one millisecond that the elapsed time, a pretty random but increasing number, happened to equal precisely 100000? If is doesn't happen, which odds are probably almost infinitely against, then the code is skipped to the end and the Lua plug-in finishes its job and exits at the end. I'm really at a loss to understand what you are trying to do. what is so special about the exact moment 100,000 milliseconds after FSUIPC starts running? BTW, instead of ipc.setbitsUB(0x56BD, 64) ipc.setbitsUB(0x56BD, 128) it would be more efficient to set both bits together: ipc.setbitsUB(0x56BD, 192) Regards Pete

The names are not mine, they are FS's! The list is automatically generated from the tables in FS's "CONTROLS.DLL", and that contains the same names it uses for assignments in its own CFG and Controls.xml files. The "names" you see in its own assignments dialogues are not names but translations for different languages, and only cover a minority of those actually accessible.. I think you misunderstand FSUIPC's function in life. All FSUIPC is doing is providing you with a link between a button or key and an FS-defined control. Neither FSUIPC nor myself have necessarily any knowledge about what those controls do. I wouldn't dare try including a translation table to my own interpretation. Who says I'd be right? I could have made it directly understandable by just listing the numbers, then you would always need to look them up or do some logging to find them. I thought it might be a little easier using the names Microsoft chose instead. It's one or the other. Please just use the Event logging. It is quicker and more reliable than searching lists in any case, even though in the case you are moaning about the controls would have easily been found by a quick search. Pete

No. SimConnect, from SP2 I believe, includes this call: 04CB is at the aircraft location, but not necessarily the aircraft's altitude. It is precipitation to ground. All weather data provided by FSUIPC is by reading it from FSX, which ofr FSX means FSX SimConnect style METAR readouts (which are subtly different from METARs being written). For the aircraft location it is the interpolation ptrovided at that position provided by SimConnect on request. It's similar in FS9 and before, but the data is obtained in binary form from FS's internals. Cloud/wind turbulence at the aircraft is derived from determining the wind layer you are in and checking that, normally in the C000-C3FF area. but in FSX there are new offsets for this at 0E88 and 0E98. Regards Pete

No, not offhand. For FSX they could simply be reading the cloud distributions from SimConnect. For FS9 or FSX they could simply be reading METARs for weather stations in range, and interpolating, much as SA_WXR does, for instance. If they are getting more accuracy and detail then I can only assume they've managed to hack into the FS code. Cloud types readable are only cirrus, stratus, cumulus or cumulonimbus (storm). In FSX there's no information about cloud top altitudes, only cloud bases. And unless the cloud is 8 oktas there's not even a way of telling whether you are in or between clouds even at the right altitudes. It is all very unsatisfactory. These things were on the list for "future SimConnect updates". :-( Pete

It sounds like the installer for the "FSX compliant radar screen" messed up the DLL.XML file. What is "FS Host Client"? If that installs an EXE.XML it may enable something which provides an Add-On menu, but not help the DLL.XML file. There's never any point in doing any of that. The DLL is just a DLL. Replacing it with the same DLL does nothing. Unless you deleted your KEY file there's no need to re-register either. You'd need to revert to the DLL.XML pre-install, not post-install if that corrupted it. Or, for test purposes, simply rename the DLL.XML so you don't lose it, and reinstall FSUIPC so that it creates a new one. Yes, of course. Corrupted DLL.XML files seem a common result of some poorly written installers. The XML files are text, so you can paste them into a message here so they can be checked. But first try renaming the bad one you have and installing FSUIPC again. If that's okay and you want the main one fixed, paste it here and I'll take a look. Regards Pete

Of course. You can use any library functions in functions, just as you can use any functions in functions. But all the ipc.elapsedtime function does is return the elapsed time, in milliseconds, since FSUIPC started. What are you using it for? How are you calling your function? The plug-in you namee ipcReady.lua is automatically called when FS is "ready to fly", which is presumably too late for you if you want to set something "right after FS is started", but "ipcInit.lua" is executed as soon as FSUIPC is initialised, which is much earlier (though still not "ight after FS is started" which is of course not exactly possible). I'm not sure what you can validly do then, though. Perhaps you should explain a little more? Regards Pete

Hmm. That's strange. There should new no reason it can lose sending these messages. Do you have errors listed in the WideServer or WideClient log files? Pete

Sorry, I don't understand what there is to show or explain. If you know the pathname to the program you want to run, you just use it as the parameter. What more is there you need? Oh, there is one thing I ought to tell you. In the Lua strings the character \ is used to introduce special characters like "return" (\r), "tab" (\t) and "newline" (\n). So when you need to use it for real, as in a pathname, each use needs to be doubled, like \\. That means it is a real \.. Okay? Regards Pete

The list of FSUIPC offsets is part of the SDK. you can get the FSUIPC SDK from the usual place -- the Schiratti site. Pete

By "function" do you mean on/off switch? To find FS controls equating to switches in FS cockpits, try using the Event logging in FSUIPC. Switch that logging on, then operate the control. If there is an FS control associated with the switch it will be logged, by name and number. Another way is to refer to the list of FSX controls installed for you in the FSUIPC documents folder. Searching for "Alternator", for example, brings up these controls: Or, if you want to use offsets, why not simply search the FSUIPC4 Offsets Status document (in the SDK). Searching for generator soon reveals the switch controls for the generator associated with each engine. [LATER] Oops, I see Andy beat me to it, again! ;-) Regards Pete

Can you tell me why, please? When would you actually want both your elevator trim axis AND the autopilot controlling the elevator trim? How would this ever be more "comfortable". In my cockpit, using Project Magenta, using the elevator trim axis manually, or the electric trim buttons on the yoke, disconnects the A/P automatically. That is normal, but I cannot understand why you'd use both at the same time. So, though you said you'd explain, you did not, at least not yet... Not that I know. You cannot switch the FSUIPC option on or off without going into the FSUIPC Options. I already explained this to you!! You could, if you are so ambitious for reasons you have not revealed yet, program it yourself using a Lua plug-in or other program, or even repeatedly pressing a button assigned to write to the FSUIPC axis disconnection offset. This was discussed in another thread not long ago: hdisconn-elev-trim-axis-for-ap But before rushing off, please please explain why you want this! Why is it more "comfortable"? Regards Pete

I wonder how you thought otherwise, then, when the instructions for making a "mouse macro file" has you entering FSUIPC options to start the mouse macro mode and provisding a filename for it, then making al the macros for that file, then re-entering the options to terminate the mode and close the completed file. That's how it is documented. If each infdividual mouse operation had to be in a separate file, why would it have to involve three operations and two names? I cannot see how this is ever implied. Yes, and this is how the term "macro" s used in FSUIPC too. The macro facilities in FSUIPC were implemented for named groups of different (or similar, as needed) actions carried out in the listed sequence and triggered by the assignment to a single button or keypress. It is fully implemented in this way for FS control and keypress actions. The "mouse macro" option came later and was "bolted onto" this existing facility. Since each mouse action needed some identification, a name, I used the Macro name as the specific action name in the existing macro structure. So, in this case such macros only have one entry -- the code position and check bytes for the action to proceed. There was no room without a massive re-write to do otherwise. The same happened when I added the Lua plug-in facility. This needed the Lua filename, and again that takes the macro name position, so macros calling Lua plug-ins only have one entry. Then the same happened yet again when I discovered how to write to local panel variables (L:Vars), which also need a name. So, I ended up with a proper macro facility, in the way you think of it, but with three special cases -- mouse macros, plug-in actions, and L:Var setting, each of which having only one entry. No, I really am NOT using the term in that way. A macro file is still a collection of macros, each of which can normally contain a series of actions. It is only the three exceptions with names which are restricted There's actually nothing in FSUIPC excepting some of the more obscure [General] parameter options which would require a restart of FS. It sounds more likely that you deleted the MCRO file without going into the FSUIPC options and ending the mouse macro creation mode. Or simply didn't end it at all and so couldn't start another. FSUIPC will automatically end it when you close FS of course. Note that you can manually edit the INI and MCRO files at any time whilst FS is running provided you tell FSUIPC to reload them -- each of the assignments and calibration tabs in the options have buttons to press which reloads all settings relevant to that area. Regards Pete

I understood that was what you meant, but with what method? After all, you said the G1000 FS controls did not work, and I found the L:Vars and Mouse macro methods of no use for that gauge. I didn't actually bother to try the G1000 controls because of your earlier report. So it sounds like it is the G1000 FS controls you are using after all? That's all I wanted clarified. Regards Pete

Sorry, you've lost me entirely. How is this related to the G1000 and whether FS controls, mouse macros or L:Vars work on it? Pete