ecarden

Thanks for the explanation. Sorry to cause you a lot of work. Take it easy, Eric

That's certainly a reasonable action. By the way, I checked out offset C0FC, also (like 0EEE and 0F70) described as the current surface layer altitude in meters MSL. C0FC is indeed as described in the documentation, so I'm correcting my program by simply using this offset instead of 0EEE. Thanks, Eric

Hi Pete, You wrote... No, I'm not sure. The nearest airfield is a couple of miles away, and its elevation is probably around 600'. I checked out a different nearby airport that's on a plateau at 1000' MSL. Directly over that airport, 0EEE and 0F70 still showed 600'. I slewed upward and found the edge of the surface wind layer at 1600' MSL. Since my surface wind layer altitude (as defined in FS' weather settings page) is 1000', it still appears that 0EEE and 0F70 are AGL and that the surface layer altitude in FS' weather settings page is an altitude above some "base" elevation, not AMSL, not AGL, and apparently not necessarily above the nearest airport. Do all airports have weather stations, or might I have tested with one that doesn't? You also wrote (in response to my observation that [surface wind layer altitude (MSL)] = 0B4C + 0EEE)... How did I prove that? I sure didn't mean to. In my last post I observed that... For example, while over a point with an elevation (0B4C) of 1500' MSL, 0EEE was 100', and I experienced the edge of the layer at 1600' MSL. While over a point with an elevation (0B4C) of 700' MSL, 0EEE was 900', and I experienced the edge of the layer at 1600' MSL. In either case (neither of which was over a point with an elevation that happened to be at the 600' "base" elevation), the formula I proposed holds true. You also wrote... I hadn't studied this yet, but I did a little testing this morning since you asked. To clarify, the only such "bulging" I've experienced has been as the "base" elevation (however we end up defining this) changed, NOT as the ground elevation (0B4C) changed. In my test area (where I find the edge of the surface layer around 1600' MSL), I added a second wind layer at 1500'. (My surface layer is set in FS' weather settings page to 1000'.) I found that the second layer, which was overlapped by 100', didn't exist. I added a third layer at 2000', and the results were peculiar. The results were as expected at or above 2000', but they were odd between 1600' and 2000'. (I used "gradual" transitions for all layers, by the way.) I set different directions for all three layers, so I could distinguish one layer from another easily. As I ascended from 1600' to 2000', the winds transitioned as if the second layer DID exist. Just above 1600', the winds switched to somewhere between the directions of layers 2 and 3. The direction gradually approached that of layer 3 as I climbed. In a nutshell, while the results are a little odd when the surface layer overlaps another layer, I believe all the upper layers are purely MSL. Eric

Hi Pete, I guess I muddied the water by using my made-up term "base elevation". I haven't seen this concept documented elsewhere, thus the made-up term. It seems to me that FS somehow stores, for a small area, the minimum, or "base", elevation in the area. For example, my local flying area is basically a flat valley at 700' MSL with mountains at 1500' MSL. The valley isn't perfectly flat, though, with some points as low as 600' MSL and others as high as 800' MSL. I think FS stores a "base" elevation in this area as, for example, 600' MSL. With a surface wind layer altitude set to 1000', this will result in a surface wind layer of 1600' MSL. Whether I'm over a mountain, a low point in the valley, or a high point in the valley, the surface wind layer altitude stays at 1600' MSL. As I cover some ground, however, I think FS adjusts the "base" elevation to reflect the minimum elevation in some local area. The local terrain drops as I fly south, so as I fly south the surface wind layer altitude might drop to 1550' after flying several miles. If I flew all the way to the ocean, the surface wind layer altitude would eventually drop to 1000' MSL. It might stay at 1000' MSL even when I am over the beach, where the elevation might be 50' MSL. I believe the formula for determining the surface wind layer altitude (MSL) is... 0B4C + 0EEE or 0B4C + 0F70 I believe the "base" elevation can be computed like this... [sfc wind layer altitude, MSL (see above formula)] - [sfc wind layer altitude as set in the FS Weather dialog] I hope this clears things up a bit. I don't think it's quite as horrible as I've apparently led you to believe. Thanks, Eric

Thanks, Pete. I had already done all the things you asked for. I was just a little too brief, I guess, in my original post. Here are details on the things you asked about: You wrote... Yes, I did this, and 0EEE and 0F70 increase as the ground elevation (0B4C) decreases and vice versa - as one would expect if they were AGL. I had my program continuously reading these offsets (and ground elevation) and writing them all to screen in flight. You wrote... I did this, and FS always shows 1000 ft (as I set it) for the surface wind layer, despite the local ground elevation. It appears, though, that this number is AGL relative to the local "base" elevation, not the ground elevation (0B4C). For example, if you fly 100 miles and during the course of the flight the "base" elevation rises from 500 to 1000 feet, then the MSL altitude of the surface wind layer will gradually rise from 1500 to 2000 feet, staying 1000 feet above the local "base" elevation. At all times, though, FS will show the surface wind layer setting as 1000 feet. Mountains seem to have no effect on the surface wind layer MSL altitude. You wrote... I had (Shift-Z) on during my tests and slewed up and down to find where the wind changed. I had very simple winds: only one layer (the surface layer) set in FS to 1000 ft. I always found the edge of this layer at an MSL altitude of 0B4C (ground elevation) plus 0EEE (or 0F70). I watched this over mountainous terrain and found that the edge stayed very near the same MSL altitude, changing only (I believe) in response to changes in the local "base" elevation, not in response to 0B4C (ground elevation) changes. You wrote... I'll have to study these things. I have no experience with the FSUIPC AWI, WeatherSet, the NWI, or WeatherSet2. Does the AWI allow access from my program to things like the surface wind layer altitude? My program needs to know the MSL altitude of the surface wind layer. Thanks, Eric

Hi Pete, I've been using 0EEE in my program for some time now, but I just did some more thorough testing of it preparing to use it in a new, more critical way. The "FSUIPC for Programmers" document describes 0EEE (and 0F70) as AMSL (which is what I've assumed to date to be true), but my recent testing suggests that they're in fact AGL. I'm using FSUIPC 3.70, by the way. Here's the test scenario and data... I simply took readings of 0EEE, 0F70, and 0B4C (ground altitude) at two different lat/lon positions. The first position was over a wide, flat valley. The second position was over a mountain adjacent to the valley. Positions 1 and 2 were less than a mile apart. Here's what I saw. 0EEE and 0F70 always read the same (as each other), so I grouped them below. offset; valley; mtn; difference 0EEE/0F70 (wind layer alt); 294; 48; -246 0B4C (ground alt); 196; 441; 245 If 0EEE and 0F70 were AMSL, then I'd expect them to read near the same both over the valley and over the mountain. Also, the wind layer altitude dropped over the mountain by almost exactly (within 1m difference) the amount that the ground rose. Am I thinking right? Are these offsets actually AGL? Thanks, Eric

Hi Pete, My application moves the plane around in slew mode to collect topographical data. This "scan" can take several hours, depending on the size of the area scanned. My main objective is to keep an accidental bump of the joystick from interfering with the slewing movement. The reason I'm a little interested in the buttons or keyboard is that I've noticed that after some scans the plane's pitch angle has changed (e.g., maybe the plane's near inverted after the scan). I'm not really sure it's spurious joystick input that's causing this, but that's where I'm coming from. Come to think of it, I believe I've seen this pitch change happen even when the joystick was disabled, so maybe it's coming from elsewhere. It doesn't affect the results of the scan, though, so the problem(?) may not even warrant the amount of attention we've already given it. :D Thanks again for the help. Eric

Thanks, Pete. I did what you said, and I figured out my problem. I was using joystick buttons, not axes, for alt, bank, and pitch. The log showed me this by showing the following events... I don't guess there's any way to disable these inputs is there? It's not that important, though, I'll be happy enough just being able to disable the joystick axes (especially AHEAD and SIDEWAYS), which I can do with 310B. Thanks for the help. Eric

Hi Pete, Is there a way to disable the joystick using an outside program via FSUIPC? I'd like to disable it while my program moves the plane about in slew mode. I didn't find an offset for this using FS Interrogate's 3-Scan Locator. I found offset 310B, which appears to do at least what I want to do, but I've only been able to get the least significant three bits (fwd/backward, side-to-side, and heading) to work as expected. I'd also like the next three bits (altitude, bank, and pitch) to work. What might I be doing wrong, or might there be a problem in FSUIPC? As a test, I set all eight bits and found that only the first three had the expected effect. Thanks, Eric

Hi Pete, I hope you enojoy(ed) your vacation. I've updated CCS to do as I described in my last post in this topic, and I'm hoping I can add another voice (my own and maybe more) to yours in asking Microsoft to give some way that FSUIPC can control (or at least recognize) cumulus cloud positions. What's the most effective way to make this request of Microsoft? A particular message board/forum? A particular e-mail address? An old-fashioned paper letter? Also, if there's a particular phrasing you'd like me to use to make sure I ask for exactly what you'd need to make this happen, I'd be happy to borrow your words. I see that FS10 (FSX) is expected around the end of 2006, so I'd like to go ahead and start making this request of Microsoft. Thanks, Eric

Thanks, Pete. I knew you were out - just wanted to write the note while it was on my slippery mind. I didn't expect there was an easy answer to this. For the time being, I think I'll try to pre-build a scenery file of clouds before starting FS and make sure CCS "dances" appropriately with these clouds. It isn't ideal, but it's at least an improvement. Thanks, Eric

Hi Pete, Thanks again for all the work you've already done to help me with my little Cross-Country Soaring (CCS) program. There's one major shortcoming in it that I don't quite know how to tackle - the inability to make thermals align with cumulus clouds. Do you have any ideas? Here are a couple of mine, but I don't know that either is possible. 1. Perhaps each cumulus cloud is treated as "temporary" visual scenery by FS, with each cloud's lat, lon, and altitude stored in memory. As the clouds drift with the wind, FS would have to update these positions. If there were a way to read these positions, I could then force CCS thermals to align with these clouds. 2. If approach #1 couldn't be used, then maybe scenery files (BGLs) could be prepared in advance or created/altered on the fly by CCS to place clouds where CCS wants them to be. I don't know that much about static scenery, but I might have to have a way to force FS to refresh its memory about nearby BGL scenery in order to make this cloud appear. Maybe there's another approach that would work. I'm open to suggestions. CCS is okay as is, but the #1 real-world thermal marker for a lone pilot on a cross-country soaring flight is a cumulus cloud. Without CCS having the ability to make thermals under clouds (or clouds atop thermals), each flight is like a flight on a cloudless day over undifferentiated terrain. I'd appreciate any amount of thought you could spare to help me figure out how to tackle this challenge. Thanks, Eric Carden

I just registered my copy of FSUIPC, so I'll write a little program to continually write 3480 (Ambient Wind Z) and will let you know what I find. I'll check, while I'm at it, to find out whether this is relative to the world or relative to the aircraft. (I suspect it's relative to the world, as it's set by FS' built-in thermal scenery object. Thermals behavior would be strange, if this value were relative to the aircraft.) I'm crossing my fingers that you can indeed have FSUIPC accept a value for this variable and then do the frame-by-frame rewriting for the program using FSUIPC. That would be just about perfect for the application I have in mind. (Not to mention the many other users that could benefit from this approach at solving the "taxi winds" problem you mentioned.) Thanks again, Eric

Thanks. Knowing that the vertical speed can probably be directly controlled gives me hope. Because a thermal effectively ADDS vertical speed (to whatever the vertical speed would otherwise be given airspeed, bank angle, attitude, etc.), it would be near impossible for my program (without duplicating flight modeling) to accurately mimic the real-world effects of a thermal... but that could end up being my best bet. You led me to another thought, though... Why not see if there's an address that holds the thermal's or ridge lift's added vertical speed and then manipulate that value? I didn't find this variable in your list, so I used FS Interrogate's 3-scan function (very nice) to try. I found two addresses, 2AE6 and 347E, that appear to be it. I haven't figured them out entirely, but I have roughly mapped it thusly so far: approximate vertical speed of air (fpm) / address value 0 / -32,768 100 / 16,350 400 / 16,387 700 / 16,400 (MS's "thermal" scenery object) 900 / 16,403 1,200 / 16,412 1,900 / 16,419 I'm a little curious, though, why both of these addresses contained exactly the same values in all my experimenting. Why would there be two variables to store exactly the same data...? I used FS Interrogate to set each value, one at a time. As soon as I unpaused FS, the plane would pitch down as if it had just hit lift, but it would, within less than a second, pitch back up as if it had just left the lift. Apparently FS continually checks the plane's position to see if it's in a lift "trigger" scenery object and sets this variable to the appropriate value during every run through the code. Do you think if I wrote a program to manipulate one of these values that I'd be able, writing over and over as fast as the program can, to stay ahead of FS and keep it from making the thermal fluctuate from lift to calm to lift to calm, etc.? If you don't know, may I have an access key for testing, please (or is there another way to figure this out)? Here's my program info: Program Name: "Cross-Country Soaring" Company: "Eric W. Carden" Product Name: "Cross-Country Soaring 2004" I'd like to know a little more about "scenery BGL variables", please. Since in the past my simulation was a combination of a special scenery object and an adventure program, these may provide a way... I just don't quite understand how they are used. Thanks for all your help, Eric

I just learned something that may make all my questions irrelevant. In FS2004, apparently the strength of the ridge lift depends on the wind speed at the plane's altitude. My ridge lift scenery object method of simulating thermal lift depends on being able to create lift at the plane's altitude without affecting the winds at the plane's altitude. This is because in a strong thermal, the wind speed may need to be 50+ mph in order for the ridge lift scenery object to create lift of the desired strength. This is a realism improvement in FS2004's treatment of ridge lift, but it pulls the foundation out from under my thermal lift simulation. I have a couple of other ideas, though, (grasping at straws) before I give up, and I'd welcome any ideas from you. First, is there any way to directly affect the plane's vertical speed (e.g., offsets 02C8, 0842, or 31A0)? I think I know the answer, but I thought I'd ask... Also, do you think there's any way to add thrust from a "phantom" engine on a glider? I considered making six different thermal scenery files, with varying lift strength and then using the outside program to change FS's "scenery complexity" setting in order to experience the desired lift strength. It looks like FS reloads scenery every time the complexity is changed, though, so this won't work. What are the "scenery BGL variables" (0DD6, 0DD8, 0DDA, 0DDC, & 0DDE)? Any other ideas? Thanks, Eric

Hi, I'm interested in creating a freeware program to mimic an "adventure" I built for FS5.1, FS95, and FS98 to create realistic thermal soaring conditions (as opposed to the few, square, ever-present, super-strong thermals MS provides out of the box). Let me explain a little about how this works, and my general question to you is... do you think I can accomplish the same (or close enough) with FSUIPC and FS2004. Thanks in advance. First, I create a scenery area, as large as I want, "blanketed" with ridge lift from sea level to 20,000' or so. I already know this is possible. The strength of the ridge lift is controlled by the surface wind layer's speed and direction. My previous adventures fixed the surface wind direction and varied lift strength by manipulating wind speed. The adventure randomly places "thermals" of various sizes, strengths, heights, and amounts of "lean" (downwind) and then monitors the aircraft's position relative to these thermals. If the aircraft is within an area defined by the adventure as a thermal, it sets the surface wind speed as needed to achieve the desired lift strength. In the strong part of the thermal, the wind speed is set highest. Nearer the edges of the thermal, the wind speed is set lower. Outside the thermal, the (surface) wind speed is set low enough that no lift is created. I haven't tested the windspeed-to-lift strength behavior in detail in FS2004 yet, but in FS5.1, FS95, and FS98, surface winds in the 0-6 knot range produced no lift. Thus, if my program set the FS2004 surface winds to calm and then FS increased them on its own up to 6 kts, there should be no problem. If it set them to 7-8 kts, though, there would be an unrealistic ~200 fpm lift everywhere. Thus, my first question: Under what conditions or over what period of time might FS2004 increase the surface winds by 7 kts? If this isn't likely to happen within at least a few minutes, then I can just make sure my program resets the surface winds every minute or two. If it may happen only seconds after I set the surface wind speed, though, it might take too much processing power just to stay on top of the wind speed. If it is known to happen gradually, then I can check the wind speed every minute and only reset it when it's approaching a value known to create lift. I could alternatively just spin the winds 180 degrees when I don't want any lift, as the wind must be within about a 90 degree window to produce lift, regardless of the wind speed. (I'd need to know the same sorts of things about wind direction, though, as I'm asking about wind speed.) While in lift, I'd like the program to be able to update the surface wind speed every second or two, as the thermals are strongest in their "cores" and taper down to zero lift at their edges (as in real thermals). Without this rapid updating, it's difficult for the pilot to find the center of the thermal and stay in it. This brings me to my second question: How quickly does a surface wind speed change take effect after a program using FSUIPC sends the "write" command to update the wind speed? If the delay is too long, the lag time will make it near impossible to find and stay in a thermal, especially a small one (as most are in reality). Also, how bad is the "skip" I've read about when adjusting wind speed? If it's too bad, then setting the wind speed every second or two may be overly annoying. Is there a method that could be used to minimize this "skipping"? Thanks for any help. Eric