Jump to content

CumulusX!


Peter Lürkens

Recommended Posts

First off, WELCOME to SOAR! :hi: I cannot answer your question about your problem. :???: But I can tell you someone should possibly be able to. I don't seem to remember who all is running in XP64bit &/or Vista64bit. I myself am running XP32bit I think.

I see that you have downloaded the current CumulusX! v.81 from Peter's site, I was going to ask you to update to that one if you had not. But with a new version comming out over the weekend sometime maybe, maybe just wait until then. That's all I can say right now, but that may be the reason you have not gotten a reply yet. Maybe the new release is coming soon!?

sf4JC

Link to comment
Share on other sites

  • Replies 178
  • Created
  • Last Reply

Top Posters In This Topic

First of all welcome to the SOAR community.

I tried to build with a different compiler options, perhaps you could try it out. Otherwise I'm afraid I can't sy too much about your problem.

best regards,

Peter

PS: See here for a short description: http://virtualsoaring.org/iboard/index.php...ost&p=11363

Edit: Attachment removed because of final release

Link to comment
Share on other sites

First of all welcome to the SOAR community.

I tried to build with a different compiler options, perhaps you could try it out. Otherwise I'm afraid I can't sy too much about your problem.

best regards,

Peter

PS: See here for a short description: http://virtualsoaring.org/iboard/index.php...ost&p=11363

Hi Peter,

downloaded the 0.911 and tested it with Windows Vista 64 Bit without problems.

The previous public version 0.81 didnt even start on Vista 64 Bit.

Thanks for youre work.

Bye

Markus

Link to comment
Share on other sites

EMPTY DEBUG WINDOW

I'm running CumulusX! 0.911 with sim_probe_debug_1_2.exe run from a console window. sim_probe_debug is printing all the right stuff in it's console, CumulusX! is giving a 'green square' for it's probe status, but the "debug" window opens normally but otherwise doesn't display anything. It seems to me the lift isn't coming into the sim either but I'm not absolutely sure. My sequence was (1) start FSX at start screen (2) start CumulusX! (3) start sim_probe_debug.exe in a console window (4) load a flight (5) fly a bit (6) click the "info/debug" option in CumulusX! (7) carry on flying. ** EDIT ** I'm a moron & forgot to click the 'toggle lift' button, thanks Bert ** END EDIT **

Any ideas ?

Peter - a suggestion - a *netto* vario is almost essential for ridge soaring and actually is the easiest to program. Is is possible to drive the bottom left (cambridge) vario with the pure lift value coming from CumulusX! ? Prior to CumulusX! I had my cambridge modified to display 'Ambient Wind Y' which basically means it's a netto, but that isn't valid for CumulusX!. It would make testing/debugging a lot easier and I think normal users would find it valuable. I considered having sim_probe write to some writeable FSX variable which otherwise wouldn't affect the glider, and have the vario read that, but that would have been a bit of a hack just for me.

cheers, Ian

Link to comment
Share on other sites

Ian,

Just a wild guess: did you press the "Toggle lift"button in CumulusX after starting it? It shoud be green also when you fly.

Bert

LOL thanks Bert - silly mistake on my part you were absolutely correct. I had the sim_probe debug window open and could see the lift being calculated, and the slope probe data light was green in the cumulusx! window. I haven't worked out whether the 'toggle lift' button defaults to off - I think the FSX menu (add-ons - cumulusx! - lift on) defaults to lift OFF? I see now the FSX menu changes from lift on to lift off (haha), but the 'toggle lift' button in the window has three states - grey, red and green. In general I think the connect, disconnect and toggle lift buttons have become redundant.

thanks

Ian

Link to comment
Share on other sites

OK - I've just flown the 'local' ridge from my old home airfield (Blairstown, New Jersey) towards the South West, with the wind at 318 degrees 24 knots, just on probe ridge lift. I definitely think we're on to something... actually I found it slightly uncanny the way the gaps and the slopes made the lift so detailed :yahoo:

I was able to maintain 100-120 knots so long as I kept close to ridge-top, just as for real in the ideal wind conditions so the parameters aren't a long way from what's needed. Lift was peaking around 4.2 m/s.

I found it best to fly in windowed mode so I could have the debug info displayed as a proxy for a netto vario, so Peter I'd repeat my suggestion about programming one of the panel varios to display the CumulusX! lift value. I'd do this myself straight away but there's no simple variable to display with CumulusX! as-is, I think.

Ian

Link to comment
Share on other sites

** I'm a moron & forgot to click the 'toggle lift' button, thanks Bert ** END EDIT **

Did already speculate about a dead SimConnect connection which could produce such a behaviour, because all timing in CumulusX! is derived from FSX, and thus update of the debug window as well as checking the state of information will stop. I'm almost always using the AutoStart feature now, which turns on lift automatically, too.

Peter - a suggestion - a *netto* vario is almost essential for ridge soaring and actually is the easiest to program. Is is possible to drive the bottom left (cambridge) vario with the pure lift value coming from CumulusX! ?

What is currently implemented is:

"Variometer Rate" is overwritten with TE-Vario. meaning that the built-in vario is now compensated rather than having a poor estimation of netto-vario. This includes the beeper.

"Vertical Speed" is overwritten with aircraft raw-vertical speed + Lift. I did this to achieve that instruments of powered planes do indicate correctly when they pass ridge lift or thermals, without the need to modify the gauges.

The sample gauges from the CumulusX! package are not relying on this, instead they provide their own compensation, rsp. averaging, thus being independent from the CumulusX! module (except from the beeper). So they work even with the original FSX thermals.

The official way (as far as I understand the SDK) to get it into a regular gauge would be:

Create a limited C++ gauge dll,say "netto_vario", contacting a new client data area of CumulusX!, receiving the netto lift from there and providing a custom variable, say "netto_lift", ready for use by a gauge.

Then create XML gauge (modification of VSI would do), where the indicated quantity is "C:netto_vario:netto_lift". That's it (only). I must admit I have little motivation to start another code project at this time, in a totally different configuration.

Of course no glider has direct access to the vertical speed of the surrounding airmass. Instead, the realistic way to do it would be:

Determine the polar of the glider and compensate the TE vario with polar sink of the glider, possibly also with weight and bug compensation.

best regards,

Peter

Link to comment
Share on other sites

I think the FSX menu (add-ons - cumulusx! - lift on) defaults to lift OFF? I see now the FSX menu changes from lift on to lift off (haha), but the 'toggle lift' button in the window has three states - grey, red and green. In general I think the connect, disconnect and toggle lift buttons have become redundant.

I know I'm behind with the doc's, just to clarify:

The Toggle Lift Button is a sort of "Lift Masterswitch", in case you encounter problems with the lift simulation, you can switch off immediately, without the need to leave the sim for restarting, or loosing your current settings. So all current thermals are kept in memory, only the clouds are removed to avoid confusion in the sky image. It's also nice for testing.

Grey: Lift not enabled, Green: Lift enabled and active, Red: Lift enabled and inactive because of FSIM stopped in pause, slew or dialogs.

The FSX menu shows what you are going to do: Lift off: turns off lift and vice versa, but obviously it is not clear enough. I think I'll change it to "Disable Lift"/"Enable Lift". I may also change the label of the button accordingly.

With AutoStart on, CumulusX! tries to connect to FSX automatically and turns on lift, if successfully connected. Still lift remains inactive (red) until the Sim is actually running. If FSX is not running, the connection attempt will fail and you have to connect manually. Lift is still turned on automatically then.

The green boxes indicate the availability of a contribution when it is requested. So in inactive state it is not a reliable indicator, the same when a component is disabled, when it is reset to grey. I'm still thinking about it, to get it most consistent, which is not easy because the mechanisms behind the scene for AutoThermals, Script Thermals, Slope Data Base and Sim Probe Contributions are pretty different.

regards,

Peter

Link to comment
Share on other sites

Hi Peter - Thanks for the update and I've got the hang of it now, but I've got a couple of suggestions for the user interface - I won't be offended if you disagree:

(1) On the FSX menu, you could have *both* an "Enable lift" menuitem and a "Disable lift" menuitem rather than dynamically changing the menu which is unusual UI behaviour. If you want the menu to show the lift status, perhaps change the text of the"Enable lift" meuitem to "Enable lift (already active)". Both menuitems should be active but you just handle them appropriately, i.e. do nothing if the user clicks "Disable lift"and it's already disabled, similar for "Enable lift".

(2) I think the 'Connect' and "Disconnect" buttons on the CumulusX! window are redundant and would be better reserved for a debug version. The prod deployment should assume CumulusX! is in exe.xml and if it doesn't connect something's gone wrong and the user should restart FSX. I *think* CumulusX! doesn't automatically exit when the user quits FSX though (for example see SIMCONNECT_RECV_ID_QUIT in sim_probe_monitor.cpp) If I'm mistaken about CumulusX! please forgive me.

(3) "Toggle lift" - do you need this button if you've got the FSX menu ? Maybe all you really need to do is display the status (Lift disabled / lift enabled / broken)

On a more important note, I just got out the Tom Knauff book "RIDGE SOARING The Bald Eagle Ridge" and took a flight from Ridge Soaring Gliderport in Pennsylvania as described in the book, set the wind to a Northerly 20 knots, and it was absolutely amazing. The sim_probe/CumulusX! combination really works!

regards,

Ian

Link to comment
Share on other sites

(2) I think the 'Connect' and "Disconnect" buttons on the CumulusX! window are redundant and would be better reserved for a debug version. The prod deployment should assume CumulusX! is in exe.xml and if it doesn't connect something's gone wrong and the user should restart FSX. I *think* CumulusX! doesn't automatically exit when the user quits FSX though.

If I'm mistaken about CumulusX! please forgive me.

Actually it should, but only if AutoStart is checked.

Bascially you're right, it's probably more that I'm used to run CumulusX! independently from FSX for testing code snippets and play around with settings.

(3) "Toggle lift" - do you need this button if you've got the FSX menu ? Maybe all you really need to do is display the status (Lift disabled / lift enabled / broken)

It's mostly the same as above. In addition, the routines setting and resetting the lift are running over GUI elements, which is probably not a preferred coding style. But it takes me some effort to redesign the code at this time and I prefer to improve the thermal behaviour some more.

Currently the thermal timing is neither latitude, nor season dependent, which results in nice AutoThermals after dawn and before dusk in some cases. I have sun path calculation ready which I'm now going to implement in the AutoThermal routine first.

I'm not through with consideration about the scripted mode. I will not change anything in CCS Compatibility mode, anyway, but for the native mode I have two different approaches in mind.

The first is to follow the content of the script file strictly. This gives the script file designer maximum influence on the thermal activity. The consequence is that a scriptfile will match only a given weather condition and season.

The second is, to consider a script file as a sort of template, which is modified to adapt current weather situation (e.g. thermal ceiling adopted to cumulus layer, timing adopted to season, no thermals with certain weather conditions (e.g. low layer stratus, rain fall, etc., rugged thermals in heavy wind)

In fact, CCS scriptfiles are a bit in between, considering the cumulus layers.

Would like to hear your feedback on this.

regards,

Peter

Link to comment
Share on other sites

Hi to All .-)

thx very much to Peter for new version 0.911 .-) I confirm too, that it works on vista 64 without problems !-)

I attached my experience from first run to feedback section. Now is finally time to try possibilities of CumulusX!! .-) Thx.

Sněhulák .-)

Link to comment
Share on other sites

Hi to All .-)

thx very much to Peter for new version 0.911 .-) I confirm too, that it works on vista 64 without problems !-)

I attached my experience from first run to feedback section. Now is finally time to try possibilities of CumulusX!! .-) Thx.

Sněhulák .-)

Hello Snowman,

welcome to our virtual airfield pub. Get yourself a beer, sit down with us around the big round table and listen and tell those tales about never flown flights... nazdraví ! :cheers2:

All right, now back to CumulusX!

Peter, Ian,

yesterday Bert and I were able to get both running, CumulusX! (V 0.911) and Sim_Probe.exe under Vista64 on my new rig. Bert did hand me those files over via email as Virtualsoaring was down the last couple of days - hope you both don't mind. I first had some troubles first due to the missing C++ Runtime. Then, after installation of the Runtime-Lib I managed to get Sim_Probe active. We started a multiplayer session afterwards (Bert started it, I just took part as client) in Sion and got airborne with slew-mode. After adjusting my CumulusX!-Settings to exactly those of Bert and a lot of trial-and-error trials Sim_Probe and CumulusX! started to work together (2nd indicator on CumulusX! main window turned green). I have to admit that most errors were clear error40s (Error was sitting 40cm away from screen) but still... one fatal error remained and we were not able to get it fixed. After starting Sim_probe and activating it via FSX-Menu->Options->Settings->General->Okay (with no changes) the indicator turnes green and the debug window of CumulusX! shows changing SimProbe-values. Additionally I was able to see pink parachutes (with pink boxes) fall to the ground around my DG808s. Seconds after the first Box kind of explodes on the ground surface (that happens everytime the parachute falls down to ground-level and you can here a crash-sound wher this happens), the CumulusX!-Sim_Probe-indicator-light turns RED. Another part of a second later the SimProbeExists-value turns to False and the other SimProbe-value locks on whatever the last lift-factor had been.

After a few more tests I can tell you now that the issue has nothing to do with multiplayer mode as it works (or does not work, to be more precisely) the same way while flying offline in free-flight-mode.

It would be great if you could help me fix that issue.

Greets from EDFM

Dirk.

Link to comment
Share on other sites

Peter I quite understand your intention to concentrate on the thermal development.

Can you explain how the script file is used - is it just for CCS2004 compatibility or is it needed in multi-player to make sure everyone has the same thermals ?

In auto-mode how does CumulusX! decide where to place the thermals? Am I right in assuming for multi-player use the placement would need to be a function of latitude, longitude and date/time only? I'm assuming the use of a common WX file between players and the lat/long might have to be the corner of some bounding box (e.g. user lat/long degrees as integers).

You mentioned a latitude factor in the lift generation - you might be able to use longitude as well for some simple tweaking (i.e. the lift goes higher in the mid-USA than Europe).

Now we're expert on client data areas (ho ho), for multi-player could CumulusX! get it's settings using that mechanism somehow so you know everyone has the same? My guess is you'd read the settings structure on each SIM_START, and given it's CumulusX! to CumulusX! it would actually be easier than reading from a file. Single-player is a file as usual. Just a thought. In a similar vein any thought about getting CumulusX! settings from a mission? Or for multi-player maybe for now the settings should just be forced to default values appropriate (as you say) to the latitude and season.

In creating my missions, (specifically Austrian Soaring - Day 4) I found it quite realistic to make the thermals weaken towards one corner of the task. It's certainly been my real-lift experience that you take a good climb when you can get it when the area ahead looks poor, and you slow down when heading towards the poor area. I could understand that you'd need additional settings which are complicated enough already, so that's a bad thing.

Im a strong believer that the majority of pilots do just want to "load up and go", and so if your auto-thermals have a latitude/logitude/time sensitivity there is the chance of not needing to provide a user settings control. I'd expect at the very least if anyone wants to compare their task times it would have to be on the 'default' CumulusX! settings and the same WX file.

Regards - Ian

Link to comment
Share on other sites

Actually it should, but only if AutoStart is checked.

regards,

Peter

Maybe it should exit automatically, but I still get the error-message that I mentioned earlier. I have AutoSart checked, and that part is working oke. Anyone else with Vista who has the same experience?

Bert

Link to comment
Share on other sites

Can you explain how the script file is used ...

At the time, the script file is still necessary for any multiplayer scenario.

In auto-mode how does CumulusX! decide where to place the thermals?

It's totally random, that's why a scriptfile is needed for multi. I'm considering a new algorithm, which is still "somehow" random, but leads to reproducible results if users have the same time and weather settings. A scriptfile is then not needed anymore.

You mentioned a latitude factor in the lift generation - you might be able to use longitude as well for some simple tweaking (i.e. the lift goes higher in the mid-USA than Europe).

The latitude factor will be a first step towards a plausible thermal generation world wide and season dependent. Still in reality there is a wide range of regional differences. One can look at the landclasses for example, but you know that these are not a reliable base for thermal conditions. In addition, this is likely to be contradictory to multi, because all users may have different landclass files installed. Yet, I have no clue how to extract landclasses from scenery files, even not during flight.

Actually CX! :smiles: adopts already for existing cloud base altitude, and this could also create easily create discrepancies between siumulated weather and thermal behaviour, when extra information is used tot determine lift ceiling (except from blue, of course).

A solution could be to develop the scriptfile approach further to a thermal template approach, forming a sort of thermal database, similar to the slope database, where ambitious thermal designers can create the template for their area of choice, and CX! does the matching with the current weather conditions, time of day and season.

Now we're expert on client data areas (ho ho), for multi-player could CumulusX! get it's settings using that mechanism somehow so you know everyone has the same?

I'm almost sure that we need a firewall forum, then. There is also a lot of software architecture considerations inveolved, e.g. hgow to determine the master source of CX! settings (e.g. the multplayer host, but how to find out?, and how in FSHOST or FSINN set-ups ...)

In creating my missions, (specifically Austrian Soaring - Day 4) I found it quite realistic to make the thermals weaken towards one corner of the task.

I agree, this can be done currently with an appropriately designed script file already. Maybe it's a reason not to go entirely to the template mode.

Im a strong believer that the majority of pilots do just want to "load up and go", and so if your auto-thermals have a latitude/logitude/time sensitivity there is the chance of not needing to provide a user settings control.

Fully agree, so we need a sort of "Fools Button". Yet, for the time being, I'm not sure if it is easily possible, to define a setting that fits to all siutations. As long as a cloud layer is there at least the ceiling is somwhow reasonable. Maybe its good to adapt the default settings somewhat. I personally find it pretty difficult to handle the pretty narrow lift conditions.

Maybe it should exit automatically, but I still get the error-message that I mentioned earlier. I have AutoSart checked, and that part is working oke.

Okay, I think I got it. The problem is, that the connection to FSX is no longer existing, when CX! receives the quit signal from FSX. Still it tries to restore FSX default conditions, which causes the error message. After that the callback function exits immediately and the rest of the code, including the exit command is no more executed, which leaves the (funny) the program alive.

Expect a solution in the next release.

regards,

Peter

Link to comment
Share on other sites

still "somehow" random, but leads to reproducible results

Makes sense - i.e. pseudorandom. I'm assuming there would be some function defining the placement of all the thermals within a certain area, but I'm unsure how you code decides to spawn 'new' thermals (or are the position of all thermals fixed and an apparent 'new' thermal is a pre-defined object that has cycled into its 'active' phase?)

I'd have thought the placement of all the thermals could be a pseudorandom function based on date and the lat/long of a corner of whatever bounding box the thermal area is in (e.g. lat, long as int if you populate 1-degree rectangles at a time). If the status of the thermal within its time-cycle is a pure function of the user time, the thermals would be reproducible even after a 'flight save' and reload. Two users with the same date/time and flying in the same area would have the same thermals at the same points in their cycle.

What functions do you use for the distribution of lift between ground and cloudbase for a thermal, and the cross-wise distribution of lift across the thermal ?

Best wishes,

Ian

Link to comment
Share on other sites

Hello,

find the most recent version 0.92 at my homepage.

Exerpt from the readme:

// 0.85 Not released AutoStart feature implemented

// 0.9 Not released New User Interface, major code overhaul, integration into FSX menu

// 0.91 11.01.2008 Interface to b21_sim_probe for real-time ridge extraction

// 0.92 20.01.2008 AutoThermal timing region and season dependent

What's new in Version 0.92 (since 0.82)

AutoThermal duration and, to some extent, strength is now depending on the latitude and season. The major factor is the sun irradiation angle and an approximation of the accumulated sun irradiation. There is currently no evaluation of the type of terrain, so you will still have AutoThermals over open sea and great lakes.

The previous version produced an exception, when FSX was closed. This was fixed.

CumulusX! has now an AutoStart feature, which allows to start up and connect CumulusX! automatically with the help of an appropriate EXE.xml file in FSX configuration folder.

The user interface was redesigned to some extent, to give more influence on the effect of the various lift contributions. In addition, CumulusX! implements a simple menu entry in FSX to allow few basic commands.

An interface to the tool sim_probe from Ian Forster-Lewis was implemented, which allows extracting ridge lift conditions from FSX terrain data base during normal flight without the need of installing a slope data base.

A new compiling configuration was chosen which should improve the compatibility with 64-bit operating systems.

brest regards,

Peter

Link to comment
Share on other sites

Peter,

Installation of 0.92 under Vista and SP2 went well. I have seen the solar features in the debug console, they work well. In winter and fall no thermal activitity (bleu or orange). I'll have to chew so more on that later. And CX! closes now went exiting FSX.

Well done, my man

Bert

Link to comment
Share on other sites

0.92 working great for me on FSX SP2. It starts minimized, and Autostart seems to do what you'd expect, i.e. CumulusX! connects to sim_probe and just starts working. Exits cleanly when FSX closes too. Does Autostart save some config info in a file so it remembers from one start to the next (I'm guessing it must do). If so is it possible to have it remember which boxes were checked and un-checked?

Is there a mode where CumulusX! neither draws the clouds nor creates thermals? I've tried flying with only probe lift checked but the clouds still appear. That scenario could be useful for a ridge soaring mission with just a couple of carefully placed mission thermals. I appreciate in this mode CumulusX! is really LiftX! but if you uncheck AutoThermals as well as 'Script' I don't see the validity of having the clouds.

Re thermal placement, have you thought about streeting? I noticed some clouds appeared to have streeted when I flew this morning but wasn't sure if that was a coincidence. Streeting is likely if wind is above say 14 knots and cloudbase is below 6000 feet, I think.

Thanks...

Ian

**EDIT **

Is there a mode where CumulusX! neither draws the clouds nor creates thermals?
I don't know what I was thinking of because I just unchecked the 'autothermals' box and the clouds disappeared. Somehow I thought this didn't happen... sorry. Ian.
Link to comment
Share on other sites

The clouds are showing up possibly due to the original FSX thermal generation, or at least that's what I'm seeing I think anyway. But as far as which boxes were checked before closing, I would also like to see CumulusX! remember it's last settings.

sf4JC

Link to comment
Share on other sites

The clouds are showing up possibly due to the original FSX thermal generation, or at least that's what I'm seeing I think anyway. But as far as which boxes were checked before closing, I would also like to see CumulusX! remember it's last settings.

Original FSX thermals can be one reason, of course.

I can make the settings sticky. For the moment I didn't, to allow to start with the most versatile conditions, and to avoid to confuse nen-technical people with two much settings.

Would you put it into the settings file, too?

regards,

Peter

Link to comment
Share on other sites

Re thermal placement, have you thought about streeting? I noticed some clouds appeared to have streeted when I flew this morning but wasn't sure if that was a coincidence. Streeting is likely if wind is above say 14 knots and cloudbase is below 6000 feet, I think.

Yes, I'm thinking of it. In the same way I would like to start with putting some structure in the widespread sink. My personal experience here is definitely that there is streeting, too, even when wind is not that strong.

regards,

Peter

Link to comment
Share on other sites

Would you put it into the settings file, too?

regards,

Peter

If I understand you correctly, YES. Your settings files can be used as profiles in the way that FSX lets a person save it's settings files different ways for different situations. I have several profiles saved, one for multiplayer, one for screencapture (video), one for better pics, etc...

Is this what you meant?

sf4JC

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use