User Input After Command

Discussion in 'Spigot Plugin Development' started by Daeshan, May 30, 2016.

  1. So this may be simple or hard but basically, I want to make a command that when a player types /achievement create it will send them a message saying, please input the name of the Achievement then from there you press enter then it asks for the description, then the reward and so on. So I need to know how to get the user input after a command has been entered.
  2. Set (a Boolean) enabled and every time they chat check if that (Boolean) is enabled and if so set the other stuff
  3. please explain just a tad more, I think I get what you mean but not quite 100%
  4. Im confused as to what this it, I looked this over but 90% of it is in spanish
  5. When they run the command, set a Boolean to true. If, in your example, you are using multiple answers after the command, I would use an Integer instead. With the Integer set it to += 1. Then, every time they chat, check the number in a switch statement, and for the one it matches do the stuff, +=1 again, then break of course. Hope this helped :3
  6. I've given you an example, you just need that.

    I'ts Portuguese.
  7. This is how I do it.

    1. Make an ArrayList
    2. When players type the command add their name to ArrayList
    3. On AsyncPlayerChatEvent, if the ArrayList contains the player's name, then get their message and turn it into an achievement and remove the player from the ArrayList (remember to cancel event)
    4. Optional If you want to cancel it, just listen if the player is in the ArrayList, if their message contains "cancel" then remove them from ArrayList (remember to cancel the event)
    5. Make a leave listener and if a player leaves, remove them from the ArrayList
    • Agree Agree x 1
    • Funny Funny x 1
  8. Using multiple lists for something that can be associated with one object is kind of pointless, use OOP design and create a class to handle everything for you.

    Personally, I would create a class that has a boolean and enum field. The enum field for where you're storing the state at which the player is in the command process. On chat, check if they're in the command (the boolean field) and if they are handle the input and progress their state. If they reach the end, take them out of the command.

    Basic OO structure, I would recommend that you brush up on it.
  9. Never done that kind of style so my brush up will be learning, I am a very basic coder, big ideas but little knowledge right now. I'll look into this tmrw and see if I can get it, if not I'll be sure to post back in here. Don't mind drop some hint code! Thanks guys, Dae
  10. TS, check this out.
  11. #12 Bimmr, May 30, 2016
    Last edited: May 30, 2016
    • Winner Winner x 1
  12. Use a PlayerChatEvent and some ArrayLists?
  13. Enum? You only need 2 enums which is basically a boolean, the boolean field doesn't even need to check the Enum, it just needs to be True or False. You shouldn't have to create a new class. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction.". I'm no 100% full-time experience Java developer. But for the sake of people looking over your code and trying to understand, or in this case someone who is most probably new and doesn't know where to start, this method is way more simpler, and works the exact same way yours does.
  14. It must also take a touch of genius to move away from what Java is designed for. It is Object-Oriented. If you have several things that are associated with one Object, then you should create your own Object to handle it for you. If that's what you want to go for, then by all means feel free to go so far outside of the box that what you're proposing goes against what the language was designed to do.
    OO design is very simple to understand, and I guarantee that many forum users who are more experienced than I (FlyingLlama, Spottedleaf, 1Rogue [not going to tag them, they aren't involved]) would definitely agree with me. Instead of having 8 lists, you can have an Object that modifies states. I'm not sure what's too difficult about that.
    It does, for the most part, work the same way. I've already gone on a rant above on why they're different. The one thing I will definitely agree with you on is that your method is undoubtedly the simplest. But, after fixing this really, really inefficient developer's code for my employer, I would have to say that just because it's simpler doesn't make it better.
    Code (Text):
    package *name removed for obscurity*;

    import java.util.ArrayList;
    import java.util.HashMap;

    public class Lists {

        public static HashMap<String, Integer> *name removed for obscurity* = new HashMap<String, Integer>();
        public static HashMap<String, Boolean> *name removed for obscurity* = new HashMap<String, Boolean>();
        public static ArrayList<String> *name removed for obscurity* = new ArrayList<String>();
        public static ArrayList<String> *name removed for obscurity* = new ArrayList<String>();
        public static HashMap<String, Double> *name removed for obscurity* = new HashMap<String, Double>();
        public static HashMap<String, Double> *name removed for obscurity* = new HashMap<String, Double>();
        public static HashMap<String, Double> *name removed for obscurity* = new HashMap<String, Double>();
        public static ArrayList<String> *name removed for obscurity* = new ArrayList<String>();


    (I don't want to reveal any of our current projects yet, so "*name removed for obscurity*")
    That ^ is a piece of code (literally, all I did was change the variable/package name) in which he handled all data for a Player. He took the name, and stored it in those List/Map objects. He showed absolutely no structure of OO design, and after I was done fixing his crap, his 4k line listener class was cut down to 400 lines with an OO structure. The method I suggested severely outweighs using Collections for storing things that could go in fields, and if you don't realize that now, you will later.
  15. Fair enough, I used Object-Oriented with my projects, getting Teams data from a config, SQLite file, or MySQL and putting it into a class, as well as GamePlayer, etc. but with this I felt that it was such a simple thing, and it wasn't storing a player for the duration of the server time. It was just something really quick that was such a minor feature that it wasn't worth paying attention to dedicate a whole class to it.