Reset command causes rapid time-catch-up in realtime mode

[coasho]

Bug Description When running JSBSim in realtime mode and sending a set simulation/reset 0 command, the simulation momentarily resets but then rapidly accelerates until it catches up to the pre-reset time before resuming realtime execution. This behavior appears to be caused by time tracking variables not being reset along with the simulation state. Steps to Reproduce

Run JSBSim in realtime mode with any aircraft Let the simulation run for some time (e.g., 30 seconds) Send command: set simulation/reset 0 Observe the simulation behavior

Current Behavior After the reset command:

Simulation briefly resets to initial conditions Immediately accelerates at maximum speed Runs until reaching the pre-reset simulation time Finally resumes normal realtime execution

Expected Behavior The simulation should reset to initial conditions and continue running in realtime from that point, without any rapid time catch-up phase. Root Cause In the realtime execution loop, the time lag calculation uses initial_seconds and current_seconds to determine how far the simulation is behind real time:

actual_elapsed_time = current_seconds - initial_seconds;
sim_lag_time = actual_elapsed_time - FDMExec->GetSimTime();

When ResetToInitialConditions() resets sim_time to 0 but doesn't reset initial_seconds and current_seconds, it creates a large artificial time lag that the simulation tries to catch up to. Proposed Solution Time tracking variables need to be reset when ResetToInitialConditions() is called. A possible approach would be to:

Move time tracking variables out of JSBSim.cpp's real_main() Make them accessible to both the main loop and FGFDMExec Reset them in ResetToInitialConditions()

Impact This bug affects any application using JSBSim in realtime mode that needs to reset the simulation state during execution. It can cause unexpected behavior in flight training scenarios or interactive simulations where resets are common. Additional Notes

Severity: Medium Component: Core/Runtime The bug does not affect batch mode operation

[bcoconni]

Thanks for the report @coasho and thanks for the proposed solution but I'd rather use SGPropertyChangeListener to detect when the value of the property simulation/reset is set to 0. https://github.com/JSBSim-Team/jsbsim/blob/bb4cd5b6c25366d60cce98954426927e83d65ff9/src/simgear/props/props.hxx#L722-L749 Indeed the class FGFDMExec should remain isolated from the considerations of running the FDM in real time or in batch mode.

I'll submit a PR later on unless someone else beats me to it.

[coasho]

Thanks for taking the time to review this! Your suggestion about using SGPropertyChangeListener makes perfect sense for maintaining clean separation of concerns. It's a much better architectural solution than my initial proposal.

Really appreciate your guidance on the design pattern. Looking forward to the fix whenever you have time!