Added ChatAPI

[ST-DDT]

Suggestion for a text/chat API supporting all features introduced in 1.7 and later:
Bukkit/Bukkit#1111

Added integration to TitleAPI.
This API is also meant to be used with other features introduced in 1.8 (signs, books...).

All authors gave permission to relicence it under MIT.

Due to a lack of matching classes i copy/pasted it just yet.
Any suggestions for improvements?

PR Breakdown:

This PR adds a builder interface based on a Message to which you append MessageParts to build a rich chat message containing (or not):

• a TextFormatting compatible text, a localized text, an Entity name, an ItemStack name or an Achievement name ;
• an optional TextHover text (showing a multi-color multi-line text, an Achievement description, an Entity description or an ItemStack description) ;
• an optional TextClickAction (executing commands / sending chat message, proposing commands / proposing chat message, or opening urls (actually opens the prompt), ...).

These messages handle colors and formatting using TextFormatting just like standard messages.

Many (many) shortcuts have been added to Message to make it easier to append specific elements, see Message static constructors, append methods and insert methods.

Authors:

• @bendem did a lot of things
• @Ribesg did a lot of things
• @ST-DDT did a lot of things

[Kiskae]

This wont work, it still uses Bukkit classes and uses dependencies that don't exist in this project.
You also cannot just copy/paste code from other projects.

[ST-DDT]

i replaced the Bukkit code, with none existing classes because there aren't any replacements available.
Missing dependencies could be added or if they won't be used they can be replaced, but this should give a first impresion how a chat API might look like.
It is a suggestion in the first place.
As the author i can do that, i even asked the other authors for permission to relicence it.

[Kiskae]

But it won't build, because ConfigurationSerializable, Achievement and ItemStack don't exist in sponge.
guava and apache-commons-lang also arent dependecies of the project.

[ST-DDT]

Shall i comment them all out or strip them entirely?
if 50% of the code is stripped we are back to plain strings.

I will update this PR if replacement classes are (partially) available and if someone makes a descission to either add the missing dependencies (tell me how i can add them properly) or states that the dependencies won't be added.

Don't try to compile it, look at it.

[turt2live]

Copy pasting is not the same as relicensing.

[ST-DDT]

Can you please explain my mistake to me?

[turt2live]

You took the code from other authors without permission and claimed it as yours in the commit. By open source logic, you have declared the other 2 authors involved as non-existent simply because they are not authors on the commit (which is not possible anyways).

[DarkArc]

We need them (the other authors) to come here and specifically say that they'll accept this is basically what turt is saying.

[ST-DDT]

Is listing them as authors not enough?
They gave their permission in the linked PR already.

[turt2live]

We need them to come here and specifically say that they'll accept this is basically what turt is saying.

This

[bendem]

Bukkit/Bukkit#1111 (comment) :-)

[turt2live]

@bendem That just says you are okay with it moving, not that you approve @ST-DDT to merge your changes under his name. Basically you need to sign off saying that you are okay with losing credit for your work.

[bendem]

Well, I contributed to the first pr. I only reviewed/merged the second one. So I don't mind ST-DDT taking credit for that. @Ribesg would be the one to ask.

[Ribesg]

I made the original PR with the help of @ST-DDT and @bendem, this second one is also done by us 3, based on this original PR and on @feildmaster's work.

I think that there is not much more than the 4 org.bukkit.chat to keep for SpongeAPI, as everything else is quite dependent on Bukkit. I don't mind @ST-DDT being the author of this PR, as he will be the one who will continue it and make it work on Sponge :p

Yeah, I'm not going to work on Sponge at the moment I think.

Note that the Bukkit PR will be added to Glowkit and implemented into Glowstone, but it may be extended with 1.8 features as Glowstone targets 1.8. Afaik Sponge will try to support 1.7, so maybe it isn't needed here. Also note that keeping the 4 main classes as they are will help implementing SpongeAPI in Glowstone at a later point.

[IDragonfire]

duplication of #15

[bendem]

It would be duplicated if it was the same implementation, this is another one and it is worth comparing them imo.

[turt2live]

@ST-DDT The build failed to complete. Please resolve this issue to have the PR reviewed further. Formatting will be checked.

[turt2live]

Missing period

[ST-DDT]

@ryantheleach Is there somewhere an definition page with the TextClickAction.Types?
http://wiki.vg/Chat does not list CHANGE_PAGE or TWITCH_USER_INFO.
It would be great if i could specify the data values (Classes) for those as well.

[ryantheleach]

I've ripped them straight from 1.8 mcp pre release code. Change_Page is used in books as links that change pages, and TWITCH_USER_INFO I assume is used for bringing up options for twitch users.

Change_Page is currently not used by chat at all, but is this API for text components or chat components? Should there be yet more interfaces for chat components that inherit from text components?

Twitch_User_Info is used by chat, but doesn't get sent by the server in normal circumstances, instead it is added to the chat window by the twitch integration. Regardless, the server still contains the code relating to this click event, so am unsure what the result would be of a server sending a twitch click event. This should probably be tested.

[Kobata]

TWITCH_USER_INFO and OPEN_FILE are unusable from the server under normal circumstances. The client is set to ignore anything with those actions coming from the server.

CHANGE_PAGE is used in book display, but has no function in chat.

[Ribesg]

This PR being originally a Bukkit PR, there was no client-side things in it. I'm not much into Sponge, but as Sponge will be on top of Forge AFAIK, I don't know if they should be added or not.

[ST-DDT]

@ryantheleach Can you please lookup the data value classes?
If those TextClickAction.Types are going to be added using proper classes would be important.

I will add them using the following assumptions:
CHANGE_PAGE = Integer
TWITCH_USER_INFO = String or UUID
OPEN_FILE = String
But we should change/verify that asap.

[ryantheleach]

@Kobata You are absolutely right. I missed that method. for some reason change_page is allowed in chat however...

@ST-DDT Minecraft uses strings for all the click events, regardless of type, I'm unsure if this would be wise to replicate, or if it could prove to be a problem in the future if something changes.

The twitch string is a twitch username, instead of a minecraft username as well.

I can't find an instance of change_page where it is used in the code where the field is populated with data, I assume the only place would be if a click event was generated by json de-serialization, or edited externally... but as I said earlier clickevent only ever uses strings.

[ST-DDT]

@ryantheleach ok i will change the data class of Twitch to String. Change Page stays as it is.
For future changes and extendability i will keep the underlying data Class an Objekt.

[ST-DDT]

I have a proposal on how to implement the score and selector message parts (mostly used by client)

First i will move the (localized) text stuff to a new class
MessasgePart -> SimpleMessagePart, LocalizedMessagePart
MessagePart will still exist but only as empty interface.
There will be a default implementation for all shared content for ___MessagePart called AbstractMessagePart or BasicMessagePart

Inheritance Overview
SimpleMessagePart, LocalizedMessagePart, ScoreMessagePart, SelectorMessagePart extends AbstractMessagePart implements MessagePart.

This will also allow custom message types.
But this also requires custom serialization, which leads me too my next proposal:

Message Serialization
MessagingService

• Message serialize(List or Array of JSON/String/Map<String,Object>)
• List or Array of JSON/String/Map<String,Object> deserialize(Message)
• void registerSerializer(MessagePartSerializer, Class<? extends MessagePart>)
• MessagePartSerializer getForClass(Class<? extends MessagePart>)

MessagePartSerializer

• MessagePart serialize(JSON/String/Map<String,Object>)
• JSON/String/Map<String,Object> deserialize(MessagePart)

Example Implementation:
https://github.com/ST-DDT/SpongeAPI/commit/9ae4ef468fdcfb92c95fb815c2ae6ccdd656dcb7

Feedback appreciated

[bendem]

What's the point of an empty interface if all the implementations extend only one abstract class? Just have MessagePart be abstract directly.

[ST-DDT]

Custom implementations may not need all the extra data that can be connected to a MessagePart (namely TextHover, TextClickAction, (insertion and extra))

[ryantheleach]

@ST-DDT when you say custom components, do you mean true custom components that would be sent to the client? Or would the custom components be able to be evaluated server side before sending to the client?

I had an idea that player specific formatting could be implemented as custom components by a plugin, then evaluated at the last moment by the server.

[ST-DDT]

Yes truly custom components.

Ill start writing the code for TextFormatting handler soon.

[maxov]

In order to consolidate this and other chat formatting PRs, I've decided to work on this on a branch of Sponge API at feature/chat. Specifically, most changes are in org.spongepowered.api.chat. I've made sure to keep account of all features in the current PRs, as well as simplify things a bit.

Here's what it will look like eventually:

RawMessage myMessage = new RawMessageBuilder()
  .setText("myText")
  .setStyle(TextStyle.AQUA.and(TextStyle.UNDERLINE).and(TextStyle.ITALICS))
  .setClickAction(clickActionFactory.openUrl("http://example.com/"))
  .addExtra(
    new RawMessageBuilder()
      .setText("otherText")
      .setStyle(TextStyle.RESET)
      .build()
  )
  .build();

I will also eventually replicate some of your Message.of methods and such, but I think you can see what the API will look like.