Make use of the 'type' parameter in the Stellarium Telescope Protocol

[dzach]

Is your feature request related to a problem? Please describe. While developing a telescope control, I find it difficult to send different commands to the telescope (server) when using the Stellarium Telescope Protocol, mainly due to the message type being fixed to 0.

Describe the solution you'd like The Stellarium Telescope Protocol version 1.0 defines a packet for the communication between a Stellarium client and a telescope server, over a TCP channel, like this:

Server (telescope) to client (Stellarium):

MessageCurrentPosition (type = 0):
 -----------------------------------------------------------------------------
|  pkt length  |  pkt type  |  time (us)  |     ra    |    dec    |  status   |
 -----------------------------------------------------------------------------
    16 bits        16 bits      64 bits      32 bits     32 bits     32 bits

Client (Stellarium) to server (telescope):

MessageGoto (type = 0):
 -----------------------------------------------------------------------------
|  pkt length  |  pkt type  |  time (us)  |     ra    |    dec    |  status   |
 -----------------------------------------------------------------------------
    16 bits        16 bits      64 bits      32 bits     32 bits     32 bits

As defined, this protocol allows for a number (total 65536) of message types to be defined at each side of a client-server connection.

At present, only type = 0 messages are used in Stellarium. This feature request proposes the addition of a parameter type to the functions/methods that talk to the telescope, like the telescopeGoto, and have it default to the currently defined type = 0, possibly like:

TelescopeTCP::telescopeGoto(const Vec3d &j2000Pos, StelObjectP selectObject, uint16_t type = 0)

For example, currently, this script slews the telescope to the selected object:

core.selectObjectByName("Arcturus", false);
TelescopeControl.slewTelescopeToSelectedObject(1);

but the following could be used to (polar or otherwise) align the same telescope in a 3 point alignment scheme:

core.selectObjectByName("Arcturus", false);
TelescopeControl.slewTelescopeToSelectedObject(1,1);
...
core.selectObjectByName("Dubhe", false);
TelescopeControl.slewTelescopeToSelectedObject(1,2);
...
core.selectObjectByName("Vega", false);
TelescopeControl.slewTelescopeToSelectedObject(1,3);

The server (telescope) then could make use of the new message types, but Stellarium could still be agnostic about the the new message types, i.e., no further new functionality needs to be created in Stellarium.

Describe alternatives you've considered The only alternative right now seems to be to create additional telescopes at different TCP ports which will interpret the messages they receive in a different way, which in essence means substituting each missing message type parameter with a new telescope. This complicates matters for end users as it makes it necessary to tie fixed ports and addresses to specific functions. Any change in telescopes is then a potential configuration problem.

Additional context To fully gain from the new message types, future Stellarium telescope GUIs would only need to provide means for creating additional buttons and assigning user definable telescope slot idx and message type values to these buttons. No further knowledge about the server's functionality is necessary for Stellarium, in order to have the buttons operational.

Thank you for reading this proposal.