Pete Dowson

Well, if you think it is worth it. Best review the User Guide, make sure you think it is worth the cost for you first. If you do, get back and we'll sort out the plug-in fix for you. Regards Pete

Ah, real aircraft reversers for jets operate completely differently. In FS you are just telling it to reverse the thrust, and that internally is a negative thrust value which is variable. In jets it's a mechanical process and in a 737 the reversers really only have two positions -- one to operate the mechanics and lower the deflectors, a position you hold for a while before you can pull back further to increase the engine thrust against the deflectors. Regards Pete

That's a shame -- they must be wired together! Yes, there is, but there's no point. you might as well assign to THROTTLE_DECR instead, which operates all reversers. That's what the F2 key does in FS. Well if you've only got one input indication they cannot be independent, can they? You'd need to sort your hardware out first. Please go back and read what I said before. How is FS to know you have pushed the reversers back to off? If the button is held with them pulled to you and released with them pushed away, just program the button release as I instructed. Otherwise there is no indication for the Sim to go by other than a throttle change, is there? Think about it, and please, please, do read what I write. I did explain all that. Regards Pete

In that case, if the button stays on when the reverser is activated, just assign it to THROTTLE1_DECR or THROTTLE2_DECR, with it set to repeat whilst held. Assign the button release to THROTTLE1_SET or THROTTLE2_SET with a parameter of 0, to go to idle when you release the reversers. If it doesn't stay on, but only comes on momentarily, you'll need to assign it to THROTTLE1_SET or THROTTLE2_SET with -4096, or maybe -16384, as the parameter. With the latter operation, or if it doesn't stay on without pressure, you would need to push the reversers back out of the way and advance the throttles a little to come back out of reverse (instead of assigning button release). Regards Pete

As Alaxus asks, how you program them depends on how they are working -- axes or buttons/switches? No need -- for that you'd need to write a program. And why bother if they are detectable controls? FSUIPC supports reverser axes. For button/switches you just use the THROTTLE DECRement controls. 207C and 217C are read-only. All direct throttle control via offsets is via the normal throttle control values. But it gets complicated using those when using Autopilot, especially with motorised quadrants. It is usually easier to use the correct controls instead. Your first job is to work out what your reversers are doing, as we first asked. Pete

It is using the FS autopilot, then, so it shouldn't even need to disconnect the controls as FS does that automatically. Anyway, it makes it easier to add a plug-in to do the reconnection automatically. It can simply test for the A/P going off. Oh dear. If you don't have an FSUIPC registration then you can't do key/button assignments, nor will plug-ins work. These are parts of the wide number of FSUIPC features you get after purchase. I'm sorry, but I can't offer such support for an unpurchased FSUIPC. It rather defeats the object of such provisions. Regards Pete

That's a pretty bad problem really -- I assume your controls are out of warranty, otherwise it would be best to get them fixed or replaced? But first check that it isn't a USB power or cable problem. make sure they are connected directly into a main USB port on the PC, not via a hub. If they are already, try another port, preferably one without another device on the other one of the pair. (USB ports are usually paired and share power to some extent). Not sure that'll help a lot, but let's see: You left your spoiler axis set at: 86721 *** AXIS: Cntrl= 66382 (0x0001034e), Param= -15592 (0xffffc318) AXIS_SPOILER_SET After using the throttle for a while you got this: 91354 *** AXIS: Cntrl= 66382 (0x0001034e), Param= -10501 (0xffffd6fb) AXIS_SPOILER_SET This was between these two Throttle axis values: 91354 *** AXIS: Cntrl= 65765 (0x000100e5), Param= -12412 (0xffffcf84) AXIS_THROTTLE_SET 91401 *** AXIS: Cntrl= 65765 (0x000100e5), Param= -9929 (0xffffd937) AXIS_THROTTLE_SET So, interestingly, it looks like a crossover value, doesn't it? It falls between the two throttle values. Hmmm. But then it immediately (in the same millisecond) reverted to a really extreme minimum value: 91401 *** AXIS: Cntrl= 66382 (0x0001034e), Param= -16384 (0xffffc000) AXIS_SPOILER_SET which is odd in itself. Another change came later, when it looks like you reduced the throttle to a complete minimum: 94302 *** AXIS: Cntrl= 65765 (0x000100e5), Param= -16384 (0xffffc000) AXIS_THROTTLE_SET 94302 *** AXIS: Cntrl= 66382 (0x0001034e), Param= -14956 (0xffffc594) AXIS_SPOILER_SET 94333 *** AXIS: Cntrl= 66382 (0x0001034e), Param= -16384 (0xffffc000) AXIS_SPOILER_SET Again, an odd, but still low, value almost immediately overwritten by a full minimum. None of this, so far, should really affect anything adversley. If you've calibrated the spoilers properly, all the values so far should have been well into the "spoilers off" or "down" zone. The possible killer comes here: 95784 *** AXIS: Cntrl= 65765 (0x000100e5), Param= -14398 (0xffffc7c2) AXIS_THROTTLE_SET 95784 *** AXIS: Cntrl= 66382 (0x0001034e), Param= 16384 (0x00004000) AXIS_SPOILER_SET 95815 *** AXIS: Cntrl= 65765 (0x000100e5), Param= -15391 (0xffffc3e1) AXIS_THROTTLE_SET 95815 *** AXIS: Cntrl= 66382 (0x0001034e), Param= -16384 (0xffffc000) AXIS_SPOILER_SET where the spoiler is whacked up to maximum (16384 -- that's actually above the normal max of 176383), but then 31 mSecs later, back down ot a real minimum. There are a couple of further incidents in the log extract, one of each of those types. All I can advise is ( a ) make sure you calibrate with generous OFF and ARM zones, and also make sure the maximum has some axis space beyond it. ( b ) try the Filter option on the Spoiler axis which should, hopefully, eliminate the really drastic jumps (though I'm not totally sure it can cover so much of a jump. If nothing else works you could try using the zone assignments (the right-hand part of the axis assignments dialogue in FSUIPC options) to assign spoiler actions which avoid the problem areas which seem to occur (mainly the whacking up to 16384), or, more complexly, use a Lua plug-in to receive the spoiler values and work out some numerical way of defeating the unwanted changes. [LATER] There is a facility in FSUIPC to eliminate extreme spikes on axes (those going to or beyond the extreme, like your +16384). At present it only works with aileron, elevator and rudder, because at the time it was added only these were affected (it was actually a software fault in an aircraft add-on as far as I recall). I could probably extend it to work for the spoiler axis too if my other suggestions don't help. But please try those, as far as you can first, then get back to me. Please tell me the version number of the FSUIPC you are using, too. Regards Pete

It includes facilities to assign and calibrate controls separately for each aircraft, or, better, named "profiles", with those settings automatically reloading when you load the relevant aircraft. Profiles are flexible in that once you've created one you can assign any suitable aircraft to it. So you only need as many profiles as you want different settings, not for every variation of every aircraft. This applies not only to control settings, but also buttons and keypresses, as needed. As to whether it is "easy to use", that's really not for me to say. I think it is, but then I wrote it. I did intend it to be easy, but opinions will vary through the user community. I suggest you install it anyway, which will also install the documentation which you can then peruse to see what you think. Bear in mind also that you can always ask questions here. Regards Pete

Sounds like it uses FSUIPC to disconnect the controls, but doesn't tell it to reconnect them afterwards. FSUIPC times out the disconnection when it isn't refreshed for about 12 seconds (if it's going up to 30 seconds your system is rather overloaded). You can fix this either by programming a key or button to reconnect controls, or by using a Lua plug-in which does it automatically when it sees the autopilot disconnect. I can probably make such a plug-in for you, but I'd need to know how to detect the A/P going off. Can you tell me how you are programming the A/P disconnect or FS off actions? I assume they are not the default FS actions / controls? Maybe you can enable FSUIPC event logging and do such an action so we can see if it uses anything in FS which FSUIPC detects. To program a button or switch to do the job just assign it to "Offset byte set" then set the offset to x310A and the parameter to 0. Try that first. If your A/P disconnect is a toggle you could add it to the actions carried out when you toggled it off. Or, actually, you could add it anyway as it wouldn't matter doing that when turning the A/P on, because the aircraft code would be setting it as it needs afterwards in any case. Regards Pete

It's okay now. I've moved it already. Can't you tell? Look at the very top of the page where it says Regards Pete

That does sound vaguely familiar. Can't be set or read. Most annoying omission in the whole weather system for FSX. The height's are decided by some internal algorithm depending on base altitude and cloud type. Someone did work it all out once but I've not been able to find those details for years. Yes, it's ignored on writes, and I think unreliable on reads. I think I currently work out thickness based on cloud type. If you find the read-back thickness is accurate now I can decode it, with an SP2 proviso. Regards Pete

Sorry, no idea. But isn't the Level D well catered for by virtue of a good SDK and software support from Nico Kaan? See http://www.lekseecon.nl/lekseecon.html. I would strongly advise doing things properly wherever possible, as it is here, and certainly rather than resorting to keystrokes which are always a pain. I wouldn't be surprised if the keystroke problem isn't simply due to message queues building up in FS -- airliners such as this sometimes use hundreds of messages per second all on their own! (You can probably see some by enabling FSUIPC's event logging). Regards Pete

Since I have no idea what your problems are, I cannot possibly answer that. But I can say that if you do have problems with 4.745 or later which weren't present in 4.2 (which is four years out of date and many many versions ago), then they need to be made known so i can fix them! Going backwards is never the right answer. Who are these "everyone" who are telling you all this stuff? Who says you should use 4.2? That's insane advice! Regards Pete

Oh, yes. Of course, corresponding to the shear field in the NewWind structure. Hmm. I've never seen that -- in fact the code contains this: n += sprintf_s(&szMetarToWrite[n], MAX_METAR_LENGTH - n, "%03d%02d%sKT%s%c%c ", dir, p->Wind[i].Speed, szGust, szAlt, chTurbulence[t], chShear[s]);[/CODE] where chShear is "GMSI", and the s value is constrained to be in the range 0-3 inclusive. Can you show me any examples? Are you sure you aren't mixing the METARs being read with the ones being written? Well, I think because it didn't work -- this is according to comments in my code, so I obviously did try it. However, we are talking about 5 years ago, and I cannot recall now whether I only tried with the RTM version or SP1 or SP2. I think SP2 because a lot of things got fixed then, but maybe, even if it worked by then, maybe I never changed it because it meant having even more messy code testing the version in use. If you'd like to try it via the string mechanism and let me know, it would be easy enough to fix. I do have quite a lot of SP1 and SP2 only checks in these days (as well as ESP and Prepar3D versions 1, 1.1 and 1.2 -- so it's messy anyway! Regards Pete

Where do you do that? (Forgive me, it's actually several years since I was involved in all this weather stuff). Yes, I was always puzzled by that. Interesting that &D0 doesn't work -- it can actually be reported back in a METAR from SimConnect. But then the read-back format and write formats are different in any case, with the documentation a bit of a mish-mash of both. Regards Pete

Looks right to me using my interpretation. these are the encoded winds in the area of your two "spot tests": 23407KT&A1192LG 233V235 5500ft = 1676 m, layer base 3900 ft = wind 233-235 at 07 25015G26KT&A2000LG 249V250 layer top is this base = 6560 feet 25015G26KT&A2000LG 249V250 two identical entries? 24416G28KT&A2064LG 244V245 24416G28KT&A2128LG 244V245 7500ft = 2286 m, 244-245 at 16-28 Correct within normal variation, assuming the A values are bases. You should take note of wind directions too, though -- the wind speeds will be varying a lot more than the direction, even at one altitude.. That METAR you've got is like those you get when something has been setting weather via SimConnect. None of the normal weather downloads or themes ever has that many layers, and certainly not such close and even identical layers. But that certainly happens when trying to set layers -- one of the main bugs in FSX weather. If allowed to write FS weather, FSUIPC tries to rationalise and remove close and duplicate layers, because they can build up so that the METAR string exceeds its FSX limit of 2048 characters and FSX crashes. Regards Pete PS why all those pix? I never doubted you had such a weather station, I just don't know why I haven;t.

Actually, nor do I. I think it works as it is. I'm simply not getting the same results as you report. I'm not setting weather, only reading it, but I'm judging by the METARs being read and the observations at the aircraft. Try, for example, the "developing storms" theme. Log the weather to find the reported Metar string at your WX station. Make a note of it then stop the weather logging as it will go on and on. In FSUIPC's logging, monitor these offsets: 0E90 U16 0E92 UA16 6020 FLT64 Check "FS Window" below. Now slew up from ground through all the layers (there'll only be about three). Compare the winds at the aircraft (0E90/0E92) at the altitude (you have it now in metres in the message window and feet in the Shift-Z display from slew mode. See how the winds change. Here they change as I would expect with A altitudes treated as bases, most certainly NOT with those treated as tops -- that would be way out. Only D (for "Depth" I think) is a "tops" measure, and that's from the ground altitude. Best if you do all this testing at a sea level airport in case your discrepancy is thinking AGL as opposed to AMSL -- though I don't think that can be it, as KTTN is only about 200 feet in any case. (Incidentally, KTTN doesn't appear to be a WX station on my system. It gives an error return from SimConnect if I try to read the weather at that station. Odd?). Regards Pete

I don't know if I can, if it's an FSX bug. The point is, the weather actually being set IS being read back with the same altitudes in the METAR strings. Correct? If I manipulate the input, contrary to the SDK documentation, and it reads back differently to what is written, I'm going to get much more flak for it being wrong than keeping it how it is and has been for 5 years. It will have to wait until i have time to do a full investigation. If it is really wrong the way it is I might need to just document it, or add another, alternative, facility to "NW_SET" like "NW_SETDIFFERENTLY". Meanwhile, can you just do a test at a weather station, not GLOB. please? Position yourself at the actual station, so there is no or little interpolation. Possibly this bug in FSX only affects the GLOB settings, not all of them. If that is the case I wouldn't really have such a worry "fixing" it ("fiddling" it is probably a more apt description). Regards Pete

That actually may be so -- I would hazard a guess that because Global mode was intended for direct easy control of the weather AT the aircraft (for training applications really), it was not necessary to implement layers. A quick log with ASE in DWC mode would show. All you need to do, really, is change the wind according to the aircraft's altitude, probably as ASE does. As I just said, it does that automatically when you try to set a station. That's because the only sure way I have to clear all weather is to tell FSX to set the "clear weather" theme. Regards Pete

But it must work. Programs, like ASE, use it! You ARE using a fully updated version of FSX aren't you? It wasn't in the original release. I think it was added in SP2, though it might have been SP1. Sorry, I just don't have time to do an investigation for you at present. I suggest getting ASE working in DWC mode and seeing what that does by examining the SimConnect logs. I've no way of doing that any better than you can, i.e. by reading the WXStationList.bin file and using the Lat/Lons there to determine their distance. You'll find that file in the same folder as your FSX.CFG I don't really think such an action falls within the FSUIPC remit. No, I won't be doing that, sorry. And in any case it would only work in places where there are no already existing weather stations, like in the Oceans. Otherwise the weather at the existing ones would interfere and cause all sorts of weird problems because of FSX's interpolation errors. Only if the weather is definitely clear to begin with. Then, gradually, each weather station's weather would change, differently. That occurs even with the dynamics slider at minimum, simply because the weather is moving, it is not static (unless there are no clouds and no wind -- but i don't think it can even stay that way for all that long). No, theme sets weather from a theme definition. User-defined or "custom". FSUIPC automatically sets Custom mode when you try to set a WX station's weather. Regards Pete

I just realised, you are talking about the "clear" button on the assignment side (left-hand side)? That's there merely to clear the entries on that page so you can start afresh. It doesn't change anything else. It is not and never has been a "delete". To delete a keystroke assignment, find it on the right-hand side (scroll through, back and forth) and use the "delete this entry" button. And don't forget to use 'OK' to exit. ESCape or cancel will restore everything to the way it was before you entered the options. This all certainly works fine, and it always has. Regards Pete

Hmm. It sounds as if the key was programmed to be both aircraft-specific and generic, so you were only clearing one of those. Is that possible? Can you clarify, please, as to how the key(s) were assigned? I'll certainly check here though. Please, do not simply say "latest version". What version is the 'latest' in your view? Was it 4.70, or something later, up to 4.747? I always, ALWAYS, need the version number, please. That is what it is for. Regards Pete

Weird, as all you are doing is bypassing the FSUIPC encoding of binary tabulated data to METAR string, so it should be no different. Well it works here with WeatherSet2, and Active Sky 6.5 also uses it and works fine in FSX. Also you can actually set ASE into FS9 mode so it uses FSUIPC and the NWI, and it works too that way. Global weather mode must work, as it is used by ASE in DWC mode. Maybe it just isn't using layers, only controling the weather at the aircraft, but I wouldn't hasve thought so. When I get time I'll do some SimConnect logging with ASE and see. Regards Pete

I thought that one of the big "fixes" in Prepar3D over FSX and ESP was the handling of multiple displays, and that it did all this for you. The Lua ext library, added in the most recent update (4.747) can position and size UNDOCKED panel windows on specific monitors. So you could do it by saving flights with the panel windows undocked (they come back that way too), and having Lua scripts running via aircraft- or profile-specific [Auto] sections which then move the undocked windows around (identified by title). You need also to download the Lua library package (again), for the updated documentation. I've not found a way (yet) of operating the 'dock' and 'undock' options on panels by program, but I am working on it. I think it should work via a WM_COMMAND message, as that's normally how pop-up menus operate, so I'm experimenting down that route. [LATER] Your inquiry spurred me on. I've found out how to Undock a specific docked but visible panel window, as long as you know its name (title). So I'll be adding an ipc.undock function in the next update. (No "dock" or "re-dock" though -- can't find how to do thast. But I doubt that's so important). Regards Pete

No. Use 4.745 or later. The earliest supported FSUIPC4 is 4.70. If there's some problem it needs fixing, not retreating from. Regards Pete