The implementation of goToStep could be bugged. The way it is currently called by the FXUI produces some odd behaviours.
To observe the issue:
- Start a simulation with the
-fxui flag.
- Play the simulation briefly, then pause it.
- Press the key corresponding to the "one step forward" action - this calls
goToStep and passes it the current step + 1.
- The simulation does not move forward one step; instead, now the play/pause feature will move one step ahead, and occasionally crash the simulation.
I remember this specific sequence of actions was working as intended back when I implemented it in the FXUI, I'm not sure if it's an issue in how the FXUI calls goToStep or if the functionality of goToStep was changed. If it's the former, I can attempt to fix it through a PR, though I already tried tweaking it and couldn't get it right.
On a side note, the implementation in Engine.goToStep is different than what is documented in the javadoc for Simulation.goToStep:
- in
Engine, it attempts to pause the simulation when the current step is higher than the given argument.
- in
Simulation, it is described as if it executes a number of steps given as argument instead.
The implementation of
goToStepcould be bugged. The way it is currently called by the FXUI produces some odd behaviours.To observe the issue:
-fxuiflag.goToStepand passes it the current step + 1.I remember this specific sequence of actions was working as intended back when I implemented it in the FXUI, I'm not sure if it's an issue in how the FXUI calls
goToStepor if the functionality ofgoToStepwas changed. If it's the former, I can attempt to fix it through a PR, though I already tried tweaking it and couldn't get it right.On a side note, the implementation in
Engine.goToStepis different than what is documented in the javadoc forSimulation.goToStep:Engine, it attempts to pause the simulation when the current step is higher than the given argument.Simulation, it is described as if it executes a number of steps given as argument instead.