http://www.hackslashmine.net/hsmwiki/api.php?action=feedcontributions&feedformat=atom&user=69.246.180.210Hack/Mine Wiki - User contributions [en]2026-07-04T07:41:35ZUser contributionsMediaWiki 1.19.2http://www.hackslashmine.net/hsmwiki/TowersTowers2012-06-04T02:10:58Z<p>69.246.180.210: /* Easy Exp Farming */</p>
<hr />
<div>[[File:2012-04-19_11.51.15.png|right|thumb|a tower]]<br />
==Overview==<br />
Towers are found throughout the world. Similar to dungeons there are different rooms with '''mob spawners'''. Each tower has a number of floors and the top room always has '''treasure''' in. Towers are found in multiple colours including blue, light blue, yellow, red and purple. Colours can also change depending on the different biomes that they are found in. Unlike the dungeons, towers are leveled depending on the level of the area you are in. As of patch 0.5, taller towers have been added to appear on occasion, with several more levels to conquer on your climb to the top, as well as better treasure once you reach the top room.<br />
<br />
[[File:JungleTower.png|thumb|Jungle Tower]]<br />
<br />
==The Rooms==<br />
<br />
There are multiple rooms in the towers. Each has a random spawner and a different design. There are sometimes lava/water blocks on the floors. If a tower has blocks on it half way up, like a generated block (not ones that have been placed) then thats where the door will be. just fyi<br />
<br />
The top floor always contains a red carpet to the end chest, making it a profitable and sometimes dangerous source of wool.<br />
<br />
[[File:2012-04-19_11.33.26.png|thumb|generic room]]<br />
==Defeating Towers==<br />
There are many ways to defeat these towers.<br />
<br />
[[File:2012-04-19_11.34.01.png|thumb|chest room]]<br />
<br />
<br />
The Mage Rush: The mage rush requires the person to blink from room to the other side and climb the ladder all the way up to the top. This Is useful when fighting towers way beyond your level as this will allow you to get 10x's the items you have. But when this comes with the going down, it is rather hard as more mobs have spawned. You must carefully blink down the tower without getting swarmed by the evil monsters.<br />
[[File:Warpedtower.png|thumb|An example of how a tower can "warp" when it spawns; notice the chest with white wool underneath of it instead of red.]]<br />
The Midway Ladder: The midway ladder is where you rush to the midway of a ladder. As most mobs have very little range you can stay up there and shoot them with your wand/bow. After you manage to kill all of the mobs in that room you can rush back down and destroy the spawners. Then you can get on the ladder and stay half-way using your bow/wand, attempt to climb yourself up and down the ladder getting hits.(Using the Lighting Spell can be a very useful tool, but be warned that you can lose your items due to the lighting) Another Tip whilst doing this is to use the S key to climb up ladders. This is so you can face the mobs and easily go up and down.<br />
<br />
All Balls: All Balls is where you get a diamond pickaxe and rush like a mad dog destroying all the spawners you can. This is best Done with warrior or a mage as mages can blink to dodge any attacks and warriors are quick enough to not get killed.<br />
<br />
Fortress: Warriors or Rangers/Mages that are playing their class wrong can vastly increase their fortitude and simply walk in. They then use whatever weapon they want (I've done it even with my fist) to destroy mobs, then grab a pickaxe and stand on top of the spawners, using gust or whirlwind to keep mobs at bay while the spawner is destroyed.<br />
<br />
==Easy Exp Farming==<br />
There Is a way for all classes to use their abilities to get massive levels in a quick time.<br />
<br />
All the mage/archer has to do is wait for a lot of mobs to spawn, then they can use their lighting abilities which can do a massive attack. The Warrior can spam their Whirlwind ability as well. Using this ability a few times will usually clear most mobs around your level.<br />
<br />
Doing this however does destroy any items that drop. Some of the items might have just been that better wand/bow/armor you needed.<br />
<br />
Another method for farming involves setting up a short barrier between a ladder, and multiple slime spawners. If one places half blocks in the right positions, it is possible to shoot charged bolt spells, arrows, or other projectiles through, dealing damage without destroying drops, or taking any hits.<br />
<br />
This method is quite difficult to set up, but is very rewarding, because it takes very little time to make many kills, and score tons of loot. Warriors can simply block off the mobs at a doorway and use whirlwind to attack them through the door.<br />
<br />
[[File:2012-05-01_20.49.46.png|thumb|this is a tower with a chunk of dirt in it<br />
<br />
the black hole is the door. ]]</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/WarriorWarrior2012-06-02T08:19:50Z<p>69.246.180.210: </p>
<hr />
<div>[[File:Warrior Skill - Leap|thumb|300px|right|Warrior using leap skill]]<br />
==Overview==<br />
Your standard fighter class. Specializes in slashing enemies to bits and charging into hordes of mobs. Can also function as a tank.<br />
<br />
Warriors are yer standard melee class, see? Slashin' Nagas, chargin' at Slimes, and leapin' all over the place are all in a day's work.<br />
<br />
<br />
<br />
==Abilities==<br />
<br />
{|align="center" border="2" cellpadding="3" cellspacing="0" class="article-table article-table-selected"<br />
! scope="col"|Spell<br />
! scope="col"|Mana<br />
! scope="col"|Cooldown<br />
! scope="col"|Description<br />
|-<br />
|Leap<br />
|7<br />
|1.5<br />
|Causes your character to soar into the air for a good distance, causing a small bit of damage on landing. Useful for when you need to get out of a jam (Ouch, my kneecaps!)<br />
|-<br />
|Taunt<br />
|5<br />
|2.5<br />
|Causes a monster to focus it's attacks on you. Not really of much use in single player, but once threat mechanics are in place, this will be essential for tank type builds in SMP. (Hey, fish-face! Come and get some!)<br />
|-<br />
|Leash<br />
|5<br />
|.75<br />
|Pulls a monster toward you. Useful for those times the wizard doesn't feel like making it easy for you and standing still so you can run him through. (Get over here!)<br />
|-<br />
|Charge<br />
|5<br />
|1.5<br />
|<br />
Ahh, my sweet, sweet charge! Causes you to, well, charge forward. When you collide with a monster, it takes a good bit of damage and is sent flying back, as well as any of its buddies stupid enough to be nearby. Good for when you need to clear a path for your group, or just need to deal with a horde of mobs (For Narnia!)<br />
|-<br />
|Whirlwind<br />
|8<br />
|1.5<br />
|<br />
Great for yer close-qaurter adventures!<br />
Turn yerself around doing damage to mobs next to you!<br />
|}<br />
<br />
[[File:Warrior Skill - Leash|thumb|300px|right|Warrior using leash skill]][[File:Warrior Skill - Charge|thumb|300px|right|Warrior using charge]]<br />
<br />
==Ways to Build==<br />
*Berserker - Prioritize getting the best weapons as you can, and go for as many Strength/Dexterity increases as possible. A tiny bit of Fortitude every now and then should be enough to keep you alive.<br />
<br />
*Guardian - Armor, armor, armor! If you like to be able to shrug off blow after blow (including the dreaded arrow to the knee!), then the Guardian is for you. Prioritize Fortitude! Maybe 4 or 5 points to fort every level, and the rest to either Dexterity or Strength. Weapons are your second priority.<br />
*Battle tank - The balance of weapons and armor should keep any SMP party alive. Strength and Fortitude should be your main skill trees. Your job is to agro all the mosters and group them, a mage and a ranger can make quick work of a group. In SSP using your charge should kill most enemies.<br />
**Paladin - A branch off of battle tank, prioritizing strength and fortitude, followed by wisdom. The goal of this build is being able to use your abilities at all times, by having loads of mana, and being able to take a hit, while still dishing out damage. Very useful when playing SSP<br />
*Pure Berserker - Strength, strength, and more strength. This build gives the highest possible damage output for each level, but with low ciritcal hit chance. Only raise Strength with points, and rely on armour and weaponry for buffs to other stats.<br />
<br />
More to come!<br />
<br />
==Stats==<br />
Focus on getting a large fortitude and strength. Unlike other classes you only need stuff that has to do with you in particular. The ranger and mage should both get some strength power so they can fight if caught in close combat but a warrior should just focus on fortitude, strength and low amounts of dexterity.<br />
<br />
[[Category:Classes]]</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/WarriorWarrior2012-06-02T08:17:04Z<p>69.246.180.210: </p>
<hr />
<div>[[File:Warrior Skill - Leap|thumb|300px|right|Warrior using leap skill]]<br />
==Overview==<br />
Your standard fighter-y class. Specializes in slashing enemies to bits and charging into hordes of mobs. Can also function as a tank.<br />
<br />
Warriors are yer standard melee class, see? Slashin' Nagas, chargin' at Slimes, and leapin' all over the place are all in a day's work.<br />
<br />
<br />
<br />
==Abilities==<br />
<br />
{|align="center" border="2" cellpadding="3" cellspacing="0" class="article-table article-table-selected"<br />
! scope="col"|Spell<br />
! scope="col"|Mana<br />
! scope="col"|Cooldown<br />
! scope="col"|Description<br />
|-<br />
|Leap<br />
|7<br />
|1.5<br />
|Causes your character to soar into the air for a good distance, causing a small bit of damage on landing. Useful for when you need to get out of a jam (Ouch, my kneecaps!)<br />
|-<br />
|Taunt<br />
|5<br />
|2.5<br />
|Causes a monster to focus it's attacks on you. Not really of much use in single player, but once threat mechanics are in place, this will be essential for tank type builds in SMP. (Hey, fish-face! Come and get some!)<br />
|-<br />
|Leash<br />
|5<br />
|.75<br />
|Pulls a monster toward you. Useful for those times the wizard doesn't feel like making it easy for you and standing still so you can run him through. (Get over here!)<br />
|-<br />
|Charge<br />
|5<br />
|1.5<br />
|<br />
Ahh, my sweet, sweet charge! Causes you to, well, charge forward. When you collide with a monster, it takes a good bit of damage and is sent flying back, as well as any of its buddies stupid enough to be nearby. Good for when you need to clear a path for your group, or just need to deal with a horde of mobs (For Narnia!)<br />
|-<br />
|Whirlwind<br />
|8<br />
|1.5<br />
|<br />
Great for yer close-qaurter adventures!<br />
Turn yerself around doing damage to mobs next to you!<br />
|}<br />
<br />
[[File:Warrior Skill - Leash|thumb|300px|right|Warrior using leash skill]][[File:Warrior Skill - Charge|thumb|300px|right|Warrior using charge]]<br />
<br />
==Ways to Build==<br />
*Berserker - Prioritize getting the best weapons as you can, and go for as many Strength/Dexterity increases as possible. A tiny bit of Fortitude every now and then should be enough to keep you alive.<br />
<br />
*Guardian - Armor, armor, armor! If you like to be able to shrug off blow after blow (including the dreaded arrow to the knee!), then the Guardian is for you. Prioritize Fortitude! Maybe 4 or 5 points to fort every level, and the rest to either Dexterity or Strength. Weapons are your second priority.<br />
*Battle tank - The balance of weapons and armor should keep any SMP party alive. Strength and Fortitude should be your main skill trees. Your job is to agro all the mosters and group them, a mage and a ranger can make quick work of a group. In SSP using your charge should kill most enemies.<br />
**Paladin - A branch off of battle tank, prioritizing strength and fortitude, followed by wisdom. The goal of this build is being able to use your abilities at all times, by having loads of mana, and being able to take a hit, while still dishing out damage. Very useful when playing SSP<br />
*Pure Berserker - Strength, strength, and more strength. This build gives the highest possible damage output for each level, but with low ciritcal hit chance. Only raise Strength with points, and rely on armour and weaponry for buffs to other stats.<br />
<br />
More to come!<br />
<br />
==Stats==<br />
Focus on getting a large fortitude and strength. Unlike other classes you only need stuff that has to do with you in particular. The ranger and mage should both get some strength power so they can fight if caught in close combat but a warrior should just focus on fortitude, strength and low amounts of dexterity.<br />
<br />
[[Category:Classes]]</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/WarriorWarrior2012-06-02T08:15:41Z<p>69.246.180.210: </p>
<hr />
<div>[[File:Warrior Skill - Leap|thumb|300px|right|Warrior using leap skill]]<br />
==Overview==<br />
Your standard fighter-esque class. Specializes in slashing enemies to bits and charging into hordes of mobs. Can also function as a tank.<br />
<br />
Warriors are yer standard melee class, see? Slashin' Nagas, chargin' at Slimes, and leapin' all over the place are all in a day's work.<br />
<br />
<br />
<br />
==Abilities==<br />
<br />
{|align="center" border="2" cellpadding="3" cellspacing="0" class="article-table article-table-selected"<br />
! scope="col"|Spell<br />
! scope="col"|Mana<br />
! scope="col"|Cooldown<br />
! scope="col"|Description<br />
|-<br />
|Leap<br />
|7<br />
|1.5<br />
|Causes your character to soar into the air for a good distance, causing a small bit of damage on landing. Useful for when you need to get out of a jam (Ouch, my kneecaps!)<br />
|-<br />
|Taunt<br />
|5<br />
|2.5<br />
|Causes a monster to focus it's attacks on you. Not really of much use in single player, but once threat mechanics are in place, this will be essential for tank type builds in SMP. (Hey, fish-face! Come and get some!)<br />
|-<br />
|Leash<br />
|5<br />
|.75<br />
|Pulls a monster toward you. Useful for those times the wizard doesn't feel like making it easy for you and standing still so you can run him through. (Get over here!)<br />
|-<br />
|Charge<br />
|5<br />
|1.5<br />
|<br />
Ahh, my sweet, sweet charge! Causes you to, well, charge forward. When you collide with a monster, it takes a good bit of damage and is sent flying back, as well as any of its buddies stupid enough to be nearby. Good for when you need to clear a path for your group, or just need to deal with a horde of mobs (For Narnia!)<br />
|-<br />
|Whirlwind<br />
|8<br />
|1.5<br />
|<br />
Great for yer close-qaurter adventures!<br />
Turn yerself around doing damage to mobs next to you!<br />
|}<br />
<br />
[[File:Warrior Skill - Leash|thumb|300px|right|Warrior using leash skill]][[File:Warrior Skill - Charge|thumb|300px|right|Warrior using charge]]<br />
<br />
==Ways to Build==<br />
*Berserker - Prioritize getting the best weapons as you can, and go for as many Strength/Dexterity increases as possible. A tiny bit of Fortitude every now and then should be enough to keep you alive.<br />
<br />
*Guardian - Armor, armor, armor! If you like to be able to shrug off blow after blow (including the dreaded arrow to the knee!), then the Guardian is for you. Prioritize Fortitude! Maybe 4 or 5 points to fort every level, and the rest to either Dexterity or Strength. Weapons are your second priority.<br />
*Battle tank - The balance of weapons and armor should keep any SMP party alive. Strength and Fortitude should be your main skill trees. Your job is to agro all the mosters and group them, a mage and a ranger can make quick work of a group. In SSP using your charge should kill most enemies.<br />
**Paladin - A branch off of battle tank, prioritizing strength and fortitude, followed by wisdom. The goal of this build is being able to use your abilities at all times, by having loads of mana, and being able to take a hit, while still dishing out damage. Very useful when playing SSP<br />
*Pure Berserker - Strength, strength, and more strength. This build gives the highest possible damage output for each level, but with low ciritcal hit chance. Only raise Strength with points, and rely on armour and weaponry for buffs to other stats.<br />
<br />
More to come!<br />
<br />
==Stats==<br />
Focus on getting a large fortitude and strength. Unlike other classes you only need stuff that has to do with you in particular. The ranger and mage should both get some strength power so they can fight if caught in close combat but a warrior should just focus on fortitude, strength and low amounts of dexterity.<br />
<br />
[[Category:Classes]]</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/Server_FeaturesServer Features2012-05-30T03:13:08Z<p>69.246.180.210: /* New Server Commands */</p>
<hr />
<div>===New Server Commands===<br />
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.<br />
<br />
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.<br />
<br />
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").<br />
<br />
{|border=1 cellpadding=5<br />
|+'''Player Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|spawn<br />
|Teleports the player to spawn (if enabled in server.properties)<br />
|-<br />
|who [player]<br />
|Gives the name, class, race, and level of the specified player (or yourself if the player isn't specified).<br />
|-<br />
|flags [<chunkX> <chunkZ> [dim]]<br />
|Spits out all flags on the chunk (pvp enabling/disabling, block protection, mob/animal spawning)<br />
|-<br />
|<nowiki>roll | rand | random</nowiki> [die size]<br />
|Spits out a random number in chat from 1 - <die size> (100 if none is given).<br />
|}<br />
<br />
<br />
<br />
{|border=1 cellpadding=5<br />
|+'''Console/Op Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|get <property><br />
|Tells you what the current value for a property in server.properties or areaCache.properties is.<br />
|-<br />
|set <property> <value><br />
|If possible, updates the value of the property in server.properties or areaCache.properties and applies it to the game immediately. Not all properties can be set for security or stability reasons (like ip-address or generate-structures)<br />
|-<br />
|reward <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Gives some currency to the player. If "mobdrop" is specified, it gives them a typical amount of gold from a monster of the player's level, times <mult>. Otherwise, it gives the player <amount> of <cur>, where <cur> is p, g, s, c, platinum, plat, gold, silver, or copper.<br />
|-<br />
|penalize <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Removes currency from the player (will report amount actually removed if they have less).<br />
|-<br />
|setspawn [<x> <z>]<br />
|Sets the spawn point to the given block coordinates (uses your current position if not specified)<br />
|-<br />
|<flag> [<chunkX> <chunkZ> [dim]]<br />
|<flag> may be protect-blocks, unprotect-blocks, prohibit-pvp, allow-pvp, default-pvp, no-mobs, spawn-mobs, no-animals, spawn-animals. Block protection prevents blocks from being dug, placed, or explodinated by non-ops, whereas prohibit-pvp and allow-pvp override the server's default pvp settings for that chunk. Explosions on the border of a protected chunk will not effect blocks inside it. Using unprotect-blocks and default-pvp will clear their respective effects. The mob/animal commands prevent or reinstate spawning for that creature type (though they can still wander into the chunk or spawn from mob spawners.)<br />
|-<br />
|clear-all <flag><br />
|Removes the flag from all chunks; <flag> may be protect-blocks, prohibit-pvp, allow-pvp, pvp, no-mobs, no-animals, flags<br />
|-<br />
|resize-ac [newsize]<br />
|Resizes the area cache (to the size in areaCache.properties if not specified). If shrinking, an area size higher than the number of players is recommended.<br />
|-<br />
|reset-ac [newsize]<br />
|Entirely cleans the area cache and resizes it (to the minSize in areaCache.properties if not specified). May fix lag if the server's acting up. Again, if shrinking, an area size higher than the number of players is recommended.<br />
|}<br />
<br />
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.<br />
<br />
===The Area Cache===<br />
"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, [[User:Frizzil|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!<br />
<br />
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?<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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) [http://en.wikipedia.org/wiki/Page_replacement_algorithm further reading]. The "growthFactor" tradeoffs are directly associated with that of a dynamic array's.<br />
<br />
<br />
{| border=1 cellpadding=5<br />
!|Property<br />
!|Default Value<br />
!|Description<br />
|-<br />
|minSize<br />
|64<br />
|The size to initialize the area cache at. Not bad to set it higher if you have a large server, to avoid the lag of resizing. Each player will need at least one area at any time, but players also frequently inhabit the same area, resulting in overlap.<br />
|-<br />
|verboseLogging<br />
|false<br />
|If set to true, will spit info out to the console every twenty ticks and whenever there's a cache resizing. Extremely useful during testing, extremely annoying otherwise.<br />
|-<br />
|avgPctUsageMax<br />
|.90<br />
|Triggers a "grow" when exceeded by "avgPctUsage." The percentage leftover (1-avgPctUsageMax) could be thought of your safety buffer; the larger it is, the less likely you'll have "area thrashing" before the avgPctUsage reflects the actual demand for areas.<br />
|-<br />
|pctUsageMax<br />
|.999<br />
|Triggers a "grow" when exceeded by "pctUsage." The percentage leftover (1-pctUsageMax) could be thought of as another safety buffer; the larger it is, the less likely you'll have an area unnecessarily reload before the tick is done and the pctUsage can be calculated. pctUsageMax is generally a safety net, and should be set to a very high value you're certain reflects an increased need for areas.<br />
|-<br />
|avgPctUsageMin<br />
|.70<br />
|Triggers a "shrink" when "avgPctUsage" < avgPctUsageMin/growthFactor. The difference between avgPctUsageMax and avgPctUsageMin could be thought of as another safety buffer; the larger it is, the less likely you'll have "twitchy" resizings as usage fluctuates (imagine min and max were the same, and the avgPctUsage were fluctuating around that number)<br />
|-<br />
|growthFactor<br />
|2.0<br />
|The relative amount to increase or decrease the cache's resources by when a "grow" or "shrink" occurs. E.g. 2.0 would double the existing cache size with each growth and halve it with each shrink.<br />
|-<br />
|avgPctUsagePastWeight<br />
|0.999<br />
|The weight to give to the past "avgPctUsage" when calculating the exponential average. Should be between .85 and 1.0. Basically, it determines the "quality" of avgPctUsage, smoothing it out with prior miss ratios. Too low and your cache will be too sensitive to fluctuations, causing excessive resizing and potentially crashing your server if bad enough-- too high and your cache is too resilient to immediate usage needs, growing only when it's too late and thus causing lag of Biblical proportions, also potentially crashing your server.<br />
|-<br />
|emergencyResetSize<br />
|131072<br />
|An upper bound on your cache size that, once exceeded, forces the area cache to entirely reset (like the "/reset-ac" command.) Basically, set it to an amount you ''know'' will never be exceeded, like 50 times the maximum players on your server (since a player isn't liable to need more areas than can appear on their radar, 50 areas per player is an incredibly generous estimate you can be 99.999% certain is the result of erroneous growth.)<br />
|}<br />
<br />
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)<br />
<br />
And most importantly, enjoy speeding up your server and improving its stability!</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/Server_FeaturesServer Features2012-05-29T04:30:51Z<p>69.246.180.210: /* The Area Cache */</p>
<hr />
<div>===New Server Commands===<br />
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.<br />
<br />
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.<br />
<br />
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").<br />
<br />
{|border=1 cellpadding=5<br />
|+'''Player Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|spawn<br />
|Teleports the player to spawn<br />
|-<br />
|who [player]<br />
|Gives the name, class, race, and level of the specified player (or yourself if the player isn't specified).<br />
|-<br />
|flags [<chunkX> <chunkZ> [dim]]<br />
|Spits out all flags on the chunk (pvp enabling/disabling, block protection)<br />
|-<br />
|<nowiki>roll | rand | random</nowiki> [die size]<br />
|Spits out a random number in chat from 1 - <die size> (100 if none is given).<br />
|}<br />
<br />
<br />
<br />
{|border=1 cellpadding=5<br />
|+'''Console/Op Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|get <property><br />
|Tells you what the current value for a property in server.properties or areaCache.properties is.<br />
|-<br />
|set <property> <value><br />
|If possible, updates the value of the property in server.properties or areaCache.properties and applies it to the game immediately. Not all properties can be set for security or stability reasons (like ip-address or generate-structures)<br />
|-<br />
|reward <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Gives some currency to the player. If "mobdrop" is specified, it gives them a typical amount of gold from a monster of the player's level, times <mult>. Otherwise, it gives the player <amount> of <cur>, where <cur> is p, g, s, c, platinum, plat, gold, silver, or copper.<br />
|-<br />
|penalize <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Removes currency from the player (will report amount actually removed if they have less).<br />
|-<br />
|setspawn [<x> <z>]<br />
|Sets the spawn point to the given block coordinates (uses your current position if not specified)<br />
|-<br />
|<flag> [<chunkX> <chunkZ> [dim]]<br />
|<flag> may be protect-blocks, unprotect-blocks, prohibit-pvp, allow-pvp, default-pvp, no-mobs, spawn-mobs, no-animals, spawn-animals. Block protection prevents blocks from being dug, placed, or explodinated by non-ops, whereas prohibit-pvp and allow-pvp override the server's default pvp settings for that chunk. Explosions on the border of a protected chunk will not effect blocks inside it. Using unprotect-blocks and default-pvp will clear their respective effects. The mob/animal commands prevent or reinstate spawning for that creature type (though they can still wander into the chunk or spawn from mob spawners.)<br />
|-<br />
|clear-all <flag><br />
|Removes the flag from all chunks; <flag> may be protect-blocks, prohibit-pvp, allow-pvp, pvp, no-mobs, no-animals, flags<br />
|-<br />
|resize-ac [newsize]<br />
|Resizes the area cache (to the size in areaCache.properties if not specified). If shrinking, an area size higher than the number of players is recommended.<br />
|-<br />
|reset-ac [newsize]<br />
|Entirely cleans the area cache and resizes it (to the minSize in areaCache.properties if not specified). May fix lag if the server's acting up. Again, if shrinking, an area size higher than the number of players is recommended.<br />
|}<br />
<br />
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.<br />
<br />
===The Area Cache===<br />
"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, [[User:Frizzil|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!<br />
<br />
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?<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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) [http://en.wikipedia.org/wiki/Page_replacement_algorithm further reading]. The "growthFactor" tradeoffs are directly associated with that of a dynamic array's.<br />
<br />
<br />
{| border=1 cellpadding=5<br />
!|Property<br />
!|Default Value<br />
!|Description<br />
|-<br />
|minSize<br />
|64<br />
|The size to initialize the area cache at. Not bad to set it higher if you have a large server, to avoid the lag of resizing. Each player will need at least one area at any time, but players also frequently inhabit the same area, resulting in overlap.<br />
|-<br />
|verboseLogging<br />
|false<br />
|If set to true, will spit info out to the console every twenty ticks and whenever there's a cache resizing. Extremely useful during testing, extremely annoying otherwise.<br />
|-<br />
|avgPctUsageMax<br />
|.90<br />
|Triggers a "grow" when exceeded by "avgPctUsage." The percentage leftover (1-avgPctUsageMax) could be thought of your safety buffer; the larger it is, the less likely you'll have "area thrashing" before the avgPctUsage reflects the actual demand for areas.<br />
|-<br />
|pctUsageMax<br />
|.999<br />
|Triggers a "grow" when exceeded by "pctUsage." The percentage leftover (1-pctUsageMax) could be thought of as another safety buffer; the larger it is, the less likely you'll have an area unnecessarily reload before the tick is done and the pctUsage can be calculated. pctUsageMax is generally a safety net, and should be set to a very high value you're certain reflects an increased need for areas.<br />
|-<br />
|avgPctUsageMin<br />
|.70<br />
|Triggers a "shrink" when "avgPctUsage" < avgPctUsageMin/growthFactor. The difference between avgPctUsageMax and avgPctUsageMin could be thought of as another safety buffer; the larger it is, the less likely you'll have "twitchy" resizings as usage fluctuates (imagine min and max were the same, and the avgPctUsage were fluctuating around that number)<br />
|-<br />
|growthFactor<br />
|2.0<br />
|The relative amount to increase or decrease the cache's resources by when a "grow" or "shrink" occurs. E.g. 2.0 would double the existing cache size with each growth and halve it with each shrink.<br />
|-<br />
|avgPctUsagePastWeight<br />
|0.999<br />
|The weight to give to the past "avgPctUsage" when calculating the exponential average. Should be between .85 and 1.0. Basically, it determines the "quality" of avgPctUsage, smoothing it out with prior miss ratios. Too low and your cache will be too sensitive to fluctuations, causing excessive resizing and potentially crashing your server if bad enough-- too high and your cache is too resilient to immediate usage needs, growing only when it's too late and thus causing lag of Biblical proportions, also potentially crashing your server.<br />
|-<br />
|emergencyResetSize<br />
|131072<br />
|An upper bound on your cache size that, once exceeded, forces the area cache to entirely reset (like the "/reset-ac" command.) Basically, set it to an amount you ''know'' will never be exceeded, like 50 times the maximum players on your server (since a player isn't liable to need more areas than can appear on their radar, 50 areas per player is an incredibly generous estimate you can be 99.999% certain is the result of erroneous growth.)<br />
|}<br />
<br />
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)<br />
<br />
And most importantly, enjoy speeding up your server and improving its stability!</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/Server_FeaturesServer Features2012-05-29T04:24:47Z<p>69.246.180.210: /* The Area Cache */</p>
<hr />
<div>===New Server Commands===<br />
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.<br />
<br />
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.<br />
<br />
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").<br />
<br />
{|border=1 cellpadding=5<br />
|+'''Player Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|spawn<br />
|Teleports the player to spawn<br />
|-<br />
|who [player]<br />
|Gives the name, class, race, and level of the specified player (or yourself if the player isn't specified).<br />
|-<br />
|flags [<chunkX> <chunkZ> [dim]]<br />
|Spits out all flags on the chunk (pvp enabling/disabling, block protection)<br />
|-<br />
|<nowiki>roll | rand | random</nowiki> [die size]<br />
|Spits out a random number in chat from 1 - <die size> (100 if none is given).<br />
|}<br />
<br />
<br />
<br />
{|border=1 cellpadding=5<br />
|+'''Console/Op Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|get <property><br />
|Tells you what the current value for a property in server.properties or areaCache.properties is.<br />
|-<br />
|set <property> <value><br />
|If possible, updates the value of the property in server.properties or areaCache.properties and applies it to the game immediately. Not all properties can be set for security or stability reasons (like ip-address or generate-structures)<br />
|-<br />
|reward <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Gives some currency to the player. If "mobdrop" is specified, it gives them a typical amount of gold from a monster of the player's level, times <mult>. Otherwise, it gives the player <amount> of <cur>, where <cur> is p, g, s, c, platinum, plat, gold, silver, or copper.<br />
|-<br />
|penalize <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Removes currency from the player (will report amount actually removed if they have less).<br />
|-<br />
|setspawn [<x> <z>]<br />
|Sets the spawn point to the given block coordinates (uses your current position if not specified)<br />
|-<br />
|<flag> [<chunkX> <chunkZ> [dim]]<br />
|<flag> may be protect-blocks, unprotect-blocks, prohibit-pvp, allow-pvp, default-pvp, no-mobs, spawn-mobs, no-animals, spawn-animals. Block protection prevents blocks from being dug, placed, or explodinated by non-ops, whereas prohibit-pvp and allow-pvp override the server's default pvp settings for that chunk. Explosions on the border of a protected chunk will not effect blocks inside it. Using unprotect-blocks and default-pvp will clear their respective effects. The mob/animal commands prevent or reinstate spawning for that creature type (though they can still wander into the chunk or spawn from mob spawners.)<br />
|-<br />
|clear-all <flag><br />
|Removes the flag from all chunks; <flag> may be protect-blocks, prohibit-pvp, allow-pvp, pvp, no-mobs, no-animals, flags<br />
|-<br />
|resize-ac [newsize]<br />
|Resizes the area cache (to the size in areaCache.properties if not specified). If shrinking, an area size higher than the number of players is recommended.<br />
|-<br />
|reset-ac [newsize]<br />
|Entirely cleans the area cache and resizes it (to the minSize in areaCache.properties if not specified). May fix lag if the server's acting up. Again, if shrinking, an area size higher than the number of players is recommended.<br />
|}<br />
<br />
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.<br />
<br />
===The Area Cache===<br />
"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, [[User:Frizzil|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!<br />
<br />
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?<br />
<br />
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.<br />
<br />
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.<br />
<br />
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 slow response to quickly increasing needs, especially at larger cache sizes.<br />
<br />
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) [http://en.wikipedia.org/wiki/Page_replacement_algorithm further reading]. The "growthFactor" tradeoffs are directly associated with that of a dynamic array's.<br />
<br />
<br />
{| border=1 cellpadding=5<br />
!|Property<br />
!|Default Value<br />
!|Description<br />
|-<br />
|minSize<br />
|64<br />
|The size to initialize the area cache at. Not bad to set it higher if you have a large server, to avoid the lag of resizing. Each player will need at least one area at any time, but players also frequently inhabit the same area, resulting in overlap.<br />
|-<br />
|verboseLogging<br />
|false<br />
|If set to true, will spit info out to the console every twenty ticks and whenever there's a cache resizing. Extremely useful during testing, extremely annoying otherwise.<br />
|-<br />
|avgPctUsageMax<br />
|.90<br />
|Triggers a "grow" when exceeded by "avgPctUsage." The percentage leftover (1-avgPctUsageMax) could be thought of your safety buffer; the larger it is, the less likely you'll have "area thrashing" before the avgPctUsage reflects the actual demand for areas.<br />
|-<br />
|pctUsageMax<br />
|.999<br />
|Triggers a "grow" when exceeded by "pctUsage." The percentage leftover (1-pctUsageMax) could be thought of as another safety buffer; the larger it is, the less likely you'll have an area unnecessarily reload before the tick is done and the pctUsage can be calculated. pctUsageMax is generally a safety net, and should be set to a very high value you're certain reflects an increased need for areas.<br />
|-<br />
|avgPctUsageMin<br />
|.70<br />
|Triggers a "shrink" when "avgPctUsage" < avgPctUsageMin/growthFactor. The difference between avgPctUsageMax and avgPctUsageMin could be thought of as another safety buffer; the larger it is, the less likely you'll have "twitchy" resizings as usage fluctuates (imagine min and max were the same, and the avgPctUsage were fluctuating around that number)<br />
|-<br />
|growthFactor<br />
|2.0<br />
|The relative amount to increase or decrease the cache's resources by when a "grow" or "shrink" occurs. E.g. 2.0 would double the existing cache size with each growth and halve it with each shrink.<br />
|-<br />
|avgPctUsagePastWeight<br />
|0.999<br />
|The weight to give to the past "avgPctUsage" when calculating the exponential average. Should be between .85 and 1.0. Basically, it determines the "quality" of avgPctUsage, smoothing it out with prior miss ratios. Too low and your cache will be too sensitive to fluctuations, causing excessive resizing and potentially crashing your server if bad enough-- too high and your cache is too resilient to immediate usage needs, growing only when it's too late and thus causing lag of Biblical proportions, also potentially crashing your server.<br />
|-<br />
|emergencyResetSize<br />
|131072<br />
|An upper bound on your cache size that, once exceeded, forces the area cache to entirely reset (like the "/reset-ac" command.) Basically, set it to an amount you ''know'' will never be exceeded, like 50 times the maximum players on your server (since a player isn't liable to need more areas than can appear on their radar, 50 areas per player is an incredibly generous estimate you can be 99.999% certain is the result of erroneous growth.)<br />
|}<br />
<br />
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)<br />
<br />
And most importantly, enjoy speeding up your server and improving its stability!</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/NagaNaga2012-05-27T09:30:44Z<p>69.246.180.210: </p>
<hr />
<div>[[File:2012-05-27 04.55.22.png|thumb|300px|]][[File:2012-05-27 04.55.22.png|thumb|300px|]][[File:2012-05-27 04.56.43.png|thumb|300px|]]Nagas are a strange mixture of snake and human. They carry golden axes, though they never drop them when slain. Like all hostile mobs in the game, they can spawn with unique names and slight recolors/palette changes. As of 0.6, the Nagas have had a major texture improvement.<br />
<br />
It is no coincidence that the old Naga resemble Chaos from Sonic Adventure II: Battle. The orange-cyan-green color scheme was subconsciously selected because [[The Hack/Mine Team|Frizzil]] secretly mourns for his long lost Chao, Douglas, who died many years ago after attaining level 99 and dominating the Chao olympics. Though Douglas's children live on, Frizzil never quite had the time to say "I love you" in between the Radical Highway runs and the dumping of green chemicals down Douglas's throat. No matter how many Chao he bred, none could make up for the opportunity he missed....</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/NagaNaga2012-05-27T09:29:48Z<p>69.246.180.210: </p>
<hr />
<div>[[File:2012-05-27 04.55.22.png|thumb|300px|]][[File:2012-05-27 04.55.22.png|thumb|300px|]][[File:2012-05-27 04.56.43.png|thumb|300px|]]Nagas are a strange mixture of snake and human. They carry golden axes, though they never drop them when slain. Like all hostile mobs in the game, they can spawn with unique names and slight recolors/palette changes.<br />
<br />
It is no coincidence that Naga resemble Chaos from Sonic Adventure II: Battle. The orange-cyan-green color scheme was subconsciously selected because [[The Hack/Mine Team|Frizzil]] secretly mourns for his long lost Chao, Douglas, who died many years ago after attaining level 99 and dominating the Chao olympics. Though Douglas's children live on, Frizzil never quite had the time to say "I love you" in between the Radical Highway runs and the dumping of green chemicals down Douglas's throat. No matter how many Chao he bred, none could make up for the opportunity he missed....</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/Server_FeaturesServer Features2012-05-27T00:07:39Z<p>69.246.180.210: </p>
<hr />
<div>===New Server Commands===<br />
These commands are new to Hack/Mine as of version 0.6 (not officially released yet.) 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.<br />
<br />
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.<br />
<br />
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").<br />
<br />
{|border=1<br />
|+'''Player Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|spawn<br />
|Teleports the player to spawn<br />
|-<br />
|who [player]<br />
|Gives the name, class, race, and level of the specified player (or yourself if the player isn't specified).<br />
|-<br />
|flags [<chunkX> <chunkZ> [dim]]<br />
|Spits out all flags on the chunk (pvp enabling/disabling, block protection)<br />
|-<br />
|<nowiki>roll | rand | random</nowiki> [die size]<br />
|Spits out a random number in chat from 1 - <die size> (100 if none is given).<br />
|}<br />
<br />
<br />
<br />
{|border=1<br />
|+'''Console/Op Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|reward <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Gives some currency to the player. If "mobdrop" is specified, it gives them a typical amount of gold from a monster of the player's level, times <mult>. Otherwise, it gives the player <amount> of <cur>, where <cur> is p, g, s, c, platinum, plat, gold, silver, or copper.<br />
|-<br />
|penalize <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Removes currency from the player (will report amount actually removed if they have less).<br />
|-<br />
|setspawn <x> <z><br />
|Sets the spawn point to the given block coordinates.<br />
|-<br />
|<flag> [<chunkX> <chunkZ> [dim]]<br />
|<flag> may be protect-blocks, unprotect-blocks, prohibit-pvp, allow-pvp, default-pvp, no-mobs, spawn-mobs, no-animals, spawn-animals. Block protection prevents blocks from being dug, placed, or explodinated by non-ops, whereas prohibit-pvp and allow-pvp override the server's default pvp settings for that chunk. Explosions on the border of a protected chunk will not effect blocks inside it. Using unprotect-blocks and default-pvp will clear their respective effects. The mob/animal commands prevent or reinstate spawning for that creature type (though they can still wander into the chunk or spawn from mob spawners.)<br />
|-<br />
|clear-all <flag><br />
|Removes the flag from all chunks; <flag> may be protect-blocks, prohibit-pvp, allow-pvp, pvp, no-mobs, no-animals, flags<br />
|-<br />
|resize-ac [newsize]<br />
|Resizes the area cache (to the size in areaCache.properties if not specified). If shrinking, an area size higher than the number of players is recommended.<br />
|-<br />
|reset-ac [newsize]<br />
|Entirely cleans the area cache and resizes it (to the size in areaCache.properties if not specified). May fix lag if the server's acting up. Again, if shrinking, an area size higher than the number of players is recommended.<br />
|}<br />
<br />
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.<br />
<br />
===The Area Cache===<br />
"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. Also, [[User:Frizzil|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!<br />
<br />
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?<br />
<br />
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", and at extreme sizes results in general lag and high RAM consumption.<br />
<br />
Each tick, the ratio of cache queries that were misses is calculated and stored in "pctMiss." This number is extremely small (generally peaking in E-4), but is still significant given that a cache miss can be over 1000 times slower than a cache hit. The exponential average of this number is stored in "avgPctMiss." I.e. avgPctMiss is set to avgPctMiss * w + (1-w) * pctMiss each tick, where w is "avgPctMissPastWeight" This gives three important numbers for you to tweak-- avgPctMissThreshold and pctMissThreshold, which "grow" the cache when exceeded, and "avgPctMissPastWeight", which is "how significant are recent 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.) If your past weight is too low, your cache will be too sensitive to minor fluctuations and grow too frequently, eventually crashing your server from RAM consumption or massive lag. If your past weight is too high, your cache will be too resilient to fluctuations, resulting in "area thrashing" as 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.) Basically, fine tune these numbers to get the perfect amount of responsiveness to cache misses, only growing when necessary to support the increased needs of players.<br />
<br />
When the cache "grows", it takes a moment to copy it's data into a new, larger location in memory. "growthFactor" determines how much larger 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 resizing. Values closer to 1 may result in good matching of resources, but will result in excessive copying (and even slow response to needs), especially at larger cache sizes.<br />
<br />
For you fellow computer science geeks, this is 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) [http://en.wikipedia.org/wiki/Page_replacement_algorithm further reading]. The "growthFactor" tradeoffs are directly associated with that of a dynamic array's.<br />
<br />
<br />
{| border=1<br />
!|Property<br />
!|Default Value<br />
!|Description<br />
|-<br />
|startingCacheSize<br />
|16<br />
|The size to initialize the area cache at. Not bad to set it higher if you have a large server, to avoid the lag of resizing. Each player will need at least one area at any time, but players also frequently inhabit the same area, resulting in overlap.<br />
|-<br />
|verboseLogging<br />
|false<br />
|If set to true, will spit info out to the console whenever there's a "cache miss" or a cache resizing. Specifically, the number of misses, pctMisses, and avgPctMisses at that tick.<br />
|-<br />
|avgPctMissThreshold<br />
|1.5E-4<br />
|Triggers a "grow" when exceeded by "avgPctMiss." "E-4" means "* 10^-4," or "times 10 to the -4." It's a very small ratio, because there are thousands of hits per tick, misses occurring only when an Area is either first loaded or reloaded as the result of offloading the area despite it still being in use. If the latter is happening too much, the cache needs to grow to support the increased demand for Areas. If the threshold is too small, however, the cache will grow in response to initial Area loading (something that cannot be helped and must be allowed for.)<br />
|-<br />
|pctMissThreshold<br />
|1.0<br />
|Triggers a "grow" when exceeded by "pctMiss" (set to 100% by default, basically not used. Almost like an emergency "GROW MY DANG CACHE NOW" threshold, which may be ill-advised. It's basically equivalent to using avgPctMissThreshold if avgPctMissPastWeight were equal to 0)<br />
|-<br />
|growthFactor<br />
|2.0<br />
|The relative amount to increase the cache's resources by when a "grow" occurs. E.g. 2.0 would double the existing cache size with each growth.<br />
|-<br />
|avgPctMissPastWeight<br />
|0.96<br />
|The weight to give to the past "avgPctMiss" when calculating the exponential average. Should be between .85 and 1.0. Basically, it determines the "quality" of avgPctMissThreshold, smoothing it out with prior miss ratios. Too low and your cache will be too sensitive to minor fluctuations, causing excessive growth and eventually crashing your server-- too high and your cache is too resilient to increased cache misses, never growing and thus causing lag of Biblical proportions and also potentially crashing your server.<br />
|-<br />
|emergencyResetSize<br />
|131072<br />
|An upper bound on your cache size that, once exceeded, forces the area cache to entirely reset (like the "/reset-ac" command.) Basically, set it to an amount you ''know'' will never be exceeded, like 50 times the maximum players on your server (since a player isn't liable to need more areas than can appear on their radar, 50 areas per player is an incredibly generous estimate you can be 99.999% certain is the result of erroneous growth.)<br />
|}<br />
<br />
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)<br />
<br />
And most importantly, enjoy speeding up your server and improving its stability!</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/Server_FeaturesServer Features2012-05-27T00:06:24Z<p>69.246.180.210: </p>
<hr />
<div>===New Server Commands===<br />
These commands are new to Hack/Mine as of version 0.6 (not officially released yet.) 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.<br />
<br />
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.<br />
<br />
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").<br />
<br />
{|border=1<br />
|+'''Player Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|spawn<br />
|Teleports the player to spawn<br />
|-<br />
|who [player]<br />
|Gives the name, class, race, and level of the specified player (or yourself if the player isn't specified).<br />
|-<br />
|flags [<chunkX> <chunkZ> [dim]]<br />
|Spits out all flags on the chunk (pvp enabling/disabling, block protection)<br />
|-<br />
|<nowiki>roll | rand | random</nowiki> [die size]<br />
|Spits out a random number in chat from 1 - <die size> (100 if none is given).<br />
|}<br />
<br />
<br />
<br />
{|border=1<br />
|+'''Console/Op Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|reward <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Gives some currency to the player. If "mobdrop" is specified, it gives them a typical amount of gold from a monster of the player's level, times <mult>. Otherwise, it gives the player <amount> of <cur>, where <cur> is p, g, s, c, platinum, plat, gold, silver, or copper.<br />
|-<br />
|penalize <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Removes currency from the player (will report amount actually removed if they have less).<br />
|-<br />
|setspawn <x> <z><br />
|Sets the spawn point to the given block coordinates.<br />
|-<br />
|<flag> [<chunkX> <chunkZ> [dim]]<br />
|<flag> may be protect-blocks, unprotect-blocks, prohibit-pvp, allow-pvp, default-pvp, no-mobs, spawn-mobs, no-animals, spawn-animals. Block protection prevents blocks from being dug, placed, or explodinated by non-ops, whereas prohibit-pvp and allow-pvp override the server's default pvp settings for that chunk. Explosions on the border of a protected chunk will not effect blocks inside it. Using unprotect-blocks and default-pvp will clear their respective effects. The mob/animal commands prevent or reinstate spawning for that creature type (though they can still wander into the chunk or spawn from mob spawners.)<br />
|-<br />
|clear-all <flag><br />
|Removes the flag from all chunks; <flag> may be protect-blocks, prohibit-pvp, allow-pvp, pvp, no-mobs, no-animals, flags<br />
|-<br />
|resize-ac [newsize]<br />
|Resizes the area cache (to the size in areaCache.properties if not specified). If shrinking, an area size higher than the number of players is recommended.<br />
|-<br />
|reset-ac [newsize]<br />
|Entirely cleans the area cache and resizes it (to the size in areaCache.properties if not specified). May fix lag if the server's acting up. Again, if shrinking, an area size higher than the number of players is recommended.<br />
|}<br />
<br />
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.<br />
<br />
===The Area Cache===<br />
"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. Also, [[User:Frizzil|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!<br />
<br />
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?<br />
<br />
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", and at extreme sizes results in general lag and high RAM consumption.<br />
<br />
Each tick, the ratio of cache queries that were misses is calculated and stored in "pctMiss." This number is extremely small (generally peaking in E-4), but is still significant given that a cache miss can be over 1000 times slower than a cache hit. The exponential average of this number is stored in "avgPctMiss." I.e. avgPctMiss is set to avgPctMiss * w + (1-w) * pctMiss each tick, where w is "avgPctMissPastWeight" This gives three important numbers for you to tweak-- avgPctMissThreshold and pctMissThreshold, which "grow" the cache when exceeded, and "avgPctMissPastWeight", which is "how significant are recent 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.) If your past weight is too low, your cache will be too sensitive to minor fluctuations and grow too frequently, eventually crashing your server from RAM consumption or massive lag. If your past weight is too high, your cache will be too resilient to fluctuations, resulting in "area thrashing" as 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.) Basically, fine tune these numbers to get the perfect amount of responsiveness to cache misses, only growing when necessary to support the increased needs of players.<br />
<br />
When the cache "grows", it takes a moment to copy it's data into a new, larger location in memory. "growthFactor" determines how much larger 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 resizing. Values closer to 1 may result in good matching of resources, but will result in excessive copying (and even slow response to needs), especially at larger cache sizes.<br />
<br />
For you fellow computer science geeks, this is 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) [http://en.wikipedia.org/wiki/Page_replacement_algorithm further reading]. The "growthFactor" tradeoffs are directly associated with that of a dynamic array's.<br />
<br />
<br />
{| border=1<br />
!|Property<br />
!|Default Value<br />
!|Description<br />
|-<br />
|startingCacheSize<br />
|16<br />
|The size to initialize the area cache at. Not bad to set it higher if you have a large server, to avoid the lag of resizing. Each player will need at least one area at any time, but players also frequently inhabit the same area, resulting in overlap.<br />
|-<br />
|verboseLogging<br />
|false<br />
|If set to true, will spit info out to the console whenever there's a "cache miss" or a cache resizing. Specifically, the number of misses, pctMisses, and avgPctMisses at that tick.<br />
|-<br />
|avgPctMissThreshold<br />
|1.0E-4<br />
|Triggers a "grow" when exceeded by "avgPctMiss." "E-4" means "10^-4," or "10 to the -4." It's a very small ratio, because there are thousands of hits per tick, misses occurring only when an Area is either first loaded or reloaded as the result of offloading the area despite it still being in use. If the latter is happening too much, the cache needs to grow to support the increased demand for Areas. If the threshold is too small, however, the cache will grow in response to initial Area loading (something that cannot be helped and must be allowed for.)<br />
|-<br />
|pctMissThreshold<br />
|1.0<br />
|Triggers a "grow" when exceeded by "pctMiss" (set to 100% by default, basically not used. Almost like an emergency "GROW MY DANG CACHE NOW" threshold, which may be ill-advised. It's basically equivalent to using avgPctMissThreshold if avgPctMissPastWeight were equal to 0)<br />
|-<br />
|growthFactor<br />
|2.0<br />
|The relative amount to increase the cache's resources by when a "grow" occurs. E.g. 2.0 would double the existing cache size with each growth.<br />
|-<br />
|avgPctMissPastWeight<br />
|0.96<br />
|The weight to give to the past "avgPctMiss" when calculating the exponential average. Should be between .85 and 1.0. Basically, it determines the "quality" of avgPctMissThreshold, smoothing it out with prior miss ratios. Too low and your cache will be too sensitive to minor fluctuations, causing excessive growth and eventually crashing your server-- too high and your cache is too resilient to increased cache misses, never growing and thus causing lag of Biblical proportions and also potentially crashing your server.<br />
|-<br />
|emergencyResetSize<br />
|131072<br />
|An upper bound on your cache size that, once exceeded, forces the area cache to entirely reset (like the "/reset-ac" command.) Basically, set it to an amount you ''know'' will never be exceeded, like 50 times the maximum players on your server (since a player isn't liable to need more areas than can appear on their radar, 50 areas per player is an incredibly generous estimate you can be 99.999% certain is the result of erroneous growth.)<br />
|}<br />
<br />
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)<br />
<br />
And most importantly, enjoy speeding up your server and improving its stability!</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/Server_FeaturesServer Features2012-05-27T00:03:24Z<p>69.246.180.210: /* The Area Cache */</p>
<hr />
<div>===New Server Commands===<br />
These commands are new to Hack/Mine as of version 0.6 (not officially released yet.) 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.<br />
<br />
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.<br />
<br />
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").<br />
<br />
{|border=1<br />
|+'''Player Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|spawn<br />
|Teleports the player to spawn<br />
|-<br />
|who [player]<br />
|Gives the name, class, race, and level of the specified player (or yourself if the player isn't specified).<br />
|-<br />
|flags [<chunkX> <chunkZ> [dim]]<br />
|Spits out all flags on the chunk (pvp enabling/disabling, block protection)<br />
|-<br />
|<nowiki>roll | rand | random</nowiki> [die size]<br />
|Spits out a random number in chat from 1 - <die size> (100 if none is given).<br />
|}<br />
<br />
<br />
<br />
{|border=1<br />
|+'''Console/Op Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|reward <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Gives some currency to the player. If "mobdrop" is specified, it gives them a typical amount of gold from a monster of the player's level, times <mult>. Otherwise, it gives the player <amount> of <cur>, where <cur> is p, g, s, c, platinum, plat, gold, silver, or copper.<br />
|-<br />
|penalize <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Removes currency from the player (will report amount actually removed if they have less).<br />
|-<br />
|setspawn <x> <z><br />
|Sets the spawn point to the given block coordinates.<br />
|-<br />
|<flag> [<chunkX> <chunkZ> [dim]]<br />
|<flag> may be protect-blocks, unprotect-blocks, prohibit-pvp, allow-pvp, default-pvp, no-mobs, spawn-mobs, no-animals, spawn-animals. Block protection prevents blocks from being dug, placed, or explodinated by non-ops, whereas prohibit-pvp and allow-pvp override the server's default pvp settings for that chunk. Explosions on the border of a protected chunk will not effect blocks inside it. Using unprotect-blocks and default-pvp will clear their respective effects. The mob/animal commands prevent or reinstate spawning for that creature type (though they can still wander into the chunk or spawn from mob spawners.)<br />
|-<br />
|clear-all <flag><br />
|Removes the flag from all chunks; <flag> may be protect-blocks, prohibit-pvp, allow-pvp, pvp, no-mobs, no-animals, flags<br />
|-<br />
|resize-ac [newsize]<br />
|Resizes the area cache (to the size in areaCache.properties if not specified). If shrinking, an area size higher than the number of players is recommended.<br />
|-<br />
|reset-ac [newsize]<br />
|Entirely cleans the area cache and resizes it (to the size in areaCache.properties if not specified). May fix lag if the server's acting up. Again, if shrinking, an area size higher than the number of players is recommended.<br />
|}<br />
<br />
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.<br />
<br />
===The Area Cache===<br />
"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. Also, [[User:Frizzil|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!<br />
<br />
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?<br />
<br />
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", and at extreme sizes results in general lag and high RAM consumption.<br />
<br />
Each tick, the ratio of cache queries that were misses is calculated and stored in "pctMiss." This number is extremely small (generally peaking in E-4), but is still significant given that a cache miss can be over 1000 times slower than a cache hit. The exponential average of this number is stored in "avgPctMiss." I.e. avgPctMiss is set to avgPctMiss * w + (1-w) * pctMiss each tick, where w is "avgPctMissPastWeight" This gives three important numbers for you to tweak-- avgPctMissThreshold and pctMissThreshold, which "grow" the cache when exceeded, and "avgPctMissPastWeight", which is "how significant are recent 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.) If your past weight is too low, your cache will be too sensitive to minor fluctuations and grow too frequently, eventually crashing your server from RAM consumption or massive lag. If your past weight is too high, your cache will be too resilient to fluctuations, resulting in "area thrashing" as 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.) Basically, fine tune these numbers to get the perfect amount of responsiveness to cache misses, only growing when necessary to support the increased needs of players.<br />
<br />
When the cache "grows", it takes a moment to copy it's data into a new, larger location in memory. "growthFactor" determines how much larger 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 resizing. Values closer to 1 may result in good matching of resources, but will result in excessive copying (and even slow response to needs), especially at larger cache sizes.<br />
<br />
For you fellow computer science geeks, this is 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) [http://en.wikipedia.org/wiki/Page_replacement_algorithm further reading]. The "growthFactor" tradeoffs are directly associated with that of a dynamic array's.<br />
<br />
<br />
{| border=1<br />
!|Property<br />
!|Default Value<br />
!|Description<br />
|-<br />
|startingCacheSize<br />
|16<br />
|The size to initialize the area cache at. Not bad to set it higher if you have a large server, to avoid the lag of resizing. Each player will need at least one area at any time, but players also frequently inhabit the same area, resulting in overlap.<br />
|-<br />
|verboseLogging<br />
|false<br />
|If set to true, will spit info out to the console whenever there's a "cache miss" or a cache resizing. Specifically, the number of misses, pctMisses, and avgPctMisses at that tick.<br />
|-<br />
|avgPctMissThreshold<br />
|1.0E-4<br />
|Triggers a "grow" when exceeded by "avgPctMiss." "E-4" means "10^-4," or "10 to the -4." It's a very small ratio, because there are thousands of hits per tick, misses occurring only when an Area is either first loaded or reloaded as the result of offloading the area despite it still being in use. If the latter is happening too much, the cache needs to grow to support the increased demand for Areas. If the threshold is too small, however, the cache will grow in response to initial Area loading (something that cannot be helped and must be allowed for.)<br />
|-<br />
|pctMissThreshold<br />
|1.0<br />
|Triggers a "grow" when exceeded by "pctMiss" (set to 100% by default, basically not used. Almost like an emergency "GROW MY DANG CACHE NOW" threshold, which may be ill-advised. It's basically equivalent to using avgPctMissThreshold if avgPctMissPastWeight were equal to 0)<br />
|-<br />
|growthFactor<br />
|2.0<br />
|The relative amount to increase the cache's resources by when a "grow" occurs.<br />
|-<br />
|avgPctMissPastWeight<br />
|0.96<br />
|The weight to give to the past "avgPctMiss" when calculating the exponential average. Should be between .85 and 1.0. Basically, it determines the "quality" of avgPctMissThreshold, smoothing it out with prior miss ratios. Too low and your cache will be too sensitive to minor fluctuations, causing excessive growth and eventually crashing your server-- too high and your cache is too resilient to increased cache misses, never growing and thus causing lag of Biblical proportions and also potentially crashing your server.<br />
|-<br />
|emergencyResetSize<br />
|131072<br />
|An upper bound on your cache size that, once exceeded, forces the area cache to reset (like the "/reset-ac" command.) Basically, set it to an amount you ''know'' will never be exceeded, like 50 times the maximum players on your server (since a player isn't liable to need more areas than can appear on their radar, 50 areas per player is an incredibly generous estimate you can be 99.999% certain is the result of erroneous growth.)<br />
|}<br />
<br />
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)<br />
<br />
And most importantly, enjoy speeding up your server and improving its stability!</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/Server_FeaturesServer Features2012-05-26T23:37:23Z<p>69.246.180.210: </p>
<hr />
<div>===New Server Commands===<br />
These commands are new to Hack/Mine as of version 0.6 (not officially released yet.) 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.<br />
<br />
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.<br />
<br />
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").<br />
<br />
{|border=1<br />
|+'''Player Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|spawn<br />
|Teleports the player to spawn<br />
|-<br />
|who [player]<br />
|Gives the name, class, race, and level of the specified player (or yourself if the player isn't specified).<br />
|-<br />
|flags [<chunkX> <chunkZ> [dim]]<br />
|Spits out all flags on the chunk (pvp enabling/disabling, block protection)<br />
|-<br />
|<nowiki>roll | rand | random</nowiki> [die size]<br />
|Spits out a random number in chat from 1 - <die size> (100 if none is given).<br />
|}<br />
<br />
<br />
<br />
{|border=1<br />
|+'''Console/Op Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|reward <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Gives some currency to the player. If "mobdrop" is specified, it gives them a typical amount of gold from a monster of the player's level, times <mult>. Otherwise, it gives the player <amount> of <cur>, where <cur> is p, g, s, c, platinum, plat, gold, silver, or copper.<br />
|-<br />
|penalize <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Removes currency from the player (will report amount actually removed if they have less).<br />
|-<br />
|setspawn <x> <z><br />
|Sets the spawn point to the given block coordinates.<br />
|-<br />
|<flag> [<chunkX> <chunkZ> [dim]]<br />
|<flag> may be protect-blocks, unprotect-blocks, prohibit-pvp, allow-pvp, default-pvp, no-mobs, spawn-mobs, no-animals, spawn-animals. Block protection prevents blocks from being dug, placed, or explodinated by non-ops, whereas prohibit-pvp and allow-pvp override the server's default pvp settings for that chunk. Explosions on the border of a protected chunk will not effect blocks inside it. Using unprotect-blocks and default-pvp will clear their respective effects. The mob/animal commands prevent or reinstate spawning for that creature type (though they can still wander into the chunk or spawn from mob spawners.)<br />
|-<br />
|clear-all <flag><br />
|Removes the flag from all chunks; <flag> may be protect-blocks, prohibit-pvp, allow-pvp, pvp, no-mobs, no-animals, flags<br />
|-<br />
|resize-ac [newsize]<br />
|Resizes the area cache (to the size in areaCache.properties if not specified). If shrinking, an area size higher than the number of players is recommended.<br />
|-<br />
|reset-ac [newsize]<br />
|Entirely cleans the area cache and resizes it (to the size in areaCache.properties if not specified). May fix lag if the server's acting up. Again, if shrinking, an area size higher than the number of players is recommended.<br />
|}<br />
<br />
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.<br />
<br />
===The Area Cache===<br />
"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. Also, [[User:Frizzil|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!<br />
<br />
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?<br />
<br />
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", and at extreme sizes results in general lag and high RAM consumption.<br />
<br />
Each tick, the ratio of cache queries that were misses is calculated and stored in "pctMiss." This number is extremely small (generally peaking in E-4), but is still significant given that a cache miss can be over 1000 times slower than a cache hit. The exponential average of this number is stored in "avgPctMiss." I.e. avgPctMiss is set to avgPctMiss * w + (1-w) * pctMiss each tick, where w is "avgPctMissPastWeight" This gives three important numbers for you to tweak-- avgPctMissThreshold and pctMissThreshold, which "grow" the cache when exceeded, and "avgPctMissPastWeight", which is "how significant are recent 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.) If your past weight is too low, your cache will be too sensitive to minor fluctuations and grow too frequently, eventually crashing your server from RAM consumption or massive lag. If your past weight is too high, your cache will be too resilient to fluctuations, resulting in "area thrashing" as 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.) Basically, fine tune these numbers to get the perfect amount of responsiveness to cache misses, only growing when necessary to support the increased needs of players.<br />
<br />
When the cache "grows", it takes a moment to copy it's data into a new, larger location in memory. "growthFactor" determines how much larger 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 resizing. Values closer to 1 may result in good matching of resources, but will result in excessive copying (and even slow response to needs), especially at larger cache sizes.<br />
<br />
For you fellow computer science geeks, this is 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) [http://en.wikipedia.org/wiki/Page_replacement_algorithm further reading]. The "growthFactor" tradeoffs are directly associated with that of a dynamic array's.<br />
<br />
<br />
{| border=1<br />
!|Property<br />
!|Default Value<br />
!|Description<br />
|-<br />
|startingCacheSize<br />
|16<br />
|The size to initialize the area cache at. Not bad to set it higher if you have a large server, to avoid the lag of resizing. Each player will need at least one area at any time, but players also frequently inhabit the same area, resulting in overlap.<br />
|-<br />
|verboseLogging<br />
|false<br />
|If set to true, will spit info out to the console whenever there's a "cache miss" or a cache resizing. Specifically, the number of misses, pctMisses, and avgPctMisses at that tick.<br />
|-<br />
|pctMissThreshold<br />
|1.0<br />
|Triggers a "grow" when exceeded by "pctMiss" (set to 100% by default, basically not used. Almost like an emergency "GROW MY DANG CACHE NOW" threshold, which may be ill-advised)<br />
|-<br />
|avgPctMissThreshold<br />
|1.0E-4<br />
|Triggers a "grow" when exceeded by "avgPctMiss"<br />
|-<br />
|growthFactor<br />
|2.0<br />
|The relative amount to increase the cache's resources by when a "grow" occurs.<br />
|-<br />
|avgPctMissPastWeight<br />
|0.96<br />
|The weight to give to the past "avgPctMiss" when calculating the exponential average. Should be between .85 and 1.0. Too low and your cache will grow too frequently, eventually crashing your server-- too high and your cache never grows in response to cache misses, causing lag of Biblical proportions and also potentially crashing your server.<br />
|-<br />
|}<br />
<br />
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)<br />
<br />
And most importantly, enjoy speeding up your server and improving its stability!</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/Server_FeaturesServer Features2012-05-25T22:04:26Z<p>69.246.180.210: /* New Server Commands */</p>
<hr />
<div>===New Server Commands===<br />
These commands are new to Hack/Mine as of version 0.6 (not officially released yet.) 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.<br />
<br />
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.<br />
<br />
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").<br />
<br />
{|border=1<br />
|+'''Player Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|spawn<br />
|Teleports the player to spawn<br />
|-<br />
|who [player]<br />
|Gives the name, class, race, and level of the specified player (or yourself if the player isn't specified).<br />
|-<br />
|flags [<chunkX> <chunkZ> [dim]]<br />
|Spits out all flags on the chunk (pvp enabling/disabling, block protection)<br />
|-<br />
|<nowiki>roll | rand | random</nowiki> [die size]<br />
|Spits out a random number in chat from 1 - <die size> (100 if none is given).<br />
|}<br />
<br />
<br />
<br />
{|border=1<br />
|+'''Console/Op Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|reward <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Gives some currency to the player. If "mobdrop" is specified, it gives them a typical amount of gold from a monster of the player's level, times <mult>. Otherwise, it gives the player <amount> of <cur>, where <cur> is p, g, s, c, platinum, plat, gold, silver, or copper.<br />
|-<br />
|penalize <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Removes currency from the player (will report amount actually removed if they have less).<br />
|-<br />
|setspawn <x> <z><br />
|Sets the spawn point to the given block coordinates.<br />
|-<br />
|<flag> [<chunkX> <chunkZ> [dim]]<br />
|<flag> may be protect-blocks, unprotect-blocks, prohibit-pvp, allow-pvp, default-pvp. Block protection prevents blocks from being dug, placed, or explodinated by non-ops, whereas prohibit-pvp and allow-pvp override the server's default pvp settings for that chunk. Using unprotect-blocks and default-pvp will clear their respective effects.<br />
|-<br />
|clear-all <flag><br />
|Removes the flag from all chunks; <flag> may be protect-blocks, prohibit-pvp, allow-pvp, pvp, flags<br />
|-<br />
|resize-ac [newsize]<br />
|Resizes the area cache (to the size in areaCache.properties if not specified). If shrinking, an area size higher than the number of players is recommended.<br />
|-<br />
|reset-ac [newsize]<br />
|Entirely cleans the area cache and resizes it (to the size in areaCache.properties if not specified). May fix lag if the server's acting up. Again, if shrinking, an area size higher than the number of players is recommended.<br />
|}<br />
<br />
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, and prohibit-pvp.<br />
<br />
===The Area Cache===<br />
"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. Also, [[User:Frizzil|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!<br />
<br />
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?<br />
<br />
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", and at extreme sizes results in general lag and high RAM consumption.<br />
<br />
Each tick, the ratio of cache queries that were misses is calculated and stored in "pctMiss." This number is extremely small (generally peaking in E-4), but is still significant given that a cache miss can be over 1000 times slower than a cache hit. The exponential average of this number is stored in "avgPctMiss." I.e. avgPctMiss is set to avgPctMiss * w + (1-w) * pctMiss each tick, where w is "avgPctMissPastWeight" This gives three important numbers for you to tweak-- avgPctMissThreshold and pctMissThreshold, which "grow" the cache when exceeded, and "avgPctMissPastWeight", which is "how significant are recent 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.) If your past weight is too low, your cache will be too sensitive to minor fluctuations and grow too frequently, eventually crashing your server from RAM consumption or massive lag. If your past weight is too high, your cache will be too resilient to fluctuations, resulting in "area thrashing" as 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.) Basically, fine tune these numbers to get the perfect amount of responsiveness to cache misses, only growing when necessary to support the increased needs of players.<br />
<br />
When the cache "grows", it takes a moment to copy it's data into a new, larger location in memory. "growthFactor" determines how much larger 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 resizing. Values closer to 1 may result in good matching of resources, but will result in excessive copying (and even slow response to needs), especially at larger cache sizes.<br />
<br />
For you fellow computer science geeks, this is 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) [http://en.wikipedia.org/wiki/Page_replacement_algorithm further reading]. The "growthFactor" tradeoffs are directly associated with that of a dynamic array's.<br />
<br />
<br />
{| border=1<br />
!|Property<br />
!|Default Value<br />
!|Description<br />
|-<br />
|startingCacheSize<br />
|16<br />
|The size to initialize the area cache at. Not bad to set it higher if you have a large server, to avoid the lag of resizing. Each player will need at least one area at any time, but players also frequently inhabit the same area, resulting in overlap.<br />
|-<br />
|verboseLogging<br />
|false<br />
|If set to true, will spit info out to the console whenever there's a "cache miss" or a cache resizing. Specifically, the number of misses, pctMisses, and avgPctMisses at that tick.<br />
|-<br />
|pctMissThreshold<br />
|1.0<br />
|Triggers a "grow" when exceeded by "pctMiss" (set to 100% by default, basically not used. Almost like an emergency "GROW MY DANG CACHE NOW" threshold, which may be ill-advised)<br />
|-<br />
|avgPctMissThreshold<br />
|1.0E-4<br />
|Triggers a "grow" when exceeded by "avgPctMiss"<br />
|-<br />
|growthFactor<br />
|2.0<br />
|The relative amount to increase the cache's resources by when a "grow" occurs.<br />
|-<br />
|avgPctMissPastWeight<br />
|0.96<br />
|The weight to give to the past "avgPctMiss" when calculating the exponential average. Should be between .85 and 1.0. Too low and your cache will grow too frequently, eventually crashing your server-- too high and your cache never grows in response to cache misses, causing lag of Biblical proportions and also potentially crashing your server.<br />
|-<br />
|}<br />
<br />
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)<br />
<br />
And most importantly, enjoy speeding up your server and improving its stability!</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/Server_FeaturesServer Features2012-05-25T22:03:58Z<p>69.246.180.210: /* New Server Commands */</p>
<hr />
<div>===New Server Commands===<br />
These commands are new to Hack/Mine as of version 0.6 (not officially released yet.) 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.<br />
<br />
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.<br />
<br />
Chunk coordinates may 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").<br />
<br />
{|border=1<br />
|+'''Player Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|spawn<br />
|Teleports the player to spawn<br />
|-<br />
|who [player]<br />
|Gives the name, class, race, and level of the specified player (or yourself if the player isn't specified).<br />
|-<br />
|flags [<chunkX> <chunkZ> [dim]]<br />
|Spits out all flags on the chunk (pvp enabling/disabling, block protection)<br />
|-<br />
|<nowiki>roll | rand | random</nowiki> [die size]<br />
|Spits out a random number in chat from 1 - <die size> (100 if none is given).<br />
|}<br />
<br />
<br />
<br />
{|border=1<br />
|+'''Console/Op Commands'''<br />
!width = 350|Command<br />
!|Description<br />
|-<br />
|reward <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Gives some currency to the player. If "mobdrop" is specified, it gives them a typical amount of gold from a monster of the player's level, times <mult>. Otherwise, it gives the player <amount> of <cur>, where <cur> is p, g, s, c, platinum, plat, gold, silver, or copper.<br />
|-<br />
|penalize <player> (<amount> <cur> <nowiki>|</nowiki> mobdrop <mult>)<br />
|Removes currency from the player (will report amount actually removed if they have less).<br />
|-<br />
|setspawn <x> <z><br />
|Sets the spawn point to the given block coordinates.<br />
|-<br />
|<flag> [<chunkX> <chunkZ> [dim]]<br />
|<flag> may be protect-blocks, unprotect-blocks, prohibit-pvp, allow-pvp, default-pvp. Block protection prevents blocks from being dug, placed, or explodinated by non-ops, whereas prohibit-pvp and allow-pvp override the server's default pvp settings for that chunk. Using unprotect-blocks and default-pvp will clear their respective effects.<br />
|-<br />
|clear-all <flag><br />
|Removes the flag from all chunks; <flag> may be protect-blocks, prohibit-pvp, allow-pvp, pvp, flags<br />
|-<br />
|resize-ac [newsize]<br />
|Resizes the area cache (to the size in areaCache.properties if not specified). If shrinking, an area size higher than the number of players is recommended.<br />
|-<br />
|reset-ac [newsize]<br />
|Entirely cleans the area cache and resizes it (to the size in areaCache.properties if not specified). May fix lag if the server's acting up. Again, if shrinking, an area size higher than the number of players is recommended.<br />
|}<br />
<br />
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, and prohibit-pvp.<br />
<br />
===The Area Cache===<br />
"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. Also, [[User:Frizzil|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!<br />
<br />
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?<br />
<br />
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", and at extreme sizes results in general lag and high RAM consumption.<br />
<br />
Each tick, the ratio of cache queries that were misses is calculated and stored in "pctMiss." This number is extremely small (generally peaking in E-4), but is still significant given that a cache miss can be over 1000 times slower than a cache hit. The exponential average of this number is stored in "avgPctMiss." I.e. avgPctMiss is set to avgPctMiss * w + (1-w) * pctMiss each tick, where w is "avgPctMissPastWeight" This gives three important numbers for you to tweak-- avgPctMissThreshold and pctMissThreshold, which "grow" the cache when exceeded, and "avgPctMissPastWeight", which is "how significant are recent 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.) If your past weight is too low, your cache will be too sensitive to minor fluctuations and grow too frequently, eventually crashing your server from RAM consumption or massive lag. If your past weight is too high, your cache will be too resilient to fluctuations, resulting in "area thrashing" as 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.) Basically, fine tune these numbers to get the perfect amount of responsiveness to cache misses, only growing when necessary to support the increased needs of players.<br />
<br />
When the cache "grows", it takes a moment to copy it's data into a new, larger location in memory. "growthFactor" determines how much larger 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 resizing. Values closer to 1 may result in good matching of resources, but will result in excessive copying (and even slow response to needs), especially at larger cache sizes.<br />
<br />
For you fellow computer science geeks, this is 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) [http://en.wikipedia.org/wiki/Page_replacement_algorithm further reading]. The "growthFactor" tradeoffs are directly associated with that of a dynamic array's.<br />
<br />
<br />
{| border=1<br />
!|Property<br />
!|Default Value<br />
!|Description<br />
|-<br />
|startingCacheSize<br />
|16<br />
|The size to initialize the area cache at. Not bad to set it higher if you have a large server, to avoid the lag of resizing. Each player will need at least one area at any time, but players also frequently inhabit the same area, resulting in overlap.<br />
|-<br />
|verboseLogging<br />
|false<br />
|If set to true, will spit info out to the console whenever there's a "cache miss" or a cache resizing. Specifically, the number of misses, pctMisses, and avgPctMisses at that tick.<br />
|-<br />
|pctMissThreshold<br />
|1.0<br />
|Triggers a "grow" when exceeded by "pctMiss" (set to 100% by default, basically not used. Almost like an emergency "GROW MY DANG CACHE NOW" threshold, which may be ill-advised)<br />
|-<br />
|avgPctMissThreshold<br />
|1.0E-4<br />
|Triggers a "grow" when exceeded by "avgPctMiss"<br />
|-<br />
|growthFactor<br />
|2.0<br />
|The relative amount to increase the cache's resources by when a "grow" occurs.<br />
|-<br />
|avgPctMissPastWeight<br />
|0.96<br />
|The weight to give to the past "avgPctMiss" when calculating the exponential average. Should be between .85 and 1.0. Too low and your cache will grow too frequently, eventually crashing your server-- too high and your cache never grows in response to cache misses, causing lag of Biblical proportions and also potentially crashing your server.<br />
|-<br />
|}<br />
<br />
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)<br />
<br />
And most importantly, enjoy speeding up your server and improving its stability!</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/ElfElf2012-05-18T14:47:10Z<p>69.246.180.210: </p>
<hr />
<div>Elves are the most varied and adaptive of all races, so summarizing them is a tad difficult. Some elves are wildsmen, living solitarily in the forests for their entire lives. Others have never spent a day outside of the city, burying themselves in their studies and practicing politics amongst the other nobles. Others still are nomads, existing in small, tight-knit communities in search of natural resources.<br />
<br />
Elves have known of Minecraftia for eons, but have only recently ventured into it after learning the Dwarves discovered valuable resources there. The Dwarven and Elven nobilities have long been at odds with one another, and live in constant fear of the other race gaining a military advantage.<br />
<br />
When Elf is selected your character looks slightly taller and stretched.<br />
<br />
<br />
{| border="1" cellpadding="5" cellspacing="1" class="article-table"<br />
|+'''Elf Starter Stats'''<br />
|Strength<br />
|8<br />
|-<br />
|Agility<br />
|Unused<br />
|-<br />
|Dexterity<br />
|11<br />
|-<br />
|Intelligence<br />
|10<br />
|-<br />
|Wisdom<br />
|12<br />
|-<br />
|Fortitude<br />
|9<br />
|}<br />
[[File:Elf.png|thumb|A picture showing the elf compared to a three block high column. The elf appears stretched and APPEARS much taller than the dwarf]]<br />
<br />
[[Category:Races]]</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/HalflingHalfling2012-05-18T14:45:26Z<p>69.246.180.210: </p>
<hr />
<div>Halflings are a tricksy race, both nimble and cunning. They are great thinkers and risk takers, always able to realize a profit where others could not. Despite their timid appearance, they are scorned universally, the Great War many hunderds of years ago having been waged in the name of a Halfling. Consequently, they've become disturbingly thick-skinned little buggers, continuing to inhabit cities everywhere, pickin' pockets, openin' shop, and laughing in the face of extreme adversity as the opportunity presents itself.<br />
<br />
Halflings are notably the smallest of all races, at a stature of only 1.3 blocks.<br />
<br />
<br />
{| border="1" cellpadding="5" cellspacing="1" class="article-table article-table-selected"<br />
|+'''Halfling Starter Stats'''<br />
|Strength<br />
|9<br />
|-<br />
|Agility<br />
|Unused<br />
|-<br />
|Dexterity<br />
|11<br />
|-<br />
|Intelligence<br />
|12<br />
|-<br />
|Wisdom<br />
|10<br />
|-<br />
|Fortitude<br />
|8<br />
|}<br />
<br />
<br />
==Traits==<br />
<br />
[[File:2012-04-26_18.30.16.png|thumb|A halfling mage. If you look closely you can see the item glitch.]]<br />
*Halfings are initially the best [[mage]] class because of their starting stats.<br />
*The hit box for arrows and magic from wands also seems to be affected by their height.<br />
<br />
==Notes==<br />
<br />
The items do not fit in the players hand. Said item can float above or below the characters actual hand. This effect is unseen in First Person.<br />
<br />
They can't fit through one block high holes because they're just slightly taller (1.4 blocks)<br />
<br />
[[Category:Races]]</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/SteveSteve2012-05-18T14:44:15Z<p>69.246.180.210: </p>
<hr />
<div>[[File:Steve.png|thumb|Comparison between the Steve and a 3 Block high pole. The Steve is just under 2 blocks, while the elf is exactly two blocks, the dwarf is shorter than the steve, and the halfling is 1.3 blocks]]The Steves are a proud, nomadic race, having been the first to settle the dangerous lands of Minecraftia thousands of years ago. Steves are among the most socially advanced races, and as such are the most prevalent race existing in communities. They are an amicable bunch, capable of great acts of kindness, yet easily manipulated for the benefit of others.<br />
<br />
<br />
{| border="1" cellpadding="5" cellspacing="1" class="article-table article-table-selected"<br />
|+'''Steve Starter Stats'''<br />
|Strength<br />
|11<br />
|-<br />
|Agility<br />
|Unused<br />
|-<br />
|Dexterity<br />
|10<br />
|-<br />
|Intelligence<br />
|9<br />
|-<br />
|Wisdom<br />
|9<br />
|-<br />
|Fortitude<br />
|11<br />
|}<br />
<br />
[[Category:Races]]</div>69.246.180.210http://www.hackslashmine.net/hsmwiki/DwarfDwarf2012-05-18T14:43:00Z<p>69.246.180.210: </p>
<hr />
<div>Dwarves were the first intelligent race to come into existence. As such, they are not very intelligent. However they are a proud, hard-working, and stoutly bunch, always liable to get the job done. The surface dwelling dwarfes have disconnected from their earth abiding ancestors long ago. Of course, they are always very good storytellers, I swear! After a little grog, even the snootiest dwarf is liable to talk a stranger's ears off.<br />
==Traits==<br />
*Dwarves are one of the best races to start on for a warrior because of their starting stats.<br />
*Dwarves are slightly shorter than the standard [[Steve]] , but taller than [[Halfling]]s .<br />
*Dwarves are the best race for starting a warrior who you want to specialize into a sort of Beserker. Steves, however, are better for warriors who want to be more balanced in stats because of their starter statistics.<br />
<br />
<br />
{| border="1" cellpadding="5" cellspacing="1" class="article-table"<br />
|+'''Dwarf Starter Stats'''<br />
|Strength<br />
|12<br />
|-<br />
|Agility<br />
|Unused<br />
|-<br />
|Dexterity<br />
|9<br />
|-<br />
|Intelligence<br />
|8<br />
|-<br />
|Wisdom<br />
|11<br />
|-<br />
|Fortitude<br />
|10<br />
|}<br />
[[File:Dwarf_-_Tree.png|thumb|Comparison between a dwarf and a tree. The trunk is 3 blocks at the top of the picture. Note how the dwarf is slightly shorter than the second tree block]]<br />
<br />
[[Category:Races]]</div>69.246.180.210