need FSUIPC-FS2004 wind control knowledge

[ecarden]

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

[Pete Dowson]

How quickly does a surface wind speed change take effect after a program using FSUIPC sends the "write" command to update the wind speed?

The bigger problem in FS2004 is getting the kind of direct control you want. As explained elsewhere, FS2004's weather engine is simply not directly controllable. It's a complete new beast and seems to be an attempt to simulate a true atmosphere.

If you start off with zero weather -- eg use the Clear All Weather facility in the FSUIPC weather interface, or the hot key, then setting global weather should give you your wind almost immediately. There will be a hesitation, a stutter.

In FS2004 I have found no way just to change one weather element. When you change the wind, FSUIPC has to supply a complete set of weather -- pressure, clouds, visibility and temperature, as well as the wind.

Then FS2004 uses this "global" data to populate all the nearby weather stations which have no local weather of their own. Immediately after "clearing all weather" this will be all of them. A matrix of possibly over a 100 stations may be so populated -- it is this process which I think causes stutters. A complex data structure is generated internally, one which I've not fathomed at all I'm afraid.

There is no such thing as weather set at any arbitrary position, weather is only "set" at weather stations. I can read the weather an any position -- what you get then is an interpolation based on the surrounding weather stations.

The next problem is that, once the stations have their weather set, they "develop" locally. After an indeterminate time you cannot influence them any more with global settings because they now have their own local weather. The only way to change them is either to set specific station local weather, using their ICAO ID codes, or starting again -- clearing all weather and setting global again. The problem with this way is that it is noticeable and ugly.

I hope I haven't put you off. You should experiment with what is available and see for yourself what you can do. Originally I thought these difficulties would make most weather control programs almost impossible to get right, but folks like the authors of FSMeteo and ActiveSky have worked wonders. None of it is perfect -- there are certainly bugs in the FS2004 weather engine (especially in the wind interpolation algorithm) which mess things up and these seem to become more evident when ambitious weather settings are attempted. But start simple and see what you can achieve.

Regards,

Pete

[ecarden]

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

[Pete Dowson]

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?

Try 31A0. In fact, try writing to any or most of the assorted velocities and accelerations in offsets 3060-30B8 and 3178-31D0. FSUIPC does route these through to the Sim Engine.

I don't know what effects you can generate, but certainly it is by manipulating things here that applications like carrier hooks and catapults have been implemented. I'm reasonably confident you'd be able to do something, but I don't know enough to advise you in detail I'm afraid. You will have to experiment.

I doubt that you could add thrust on a glider because the internal data sections referring to engine behaviour and performance simply don't exist when there are no engines pre-defined. You'd need to fiddle it by constantly writing accelerations and/or velocities.

What are the "scenery BGL variables" (0DD6, 0DD8, 0DDA, 0DDC, & 0DDE)?

Just ways of purpose-written scenery to interact with programs and vice-versa. The BGL can read/write those as well as a program.

Regards,

Pete

[ecarden]

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

[Pete Dowson]

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.

These offsets both map to the same place, and that is half-way through the Ambient Wind Z value :o . This is accessible directly, as a Double float, at offset 3480, but it's behaviour and usefulness is unknown at present -- maybe you will find out more.

This offset is one of a number which were added in 3.22 but have not yet appeared in the SDK (I've just been too busy!). In the interim I list new mappings in the Release Notices -- in the History document, and in the first Announcement at the top of this page.

You will see that these are the wind elements available:

3470 8 Ambient wind X (double)

3478 8 Ambient wind Y (double)

3480 8 Ambient wind Z (double)

3488 8 Ambient wind velocity (double)

3490 8 Ambient wind direction (double)

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...?

They don't, it is merely an artefact of the mapping carried out inside FSUIPC to provide access to variables in various places inside FS. Unlike FS98 where all this stuff was concentrated in one memory area, the data listed in the Programmer's Guide is obtained from all over FS -- even the data that was in one data area in FS2000's SIM1 is, in FS2004's SIM1 split into smaller private data areas only accessible through pointers to pointers to pointers and so on -- FSUIPC follows all these to access the data for you.

In other words the vision of all this being simply in memory for you to read and write as you please is a mirage, an illusion, created by FSUIPC to make the programming the same as it was in FS98.

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.

This is the problem with most of the values which are derivatives -- they may have an effect, but will be re-calculated on each cycle. I think the success of catapults and hooks was only by repetetive changes over a period to slow down/speed up the action. Just changing a value which is continually re-calculated has no lasting effect.

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

I don't know. You'd have to find out by experiment.

may I have an access key for testing, please (or is there another way to figure this out)?

You mean to say you aren't even a registered user of FSUIPC? :( If you register FSUIPC you need no other access keys. Pretty much all the developers I know of register FSUIPC so they can get the sort of support I am providing. After all, the SDK itself represents a lot of work in itself.

You don't really need an access key for your program, even if it is freeware, until you have something you wish to share will others, possibly unregistered users.

I'd like to know a little more about "scenery BGL variables", please.

Sorry, I've no idea. I am not a scenery writer. As far as I know there are BGL instructions which can set them and read them. You really need a BGL programming reference.

Regards,

Pete

[Pete Dowson]

By the way, I think all these:

3470 8 Ambient wind X (double)

3478 8 Ambient wind Y (double)

3480 8 Ambient wind Z (double)

3488 8 Ambient wind velocity (double)

are in metres per second. FS seems to work in those units internally.

The fact that you have found that by writing to the Ambient wind Z vector you can make a difference to the aircraft behaviour is very interesting. It opens up another line of research for me -- into how to provide wind speed limits, "taxi winds" and wind smoothing on FS2004.

Maybe if I constantly write to these values I can at least make the sim act as if the winds were limited or smooth even if the weather data says otherwise.

When I'm looking into this, perhaps I will find an easy way to allow you to provide a specific up or down draft -- like allocating another offset for you to write a required Z wind component to, which FSUIPC could apply on every FS frame.

One thing I'm not too sure of at present is the X, Y, Z notation -- I don't know if these axes are relative to the aircraft, or the FS world, and in the latter case, whether X and Y are oriented to True North or to the aircraft's longitudinal axis. Some experimentation is called for!

Regards,

Pete

[ecarden]

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

[Pete Dowson]

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.)

I spent a lot of time experimenting over the weekend, trying to use these offsets to implement both taxi-winds and wind smoothing. I've not really got anywhere yet -- there's a strong possibility that the weather input to the sim engine is NOT via these values.

But one thing I have found out for sure -- 3480, the Z axis wind component, is NOT the vertical wind. FS is consistently following the system it has for the other dynamic values (see the Notes at the end of the main table in my Programmer's guide):

X = Lateral Left-Right

Y = Vertical Up-Down

Z = Longitudinal, forward-backward.

I think this is related to True North, not the aircraft orientation.

I don't know what you discovered earlier, with half the Z component, but maybe lift changes are being influenced by changing the air flow over the wings, not by Y-component air velocities.

Anyway, maybe you need to concentrate on the location for Y not Z, assuming it is actually used in the sim engine.

I'll continue experiments on the others for taxi and smoothing, but I am not holding out much hope yet.

Regards,

Pete

[Pete Dowson]

I've now found what I think are Aircraft-related wind values:

AIRCRAFT_WIND_X

AIRCRAFT_WIND_Y

AIRCRAFT_WIND_Z

I'll check some more, but if these X and Z coordinates are related to the aircraft orientation, as I think they are, then writing to these may be a better bet than using the "wind at aircraft location" values.

They are double floats and also in metres per sec.

If they look like they might be useful I'll map them and let you know the offset details -- possibly I could sustain all these once written, releasing them back to FS control after you write 0.0 perhaps.

Regards,

Pete