Server Features

New Server Commands
These commands are new to Hack/Mine as of version 0.6 (now available as a development build.) Smart name matching has been added as well, so players can be searched for via the first few letters of their name, both case and 1337 insensitively.

If chunkX and chunkZ aren't specified, the player's current chunk is assumed. Dimensions may be -1, 0, 1, or 10 for the Nether, the surface, the End, and the mystery dimension respectively. The surface is assumed when not specified.

Chunk coordinates can be calculated from block coordinates if they're divided by 16 and floored (e.g. block coords of (26, -113) are inside chunk (1, -8)). Your current position in block coords can be found by opening the debug menu with F3 and taking "x" and "z" (your height being "y").

Useful tip: F9 will toggle a "Chunk Grid" on your radar when at maximum zoom. Good for fast chunk flaggin'.

Flagged chunk data is saved to "flaggedChunks.txt" and can be edited while the server is off for quick flagging. Possible flags are protect-blocks, allow-pvp, prohibit-pvp, no-mobs, and no-animals.

The Area/Chunk Cache
"areaCache.properties" contains advanced settings for Hack/Mine's area cache, and fine-tuning them may improve performance and stability for your H/M server. The in game "get" and "set" commands available to Ops are the best way to perform quick experimentation, and additionally disallow you from setting your values to anything ridiculous. Also, Frizzil needs people to mess with it in hopes of finding better numbers (if you screw it up or aren't sure about your changes, just delete the file and H/M will generate a new one for you.) Fine-tuning is really only necessary if your server is at 20+ people. However, the larger your server is, the more significant fine-tuning your area cache will become. You'll want to enable "verboseLogging" when experimenting and disable it otherwise, to avoid console clutter. If you find settings that work, post them along with your system and server specs on the discussion page!

Things to consider when tuning, from most to least important: How fast is my file I/O? What's the speed on my CPU? How much RAM do I have?

Basically, the area cache is a place in memory where Areas are stored for quick access. A "cache miss" is when a request is made for an area that isn't in the cache, resulting in it being loaded from disk and into the cache-- you're trying to minimize these as much as possible, since file I/O is VERY expensive (unless you've got SSD like a boss!) Obviously, areas must be loaded at least once, but the trick is storing areas that will likely be used again and removing those that won't to make room. More recently referenced areas are kept, whereas less recently referenced ones are removed. A larger cache helps, but results in slower "victim selection" (selection of an area to remove on a cache miss), and at extreme sizes results in general lag and high RAM consumption.

Each tick, the ratio of cache entries that have been recently used is calculated and stored in "pctUsage." The exponential average of this number is stored in "avgPctUsage." I.e. avgPctUsage is set to avgPctUsage * w + (1-w) * pctUsage each tick, where w is "avgPctUsagePastWeight" This gives several important numbers for you to tweak--  avgPctUsageMax and pctUsageMax, which "grow" the cache when exceeded by their respective variables, and "avgPctMissPastWeight", which is "how significant are past values?" and effectively smooths out avgPctMiss as it approaches 1.00 (at 20 ticks/second, slight variations of this number from the default make dramatic differences.) You'll probably want this number to start around .99, making extremely marginal changes until you get a "memory" of usage that feels right. If your past weight is too low, your cache will be too sensitive to fluctuations and cause too many cache resizings, causing negligible to extreme lag (depending on how large your cache is and how badly you undershot it). If your past weight is too high, your cache will be too resilient to fluctuations, resulting in "area thrashing" if the need for areas exceeds the size of the cache, causing needed areas to be saved and loaded with each tick (This will cause massive lag and may also crash your server.) pctUsageMax generally prevents this if avgPctUsageMax doesn't catch it. Finally, you have avgPctUsageMin, which "shrinks" the cache when it can support that low of a usage when shrinking (iow, when avgPctUsage < avgPctUsageMin/growthFactor) Basically, fine tune these numbers to get the perfect amount of responsiveness to cache usage, only growing and shrinking when necessary to accurately support the needs of players.

When the cache "grows" or "shrinks", it takes a moment to copy it's data into a new, larger or smaller location in memory, respectively. "growthFactor" determines how much larger or smaller this location should be than the last location. Larger values result in less copying and hence lag, but more poorly associate the right cache size with your needs. E.g. a factor of 2 makes for little copying but potentially twice the resources consumed than needed if you just barely trigger a growth. Values closer to 1 may result in good matching of resources, but will result in excessive copying and more lag in response to quickly increasing needs, especially at larger cache sizes.

For you fellow computer science geeks, the area cache uses an aging page replacement algorithm (except not pages), using a 64-bit "age" for each cache entry, shifting once every tick (about 20 times a second) further reading. The "growthFactor" tradeoffs are directly associated with that of a dynamic array's.

Remember to test this stuff out! If you're testing with a large player base, gradually make changes and see how they go so you don't piss everyone off. Take notes even-- save old "areaCache.properties" and write notes at the bottom of it, so you can go back to good settings once you've found them. Finally, good settings on one machine aren't necessarily good another, especially if the system specs are drastically different (SSD vs Harddisk, low-end CPU vs monster CPUs, etc)

And most importantly, enjoy speeding up your server and improving its stability!