Solved Using sender.sendMessage in secondary class files

I'm trying to issue a sender.sendMessage in a class file that holds all my methods. However, whenever I run it, I get an error (org.bukkit.command.CommandException: Unhandled exception executing command 'test').

I've imported:
import org.bukkit.ChatColor;
import org.bukkit.command.Command;
import org.bukkit.command.CommandSender;
import org.bukkit.plugin.java.JavaPlugin;

and when I call something, such as this
(I have defined CommandSender sender; in this class file)

Code:

public void test() {
     sender.sendMessage("test");
}

in my main class file
TestClass sample = new TestClass();

Code:

 if (cmd.getName().equalsIgnoreCase("test")) {
      sample.test();
}

This results in the error; however, if I put all of my sender.sendMessages into my main class file, then everything works.

 

Who's sender? You can't just do it like that. You would have to do something like:

Code:

public void test(CommandSender sender){
        sender.sendMessage("Test");
        return;
    }

Then you call this by doing:

Code:

if (cmd.getName().equalsIgnoreCase("test")) {
    test(sender);
}

notes: sender is the CommandSender.
public boolean onCommand(CommandSender sender, Command cmd,
String label, String[] args) {

 

DoggyCode said it perfectly, but in your case, you are probably trying to store the CommandSender in your new class, so make sure to assign "CommandSender sender" properly in a constructor or in a setter method before you try and use it.

 

Would it not be safer to store/send the Player object rather than the sender (given that sender is an extension of Player)
Or even the UUID?

Anyone with more info on this?

 

It doesn't matter what you store it as. A Player is always a Player no matter what you reference it as. If the object that stores the CommandSender or Player isn't stored, then you should be good. The object and the Player (if not stored anywhere else) can be safely garbage collected.

 

@teej107
Well that's true on the Sender point, but storing as a UUID allows usage through logins
Cheers

 

@Scimiguy storing the UUID would be a good option, but would be reliant on whether archie is using CommandSender for just players, as it could be the console as well. Either way, it all depends on how the class is being used.

 

@CoolDude53
Ah yeah, can't cast to player if it's console either -- totally forgot about that one

 

Who said anything about this needing to last through logins?

 

@teej107
No-one
The question wasn't really even about this topic, It was more a personal curiosity relating to storage of extended mutable objects

 

Thanks for the help guys. I don't really care to store UUID's since this doesn't actually store data (yet).