CB 1.2.5 RB1.2 - Player object issue

Hi everyone, im having a big issue since the new RB on my plugin.

In my plugin i have multiple hashmaps to store player information.
Like this one :

public final static HashMap<Player, Long> myhashmap= new HashMap<Player, Long>();

Before RB1.2, When a player relog the Player object was always the same. So a condition like this worked:

if(!MyPlugin.myhashmap.containsKey(player)){

}


But after RB1.2 Everything changed and now each player relog his player object is different.
------------------------------------------------------------------------------------------

Is there anything i missed or did wrong, my plugin has been working like this for the last year without any problem functionning like that and now out of the blue, i have this huge problem.

Could anyone help me i would really apreciate it.

 

I think that the player objects weren't really the same before, but the equals() method only checked the player's name, which changed in the lastest RB.

This is the code from 1.2.5 R1.0:

Code:

    @Override
    public boolean equals(Object obj) {
        if (obj == null) {
            return false;
        }
        if (!(obj instanceof OfflinePlayer)) {
            return false;
        }
        OfflinePlayer other = (OfflinePlayer) obj;
        if ((this.getName() == null) || (other.getName() == null)) {
            return false;
        }
        return this.getName().equalsIgnoreCase(other.getName());
    }

And this is the lastes code from github:

Code:

    @Override
    public boolean equals(Object obj) {
        if (obj == null) {
            return false;
        }
        if (!(obj instanceof OfflinePlayer)) {
            return false;
        }
        OfflinePlayer other = (OfflinePlayer) obj;
        if ((this.getName() == null) || (other.getName() == null)) {
            return false;
        }

        boolean nameEquals = this.getName().equalsIgnoreCase(other.getName());
        boolean idEquals = true;

        if (other instanceof CraftPlayer) {
            idEquals = this.getEntityId() == ((CraftPlayer) other).getEntityId();
        }

        return nameEquals && idEquals;
    }

As you can see it now checks the entity id as well which changes when the player logs out & back in again.

 

so you see any solution in that, since my plugin have tons of class and over 240 hashmaps -_- yeash that much, its a big plugin. So rebuilding this can mean rewriting the plugin overall......

i would have to put in my hashmap the player name but then i wont have methods like getServer etc, and i need those, to fix that i would have to always have a server instance near witch i don't always have in all classes. To get my player object i mean.

I hope im clear a little

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

The Bukkit class has a bunch of static methods you can use, including Bukkit.getServer() and Bukkit.getPlayer(), etc.

 

Well you basically have to replace 'Player' with 'String' and change all gets/puts to use the player's name.
Also If you have so many hashmaps have you considered writing a PlayerData class which holds all information about a player, and only have one hashmap to link from each player's name to the player's data?

 

tought about it yeah, but now im just sad. What you poeple would suggest i do.

 

You can also try to convince the Bukkit team to revert the changes, with the argument that it breaks many plugins (like yours).
Also since an entity should only ever exist once, they can use player1 == player2 to see if they are the same entity, and can leave player1.equals(player2) to only check the names of the players. And if they need hashmaps with entities as keys they can always use an IdentityHashMap.

 

That would save me. Really. If only.. Would save me countless hours of migration :/

 

I opened an issue for this: https://bukkit.atlassian.net/browse/BUKKIT-1673

 

This?

 

thanks you so much, for now i wont update to RB1.2 hoping they agree to revert it back. Because i know ill have to redo a good part of the plugin when the Mojang api comes out, so having to redo my plugin twice in a row is like countless hours of updating.

 

Travis Watkins added a comment - 18/May/12 7:19 PM​

Stop storing Player objects after the player disconnects. You were never supposed to do that.

Now that's a chicken shit response....

If we were not supposed to do that, why did YOU not 1. A Mention that & 2. treat .equals() as though we could?

This is why scrip kiddies should not be developers...


You see Travis, when you CODE a community API, there is this little thing called BACKWARDS COMPATIBILITY, you guys at Bukkit and MOJANG never did learn... This is why there are so many issues with Bukkit. You have a responsibility to the community to ensure when you get a brilliant idea that it does not KILL half or more of the projects attached to it. (Reminds me of the PHP people).. GET YOUR SHIT TOGETHER!
If you worked for me, I would have fired the LOT of you.

 

Thanks you, and now here i what i did to fix this for me. -.- every new Rb I change the .equal function and rebuil craftbukkit over again. Since to me its useless to change this matter since the new mojang api will be out soon, and i certainly will be needed to start many thing over on my plugin. So thats why i dont want to change this now.

And like you said how should I have known that I wasn't supposed to do that..
Anyway Thanks for the support guy it helped me a lot!

 

You do realize that all we did is make it compatible with Mojangs .equals?

A design flaw with the API, which has been corrected. The problem, you see, is that those player objects were "never" valid. They were old players that didn't have anything to do with the current players. This will not be reverted, it has always been said to never store Player objects, and your .equals question has now been fixed.

 

Ok, I very please if its to fit with the new mojang api,
But I check often all the info on Bukkit and never saw anything saying i should never store player object.

Anyway knowing that its for the new api, good thing. And now i know that i should not stoore player object.
Ill do the right change to my plugin.

Thanks.