till213
commented
1 month ago Hello,
Thank you for reporting this issue!
Upon touchdown, if I pause and unpause the recording, both issues disappear
As for the spoilers, I have an explanation: first of all, they should really deploy, especially when you say that when you pause/unpause they actually do (that means the aircraft actually does react to the corresponding SimConnect "event").
Some background: as you probably know - as a software developer ;) - Sky Dolly records a selected set of so-called SimConnect simulation variables that represent the state of a given aircraft system (gears, flaps, spoilers, ...).
Specifically those that a) have a "visual impact" (flaps, gears, ailerons, and of course aircraft postion and attitude) and b) those that are also "writeable" (that is, can be modified by an application like Sky Dolly, via SimConnect) are recorded (in Sky Dolly: open the "Simulation Variables" (key V) dialog, to get an idea: the tooltip of each field represents the actual simulation variable name).
Now I have learned that not every aircraft (specifically 3rd-party aircraft) does actually react to those simulation variable changes. In the best case (*) those aircraft at least report proper values via those simulation variables (during recording, that is).
(*) Not always: specifically the Fenix A320 does seem to report bogus values for the spoilers: the maximum reported value is only like 1/3 of the actual expected range, if I remember correctly: and the behaviour "worsened" with subsequent Fenix A320 versions...
Hence certain variables are actually sent as SimConnect events: gears, flaps, and also spoilers (and some others).
Now it would be to easy if e.g. every "boolean" variable had a proper "set" event where you could pass the desired value. Or at least a "set on" / "set off". But certain events only have a "toggle".
And with flaps: there are only 4 specific events for flaps position 1, 2, 3 and 4. But certain aircraft have more than 4 flap positions. So I need to fallback to the events "increase flaps" and "decrease flaps".
(With the spoiler I would have to look into the code, but it is possible that at least there I have an event that allows to pass the desired position value directly).
So what do I do? Every time replay resumes - either because "Play" was pushed, or an existing replay was unpaused - I reset the "state" of each variable, and before setting it again I first query the existing state (e.g. the current flaps position). Then I know by how much I need to increase or decrease the flaps (or whether a specific light is already on etc.).
This would explain why the spoilers go into the expected position when unpausing a paused replay.
What really sounds like a bug is why they do not do that during normal replay. I have to investigate this.
Now as to the "sinking gears", this is a different matter: there is (as far as I know) no simulation variable that would tell me how much weight is on the gears, that is by how much the gears are "compressed" (?). And since during replay everything that would affect the aircraft position or attitude is "frozen" (otherwise the simulation would "fight" against the attitude and position as set by Sky Dolly). It is possible that the "hydraulics" simulation is also frozen, hence the gears are "weightless" and seem to sink into the runway.
Now here is the thing: there is actually a SimConnect function (or rather data structure) that allows me to properly align the aircraft on the runway:
And it has an
DWORD OnGround;member that - if set to 1 - will properly align the aircraft (including gears) on the ground.
The "problem" with this data structure: when passed along with SimConnect_SetDataOnSimObject this will also initialise certain simulation systems, including other AI objects.
From the documentation:
"The primary use of this structure is to initialize the positioning of the user aircraft, because it also optimizes some of the terrain systems and other Microsoft Flight Simulator systems. Simply setting parameters such as latitude, longitude and altitude does not perform this kind of optimization. This structure should not be used to incrementally move the user aircraft (as this will unnecessarily initiate the reloading of scenery)"
So I do this call only once, at the very beginning of the replay (and when seeking back to the very beginning). For all other position changes I merely send latitude, longitude and of course altitude - but then the gear will (unfortunately) remain fully extended ("weightless").
There actually is a simulation variable called SIM_SHOULD_SET_ON_GROUND. But while it is marked "writeable" it is not documented, and last time I tried it it did not seem to have any impact. That was a couple of months (or 1+ year) ago, so things might have changed.
The good news: with the upcoming Sky Dolly v0.18 I am splitting the position and attitude data (the position is now only sampled at 1 Hz: my hope is that this acts as a "low pass filter" and "stutter" during recording will be naturally smoothened out like this). And I now also store the "on ground" simulation variable for each position, so now I will have the exact information at each position whether the aircraft is (or should be) on ground.
I will hence try the SIM_SHOULD_SET_ON_GROUND variable once more (with the new information that I now have per position) and see whether I can improve the "sinking gears" problem.
Now all that said: I have currently no explanation why the gear is aligned after unpausing: possibly because I am (now) also using the SIMCONNECT_DATA_INITPOSITION data structure upon resuming a paused replay (I have to check my code ;)). So far I thought I would only be doing this at the very beginning of the replay (for the mentioned "AI objects initialisation" side-effect).
I'm a software developer,
I thought so: a concise and complete issue desciption ;)
so tell me if I can help in any way.
You could indeed help:
- You could export your flight as "Sky Dolly Logbook" (this format contains the complete flight data: it will even be "migrated" when being opened with a newer Sky Dolly version - just as some side-remark ;)) and attach it here (IF it does not reveal sensitive data, such as your location where you actually live - in case you circle over your house, for instance ;)). Like this I could have a look at the actual recorded data (it is really an SQLite database) and try to reproduce the spoiler issue (*)
(*) I could do this myself. But as a matter of fact I rarely get to fly, let alone longer, complete flights from airport A to B ;)
- If you have or find any additional information about the "animation state" ("weight on gears", or anything that would impact the gears animation state other than "up / down") OR...
- ... any information how to properly "set the aircraft on ground" (e.g. also with the "Simvar Watcher" example app that comes with the MSFS SDK - in case you have that installed)
that would be very helpful! You don't have to test it yourself actually, but if you stumble over anything in the SDK documentation that you think may help with regards to the gears / on ground alignment, please do let me know and I will try it!
https://docs.flightsimulator.com/html/Programming_Tools/Programming_APIs.htm
Happy flying!
Describe the bug During replay, on touchdown the landing gear wheels sink below the runway and the thrust reversers don't get deployed.
To Reproduce Steps to reproduce the behaviour:
Screenshot
Expected behaviour
Application version: "Humble Hawker" (2024.05) Version 0.17.3 (ae5af3b6) Sat May 25 20:41:11 2024
Additional context Upon touchdown, if I pause and unpause the recording, both issues disappear, but this isn't a suitable solution for recording a video of the landing. Is there a chance that the aircraft is still considered in the air after landing? I'm a software developer, so tell me if I can help in any way. Feel free to share technical details if you like and please let me know if I have misconfigured something or if there is a simple workaround. Thanks.