pilotjohn

Is the cloud SimConnect_WeatherRequestCloudState data available from an offset? If not, could it be added, either as call for some static alt/lat/lon around the aircraft, or a similar mechanism to the current weather system, where the request could be written in one area, and read from another? Maybe even reuse the existing weather area? Is 0xE85-0xE88 retrieved through this mechanism or METAR?

By cloud distributions do you mean what's given in the SimConnect METARs? Is the precipitation types/rate (0x04CB) give at aircraft, or is that also based on your METAR translations? How about the cloud/wind turbulence at aircraft?

Would you know how the simulated radar echoes are determined by RXP or CaptainSim radar? Would any of the current offsets provide anything comparable, such as precipitation intensity at aircraft, including cloud type? I see the cloud type and coverage offsets (0x0E84...), but I'm guessing that doesn't exactly tell me whether I'm IN cloud. I also see 0x04CB but that doesn't tell me whether it's at the aircraft. I'm trying to create some incentive for avoiding weather (since, as-is, it makes no difference whether you pummel through heavy precipitation in a CB cloud or not) by increasing the failure rate of systems through my random failure script if you're in certain weather conditions.

I'm working on a Flight Critic script which does this already, and will also "grade" your takeoff/approach/landing. It's not quite ready yet, but if you want to try it out just so you have the distances, PM me and I'll send it to you. You'll find that determining the takeoff/landing points get a little complicated to calculate if you bounce and or are taking off on rough strips (grass/gravel off-airport etc.) If you do try I would also appreciate if you would send me whatever flight logs it creates so I can collect flight analysis data for figuring out a good mechanism for grading.

You can probably accomplish what you want (or close to it) with a Lua script.

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.