(+) 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).
* Lift-off side conditions.
* Force stop gliding for some side conditions, to avoid freezing.
* Set maxheight to 128 for elytra and levitation too (mods/plugins/etc)
- better refine checks to catch stuff.
* Fix special flags not getting set with initializing ModelFlying from
config.
* Debug log exceeding the maxheight setting.
* Mostly harmless: Add interfaces and access methods, including
convenience methods.
* Don't store methods in Bridge1_9.
Issues left, not limited to:
* Boost not recognized on occasion.
* Gliding state kept when submerged in water and moving normally like
when not gliding, e.g. ascending (head in water / fully submerged).
* Elytra lift off not accepted: Gliding state set near the water
surface, but survivalfly check runs. Might be fixed already, though.
Breaks what used ModelFlying in any other way than setting up by config.
Use setters with chaining and a lock() method to lock against changes,
provide copy-constructor.
This is incomplete, as some pre-checks are still done with the full
bounds (flying just under web will put you to sf). Efficiency-wise there
could also be a more light-weight adjustment.
Attack areas are left too, e.g. flying (with or without boost) to
underwater, then end gliding to effectively clip with the head into
/through the block above.
With the lowered height it's also possible to get into odd spots, so
after stopping to glide you'll not be able to get out anymore.
This will not check all possibilities, if default=YXZ fails:
* X or Z collision: test YZX as alternative.
* Y collision: test XZY then ZXY as alternatives.
Would need to check client code, possible of multiple client versions,
considering widespread use of protocol support plugins.
New
* Define a couple of default lists for axis order.
* Allow setting axis order via a list.
Removed
* Configuration option to disable ray-tracing.
* Configuration option 'blockchangeonly' - there may be an equivalent
later on, where checking accounts for the entire bounding box(es).
* Legacy code option (things have stabilized and axis order switching
should fix false positives).
Random
* Accidentally commit FastConsume (whitespace).
Currently typically blockbreak.direction will fail, if blockinteract
used a (the first) flying packet.
Other oddities: Block damage followed a cancelled interact event.
* Issues remain with "moved too quickly" interfering (TP loop with
waterfall/alternating, possible to escape).
* Not sure the previous modeling makes sense at all with allowing
friction now.
This probably is too much of a special case (place without interact?),
might rather hit plugin features. Apart from that, consequently, other
checks should test for this too?
[BLEEDING] just to note blockinteract changes may alter things.
Currently it looks like only blockplace.against is using the last move
of BlockInteractData - later other checks are intended to use that too,
in terms of a data source.
* Store complete event result state for interact.
* Store consumed checks as well.
* Still run the speed check, if only using the item in hand is allowed.
* Add a class to loop the flying queue with a block as target (look
only).
* Pass the flyingHandle to sub checks (doesn't necessarily make sense
with reach - should probably re-check reach with the used flying queue
state, but that's more complicated due to the possibility of split pos
vs. look).
* Use the loop class both for visible and direction (not reach).
Likely similar has to be done with BlockPlace and BlockBreak - would be
good to find a skipping heuristic for blockbreak.direction etc., so we
know we have successfully checked that block from that exact position
for this player and nothing has happened between (and so on, or a more
relaxed heuristic).
skipping redundant checking (limiting the number of visited packets
doesn't work - instead 'good candidated' for packet inversion with dig
packets should be stored together, so it's easy to just check vs. the
first/last stored one).
To be done:
* Use yaw and pitch of past packjets for Direction and Reach.
* If block break mathes the last interacted block (+ moving sequence
indicates no change), skip some checks like direction and reach there,
possibly keep track if those were run at all.
If the teleport confirm packet is available, flying packets with
AckResolution.WAITING will be cancelled.
This is real bleeding edge and might need other adjustments not to
freeze players for to be discovered edge cases. The TeleportQueue
already does contain a timeout mechanism and should return
AckResolution.IDLE after some time.
* Count all events/packets regardless of settings.
* MovingListener: Remove pos/look counting for move events.
* MovingFlying: Call the counter method according to primaryThread flag.
This way, you can calculate a more interesting set-back location from
within a hook during violation handling. All you need to do to adjust
the set-back location is to call MovingData.setTeleported(newSetBack)
and NoCheatPlus should recognize this as the location to set back to.
Please do:
* Test if the check in question would set back at all
(IViolationData.wilCancel() returns true).
Please in such a case do not:
* Don't call setTeleported if IViolationData.willCancel() returns false
:).
* Cancel violation processing.
* Teleport the player.
* Do something complicated with MovingData otherwise :).
Store an extra array of items internally and allow fast fetching (for
fastest processing, where necessary). The sortedItemNodes array is kept
for future purpose.
Despite having an interface yet, add things like unregister many objects
(items) and getting all registered items, e.g. for dealing with
sub-registries efficiently (at first code-wise).
Store items in lists by type, sort by RegistrationOrder either lazily on
fetch or upon request. Allow registering an item multiple times, but
only once per type.
Tests, adaption of signatures, additions and variants should follow.
* Add RegistrationOrder for order.
* Add sorting functionality with some tests. (See
RegistrationOrder.AbstractRegisTrationOrderSort.)
* (Except for test cases, all this is not yet in use.)
(Perhaps the sorting should be changed to use an array for output
instead of iterators, this just represents a quick way in.)
Further direction:
* Replace all the registry lists like for INotifyReload and
IDisableListener and so on within registries by a generic storage that
uses this for sorting. This way every such thing will support both
priority-based and tag-based order at the same time.
* To support different order definitions depending on what type an
interface like IRegisterWithOrder might be supported by a registry.
* Later generic event listeners might also use this, simply.
* Reduce details and only send a configurable amount of lines in
notify/chat, default to 5, just state to check logs in the end,
instead of lengthy hints.
* Log detailed output to STATUS (file/s).
* Fix wrong build number printed to set configversion.created to.
* lostGroundAscend: new condition.
* lostGroundStill: some precondition checks moved inside, new condition.
* vdistrel: Extra case with decreased lift-off gain, but second move as
if normal lift off.
* With from being on ground, and last move not having touched ground,
setSetBack(from).
* The construction routine for ActionListS is to by passed the silent
permission already, so getting optimized copies will not add another
'.silent' to the already passed permission. (Correct me if i am
mistaken).
* Clarified javadocs/names.
* Further null permissions are handled, even if not (yet) necessary.
Still to be called with the ordinary check bypass permission:
* ConfigFileWithActions: The convenience methods to obtain
(Optimized)ActionListS from the
configuration.
* AbstractActionFactory.createNewActionList: will then create actual
lists, extending the permission by '.silent', unless the permission is
null.
(Stumbled onto, while looking for optimization potential with log action
execution.)
[BREAKING]
* Due to adding a method to CheckDataFactory.
* Might alter data removal (less is removed, might've overlooked
something).
For MOVING, FIGHT, COMBINED, data removal for sub checks now is
possible, allowing for more precise resetting via commands. Other check
groups may follow on request / randomly.
Data removal for check data is logged now (only CheckData, not
IRemoveData in general), in case the debug flag is set in the data.
Later, a more flexible method may get implemented, accepting a String
id, so not only check type related data, but also any type of special
data can be removed (e.g. moving.locationtrace would not be a check
type, but allow resetting the location trace of a player).
No bypass permission is set. The yawrate part depends on multiple other
checks. Checking for exemption is a hack within feedYawRate, fastest way
to implement.
HashMapLOW
* Add a constructor for using an external lock.
* Add putIfAbsent.
DataManager
* Use playerDataMap.putIfAbsent, return the PlayerData instance that has
been there first.
The per-config-path notifications would keep showing up, even if you
removed the paths, then run 'ncp reload', then alter any of them and run
'ncp reload'.
To fix this, the configversion.created value is set to the current
build, if no config warnings are there - which is the same, as what the
notification suggests as an alternative to removing the paths and
running 'ncp reload'.
To do this, isConfigUpToDate had to be moved from Updates to
ConfigManager, which makes more sense anyway. In addition the 'created'
and saved 'values' are set to the biggest thing found, instead of the
prehistoric static value.
Further a negative 'created' value will not be overridden anymore,
allowing to silence the config notifications forever. Not necessarily
recommended for the general case, but it can be useful/necessary with
maintained blueprints, e.g. with administering multiple servers.
One of the next steps will be to remove the DefaultConfig.buildNumber in
favor of setting a build number for each and every path added. All
provided we don't run into nasty issues here.
Another follow up could be to create an extra registry/config log file
and write all the values there, and only print the first 5 in ingame
chat.
A NO_RISK flag has been added, to allow skipping workarounds such as
packet level ack for skipping a set-back teleport. This remains
so-and-so, because in this case the set-back still would stay 'to be
done' and moves setting off from elsewhere would get cancelled, leading
to re-scheduling it, still:
* There could remain potential with micro moves, intentionally getting
set back.
* There remains an uncertainty with the telported logic initially not
having been made for a set-back location getting kept 'to be done' over
multiple server side ticks potentially.
* Having the ability to turn off this rare (?) case, allows faster
reaction, if issues should arise.
The default settings can be referenced by their ids:
* default.legacy for pre-1.9.
* default.cautious for not taking risks (such as packet level workaround
disabled, otherwise it's currently post-1.9 handling, working but not
optimal on pre-1.9).
* default.modern for the latest thing (currently post-1.9).
The defaults have been adjusted, according to so far experience:
* default.cautious contains flags SCHEDULE and NO_RISK now.
* default.modern is the default now, and contains SCHEDULE (but not
NO_RISK). This is used if nothing is specified in the configuration.
Where it's known that it's the primary thread, that test should be
omitted.
A remaining problem is the Check class, where the convenience methods
all will lead to testing for Bukkit.isPrimaryThread(). This needs to be
done differently.
It'll be hard/impossible to work around, if we have to check permissions
and meta data. For permissions we could do some kind of bulk/context
dependent caching and updating policy and check via PlayerData, but meta
data needs the Bukkit API to state thread safety. Future design could
also do without knowledge of the thread, if permissions are cached and
exemption by meta data is turned off (or also cached, but this only
works if other plugins don't use it for temporary exemption), a lazy
approach could pass on an AlmostBoolean isPrimaryThread.
For now, at least some of the frequently run moving checks use the
optimized approach.
* HashMapLOW for thread-safe access to PlayerData instances.
* PlayerData removal now used the UUID. More changes pending for storing
the UUID for reference rather.
* Use bulk removal for expiration of entries (one time lock).
Can't do much better than being there already. Thinkable trouble could
be with high latency and multiple teleports to different locations in
quick succession, so that cancelling the teleport will lead to the
player violating survivalfly again in the future, which means longer
freezing/rubberbanding than if we teleport now. However, current
assumption is, that it's better not to keep teleporting players around.
Instead of maps for each individual purpose, and the rather expensive
TickListener adding and removing, player specific task will be done via
one PlayerTickListener that can be registered with the TickTask. Thus
PlayerData has the access methods requestUpdateInventory and
requestPlayerSetBack, and so on, later more. For the
DataManager.playerData map it'll be UUID first now.
Consequently some calls have been altered to prefer passing Player or
UUID for PlayerData getting.
Breaks: DataManager.getPlayerData(String, boolean) has been removed, new
methods added to do the same without boolean or with UUID passed extra.
Following changes may repeatedly/randomly break PlayerData and check
data access (unless you use CheckType.getDataFactory), this may not
follow directly, but more or less soon. Even Later, CheckType will get
broken too :), in favor of class instances with dynamic registration
ability.
Basic direction is to concentrate stuff in PlayerData, getting rid of
all the static data stores, but also making access to shared data
more efficient (e.g. store last world id + name and permission cache in
PlayerData). Access will be more thread safe (only for PlayerData,
permissions cache, likely for fetching check data too, however returned
objects may have their own contracts).
* The player is at the coordinates.
* The last received ACK for an outgoing teleport has been received on
packet level. This is experimental, to be confirmed to a) do something
b) not allow abuse.
