Support for colors in ASSS (request)

[Dr Brain]

It'd be nice if Starlight would display all the color codes despite their context, since there's no way to discriminate between Continuum and Starlight in the code. Meaning, if the server sends a public message with no pid, just display it anyway.

 

Also it would be nice if Starlight supported color code 79 (Fuschia: http://forums.minegoboom.com/viewtopic.php?t=8095).

 

I plan on using all of these codes in Hyperspace (for menus), and there's no way for me to modify things on the server side to not send these codes to Starlight clients (like I'm doing for chatnet clients).

[Snrrrub]

Thanks for the suggestions! I like the first idea and I'll make sure that is the case in future releases. The color codes pose a slightly larger issue. Since Starlight is a native client, it has a different interface than the game interface. The colors that you've listed won't be exactly the same because they don't work quite as well on a light background. Moreover, the chat types don't seem to have any comprehensible mapping to color. Frankly, adding these color types opens up a can of worms (for all clients) and I think it needs more thought put into it.

 

I'll think about how we can make this happen (since those colors *are* useful) and add my thoughts here for some discussion until we reach consensus.

 

-Snrrrub

[Dr Brain]

How about forcing clients to say ?starlight when they log into a zone? At least that way I can detect the lack of color support.

[rootbear75]

or change the background to black, and you wont have to worry what the color looks like on a light bg

[»Admiral Kirk]

I always prefered keeping it configurable, just define each chat type in a configuration screen along with the background color and let the user decide what colors they want to use.

[»Lynx]

I agree with Kirk.

 

-Lynx

[CRe]

or change the background to black, and you wont have to worry what the color looks like on a light bg

 

You can already change it in the preferences.

[Snrrrub]

I don't think it's safe to assume that every client will render text in the same way. More generally, the issue boils down to the server knowing the client's capabilities and falling back to a safe default in case the client does not support an extension.

 

Expecting a client to send an identifier (e.g. ?starlight) on login is a good idea but has several drawbacks.

 

1) If a server does not need to distinguish between clients, there is no point in sending an extra packet (e.g. subgame, ASSS with no special modules like 'fuschia', etc.).

2) The client version isn't sent so it's hard to determine what the client is capable of.

3) Even if the version is sent in that chat message, it now becomes the server's responsibility to map a (client, version) pair to a capability set. If, for example, Starlight supports extended colors in version 1 but not in version 2 (maybe there was an application rewrite and extended colors are not supported yet), the server will have to encode that knowledge. Every time a new client is deployed, the server modules will have to be upgraded. It is unreasonable to expect such tight coupling between clients and servers given that there is so much independent development in this game.

4) If the capabilities of a client change at runtime, there is no way to notify the server because the capabilities are hard coded in the server based on client type and version.

5) The user can manually type the command (or every client has to filter out the identifier commands for every other client - e.g. Continuum, Discretion, subchat, etc. all have to prevent ?starlight from being sent). We don't want the user to be able to explicitly specify extensions because it could put the client into an inconsistent state, potentially causing poor interactions between the client and server.

 

Instead, I propose the following protocol extensions:

 

Direction: Server to Client

Packet Name: Query Client Version

Packet: 0x80

 

Direction: Client to Server

Packet Name: Client Version

Packet: 0x80

client:

0 - Reserved

1 - Starlight

clientVersion: an application-specific version number. This number must increase with every public client release.

displayName: a string that can be used by the server to display the client name. Example: "Starlight 1.0"

 

Direction: Server to Client

Packet Name: Query Client Capabilities

Packet: 0x81

 

Direction: Client to Server

Packet Name: Client Capabilities

Packet: 0x81 [capFlags2 (1) [capFlags3 (1) ... ]]

capFlags1:

bit 0 - Extended Continuum Chat Types

bit 1..7 - must be zero

Note: this is a variable-length packet with a maximum of 256 capFlags bytes. The server must accept all packets smaller than 258 bytes and will interpret only the flags it understands.

 

The following rules determine when the above packets can be sent:

1) The server may send "Query Client Version" or "Query Client Capabilities" at any time after a connection is established (i.e. after 0x00 0x02 packet)

2) The client must send "Client Version" only in response to a "Query Client Version" packet.

3) The client may only send "Client Capabilities" after receiving at least one "Query Client Capabilities" packet.

4) The client may send "Client Capabilities" at any time after receiving "Query Client Capabilities".

 

If the server does not receive a single reply to "Query Client Capabilities", it should assume no capabilities. If the server receives at least one reply but no subsequent replies, it should assume the capabilities of the last reply.

 

I should also address some practical issues in adopting protocol extensions. Since these packets are not part of the standard protocol, we should strive for interoperability. To make sure that developers don't use the same bits or identifiers for different purposes, I propose the following:

 

1) All new protocol extensions and changes to existing extensions must be specified as above and must go through a review process.

2) The client id (in the "Client Version" packet) must be !@#$%^&*igned serially (i.e. you cannot choose your id, you just get the next available one) and does not need to go through a review process. A request is made for a new client id with an application name and description and the next available id is !@#$%^&*igned.

 

To make the peer review process easier, I have set up a Google Group for developers. It is open to everyone, serves as as a point of reference for developers, and publicly do!@#$%^&*ents the peer reviews. The group is called SubSpace Development.

 

As always, I appreciate any feedback.

 

-Snrrrub

[Samapico]

I would make background black by default, and text colors are already configurable anyway. I think black background is much more ergonomic, as it is less tiring for the eyes (might be less true with the LCD screens of today, but anyway...)

[Dr Brain]

I'm not really worried about how it looks on the receiving end, just that it shows up in some form.

 

My suggestion for ?starlight was only if you weren't going be continuum compliant. If you are, then there's no issue.

 

And your arguments against something like ?starlight are flawed:

1) If the server DOES need to distinguish clients, it has to query all of them. That means packets to all clients, even though only a very small percentage are starlights. I personally don't think the overhead of a single packet is significant, but you brought it up.

2&3) Making mapping impossible is worse than making it mandatory. If bugs are discovered in previous versions, then with your capability system it'll be impossible to resolve (without adding a capability for no_bug_x, which I'm sure you'll agree isn't clean).

4) Continuum compliance is really not something you should be changing at runtime.

5) Can send it out of band, either using invalid message settings or by creating a packet for it. Or not worry that continuum users can disable their continuum compliance.

[rootbear75]

or change the background to black, and you wont have to worry what the color looks like on a light bg

 

You can already change it in the preferences.

you can?

 

oh, i still have the original starlight O.o

[CRe]

or change the background to black, and you wont have to worry what the color looks like on a light bg

 

You can already change it in the preferences.

you can?

 

oh, i still have the original starlight O.o

 

Yes starlight 1.1 supports it. And the pub color in starlight 1.1 is the color you see in the input text box. So yeh.