This alters the behaviour of the ``getInventoryHolderLocation`` and ``getInventoryHolderType`` methods in a way which should have identical behaviour for double chests but which should also not raise an exception if there are triple (or larger) chests. The type will be correct; the location will at least return *something* which is the location of one of the chests involved, but it'll probably be semi-arbitrary what coordinates are returned.
Fixes#563 - note issue #533 which this does **not** address
- Update PR to use Actor system
- Amend actorFromProjectileSource to choose a friendly name when a block is the source of a projectile
- Added util method to try to suggest an appropriate item as the "weapon" in a projectile kill
Closes#442Fixes#470Fixes#471
This increases insert speed by up to 6 times when the DB server is on the same
box as the minecraft server, and many HUNDREDS of times when it is accessed via
a network connection.
This creates a new kind of BlockRow which is a collection of many similar rows, each
of which uses the same PreparedStatement. As such, when asked to run, it can
use the executeBatch() method. It also adds code to BlockRow to see if they are mergeable
(it won't if they have sign or chest actions associated) and to merge two rows into one of
these new objects. The consumer processing loop is altered to check for merges, and do so if
possible.
Also, prevent consumer race condition on shutdown
On shutdown, LogBlock invokes the consumer's run() method up to twn times on
the main thread. However, the consumer may still be running from the last
scheduled task, and this could result in two threads running the run() code
simultaneously, resulting in inconsistent row insertion order.
Another scenario is that the consumer has just started processing the last
row in the queue. With the queue empty, the server will terminate, but the
consumer could still not have fully executed the databse query.
To solve this, the run() method is syncronized, so it can only be run on the
object by one thread at a time, and is made to run at least once (to force LB
to wait on any already processing run)
Also, the pause between consumer runs was altered to be in ticks (50ms) rather than
in seconds, to prevent needless pauses between runs.
Fixes#580Fixes#56
Currently will search only using block type ie searching for prismarine_brick
will search for all prismarine blocks
Also removed pluralisation of prismarine_brick
- Print warning if the pre-existing file doesn't contain one of the new names
- Make name lookup in plugin startup to force the MaterialName static code to be run
What MySQL calls "UTF8" is actually a subset of the full unicode specification.
It doesn't accept 4-byte UTF-8 characters. Proper support is called "utf8mb4"
and is, these days, fairly common (Ubuntu 10.04LTS's bundled MySQL does not
support it, but later ones do)
Detection of utf8mb4: "SHOW CHARACTER SET WHERE charset='utf8mb4';" returns at
least one row
Conversion of pre-existing DBs: this was easy, we already had code in the
updater for this for when we started enforcing utf8. It was version-bumped and
set to update to either utf8mb4 or utf8, depending
Making it use utf8mb4 in the database connection: Actually hard. Connector/J
5.1.13 or newer should autodetect this, but in my testing it didn't
(http://dev.mysql.com/doc/relnotes/connector-j/en/news-5-1-13.html)
As such, if utf8mb4 has been detected, I've added code that should manually
execute "SET NAMES utf8mb4;" on all new connections.
If a database does not support utf8mb4 (rare these days) I've added code to
strip these characters before DB insertion; they won't be recorded correctly,
but it'll avoid the exception from issue #535
Firstly, remove incorrect unique index on playername (and UUID, just in case) columns, and add a non-unique index on the UUID column
Secondly, account for setups not logging onlinetime - in that case, try to look up ALL names, and give any not found the log_ prefix rather than the noimport_ prefix
This creates a new column in the lb-players table called UUID. If this is in the form of a UUID,
it's assumed to be a player. If not, it's assumed to be a server entity (zombie, sheep, or
WaterFlow, LavaFlow etc.). LogBlock will set the UUID of entities to "log_" plus their name
(i.e. log_zombie or log_sheep)
To assist this is a new class Actor, which wraps a name/UUID pair, with constructors that will
generate one from server entities, or SQL results. Every listener and every class in Consumer
needed to be updated to deal with this
As of yet, only the playername is displayed in results (although the queries do return UUID data).
Similarly, you can only query by name (the database stores the last name they have logged in as).
In addition, the WorldEdit hook has been disabled (is not compiled) since LB needs to be updated
to use their new API, and the LB code hook has to extract UUID information for insertion.
The UUID importer assumes any player with an onlinetime of 0 is a server-generated source, and set
the UUID as above (log_sheep etc.). For everything else, it sends 100 names at a time to Mojang's
name->UUID service, and records them if available. If no result is found, it records their UUID as
noimport_theirname. As this is more likely than other updates to be interrupted mid-way, the
importer is tolerant of e.g. the column already being added, and will resume where it left off.
Philip Cass
Ammar Askar
Ammar Askar
Thundaklap
Mahagon
Philip Cass
Dark Arc