This implements the "buffering proxy" we used in Bangkok last year directly into RoboViz. It should be a lot more reliable than the external proxy. What it does is fairly simple: if data for multiple cycles arrives at the same time, RoboViz is going to wait for the duration of a monitor cycle between applying/rendering these frames.
This buffering mechanism is disabled by default. Usually, a good network connection is available and this isn't required. This also avoids being out of sync with the live state of the simulation.
The duration of a monitor cycle needs to be defined manually with the "Monitor Step" setting. I'm not aware of an option to get this property through the monitor protocol.
To not break the config files again, I also improved the config reading mechanism a bit. If a value is not present yet in the config file, RoboViz will fallback to its default value and store it at the end of the config file (when writing back changes).
This implements the "buffering proxy" we used in Bangkok last year directly into RoboViz. It should be a lot more reliable than the external proxy. What it does is fairly simple: if data for multiple cycles arrives at the same time, RoboViz is going to wait for the duration of a monitor cycle between applying/rendering these frames.
This buffering mechanism is disabled by default. Usually, a good network connection is available and this isn't required. This also avoids being out of sync with the live state of the simulation.
The duration of a monitor cycle needs to be defined manually with the "Monitor Step" setting. I'm not aware of an option to get this property through the monitor protocol.
To not break the config files again, I also improved the config reading mechanism a bit. If a value is not present yet in the config file, RoboViz will fallback to its default value and store it at the end of the config file (when writing back changes).