Changed aircraft title prevents AI aircraft creation (formation flight) #4
Assignees
Labels
enhancement
New feature or request
Comments
|
With the upcoming Sky Dolly v0.8 the aircraft type (including aircraft data like wingspan etc.) is now stored in a separate table. That means that we can now "enumerate" the (previously recorded) aircrafts, which would make a "dropdown list" feasible in the future. |
till213
added a commit
that referenced
this issue
Oct 8, 2022
* Reduce code analysis warnings
* Remove NullData constants
- Pass simulation records by value
* Use struct instead of class for private data
* Use qDebug() << "" instead of qDebug("")
* Pre-allocate vector capacity
- Return std::vector by value
* Return vectors by value
- Revert arguments back to "const &"
- Also refer to: https://raw.githubusercontent.com/CppCon/CppCon2014/
master/Presentations/Back%20to%20the%20Basics!
%20Essentials%20of%20Modern%20C%2B%2B%20Style/Back%20to%20the%20Basics!
%20Essentials%20of%20Modern%20C%2B%2B%20Style%20-%20Herb%20Sutter%20-
%20CppCon%202014.pdf
- -> Slide 24
* Move data will invalidate data ("null" data)
* Return aircraft vector by value
* Return by value (copy ellision)
* Return data by value (WIP)
- Won't compile
* Use const pimpl
- Refer to "Lifetime Safety... By Default: Making Code Leak-Free by
Construction", Herb Sutter, CppCon 2016
- WIP (won't compile)
* Refactoring (WIP)
* C++-14-ify type traits
* Use return value optimisation (RVO)
* Fix mutual shared pointer dependencies (graph edges)
- In the (academic) case when the module graph should have cycles
- Which would be possible if two (or seval) modules defined "after"
dependencies for each other (which would be a "configuration bug")
* Remove const from values returned by value
* Value-based aircraft list
- Drop QObject inheritance
- WIP: Refactor signals (won't compile)
* Move waypoint / aircraft info signals
- Compiles again
- TODO: Explictly emit signals (from services)
* Move ctor: initialise private data
* Thread-safe acccess to singletons
- Not that we have multiple threads just yet...
- ... but you never know :)
* Rename LogbookManager to PersistenceManager
- To avoid confusion with Logbook (the model)
* Replace "other" with "rhs"
* Refactoring (won't compile)
* FIX: Update Flight information dialog when loading flight
* Restore method names
* Bump version to 0.13
* Rule of zero / five #1
* Rule of zero / five #2
* Rule of zero / five #3
* Rule of zero / five #4
* Update
* Constant strings
* Fix compilation (Windows)
till213
added a commit
that referenced
this issue
Dec 3, 2022
* Reduce code analysis warnings
* Remove NullData constants
- Pass simulation records by value
* Use struct instead of class for private data
* Use qDebug() << "" instead of qDebug("")
* Pre-allocate vector capacity
- Return std::vector by value
* Return vectors by value
- Revert arguments back to "const &"
- Also refer to: https://raw.githubusercontent.com/CppCon/CppCon2014/
master/Presentations/Back%20to%20the%20Basics!
%20Essentials%20of%20Modern%20C%2B%2B%20Style/Back%20to%20the%20Basics!
%20Essentials%20of%20Modern%20C%2B%2B%20Style%20-%20Herb%20Sutter%20-
%20CppCon%202014.pdf
- -> Slide 24
* Move data will invalidate data ("null" data)
* Return aircraft vector by value
* Return by value (copy ellision)
* Return data by value (WIP)
- Won't compile
* Use const pimpl
- Refer to "Lifetime Safety... By Default: Making Code Leak-Free by
Construction", Herb Sutter, CppCon 2016
- WIP (won't compile)
* Refactoring (WIP)
* C++-14-ify type traits
* Use return value optimisation (RVO)
* Fix mutual shared pointer dependencies (graph edges)
- In the (academic) case when the module graph should have cycles
- Which would be possible if two (or seval) modules defined "after"
dependencies for each other (which would be a "configuration bug")
* Remove const from values returned by value
* Value-based aircraft list
- Drop QObject inheritance
- WIP: Refactor signals (won't compile)
* Move waypoint / aircraft info signals
- Compiles again
- TODO: Explictly emit signals (from services)
* Move ctor: initialise private data
* Thread-safe acccess to singletons
- Not that we have multiple threads just yet...
- ... but you never know :)
* Rename LogbookManager to PersistenceManager
- To avoid confusion with Logbook (the model)
* Replace "other" with "rhs"
* Refactoring (won't compile)
* FIX: Update Flight information dialog when loading flight
* Restore method names
* Bump version to 0.13
* Rule of zero / five #1
* Rule of zero / five #2
* Rule of zero / five #3
* Rule of zero / five #4
* Update
* Constant strings
* Fix compilation (Windows)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Existing formation flight recordings are unable to properly "spawn" the AI aircrafts in the formation in case the aircraft has changed its aircraft type ("container title") in the meantime, e.g. due to some aircraft update.
Example:
OLD: Supermarine Spitfire LF Mk IXc RAF - 126 Sqn ML214 'Muscat'
NEW: Supermarine Spitfire Mk IX RAF - 126 Sqn ML214 'Muscat'
To Reproduce
Steps to reproduce the behavior:
Expected behavior
In such a case it should somehow be possible for the user to adjust/fix the aircraft title. Manually editing the aircraft would be a possibility, but would be cumbersome if many recordings are affected.
Possibly an "Update aircraft type" dialog which would update all flights would be a possibility? But how would the user know the new aircraft title?
Hint: the new title becomes obvious when recording a new flight with the new aircraft.
Application version:
Additional context
Workaround: the aircrafts can be updated with an SQL DB browser. In the above example:
The text was updated successfully, but these errors were encountered: