Replacing parts of chat messages

I'm trying to automatically replace words in a chat message with other words. Here is what I have:

Code:java

 
  @EventHandler(priority=EventPriority.LOWEST)
  public void AntiIdiot(AsyncPlayerChatEvent event, String message)
  {
 if(message.contains("budder")){
 message = message.replace("budder", "gold");
 }
 

I wasn't really sure how to go about doing this so I just took a shot at it. It doesn't work. How should I be doing it?

 

Don't make a message parameter (don't make any extra parameters when creating an event method), just use event.getMessage().

 

Something like that:

Code:

    @EventHandler(priority=EventPriority.LOWEST)
    public void AntiIdiot(AsyncPlayerChatEvent event)
    {
        String message = event.getMessage();
        message = message.replace("budder", "gold");
       
        event.setMessage(message);
    }

 

larperdoodle

Code:

@EventHandler(priority=EventPriority.LOWEST)
          public void AntiIdiot(AsyncPlayerChatEvent event){
            String msg = event.getMessage();
            if(msg.contains("budder")){
 
                msg.replace("budder", "gold");
               
               
               
               
            }

 

That doesn't work.

 

larperdoodle Listen to what Pr07o7yp3 told you. It should work.

 

you have to do:
@EventHandler (priority=EventPriority.HIGHEST)

 

whereisthemonkey
You are implying that the code will not work at any other priority, which is incorrect. Simply leaving it at a normal priority would probably be sufficient for the code to run.

bitWolfy JoTyler
The priority in Pr07o7yp3 's code is set to LOWEST. If other plugins are present and utilise the AsyncPlayerChatEvent on the test server, it is almost certainly guaranteed the code will not function. LOWEST Priority is well, exactly that; it's of the lowest priority. If the server saw several events of the same type, it would run them in the following order:

LOWEST
LOW
NORMAL (default)
HIGH
HIGHEST
MONITOR

The compiler runs the lowest events first. Then checks if any Low priority events wants to override the outcome. Then it checks if any Normal events want to override ... etc.

So theoretically, shouldn't we all use MONITOR all the time? NO. Monitor is a bad practice and its intent is to serve as loggers to see the outcome of an event without altering it.

I hope this clarifies the issue.

 

I agree 100% in this instance, but not when the event implements cancellable . If I listen on LOWEST on say the BlockBreakEvent and cancel it all others above me are stuffed. I know you know this I was more point out to anybody else that might benifit, you need to choose your priority carefully and also consider carefully when cancelling events, as this can have an impact on other plugins. Not to say you shouldn't be cancelling, but certainly shouldn't be considered standard practice.

 

Relicum
Actually cancelling on LOWEST doesn't mean the event won't be called on LOW.

If you cancel on LOWEST, the compiler first check if the event is uncancelled on LOW, NORMAL, HIGH, HIGHEST and MONITOR, and if there is any conflict, it will side with the highest priority.

 

AoH_Ruthless sorry going to have to challenge you on that and provide me with that your basing that on as that violates the contract of the Cancellable interface. While it will still get passed but the event will not be run. Not trying to have a row lol just don't agree with your past post. But I will admit if you can show me evidence I will hold my hands up.

 

Relicum
http://forums.bukkit.org/threads/getting-your-priorities-straight-the-plugin-version.788/

 

@AoH_Ruthless I am not worthy. I are 100% correct. What gets me is not being wrong, its the fact that 2 experienced dev's convinced me what I was saying was correct. I am a JavaDoc fanboy, and use them extensively as Java has so many packages and classes I like to learn what it has to offer. Same with the Bukkit Docs. There is no mention or the overriding of cancelled events, just the Cancellable interface is not being enforce. The whole point of an Interface is you can rely of the implementing contract being upheld. It comes to something when you have to bit out 3 year old forum posts, we should not be using forums as a source of important information like that.

I have just been testing it all out. While highest can override, it doesn't stop lowest from making any changes not connect to the event in my case block break. I can save to file, switch gamemodes then cancel the event all in lowest. and highest sets canceled to false as you explain you override my lowest and allow blocks being broken, it could do nothing to stop me doing anything else. I am going to test out having lowest remove the block and replace it with air and see what can get round. As it is looking like it has some weird bugs/logic in the entire event system.

Thanks for accepting the challenge, at least I know now for the feature.

 

Relicum
What?