Player logged OUT before logging IN.. welp

Discussion in 'Plugin Development' started by Dread9Nought, Jul 29, 2013.

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

    Dread9Nought

    So... sos.

    So, before I give some gritty errors, a player seems to logout with end of stream, before ever logging in, and then logging in right after.

    IE:

    After which my plugin, and a few others start throwing entire sissy fits..



    DESPITE:




    Any help would be awesome.

    This itself isnt the biggest problem.

    Upon the "game" ending, and after all the plugins are disabled, it tries to "Saving players" at which point it freezes, the server doesnt stop, therefore bringing that game server to a complete halt until manual interaction.
     
  2. Offline

    etaxi341

    Dread9Nought You probably use the PlayerLoginEvent right? This will trigger too if its an End of Stream. If you won't get it triggered at an End of Stream use the PlayerJoinEvent.
     
  3. Offline

    xTrollxDudex

    Dread9Nought
    Do you see why you would use a player name instead of a player object in a collection?
     
    etaxi341 likes this.
  4. Offline

    etaxi341

    xTrollxDudex Ohh I didn't see this! Yes you are right. He needs to store the Playername.
     
    xTrollxDudex likes this.
  5. Offline

    Dread9Nought


    I do not see how that would cause my issue, its causing an issue that doesnt appear cause-capable by storing a player object - I mean: ALL the other plugins start throwing errors.

    Could it be some weird out of memory error that is disguised?? Will be trying the player thing, however.

    But I do need more suggestions as to the cause vs just one, which isnt very likely.

    Bump bump. suggestions welcome

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 3, 2016
  6. Offline

    IanM_56

    Is '(Line cries about)' actually in the code?
     
  7. Offline

    Dread9Nought

    Yeah.

    According to craft bukkit its because a player is still technically there, but isn't connected, but isOnline() returns true, and is null returns false, no matter how I try to sugar coat it.

    BTW: I'm more than sure the QuitEvent is never even called otherwise my HashMap wouldn't ever contain that player.

    I have updated it all to never hold the player object but as I said, it clearly isn't the issue, and that issue still remains.

    welp.
     
  8. Offline

    ZeusAllMighty11

    Regardless of the situation, you shouldn't be storing the player object.

    Instead, just store their name, and to retrieve you can use Bukkit.getPlayer(String name);
     
    Milkywayz likes this.
  9. Offline

    xTrollxDudex

    TheGreenGamerHD
    He's not listening to me....
     
  10. Offline

    Dread9Nought

    I have already stated that "I have updated it all to never hold the player object but as I said, it clearly isn't the issue, and that issue still remains."

    I did listen.
     
  11. Offline

    Samthelord1

    Dread9Nought storing a player as a object causes memory leaks.
     
  12. Offline

    IanM_56

    ? - What is the goal of the code?
     
  13. Offline

    Double0negative

    Samthelord1 TheGreenGamerHD

    This is all totally wrong. I would think that the staff of bukkit would at least know their own API better than this.

    Using the player object doesn't cause memory leaks. Bad coding practices do. As long as you clean up after yourself, using the player object would be faster then making calls to getPlayer. on that note, why in the world you would EVER recommend using getPlayer is beyond me. getPlayer is a EXTREMELY expensive call and should only be used if you dont have the players full name (ie command input). Use getPlayerExact() instead.
    tl;dr, learn what you are talking about before spitting the info of people who dont know what they are talking about
     
    hatstand and xTrollxDudex like this.
  14. Offline

    xTrollxDudex

    Double0negative
    O.O you're never on the forums :O
    Also, TheGreenGamerHD didn't create bukkit, he is just a staff member, as from
    Otherwise, I don't see why it needs to be reemphasized
     
  15. Offline

    flaaghara

    Double0negative I'm going to have to agree with you.

    Telling people to never store the Player object with the generic "memory leaks" reason can be ridiculous if it doesn't apply to the situation. In this case, the object is perfectly encapsulated and isolated so there is no need to fuss about storing the player's name. The Player object is just like any other object in Java, and if you really are frightened by the prospect of storing a Player object, then perhaps reading up on Garbage Collection will be enormously enlightening to you on how the JVM operates.
     
  16. Offline

    ZeusAllMighty11

    Usually the reason that people (including I) flaunt the 'memory leaks' when talking about player objects, is because the people we are talking do don't even know Java. They do not know what happens 'behind the scenes' of the JVM.

    It's better just to tell them not to store it, because they probably won't be capable of fixing their issues which may come up with them. For example, memory leaks are really common because they know nothing/very little about objects, and therefore are given the 'PermGen ... ' error, then they come to the forum to complain. When they are told not to store the Player object, they go ballistic.


    I don't really see a reason to call out all Bukkit staff for this. A lot of us aren't here to know every line of code for every class in the API. We're here to contribute to the community, on DBO not this website. So being staff is completely irrelevant anyway. We're just as human as everyone else. Assuming that a majority of this forum now-a-days is filled with new users, which I am not ridiculing, it is also fair to assume they may be new to Java. Based on the posts I see here every single day, it's also fair to say that they aren't experienced with the Bukkit API. Therefore, it's completely legitimate to push good coding practices upon them and telling them otherwise of their bad ones. How many which are new to Java actually know about garbage collection? Or even OOP in general? Not too many from what I've seen, though that's just a speculation.

    It's pretty rude just to call out all staff on this one. If you want, take the wrap on me, but make sure you read what I have to say...


    TL;DR:
    Many on this forum are new to Java and the Bukkit-API, and therefore should just follow standard practices.
     
    xTrollxDudex and Samthelord1 like this.
  17. Offline

    Samthelord1

    In this instance, it's what is causing the error, so why do it? Also, nice to see you on the forums, Ive seen some of your GitHub, you know what your on about, but I don't want to start a argument especially with you :)
     
  18. Offline

    Double0negative

    TheGreenGamerHD

    I agree with everything you just said. I just don't think saying to always use Strings is the best idea, but I do agree with what you said. The problem like you said, obviously spawns from the fact that a lot of people on this forum do not know what they are doing, so like you said, its easier to just tell them to use Strings to save the hassle of telling them how to clean up after them selfs and what makes storing the Player object bad. Where it starts causing problems is when people don't know why they are using it, and don't know better ways to do things and end up causing more trouble in the long run.

    Also, I didn't mean to be calling you or staff out in general, I just think that being that your job is to review plugins, you might explain it better then the common person in an effort to make higher quality plugins.

    Samthelord1

    Hi!

    And, I don't believe that is what is causing the errors in this instance, as like he said ALL plugins start throwing exceptions as if theres a issue in bukkit where the logout even isn't being fired or something in some cases. I only started noticing this recently
     
    Milkywayz and TheGreenGamerHD like this.
  19. Offline

    xTrollxDudex

    Also, besides that, he is using direct public static methods/variables. A better way is to have a static method to get an instance of the class.
     
  20. Offline

    Dread9Nought


    The way it works is this basically does the same thing.

    The code does one game, and one game only. The game class is actually dynamic and CurrentGame is just assigned to the new instance that was initialized at runtime.

    Not too sure how this would benefit me.

    private Game game;

    public static getGame() { return game; }

    o.o
     
Thread Status:
Not open for further replies.

Share This Page