Jump to content

CumulusX!


Peter Lürkens
 Share

Recommended Posts

  • Replies 178
  • Created
  • Last Reply

Top Posters In This Topic

Hi all,

today I had bad setback. While tracking down the bug I mentioned above, I discovered so many conditions, that in cases will lead to diverging thermal development, that I'm afraid I have to redesign the entire control code for the MP AutoThermal section.

It's unbelievable how much problems it makes to handle our system of time zones, datum line, and so on properly.

So, please do not waste too much time to track inconsistencies in multiplayer AutoThermals.

regards,

Peter

Link to comment
Share on other sites

I had bad setback

eeek unlucky Peter! We're still having good fun flying around with 0.94 so we're not exactly suffering.

Is multi-player effectively the same issue as loading a saved flight - i.e. if the auto-thermals are consistent for multi-player then when you re-load a saved flight the thermals will also be in the same places ?

Good luck,

Ian

Link to comment
Share on other sites

Back again. I hope its fixed now.

Is multi-player effectively the same issue as loading a saved flight - i.e. if the auto-thermals are consistent for multi-player then when you re-load a saved flight the thermals will also be in the same places ?

In fact, the entire situation of AutoThermals (=Multiplayer Thermals, in the meantime), including random variation of thermal ceiling and inversion layers is controlled by universal time, geographic psoition of the individual thermal sections, and weather conditions (controlling presence, clouds, and ceiling of thermals). So if weather and time is the same, and you have the same global Cx! settings then you will have exactly the same thermal siutation.

All these are the same for everybody in an FSX multiplayer session, when the particpants are close by and have the same Cx! settings loaded. However weather and time are not necessarily synchronised in alternative hosting environments as FSD or FSHOST (in particular time).

The problems I had, came from the fact that people may join in a session at different times and places. Basically, you need to look back in time, and over to adjacent regions, to be able to create the same situation that everybody else already has. That is possible for the time parameters and the geographic sections (because the rules are simple and deterministic), but it is impossible for the weather conditions. Therefor all weather dependent effects are always created "on the fly" which means, that it will change rather abruptly in occasions, e.g. if you fly from an area with high cloud altitude in another one with low altitiude. The exisitng Cx! clouds will drop down immediately, and jump up again if you return in the previous area.

What's new in Version 0.941

This is mostly a bug fixing release. In the previous release (and possible also in 0.93) there were many possible conditions when AutoThermals would actually not coincide among the participants. This should be fixed now. Inversion layer and thermal ceiling (when blue) are synchronously randomized every three hours within the limits of the settings.

An annoying behaviour until now was that after a sudden change of wind, due to the wind dependent leaning of the thermal column, all of a sudden the center of the thermal was far away. This was more, the bigger the distance to the ceiling was. Now, changes in wind are smoothed over approximately two minutes, which gives a much better chance to keep the thermal centered. This features is always effective in AutoThermals. In ScriptThermals it is deactivated when selecting CCS2004 compatibility.

What's next:

  • Structured wide spread sink with streeting
  • Using the slope data base for proper location of mountain thermals (offline only, or selectable)
Cheers,

Peter

Edit: Attachment removed because of final release

Link to comment
Share on other sites

Hi Ian,

I have stolen your probing approach to keep the water bodies clear.

Stay tuned.

best regards,

Peter

Hi Peter,

could you use the probing approach to get landclass infos too?

This could be the way to set thermals more to the places where thermals more likely. The FSX default thermals are used the landclass informations too.

Bye

Markus

Link to comment
Share on other sites

I have stolen your probing approach

Cool! sim_probe version 2.0 includes the c++ source. How many probes do you have and are they at 10,000 meters like mine ? Do you create new ones each time or create them once and move them around? FSX can be expected to discard AI objects at will, although generally you should expect a 'ai deleted' event. But also your AI objects sometimes don't survive certain user actions but then you might not get the 'ai deleted' event and you can't assume you will get a simstart event in that particular circumstance either. So basically I handle the events I do get and fall back to a four-second 'heartbeat' as a safety net. It's worth saying in my experience if I just fly around in the sim, my ai probes *never* get deleted but it's clear this *can* happen.

If you're probing for water you could bias the thermals to locally higher ground also...

Ian

Link to comment
Share on other sites

could you use the probing approach to get landclass infos too?

I'm afraid not. There is no API to retrieve land class information in the SDK :confused2:

How many probes do you have and are they at 10,000 meters like mine ? Do you create new ones each time or create them once and move them around? FSX can be expected to discard AI objects at will, although generally you should expect a 'ai deleted' event.

If you're probing for water you could bias the thermals to locally higher ground also...

I'm using only one probe at a time at the exact place of the thermal It is created, produces the data and immediately deleted again. If the probe is deleted before it produces the data my thermal engine would probably stop, because there is a handshake in the program. So far I never missed an object.

See the readme for the relief (Edit: means the mountain profile).

I' mostly interested in the wind smoothing feature. On the one hand side its convenient not to have the abrupt chances on the other hand, this might be a source for inconsistencies between multiplayers.

regards,

Peter

What's new in Version 0.95

The major improvements are structured widespread sink and the correct :-) handling of waterbodies. Widespread sink aligns to the wind direction and strenght and influences the thermal positions (places that have less sink will attract thermals). At higher wind speed this leads to streeting as you can check best with high thermal density and e.g. 14 kn of winds in various directions. Wind smoothing has been turned off again temporarily, because it takes also quite a while until a new streeting pattern has settled.

The other feature is that thermals do not go over water anymore. In future, they may also follow the relief to a certain extents.

Computing effort has grown relevant so that an impact on FPS may be ovserved.

Edit: Attachment Removed

Link to comment
Share on other sites

Peter,

Are you sure your 0.95 version is working oke? On my computer it starts oké with lots of thermals with 4/8 clouds set, but after about 10 to 15 minutes suddenly most of the thermals disappear and after some minutes only a few new ones show up every now and then. Maybe 1 per 100km^2

I saw it happen in the SION-area and the same when flying over Holland (Nice to see no thermals show up over the NorthSea anymore).

My weather settings were: 4/8 clouds cumulus base 10.000ft, wind 360/16, season summer, time 13.00 local time.

In the CLX!-configuration I have thermal density set to 5 per 100km^2.

Bert

Link to comment
Share on other sites

Hi Bert,

I'm afraid you are right. Today I might a longer test tflight myself, and it turned out, that the algorithm of interference of the cloud distribution with the widespread sink has a basic problem. That was the reason I deleted the attachment again.

The principle idea was to generate repeating, wave-like pattern, influenced by wind speed and direction. To make it manageable and repeatable it is based on sinus-functions and aligns to discrete directions through a landscape tile (1°x1°). Thermals are produced and deleted according to this pattern at the origin of the thermal. Since it is not possible to look back in history regarding the weather conditions, it is done continuously, expecting that when two aircraft are meeting at the same location, they will have equal conditions and as such also an equal thermal situation.

The problem is, that with this approach you will always have discrete steps in the pattern, when wind direction changes over one of these discrete transitions. Unfortunately, this means that sensitivitiy to changes of wind direction is enormous close to these transitions. Another problem is, that relying on the aircraft wind situation, there might be substantial differences in different altitudes, meaning that a thermal disappears, when climbing into another wind layer.

It would work perfectly, if wind conditions were constant.

The effect is, that you have an almost erratical change of thermals placement, when the wind oscillates around certain directions (and speed). As I cannot rely on constant and stable wind conditions, I need to find a more robust approach. Yet, the management engine behind it could be used further on.

Your observation, that thermals were disappearing after a while, is not that obvious to me. It would mean, that there is also a bug in the management part of the algorithm, not only in the control rule.

That's too bad, because that was the biggest effort in the change from the previous release. Do you have a situation and Wx file available that could help me to track the conditions down?

best regards,

Peter

Link to comment
Share on other sites

Well Peter,

I'll have to check first if it also happens when I delete my wind-layers. I always have three wind layers set with slight differences of wind direction (about 10degrees) and wind speed (16, 20 and 25 kts).

It could be that I saw what you described "when climbing into another wind layer".

Bert

Link to comment
Share on other sites

I'm afraid not. There is no API to retrieve land class information in the SDK :confused2:

Hi,

sorry I think I make a wrong suggestion, I mean the "SURFACE TYPE" for Aircraft on ground. I guess you use the "2 = Water" to get the water position. I suggest too use the other values like "11 = Forest" too get the place where thermals are rare. And place where thermals are more likely.

Don`t know if this will work.

You know add the "SURFACE TYPE" with "SimConnect_AddToDataDefinition" and you should get the informations. Like said before I guess you already use this for getting the water information.

Sorry for my misleading post before.

Bye

Markus

Link to comment
Share on other sites

sorry I think I make a wrong suggestion, I mean the "SURFACE TYPE" for Aircraft on ground. I guess you use the "2 = Water" to get the water position. I suggest too use the other values like "11 = Forest" too get the place where thermals are rare. And place where thermals are more likely.

Don`t know if this will work.

Yup, this will work, and that's what I do, but only for water right now. I have a mechanism already in place that could handle probabilities as well, and not only yes/no.

I have FSUIPC un-licensed version installed.

Well, as said above, FSUIPC does a lot of things with weather. I'm not sure how much of it is done also in un-licensed versions, since many features are reserved for licensed users, as, for example, wind-smoothing. Afaik it does by directly modifying and possible creating nearby weather stations according to some complex algorithm aiming to reduce discontinuous wind changes.

A side effect is, that it most probably renders wind information useless for structuring sink and streeting, because there is no guarentee to have reliable and halfway stable wind information, in particular among multiplayers.

I think I'm close to solution for the continuity issue with the structuring, but I still need a good idea who to overcome the problem with the wind data. It would be also good to know, if the problem with disappearing clouds is reproducible. In the meantime I have also two other ideas what may have happend:

1) An AI Probe has got lost, and Cx! stopped to create or recreate thermals. Very bad.

2) I noticed, that sometimes FSX shows cumulus clouds in the sky while the internal weather observation reported cirrus only. In this case Cx! gradually starts to remove the clouds, 3 every second. In this case, you may turn on the "UnBlue" option and the clouds should reappear. If nothing happens, and the clouds continue to disappear, then either 1) has happened, or Cx! thinks that by some reason thermal activity has stopped, e.g. because of overcast stratus or some stratus below cumulus layers.

Well, complicated, isn't it?

best regareds,

Peter

Link to comment
Share on other sites

I think I'm close to solution for the continuity issue with the structuring, but I still need a good idea who to overcome the problem with the wind data. It would be also good to know, if the problem with disappearing clouds is reproducible. In the meantime I have also two other ideas what may have happend:

1) An AI Probe has got lost, and Cx! stopped to create or recreate thermals. Very bad.

2) I noticed, that sometimes FSX shows cumulus clouds in the sky while the internal weather observation reported cirrus only. In this case Cx! gradually starts to remove the clouds, 3 every second. In this case, you may turn on the "UnBlue" option and the clouds should reappear. If nothing happens, and the clouds continue to disappear, then either 1) has happened, or Cx! thinks that by some reason thermal activity has stopped, e.g. because of overcast stratus or some stratus below cumulus layers.

Well, I sat myself down at SION airport (LSGS) next to the runway, looking in East direction, and waited in top down mode, to see the thermal activity from above. After about 10 minutes the clouds disappeared, three per second and no new thermals were created. about five minutes waiting (no visual CSX!-activity in that time) I checked the "unblue" and new thermals were created immidiately and the thermal engine worked from that moment as it should. After unchecking the "unblue" the thermals disappeared again. Re-checking the "unblue" gave me back the thermals.

My settings were:

cumulus layer at 10.000ft 2/8 coverage, and nothing above it;

visibility 30mi/48km;

One wind layer 6degrees/16kts up to 3.000ft, one wind layer from 3000 up to 6.500ft 16degrees/20kts and one wind layer from 6.500 up to 20.000ft 21degrees/25kts. Season summer (21 of june) start-time local 12.25hrs.

For now i will keep the "unblue" checked and see if it stays running oké.

Bert

Link to comment
Share on other sites

That sounds pretty much, as if Cx! recognises the weather as "blue"-condition, and is good news for the principle working of the management engine (no loss of AI objects or other dead lock conditions).

I will run the test, too.

One more question: What was your setting in the Weather Change slider in FSX?

regards,

Peter

Link to comment
Share on other sites

That sounds pretty much, as if Cx! recognises the weather as "blue"-condition, and is good news for the principle working of the management engine (no loss of AI objects or other dead lock conditions).

Does the "blue-"condition mean that thermals are there, but no clouds appear? Just like it can happen in real life, when air-humidity is low and/or the thermal doesn't climb until dewpoint is reached?

If you really are building that, man are you good :respect: .

Bert

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share


×
×
  • Create New...