The current declination of the view, in radians.
The current value of WWT's internal clock, as an ISO-T datetime string.
The current rate at which the WWT clock is running compared to the frontend system clock. Zero indicates that the WWT clock is paused.
The current height of the viewport (zoom level), in degrees.
The current right ascension of the view, in radians.
The current roll angle of the view, in degrees
An app/client session identifier.
If a single client is communicating with multiple apps, it needs to be able
to tell which app is the source of any update messages. This session
identifier allows clients to do so. The default value is "default". But if
a client sends a PingPongMessage with a customized sessionId field,
that value will start appearing in these view state update messages.
The current datetime of the computer running the WWT frontend, as an ISO-T datetime string.
A message type identifier.
Generated using TypeDoc
Information about the current position of the WWT view.
Frontends (e.g., embedded WWT apps) periodically send this information to backends (e.g., pywwt) so that they can be aware of what's going on with the view.
The WWT clock time isn't sent directly, so that constant updates aren't needed in the common case that the clock is running. If you care about the current time of the WWT clock, you should maintain state that tracks the most recently provided values of the engineClockISOT, systemClockISOT, and engineClockRateFactor fields. If you need to estimate the current time of the WWT clock, you should calculate:
This calculation assumes that the frontend and backend system clocks are in OK agreement. You could try to do better by tracking the difference between the frontend and backend system clocks, but your accuracy is always going to be limited because messages from the frontend are propagating over some channel with unknown latency, and this simple protocol doesn't have any mechanism for determining this latency. File an issue if you think that you have an application that calls for higher accuracy than is made possible here.
Updates are sent no more frequently than every ten-or-so of milliseconds, and no less frequently than every minute or so. If the clock rate parameters change discontinuously, an update is sent immediately.