Yes
* Remove the UNKNOWN type.
* All types except ALL have a parent now.
* All types have a type now.
* APIUtils: Add getDirectChildren for distinction.
No
* APIUtils doesn't collect the descendants in a generic way yet.
(+) Note: If it's fired asynchronously, meta data isn't checked, due to
that not being thread-safe. In future extra checks for (demanded to be)
thread-safe external plugin APIs can be added (reflection only).
(+) Add comments to PlayerData, concerning future treatment of name-uuid
mappings and retaining data.
Only applying with GROUND_HEIGHT set, these flags allow setting a
minimum height for passability and ground workarounds, covering two
typical cases.
Due to a range of hard coded workarounds being in place already, these
flags won't apply for all blocks. See getGroundMinHeight.
* Start renaming methods internally (getType for getting Material) -
unfinished.
* Temporary fix for the NCPCompatbukkit/cbreflect module: fetch NMS
blocks by id until we have a mapping and/or something efficient and
future proof in place.
Placing boats on ground is possible at least down to CraftBukkit
1.4.5-R1.0, thus the reason for having the boatsanywhere feature solely
is to prevent abuse. Thus allowing to place boats on ground does not
really provide a 'fix'. In order to allow placing boats anywhere, the
configuration flag has to be altered.
It may be worth a discussion, if we want checks to prevent Minecraft
features at all. A proper fix for abuse would be more complicated,
involving checking the estimated bounding box of the placed boat not to
collide with blocks neither with entities while being on ground-.
Determining the bounding box and re-checking with entity spawn might be
the more complicated part, as for the rest API/Infrastructure exists.
Allowing it with protocol support plugins is added, assuming that
they'll allow 1.12 too.
Missing:
* The vehicle.envelope check must be made (more) precise, as moving on
ground is possible with a boat since 1.12, specifically on ice they can
reach high speeds. Without more close modeling, they'll be able to use
this for speeding.
* Allow specifying to remove color definitions (both Minecraft default
and with '&') and to replace color definitions that use '&'. Append
?color or ?nocolor after the level definition. (Shortcuts: c, col / nc,
noc, nocol, nocolor). Either of both can be set, not both.
* Log to multiple streams with individual levels and color flags by
separating stream definitions with '+'.
Any registered stream id can be used (default streams are defined in
fr.neatmonster.nocheatplus.logging.Streams, in theory other plugins
might register their own ones).
Shortcuts are:
* ncp log stream notify message... (ingame notification, info level)
* ncp log stream debug message... (trace file, fine level)
* ncp log stream status message... (file + console, info level)
* ncp log stream init message... (file + console, info level)
Shortcuts do support setting the level, e.g. status@severe.
Due to string parsing these are not as efficient as hooking into the API
would be, naturally.
To model differing behavior of fluids, i.e. half fall distance per
in-lava move vs. zero fall distance once in water, block flags will be
used. To really do this the NoFall check will be altered to account for
new flags. Once at it, the check should also treat from and to
independently of each other - there are some inconsistencies, such as
how oFallMaxY is set.
Further flags are reserved for MIN_HEIGHT..., indicating that
compatibility will be improved without compromising protection too much.
Thus instead of making a block entirely passable, you could set a
specific min height flag alongside ground_height (and possibly height
for max. height), in order to allow walking between level x and y but
not below (think of grass_path).
