Is there a way to check how many maps (the item) exist on a server?

or get the ID of the last map created? I guess it would be the value in /mainworldname/data/idcounts.dat but I have no idea how to read that file.

or if there's someway to check does map[ID] exist, that would work too.

 

Code:java

private boolean doesMapExist(World world, short mapid)
{
    return ((CraftWorld)world).getHandle().a(WorldMap.class, "map_" + mapid) != null;
 
}

You need to import CraftBukkit.
I might be able to provide a method to get the number of maps, too.

Code:java

private int numberOfMaps(World world)
{
    WorldMapsCollection worldMaps = ((CraftWorld)world).getHandle().worldMaps;
    Field d = WorldMapsCollectio.class.getDeclaredField("d");
    d.setAccesible(true);
    HashMap hashMap = (HashMap)d.get(worldMaps);
    return hashMap.size();
}

Though I tested neither of them.
Edit: forgot a cast

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

 

Thank you so much for your help!

 

I actually wonder why "private" or visibility in general exists in Java when you can just do setAccesible(true) and BAM, you can do whatever you want? Doesn't that defeat its purpose?

 

Variable visibility isn't a security feature. It's more of an organizational feature.

 

Uh, I supposed that. It makes ... sort of ... sense. I'm not going to argue about that, although I can think of a couple of disadvantages for that concept.

 

@Bone008

Just an example with psuedo code

Code:

class test
{
   //class test takes 2 positive values and just keeps it like a first-born.
    public a;
    private b;
    public set_b(int i)
   {
       if (i < 0)
          i *= -1;
       this.b = i;
   }

//in the main

test t = new test();
t.a = -5; //success  - value of t.a = -5
t.b = -5; //fails because b is not accessible
t.set_b(-5); //success  value of t.b = 5
t.set_b(5);  //success value of t.b = 5

The class intended a and b to be positive... so as you can see, a was public and had no say in what it should be. It couldn't be validated on setting. (You leave the user of your class responsible for it). (This is just a really weak example) but the power of the set is, it can modify the value before assigning, or even throw errors, or affect other members of the class. Hell I could even have set a to be the difference of b in that set function... The idea is to make sure the setting conforms. Same with get.

Hope that clears it up a little.

 

@lxy And what has that to do with what I pointed out? I'm totally aware of the uses of getters/setters and private members.
But when you try to block direct access to something by making it private - it's still possible to make your way to it (with the methods Shamebot posted above).

 

Sorry for jumping in but is there a way to get the map ID from the map the player holds in the hand?

And one more: If I give a map to a player he get's it with a random ID.
If he presses q for throwing it away and then collect it from the ground it has the ID it should be. The same is after a reconnect: The ID changed again... Why and how can I prevent this?
P.S. I give him the map like this:

Code:

player.getInventory().addItem(new ItemStack(Material.MAP, 1, (short)9));

 

I haven't tried it but ItemStack.getDamage() should return the id.
About the latter, not sure isn't there some player update inventory stuff or something?

 

getDamage() ... of course... sorry.
I searched for something like that but it seems it's deprecated (not sure if it exists in bukkit anymore). I have a workaround but it would use less resources if there were a bukkit function (The workaround is to use codename_Bs Map API to render something on the map, then it switches to the right ID, too. This is used for V10phone so the map has to render a black screen when the player get's it the first time but I hoped I don't have to blank again after a login).

 

Ah I think it's getDurability() not getDamage()

 

Sorry for confusing, the first sentence in my last post was for the map in hand stuff and all starting from the secound was related to the ID issue.