* PlayerMoveEvent performance boost (from 0.047ms to 0.015ms in testing, ~313% as fast): now more thrifty in determining whether player has actually moved between chunks before doing anything else; important since this event triggers extremely quickly
* PlayerInteractEvent performance boost (from 0.068ms to 0.034ms in testing, ~200% as fast): now ignores left-clicks for interaction checks, since in CraftBukkit 1.4 left-clicks no longer open doors or activate buttons/levers/etc.; not as important as above, but still triggers quite often as people are digging or interacting with blocks
* "/f list" command performance boost (from 234ms to 30ms in testing, ~780% as fast): code was getting information for all factions, narrowed it down to only getting info for displayed page range
* "/f show" command performance boost (from 132ms to 28ms in testing, ~470% as fast): tweaked the ally & enemy listing code used
if the offline player had similar name with the online player
ie. online "s2", offline "s", then "s" would show as online because
getPlayer("s") will return getPlayer("s2")
this is why getPlayerExact should be used
Some further info display to go with this feature is yet to come, and further testing for possible bugs is also needed.
Related info:
New FPerm "ACCESS" which is granted to faction leaders and officers by default. This FPerm allows you to bypass access restrictions throughout your faction territory, and (along with the "factions.access" Bukkit permission below) allows you to change access settings for any chunk owned by your faction.
New permissions:
factions.access - Ability to grant territory access for your faction, if you have the proper "ACCESS" FPerm (defaults to leaders and officers only). Added to factions.kit.halfplayer permission kit.
factions.access.any - Ability to grant territory access for any faction on the server. Added to factions.kit.mod permission kit.
factions.access.view - Ability to view territory access info for your own faction. Added to factions.kit.halfplayer permission kit.
New command:
/f access [view|p|f|player|faction=view] [name=you] - view or change the access information for the chunk you are in. If "view" or nothing is specified, it will simply display the info. If "p" or "player" is specified, a player will be granted access, or removed from the list if they were already granted access. If "f" or "faction" is specified, the same will be done for the specified faction. The name defaults to yourself or your faction if not specified. If your own faction is specified, you will toggle restricted access for the chunk so that normal faction members can be denied access, unless they are in the access list.
Examples:
/f access - view access list, if in your own territory
/f access p SomePlayer - grant access to player "SomePlayer" for the current chunk, or remove them from the access list if already there
/f access f - toggle restricted access for the current chunk (since faction name isn't specified, uses your own faction), assuming you're in your own factions territory
TNT in water/lava doesn't normally destroy any surrounding blocks, which is usually desired behavior. That's the reason this setting is disabled by default. However, it is available because it provides a method to get through waterwalls with enough persistence, and it makes cheap (non-obsidian) TNT cannons require minor maintenance between shots. Both are useful things for my server.
1. Obsidian generator exploit, which converts redstone wire to obsidian. New setting "handleExploitObsidianGenerators" (enabled by default) to determine whether it's prevented or not. Some servers might want to disable this prevention, to keep it as a viable obsidian creation method. Thanks to ObGenBlocker and WorldGuard plugins for the prevention method.
2. Ender pearl exploit, which could be used to clip through doors, glass, and probably a few other things if just the right spot was targeted. New setting "handleExploitEnderPearlClipping" (enabled by default) to determine whether it's prevented or not.
Also removed our TNT exploit prevention code, since they did get it fully fixed in 1.1-R4 and it doesn't look to be coming back from the dead again like it did when they released 1.1-R2.
