'Help' info for the Krasnoff Soaring Simulator!

Download and unzip krasnoff.zip if you want to download your own copy of the Krasnoff Soaring Simulator, or if you can't handle PC zip files, look in the local install section.

Basic steps for the first-time user

Along the top of the screen are a set of buttons labelled 'Practice', 'Day 1', 'Day 2' etc. Select which day you want to fly, and the various panels on the page will be initialised to startup values for that day. Make careful note of the weather briefing, in particular the expected timing of changes in conditions. Each day has different conditions and a different task set, and your starting altitude will be 2000 feet, as if you have just released from tow. If during the flight you forget the assigned task, click the 'show task' button.

After selecting a day, click the 'Hunt' button to hunt for a thermal. This button gives you a very low cross-country speed but improves your chances of finding a thermal. As you haven't started the competition task yet, the cross-country speed doesn't matter and you simply want to climb to cloudbase prior to starting. As you 'hunt' you'll see the time counting forwards and your altitude reducing.

When you are offered a climb, either accept it by clicking the 'Climb' button, or continue looking for another thermal with the 'Hunt' button. Perhaps the simplest thing to do is to accept the first climb you are offered and climb to cloudbase.

When the climb reaches cloudbase, the climb will stop and the simulator will wait for you to hit a 'Cruise' button to continue. First, hit the 'Start Task' button to call a start. Then, click the 'Cruise 80' to set off on track at 80 knots. The altitude will count down as your distance counts up, until you reach the next thermal. As you are cruising, you can select another cruise speed mid-cruise by clicking on the appropriate 'Cruise' button. Hence you can fly at 90 knots down to 2000 feet, and then select 60 knots while you pray for a thermal. If things look really bad (e.g. you're under 1000 feet) click the 'Hunt' button - your chances of finding a thermal are increased, but your progress on track is very limited.

Essentially, just like gliding, you now continue in a climb-glide-climb-glide manner until you've reached the goal. The simulator will call 'Good Finish' when the distance shown reaches the task length set for the chosen day, or will give 'Landed Out!' if you get low and don't reach the next thermal.

Becoming a competitive pilot: additional techniques

The idea is that competition flying techniques used in real flying should improve your cross-country speeds in the simulator. These include the following:

  1. Cruise at speeds appropriate for the expected next climb. The simulated aircraft is a Schleicher ASW24 flying without water ballast, so with climbs around 3.5 knots you should cruise around 80 knots.
  2. Pay attention to the weather briefing. The task briefing given when you select a day includes an overview of the expected weather. Note when lift is expected to be stronger or weaker and select cruise speeds and conserve lift appropriately.
  3. Be aware of the effect of wind. A climb taken in a headwind is much more expensive than one taken in a tailwind. You should aim to go around downwind turnpoints high, and into wind turnpoints as low as you dare. As in real flying, into wind legs take an age to complete, while downwind legs fly by. Final glides are similarly affected.
  4. Select your start time. Aim to get most of the task into the strongest part of the day.
  5. Fly at the appropriate speed for your height. Cruise at the correct speed-to-fly speed until you get uncomfortably low, then progressively select slower cruise speeds until you get a decent climb (or land out...). In other words, don't fly at 90 knots into the ground, and don't select 60 knots at 5000 feet.
  6. Don't take too many thermals. Centering in a thermal wastes time. The simulator models this by adding 30 seconds to the clock as you enter the thermal, which penalises pilots who stop in every thermal. If you fly through the thermal, you still get the pull-up benefit, which is 20 seconds of lift at 60 knots, and proportionately less for higher cruise speeds.
  7. Finish low. Any height you have at the finish is time wasted climbing earlier in the flight. Aim to finish around 100 feet. If it looks like you'll finish with a few hundred feet in hand, speed up by selecting the 'Cruise 90' or 'Cruise 100' button.

Simulator description - how the simulator works.

The simulator is implemented entirely as HTML and JavaScript, in a set of source files which are freely readable and copyable. In fact you can copy these files to your local PC and run the simulator entirely locally.

  1. 'krasnoff.html'. This is the 'homepage' of the simulator, which does little other than define the two frames in the top and bottom halves of the browser window and load the program ('k_prog.html') in the top frame and the first 'day' page ('k_day0.html') in the bottom half.
  2. 'k_prog.html'. This file contains the entire program and data tables for the simulator, and is permanently loaded into the top half (frame) of the browser window. When you click on a day selection (radio) button, the associated 'day' page is loaded into the lower frame. While the simulator runs, the program outputs messages (as html) into the lower frame.
  3. 'k_day0.html' through 'k_day7.html'. These are the 'day' files giving the descriptive text and setting the parameters for the given competition day. More detailed information is given below. Note that the simulator ('k_prog.html') simply loads this page into the bottom half of the browser, picks up the parameters defined within the file, and then has no further need of the day file. In fact the simulator overwrites the contents of the lower frame with the ongoing flight status messages.

It is worthy of note that the simulator doesn't contain any 'special' rules for the behaviour of the glider other than a table containing the sink speeds at various cruise speeds (see the polar table). To simulate a different glider or the carrying of water ballast only the polar table need be altered.

The simulator maintains three particular pieces of information as you proceed around the task:

  1. Your current distance around the task. Task completion is when your current distance exceeds the set task distance.
  2. Your current altitude. A 'land-out' occurs when your altitude reaches zero, and climbs go to a set maximum altitude associated with the current conditions.
  3. The current time. Your speed is calculated using the current time versus your start time, and some events (see the events section) such as a change of conditions can be triggered at a certain time.

The simulator repeatedly makes a random selection at check points in the flight:

  1. When a 'cruise' is first selected after a climb: for the distance fly to reach the next thermal.
  2. When a thermal is reached: for the strength of the thermal.
  3. When 'Hunt' is selected: for the strength and distance of the thermal.

In both cases, the values are looked up in the 'current conditions' table. The look-up is implemented by generating a random number between 1 and 20 (in effect throwing a dice with 20 sides) and using that number to look up a lift strength or distance in the appropriate table. The simulator currently has tables representing six sets of conditions defined (0=normal Cu, 1=strong Cu, 2=over-convected, 3=blue, 5=weak, 5=weak-blue), given in the conditions tables below.

The current table to use is given by a variable in the program called 'current_conditions', and this value can be changed during the flight to simulate changing weather conditions. When and how this value should change is defined in the day file (e.g. 'k_day1.html'), so different days can be defined with different tasks and conditions without having to alter the actual simulator. A description of the key values defined in the day file is given in the day file section of this page. The simplest day file need not select a new conditions table at all, so conditions remain on 'type-0', i.e. normal Cu, throughout the flight. For a more complex day, the conditions can be changed at a certain time or on reaching a certain distance.

How pull-ups in thermals are simulated

One parameter setting the conditions as you fly around the task is 'thermal_width' in feet, with most conditions setting this at about 1000 feet. The simulator assumes you straight climb for this distance. The climb rate is the netto strength of the thermal you've just entered minus the minimum sink of the glider. The time spent climbing in a straight line is calculated as the time taken to fly the 'thermal_width' distance at a speed taken as the average of 60 knots and your most recent cruise speed. Pull-up height is then 'climb rate' times 'time spent climbing'.

If you fly at 60 knots, in a glider with a min sink of 1 knot, and enter a thermal with a netto strength of 4 knots and thermal_width of 1000 feet, you pull-up will be calculated as follows:

Average speed through rising air = 60 knots (=100 feet per second).

Time to fly across lift = 1000 feet crossed at 100 feet per second (=10 seconds).

Climb rate of glider = 4 knots (netto) minus 1 knot (min sink) = 3 knots (=300 feet/min, 5 feet per second).

Pull-up height = 10 seconds times 5 feet per second (=50 feet).

Hence the following will improve your pull-up height:

  1. Fly a glider (e.g. ASW-22) with a lower minimum sink.
  2. Fly into a stronger thermal.
  3. Fly more slowly (down to 60 knots min).
  4. Fly in conditions with wider thermals.

Note that the simulator is not simulating the speed-versus-height tradeoff as you decelerate into the thermal, nor the reverse trade-off as you exit it, as these should mostly net out. I guess I could do an altitude adjustment based on speed change each time you enter/exit a thermal or select a new cruise speed. Later, maybe.

Specifying the task and conditions in the day file

Please note that the conditions tables have been modified since this was written, but the principle remains broadly the same. The conditions tables now contain netto climb values, and the actual climb of the glider is calculated from the thermal value minus a sink value for the ballasted glider. To keep the day conditions similar to those planned below, I upped the values in the table from those given below by approx 1 knot, so the true climb (netto minus sink rate) remains about the same. Also each condition also has a 'thermal_width' parameter, which affects pull ups (see above).

For this section you really need an appreciation of the basic structure of a web (html) document, and ideally a basic understanding of web page scripting (JavaScript). I really do mean basic, though, so you should get the idea even if you don't have that knowledge.

Each 'day' page is loaded into the bottom half of the browser when you click the day selection button. You can 'view source' of the day page by right-clicking on the newly loaded day description and selecting 'view source' on the mouse menu. You will see that the day page is just text, marked up for the browser fomatting, plus a header section giving the parameters defining the page.

In the day file, you define all the parameters (key-values) associated with the day, plus the welcome text which appears when that day is selected. The key-values are given as the values of a set of variables in the 'head' section of the web page (between SCRIPT tags) while the description of the day is given as the main 'body' of the page.

Here is an example of the the key-values defined in a typical day page ( 'k_day0.html', you can open the page, ignore the errors, and 'view source').

var task_length = 302; // DEFINE YOUR TASK LENGTH (in km) HERE
var tp = new Array("Gransden","Didcot","Leicester");
var leg_length = new Array(90,130,82);
var leg_wind = new Array(10,2,-8); // head (pos) / tail (neg) wind
var events = new Array("general,time,13:00,conditions,1", // stronger
                       "general,time,14:20,conditions,3", // blue
                       "general,time,14:50,conditions,5", // weak-blue
                       "special,distance,80,100,conditions,2"); // over-convected

These five items, with the associated 'conditions' data in the simulator (see below) completely define the characteristics of a particular day, and each item is explained in the following sections.


Here you define the overall length of the competition task in kilometers. The simulator will load this figure and continually compare your achieved total distance with this figure to establish whether you have completed the task.


In this array (don't worry about the format if you are not familiar with JavaScript), you can put the text names of the turnpoints (omitting the finish, which is assumed to be the same as the first tp).

note: the simulator currently does not us these values... I'm thinking of improving the 'distance-to-next-tp' field with the actual name of the turnpoint.


In this array the length of each leg of the task (which have to add up to task_length) is given. While the simulator fundamentally keeps track of total task distance flown, this data can be used to simply calculate the 'distance-to-next-tp' figure, and to change the headwind/tailwind according to the current leg you are flying.


This array give the headwind(+) or tailwind(-) on each leg, in knots. This figure is subtracted from the cruise speed to give penetration speed during cruise, and is used to adjust the distance flown with drift while you are thermalling.


Now here is the complicated piece... this simulator is a computerized development of a card game created by Peter Krasnoff, in which the next thermal or distance flown is truly random. The first version of this simulator generated the 'next thermal strength' or 'next cruise distance' by generating a random number between fixed bounds. For example, 'next thermal strength' was generated as a random number between 1 and 8, and this meant you would fly along with 1 knot thermals one minute and possibly 8 knot thermal the next. This was too random to be realistic, and so the 'conditions table' was created, in which the random number was used a a 'seed' to point into a table to look up the thermal strength or cruise distance.

The first simulator had one, fixed, conditions table. The results of a simulation were surprisingly realistic, especially when wind was added. The values in the table could be simply adjusted to model a realistic distribution of thermal strengths (or in another column, cruise distances) found on a typical flight. For typical (good) English conditions, I bunched the values around 3.5 knots, with some weaker thermals thrown in and a smaller number of stronger ones. If you disagree with the values given, you can edit the table to something you are more happy with. At any rate the technique is far more controllable than the simple generation of a random thermal strength between set bounds.

Having the conditions defined in a table meant that the conditions could be changed simply by loading a different table, but the less simple issue is how to trigger that change in the simulator. Also, the change in conditions should be specified somehow in the 'day' file, so that many different setups can be stored representing different competition days.

The changing conditions are defined in the 'day' file in the 'events' array.

var events = new Array("general,time,13:00,conditions,1", // stronger
                       "general,time,14:10,message,Looks stronger ahead!",
                       "general,time,14:20,conditions,3", // blue
                       "general,time,14:50,conditions,5", // weak-blue
                       "special,distance,80,100,conditions,2"); // over-convected

The simulator always starts with conditions type-0, and the example above defines 4 events:

  1. At 13:00, conditions type-1 (see below) will be loaded. This will have the effect of cloudbase rising to 5000 feet, the thermals becoming closer together, and also lift improving.
  2. At 14:10 a message "Looks stronger ahead" will pop up.
  3. At 14:20 hours, conditions type-3 will be loaded.
  4. At 14:50 hours, conditions type-5 will be loaded.
  5. When the distance flown is between 80km and 100km, conditions type-2 will be loaded.

Each event is defined as either 5 or 6 fields, representing the circumstances under which the event should be triggered and the action to be taken when the trigger occurs.

There are (currently) two types of event, general and special, given as the first word of the string defining the event. A general event occurs once when the associated circumstances are met, e.g. in the example above the conditions are changed to type-1 as soon as the current time passes 13:00, and no further action will ever be taken associated with that event. A special event is slightly different: the associated action can be thought of as applying between the two limits set in the event. After the second limit is reached, the associated parameter reverts back to its value before the event was triggered. So a special event changing conditions can be thought of as two events: one to set the new conditions, and one to revert back to the previous ones.

A 'general' event triggered by time is a good way of systematically changing the conditions during the day, i.e. you create a set of events to change the conditions at 1pm, 2pm, 4pm, 5pm etc.

A 'special' event can be used to set up certain conditions (e.g. spreadout) on a particular section of the task by using a 'distance' trigger around the distance of the tp (maybe 10km either side).

There are (currently) two parameters which can be measured to trigger an event, time and distance. Time is specified in hh:mm, and distance in kilometers. For example, when the current distance exceeds the value given in a general distance event, the associated action will be triggered. The event will then be flagged to prevent it being triggered again.

There are (currently) two permissible actions, namely to pop up a message or to change the current conditions. It wouldn't be difficult to define some more actions, e.g. to have an area of sink, but I haven't got around to that.

Hopefully it is clear that you specify a 'general' event with five fields in total, separated by commas: 'general', 'time' or 'distance', trigger-value, 'message' or 'conditions', message-string or conditions-type. A 'special' event is similarly specified except with an additional 'trigger-value' field to indicate when the event should no longer apply.

Note that when you define the events, a suitably worded description of the task needs to be written in the 'body' part of the day file. This is the bit that the user actually gets to see.

The various data tables used in the simulator

The polar data for the glider (ASW24, dry)

When you select a 'cruise' button, the simulator updates your distance-to-go at the appropriate rate (cruise speed minus headwind) and reduces your altitude at the rate given in this table. This gives the flight performance experienced by glider pilots, of poor apparent glide performance and slow cross-country speed into wind, and long extended glides downwind. I am yet to find out whether a higher cruise speed is appropriate for the last glide of an into-wind leg (I suspect you should) but I may find out through practice with the simulator.

Speed60 knots70 knots80 knots 90 knots100 knots
Sink1.5 knots2.0 knots2.7 knots 3.6 knots5.0 knots

The Conditions tables

At each 'checkpoint' of the simulator (start of cruise, reaching a thermal, clicking 'Hunt') the simulator effectively rolls a twenty-sided 'dice' (i.e. generates a random number between 1 and 20) and uses the result to look up a thermal strength and inter-thermal distance from an appropriate 'conditions' table. Note that the dice is rolled for each of the thermal strength and the cruise distance, so you are equally likely to to get a stronger thermal at a shorter distance or vice versa.

Conditions type-0. Normal Cu. Median 3.6 knots to 4000ft, 9km spacing.

Look-ahead message: Cumulus clouds can be seen in the distance.

Description: The sky is full of good-looking cumulus clouds. Cloudbase is about 4000 feet

'Dice'12345678910 11121314151617181920
Thermal knots0.
Distance km0. 7810111112121214161820

Conditions type-1. Stronger Cu. Median 4.6 knots to 5000 ft, 6.3km spacing.

Look-ahead message: Cumulus clouds can be seen in the distance.

Description: The sky is full of good-looking closely spaced cumulus clouds. Cloudbase is approximately 5000 feet

'Dice'12345678910 11121314151617181920
Thermal knots0.
Distance km0. 444.566.6778 889101214

Conditions type-2. Over-convected. Median 2.4 knots to 4000ft, 13km spacing.

Look-ahead message: The sky in the distance looks over-convected.

Description: The sky has over-convected, with 6/8ths Cu and rapid cycling. Cloudbase is around 4000 feet, and the climbs are harder to find.

'Dice'12345678910 11121314151617181920
Thermal knots0.
Distance km0.71.51.8369 9121212151616 18181820222730

Conditions type-3. Blue. Median 3.6 knots to 4500ft, 13km spacing.

Look-ahead message: The sky in the distance looks blue.

Description: The sky has gone completely blue. Cloudbase is around 4500 feet, and the climbs seem further apart.

'Dice'12345678910 11121314151617181920
Thermal knots0.
Distance km0.71.51.8369 912121215161618 181820222730

Conditions type-4. Weak. Median 1.8 knots to 3500ft, 13km spacing.

Look-ahead message: The sky in the distance has weakening Cu's.

Description: The Cu's look scattered and weak. Cloudbase is around 3500 feet, and the climbs seem further apart.

'Dice'12345678910 11121314151617181920
Thermal knots0.
Distance km0.71.51.8369 912121215161617 171718182021

Conditions type-5. Weak-blue. Median 1.8 knots to 3500ft, 13km spacing. Some long glides.

Look-ahead message: The sky in the distance is blue.

Description: The sky has gone completely blue. Cloudbase is around 3500 feet, and the climbs seem further apart.

'Dice'12345678910 11121314151617181920
Thermal knots0.
Distance km0.71.51.8369 912121215161618 181820222730

Local installation of the simulator

The easiest way is to download and unzip krasnoff.zip, but if you can't handle PC zip files, follow the instructions below.

If you are familiar with downloading web pages from a web site, simply collect all the html pages in this directory and copy them onto your local PC. The simulator is written entirely in JavaScript and will run locally on your PC without change.

If you are less familiar with the process, follow these steps:

  1. Go to the simulator homepage ('krasnoff.html' but don't click on any buttons in the simulator once it's loaded.
  2. From the menubar, click View... Source, then File... Save As, and save the homepage locally as krasnoff.html.
  3. The top half of the page (frame) now contains the simulator program. Right-click somewhere (i.e. not the menubar) in the top half of the page and View Source then Save As k_prog.html.
  4. The bottom half (frame) of the page contains the startup info file. Right-click the bottom half of the screen and View Source then Save As k_start.html.
  5. Now select the practice day at the top of the page, and you will see the description of the practice day task and conditions appear in the lower half of the window.
  6. The bottom half (frame) of the page contains the practice 'day' file. Right-click the bottom half of the screen and View Source then Save As k_day0.html.
  7. You should now be able to run the simulator successfully on your home (or work...) PC by looking at your local copy of 'krasnoff.html' with your browser (click on it in Windows Explorer, but at this stage you have only the practice day file ('k_day0.html') available.
  8. To get each of the other day files, click each day selection radio button at the top of the page in turn, and right-click the bottom half of the screen as soon as the desired day page is loaded and View Source then Save As 'k_dayN.html' where N is the day number.