Library NetworkUtilities - 6 Line Command System!

Discussion in 'Resources' started by olivervscreeper, Nov 28, 2014.

Thread Status:
Not open for further replies.
  1. Offline


    Hello There!
    I've just finished the first public release of NetworkUtilities. It's a very lightweight, easy to use system for controlling all of your Bukkit plugins.
    For example, to make a /feed command - simply:
    1. Add the plugin to your server
    2. Add it to the class path of your plugin
    3. Add the following to your plugin:
    1. CommandManager manager = newCommandManager(this);
    2. manager.registerCommands(this.getClass());
    4. @Command(command = "feed")
    5. public static void feed(Player player, List<String> args){
    6. player.setFoodLevel(20);
    7. }

    You'll have a new Command, without the need to add it your plugin.yml, or anything! It's that easy.

    You can make block breaking OP only with just:
    1. getServer().getPluginManager().registerEvents
    2. (new BlockBreakHandler
    3. (new OPPermissionSet()), this);

    Wiki: Plugin

    Please let me know what you think, and any feedback. If you end up using it, please tell me how you get on.
  2. olivervscreeper
    That's neat, but I've seen a few similar ones, especially the command thing.

    And the wiki seems to inaccessible. "You do not have access to the wiki. Use the links at the top to get back.".
  3. Offline


    There are lot's more features, shame you couldn't see the Wiki, that's the hub for it all. Take a look now - what do you think of it?
  4. Offline


    This is cool, like a faster version of the bukkit API?
  5. Offline


    Much Faster, slightly quicker at runtime in some aspects, but most importantly, your code will be sooo much smaller! You could make blockBreaking only for OP's with just one line of code.
    ChipDev likes this.
  6. Offline


    I don't see how it's any faster than the Bukkit API if you're just calling the Bukkit API to begin with
    Several other issues:
    • If you're going to create dynamic commands (i.e commands that circumvent plugin.yml), you would want to get a hold of a Command object (either by extending Command in a new class or reflection or etc.) and register that. Using the command preprocess may be neat for now, but what if another plugin has the same command name as yours? Now you're just overriding their command no matter what. I believe you could do /<pluginName>:<commandName>, but don't quote me on that.
    • Every time a player does a command and it is registered with your library, you loop through every method. While this shouldn't be much of a problem, it can hinder performance if you have a lot of methods within a single class. I suggest you use a Map<String, Method> and then cache the method instead.
    • I'm not really sure what the use of the *Handler class is for. It looks like you're just filtering listeners out based on their priority by using the setCancelled() method...?
      edit for handler one: I looked at the source code a bit more; it kinda makes sense, but why do you listen on every level? If you want to go the extra mile, you could use hacky reflection to do it at runtime.
    • The PermissionSet is a nice feature, but why store the UUID in it's string format?
    • Why do you log that you're starting up? Bukkit already handles this. Plus, the compatibility line isn't necessary as you don't access any NMS or OBC classes.
    • Agh; Singleton pattern. You need to wipe the variable named plugin along with command in onDisable so that the GC can grab it when the plugin is disabled.
Thread Status:
Not open for further replies.

Share This Page