Engine failing #178
Comments
|
Hello, thank you for raising this issue and sorry for my late reply. The engine is controlled in quite a rudimentary way: essentially Sky Dolly tries to - somewhat heuristically - detect whether the engine is either running or stopped. This is essentially done by reading essentially two simulation variables:
Once Sky Dolly knows (or assumes) that the engine(s) is (are) either running or stopped ("cold and dark") then it either tries to start or stop the engines, by issueing an "auto-start engines" respectively "auto-stop engines" event. In essence what you do in MSFS by pressing CTRL + E (auto-start) and CTRL + SHIFT + E (auto-stop). This is not optimal, but there is no practical way to try to detect for each custom engine logic (each custom aircraft) whether the engines are running or not, let alone how to reliably start and stop the engines (with the aircraft custom logic, let alone the distinction between propeller, rotor, turboprop, jet, ...). This simple "auto-start/stop" logic together with the detection whether the engines are currently running or not (this is determined each time you push the play button and each time you seek back and forth, e.g. by sliding the timeline) works for most (stock) aircraft though. Depending on whether there is custom logic or not that requires more than a simple auto-start this may or may not work with certain 3rd-party aircraft. As I do not own the above mentioned aircraft myself, I have a question:
|
till213
added
enhancement
|
Thanks for the response. I'll try that. There's a multi action process for starting the engine. I automate this with AAO but basically, for each engine, you have to select the correct primer switch position, then press the appropriate start button. If you don't set the primer switch correctly, it won't start. I got around it by manually jogging sky dolly along the timeline then manually starting whichever engine has stopped. It's a bit hit and miss, but eventually, I can get both engines running. What would be useful, but maybe not worth the effort, would be the ability to filter/disable certain categories of commands. Such as engine start/stop. Anyway, Sky Dolly is brilliant! I now use it for all the external shots for my VR flight videos like this one. https://youtu.be/Wd1OiOlUsEwKevin
(Editor's note: quote of original reply (#178 (comment)) removed, for clarity.)
|
That's what I thought: a rather sophisticated process, and most importantly specific to this aircraft. And I assume that it even uses what is known as "local variables", that is variables that are specific to this aircraft (in order to implement e.g. a custom engine logic). While it is now (since several MSFS SDK releases) possible to record (and presumably also replay) those so-called "local variables" (as opposed to "simulation variables" that are "public" and well defined) it is currently out of scope for me to implement aircraft-specific sets of such local variables. Also, those sets could change nilly-willy, at the will (and requirement changes) of the corresponding the 3rd-party aircraft producer. However I actually already thought about having the option that the user could specify - somehow, e.g. as "comma-separated text list" or so - such "local variables" sets, that would then be dynamically registered (how? -> to be investigated whether possible to define such sets "dynamically at runtime"), recorded and replayed. (What makes this tricky is that each request / response "struct" (structure) must actually be known and defined at "compile-time", such that the "code knows about the struct member offsets etc. - but I'll look into that, I guess that's solvable).
This sounds actually like a good idea: such settings could perhaps even be implemented "per aircraft". I thought about the possibility to define "aircraft mappings" between MSFS 2020 and the upcoming MSFS 2024, such that a "formation flight" recorded with MSFS 2024 specific aircraft could still be replayed in MSFS 2020 (and vice versa) (essentially that when an aircraft cannot be spawned as "AI aircraft" the mapped replacement aircraft would be spawned instead). In such an "aircraft editor" the options to not record and replay certain variables (such as auto-engine start/stop) could certainly be implemented. Until such an "aircraft configuration editor" would exist (which is currently lower priority) I could add such an "Enable engine auto-start/stop" option in the Sky Dolly application settings. I'll think about that... thanks for the suggestion! In the meantime I would still be curious to know whether auto-start/stop works with the Milviz C310R. Or perhaps anyone knows a more reliable way to detect whether the engine is running (or stopped), and I could improve the code to more reliably send the proper "start engine" or "stop engine" event (in case engine state detection is the problem). By the way, in the "Simulation Variables" dialog in Sky Dolly (press key V) you will see the following values:
If either General engine start or Combustion (or both) is enabled (checked) then Sky Dolly concludes that the engines are running (or about to be running) and issues the mentioned "engine auto-start" event. Otherwise (both disabled) then an "engine auto-stop" event is sent. This is done each time the replay is started (resumed) or a seek on the timeline is done. Of course this approach is rather simplistic, and does not work for individual engines: so all engines are started (according to the "auto-start" logic that is implemented by the aircraft) or stopped at once. |
|
I'll read this in more detail later. But yes, a lot of things are controlled by local variables. I've automated some things using lorby aao, with the help of the creator, and the monitor function built into aao, but I agree such a level of detailed granularity would take away from what Sky Dolly is. Still think it's a brilliant app though! Sent from my Galaxy
-------- Original message --------From: Oliver Knoll ***@***.***> Date: 30/09/2024 19:41 (GMT+00:00) To: till213/SkyDolly ***@***.***> Cc: kevinbuckley70 ***@***.***>, Author ***@***.***> Subject: Re: [till213/SkyDolly] Engine failing (Issue #178)
for each engine, you have to select the correct primer switch position, then ...
That's what I thought: a rather sophisticated process, and most importantly specific to this aircraft. And I assume that it even uses what is known as "local variables", that is variables that are specific to this aircraft (in order to implement e.g. a custom engine logic).
While it is now (since several MSFS SDK releases) possible to record (and presumably also replay) those so-called "local variables" (as opposed to "simulation variables" that are "public" and well defined) it is currently out of scope for me to implement aircraft-specific sets of such local variables. Also, those sets could change nilly-willy, at the will (and requirement changes) of the corresponding the 3rd-party aircraft producer.
However I actually already thought about having the option that the user could specify - somehow, e.g. as "comma-separated text list" or so - such "local variables" sets, that would then be dynamically registered (how? -> to be investigated whether possible to define such sets "dynamically at runtime"), recorded and replayed.
(What makes this tricky is that each request / response "struct" (structure) must actually be known and defined at "compile-time", such that the "code knows about the struct member offsets etc. - but I'll look into that, I guess that's solvable).
What would be useful, but maybe not worth the effort, would be the ability to filter/disable certain categories of commands. Such as engine start/stop.
This sounds actually like a good idea: such settings could perhaps even be implemented "per aircraft". I thought about the possibility to define "aircraft mappings" between MSFS 2020 and the upcoming MSFS 2024, such that a "formation flight" recorded with MSFS 2024 specific aircraft could still be replayed in MSFS 2020 (and vice versa) (essentially that when an aircraft cannot be spawned as "AI aircraft" the mapped replacement aircraft would be spawned instead).
In such an "aircraft editor" the options to not record and replay certain variables (such as auto-engine start/stop) could certainly be implemented.
Until such an "aircraft configuration editor" would exist (which is currently lower priority) I could add such an "Enable engine auto-start/stop" option in the Sky Dolly application settings.
I'll think about that... thanks for the suggestion!
In the meantime I would still be curious to know whether auto-start/stop works with the Milviz C310R. Or perhaps anyone knows a more reliable way to detect whether the engine is running (or stopped), and I could improve the code to more reliably send the proper "start engine" or "stop engine" event (in case engine state detection is the problem).
By the way, in the "Simulation Variables" dialog in Sky Dolly (press key V) you will see the following values:
Simulation.Variables.jpg (view on web)
If either General engine start or Combustion (or both) is enabled (checked) then Sky Dolly concludes that the engines are running (or about to be running) and issues the mentioned "engine auto-start" event. Otherwise (both disabled) then an "engine auto-stop" event is sent. This is done each time the replay is started (resumed) or a seek on the timeline is done.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Hi Oliver – I have a feature request. I use Sky Dolly for post-flight video capture. Mostly for external, or through the side windows shots. It would be helpful if Sky Dolly, perhaps in the simulation variables window, could also show the ‘sim time’. The time shown on the clock in the cockpit. At the moment I have to note down the time on the clock in cockpit view and the elapsed time of the replay from which I can calculate sim time when I need it – to synchronise post flight external video capture with video captured in the cockpit during the flight.
I imagine this would be an easy thing to implement. When you have a moment… lol.
Cheers, Kevin
From: Oliver Knoll ***@***.***>
Sent: 30 September 2024 19:41
To: till213/SkyDolly ***@***.***>
Cc: kevinbuckley70 ***@***.***>; Author ***@***.***>
Subject: Re: [till213/SkyDolly] Engine failing (Issue #178)
for each engine, you have to select the correct primer switch position, then ...
That's what I thought: a rather sophisticated process, and most importantly specific to this aircraft. And I assume that it even uses what is known as "local variables", that is variables that are specific to this aircraft (in order to implement e.g. a custom engine logic).
While it is now (since several MSFS SDK releases) possible to record (and presumably also replay) those so-called "local variables" (as opposed to "simulation variables" that are "public" and well defined) it is currently out of scope for me to implement aircraft-specific sets of such local variables. Also, those sets could change nilly-willy, at the will (and requirement changes) of the corresponding the 3rd-party aircraft producer.
However I actually already thought about having the option that the user could specify - somehow, e.g. as "comma-separated text list" or so - such "local variables" sets, that would then be dynamically registered (how? -> to be investigated whether possible to define such sets "dynamically at runtime"), recorded and replayed.
(What makes this tricky is that each request / response "struct" (structure) must actually be known and defined at "compile-time", such that the "code knows about the struct member offsets etc. - but I'll look into that, I guess that's solvable).
What would be useful, but maybe not worth the effort, would be the ability to filter/disable certain categories of commands. Such as engine start/stop.
This sounds actually like a good idea: such settings could perhaps even be implemented "per aircraft". I thought about the possibility to define "aircraft mappings" between MSFS 2020 and the upcoming MSFS 2024, such that a "formation flight" recorded with MSFS 2024 specific aircraft could still be replayed in MSFS 2020 (and vice versa) (essentially that when an aircraft cannot be spawned as "AI aircraft" the mapped replacement aircraft would be spawned instead).
In such an "aircraft editor" the options to not record and replay certain variables (such as auto-engine start/stop) could certainly be implemented.
Until such an "aircraft configuration editor" would exist (which is currently lower priority) I could add such an "Enable engine auto-start/stop" option in the Sky Dolly application settings.
I'll think about that... thanks for the suggestion!
In the meantime I would still be curious to know whether auto-start/stop works with the Milviz C310R. Or perhaps anyone knows a more reliable way to detect whether the engine is running (or stopped), and I could improve the code to more reliably send the proper "start engine" or "stop engine" event (in case engine state detection is the problem).
By the way, in the "Simulation Variables" dialog in Sky Dolly (press key V) you will see the following values:
Simulation.Variables.jpg (view on web) <https://github.com/user-attachments/assets/2f4d3b32-6500-403c-9018-9a9f97855cac>
If either General engine start or Combustion (or both) is enabled (checked) then Sky Dolly concludes that the engines are running (or about to be running) and issues the mentioned "engine auto-start" event. Otherwise (both disabled) then an "engine auto-stop" event is sent. This is done each time the replay is started (resumed) or a seek on the timeline is done.
—
Reply to this email directly, view it on GitHub <#178 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJ2ODZ7ATGVMUOT2XSVQBJDZZGLMXAVCNFSM6AAAAABOZI5Y5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBTHEYTAOBZGI> .
You are receiving this because you authored the thread. <https://github.com/notifications/beacon/BJ2ODZ5LTTB6HENRJKKY763ZZGLMXA5CNFSM6AAAAABOZI5Y5KWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUOC6L6Y.gif> Message ID: ***@***.*** ***@***.***> >
|
Describe the bug
When replaying a flight with the Milviz C310R twin prop, the engines are started correctly but then randomly one or other just stops. I can usually manually restart the stopped engine whilst the Sky Dolly replay continues. This happens every time.
Today, I am replaying a flight but one of the engines simply won't start. Either by Sky Dolly or manually. If I load an MSFS flight without Sky Dolly, the aircraft is fine. As soon as I load Sky Dolly, everything stops as it forces the aircraft into cold and dark. But after that, the starboard engine cannot be started.
Interestingly, if I fast forward, the engine gauges show correct manifold pressure and rpm. But the engine is not actually running.
I've used Sky Dolly extensively and it's great but it does have this quirk. Usually, I just restart the stopped engine and get on with capturing my post-flight video. But this time I'm stuck as the aircraft is being forced to fly but one prop is actually just windmilling.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Application version:
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: