Adding or removing operators was mistakenly using a loose player lookup
method, which would cause a permission refreshes on an online player whos
name starts with the name of the (offline) opped player.
Add/Remove op operations are exact name match only and the permission
refresh will behave the same way.
Both log4j and our own jline/jansi initialization attempt to catch
errors caused by jansi's use of native libraries. However both of them use
the Exception type which does not catch all errors. On Windows Server 2008
R2 Enterprise without installing extra software the required C++ libraries
are not available which causes an error that does not extend Exception. To
ensure we catch all errors I've changed both of these to catch Throwable
instead which gets us a working console minus jansi functionality.
l previously was the block id, however Minecraft's refactoring means that
the method is now passed a Block reference rather than the id. l is now
the data value of the block, so the block retrieved with that value is not
the correct block to be testing.
Something the log4j ConsoleAppender does makes the console work correctly
on Windows. After trying to pull pieces of it out and run them manually
I decided to just put the appender back. We now once again start with the
ConsoleAppender then remove it immediately after starting.
WorldMapCollection stores scoreboard, map (item), structure, and
village information. Scoreboards are explicitly handled globally,
while villages and structures are erroneously shared.
This commit separates the WorldMapCollections to not be shared among
custom worlds. Maps are special-cased to maintain the previous shared
behavior.
This change will print a warning when a plugin induces a forced save. A
player or console forcing a save (via a command) is ignored for purposes
of printing a warning.
When Minecraft first introduced an auto-save feature, we
were taken by surprise by how much of an impact it actually had on the performance
of the server. After investigating the potential causes of the significant
slow-downs we saw at the time, we came to the conclusion that it was a
combination of the auto-save interval being incredibly frequent and
servers already having an auto-save solution that was conflicting with the
newly added built-in one.
Since we noticed that most servers already had their own auto-save
solution, we decided to completely disable the built in auto-save by
default. In hindsight, however, we were so happy that we discovered and
squashed the cause of the performance issues that we forgot to consider
the future and, as a result, some servers have unfortunately been caught
by surprise when they ran their servers without any auto-save plugins.
Without the auto-save plugin conflict, however, Minecraft's default save
interval of 45 seconds is not suitable for the types of servers that run
Bukkit, to the point where it was negatively impacting performance. As
such, we've decided to re-enable the built in auto-save at an interval of
5 minutes for newly created servers.
The WorldMapCollection object for SecondaryWorldServers(Nether, End) is
shared with the main world, so saving it again for each SecondaryWorldServer
is redundant.
This commit removes the redundant call by checking if the WorldServer is an
instanceof SecondaryWorldServer before invoking worldMaps.a().
This change removes a redundant addition of source encoding and makes our
compiler match the current maven default. This amends the commit
4775b25a5932a2a24da2c55356936e2f98bff98c
Upstream issue http://jira.codehaus.org/browse/MCOMPILER-70
The recent Minecraft update rendered the
e20e50f85083dc53cb5456254bcf5781ef750daa fix incorrect by adding a
compound name to the base tag in some code. This fix changes all uses
of tag changes to explicitly use a name.
When a "uid.dat" file is corrupt (empty or <16 bytes), WorldNBTStorage
will silently fail to read and return null. Non-null behavior is
expected everywhere that this value is used.
This change will force a random UUID when the previous UUID cannot be
read, and getUUID to no longer silently ignore read/write exceptions.
This change adds the location and a more specific message to the
IllegalArgumentException that gets thrown when a hanging entity is being
spawned in a location that it cannot survive.
Opening a hopper inventory created by Server.createInventory will
currently have no effect as proper handling code is missing in
CraftEntityHuman for hopper inventories that aren't associated with a tile
entity or minecart. Initialization logic for hoppers is also missing from
CraftContainer, which is necessary for the opening of custom hopper
inventories.
This commit fixes the two aforementioned by adding proper handling to
CraftHumanEntity for opening inventories not associated with a tile
entity, and by adding initialization logic for hoppers to CraftContainer.
Previously fires spawned by lightning strikes were in the wrong locations.
This introduced the possibility of having blocks replaced when they should
not be.
EntityLightning now uses the correct locations as defined to spawn the
fires when needed.
When an entity is being moved as the passenger of an entity from one
entity to another, a VehicleExitEvent is fired, but it is assumed that the
current entity is a Vehicle. However, entities can be passengers of more than
just Vehicles, which causes a ClassCastException to be thrown.
This commit fixes the issue by checking that the current entity's vehicle's
bukkitEntity is an instance of Vehicle before casting it to Vehicle.
This change adds the source encoding to the maven compiler plugin, which
will strictly enforce build consistency on multiple platforms and address
possible compilation issues on some of the source files. The source
encoding unintuitively is system-specified by default.
Prior to this change when a plugin called Player.hasLineOfSite() the
method would always return false because EntityHuman does not extend
EntityInsentient. This commit changes that by explicitly checking for
line of sight between two entities and returning that value.
