Yes, by now I came to the same conclusion, after some quick “top left to bottom right” scan of the documentation that I’ve found/read so far.
The most relevant data is in the “B records”, so it could be as simple as “reading position & altitute” (and I guess the timestamp, but not sure yet whether the timestamp is also included in the “B records”, or implicitly given by the “recording interval” in some other record).
I’ll keep support for this format in mind - but no promises made at this point
Btw a better place to request features would be:
(free github.com account required though). Not least because we are not allowed to misuse this forum here as a “support forum” for 3rd party applications (open source or not - so only for “discussing features or getting help from within the flight simulator community”).
Thanks for all your hard work making Sky Dolly, I’m finding it very easy to use and having a lot of fun with it.
Any idea what is causing the jitters yet? Or any tips to reduce them while recording a formation flight?
I have a fairly low spec machine, but can still get decent frame rates if I sacrifice a lot of graphics settings… (40-60+ fps)
I like to keep a nice tight formation in an aerobatic aircraft at around 120kts
The aircraft in focus is always steady as a rock during playback, but ones played back as AI are very jittery. If playing back more than one as AI they jitter at the same time.
I`ve tried a lot of different settings, but nothing seems to make much if any difference.
I have some ideas what might causing the jitter - unfortunately those ideas tell me that I cannot solve this “client-side” (in Sky Dolly). But there is still some idea that I want to try out before I “give up”.
Essentially my theory is that “AI Objects” (technically speaking there is the “user aircraft” which is typically directly controlled by the user. Every other object - aircraft, cars, boats - is spawned as an “AI object”) are updated less frequently than the “user aircraft”, especially when nearby the user aircraft. Or at least in different intervals (in the best case each object should get updated for each “simulated frame”).
What speaks for this theory is that you see all AI aircrafts “jitter” by the same amount (at the same time). Note that the “jitter” is caused by "slightly different movements relative to the user aircraft (respectively the camera, which typically moves along at the exact same speed like the user aircraft).
Another theory is that the precision of the latitute / longitute coordinates (keyword: “double vs float” or 64bit vs 32bit floating point numbers) is somehow less than for the user aircraft, making the AI objects move in a more “coarse way” (note: Sky Dolly receives, stores and sends all position data as double (64 bit) - so if my theory about “loss of precision” would hold then that would somewhere happen along the way of SimConnect → MSFS).
I have also been told that the same “jitter” effect also happens with other flight simulators such as Prepar3D - as MSFS “inherited” quite some code from the common “base” FS X (specifically the SimConnect implementation) that would indicate that this “jitter” effect must be a common problem of “SimConnect” (respectively how (often) the AI objects get updated within the flight simulator).
Again, I emphasise that those are just some vague theories of mine without any hard evidence. And I still want to try out something else (related to interpolation and “smoothening” of sample points). But I cannot (do not want to ;)) give any timeline nor any false hopes here. In fact, I just made some longer “creative winter pause” and just slowly started adding a new feature (which was requested by a user ;)).
Header data (pilot names, glider type and ID, flight date and number)
Tasks (“C records”) which are stored as “waypoints” in Sky Dolly
Position data: latitude, longitude, GNSS altitude (altitude above the WGS84 reference elipsoid)
Note that some flight recorders only sample in very rough intervals (e.g. only every 10 seconds), so while the interpolated flight path is “smooth” it is impossible to properly reconstruct “tight turns” (e.g. when rising in thermal updrafts) with so few sample points, especially the heading (which is “reconstructed” from the sampled positions).
The glider also typically “wildly turns on the ground” just before take-off, due to GPS “signal noise” (this might be amended in a future update of the IGC importer). Another known issue is that the initial altitude rarely matches with the terrain height in MSFS, so the glider starts either way below or above the terrain. This might be amended with a future altitude offset in Sky Dolly.
Today a year ago - on the February 28 2021 - Sky Dolly saw the world of flight simming, in its glorious first v0.1 release on flightsim.to. And exactly one year later the latest Sky Dolly v0.9 has just been released, focusing mainly on new import and export plugins (KML, CSV, IGC, GPX, including variants for flightradar24.com, flightware.com and Flight Recorder).
Also refer to the announcement here in the forum for the detailed new feature set. Here I’d like to take the opportunity for a quick “behind the scenes” overwiew (aka “How time flies!”):
December 22 2020
Shortly before Christmas: “Hmmm, still no decent replay in MSFS? What exactly is this SimConnect everyone is talking about anyway, what can it do and how does it work?”
→ The “initial commit” is done!
February 24 2021
The first “0.1.0” tag was set and the basic feature set concluded: “Basic recording functionality”, including “latitude, longitude, altitude, pitch, bank, heading”.
February 27 2021
Talk about “release early, release often”: already v0.2 was tagged, with additional simulation variables (flaps, ailerons, gear, …) and this version was then released…
February 28 2021
… on flightsim.to (which I randomly decided to be Sky Dolly’s birthdate)
Fun fact: from the very beginning Sky Dolly got the “modulo 180/360” interpolation right: no glitches when the aircraft just crossed the “magic marker” of e.g. 180° pitch up - yeah, “it’s math, babe!”
March 1st 2021
Oh no, the first bug! While I was editing my first David-Monthan Aircraft Boneyard-video I noticed that the flaps were either fully extended or not at all. So the first “fix release” - v0.2.1 - was published.
March 4 2021
And the next preview version, v0.3.0 went out! This time with some very crude, but direly needed, possibility to actually save and load the recorded flight data: the first CSV (“comma-separated values” - although Sky Dolly uses the TAB character as delimiter) import/export was born.
“The glory of open-source”: of course I was looking at other people’s source code (and referred to other open-source projects in the README.md) and quickly learned from projects like the famous Flight Recorder by @NguyenQHy that the SimConnect API offers the possibility to “freeze” the aircraft, and that recording the velocity and acceleration is equally important (besides recording the “raw position” lat/lon/alt) to make “smooth aircraft movements”. Otherwise the simulator would constantly “fight against the imposed position”.
But give and take: I informed Nguyen about the “interpolation glitch” in his code which he then quickly fixed, and the possibility that light states could now be set via “simulation variables” (the light state can be set “in one go”) instead of “events” (one event per light switch required).
March 18 2021
The next “major preview version” - v0.4.0 - introduced "event-based sampling, both for recording but especially also for replay. Gone the awkward setttings to define the replay frequency (in Hz), when in fact it is the flight simulator that dictates the (maximum) refresh rate (“event-based”).
The recording frequency can still be set to the current day, but this is more meant for lowering the sample rate, in order to reduce the amount of recorded data. E.g. sampling an airliner which “flies straight lines most of its time” with just 1 Hz or even less is more than sufficient, due to the interpolation (which for position data is Hermite cubic spline interpolation, for smooth curves).
The Acrobatic Flying in FS 2020 video illustrated the various recording sample rates in two different scenarios (“acrobatic flying” vs “airliner”).
Another “under the hood”-feature - but clearly visible in the “simulation variables dialog” - improves the data efficiency of Sky Dolly even further: the simulation variables are organised into “groups” (position, primary controls, secondary controls, …).
As data is only recorded “once its value changes” this means that most simulation variables do not need to be recorded most of their time. First experiments confirm this: depending on the “flight style” (“airliner” vs “acrobatic flying with disco lights and constantly lowered/raised gears”) savings up to 35% of disk space are measured.
An initial implementation supporting “cold starts” is also released.
May 11 2021
This is the first major release, supporting a fully-fledged database - SQLite - as underlying “logbook” technology! This allows to browse, update and migrate (!) data with the powerful structured query language (SQL). But most importantly: recorded “flights” are now automatically persisted and are loaded with the ease of a double-click.
Talking about usability: not everything is perfect yet (not to say in a very “crude state”, especially “error handling”), but usability and ease of use has always been a primary goal: you want to “fast-forward” during replay? Just do so my sliding the time-slider: no need to “press pause first”. During recording my own videos - like the first Cinematic Teaser Trailer - I very quickly noticed a missing keyboard shortcut or an unnecessary mouse-interaction.
Juny 17 2021
The release cycles are getting longer, but at the same time the new features are getting bigger, too: this time “formation flying” is introduced with the v0.7: it not only allows to replay several aircraft at once, but also to replay already recorded aircraft during the recording of a new flight! So you see exactly where you fly in relation to the other aircraft - and all this with a single user interface, with a single click on the Record respective Play button.
To the current day and the best of my knowledge this is still a unique feature that no other flight recorder offers in that form.
This new formatin flight feature was intensively tested with the New York 1933 video, where 30+ aircraft circle around the iconing Empire State Building (I was desperately looking for a King Kong model for MSFS, but didn’t find any at the time).
However this new feature also revealed an inherent weakness in the “replay AI aircraft” feature: especially when coming close to such AI aircraft they randomly seem to “jitter”, and sometimes also quickly disappear and reappear. I still hope to be able to improve on this, but since other replay software seems to be equally affected this might be an issue within the SimConnect “server-side” (in MSFS itself). To be continued…
July 28 2021
The v0.8 introduced a new plugin-architecture which I had in mind since the very beginning. Not only the import and export functions are now “pluggable”, but also the connection to the given flight simulator as well.
The SQL technology now starts to show its advantages as well: the logbook can now easily be filtered by aircraft, arrival/destination, formation flights, …
Fun fact: Sky Dolly is for a large part developed on macOS (40%) and also on Linux (10%). The other half (rough estimate) on Windows 10. For very obvious reasons I have to implement against a second “SkyConnect” (Sky Dolly terminology) interface, other that SimConnect for MSFS: a “fake interface” which (currently) only produces “random data” during recording. On Windows both those plugins can be exchanged (even at runtime: Sky Dolly reconnects “on demand” with the flight simulator), and - theoretically - opens the doors for future extensions…
August 18 2021
Further “bug fix releases” follow, until on this day the “happy birthday, MSFS”-release v0.8.5 is made available, which also introduces initial KML import support (for flightaware.com files).
“Are many pilots using this recorder format?” But this kept me thinking, and since I had thought about continuing with development anyway, why not start with this IGC format then…
February 6 2022
Another “bug fix” release - v0.8.6 aka “Drop Bear Edition” - introduced the first IGC file import plugin. And now since I knew quite a bit about this simple - but effective - file format, why not write an export plugin for it as well?
February 28 2022 (today)
The current “major” new release v0.9.0 is made available, which besides the mentioned IGC export plugin (and improving on the IGC import plugin as well) provides a range of other import/export plugins and improvements.
I just wanted to say how impressed I am with Sky Dolly. I was looking for a simple, easy to use, basic, robust recorder to allow me to record portions of flights and make videos afterwards using different camera angles etc. In this, Sky Dolly is perfect! I had used a different recording app before but I struggled with the UI, ease of use and stability. When I started using Sky Dolly it was like a breath of fresh air: it really was exactly what I wanted.
I find the UI VERY easy to use and the stability is rock solid. Granted that I am only using the absolute basic, core functionality but in that Sky Dolly certainly excels.
Thanks for a great product: it adds greatly to my enjoyment of MSFS
Thanks a lot for such a useful and easy to use add on !! I experienced it several times already, however, for formation flights, is there any dev news about the “jitter” effect? I remember seeing the same thing with X Plane with similar add on for flight formation … sadly it makes impossible to fly close formation and acrobatic flights
I used to fly on a very old (but still available) flight sim called Ys Flight where you could fly yourself such formation flight, flying every position alone and with replay, as an in game feature. It is working very smoothly! And btw, it allowed me to recreate complete formation flights (all alone ^^) with different acrobatic teams, I still have some videos of such flights on YouTube (search ysfoxtwo)
If it could reach the same smoothness in mfs2020, that would be so great!!!
Thanks a lot for your hard work
I’ve tried both recorder/playback tools and the jitter is always there.
One thing I have noticed is the severity of the jitter depends on the speed, formation proximity and specific aircraft model also. For now even multiplayer is smoother than recorder tool ai playback.
The “jitter effect” really seems to be caused by different “update intervals” (internally in MSFS) by which the “user” and the “AI aircrafts” are updated, causing “relative, small offsets” to each other → visually visible what I and others call “jitter”.
Note that Sky Dolly interpolates the positions of each aircraft upon the notification of the “simulated frame” event (sent by MSFS), and from this point onwards all positions (and attitude, flaps settings etc.) are sent sequentially (for each aircraft) to MSFS. From this point onwards it is up to the “server” (MSFS) how to process those updated “simulation variables” (means: “out of control” for the “client”, e.g. Sky Dolly).
I do still have some idea how this could be improved “client-side” (e.g. in Sky Dolly), and yes, this issue is “still on my radar” (there has been a “winter break” in development and recent development revolved around refactoring the import/export plugin architecture).
But since I cannot exactly tell whether my idea will have an actual effect “server-side” (in MSFS - the flight simulator providing the SimConnect API in general) I cannot make any promises. We will have to see
Sky Dolly v0.10 has just been released, refer to the official announcement here:
While you can do all sorts of (visual) analysis with the exported files - CSV in flightradar24.com format, GeoJSON, GPX, … - sometimes you may want to go a bit more “after the actual numbers”. Perhaps.
So here is a little “fun workshop” about “things you can do beyond the Sky Dolly user interface”. The idea is to dig in right into the logbook, respectively the actual database. Yes, that’s right: the logbook is an actual database - an SQLite file-based database, to be specific - from which you can extract and process the data from… with SQL!
“SQL? Me? But… I am not a programmer!” - okay, okay, let’s define our main goal first: the goal here is not to make you fluent in SQL. Which by the way stands for “structured query language”. You might not even understand the actual examples that I am going to show, how and why they work etc.
The goal here is to give you some ideas what is possible, and if you are interested in learning more there are excellent SQL tutorials out there! After all Sky Dolly is open source, and so is its database format (also known as “schema”) and you may have a brilliant idea what you could do with it.
That being said… let’s start!
The easiest way to “browse a database” is probably by using a (graphical) user interface which allows us to easily “discover” all “tables” (we’ll come to that in a minute) while also offering a way to “execute queries”. I am using the application DB Browser for SQLite, available here:
It is available for several platforms, among them Windows, macOS and Linux. Install the tool to be able to execute the below examples and continue with your own experiments. Otherwise just keep on reading…
So what is the “logbook”? In Sky Dolly it appears e.g. like this:
If your logbook is still empty then now would be a good time to record a few flights first, such that we have some actual data.
How do we find the location of the logbook? That’s easy:
Open File | Logbook Settings…
Click on the Show button (next to the logbook folder path)
The file explorer should open, showing the folder with a file named Sky Dolly.sdlog (by default). You may also have a Backup subfolder already.
Now is also a good time to ensure that we have an up-to-date backup of the logbook. In that same Logbook Settings dialog:
Select Period: Next time, when exiting Sky Dolly
Confirm with OK
Quit Sky Dolly (CTRL + Q)
A backup dialog should now open: execute the backup by clicking the Backup button
Open the Logbook with the DB Browser
In general it is a good idea to access the logbook (database) with only one application at the same time. While it is generally not a problem if we only browse (“read only”) the database with one application while the other one (Sky Dolly) is also writing data you may end up locking one or the other application when both applications try to modify the database at the same time.
So now that Sky Dolly is closed (and we have an up-to-date backup, just in case…) launch the DB Browser for SQLite. While the file extension of the Sky Dolly is *.sdlog (“Sky Dolly Logbook”) it is really an SQLite database file (typically having the extension *.sqlite). And we can open it as follows in the DB Browser:
File | Open Database… and browser to the folder containing Sky Dolly.sdlog or
Simply drag and drop Sky Dolly.sdlog onto the DB Browser
In either case we should now be seeing something like:
I have marked the areas of interest to us in this tutorial:
The Database Structure shows us the elements of the database, most importantly the “tables”
We can browse the data of any given table in the Browse Data tab
Finally we can execute our own SQL statements in the Execute SQL tab
SQL - A Primer
The goal here is to get acquainted with the basics of databases and SQL, essentially in order to be able to execute and “follow the idea” of the upcoming examples.
Table - a table is the most important object in a database: it allows us to organise our data. For instance you may have a table containing persons (name, familiy name, birthdate, …), and a table listing all possible hobbies in the world (hobby name, …), and yet another table linking the persons with one or several hobbies (person, hobby)
Entries in those tables are also called records. Each record typically has one (or several) “identifer” - or ID in short - which uniquely identifies that record in the given table
A record may also “point to” another record in another table. For such a “1 : n” relationship this is typically done by simply storing the “foreign ID” in the table as well (we will see this with a practical example below)
SQL - the structured query language is a standardised language which allows us to select (and also update - but we deliberatley won’t cover this here) one or several records, either from one or possibly multiple tables (the data from the various tables is then joined).
The most important concept in a SELECT statement is the WHERE-clause which allows us to define one or multiple selection criteria (“Get me all the data having the following attributes…”)
The second most important concept is the FROM clause which specifies the involved tables from which we want to query the data
In short, the SELECT … FROM … WHERE … is the “skeleton” of the majority of all SQL queries out there
Sky Dolly - Most Important Tables
Before we start with an actual SQL query let’s get a bit familiar with the Sky Dolly specific tables. Still on the Database Structure tab in the DB Browser we see all tables that Sky Dolly is using. The most important ones:
flight - contains common data such as creation_data, title and description of each recorded flight, as well as initial ground altitude (of the airport), visibility and other weather related conditions
aircraft - contains the flight number, airline name, tail number and a few other “static data”
position (and similar tables) contain the actual recorded position data (latitude, longitude, altitude) and velocity
A couple of “house keeping” related tables, but we won’t look into those in this tutorial
Browsing the Tables
We now switch to the Browse Data tab in the DB Browser. Note that I tend to CAPITALISE table and column names, for readability. There are different “SQL style guides”, but for all practical matters SQL is case-insensitive. So if you see me writing “id” instead of “ID” - that’s just me being inconsequential, but it means the same thing (column).
In the Table dropdown list select the FLIGHT table
Does this look familiar? Yes, it resembles the Logbook in Sky Dolly itself. In fact, that is the table the Logbook in Sky Dolly is querying its exact data from. And we take note that the table ID is the exact same “Flight” number in Sky Dolly (the first column in the Sky Dolly logbook table).
We may repeat this browsing with the following tables:
AIRCRAFT - contains “static aircraft data”
We note that besides the (unique) ID for each aircraft each record also contains a so-called “foreign key”, or ID, referring to another table. Here, the previous FLIGHT table to be specific. And the key (or identifier) is called FLIGHT_ID - do those numbers in that AIRCRAFT.FLIGHT_ID column look familiar? That is because those are the exact same IDs that we have seen in the previous FLIGHT table already (and in the Sky Dolly logbook).
If you have ever recorded a formation flight - a flight with multiple aircraft - then you may find multiple aircraft having the same FLIGHT_ID. Well, that is exactly because they “belong” to the same flight (as stored in table FLIGHT). In order to distinguish those aircraft for the given FLIGHT ID each aircraft additionally as a sequence number (column name: SEQ_NR).
All other AIRCRAFT columns should be self-describing.
Lastly, let us have a quick look at one of the tables which contains the actual sampled data:
POSITION - contains the recorded positions and velocities
The columns mostly reflect the corresponding “simulation variables” as received via the SimConnect API from MSFS (including some data transformations, in order to reduce storage space where applicable).
All data tables have the TIMESTAMP in common, which stores the point in time in milliseconds the data has been recorded (“sampled”) since the beginning of the recording (of the given aircraft). Speaking of which: the position data always belongs to a given aircraft (as stored in table AIRCRAF), again identified by column AIRCRAFT_ID.
But wait - why isn’t there a unique identifer, a column named ID (in table POSITION, and also the other “sample data tables” like ENGINE etc.)? Well, there is a unique identifier already, and we just stumbled over it already: it is called TIMESTAMP! Yes, each position data (and each engine data…) has a unique timestamp (as a consequence, if MSFS sends us multiple values for the same timestamp then “the last one wins”: existing entries are then simply updated) - so the TIMESTAMP also acts as a unique key to identify each data record.
Okay, enought gray theory about tables, keys and foreign keys… let’s finally try this out!
Querying All Flights
We now switch to the Execute SQL tab in the DB Browser.
Type in the text editor the following SQL query:
Again, SQL is (mostly, depending on the underlying dabase) case-insensitive, so the following statement is the same (you will see this kind of CAPITALISATION in many SQL tutorials):
Any combination (CAPITAL SQL keywords, lower-case table names and vice versa) will also work. I will stick to lower-case for now.
We could also write the whole query in one line:
select * from flight;
but especially with the addition of more complex WHERE-clauses distributing the SELECT, FROM, WHERE clauses onto multiple lines is common practice and makes the queries more human-readable.
Now execute this statement by either:
Press the Execute all/selected SQL button in the toolbar above (the button has a “play” icon) or
Select the entered statement and press CTRL + RETURN
In both cases you should see the same result set as we have already seen with the database browser on the previous Browse Data tab. So not very exciting, huh?
Before we continue, let’s have a quick look back at what we actually did here:
SELECT - we selected all columns, as indicated by the placeholder symbol *
FROM - we simply indicated the table name (in this example just one), the table from which we want to read the records
Every SQL statement is terminated with a semicolon ; (especially important if we have multiple SQL statements that we want to execute “in one go”)
Select Some Flights Only
Now let’s say we only wanted the flights where the DESCRIPTION column contains the word “Zurich” (case-insensitive, so we convert all values to lower-case). And we are also only interested in the flight ID. CREATION_TIME and DESCRIPTION, so let’s try this:
select id, creation_time, description
where lower(description) like '%zurich%';
You can either enter this second SQL query below the first one and then select it before pressing the “play button” (or press CTRL + RETURN), or simply clear the previous statement (then you don’t have to worry about first selecting the SQL statement(s) to be executed).
In my case I get for instance:
A gorgeous city at the lake Zurich. Go and visit the Grossmünster church, the town’s landmark with its twin towers.
Landing on the lake of Zurich
If you are getting an empty result set back then this is because none of your flight descriptions contains the word “zurich” (or “Zurich”, “ZURICH”…). Try with another keyword then.
What did we do?
the command lower() converts all letters to lower-case, so e.g. “ZURICH” becomes “zurich”
The comparator like does a “fuzzy comparison”: with the help of the “placeholder” percentage symbol % it essentially checks whether the given sentence contains the given value (taking the placeholder values into account)
LIkewise we can also select all flights were the initial visibility (at take-off) was very low, say less than 2000 meters, like so:
from flight f
where f.visibility <= 2000;
Again, whether you receive any fllights at all depends on your actual data. You may adjust the 2000 meters, or do a “greater” test with > etc.
What did we do?
There are many different ways to compare data with each other, the most common ones include <, <=, =, >, >= and LIKE
I also introduced an alias for table flight, by simply calling it “f”; this becomes very useful once we start joining data from multiple tables (which may have columns with the same name, especially ID columns)
But by using an alias (which can really be anything, but here is simply used the first letter of the table name) we also get “auto-completion” in the DB Browser SQL editor - nice!
Now we’ll ramp up the complexity just a little bit, by querying data from multiple tables. I won’t go into the various inner, outer, left and right joins etc., that is something if you really want to dig deeper into SQL. But essentially this is all about set theory in the end.
In this example we want to list the (all) aircraft belonging to some given flight, identifed by its flight ID (in my example I am using ID 51 - choose any existing flight ID in your example). Let’s also assume we want to have the flight ID, TITLE and the aircraft TYPE (e.g. “Pitts Asobo”) and its sequence number SEQ_NR (only).
Let’s jump right into it:
select f.id, a.type, a.seq_nr
from flight f
join aircraft a
on a.flight_id = f.id
where f.id = 51
Each existing flight always has at least one aircraft, so if you choose an existing flight ID (here: 51) you should get at least one resulting row.
What did we do?
We joined tables FLIGHT (with chosen alias f) and AIRCRAFT (with chosen alias a)…
The default join method is an inner join (we could make this explicit by writing also INNER JOIN instead of just JOIN) - but again, the join-topic is beyond the scope here
… given a join condition, defined in the ON clause, specifically: “Select all flights and aircraft where the aircraft foreign key - as stored in column A.FLIGHT_ID - matches the corresponding ID of the flight (as stored in its column F.ID)”
This joined data alone would return way more rows than what we have asked for (essentially all flights, with all their aircraft)
So now comes the WHERE clause with which we “filter out” the joined data set, and we essentially say: “From all this joined data only return those records where the FLIGHT.ID equals to 51”
In my example I get:
With SQL and the relatively simple Sky Dolly DB schema you can already extract a lot of data. Note that you can also extract the result set as CSV data, for further processing (visualisation) in e.g. a table editor like Excel or Libre Office Calc and the like.
If that has raised your interest in “datamining” then here are a few more things you could try:
Try joining three tables, e.g. FLIGHT, AIRCRAFT AND POSITION (remember: POSITION.AIRCRAFT_ID associates the sampled position data with the given aircraft, identified by its ID)
Try finding all flights which took off at night (take-off e.g. between 9 and 11 PM)
Try finding all flights where the highest altitude is over 30’000 feet (hint: this goes beyond the toolset we have discussed above, but has a hint: you will probably need the MAX() function
Here are some resources that might help you going with SQL:
SQLite Tutorial - The SQLite documentation provides a surprisingly good SQL tutorial (with some specifica to SQLite) as well
There is a neat little thing that may be useful for photographers: automatically GPS-tagging your screenshots taken during a flight recording. The actual GPS tagging of the screenshots (“photos”) is to be done with an external photo application of choice, but the essential workflow is:
Export the flight as GPX, with “Recording (real-world) time” timestamps
Import the screenshots: make sure to preserve the original file creation timestamp
Import the previously exported GPX file (“track”)
Automatically GPS-tag the photos
Here is how this could work in detail:
In Sky Dolly, load a flight (by e.g. double-clicking on a flight in the logbook)
Choose File | Export | GPX
Now for the Timestamps option select Recording (real-world) time
The exported GPX track then contains the actual real-world timestamps (converted to zulu time), and not timestamps based on the simulation time. Why is that useful? Because now the photo application can make a correlation between the creation timestamp of the screenshot file and the corresponding GPS coordinate.
Note that resampling the recorded flight data with 1 Hz (“one sample per second”) should give us a good precision when it comes to geolocating the corresponding screenshots, but of course you may also choose 1/10 Hz only (“one sample every 10 seconds”) or - if you are flying with a very fast aircraft and precision is everything - choose 10 Hz, or even “Original data” (if the recording frequency was kept at “auto” this gives you up to 60 Hz sample rate, depending on your actual frame (simulation) rate).
However most GPS tagging algorithms interpolate anyway between the GPX track points, so again: 1 Hz (or even less) resampling rate is a good choice for our purpose here.
We now switch to the photo application of choice, import the screenshots (again, pay attention that the original file creation timestamps are preserved) and load the GPX track:
The GPX timestamps are always Zulu time (= UTC+0). Depending on the photo application the application may assume that the timestamps of the screenshot files are also in the same UTC+0 (“Zulu time”) timezone. However since the file creation timestamps refer to your local timezone (as set in the operating system) the timezones most often do not match (unless you happen to live in an UTC+0 timezone).
So in most cases we need to adjust the timezones of the screenshots:
Now we could spin this further and - with the help of the appropriate tool - export the photos in KML format, in order to show then “geolocated”, e.g. in Google Earth. Even in combination with the actual flight path which Sky Dolly can directly export as KML. You get the idea
Sky Dolly can export your flights in GPX format. By setting the timestamp format to “Recording (real-world) time” the exported GPX track data may be used to automatically GPS-tag your screenshots, with the help of the photo editor of your choice.
That’s it! Sky Dolly takes care that all your recorded aircraft get properly persisted in the logbook and that they are associated with the same flight.
Granted, you need to switch to the formation module first. But the cost of this extra mouse click (or the F2 key) is quickly amortised as you keep adding more and more aircraft to your formation flight. Again, simply press the record button for each aircraft to be added to the formation.
And the best thing: all previously recorded aircraft are replayed while you are recording the current aircraft. So you know exactly where you fly in relation to all the other aircraft in the formation.
The formation module also lets you choose the initial position, relative to the current user aircraft in the formation. Each aircraft can be assigned a time offset: this is useful in case the aircraft were recorded on different computers (“multiplayer formation flight”) and each pilot pushed the Record button at a slightly different time.
Replaying all your recorded aircraft is equally easy:
Just press the play button (or press the space key)
This works regardless of the selected module (also in the logbook module). All aircraft will be controlled by Sky Dolly - a single instance of the application, that is. And no need to load dozens of files first: a double-click on the flight in the logbook, and all your aircraft are ready to fly. Again, with the same ease as you would replay a single aircraft.
The logbook module also lets you:
Choose the current user aircraft (the one being followed by the camera in MSFS)
Choose different formation replay modes:
Formation - Sky Dolly controls all aircraft
Take control of recorded user aircraft - you take manual control of the recorded user aircraft in the formation
Fly with formation - you keep control of your current user aircraft in MSFS and fly together with all recorded formation aircraft
The later mode also works with a “formation” consisting of only one aircraft, or in other words: you can interactively fly together with any previously recorded flight, no matter the number of recorded aircraft in that flight.
Of course you can switch the user aircraft and replay mode at any time during replay. No need to first pause/stop the flight or - oh beware - reload the flight anew. Sky Dolly tries its best not to stop your creative flow.
With all this the following scenarios are possible:
Watch your recorded formation flights
Race against yourself in a “race course”
Create formation flights of community “formation flights” (recorded on different computers - exchange the flights e.g. via the CSV import/export)
Create phantastic cinematic videos
Also noteworthy: there is no limit of how many aircraft Sky Dolly can record in a given formation.
One of those cinematic videos I’d like to share with you, shared with kind permission from TechnicAl, the creator of this phantastic video:
A nice touch: he also placed some of the “static aircraft” on the ground and recorded those as “formation”. A simple, but very effective idea
Thank you for this recommendation. I have just added it to my README, under “related work”.
Yes, I agree: geotagging photos with a GPX path is very old-school and wasn’t meant at all as a “primary functionality” of Sky Dolly. It is merely a “by-product” of being able to export the flight path into GPX, and by allowing to set the time stamps to the actual recording time (instead of the simulation time) it allows to use the workflow as described above.
By the way, that reminds me of my first GPS recording device: a physical device with an SD-card reader, a tiny LCD screen displaying the current GPS coordinates and some cryptic symbols, and two or three buttons (with other cryptic symbols). It essentially allowed to record the GPS path, and once done so you could insert an SD-card with JPEG photos (which were hopefully backed up elsewhere already ;)) and by the push of a button (or rather: a “secret combination” thereof) it would then geotag all JPEG photos found on that SD-card.
In theory anyway. In practice it either didn’t record the GPS path at all, it wiped it instead of geotagging the photos (because you pushed the wrong button sequence), it failed to read / write the JPEGs for other reasons (I also think there was a size limitation of 2 GB for the SD-card, which already for its time was abysmal) and once I figured it out (given the small instruction leaflet which must have been “machine translated from Chinese”) it turned out that the device gave up after only one hour or so due to empty batteries
The device cost me like 80+ EUR at the time! After this bloody experience I purchased an app for my mobile phone for like 5 EUR which did the exact same job, just like 1000 times better (the tool was even able to “geotag” photos lying on some network share, so one didn’t even have to copy the photos “into the app”).
But at least for photography all this has become moot since even DSRLs have built-in GPS receivers in many cases, not to mention all mobile phone cameras.
Anyway, there you have it: GPX paths exported from Sky Dolly, suitable to geotag your screenshots, especially if you want to use a specific screenshot utility (other than the proposed tool) - or use the GeoShot tool you’ve just proposed
Note that this is a fully functional Sky Dolly interface, even allowing you to record formation flights. Simply switch into the Formation module first (key F2), enter the minimal UI mode (key M) and keep clicking on the record button, and the aircraft get added to your formation.
And of course all your flights and aircraft still get automatically persisted in the logbook (which keeps working in the background, of course). Reduced to the max.
It does not get simpler than that!
Minimised RAM Usage
Sky Dolly now only allocates resources (e.g. for dialogs) on demand, and immediatelly releases them after use (instead of only at the end of the application). Like this the RAM usage could be reduced even more, especially when launching the app in the minimal UI mode (the choice gets remembered in the application settings).
Here is the absolute RAM usage (in Megabytes [MiB]) just after application launch, compared to the previous Sky Dolly v0.10 and to other replay applications:
One of the nicest rewards as a software engineer is when you see your users actually enjoy the application you are developing.
Like Luna who demonstrates the usage of Sky Dolly in the following video, shared here with kind permission of the author:
The video illustrates:
The simple way to record a flight, including automatic persistence in the logbook
The intuitive way to seek back and forth in the timeline, also at any time during replay (without first having to press “stop” or any other button)
The correct deployment of e.g. the flaps and starting / stopping the engine at any time during seek
The usage of Sky Dolly starts at the 2:06 timemark where Luna starts recording a roughly six minute flight. Recording is stopped at the 8:18 timemark which also immediatelly persists the flight in the logbook (searchable by date, engine type, departure & arrival and other keywords).
But the feature that gets the most exciting reaction is the smooth seeking on the entire timeline (timemark 9:58) . Again, at any point during replay, whether paused or stopped. Quote:
“Look! How smooth… it is insane! How does that… how can they do that?”
Well, I can give the answer to this question: Sky Dolly uses a simple binary search, extended to an interval search (instead of a simple value), where the time interval is given by the previous and next timestamp of the corresponding sample points.
A binary search essentially always halfes the search space, resulting in a so-called O(log n) runtime behaviour, where n is the number of sample points and the logarithm is base 2. Example: when n = 1024 (number of sample points) the binary search finds the proper interval in log(1024) = 10 seach steps in the worst case (instead of 1024 steps in the worst case for linear search).
And Sky Dolly doesn’t stop there: once the proper time interval has been found the actual position of the aircraft is interpolated with cubic spline interpolation - for this extra smoothness.
All this is even more remarkable considering that Sky Dolly does only sample data when the values actually change. This saves both disk space and CPU usage, as - by implication - Sky Dolly only sends requests to MSFS during replay as needed (again, only the data that actually changes at any given point in time).
Take for example the extension of the flaps at the 10:20 timemark: the last point in time when the position of the flaps have been recorded was probably shortly after take-off. And yet Sky Dolly is able to properly detect the exact point in time when they are extended again. The same is true for starting the engine “from cold and dark”, and stopping it again at the end of the replay at the 11:36 timemark.
Of course all of this is basic software engineering, e.g. you’ll learn about binary search in the first or second semester of any decent software engineering studies (for splines you may want to attent some computer graphics lectures perhaps ;)). The trick is that the users don’t even realise the complexity behind all this: the functionality of any software should be presented in a seamless and intuitive way, without any usability hurdles or artificial limitations.
That is not to say that Sky Dolly is perfect just yet: there is always a walk between new functionality and improving existing usability - and available time ;). But this kind of feedback as just seen in the above video is really what keeps me driving here - so thanks for that, and thanks to the entire community for providing constructive feedback in the past and the future!
P.S. Just a small correction with respect to the 12:23 timemark: it’s just one developer
Did you know that you can directly import flight plans from Little Navmap into Sky Dolly for replay? Here is how…
Import & Export Formats
Sky Dolly supports a whole range of import and export formats, such as:
CSV: The comma-separated value (CSV) file format is a simple text format supported by most spreadsheet editors, e.g. for data analysis and visualisation with 2D charts. It is also exported by e.g. flightradar24.com
GPX: The GPS Exchange format is a light-weight, XML based format for the exchange of waypoints, routes and recorded GPS paths
IGC: A format defined by the International Gliding Commission (IGC), mostly used by flight recorders in gliders
KML: The Keyhole Markup Language is most prominently supported by Google Earth and suitable for flight path visualisations
Importing Flight Plans from Little Navmap
Flight plans generated in Little Navmap can be exported in the GPX format. So if we have a flight plan such as:
As outlined above the GPX format is able to essentially store three distinct items:
Waypoints: individual locations/waypoints
Routes: the (planned route how to get from the start to the end waypoint
Tracks: the actual recorded GPS path
Typically a flight plan does not contain a recorded track just yet (although Little Navmap is also able to export track data), which is the data that is normally imported into Sky Dolly for replay. As expected Little Navmap exports the flight plan as a route instead. This is what an extract of such an exported GPX flight plan may look like:
By changing the Position from the default Track (<trk>) to Route (<rte>) we are able to re-map the flight plan to actual position data of the aircraft to be imported. Of course the less waypoints there are in the flight plan the coarser the flight path reconstruction will be, and the flight reconstruction - specifically flaps settings, attitude and landing lights etc. - is still in its infancy, but Sky Dolly faithfully interpolates the flight path smoothly (as usual with cubic spline interpolation) between those track points (= aircraft position points in Sky Dolly).
Reconstructing the Flight
Typically GPX waypoints do not contain timestamp information (but as is the case with Little Navmap they may contain altitude data). This is where the default altitude and velocity options come into play: Sky Dolly uses this information to calculate the required time it takes to fly from one track point to the next, given their geodesic distance, and places the aircraft at a constant altitude (if needed).
The Waypoints can be left as Route (<rte>): the flight plan will of course also be imported into Sky Dolly, as can then be seen in the Flight (key F) dialog, in the Flight Plan tab: