Hello, is it possible to get a list of all tamed animals of a player? Something like “Player.getTamed()”? Fabian
I can't see anything for that in the source. You can find out who owns a wolf but not what wolves someone owns.
Probably the simplest way to do this is to iterate over the entity list and check each entity to determine, first, if it is a wolf, and then whether its owner is the desired player. Using this mechanism it would be fairly simple to build a data structure containing the players and their associated wolves. Unfortunately, it's expensive (an instanceof for every entity and a cast for every entity that is a wolf) and should probably only be done when specifically requested, or in controlled scenarios.
Saw Edwards post, and thought up exactly the same thing. You can find the wolves a player owns by reversing the search. With lots of players and lots of wolves, could be time consuming.
Mobiles, in general, are probably the largest population of entities to consider, but there are also falling blocks, arrows, primed TNT, dropped items, mine carts, and others. The cost of this search could be quite substantial. I would assume, if the search were in response to a command, it's probably not too terrible a problem. It would be optimal if the command has some sort of cool down. It the search were to be done programmatically, either on a schedule or in response to a specific event, it could have very negative performance implications unless the frequency were very carefully controlled.
When you guys say owner, are you talking about target? If so, if a wolf is friendly toward a player, is that player it's target? Whenever I have set the wolf's target, it always seems to, well murder me.
Interesting. I hadn't looked at the documentation. Perhaps you could try this: Code: void follow(Player player, Wolf wolf) { if (wolf.getTarget() != null && !wolf.isAngry()) { wolf.setTarget(player); wolf.setAngry(false); } }
Unfortunately this does not work, although it seems logical that it should. EDIT: Now i remember why this does not. (maybe this could be handled in bukkit?) Once a wolf is hostile, it can never be made friendly again (in vanilla minecraft).
Ach, well. I think, perhaps, we're missing something important about how this works, internally, in Minecraft. The setAngry method should fix that. There's clearly something more going on.
Agreed, but i'm not too concerned, 1.4 just came out, and the devs look like they're working on core functionality right now, i'm sure it'll get taken care of!
Hmm I do need something like this for one of my WIP plugins. I'll dive into the client source and see if I can find anything that bukkit has that we can use for now.
I know this isn't exactly what the OP wanted, but it's getting much closer, we just need this in CraftBukkit now: via @jynxdaddy Original GitHub Commit
One thing that would help the performance of creaturebox would be if world.getLivingEntities returned a HashSet instead of an ArrayList. I find myself needing to search the list for specific entities (to see if they've died), which is pretty inefficient with an ArrayList.
I did something like that in part of my code at one point. It pulled all of the wolves and then added them to a HashMap so I could pull any info from them as needed. While inefficient the way I did this was to have the server use the first player that enters to get the name of the world that was loaded. From there I got a List of all living entities and weeded out all but the entities I wanted which was wolves in this case and added them to there respective HashMap for later use. I could then add the onEntityDeath and onEntitySpawn events to keep up with the current list of living entities.
Perhaps on could handle the onCreatureSpawn event, and if the entity is a wolf, at it to a Set. One would also have to handle removing the entity from the set when it dies or despawns. Perhaps using a WeakHashSet would simplify the resource handling side of it.
From what testing I did with onEntityDeath, it wasn't clear that it was always being called - I'm pretty sure I was seeing entities vanish from getLivingEntities without triggering a death event. It's possible that's been fixed by now.
I think that's because not all entities "die." When a player moves far enough away from a chunk, the mobiles occupying that chunk unload. (Although, it might be the distance from the mobile rather than the chunk that spawned the mobile.) What we need to make this work right is an onCreatureDespawned event. In lieu of such an event, we could make do with onEntityDeath to at least remove wolves that we know have been slain. It's still possible that other entities in the set might have despawned. We would need to find another, preferably inexpensive, way to determine if they're still active.
Code: CraftWolf cWolf = (CraftWolf)theWolf; EntityWolf eWolf = (EntityWolf)cWolf.getHandle(); String playerName = eWolf.v();
.v() seems to be working appropriately for me, at least in the small amount of testing I've done so far
Why don't you make files for every player (name.pets). Inside that file, use something like this: if(player right clicks wolf with bone){ amountOfWolves++; open file(player + ".pets"); properties.put("wolf" + amountOfWolves); } then when you want to check: function blah(){ open file(player + ".pets"); for(var i = 0; i < properties.getProperty("amount_of_wolves"); i++){ playersPets.add(properties.getProperty("wolf" + i); } } or something
The main problem with that would be how to store a reference to the wolves. Their entity ID's aren't persistent across server restarts so you can't use those. Even if you can think of a way (I can't), then what happens if the wolf isn't loaded into memory because its on an unloaded chunk? How do you distinguish between this and the wolf having de-spawned (as they so often do).
Everytime the player logs on, spawn 'amount_of_wolves' and make them follow him. Then you can reference them through the array that has been made? and an even better way to do it, if it is possible, before you spawn the new wolves, make the old ones either despawn or stop following.