Pete Dowson

So I assume even Task manager won't get rid of it? I've known some awkward programs like that. I don't know how they do it! All that happens with CloseKey=Yes is that FSUIPC will send a "WM_CLOSE" message to the topmost window of the process. Maybe it's topmost window isn't processing the messages in the same way, and the window you normally click X on is not that window. However, Windows itself normally sends a WM_CLOSE to each child Window in turn, so it is odd. Maybe the top-level window explicitly clears or sets some values which the lower ones check and thereby do some different actions. There's really no easy way I can make an automated process for programs which do such things. There's no way possible to automatically determine the Window which is processing the WM_CLOSE the way you want. Assuming the top-most window does work with 99% of programs though. Well, maybe -- just maybe -- I could add an option to the Close facilities to send the WM_CLOSE to the window in the Process with a given ClassName. When you use the utility on VASfmc does it give you different classnames for each window, and if so would you be able to tell which one you close with your 'X'? Regards Pete

To ask FSUIPC to read specific weather it has to Write offsets first. There are a number of NWI Commands to do different things. One is to read the weather, and before sending it the requesting program has to set values such as the ICAO ID of the weather station, or the Latitude and Longitude for the weather it wants. I doubt that SIOC is doing that unless it is a pretty sophisticated weather program designed to do so. I provided an example utility which uses the NWI -- WeatherSet2. Play with that and you'll see what the NWI can do. You say you don't want weather at the aircraft nor at any weather station, but you don't say where it is you want the weather for! Really there's not much other weather, as FS doesn't simulate other planets. How can I possibly advise you unless you make up your mind what weather it is you want to know about? And you completely missed the whole section on the offset area you are trying to use? Incredible! :-( Here, please note the parts I highlight in RED: So, how could you miss the complete section detailing exactly how to use the offsets you are trying to use? That is true ONLY if some program has requested that the weather, for somewhere specified, be read into those offsets. If you don't do the request then either the offset will contain rubbish or will contain the correct value for some place you don't know (unless you read the offsets giving place too). No problem if you just want to use a random value, obviously. But you don't seem to even know what weather you want it to relate to! FSX doesn't have the same weather everywhere you know! Is that what you were thinking? Pete

The commands, as documented in the SDK, as I referred you to, which operate the reading from and writing of weather to FS. It appears you aren't referring to any of the documentation provided! :-( In that case there's only one other option, and that it weather at a given Latitude and Longitude. You certainly have to request that. Neither FSUIPC nor FS can guess what you want! Weather WHERE though? If not at a nearby weather station, and not at the aircraft, where? You are not making sense I'm afraid! But CE8D will only ever be populated with weather when something, some add-on, makes a request to read the weather. And then the weather may be at a distant place. If you don't request the weather, how will you know if there's any provided for that ofset or where it relates to? Evidently you've not read much if any of it! Regards Pete

No, not with the offsets you are quoting. The CC00-CCFF offsets show the weather results after an NWI READ command. You don't appear to be issuing any NWI commands at all. Weather radar mappers use the facility to read the weather at points around the aircraft, to build up a picture. But there's a protocol for that, as documented. If you want weather at the aircraft then either read the FS98 offsets as I said, or use the NWI weather populated in offsets C000-C3FF. However, note that when supplying weather at the aircraft, FSX does NOT supply any data for wind layers other than the one you are in. FSUIPC4 fills in the other layers from the nearest weather station. This information is in the offsets listing by the way. Regards Pete

Ah, okay. Thanks. I understand now. Pete

By "mode" here you only mean the selection of which value the dial is changing, right? If so, then I am pretty sure that is all local to the device. I've no idea why yours is doing that -- I cannot make it happen here. I don't know any command which can be sent from the PC to the M-Panel to change the selection, but maybe that's because I've no add-on aircraft. Maybe you have an early model M-Panel with some bugs in its firmware? Have you asked VRi Support? There's where I get lost. I don't understand why an internal action would vary depending on the aircraft. Maybe the bug in the M-Panel firmware is dependent upon some sequence of commands from SerialFP2 which doesn't occur with default aircraft. If that seems to be the case, then by all means see if you can isolate a log of the sequences just prior to when you notice this discrepancy. You need to enable the VRi logging as documented (i.e. Debug=Please, LogExtras=x4). When you get the log please only show me the stuff for the few seconds before it goes wrong, else there will be too much to wade through. And tell me what you were adjusting and what it changed to in error. Since we don't know why the selection is changing I couldn't say. But you now know how to stop the display commands going to the M-Panel. Maybe there are other commands responsible for the selection change - if so, I've not seen them, but we should see them in your log. Regards Pete

I don't really understand your question, but why not think it through logically? So: 1. You only want to do something when "X" changes. Correct? 2. When it changes you only want to do something if Y = 1 (where Y is some other value of interest). If you do it the other way around, then you will miss changes in X and may miss important changes subsequently. So, the logic has got to be if x ~= MemoryOfX then -- Only do something if x changes if Y == 1 then -- Only do something if Y = 1 DO SOMETHING end MemoryOfX = x -- update our memory of the state of x end See? If you state the logic of your problem, the program is identical, it follows the logic part for part. That is all programming is, logic written down in a form the computer can read! However, in your solution above, which is nearly correct, you are not checking whether the autopilot, which has changed, is now ONit might have changed to OFF. So it should surely be: if x ~= MemoryOfX then if x == 1 then if ipc.readUB(0x6DF1) == 1 then ipc.writeUD(0x07BC, 0) ipc.writeUB(0x6DF2, 0) end end MemoryOfX = x end You can, incidentally, combine conditions, so it could be shortened to: if x ~= MemoryOfX then if x == 1 and ipc.readUB(0x6DF1) == 1 then ipc.writeUD(0x07BC, 0) ipc.writeUB(0x6DF2, 0) end MemoryOfX = x end However you might find the longer forms easier to read and understand until you get used to logic. Unfortunately, this time, you've not answered my questions about missing possibilities. You seem to be rather selective in what you read and what you ignore. If the answers to that question are what I suspect they might be (that the initial condition of the priority switches are irrelevant) then I think you can do all you want by FSUIPC INI assignment lines, except for the one simply loop in Lua for the autopilot going on. Let me suggest a revised set of logics for your complete need, derived from your list. Is there anything wrong with this: First, possibly the only one needing a Lua program: If the Autopilot is turned on (with the button at the FCU) 1. the Autopilot should set on (07BC = 1) 2. the Autopilot heading hold should set on (07C8 = 1) 3. the Priority light at the Cpt Side and the red arrow on the FO side set off (6DF1 = 0). 4. the Priority light at the FO Side and the red arrow on the Cpt side set off (6DF2 = 0). Then all the others with no conditions collapse into only two, one for each button, and therefore easily dealt with in FSUIPC INI button assignments If Cpt Sidestick priority button pressed then (i.e. doesn't matter if A/P is on or off, or FO priority on or off?) 1. the Autopilot should set off (07BC = 0) 2. the Autopilot heading hold should set off (07C8 = 0) 3. the Priority light at the Cpt Side and the red arrow on the FO side illuminates (6DF1 = 1). 4. the Priority light at the FO Side and the red arrow on the Cpt side set off (6DF2 = 0). If FO Sidestick priority button pressed then (i.e. doesn't matter if A/P is on or off, or Cpt priority on or off?) 1. the Autopilot should set off (07BC = 0) 2. the Autopilot heading hold should set off (07C8 = 0) 3. the Priority light at the FO Side and the red arrow on the Cpt side illuminates (6DF2 = 1). 4. the Priority light at the Cpt Side and the red arrow on the FO side set off (6DF1 = 0). Regards Pete

Sorry, can you clarify that please. Are you saying that when you change the A/P Heading the SPD or V/S values are also changing in FS? Or only on your panel, so that the panel then no longer matches FS? If you stop those (which is perfectly possible if you know the parameter format) then you will stop FSX values being shown correctly on the panel. Surely this is undesirable! You then cannot realy on the M-Panel and will always have to refer to the FS screen instead! The VRi Panel is only reading and showing the values it gets from FS, surely? I don't understand where it could be getting incorrect values from. I have an M-Panel here and haven't seen any problems with it. Is it related purely to the add-on aircraft you are using? Of course I've only ever tested it with default aircraft. I really don't see how VRi can support many of the add-on aircraft with their non-standard non-FS autopilots. If you simply want to stop the VRi device displaying FSX values, then you simply filter off the commands it receives telling it to do so. However, I'm not sure you'll be pleased with that. If you know how to get the correct values to be displayed then you could write a Lua program which "corrected" them. With some add-on aircraft which do their own thing there is no way to read the A/P values - PMDG aircraft are like that. I don't know if the F1 ATR72 is as bad. To block them you need to use the VRi Lua facilities provided by FSUIPC, as documented in the "Lua Plugins for VRInsight Devices" document provided. You may already be using the example shown there to get the M-Panel pressure display showing optionally in hectoPascals or inches rather than only inches. If not, do so now, then simply add lines like the following to stop the driver setting the displays: WrFilter.2=SPD? WrFilter.3=VVS+? WrFilter.4=VVS-? The strings for HDG and ALT are similarly HDG? and ALT? Regards Pete

Are you just reading weather or wanting to set it too? If only reading, are you wanting to read weather at the aircraft, or at some specific place? Er, named? I don't name offsets individually. The structure for clouds has a name, as do its components, of course. Whatever weather you are reading, there may be anything from 0 to 16 cloud layers. You need to read the number of cloud layers and not read any offset which isn't valid for the number of cloud layers actually present. FSUIPC doesn't guarantee to zero unused offsets. Turbulence and precipitation where? At the aircraft, on the ground, at a weather station, at agiven Lat/Lon? I assume you want it at the aircraft, in which case you have to scan the cloud layers, if there are any, and find out which one you are in (for turbulence) or is just above you (for rain). For wind turbulence you have to scan the wind layers to find which one of those you are in. Yes, of course it is possible (assuming you have a way of lighting a LED). It just may not be quite like you think. If I am wrong I apologise, but your earlier referring only to FSInterrogate had me worried you were missing too much. For simple "at aircraft" values I recommended the old original FS98 offsets for this reason. They have been maintained throughout all the FS versions for a reason! ;-) Regards Pete

The autopilot master light goes on and off with the autopilot (07BC), which offset is controlled by normal FS controls. Offset 078C is merely a flag which is "true" (1) if a spoiler is available on this aircraft. You probably meant 07c8 as in previous messages, which isn't the A/P light but the heading lock. Again there are standard FS controls for this. Well, change 078C to 07C8 (when programming silly little errors like that will make it fail and be a devil to spot. Always take care, whether planning or executing) and then just convert all of the conditions to "ifthen" statements and the actions to "ipc.write ..." statements, and you are home and dry. However: I suspect all of those sections EXCEPT the one where the A/P is turned on directly by the FCU and not via assignment in FSUIPC can easily be done using your original multiple assignments in the FSUIPC.INI file. The only reason the A/P one might need to bve Lua is because there's nothing going through FSUIPC when the FCU sets the A/P on. However, there are other conditions you need to state actions for, if any: Autopilot is off. Cpt Sidestick priority button pressed ... Autopilot is off. FO Sidestick priority button pressed ... Cpt has the priority and Capt Sidestick priority button pressed ... FO has the priority and FO Sidestick priority button pressed ... No one has the priority and Capt Sidestick priority button pressed ... No one has the priority and FO Sidestick priority button pressed ... Now these might be trivial cases where nothing needs doing, or they might merge with one of the other cases. For instance, if these two Cpt has the priority and Capt Sidestick priority button pressed ... FO has the priority and Capt Sidestick priority button pressed ... can both result in the same actions without problems (even though some of those actions might be unnecessary) then things simplify -- you don't need to test the "priority" setting when the button is pressed, so it is easy then to program in the INI file instead of Lua. Incidentally, what didn't you understand about my previous message showing you how to detect changes rather than repetitively do the same thing whilst a condition remains true? I am not going to write your program for you. I just want to help you understand what to do. It isn't helpful ignoring my suggestions. Regards Pete

The Lua program was designed to run in its loop all of the time. That's why we put in the 250 millisecond delay. You wanted to write to some offset(s) all the time some offsets were set to 1. Is this not what you wanted? What condition? You have three conditions: if ipc.readUB(0x6DF2) == 1 then if ipc.readUB(0x6DF1) == 1 then and if ipc.readUD(0x07C8) == 1 then While any of those condtiions are met, the associated code is executed. Isn't that obvious at all? I don't think so. I think the solution is for you to work out the logic of what you want to do, which you have so far not manasged to explain to me. If you cannot explain the logic to someone you cannot really successfully program it in any language, as all a programming language does is formalise the logic. If you only want some action to occur when something CHANGES, rather than when is simply "IS" in a certain state, you have to save its state and only act when you read it again and find it is different. You can use the FSUIPC Lua "event" library facilities for that, which is efficient, but I fear that might be too advanced for you to consider. So try simply doing something like: MemoryOfX = -1 -- Make sure seems to change first time while 1 do x = if x ~= MemoryOfX then MemoryOfX = x -- store new value of x end ... If you want to try Events there are examples in the package supplied with FSUIPC. Pete

The New Weather Interface is defined in a package in the SDK called (obscurely?) "New Weather Interface for FS2004.zip". (It was new to FS2004, remember?). That contains a text document explaining how to use the interface, and a C header file which defines the structures used. The latter, in turn, define the data type of each field. so for clouds it defines: // Cloud structure (size 16 bytes) typedef struct _NewCloud { unsigned short UpperAlt; // Metres unsigned short LowerAlt; // Metres unsigned short Deviation; // Metres unsigned char Coverage; // Octas, 0-8 unsigned char Type; // 1-10 unsigned char Turbulence; // 0-4 unsigned char Icing; // 0-4 signed short PrecipBase; // Metres unsigned char PrecipType; // 0-2 unsigned char PrecipRate; // 0-5 unsigned char TopShape; // ? unsigned char Spare; } NewCloud; and as you can see from that the Precipitation Rate is defined as "unsigned char", meaning it is one byte. No, most certainly not! It's a simple number as you know already. Each whole cloud layer entry is 16 bytes! Please use the documentation supplied. I'm not sure how you are using the NWI, but it sounds as if you are trying to pick individual values from it which may not actually work the way you think. If you only want the weather at the aircraft you are really better of using the old FS98 style offsets in the lower areas. Pete

You should need any Class names -- if WideClient creates the process (i.e. runs the program) then it has a Process Id for that process, so it can Close it directly. Just use: RunKey1= CloseKey1=Yes KeySend1=RunKey1 KeySend2=CloseKey1 where of course you change the 1's and 2's to suit your configuration. There's no place to put a "classnname" -- that's only used to send keypresses to programs you've not started in the INI file. THat doesn't apply at all here. If they won't close with "CloseKey1=Yes" try "CloseKey1=Kill". That forces closing in the same way as Windows task manager does, without tidying up the program. Pete

No, they are assigned to FS Communicator, but I suppose it doesn't matter if you don't use that and don't intend to distribute your Lua programs. The area reserved for general use by anyone is 66C0 to 66FF. What is this "endless loop" doing? Why don't you use the FSUIPC logging facilities to see what is going on? You can log Button activity and its results, you can monitor offset 6DF1 and 6DF2 as type "UB" on the right-hand side of the Logging tab, and you can add "ipc.log" entries to your Lua file, temporarily, to log what they are doing. Debugging using logging is always going to be easier and less error prone than trying to follow someone's logic by looking at lines of code. I look at what you are doing and I still don't understand it at all. Offsets 07C8 and 07BC are standard FS offsets operated by standard FS controls, as I already pointed out. I don't see why you had to use FSInterrogate for those when they are so well known and easily handled. It is far from easy for me, I'm afraid, because I still don't understand what you are trying to do. Sorry. Regards Pete

Yes. In fact you could do it just by conditional button programming in the FSUIPC INI file. But in Lua the logic is easier to follow. You need a memory of what last function your button executed, so you can move onto the next. The easiest way is to use one of the free FSUIPC offsets (the range 66C0 to 66FF is free for users). So: x = ipc.readUB(0x66C0) if x == 0 then ipc.control(65911) else if x == 1 then ipc.control(65910) else if x == 2 then -- et cetera, for each view change or whatever function you want -- ending with end x = x + 1 -- move on to next mode if x > 3 then -- 3 for 4 different settings (as we start at 0), and so on x = 0 end ipc.writeUB(0x66C0, x) Save your code into the FS Modules folder as, say "myviews.lua", and assign your button to it in the FSUIPC Buttons page. you may need to ask FSUIPC to relad the settings if you change the file whilst FS is running. Regards Pete

The 2 is normally pressed after the Shift+E, as the latter is the command instigator. Have you tried assigning the "Toggle aircraft exit" control (which is all Shift+E sends in any case), with a parameter of 2? It might work (I think it does on FSX but I have not tried FS9). Otherwise you have to make the one button send Toggle Aircraft Exit, then "Select 2", which would just mean editing the INI file to make 2 assignments to the same button. FSUIPC can only provide mouse macro facilities for gauges written with standard Microsoft FS SDK mouse area definitions. Many aren't. Regards Pete

Sorry, i don't really know what that means. Offsets 07C8 and 07BC are more easily set to zero by the normal FS controls "Autopilot off" and "AP hdg hold off". Offsets 6DF1 and 6DF2 are assigned to FS Communicator. I don't know what it or you are using them for, so the INI file coding makes little sense to me I'm afraif. But 07BC is the standard FS autopilot master switch and is operated equally by standard FS controls. Sorry, but I don't understand any of that. If you can set down the logic of what you want to do, then converting it into a Lua program would be easy. Programming is merely logic. but you need to know what to do first. Regards Pete

Have you looked at any of the many examples I provide with FSUIPC? (In the "example Lua plugins" ZIP). Anyway, what you want isn't exactly complex as it only uses two of the FSUIPC library functions -- reading and writing offsets. There are examples of that, and of using "ifelse" statements. Did you not find any of them? You don't say what size of offsets these are, but 078C is a DWORD (4 bytes, or 32 bits). Assuming your other two are single bytes then you do something like if ipc.readUD(0x078C) == 1 then ipc.writeUB(0x6DF1, 0) else ipc.writeUB(0x6DF2, 0) end If you want this running all the time rather than being executed by pressing a button or key then the easiest way is to make it loop: while 1 do if ipc.readUD(0x078C) == 1 then ipc.writeUB(0x6DF1, 0) else ipc.writeUB(0x6DF2, 0) end ipc.sleep(250) end and save this into the FS modules folder as "ipcReady.lua" so that FSUIPC starts it running as soon as FS is "ready to fly". The "ipc.sleep(250)" is there to stop the program hogging more of the processor than it needs. The delay is in milliseconds, so that makes it check 4 times a second. You can of course adjust that as needed. Regards Pete

That is almost always caused by a clash in SimConnect between two programs or modules it is loading, and is related to a bug in the validity checking it does. It was really bad with the original version of FSX, and never fully corrected, but a work-around was implemented in either the SP1 or SP2 update to FSX (I don't recall which) which works most of the time. If your FSX isn't full up to date I'd advise applying the updates. If it doesn't correct itself on its own (and it does usually), then you might need to shuffle the order in which things are loaded -- editing either DLL.XML or EXE.XML. But first, just try the easiest route -- re-run the FSUIPC4 installer. This will place FSUIPC4 back at the end of the DLL.XML, possibly then occurring after whatever new add-on you've installed. Regards Pete

There are more than that. Please please do refer to the SDK documenta. Do NOT continue to try to learn from FSInterrogate, which is a utility foryou to try stuff NOT an educational tool, and most certainly NOT the source or definition of interface information. There are THREE weather interfaces. 1. The offsets in the lower ranges, mainly 04B4 through to to 05DA, and 0E8A through to 0F8C, all of which derived from original FS95 and FS98 offsets with some additions in FS2000. In general these all relate to the single "global" weather settings which was all that was supported by FS in those days. They are maintained as the "weather at aircraft" to this day, for compatibility (FSUIPC's whole reason for existence was, and is, ongoing compatibility for applications). The SDK's documentation has a lot of text about all this if you want more information. 2. The "Advanced Weather Interface" implemented for FS2002, which included localised weather stations stuff too, but was not offset based but command / response methods. This is now largely defunct, but still works. The original "WeatherSet" application demonstrated this. 3. The "New Weather Interface", developed for FS2004 and extended for FSX and ESP, which is documented in the SDK and which is recommended for all new programs over both of the others. That uses the offset range B000 to CFFF. Regards Pete

No, not in the INI file. That's the file where your settings (normally made in the FSUIPC options dialogue, in FS flight mode) are saved. True, there are some conditional facilities for button actions which can be performed by INI editing, but in general it is what it says, a configuration or INItialisation file. To program things like you are asking you use the Lua plug-in facilities. Please see the package about this which is installed with FSUIPC. For full information about Lua you would need to refer to its own website. Regards Pete

The format of button assignments in the INI file, and ways of making them conditional (on other buttons, or on offsets) is all covered in the FSUIPC Advanced User's document, in the section on button programming. Regards Pete

Erthere's only one "precipitation rate" per cloud layer. Please see the New weather Interface definitions in the SDK. You can'tlearn this stuff from FSInterrogate data files. Where are you seeing the latter? Without specific references it is hard for me to understand your questions. Regards Pete

It is the cloud layer number. You are viewing elements in an FSInterrogate array. I think the FSInterrogate documentation will explain it (but I've not checked). FSUIPC handles up to 16 cloud layers, 24 wind layers, 24 temperature layers and 12 upper visibility layers. Please refer to the "NewWeather.h" header file in the SDK. Pete

Sorry. Ahjust use the "RunKey" and "CloseKey" options in WideClient.INI, programming buttons (whether real or from the button screen) in FSUIPC to send the appropriate "KeySend" values. Regards Pete