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.
