flight_number should be an attribute of the flight table, not of the aircraft table

[fsx-rwt]

I believe that flight_number should be an attribute of the flight table, not of the aircraft table.

I think it is an attribute of the aircraft in MSFS so that you have a default flight number, when you use an aircraft for Free Flight. In real life I believe that when an airline has a last minute change of aircraft for a flight they keep the same flight number.

And it should be one of the field presented when I look at Logbook user interface,

In my case I have a flight training package that use the Savage Cub for all the Sport Pilot training flight. Each training flight has a different flight number. For example when we flight from Post Mill to Lebanon to learn about airport communication and traffic pattern it is always "FLT-005" whether I use the Savage Cub or the Cessna 152.

[till213]

Technically the flight number - like almost all vaues - comes from the aircraft, that is via the SimConnect API you query the "simulation variable" called ATC_FLIGHT_NUMBER, given the user aircraft ID (typically SIMCONNECT_OBJECT_ID_USER, to query the flight number from the current "user aircraft").

But you are right: it makes much more sense to

• Present this value in the Logbook (instead of per aircraft, in the Formation module)
• The presented value would simply be the flight number of the "user aircraft" (as defined for the formation flight)...
• ... and assuming that the flight number would apply for all aircraft in the formation equally

In that same argument I would remove it from the Formation aircraft table, as there the flight number is probably not really of interest anyway (again, technically it could be different for each aircraft, depending on the actual flight number as selected at the time of recording - but in reality we would expect the same flight number for all aircraft/the formation, just as you said).

[fsx-rwt]

Just to complement your answer, as a matter of fact, when I generate my flights I put the flight number in the [Sim.0] entry:

[Sim.0]
Sim=Asobo Savage Cub
SimFile=runway.FLT
TailNumber=MSFS-RWT
AirlineCallSign=MSFS-RWT
FlightNumber=FLT-001
AppendHeavy=False
Pilot=Pilot_Male_Casual

and it is correctly captured by SkyDolly.

Gilbert Laprise

------ Original Message ------ From "Oliver Knoll" @.> To "till213/SkyDolly" @.> Cc "fsx-rwt" @.>; "Author" @.> Date 2023-03-11 12:54:40 PM Subject Re: [till213/SkyDolly] flight_number should be an attribute of the flight table, not of the aircraft table (Issue #103)

Technically the flight number - like almost all vaues - comes from the aircraft, that is via the SimConnect API you query the "simulation variable" called ATC_FLIGHT_NUMBER https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Aircraft_SimVars/Aircraft_RadioNavigation_Variables.htm#ATC%20FLIGHT%20NUMBER, given the user aircraft ID (typically SIMCONNECT_OBJECT_ID_USER, to query the flight number from the current "user aircraft").

But you are right: it makes much more sense to

Present this value in the Logbook (instead of per aircraft, in the Formation module) The presented value would simply be the flight number of the "user aircraft" (as defined for the formation flight)... ... and assuming that the flight number would apply for all aircraft in the formation equally In that same argument I would remove it from the Formation aircraft table, as there the flight number is probably not really of interest anyway (again, technically it could be different for each aircraft, depending on the actual flight number as selected at the time of recording - but in reality we would expect the same flight number for all aircraft/the formation, just as you said).

— Reply to this email directly, view it on GitHub https://github.com/till213/SkyDolly/issues/103#issuecomment-1464964259, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSXAY7OHLOEWVOGRX6AME3W3S36BANCNFSM6AAAAAAVXDNEZY. You are receiving this because you authored the thread.Message ID: @.***>

[till213]

Yes, and I just realised that the value shown in the Formation module is actually the tail number (which is indeed aircraft-specific), not the flight number. So there is nothing to change in the Formation module.

I believe that flight_number should be an attribute of the flight table, not of the aircraft table.

Oh, or are you referring to the actual SQLite database tables (as opposed to the tables as presented in the user interface)? In this case you are right: the "flight_number" is indeed part of the aircraft table (and not the flight table). And yes, this is probably also something that I could change, but I have to think about the implications (the obvious implication is that the first recorded aircraft would specifiy the flight number - for subsequently recored "formation" aircraft the flight number would simply be ignored).

But your argument that the flight number conceptually really belongs to the flight (and not any aircraft) totally makes sense to me...

[fsx-rwt]

Yes, I was referring to the SQL table. While I still think that it should be presented to the user as part of the Flight, since MSFS assign it to the aircraft in the FLT, you might want to keep it with the Aircraft table.

However the value of this attribute will probably change with different flight with the same aircraft. For example for the sport Pilot training I have 29 flights that use the Savage Cub and each one of them have a different flight number, and these same numbers are used even if you decide to do the training with the Cessna 152. So the association with the aircraft is only while the flight is running.

Even people using Free Flight might change that number all the time for the same aircraft.

Gilbert Laprise

------ Original Message ------ From "Oliver Knoll" @.> To "till213/SkyDolly" @.> Cc "fsx-rwt" @.>; "Author" @.> Date 2023-03-11 2:01:00 PM Subject Re: [till213/SkyDolly] flight_number should be an attribute of the flight table, not of the aircraft table (Issue #103)

Yes, and I just realised that the value shown in the Formation module is actually the tail number (which is indeed aircraft-specific), not the flight number. So there is nothing to change in the Formation module.

I believe that flight_number should be an attribute of the flight table, not of the aircraft table.

Oh, or are you referring to the actual SQLite database tables (as opposed to the tables as presented in the user interface)? In this case you are right: the "flight_number" is indeed part of the aircraft table (and not the flight table). And yes, this is probably also something that I could change, but I have to think about the implications (the obvious implication is that the first recorded aircraft would specifiy the flight number - for subsequently recored "formation" aircraft the flight number would simply be ignored).

But your argument that the flight number conceptually really belongs to the flight (and not any aircraft) totally makes sense to me...

— Reply to this email directly, view it on GitHub https://github.com/till213/SkyDolly/issues/103#issuecomment-1464984798, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSXAY2WGJAO7EZYOIDA75TW3TDWZANCNFSM6AAAAAAVXDNEZY. You are receiving this because you authored the thread.Message ID: @.***>

[till213]

The flight number is now stored in the 'flight' table (only) and only recorded with the first aircraft. Subsequent aircraft (recorded in the same formation flight) do not influence the flight number.

The flight number is now also shown in the Logbook table (in the user interface) and searchable.

[fsx-rwt]

Thanks, this is much appreciated.

Gilbert Laprise

------ Original Message ------ From "Oliver Knoll" @.> To "till213/SkyDolly" @.> Cc "fsx-rwt" @.>; "Author" @.> Date 2023-03-12 9:02:31 AM Subject Re: [till213/SkyDolly] flight_number should be an attribute of the flight table, not of the aircraft table (Issue #103)

The flight number is now stored in the 'flight' table (only) and only recorded with the first aircraft. Subsequent aircraft (recorded in the same formation flight) do not influence the flight number.

The flight number is now also shown in the Logbook table (in the user interface) and searchable.

— Reply to this email directly, view it on GitHub https://github.com/till213/SkyDolly/issues/103#issuecomment-1465192987, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSXAY6LSRXG42LZXSARE63W3XCOPANCNFSM6AAAAAAVXDNEZY. You are receiving this because you authored the thread.Message ID: @.***>

[fsx-rwt]

Just a quick one, what about migration of existing flight, should i export them et import after installing the new version. What happen if I don't?

Gilbert Laprise

------ Original Message ------ From "Gilbert Laprise" @.> To "till213/SkyDolly" @.> Date 2023-03-12 1:46:21 PM Subject Re[2]: [till213/SkyDolly] flight_number should be an attribute of the flight table, not of the aircraft table (Issue #103)

Thanks, this is much appreciated.

Gilbert Laprise

------ Original Message ------ From "Oliver Knoll" @.> To "till213/SkyDolly" @.> Cc "fsx-rwt" @.>; "Author" @.> Date 2023-03-12 9:02:31 AM Subject Re: [till213/SkyDolly] flight_number should be an attribute of the flight table, not of the aircraft table (Issue #103)

The flight number is now stored in the 'flight' table (only) and only recorded with the first aircraft. Subsequent aircraft (recorded in the same formation flight) do not influence the flight number.

The flight number is now also shown in the Logbook table (in the user interface) and searchable.

— Reply to this email directly, view it on GitHub https://github.com/till213/SkyDolly/issues/103#issuecomment-1465192987, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSXAY6LSRXG42LZXSARE63W3XCOPANCNFSM6AAAAAAVXDNEZY. You are receiving this because you authored the thread.Message ID: @.***>

[till213]

Migration is trivial if a flight contains exactly one aircraft: the flight number of this one single aircraft (table) is moved into the flight table (now we‘re talking about database tables flight and aircraft).

A more interesting case is when you have a formation flight (#aircraft > 1): a flight does have a designated „user aircraft“ (which can be set by the user to any of the formation aircraft), but I then decided to move the flight number of the first aircraft („seq_nr = 1“) into the flight table (and all other flight numbers are ignored).

This is consistent with the fact that the first recorded aircraft (whether additional formation aircraft are going to be recorded / added later on or not) also defines the „global“ flight parameters, most importantly the „flight conditions“ (time of flight, runway conditions, temperature, wind, …).

(Btw while re-evaluating this logic I stumbled over a bug that those conditions actually are overwritten (recorded) when recording additional aircraft, which is wrong. Luckily only „in memory“: the persisted data is correctly stored. This is going to be fixed).

Oh and migration happens - as always - automatically each time an older logbook (from an older version) is loaded. A backup of the older logbook is made first (unless deactivated in the Logbook settings).

So nothing to do for you ;)

[fsx-rwt]

Thanks, so far I am just recording, so I am in gooo shape. 👍

Gilbert Laprise

------ Original Message ------ From "Oliver Knoll" @.> To "till213/SkyDolly" @.> Cc "fsx-rwt" @.>; "Author" @.> Date 2023-03-13 2:50:45 AM Subject Re: [till213/SkyDolly] flight_number should be an attribute of the flight table, not of the aircraft table (Issue #103)

Migration is trivial if a flight contains exactly one aircraft: the flight number of this one single aircraft (table) is moved into the flight table (now we‘re talking about database tables flight and aircraft).

A more interesting case is when you have a formation flight (#aircraft

1): a flight does have a designated „user aircraft“ (which can be set by the user to any of the formation aircraft), but I then decided to move the flight number of the first aircraft („seq_nr = 1“) into the flight table (and all other flight numbers are ignored).

This is consistent with the fact that the first recorded aircraft (whether additional formation aircraft are going to be recorded / added later on or not) also defines the „global“ flight parameters, most importantly the „flight conditions“ (time of flight, runway conditions, temperature, wind, …).

(Btw while re-evaluating this logic I stumbled over a bug that those conditions actually are overwritten (recorded) when recording additional aircraft, which is wrong. Luckily only „in memory“: the persisted data is correctly stored. This is going to be fixed).

— Reply to this email directly, view it on GitHub https://github.com/till213/SkyDolly/issues/103#issuecomment-1465599046, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSXAYYKH3BGPBO5HYLRLIDW327ULANCNFSM6AAAAAAVXDNEZY. You are receiving this because you authored the thread.Message ID: @.***>

[fsx-rwt]

Oliver,

I am sorry to bother you with this question and will understand if you don't have the time to answer, but I am desperate!

For the last few months everyday I have scan Qt Forums and documentation, to find a lot of answer but nothing works. I see from the forum that a lot of people are facing the same challenges.

I know that with Sky Dolly you have manage to package everything including the database, I use it, and even update are painless.

My Appl is a FlightLog application that monitor the MSFS-RWT Training Flights, log information about the flight, and let the user score their performance.

Everything works fine and is ready for distribution. But when I install it on a different computer it does not find the FlightLog.db in the DataBase subfolder of the Application.

I am using QMake. Which entry do I need, to point to the database location. (conversion to CMake is still too complicated for me) How do I make the connection in the .cpp I know it does not work as a resource.

I tried :

//QStringdbPath=QCoreApplication::applicationDirPath()+"/FlightLog.db"; //QStringdbPath=QDir::currentPath()+"/DataBase/FlightLog.db"; //QStringdbPath="H:/QtLearn/MsfsRwtFlightLog/DataBase/FlightLog.db"; QStringdbPath=":FlightLog.db"; QMessageBox::information(this,tr("LoginWin"),dbPath);//**GL2024-02-22 mydb=QSqlDatabase::addDatabase("QSQLITE"); /mydb.setDatabaseName("H:/QtLearn/MsfsRwtFlightLog/DataBase/FlightLog.db");*/ mydb.setDatabaseName(dbPath);

Nothing works other than the absolute path when I move to another computer.

If you have the time to answer it will be greatly appreciate. In the mean time I will try understanding Sky Dolly code and continue to enjoy using Sky Dolly,

Best Regards, Gilbert P.S.: Eventhough I have been programming in Assembler, since the early 70s, I am still a Newbie with Qt and C++

------ Original Message ------ From "Gilbert Laprise" @.> To "till213/SkyDolly" @.>; "till213/SkyDolly" @.> Cc "Author" @.> Date 2023-03-11 1:08:51 PM Subject Re[2]: [till213/SkyDolly] flight_number should be an attribute of the flight table, not of the aircraft table (Issue #103)

Just to complement your answer, as a matter of fact, when I generate my flights I put the flight number in the [Sim.0] entry:

[Sim.0] Sim=Asobo Savage Cub SimFile=runway.FLT TailNumber=MSFS-RWT AirlineCallSign=MSFS-RWT FlightNumber=FLT-001 AppendHeavy=False Pilot=Pilot_Male_Casual

and it is correctly captured by SkyDolly.

Gilbert Laprise

------ Original Message ------ From "Oliver Knoll" @.> To "till213/SkyDolly" @.> Cc "fsx-rwt" @.>; "Author" @.> Date 2023-03-11 12:54:40 PM Subject Re: [till213/SkyDolly] flight_number should be an attribute of the flight table, not of the aircraft table (Issue #103)

Technically the flight number - like almost all vaues - comes from the aircraft, that is via the SimConnect API you query the "simulation variable" called ATC_FLIGHT_NUMBER https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Aircraft_SimVars/Aircraft_RadioNavigation_Variables.htm#ATC%20FLIGHT%20NUMBER, given the user aircraft ID (typically SIMCONNECT_OBJECT_ID_USER, to query the flight number from the current "user aircraft").

But you are right: it makes much more sense to

Present this value in the Logbook (instead of per aircraft, in the Formation module) The presented value would simply be the flight number of the "user aircraft" (as defined for the formation flight)... ... and assuming that the flight number would apply for all aircraft in the formation equally In that same argument I would remove it from the Formation aircraft table, as there the flight number is probably not really of interest anyway (again, technically it could be different for each aircraft, depending on the actual flight number as selected at the time of recording - but in reality we would expect the same flight number for all aircraft/the formation, just as you said).

— Reply to this email directly, view it on GitHub https://github.com/till213/SkyDolly/issues/103#issuecomment-1464964259, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSXAY7OHLOEWVOGRX6AME3W3S36BANCNFSM6AAAAAAVXDNEZY. You are receiving this because you authored the thread.Message ID: @.***>

[fsx-rwt]

Oliver, just forget about my request, I finally got the right combination of options working.

Everything is working fine even from a USB drive.

I will be able to distribute v2.0.0 of MSFS-RWT Real World Flight Training package.

Thanks again for your support in the past.

Gilbert

------ Original Message ------ From "Gilbert Laprise" @.> To "till213/SkyDolly" @.>; "till213/SkyDolly" @.> Cc "Author" @.> Date 2024-02-24 2:16:17 PM Subject Re: How to package and distribute a QT C++ application with a populated SQLite DB that will be updated by the end user ???

Oliver,

I am sorry to bother you with this question and will understand if you don't have the time to answer, but I am desperate!

For the last few months everyday I have scan Qt Forums and documentation, to find a lot of answer but nothing works. I see from the forum that a lot of people are facing the same challenges.

I know that with Sky Dolly you have manage to package everything including the database, I use it, and even update are painless.

My Appl is a FlightLog application that monitor the MSFS-RWT Training Flights, log information about the flight, and let the user score their performance.

Everything works fine and is ready for distribution. But when I install it on a different computer it does not find the FlightLog.db in the DataBase subfolder of the Application.

I am using QMake. Which entry do I need, to point to the database location. (conversion to CMake is still too complicated for me) How do I make the connection in the .cpp I know it does not work as a resource.

I tried :

//QStringdbPath=QCoreApplication::applicationDirPath()+"/FlightLog.db"; //QStringdbPath=QDir::currentPath()+"/DataBase/FlightLog.db"; //QStringdbPath="H:/QtLearn/MsfsRwtFlightLog/DataBase/FlightLog.db"; QStringdbPath=":FlightLog.db"; QMessageBox::information(this,tr("LoginWin"),dbPath);//**GL2024-02-22 mydb=QSqlDatabase::addDatabase("QSQLITE"); /mydb.setDatabaseName("H:/QtLearn/MsfsRwtFlightLog/DataBase/FlightLog.db");*/ mydb.setDatabaseName(dbPath);

Nothing works other than the absolute path when I move to another computer.

If you have the time to answer it will be greatly appreciate. In the mean time I will try understanding Sky Dolly code and continue to enjoy using Sky Dolly,

Best Regards, Gilbert P.S.: Eventhough I have been programming in Assembler, since the early 70s, I am still a Newbie with Qt and C++

------ Original Message ------ From "Gilbert Laprise" @.> To "till213/SkyDolly" @.>; "till213/SkyDolly" @.> Cc "Author" @.> Date 2023-03-11 1:08:51 PM Subject Re[2]: [till213/SkyDolly] flight_number should be an attribute of the flight table, not of the aircraft table (Issue #103)

Just to complement your answer, as a matter of fact, when I generate my flights I put the flight number in the [Sim.0] entry:

[Sim.0] Sim=Asobo Savage Cub SimFile=runway.FLT TailNumber=MSFS-RWT AirlineCallSign=MSFS-RWT FlightNumber=FLT-001 AppendHeavy=False Pilot=Pilot_Male_Casual

and it is correctly captured by SkyDolly.

Gilbert Laprise

------ Original Message ------ From "Oliver Knoll" @.> To "till213/SkyDolly" @.> Cc "fsx-rwt" @.>; "Author" @.> Date 2023-03-11 12:54:40 PM Subject Re: [till213/SkyDolly] flight_number should be an attribute of the flight table, not of the aircraft table (Issue #103)

Technically the flight number - like almost all vaues - comes from the aircraft, that is via the SimConnect API you query the "simulation variable" called ATC_FLIGHT_NUMBER https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Aircraft_SimVars/Aircraft_RadioNavigation_Variables.htm#ATC%20FLIGHT%20NUMBER, given the user aircraft ID (typically SIMCONNECT_OBJECT_ID_USER, to query the flight number from the current "user aircraft").

But you are right: it makes much more sense to

Present this value in the Logbook (instead of per aircraft, in the Formation module) The presented value would simply be the flight number of the "user aircraft" (as defined for the formation flight)... ... and assuming that the flight number would apply for all aircraft in the formation equally In that same argument I would remove it from the Formation aircraft table, as there the flight number is probably not really of interest anyway (again, technically it could be different for each aircraft, depending on the actual flight number as selected at the time of recording - but in reality we would expect the same flight number for all aircraft/the formation, just as you said).

— Reply to this email directly, view it on GitHub https://github.com/till213/SkyDolly/issues/103#issuecomment-1464964259, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSXAY7OHLOEWVOGRX6AME3W3S36BANCNFSM6AAAAAAVXDNEZY. You are receiving this because you authored the thread.Message ID: @.***>