Pete Dowson

Not sure about those. FSUIPC has no way into them, but I've not seen them. I think you can turn off ATIS text messages in FS -- I never seem to get them, but I do get the ASE messages telling me it is refreshing weather and so on. Generally it doesn't bother me as the top of the projected screen is above the cockpit window I look through and I'd have to lean forward to see up that far. You might be able to select the message window they occur in, re-size it and move it. I'm not sure about that, but if so you could move it off-screen, or at least make it inconspicuous. Regards Pete

In FSX and ESP the displays from add-ons can only be hidden if they are produced by via FSUIPC facilities. Those instigated by programs using SimConnect directly cannot be suppressed. REX and ASE both interface directly to SimConnect. FSUIPC has no control over them. See if the programs have options to suppress them. If not, it would be a good idea to ask the producers to add such options in future. Regards Pete

The FS autobrake setting (RTO, off, 1, 2MAX) is a standard FS setting, at offset 2F80 (0-5). That's just the preset value. the actual braking is done internally by FS. I don't think PM has anything to do with it. Well you could monitor the braking level offsets, 0BC4 (left brake) and 0BC6 (right brake). Offset 0BCA is a flag which shows both/either. I think that is non-zero when you see "BRAKE" on the screen. To get lights to flash is either an electronic circuit function, or a program function. If it is linked to an offset you could write a Lua plug in to make a user offset (66C0-66FF are free) alternate from 0 to 1 over time whilst the braking indicator is on. This would of course operate for manual braking too, and parking brake (unless you eliminate these by checking the Parking Brake offset and the manual braking indicator at 32F9). Well, it isn't actually "bit 1" (that would be value 2), but the byte being set "TRUE" (=1) or "FALSE" (=0) according to whether the toe brakes are pressed. It is explicitly for detecting manual braking and documented as such. i really don't know why you are looking at that rather than the real braking offsets. Regards Pete

Okay. I knew it couldn't be perfect -- there are bound to be times when your adjustments just occur at the wrong time in relation to the aircraft's changes. But as long as it is better, I am glad. No others. Even if you programmed it all yourself, not using SerialFP2, you could not overcome the fact that writing to the V/S display (or any of the others) causes the selector to move to that value, even if only for a short time. That action is done within the M-Panel's firmware, so you cannot program around it from outside. Regards Pete

Yes. The mouse macro facility can only work when the aircraft gauges are written using the standard C/C++ gauge SDK. it relies on their being a distinct tabular structure containing the addresses in code of the routines which execute the mouse clicks. Almost none of the default FS aircraft are written this way. Unfortunately Microsoft did not use their own SDK to make their aircraft. If you read the documentation on the mouse macro facility I think you will find it tells you that if you get no response then this is the reason. These days many aircraft panels are not even using compiled code but XML, and there is no way any code hooks can handle that. However, you might be luckier with the local variable facilities instead (L:Vars). Yuo can log them for the aircraft and see if any are usable for your needs, but it is still doubtful. Yes, it is, but it wouldn't create a folder in any case, even if it worked. It would create a macro file. I'm afraid that is a meaningless statement. Please always state version numbers. Folks have said they had the latest version and were found to be using months old versions -- they merely meant the last one they'd seen! Version numbers are easy to find. They are on screen, in the log, in the DLL file properties. Regards Pete

I've no idea. sorry. How are you setting the weather "at the aircraft"? You are aware, i assume, that FSX is dynamic? Any weather it sets is "transitioned" into place and is constantly changing even then. The weather at the aircraft will be influenced by at least three of the nearby weather stations -- have you seen what it is doing with those, on the weather map? And even if you put the rate of change slider to full left, it is not stopped. Only "global" weather mode is fully controllable, and you cannot set that in the sim, only via SimConnect programming. Please use the tools provided to check things. FSUIPC provides full weather logging facilities, and WeatherSet2 will read the weather at the aircraft or anywhere you ask. I really cannot undertake to check what you are doing. FSUIPC reports what it is told by SimConnect, no more, no less. You can see what that is using the tools provided. Pete

This is because it takes time for the A/P to be switched off. You'd still be far better off only doing the "AP on" action when the AP changes. Now it works, here's the event-driven version of the Lua plug-in: function autopilotonoff(offset, val) if val == 1 then ipc.writeUD(0x07C8, 1) ipc.writeUB(0x6DF1, 0) ipc.writeUB(0x6DF2, 0) end end event.offset(0x07BC, "UD", "autopilotonoff") That's it. There's no "while" loop nor delay needed. Just save it as ipcReady.lua and you are away. What happens is that FSUIPC reads the file and actions not the "function", but just the "event" command. This lodges a request for that function, here named "autopilotonoff" to be called whenever offset 07BC changes. Then that function does its job, after checking that the change has been to turn the A/P on. If it is turned off it does nothing. Regard sPete

This seems to mostly work, but needs checking in a real environment with an add-on aircraft. First implement the "VRI_SetBaro" example as in the VRi Lua plugins document. But in the FSUIPC.INI file change the line "Lua=VRI_SetBaro" to "Lua=VRi_SetBaroEtc". don't have any other filters than those shown in the example. Then put the VRi_SetBaroEtc.lua plug-in from the attached ZIP into the FS Modules folder. Run FS and seehow it goes. It won't be perfect, but it might help. You may need to adjust the delay -- the line if (ipc.elapsedtime() - timeinput) < 500 then operates the half second delay. For more increase the 500, for less decrease it. Regards Pete VRI_SetBaroEtc.zip

Er .. it would be me helping him, wouldn't it? I don't need any help as I don't actually use the VRi devices! ;-) I'm trying something now. After I wrote the last message I had some doubts, so I'm doing an experiment. Pete

Actually, after more experimentation, I see why. The selection changes to the last value sent from the PC, but then changes back to your current selection. It is quite quick (though I can see the user occasionally catching it so it stays updating the wrong value). The problem, more obvious with A/P implementations which are constantly manipulating things like V/S, is that the selection will not have time to revert to the user's choice before the next value is in. The ATR example in this thread is actually worse again because the implemented A/P seems to be sending V/S settings to FS even when there is no need, when there's no change occurring, as illustrated by the repeated settings of 3000 in the log. That's just poor implementation in the aircraft. Unfortunately there's no indication sent to the PC when the user selects a particular entry. If there were I could deal with it in a Lua plug-in -- by saving copies of any V/S or other values sent whilst the user is causing other values to be sent, and only sending the new VS (or whatever) when things have been quiet for a while (half second or so, maybe). Actually that could be done anyway, I suppose. It wouldn't be foolproof of course. A hesitation of half a second doesn't mean the next change won't occur immediately I try updating the VS (or whatever). Maybe I should offer Mauro a Lua plug-in with this attempted to see if it helps? Yes, i cannot disagree. It's a nice piece of kit. The really admirable thing about the M-Panel is how much functionality they've managed to package into such a small unit. Good for those with little space! ;-) Pete

So it's related to the number of requests reaching the M-Panel? Some sort of overrun causing corruption internally then. If it happened on just any old change in the aircraft then it should be noticeable more often, with default aircraft too. [LATER] No, it isn't related to the number of requests at all. I've just tried it with the default FSX 737. If I show the A/P settings on the M-Panel, with any of the 4 items selected, ready to be adjusted, then adjust one of the other values on screen, even a single change makes the M-Panel select that item, so that if you are operating the knob to adjust something when FS, for any reason, changes one of the others, you get in a mess. This is most certainly a deliberately designed action, not a bug, but it is an incorrect design decision on VRi's part. Certainly they did not make the same mistake on the MCP Combi, as you said and as I've just proved to myself. ;-) I'm afraid it does make the M-Panel much less worthy that I originally thought. Such a shame for what is otherwise a neat gizmo. Perhaps they should be persuaded to work out a way of updating firmware without "bricking" it. No, not Cosford, but I am going to the Battle of Britain Show as Duxford on the 4th September. There's a FlightSim show there -- Flight1's I think. I usually see the VRi folks at the Lelystad show in November, but I've decided to go only every other year now, as the last two years were much the same and I got rather bored being there the whole weekend! ;-) Best Regards Pete

How do you get so confused? If you count from 0 (as C/C++ does) then it is 0 and 1. If you count from 1 (as in Basic) then it is 1, 2. Either way it is the lowest two layers, the first two starting from the ground and ascending. Pete

Well 0 and 1 really, considering the arrays in the NWI areas are [0] to [15]. More, they are different because they are automatically populated for you. You don't have to tell FSUIPC to read the data from FS for you. They are the source for the lower (FS98) offset data. Pete

Any number of actions are executed for a button press. The only limit is on the overall size of the [buttons] section, which is certainly several hundreds (I don't recall without looking it up). If you think one of them is not doing its job it is probably because it is being overridden by some other action immediately afterwards. Since I've no idea what 6FD1 and 6FD2 are used for I can't really help directly, but you can help yourself. Just enable button logging, and also monitor 6FD1 and 6FD2 as "U8" types on the right-hand side of the Logging tab. Check the "normal log" option below, and you will get a log of both button operations and the changes in your 6FD1 and 6FD2 offsets. Sorry, what do you mean "not possible"? You can execute as many queries as you like. Lua is an extremely flexible programming language. First off, a sleep of only 50 means you are repeating everything 20 times a second. That is a waste of time. Please put it back to at least 250. Probably 500 would be better. When you write to 07BC or 07C8, it effectively schedules the request in FSUIPC to send the FS controls to turn on/off the Autopilot/Heading hold. The effect will NOT be immediate so you must give it time. It would be faster if you used the FS controls directly instead of writing to the offsets, but I keep suggesting that you use those to no avail. Second, if the second part of the code never executes it must be because 6DF1 is never equal to 1. That is what you have to investigate. Try the logging and monitoring as I suggested! One possibility I can see is this: This loop: if ipc.readUD(0x07BC) == 1 then ipc.writeUD(0x07C8, 1) ipc.writeUB(0x6DF1, 0) ipc.writeUB(0x6DF2, 0) end sets 6DF1 and 6DF2 to zero all the time that the A/P is signalled 'on'. Right? But this: 0=P0,2,Cx01006DF1,x01 1=P0,2,Cx010007BC,x00 first sets 6DF1 to 1 then tries to turn the A/P off. Because the Lua program is operating ALL THE TIME the A/P is on, 6DF1 will be set to zero again immediately (or at least within the nexct 50 or 250 mSecs). The A/P being switched off takes time and FSUIPC has to interpret the write to 07BC and THEN send the request to FS as a control. That goes through SimConnect on FSX or via the message queue on FS9. If your Lua loop only acted on a change in the A/P then this problem would not arise. Why are you omitting the other two controls for each button? Why have you reverted to code which executes continually whilst the A/P is on? You are ignoring everything we discussed to do this only when it changes. Why? If it isn't working now it won't be "solved" by using events. Using events is just a much tidier and more efficient way of doing things only when something changes. A change in an offset is detected for you by FSUIPC and that instigates some Lua code. What is and is not working? You don't actually say. Please try to use the Logging. You are making very heavy weather of something which appears on the surface to be such a simple thing. I get the feeling you aren't telling me everything, so I have to keep guessing. Are you sure you really want to continue for another n days? ;-) Pete

Good. Yes, that looks good. Regards Pete

Please show the BEGINNING of the Log file. That is where all the main information, including the derived paths, is logged. This merely shows that you have shared "C:\Users\Mike\Documents\Flight Simulator X Files" on the PC which is named "MES-ASUS-GM" as "Flight Simulator X". FSUIPC gets the share names from the Registry so that it can make valid UNC names (those accessible to all, including Networked PCs). No, it will only do that if it cannot find that path in your list of shares. If the UNC path is incorrect then it is likely to be a Registry corruption. Try unsharing the folder, or if it actually appears to be unshared already (in Explorer), try sharing it and give it a good name. I always use the name "FSPLANS" because a lot of applications seem to expect that name -- Project Magenta to name but a few . If that doesn't work you may need to repair your Registry. If a registry repair program doesn't fix it, it can be edited. I'd need to know what version of Windows you are using so I can help. Regards Pete

You don't "assign offsets" to a button. But you can have any number of lines detailing actions for the one button -- as in fact you already did, way back. Just remember that the actions are executed in line number order (i.e. the number before the "-" sign). Remember this, from your own message? This showed that you understood how to do multiple actions with one button press. However, you seem to have the order wrong here. Shouldn't it be: 0=P0,2,Cx010007BC,x00 P0 = Cpt. side Autopilot Master off 1=P0,2,Cx010007C8,x00 Autopilot heading lock off is required to switch off the autopilot light (my FCU is from CP Flight, with Wilco Airbus module) 2=P0,2,Cx01006DF1,x01 Offset for Cpt. priority + FO red arrow 3=P0,2,Cx01006DF2,x00 Offset for FO. priority off You want another set like that for the FO priority button, and you should be done. If you'd like to show me your working Lua code for the A/P switch going on, I'll show you how to midify it to use "events", which will make it much more efficient. Regards Pete

Sorry, what does "inserting AP" mean? No. the string is the name of the FS control, equating to control number 66036. You or something is constantly setting the V/S -- presumably the A/P is doing this dynamically as part of its vertical path control (for speed or altitude maintenance). However, even though it is stable as -3000 it seems to keep sending it to FS in any case. That is a bad part of the add-on aircraft design and is probably one of reason your problem is more obvious on that add-on aircraft. However, as shown below, it could happen with default aircraft too as there does indeed seem to be a bug in the M-Panel firmware. ... This is nearly 14 seconds later. Evidently the aircraft is now climbing instead of descending -- the V/S is being set to +2899 etc ... The aircraft is changing the V/s and the altitude target (99,900 is set so high as target so that the V/S is maintained until changed, rather than reducing 500 feet from a target altitude). Yes, it does. It shows quite clearly that the V/S, and once the Altitude, was changed and continues to be changed. The bug appears to be in the M-Panel firmware. It seems to automatically select the last value sent by the PC. It should not do that. Report it to VRi, get an update for the firmware (if they can do such things). [bTW I think Andy is not part of VRi, but an enthusuastic and helpful user who voluntarily maintains the Forum] Tomorrow, if I have time, i will see if I can reproduce it with a default aircraft. It should do the auto-selection if I use the V/S adjuster on screen and i should see the selection move away from what I wanted to adjust on the M-Panel. If it happens on mine it is a general firmware bug. If not it may depend on the version. Unless you can get the M-Panel fixed I'm afraid the only answer is to block the commands from the SerialFP2 driver to the M-Panel as already discussed. It is rather a serious deficiency in what is otherwise a nice little product. I might try it also on the MCP-Combo device, just to see if it suffers the same way. Regards Pete

It isn't, it is dead easy for a known place -- i.e. at the aircraft. That's the ONLY known place. For everywhere else you need to say WHERE it is you want that information for. Don't you see that? Isn't it blindingly obvious? How does the system (FSUIPC + FSX) "guess" where it is you want the weather for? Obviously you have to tell it!!! How do you get this application to get the weather at the place you want it? No. it sets the weather, not reads it. And it uses SimConnect directly, not via FSUIPC. Wow! This is the very first time you've actually said where you want the weather for -- NOT "the nearest weather station" as you proclaimed earlier, but "AHEAD" or "AROUND" your aircraft. Well, for AHEAD of your aircraft you'd need to compute the Latitude and Longitude of some point ahead, presumably on your course or track. Then ask for the weather there. But "AROUND" you? Where? All around? All points of the compass? For a decent radar you'd need to get it for at least 5 points ahead and to the forward left and right. That's 5 calculations of Lat/Lon and five requests for weather. There are good weather radar programs available -- SA_Wxr is one i use -- and gauges. All of them read the weather at a number of points, both near and distant, in an arc from the aircraft nose, where the radar is. Can't you see that this is not simply a single reading from some preset offset? Obviously the values have to be deliberately gathered via a series of requests. How else could it possibly be done? I understand full well that you seem to have an odd idea of what a single set of offset values can give you. There's no way FSUIPC or FS can read your mind and know where it is you want the weather for. I've told you time and time again that it cannoot be that simple, for reasons which should be blindingly obvious, but you even now still persist that it is I who is not understanding you? Phew! :-( Those lower offsets date from FS98, which supported only 3 wind layers and two cloud layers. The two which are provided for later versions of FS are the lowest two, because it is generally those which are required for ATIS reports and ground information. If you want all the layers at the aircraft you must use the NWI offsets C000-C3FF as I've previously advised you. Those are populated and updated constantly by FSUIPC without you making any requests, and can easily be used the way you first asked. Pete

Thanks for the offer, but there's no need for my products. I don't seem to have to advertise to have enough work to do! ;-) Regards Pete

Have you not yet heard of "Googling"? I just Googled "FSCommunicator" and the first choice on the resulting list said plus a lot more. Try the Search entry on your Internet browser. Regard Pete

Oh dear, you don't read much of what I write do you? :-( It is just not that simple. Can I repeat the extract I showed you again, from the document you claim to have read? Look, don't you see there are 5 steps. Not just a signature, but an ICAO id for the Wx Station. As it clearly says, a total of 28 bytes written. Then the program waits for the reply. it takes time for FSUIPC to send the request to FS, get the reply and populate the offsets. And that is assuming your access doesn't clash with anyone else's -- so you have to check for acceptance and be prepared to retry a few seconds later if not. See: Why do you want this data for a weather station which might be many miles away? What on Earth is the point? I did not say that. I said that the procedure, as documented, has to be programmed. Is SIOC a Weather Program? Is it written with this job in mind? I thought it was merely a hardware interfacing program, nothing to do with weather. For weather programs look at ActiveSky and FSMeteo, for example. They use this facility because they are programmed to. But a program designed to do something entirely different won't be programmed to do the same thing. Don't you see this? I am about to give up with you I'm afraid. You seem to only read a little of each of my replies, and at that rate it will take several more weeks. you do not seem to appreciate that handling data in computers needs programming. Folks write programs to achieve certain things. SIOC is not a weather program. :-( Pete

I've no knowledge at all about FSCommunicator. Everything to do with FSUIPC (and WideFS, which is what I assume you mean by 'FSWIDE') is contained in the FS Modules folder. FSUIPC's settings are all contained in the FSUIPC.INI file. You should save that. For FSUIPC4 it would have to be renamed FSUIPC4.INI but everything should be okay with a possible exception for some of the joystick axis assignments if you've made them in FSUIPC's "Axes" tab. FSUIPC3 and 4 use different Windows interfaces for joystick axes. If you've made any macros or Lua plug-ins (.mcro and .lua files) save those too. Your license registration details would be no good as FSUIPC4/WideFS7 are new products with new registrations needed. If you want to run FS9 on the new system too, you still need to re-register, but you do so with your existing registration details. You can either get those from your account at SimMarket, or save the FSUIPC.KEY file. It is a text file which you can read and copy/paste from when re-registering. There are no license keys associated with WideFS clients. If you made any fancy settings in any of your WideClient.INI files you might want to save those, but in general there is nothing needed. pmInstructor is another matter, but it isn't my product. Regards Pete

That means they share the same Windows procedure, so only processing WM_CLOSE in one place. Well, it will be the "main Window" which receives the same WM_CLOSE message. So, sorry, I don't know what it is doing differently. Maybe a question to the author might elicit a reason for this behaviour? If it closes normally it should surely save it's state? Regards Pete

Yes, and the document says the same thing. Locations like an ICAO ID for a Wx station, or a Lat/Lon, or "GLOB" for global default weather (used to populate Wx stations with no other weather). There's a sequenced procedure for specifying the place, waiting for the response, and checking that it is YOUR request answered and not someone else's. Exactly as documented! It sounds like you've STILL not read the section about the offsets you are interested in, even though i posted a copy in my last message! Why not? You still haven't said WHERE it is you want this weather data for. If not at a weather station or at a given position (Lat/Lon) at the aircraft, where on Erath can it be? Pete