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.

jsbsim/src/simgear/props/props.hxx

Lines 722 to 749 in bb4cd5b

	/**
	* The property change listener interface.
	*
	* <p>Any class that needs to listen for property changes must implement
	* this interface.</p>
	*/
	class SGPropertyChangeListener
	{
	public:
	virtual ~SGPropertyChangeListener ();
	/// Called if value of \a node has changed.
	virtual void valueChanged(SGPropertyNode * node);
	/// Called if \a child has been added to the given \a parent.
	virtual void childAdded(SGPropertyNode * parent, SGPropertyNode * child);
	/// Called if \a child has been removed from its \a parent.
	virtual void childRemoved(SGPropertyNode * parent, SGPropertyNode * child);
	protected:
	friend class SGPropertyNode;
	virtual void register_property (SGPropertyNode * node);
	virtual void unregister_property (SGPropertyNode * node);
	private:
	std::vector<SGPropertyNode *> _properties;
	};

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!