Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API8 - Improve PlayerChatEvent #2340

Merged
merged 1 commit into from
May 23, 2021
Merged

API8 - Improve PlayerChatEvent #2340

merged 1 commit into from
May 23, 2021

Conversation

Faithcaio
Copy link
Contributor

@Faithcaio Faithcaio commented May 1, 2021

SpongeAPI | Sponge
#2259

  • adds an easy way to filter Audiences for MessageChannelEvent.
  • PlayerChatRouter -> PlayerChatFormatter now only handles message formatting. Which is applied to each audience of a ForwardingAudience
  • PlayerChatEvent extends MessageChannelEvent to handle the audience target replacing PlayerChatRouter

@ImMorpheus ImMorpheus added api: 8 (u) version: 1.16 (unsupported since Oct 17th 2023) status: needs review status: needs testing type: feature request A feature request labels May 1, 2021
@dualspiral dualspiral linked an issue May 3, 2021 that may be closed by this pull request
@dualspiral
Copy link
Contributor

I've been talking to Faith about this as it's been done and this is a step up from where we were.

I do have a couple of thoughts on a slightly different approach and any feedback/thoughts on this would be welcome.


For this, the intention is that chat formatters are chained. Would a list of formatters that are then executed in order, rather than chained, be better here. My thought was that plugins could inspect the formatters that other plugins have applied and make decisions based on that, so if I detected a chat router that came from UltimateChat, via some heuristic, for example, I might not want to apply mine at all. It should also be possible for a plugin to clear formatters from this list too

That might be complicating it a bit though. I don't mind not doing this, it's just an alternative, but it might not be all the useful.


Protection plugins, such as GriefDefender, may only care about the end result of a message. Rather than having to go and execute the chat formatter on every audience manually, is there merit to create a second "post but not post" event after the formatting has been resolved? Something like:

interface PlayerChatEvent extends Cancellable {

    interface Format extends PlayerChatEvent {
        // this would be what we have now
    }

    interface Formatted extends PlayerChatEvent {

        /*
         * The Audiences that will recieve a message, and their respective message
         */
        Map<Audience, Component> messages();

        /*
         * Protection plugins could stop certain messages getting through to specific
         * audiences
         */
        void filter(Audience audience);        

    }

}

Protection plugins etc. that really only care to cancel something may appreciate this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: 8 (u) version: 1.16 (unsupported since Oct 17th 2023) status: needs review status: needs testing type: feature request A feature request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rethink PlayerChatRouter
4 participants