PMDG 737-800 replay landing issues

[Naegrad]

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:

1. Record a landing with the PMDG 737-800 (for example at LEIB)
2. Play the recording
3. Observe the described issues after touchdown

Screenshot

Expected behaviour

Application version:
"Humble Hawker" (2024.05)
Version 0.17.3 (ae5af3b)
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.

[till213]

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:

https://docs.flightsimulator.com/html/Programming_Tools/SimConnect/API_Reference/Structures_And_Enumerations/SIMCONNECT_DATA_INITPOSITION.htm

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!

[till213]

If you do not want to share your exported *.sdlog flight with the world, you can also send it to me via email - my address should be here somewhere on github.com (look at the commit data ;)). Or send it via wetransfer.com, in case the size is exceeding 15 MB or so.

[ebisettia]

Hello from Perú, South America. Sorry, I hope I'm not doing something wrong here. I've been recording lately my flights with SD but I remember when I did it before, Reversers deployed normally, now, with the previous version and the new one, they don't.
Since this post basically has the same issues I do, I didn't think it was necessary to create a new one.
Here I have a video where I land using SD and reversers do not deploy, but when I pause it and pull the play bar backward, you can see reversers deploy. You can also see tires sink below the tarmac level, but I read that there is a reason and actually that isn't much of a problem for me now.
If you need anything else from me, please do not hesitate and let me know.
Have a good one!
C-ya!

no.reverser.mp4

[till213]

You can also see tires sink below the tarmac level, but I read that there is a reason and actually that isn't much of a problem for me now.

Hello to Perú, greetings from Switzerland! Nice to know that Sky Dolly made it that far (geographically speaking ;)).

Now I will double-check the "reversers deployment" code: especially when you say that when you pause the replay and "skip back in time a bit" this could be an indication that some "SimConnect event" is not properly being sent to MSFS (some "simulation variables" are sent back to MSFS as so-called "events" - essentially the same "input events" that you map your joystick buttons etc. to).

However I have another theory, and that is related to the "wheels sinking into the ground", or put differenlty: MSFS does have logic to detect whether the aircraft is "on ground". And it could be that the aircraft in question has (new?) logic to only deply the reversers if the aircraft actually is "on ground" (which makes sense - especially in the real world ;)).

It could be (weak theory! to be tested / confirmed) that MSFS thinks that the aircraft is "anywhere but on the ground", hence the aircraft would not deploy the reversers either.

(By the way: the wheels sinking into the ground or the opposite: the aircraft howering slightly above the ground is due to the fact that some aircraft have their own dedidacted "hydraulics simulation logic", which is not controlled (controllable) by Sky Dolly - hence the wheels simply take a "neutral position" which may or may not fit with the current aircraft weight etc.).

Now the good news: I will try to improve the "on ground" situation, by a) storing the "on ground" simulation variable (which is "read-only") and b) during replay actively "measuring the actual height above ground", and adjusting ("correcting") the actual aircraft altitude during replay such that the "aircraft is exactly on the ground when it should be on the ground".

Now if this sounds complicated, don't worry: it will become clear once you see it. And I made some good progress with my initial code!

So my hope is that this will also more reliably deploy the reversers when they should. But again, I will also double-check the current code and see what happens with the event etc.

[ebisettia]

Hello! I've been using it for quite a while but basically for taking snapshots in the beginning, but to be honest, since I started uploading videos to my New YouTube channel, I decided to use it for them and I encountered this.
Just in case, I didn't say the aircraft is the PMDG's 737-700.
Thanks for the effort you put into this, we appreciate it.
Have a good one!
C-ya!