pilotjohn

I decided to use the full range of the axes for both forward and reverse. Under normal flight conditions the axes act from idle to full forward thrust. However, when a button is pressed the throttle range becomes a reverse range acting from idle to full reverse, and it toggles back to forward when it's brought near idle again. You can find my script for this in the User Contribution sub-forum. As you're landing, you will bring your throttle to idle. You can then switch to reverse using a button (such as the detent below the idle gate on the Saitek) and then push the throttles full forward again which will provide you with reverse thrust until you slow down. Then as you bring the reverse back to idle again, it will automatically switch to forward thrust again. There also audio feedback so you know that you've switched to reverse or forward.

Attached is a quick script that automatically fills the tanks on flight start to some random percentage of total capacity (default is between 33%-66%) with some minor variation (default is +/-1%) between tanks. This allows for a more "real" preflight since you don't know what you'll be getting when the plane is handed to you. It also has a quick input interface for setting the fuel level to a specific % or changing it by a given %. Rename .txt to .lua and install as described in the instructions at the top of the file. FuelManager.txt

Attached is an update to the JS41 Saitek Multi-Panel Script. There might other fixes I haven't posted here yet, but most importantly it changes the AP button functionality to turn OFF the yaw damper if it's ON but AP is OFF. As it was, when the AP was toggled OFF the YD stayed ON (default JS41 behavior), and needed to be clicked OFF with the mouse at 200 feet AGL for landing (otherwise you'd have a nasty cross-wind touchdown). This was rather disorienting to say the least. Thus, the new order of functionality for the AP master switch is as follows: AP ON YD ON AP OFF YD ON AP OFF YD OFF ... So when passing 500 feet AGL, AP can come OFF with YD remaining ON, and then a second press at 200 feet AGL will turn the YD OFF. On a go-around a third press will bring both AP and YD ON. As before, change the extension to lua. JS41SaitekMP.txt

Here's a script that generates random weather conditions based on themes. Each weather theme has random parameters, and themes can be selected based on weight. The weather is "global" in that all stations are assigned the same weather, but not in true global mode so individual stations can be adjusted. Currently all weather parameters are generated from MSL (not from where the aircraft is sitting) which may change (clouds should probably from AGL, but not if you want to go from a high elevation airport to a low elevation airport and keep IFR ceilings, for example). Theme parameters may also be adjusted in the future. To make available within FSUIPC, place all files/directories in Modules. Features: - Themes with randomized parameters - Many pre-defined VFR, MVFR, IFR, LIFR themes - Randomly picked themes with configurable probabilities (weights) - Excluded themes (by weight) can still be selected through user input - Custom themes can be provided as METAR input - Temperature layers with different lapse rates - Surface temperatures adjusted for latitude and season - Graduated visibility layers - Multiple cloud layers with order restrictions - Precipitation type based on cloud and surface temperatures - Precipitation rate adjusted by cloud coverage - Icing based on cloud temperatures and adjusted by cloud coverage - Multiple wind layers with controllable shear - Surface wind based on prevailing direction by latitude - Winds aloft direction and strength based on latitude Themes: - VFR Easy - VFR Medium - VFR Hard - VFR Calm - VFR Windy - MVFR Visibility - MVFR Ceiling - MVFR Both - IFR Visibility - IFR Ceiling - IFR Both - LIFR Visibility - LIFR Ceiling - LIFR Both - Unpredictable RW.zip

Update to ignore IPC flag state and keep state internally so that it works regardless of FSUIPC version. ThrottleManager.txt

It did seem counter-intuitive to me at the time, but I didn't question the logic, I just went with how/what worked. And when that changed on the upgrade to 4.749d I thought I'd point it out. In any case, whatever changed doesn't matter to my script any more, as I changed it to ignore the actual flag state and keep state internally, as long as I get events on toggling. This way it works with either version of FSUIPC.

Clearly something changed between at least these two versions. I can live with it, but it'll likely break a lot of people's scripts like it did mine.

The part meaning 0 is true. Clearing a flag would cause it test 0, and should be false (a cleared flag is false, it's not set, but might read 0 which according to that convention is "true"). So it depends on whether testflag() was returning a boolean primitive or a number. If a number - 0 or the set bit - it was correct before since "if testflag()" would have evaluated to true when cleared and false otherwise. If that changed to a boolean primitive it is now correct. I meant working since I've hacked together my ThrottleManager a few months and versions ago which worked as I described (that clearflag resuted in testflag equating to true).

I concur with this, but I didn't report it because I thought you were following this Lua expression condition: http://lua-users.org/wiki/ExpressionsTutorial Note on test expressions and nil An important point to note is that the value 0 is not a false test condition in Lua. In some languages, for example C, a test of: if (0) printf("true"); else printf("false"); Also, this has been working as originally described since at least 4.739 so I don't know what else it will break and for whom.

It does seem to act the opposite of 4.745 and before. In my ThrottleManager I use flags to toggle states (forward or reverse). In 4.745 if I do an ipc.clearflag and then test with ips.testflag in the generated event, it returns a true boolean. In 4.749d the same condition returns a false boolean.

4.745. I'm still investigating.

Did the ipc.testflag functionality change in this version? I'm relying on it for my ThrottleManager, and it seems to be returning the opposite of what it used to.

Just so I understanding... You preselect HDG mode, and select a heading of XXX using the Saitek panel (with XXX displayed on both the Saitek and EHSI). Then, when you engage the A/P the heading selection to changes to YYY (the current actual heading)?

Are you using SPAD? Do you have your modes preselected before engaging AP? What happens if you select HDG mode? I'll try to duplicate, but the only time I've seen this is when A/P is turned on without any mode being selected, or in GA/GA mode. In that case it's an unfortunate rounding issue.

So there's no indication from FSX whether the data you're monitoring is "real" or a "simulation"? That's unfortunate...

The docs state that the replay offsets (0x0628, 0x062C) are not supported. Is this because it's not possible, or not yet implemented? I'm working on a flight judging script that determines when certain phases of flights start/stop and the replay triggers certain events. Is there a way to check whether replay is on?

What's not working for you? If the altitude preselector works, everything else should be working. Some of the lights will not synchronize but there's no way to fix that. Are using SPAD? I've only tested it with SPAD.

That gap is not 0 or unpredictable, it either continues the surface layer (if the the next layer has an instantaneous shear) or that's where the shear graduation is performed. As it is, it's simply ignored and graduation proceeds to the next layer (in FSX GUI you cannot actually place a layer there.) Since you have a "Spare" field in the NewWind struct, I thought it would be the easiest solution to use part of it to signal that UpperAlt should be passed on as is without any manipulation. This would not touch anything else, and would not impact existing functionality. There's no other way for me to achieve the desired affect without writing my own METAR translation code which would likely be a waste of effort, and likely error prone since you've done the bulk of the lifting. I'd like to make sure this generator performs correctly but I can't think of any way to trick your calculations to do what I want. If I could I would. So I'm hoping you're willing to provide the next best easiest thing which is a simple flag.

So the reason for the surface DEPTH is for it to be in effect from AGL (to DEPTH) regardless of the other MSL layers. So for example, If I want surface winds to be 10KT with a depth 1000 feet, but I have a 60KT layer at 3000 feet, if I take off from a 6000 foot elevation airport, the surface winds will still be 10 KTS to 7000 feet (unfortunately they will instantaneously shear if the layer base is below the surface layer, but that's an FSX bug). This is great, but putting the next layer immediately on top of the surface layer may not allow for a good gradient under normal circumstances. It works because it looks like the next layer is ignored, but that's not what I really want. As an example, I'm generating 10 equal layers to 30000 feet, but what I'd like is for the surface layer to be half the normal layer depth. So I'd like the surface to be 1500, and the next layer base to be at 3000. With the current calculations I don't have control over this since you automatically place the next layer on top of the surface layer. Would it be possible for you to add a bit-flag in the NewWind structure (in Spare perhaps) that would treat UpperAlt without manipulation if the bit is set? That would seem like a simple solution without me having to write NWI struct to METAR translation, thus duplicating work and spending a lot of effort on it. BTW, this is all for a random weather generator, that should be done soon (I'll post it). Here are it's features: - Themes with randomized parameters - Many pre-defined VFR, MVFR, IFR, LIFR themes - Randomly picked themes with configurable probabilities (weights) - Excluded themes (by weight) can still be selected through user input - Custom themes can be provided as METAR input - Temperature layers with different lapse rates - Surface temperatures adjusted for latitude and season - Graduated visibility layers - Multiple cloud layers with order restrictions and MSL/AGL options - Precipitation type based on cloud and surface temperatures - Precipitation rate adjusted by cloud coverage - Icing based on cloud temperatures and adjusted by cloud coverage - Multiple wind layers with controllable shear - Surface wind based on prevailing direction by latitude - Winds aloft direction and strength based on latitude

It didn't work. It takes the parameter, and reads back correct for GLOB, but all the stations read back 180 of the direction given (if the variance is included) and the speeds are not set. So there's something definitely not right about it. Along the lines of your notes in your code, do you have anything about cloud depth/height? I noticed you're setting it in the second field after &TT (CU, ST etc.) but it seems to be completely ignored, and even the documentation says it's unused. Reads of course, include a value.

The two letters at the end of a wind group provide turbulence and shear, so instead of 27060KT&A3000NG I put NI (no turbulence, instantaneous shear). I believe some of this is actually missing in your struct-to-METAR code as occasionally I've seen things like A3000G or A3000N etc. I believe two letters might be required. Did you also notice that variance information was being sent after each wind group in that whacky KTTN METAR from the theme? You only send one, correct, even if I include variance information in other layers? Is this because it doesn't work?

All I did was start FSX, load my default flight with KTTN set, and select the weather theme. As the flight got progressively along, the layers got more and more confusing. That's the one I grabbed after about 5-10 minutes of slewing and checking the GUI, when I finally launched WeatherSet2. Another 5-10 minutes later it was looking nastier (dynamics?). Initially they looked a little cleaner but I didn't have KTTN which is why I asked for it specifically. I included the image to make sure we're talking about the same thing when talking about a station (something that has an ATIS and shows in the weather GUI). Well, I did some additional testing. I set the shear level to instantenous. This stopped interpolating and only provided the required wind when the altitude provided in &A is passed. This would indicate a "base" as you suggested. I'm trying to figure out the need for a surface depth then. It seems using a simple &D1 (&D0 doesn't work) for the surface layer is probably the correct approach for me as then all wind is interpolated to whatever wind aloft is at the airport elevation without having a "fixed" layer. Thanks for sticking with my investigation.

Odd... I'm getting different results. Using FSX Acceleration KTTN is definitely a station and has an ATIS (screenshot attached). 1. I put the plane at KTTN. 2. I loaded Developing Storms theme 3. I launched WeatherSet2 and looked the request return for KTTN The METAR from KTTN is: 295919 Weather Received (type 3 request, AtStation): "KTTN&A64 151850Z 22805K T&D1057LM 227V229 22805KT&A1000LM 227V229 23206KT&A1000LG 231V234 22805KT&A1064L M 227V229 23206KT&A1121LG 231V233 23306KT&A1124LG 231V234 23306KT&A1128LG 231V23 4 23407KT&A1188LG 233V235 23407KT&A1192LG 233V235 25015G26KT&A2000LG 249V250 250 15G26KT&A2000LG 249V250 24416G28KT&A2064LG 244V245 24416G28KT&A2128LG 244V245 32 KM&B-257&D30736 2CU048&CU004FMVN000N 8CI301&CI000FNVN000L 2CI390&CI000FMVN000N 2 4/24 24/24&A0 23/23&A1300 23/23&A1300 23/23&A1364 23/23&A1428 23/23&A1492 23/23& A1556 22/22&A1620 22/22&A1684 22/22&A1748 21/21&A1812 21/21&A1876 Q0989 @@@ 35 2 3 228 5 | 35 23 232 6 | 37 23 228 5 | 39 23 232 6 | 39 23 233 6 | 39 23 233 6 | 41 23 234 7 | 41 23 234 7 | 68 21 250 15 | 68 21 250 15 | 70 21 244 16 | 72 21 2 44 16 | " Let's assume they're layer tops as depicted in the FSX GUI. Then... At 4000 feet there's a 7KT layer, and at 6600 feet, a 15KT layer, with the highest layer of 16KT at about 6800 feet. 4. I slewed to 5500 feet, and there's 11KT wind there (about right for interpolation between 4000/7 and 6600/15) 5. I slewed to 7500 feet, and there's 15KT wind there (about right for above any interpolation layer) These wind speeds are too close together for clear testing (screenshots attached) which is why I tested with pretty obvious layers and speeds. It's odd that winds aloft would behave differently than all the other weather parameters (visibility etc.) which use upper altitude to delineate a layer. In my case and testing winds aloft behave similar to visibility layers.

No, I don't think it's an FSX bug. If you write X and read back and get X than FSX is not altering anything, thus there's no bug (only if it behaves differently than written, but it doesn't, you write X as the layer top, you read back X, and FSX is using that as the layer top). It's just that the &A should be the layer top, and that's how FSX interprets it (per "option B" in the documentation). If you were writing X and getting X+Y or getting X but FSX behaving like X+Y than I would concur that it's an FSX bug and you're "fixing" it. But that's not the case here. Checked at KTTN (same METAR but KTTN instead of GLOB). Same result (writing, reading, behavior, GUI all agree as layer top). See log below: 176874 NW_CLEAR weather command received 176874 NWI weather clear actioned 176874 External weather discarded 176936 Weather Mode now = Theme 176936 Weather Mode now = Custom 177872 Setting Metar: "KTTN 000000Z 36010KT&D1000NG 27060KT&A3000NG 15/10&A0" 178059 Weather Read request (At Aircrft) to area 4: Lat=40.27, Lon=-74.81, Alt=66.8, Req=2 178059 Weather Received (type 4 request, Interpolated): "????&A0 151734Z 36010KT&D1000NG 100KM&B-1500&D2021 CLR 14/09 Q1013 " 178059 WX Received in 0 mSecs, WX request type 4, Lat=40.2730, Lon=-74.8084,Alt=66.8m 181226 Weather Read request (Nr Station) to area 5: Lat=40.27, Lon=-74.81, Alt=0.0, Req=1 181226 Weather Received (type 5 request, Nearest): "KTTN&A64 000000Z 36010KT&D1000NG 27060KT&A3000NG 100KM&B-1564&D2021 CLR 15/10 Q1013 @@@ 101 15 270 60 | " Aside from the "feature" in global mode of ignoring winds aloft, in custom mode all signs point to the fact that &A should be the layer top, not base: in writing and reading the METAR, in behavior, and in FSX weather GUI. How about "NWI_SETCORRECTLY" instead? :)

Pete, In this non-global custom mode, my original "bug" report stands. The winds aloft altitude after the &A should be the upper altitude, not the upper altitude less surface wind depth. I just tested this with the two following METARs and the described results which show that &A should have the layer top, not base. GLOB 000000Z 36010KT&D1000NG 27060KT&A3000NG 15/10&A0 At the surface the wind was shown as 10 KTS. Slewed to 5000 feet the wind read-out was 24 KTS (which is about correct for interpolation using 10000-3300=6700, 60-10=50, 5000-3300=1700, 1700/6700*50=13, 10+13=23). GLOB 000000Z 36010KT&D1000NG 27060KT&A1100NG 15/10&A0 At the surface the wind was shown as 10 KTS. Slewed to 5000 feet the wind read-out was 60 KTS (no interpolation since above the layer top), and at 3500 feet the wind read-out was 37 KTS (which again is correct for interpolation, 3700-3300=400, 60-10=50, 3500-3300=200, 200/400*50=25, 10+25=35). Can you fix this please? Regards, John