PlayerQuitEvent on server shutdown.

Discussion in 'Plugin Development' started by Minecraft Frontiers, Jan 13, 2015.

Thread Status:
Not open for further replies.
  1. When I shutdown the server using the /stop command, the PlayerQuitEvent doesn't get called. Nor does the PlayerKickEvent.

    Is that how it is meant to work?

    Also, is there any event dedicated specifically to server shutdown?
     
    GrandmaJam likes this.
  2. Offline

    Krizeh

    Code in the onDisable() method located in your Main class gets ran when the plugin is disabled.
    So when the server is reloaded the code in the onDisable() will run.
    If the server gets shut down using /stop the code in the onDisable() will run too.



    Code:
        public void onDisable() {
            for(Player on:Bukkit.getServer().getOnlinePlayers()){
                on.kickPlayer(ChatColor.RED + "The server is restarting please reconnect.");
         
         
            }
    If you don't want players getting kicked on reload you could create a boolean and set it to true when a player with the correct permissions types /stop using a PlayerCommandPreprocessEvent and in the onDisable() check if the boolean is true and if it is then kick players. That way it won't kick players on reload.

    Boolean:

    Code:
          public static boolean stop = false;
    EventHandler:

    Code:
        @EventHandler
          public void onCommand1(PlayerCommandPreprocessEvent e) {
              String args[] = e.getMessage().split(" "); 
              Player p = e.getPlayer();
              if (args[0].equalsIgnoreCase("stop")) {
                  if (p.hasPermission("server.stop")) {
                      Main.stop = true;
                      
    onDisable():
    Code:
        public void onDisable() {
        if (Main.stop) {
            for(Player on:Bukkit.getServer().getOnlinePlayers()){
                on.kickPlayer(ChatColor.RED + "The server is restarting please reconnect.");
         
         
            }
     
    Last edited: Jan 13, 2015
    Minecraft Frontiers likes this.
  3. Offline

    SuperOriginal

    @Krizeh You really love spoonfeeding with no explanation. Please stop.
     
    mine-care, Regablith and Krizeh like this.
  4. Offline

    Skionz

    @Krizeh Static? Why not an accessor method?
     
    mine-care, Regablith and Konato_K like this.
  5. Offline

    SuperOriginal

    @Skionz Because it magically makes anything accessible anywhere.. And class semantics and industry standard don't matter

    ....Obviously
     
    teej107, Krizeh and Skionz like this.
  6. Offline

    teej107

    Really? I thought the public modifier did that and not static.


    @Minecraft Frontiers A quick google search and I found this: http://bukkit.org/threads/servershutdown-event.87125/. I'm just wondering what do you need to do when the server shuts down?
     
    mine-care and Regablith like this.
  7. Offline

    SuperOriginal

    @teej107 They're better off together so you don't even need an instance to access it!
     
  8. Offline

    teej107

    @SuperOriginal Should made my statement look more jokingly. But static isn't an access anywhere modifier.
     
    SuperOriginal likes this.
  9. Offline

    Regablith

    Learn to use instances.
     
    GrandmaJam likes this.
  10. Offline

    mythbusterma

    @Regablith

    His post was sardonic. Learn to interpret tone.
     
    SuperOriginal likes this.
  11. Offline

    unrealdesign

    @teej107 @SuperOriginal @Skionz His way of accessing the boolean "stop" is fine if it is only set by the programmer. Although, it should be set to final. If you want to be purely professional, then yes, he should make a separate handler class that deals with these types of variables and make the variable name in all caps, but if he just made it final, then what he did would be fine.
     
  12. Offline

    teej107

    ZodiacTheories likes this.
  13. Offline

    unrealdesign

    In real world development, this is fine, and preferred. This is what I was describing.
    Code:
    public class PermissionHandler
    {
        //Permission to allow a player to pvp
        public static final String PVP = "plugin.pvp";
      
        //Permission to place a block
        public static final String PLACE_BLOCK = "plugin.block.place"
    }
    Second of all, a static variable for such a type isn't a terrible idea because you don't want multiple instances for a variable like that. What if you have two instances of the class that handles that and one is set to true and the other is false. Obviously he could have handled it better than that, but his basic understanding of the usage of static is okay in this situation.
     
  14. Offline

    teej107

    Isn't everything set by the programmer? Also, an immutable boolean field. That sounds genius!!!!!!!!!!!!!!!!!!!
     
    ZodiacTheories likes this.
  15. Offline

    SuperOriginal

    @teej107 I was making an elegant post on my iPad until you Ninja'd me. Thanks mate

    But to add on, the variable isn't constant, it changes depending on the command

    @unrealdesign
     
    teej107 likes this.
  16. Offline

    unrealdesign

    Why does this forum have to be so condescending? You just come off as an ass and the whole purpose of this forum section is for getting help. Also, that's like asking me why a immutable string is important. It has certain instances where it is important. Anyways, one reason it is helpful is for testing purposes. So you don't have to constantly comment out your code. So for example, in onDisable(), he doesn't have to keep commenting out the line. In many cases it could be more than one line, so constantly having to enable and disable a part of your code is very helpful by having a immutable boolean.

    Sorry, I did not read carefully enough to notice it was changing with a command. So then obviously it cannot be final. Having it be static is fine, but yes, having a static getter method would be better suited.


    @teej107 Sorry, forgot to answer the first part of your question. What I meant by that was after it was initially set. So if it was changed after the program was run by a input from a user.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 13, 2016
    RunsWithShovels likes this.
  17. Offline

    teej107

    An immutable boolean field is unneeded. Also having a getter method for a public field is also not needed. Sorry for being a little mean but people here need to understand Object Oriented Programming and Encapsulation. It is all part of (what I consider) basic Java which you should have when developing plugins. Half the people in this section can't even create a plugin properly because they misuse static.
     
  18. Offline

    unrealdesign

    @teej107 I get where you're coming from. I just think having a little patience or just telling people straight up to learn Java before posting here is better than being satirical. And yes, when I said he should have a getter method, I meant for him to make it private. I thought that was a given :p

    Anyways, kind of off-topic, but I think this could help others who are reading through. Here is why something like:
    Code:
    public static final boolean stop = false;
    is useful. I'll give you an actual example for when I sometimes use to debug code.

    Code:
    public class DebugLog
    {
        private final static boolean DEBUG = true;
       
        public static void log(String message)
        {
            if(DEBUG)
            {
                String fullClassName = Thread.currentThread().getStackTrace()[2].getClassName();
                String className = fullClassName.substring(fullClassName.lastIndexOf(".") + 1);
                String methodName = Thread.currentThread().getStackTrace()[2].getMethodName();
                int lineNumber = Thread.currentThread().getStackTrace()[2].getLineNumber();
               
                System.out.println("[StrongTurrets] "+ className +"."+ methodName +"():"+ lineNumber +" - "+ message);
            }
        }
       
        public static void log(Object o)
        {
            if(DEBUG)
            {
                String message;
                if(o == null)
                    message = "null";
                else
                    message = o.toString();
               
                String fullClassName = Thread.currentThread().getStackTrace()[2].getClassName();
                String className = fullClassName.substring(fullClassName.lastIndexOf(".") + 1);
                String methodName = Thread.currentThread().getStackTrace()[2].getMethodName();
                int lineNumber = Thread.currentThread().getStackTrace()[2].getLineNumber();
    
                System.out.println("[StrongTurrets] "+ className +"."+ methodName +"():"+ lineNumber +" - "+ message);
            }
        }
    }
    
    So in this example, I have this simple class to help me have a quick debug helper class that I can user statically anywhere in any class. So as you can obviously see anywhere in my code I can do "DebugLog.log()" and log whatever messages I want to see where my code is messing up, or just to double check everything. But what really annoys me is I didn't want to have to constantly remove my debug strings whenever I wanted to test it live without the debug on, so I made the immutable boolean and checked if it was true before logging the debug. As you suggested before, I could just replace the value of DEBUG everywhere with true since it is final. But it makes it more obvious what I am doing when I put it in a variable. Furthermore, it also makes it so I don't have to search my class and find all places I need to replace every time I want to switch between true or false. Not only that, but it makes me able to see if I'm debug mode is enabled outside of the class since it's a variable if I just made a getter for it.

    I hope this explains some of the uses of a immutable boolean.
     
    SuperOriginal likes this.
  19. Offline

    mythbusterma

    @unrealdesign

    We understand it is "useful" (it's really not), we are saying that it is terrible practise, and leads to a hoard of unforeseen bugs.

    There is a use for a constant (constant in this case being "public static final" boolean), and that is not this usage case. The "debug" example, however, is an appropriate case. OP's code is not.

    We are not arguing the merit of constants, if you look at the post, that value would have to be mutable, and as such, could not be declared constant, and therefore should not be static.
     
    SuperOriginal and teej107 like this.
  20. Offline

    unrealdesign

    @mythbusterma No actually the code I gave an example of is a great practice. And if you could read I said I was going off-topic to explain why "public static final boolean" was useful in my example only and not the one OP posted unless he edited it to be handled similar to my example. So if you want to give more condescending comments like you always do, feel free to PM me instead of continuing to go off-topic.
     
    RunsWithShovels likes this.
Thread Status:
Not open for further replies.

Share This Page