Bukkit

@coldandtired

Sorry databases is my weak point too so can't really help there :P

Basically just wanted to add (to my previous post) that, yes, in theory it should probably work, but the choice of collection could be a bit tricky. You want fast add, fast remove, and you want to be able to add/remove in the middle of an iteration over the collection (so you can split the iteration over several ticks). Might exist better solutions, but of the top of my head ConcurrentSkipListMap comes to mind. It does these things, with one "drawback": iteration might miss some objects if they are added during the iteration. This should probably not be a problem though because I believe you only need approximate numbers? So if it reports say, 300, but the correct number is 290 or 310 it probably isn't an issue right? (This error wont accumulate over time - it's just a bit fuzzy.)

@coldandtired

I haven't properly looked into the despawning problem, and one would hope there is a better way, but I can think of one way to count mobs that would (sort of) work (unless there is a memory leak somewhere). But it is a bit complicated and requires understanding of weak references and garbage-collection.

Basically whenever an entity gets spawned you could store it in a WeakReference (that WeakReference being registered to a ReferenceQueue that you've made) that in turn gets stored in a collection of appropriate sorts. The basic working principle of this solution is that once the entity despawns it will soon* (*usually - and only if there is no memory leak somewhere else - like in another plugin for example) be garbage-collected, which will cause the garbage collector to add the corresponding WeakReference-object to your ReferenceQueue. That means that you can poll this ReferenceQueue from time to time, and the number of elements in this queue is the number of entities that got garbage-collected since you last checked and emptied the queue (use the WeakReference-objects in this queue to remove the strong references to the WeakReferences-objects - aka to remove them from the collection you used to store WeakReferences - otherwise you will accumulate and have a memory leak of these objects :P).

tl;dr: Use the garbage collector to do the work for you and notify you of entities that has disappeared.

See this java article for a much better explanation than mine! :P

You could of course combine this with manual checks: every tick you could check a few of the entries in the collection (of WeakReferences), 1. Try to retrieve them (if not they have been garbage-collected) 2. if retrievable, check if they are dead or some other stuff, if so remove from collection and do other appropriate tasks. But basically the idea in this case is that you don't need to loop through the whole collection every tick, just check a few, store the index (or similar), and continue where you left of the next tick. This way performance can be tuned on the fly even: if server is lagging you could try to detect this and do less processing each tick. And since you are using WeakReferences storing all entities in a collection isn't a problem / memory leak.

Instead of being forced to hold up the main-thread to count all mobs this can allow the counting to be split up over several ticks in a safe way (there are pitfalls!). So it might be worth testing out.

@coldandtired

Do as you wish with it, I think it will mostly be useful to you anyway - as soon as 1.7.2b6 gets approved it wont be much use to most people. :P

It's open source and free to use. (I forgot to include a license file but SpawnsSpawnFix.java ...lets say thats public domain because it's not a big deal, the aztb-classes though are part of a larger collection of tool-classes, they are creative-commons-attribution - aka do anything as long as I get credit for them.)

Regarding the chunk unload - I'm not sure, but I would think a RemoveWhenFarAway-enabled mob can despawn without the chunk getting unloaded. Don't take my word for it though...

Made a small plugin to (partially) fix, and optionally help debug, Spawns.
Aside from the debug stuff it adjusts the spawn location for Spawns mobs so they spawn in the middle of blocks. The plugin is called SpawnsSpawnFix.

(It is made for Spawns 1.7.2 b5 and MC 1.7.2 - I haven't tested it on any other version.)

It runs in debug-mode by default, and will print out A LOT of messages in the console.
It can look something like this:

(Click to enlarge)

It has 3 commands that all require op, and of which 2 only are for debug-mode:

• ssfix - toggles correction of coordinates
• ssfs - toggles spawn-msg logging in the console (aka. to only see "died" messages)
• ssftp <mob-id> - teleports the player to the spawn/death location of a spawns-mob.

For debugging it can be nice to disable spawn-messages with ssfs and then wait for death messages (two of which can be seen in the above example) and use ssftp to tp to the location where that mob died. In other words it's a handy tool to teleport to and inspect the locations where Spawns-mobs actually spawn.

ssftp keeps track of the 512 most recently spawned Spawns-mobs. This is only done in debug-mode - "Normal"-mode is very lightweight. (Debug-mode can be disabled in the plugin config.)

I'm obliged to raise attention to the fact that this plugin has not been uploaded to and inspected by bukkit - use at your own risk.
Now that we've got that technicality out of the way... [MOD edit: Removed unapproved link]!

Hopefully this will be useful to you (or someone else). The code is very simple so if it doesn't work with the 1.7.9-version it can probably be fixed by doing only 2 or 3 small and easy changes. Oh, right! Almost forgot to mention: It's open-source and all the source is included inside the jar! If there is any questions, you want me to explain the code or whatever, just ask!

btw. spotted a tiny mistake in the documentation for hubs

<hub-attempts>5..8<hub-attempts>

notice lack of '/'. (will ofc cause a crash)

Also may I recommend adding

<hubs>
   ...
</hubs>

...to timers page, similar to how

<packs>
   ...
</packs>

...is added the hubs-page. (Easier to read/learn.)

@coldandtired

Well the mobs can disappear without dying can't they?
If you're only listening to death events then aren't you going to miss all the "despawned" mobs?

Well... "despawned" is a relative term here...
Might or might not be what you intended...
See this.
(I do believe RemoveWhenFarAway = true would indeed despawn the mob though - with no event afaik.)

@coldandtired

No problem, I'm basically helping myself since the server I'm playing on is using your plugin! :P

To answer your question: yes, everything works fine once I removed the '#'. (I didn't bother testing other rarely-used-but-valid-in-folder-and-filename symbols - only changed my folder name.)

P.S: I think that spiders still need 2 blocks wide spawn-space, so spawning spiders 1 block away from walls is probably still a good thing - would assume horses need at least 2x2x2 too, maybe more? But it would be bad if zombies and such "thin creatures" never spawn in 1-block narrow passage-ways that players tend to dig out while mining.
(Fun-fact: If I'm correct the minecraft codes Entity-class has a width, height and length property, but bukkit doesn't expose them... didn't dig around very deep not sure why.)

Was going to do some work with Spawns (for a private 1.7.2 server) when I stumbled on an obscure bug in your loadConfig-code:

line 236 Spawns.java (1.7.2 b5):

NodeList list = (NodeList)Conditions.xpath.evaluate("packs/pack", new InputSource(f.getAbsolutePath()), XPathConstants.NODESET);

This can cause a very misleading SAXParseException even if there is nothing wrong with the xml-file. Took me a while to track down the true cause, but it turns out it can't handle all types of paths. In my case the absolute path was: "H:\#TESTSERVER2" and that will crash your plugin with a SAXParseException...
"lineNumber: 1; columnNumber: 1; Content is not allowed in prolog."
...because of the '#' in the path.

(Have not tested this in your latest version because I'm only interested in 1.7.2)

Not going to look into this issue any further since I will just change the path. But might be very helpful to know in case you want to try and fix it / others are getting this exception and can't find the cause.

Pastebin if you're curious, but should be super easy to reproduce yourself...
Spawns path-related xml parsing error
(Clean server, no other plugins, empty world, packs.xml freshly auto-created by your code - never edited.)

Oh, right... and what I was actually looking into:
Your understanding of the coordinate system in minecraft seems to have one small but crucial flaw... To spawn something on the middle of a block you need to add +0.5 to the x- and z-coordinate. Your code (1.7.2 b5) is currently spawning stuff on the North-West corner of blocks, causing mobs to quite often die of suffocation in caves or steep hill/cliff/mountain areas.

Basically just go ingame, activate the F3-overlay, look straight down, position yourself on the middle of a block and you will see this. (Also many bukkit-commands like /tp adds +0.5 automatically for convenience... try using /tp but instead of "/tp x y z" type /"tp x.0 y.0 z.0" and you will end up on the North-West corner of that block.)

I can send you my debug code for this if you are interested...