Kits

Discussion in 'Spigot Plugin Development' started by christianboo2, Jan 7, 2020.

  1. Whats the best way to create bulk kits? Use enums? create like a main class or something?? Im an idiot
     
  2. Please elaborate more, are you trying to write a plugin for your server?
     
  3. Yes? Why else would it be in plugin dev section
     
    • Friendly Friendly x 1
  4. depends on the design. if you know what all your kits are gonna be and plan to never change them unless you want to edit the code, then enums would be alright. personally id do objects that serialize so they can be changed whenever i feel like it
     
  5. Yea, theyre never gonna be changed... so enums?
     
  6. eh now that i think about enums, constructing them would be awfully annoying. and if you ever released it publicly, nobody else would be able to change anything without editting the source (rather than just adding onto it). id say objects are your best bet.
     
  7. Alright, whats the best way to do this in bulk? Like, theres a lot of kits. Also its never gonna be public and the kits will never change
     
  8. Have a List<Kit>, and Kit would hold all the data about the kit. You'd have children of Kit, but they'd all be used as Kit when using them in bulk. Also I asked for elaboration because it's not clear what you're trying to do tbh.
     
  9. Ok heres what i want clearly, as /kit command, but i need lots of kits, so is there an efficient way to do that
     
  10. Probably writing up a method that processes a list of itemstacks from a config relating to the specific kit.

    Ex:

    Code (Text):
    kits:
      overlord:
        0: //itemstack 0
          material: "DIAMOND_HELMET"
          //etc
        1: //itemstack 1
          material: "DIAMOND_CHESTPLATE"
          //etc
     
  11. in that case, objects would probably be better. although objects in the way im currently thinkign run into the same problem as enums.
    i think the quickest/easiest way that also ends up being the most resourceful would be to serialize objects. meaning establish a format for yml files to load kits from, such as
    Code (Text):
    helm: IRON_HELMET
    chest: LEATHER_CHESTPLATE
    # so forth
    and in your code, iterate through all of these files and create kit objects from the data these files contain. that way the code only has to do everything once (just variably), and you can modify and add and delete kits as you please.

    /e my format is assuming no additional item modifications. if there are, youd have to modify the structure to accommodate enchants and item names and lore and what not.
     
  12. I dont want to use config files, i want them hardcoded, so would i create a class for each kit or? Whats the best way.
     
  13. if you want to do it the extremely tedious way... id create 1 method for each kit with the player you wish to give it to as an argument, generate all the items and give them to the player how you want to.

    you could go the abstraction route but i think thats not really worth the effort based on how youre doing it.
     
  14. You'd have a KitGroup interface. Then you'd implement it inside the group classes, for example:

    KitGroup villagerKits = new VillagerKitGroup();
    KitGroup emperorKits = new EmperorKitGroup();

    where VillagerKitGroup and EmperorKitGroup both implement KitGroup.

    And inside the constructor those classes would initialize the Kit instances you need.

    Now Kit would also be an interface, and you'd have children of this interface being actual kits, like this:
    Kit startingVillagerKit = new StartingVillagerKit();
    Kit richVillagerKit = new RichVillagerKit();
     
  15. What? Do you have an example of this anywhere?
     
  16. idk what good kitgroups do, but hes going the abstraction route. basically you create an interface with the basic kit methods needed, and then create one class per kit that implements the interface and creates all the items and what not in the constructor, and the implemented method sets all the items to the player
     
    • Agree Agree x 1
  17. I think you need to read a little about OOP. Here's a guide that could be helpful.