Coding Bukkit Plugin Command doesnt do anything!!!

[olsyboy]

package me.olsyboy.spleef;

import org.bukkit.Bukkit;

import org.bukkit.ChatColor;

import org.bukkit.command.Command;

import org.bukkit.command.CommandSender;

import org.bukkit.plugin.java.JavaPlugin;

import org.bukkit.configuration.file.YamlConfiguration;







public class Main extends JavaPlugin {

    public void onEnable() {

        loadConfiguration();

        reloadConfig();

    }




    public void onDisable() {

        saveDefaultConfig();

    }




    public void loadConfiguration() {

        //See "Creating you're defaults"

        getConfig().options().copyDefaults(true); // NOTE: You do not have to use "plugin." if the class extends the java plugin

        //Save the config whenever you manipulate it

        saveDefaultConfig();

    }




    public boolean onCommand(CommandSender sender, Command cmd, String label, String[] args, String gameName) {

        if (cmd.getName().equalsIgnoreCase("spleef")) {

            if (args[0].equalsIgnoreCase("setgame")) {

                Bukkit.broadcastMessage(ChatColor.GREEN + "Message 2");

                if (args.length == 2) {

                    gameName = args[1];

                    String path = "GamesLocations." + gameName;

                    getConfig().addDefault(path, "I did!");

                    getConfig().options().copyDefaults(true);

                    saveConfig();

                }

            return false;

            }

        }

        return true;

    }

}

name: Spleef
version: 1.0
author: olsyboy
main: me.olsyboy.spleef.Main

commands:
spleef:
    description: The Spleef Command
    permission: spleef.spleef
    usage: Type /spleef to use the Spleef commands

It should do something on /spleef, but it just shows what I have put in plugin.yml!!

Please help!

 

[alyphen]

You can't just add parameters to onCommand - since onCommand overrides the method in JavaPlugin by the same name, it must be exactly the same (CommandSender sender, Command command, String label, String[] args)
Adding gameName means the method signature is different. If you're taking the game name from what the user specifies, you want to assign gameName after validating your arguments. It looks like you've done this in addition to adding it as

From what you've written, I believe something like the following may achieve what you want (if you want to learn from this, make sure to at least write it out by hand and make sure you understand each statement. I've heavily commented it, so it should be fairly easy to grasp):

package me.olsyboy.spleef;

import org.bukkit.Bukkit;
import org.bukkit.command.Command;
import org.bukkit.command.CommandSender;
import org.bukkit.plugin.java.JavaPlugin;
import org.bukkit.configuration.file.YamlConfiguration;

// This import allows us to use ChatColors without specifying the ChatColor prefix. (used with enumerative types (enums) and classes that include static variables & methods)
import static org.bukkit.ChatColor.*;

public class Main extends JavaPlugin {

  public void onEnable() {
    // Saves the default configuration if it does not yet exist
    saveDefaultConfig();
    // Copies default options from internal file config.yml if they do not exist in plugins/Spleef/config.yml
    getConfig().options().copyDefaults(true);
  }

  // onDisable removed since saving the default config on disable doesn't make any sense - if you need the default options, you need them upon enabling.

  // loadConfiguration method removed due to misleading method name and only being two lines long anyway (not really enough to justify a method, and not re-used outside of onEnable)

  public boolean onCommand(CommandSender sender, Command cmd, String label, String[] args) {
    if (cmd.getName().equalsIgnoreCase("spleef")) {
    // Check we actually have an argument before playing with args[0]
      if (args.length >= 1) {
        // Check the argument is what we want
        if (args[0].equalsIgnoreCase("setgame")) {
          // Broadcast this questionably obscure message to all players. Avoid using static references wherever possible.
          getServer().broadcastMessage(GREEN + "Message 2");
          // Check we have at least 2 arguments before saving a game location
          if (args.length >= 2) {
            // Declare and initialise gameName as a variable local to me.olsyboy.spleef.Main.onCommand
            String gameName = args[1];
            // Set the game location (not as a default, just the current value)
            getConfig().set("GamesLocations." + gameName, "I did!");
            // Save the in-memory version of the config back to disk
            saveConfig();
            // Send the command sender some feedback!
            sender.sendMessage(GREEN + "Set game location for " + gameName);
          } else {
            // What went wrong? Tell the player!
            sender.sendMessage(RED + "Please specify a game name.");
          }
        } else {
          // What went wrong? Tell the player!
          sender.sendMessage(RED + "Unknown argument! Try \"setgame\"");
        }
      } else {
        // What went wrong? Tell the player
        sender.sendMessage(RED + "Please specify an argument (such as \"setgame\")");
      }
    }
    // No else because we ignore commands that are not "spleef" here
    // Always return true to avoid getting any Bukkit-generated jargon sent to the player. We create our own (player-friendly!) error messages.
    return true;
  }

}

 

[NanoNet]

You can't just add parameters to onCommand - since onCommand overrides the method in JavaPlugin by the same name, it must be exactly the same (CommandSender sender, Command command, String label, String[] args)
Adding gameName means the method signature is different. If you're taking the game name from what the user specifies, you want to assign gameName after validating your arguments. It looks like you've done this in addition to adding it as

From what you've written, I believe something like the following may achieve what you want (if you want to learn from this, make sure to at least write it out by hand and make sure you understand each statement. I've heavily commented it, so it should be fairly easy to grasp):

package me.olsyboy.spleef;

import org.bukkit.Bukkit;
import org.bukkit.command.Command;
import org.bukkit.command.CommandSender;
import org.bukkit.plugin.java.JavaPlugin;
import org.bukkit.configuration.file.YamlConfiguration;

// This import allows us to use ChatColors without specifying the ChatColor prefix. (used with enumerative types (enums) and classes that include static variables & methods)
import static org.bukkit.ChatColor.*;

public class Main extends JavaPlugin {

  public void onEnable() {
    // Saves the default configuration if it does not yet exist
    saveDefaultConfig();
    // Copies default options from internal file config.yml if they do not exist in plugins/Spleef/config.yml
    getConfig().options().copyDefaults(true);
  }

  // onDisable removed since saving the default config on disable doesn't make any sense - if you need the default options, you need them upon enabling.

  // loadConfiguration method removed due to misleading method name and only being two lines long anyway (not really enough to justify a method, and not re-used outside of onEnable)

  public boolean onCommand(CommandSender sender, Command cmd, String label, String[] args) {
    if (cmd.getName().equalsIgnoreCase("spleef")) {
    // Check we actually have an argument before playing with args[0]
      if (args.length >= 1) {
        // Check the argument is what we want
        if (args[0].equalsIgnoreCase("setgame")) {
          // Broadcast this questionably obscure message to all players. Avoid using static references wherever possible.
          getServer().broadcastMessage(GREEN + "Message 2");
          // Check we have at least 2 arguments before saving a game location
          if (args.length >= 2) {
            // Declare and initialise gameName as a variable local to me.olsyboy.spleef.Main.onCommand
            String gameName = args[1];
            // Set the game location (not as a default, just the current value)
            getConfig().set("GamesLocations." + gameName, "I did!");
            // Save the in-memory version of the config back to disk
            saveConfig();
            // Send the command sender some feedback!
            sender.sendMessage(GREEN + "Set game location for " + gameName);
          } else {
            // What went wrong? Tell the player!
            sender.sendMessage(RED + "Please specify a game name.");
          }
        } else {
          // What went wrong? Tell the player!
          sender.sendMessage(RED + "Unknown argument! Try \"setgame\"");
        }
      } else {
        // What went wrong? Tell the player
        sender.sendMessage(RED + "Please specify an argument (such as \"setgame\")");
      }
    }
    // No else because we ignore commands that are not "spleef" here
    // Always return true to avoid getting any Bukkit-generated jargon sent to the player. We create our own (player-friendly!) error messages.
    return true;
  }

}

Little off topic- but what defines a methods signature? I was told It was it's name, and the parameters in which it takes. Is this true?

 

[not2excel]

Little off topic- but what defines a methods signature? I was told It was it's name, and the parameters in which it takes. Is this true?

name, parameters, and return type

 

[alyphen]

Little off topic- but what defines a methods signature? I was told It was it's name, and the parameters in which it takes. Is this true?

name, parameters, and return type

NanoNet is correct here, two methods different return types but the same name and parameters (in Java at least) will have the same method signature.

 

[not2excel]

NanoNet is correct here, two methods different return types but the same name and parameters (in Java at least) will have the same method signature.

Actually, that's only correct for compilation usage. However, bytecode wise, the return type is included as part of the sig. eg. Ljava/lang/String/length()I
As for compilation it will drop the return type and only respect the first part.

You can hackishly get the jvm to comply with multiple methods that purely differ in return type. However, at that point, you're already enforcing type inference and you should just be using a language that supports it.

 

[not2excel]

Can't edit lol.

Anyways disregarding the bytecode level fun you can have, you are correct. (in terms of source only)