Get player from other eventhandler

Discussion in 'Spigot Plugin Development' started by UnlimitedNinjas, Jun 1, 2018.

  1. I need to get a player from another EventHandler.

    I have the target in one eventhandler and the player in another
    i need to get the target from the eventhandler that has the player.

    If your confused: I just need to get a player from another EventHandler
  2. Please tell us which EventHandler you need. For example: there is a PlayerDamageEvent and a EntityDamageByEntityEvent. Both have same things but are different because you got a target in the second.
  3. You would prob need to make a variable and make x event set variable so other event runs it off that set variable.
    • Like Like x 1
  4. Error 404: basic Java variable knowledge was not found.
    Try again?

    On a side note: most likely the two events will not be fired at the same time, so you have to store one part of the equation somewhere anyways. If they do get fired at the same time, then you probably missed the correct event that contains all the things you need.
    • Winner Winner x 3
    • Funny Funny x 1
  5. What you typed is too vague. How far apart are these events, is there a chance that another instance of event two sprung before the first instance event 2 need the event 1 information and over writing the event you needed so if so you need a way to have a buffer and pull what you need out.

    Its probably best to tell us what the first Event is and what the Second Event is and what your trying to grab from the first event into the second.
  6. From PlayerJoinEvent to AsyncPlayerChatEvent.
    need to get Player target from PlayerJoinEvent and use it in AsyncPlayerChatEvent
  7. tbh made my day
    • Agree Agree x 1
  8. I don't know why would you want to do it, but you can just create a Set of UUIDs and store his uuid there when a player logs in.
    Then, in the AsyncPlayerChatEvent, go through this Set of UUIDs and use it.
    Just a reminder: never store a Player object in any kind of array, as it eats your ram.
  9. This isn't true. As long as you clean up your players when they log off, or use a weak reference, there is no problem with storing player objects.
  10. It is, as it eats your ram. It's better to store UUIDs and then just use the Bukkit#getPlayer or Bukkit#getOfflinePlayer methods.
    • Agree Agree x 1
  11. Player objects don't eat your RAM. It becomes a problem when a player logs off and you are still holding a reference to that player in memory when it should be cleaned up by the garbage collector (which isn't possible then, since your storing a reference to it).

    If you want to save some kind of link to a player while this player is offline, yes, you'd use UUIDs. If this isn't required however (e.g. you only need to store the player when it's actually online) you can safely store player objects as long as you remove them when they log off the server.

    Internally it works as follows. You store a player, retrieved in some way, in some kind of collection. However this player object just references to the same player object which is already stored internally, so other than a pointer to that object, no extra ram is used. The same works for a UUID, it just points to an already existing UUID.

    However when the player logs off, the player object is discarded internally. In the next gc cycle it tries to get rid of the player altogether, but it can't because you are still storing that player object. The same is said for the UUID, it keeps it alive, since you still store it. The difference is however, that a Player object holds much, much more data than a UUID, which causes al kind of other problems. A UUID stores very little data and therefore doesn't use as much ram. A Player object on the other hand, stores location, name, health, food, air, game profiles, textures, etc. etc. and therefore uses more ram.

    However when you remove your player objects from memory when said player logs off, there is no reason to worry one bit, since the gc can clean everything up just fine next time it runs.
  12. You are wrong. When you need to cache 100 players, 200 players and more, you are just wasting ram as you are storing player objects while you can just store their uuids. UUID object take less ram than Player object, so its always better to store UUID objects.
    It doesn't matter if you remove them when a player logs out, as when the player is still online - it takes more ram to store the Player object.
    This is an advice from me to the OP, if you don't agree with me - fine. There is no point in discussing about it.
  13. Internally a player object is already stored for every player, so you already have a bunch of ram used to make CraftBukkit store these.

    Adding a Player object to a collection, doesn't just create a new player object, nor does it make a copy of an already existing one. It just points to the player object already stored internally. That's it. The only additional ram used is a simple pointer, which is the same amount (or at least very similar) of ram that would be used when storing a UUID.

    As I said the only problem is that when you don't remove the player when they log off, their object is still stored internally because your plugin is holding a reference to it somewhere. That is the problem. If you have 100 players online and 50 log off and you don't handle this, there will be still 100 objects loaded, while this could be reduced to 50. This is where the actual problem lies, cause if you have a 1000 players and after an hour you have 1000 different players, but you don't clean your stuff up correctly, you'll now be holding 2000 players in ram. That is of course an issue, since only 1000 have to be available.

    As long as you clean up the instances in which you store players when said player logs off, there is absolutely no problem.
    It is a common misconception that storing a Player object is a taboo, and that storing UUID objects are better. It is not. In fact, they behave the same, the only difference being that the Player object holds othet Objects. That is completely fine and is not a reason to prefer UUID over Player objects.

    It depends on your needs. Why? If you need to store a reference, then retrieve the Player's name, location or whatever you need, then storing the Player object is the right way to go. In fact, I'd like to debunk your claim that
    That should not be the decision/thought process when it comes to deciding what to use. It, actually, does matter if you remove them when a player logs out. The Player object is NOT persistent, i.e. the Object differs with sessions(logins). Thus, it is important that you run your own clean up to prevent memory leaks. UUIDs on the other hand, are persistent, and do not change at all. Hence, that is a valid claim.

    However, I'd like to point your attention back to my central topic of concern: It depends on your needs.
    #14 PotatoBro, Jun 2, 2018
    Last edited: Jun 2, 2018
  15. Ok, message me private. May I can code that for you.
    • Optimistic Optimistic x 2