Ideas wanted :)

Discussion in 'Spigot Plugin Development' started by Rasturize, Jul 15, 2018.

  1. If your just starting in Spigot Plugin Development, you will want to learn the Api. So go over to the wiki and look at all the methods, events etc, and try learn use those by learning what each do. What i'm meaning is creating small plugins that utilize each class. meaning you will learn along the way how they act in game. This way when you come to creating things, you will know the best ways to do things, and how to do things since you would've learned each aspect of the Spigot Api Classes.
     
  2. First thing I ever made was a random tp (/wild) plugin, Imo they are a good thing to start with just because you can start with something super basic and learn all of the fundamentals of coding spigot plugins by building on that plugin. You can learn configs by adding ranges or a world to take you to or whatever, you can learn guis by making it so there are a few range options you can select, you can learn vault integration by making teleporting cost X amount, you can learn worldedit integration and listeners by making a inbuilt portal system, learn how to set up cooldowns, use listeners and repeating tasks to cancel the teleport if a player moves etc. I think its a good thing to start with rather than doing 10 mini projects that cover 1 thing each although wild plugins aren't that hard they include most of the basic level stuff you need to know to make plugins.

    Daniel and rasturize we got the whole squad here :p
     
    • Friendly Friendly x 2
  3. No they aren't. The most powerful command frameworks (for example, the one in MassiveCore) use static to an extent, but the OOP allowed lets the commands automatically implement many different checks and functions. It automatically assigns permissions, gets Objects (Players, Locations, Factions, etc) from string arguments, generates usage paired with aliases, descriptions etc, all with very minimal work required.

    On the surface, it may seem that static is more convenient. To an extent, it's true. But for something that's really much more effortless, very well made OOP wins it by a longshot. It compresses multiple lines of code into singular, understandable lines and is highly simple to modify, much more so than static.

    Additionally, static shouldn't be used as a trick card. When using static, a lot of fields and methods end up needing to be hardcoded in some way. Let's say we don't use OOP for the command framework at all. That means we need to do this:
    Code (Java):
    if(command.getName().equalsIgnoreCase("itembox")){
                if(args.length == 0){

                    displayHelp(sender);
               
                }else if(args[0].equalsIgnoreCase("open")){
                    CommandOpen.runCommand(sender, args);
                }else if(args[0].equalsIgnoreCase("send")){
                    CommandSend.runCommand(sender, args);
                }else if(args[0].equalsIgnoreCase("claimall")){
                    CommandClaimAll.runCommand(sender, args);
                }else if(args[0].equalsIgnoreCase("givedynamicbox")){
                    CommandGiveDynamicBox.runCommand(sender, args);
                }else if(args[0].equalsIgnoreCase("givealldynamicbox")){
                    CommandGiveAllDynamicBox.runCommand(sender, args);
                }else if(args[0].equalsIgnoreCase("sendall")){
                    CommandSendAll.runCommand(sender, args);
                }else if(args[0].equalsIgnoreCase("additemtodynamicbox")){
                    CommandAddItemToDynamicBox.runCommand(sender, args);
                }else if(args[0].equalsIgnoreCase("reload")){
                    CommandReload.runCommand(sender, args);
                }else{
                    displayHelp(sender);
                }
            }
    It's fine for something short, but it's ultimately not sustainable. For example, we want to add an alias, or we want to modify permissions. Additionally, we need to repeat code in each and every class with the static run method - we need to retype permissions checks, argument checks etc.

    Summary: Static is good in some places. It's useful for a tiny project for fast progress. But for a large scale project, it's very limiting and can lead to messiness due to violating DNRY rules (Do not repeat yourself), reduces your ability to go back and edit previously done work and finally does not make it easier for you to directly add new features (highly similar work must be repeated)

    However, since OP is practising, it may be more beneficial to learn this. Everybody can do static, it's easy. OOP is a slightly more abstract concept for beginners

    EDIT:
    This is an example of my own OOP commandhandler (handles about 20 commands)
    Code (Java):
    SkillsCommand command = null;
            if(!commands.containsKey(args[0].toLowerCase())){
                if(!alias.containsKey(args[0].toLowerCase())){
                    commands.get("help").runCommand(sender, args);
                    return;
                }
                command = alias.get(args[0].toLowerCase());
            }else{
                command = commands.get(args[0].toLowerCase());
            }
            if(command.hasPermission(sender)||sender.isOp()){
                command.runCommand(sender, args);
            }else{
                sender.sendMessage(Skills.get().languageManager.parseFirstString(Languages.Misc_No_Perm_Error));
            }
    It's not perfect, I can definitely make it more efficient and cut down on more redundant things (...and also not use some static because I'm lazy), but it's an example of how it helps make your code more sustainable than compared to static frameworks.
     
    #23 Hex_27, Jul 17, 2018
    Last edited: Jul 17, 2018
    • Agree Agree x 1
  4. This makes sense to me, going to probably recode what I've done so far using this. Thanks everyone so far!