Upstream
/
NoCheatPlus
mirror of https://github.com/NoCheatPlus/NoCheatPlus.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
NoCheatPlus/NCPCore/src/main/java/fr/neatmonster/nocheatplus/checks/blockbreak/FastBreak.java

162 lines
7.6 KiB
Java
Raw Normal View History

Ready for UEFA EC: GPLv3 headers. Might need more training still.
2016-06-02 20:14:09 +02:00
/*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
package fr.neatmonster.nocheatplus.checks.blockbreak;
Reduce use of using block-ids in more places. * Use Material directly in more places. * Hide id-getting within BlockProperties. TODO: * BlockInit, BlockFlags + use of those. * Possibly other.
2014-06-13 11:27:42 +02:00
import org.bukkit.Material;
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
import org.bukkit.block.Block;
import org.bukkit.entity.Player;
Bleeding: Sharpen NoFall. New attempts to reduce fall damage by stopping in mid air and letting MC deal fall damage (send ground), then regenerate health and/or fall the last 3 blocks without damage are prevented by this (mostly). Hopefully few to none false positives.
2012-12-04 04:41:50 +01:00
import org.bukkit.inventory.ItemStack;
More haste.
2013-02-05 11:02:47 +01:00
import org.bukkit.potion.PotionEffectType;
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
Add block id to fastbreak message.
2012-09-30 02:04:43 +02:00
import fr.neatmonster.nocheatplus.actions.ParameterName;
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
import fr.neatmonster.nocheatplus.checks.Check;
[Development] An other day of work, wow so much changes: some issues fixed (some others left), new API introduced, new way of declaring checks, etc.
2012-08-08 01:24:31 +02:00
import fr.neatmonster.nocheatplus.checks.CheckType;
Add block id to fastbreak message.
2012-09-30 02:04:43 +02:00
import fr.neatmonster.nocheatplus.checks.ViolationData;
Ra-add the instant-break compatibility code. For whatever reason it was commented out, it is now put back, assuming that the reason was "it did not help with mcMMO", because mcMMO used to fire extra BlockBreakEventS. Now we use a tri-state and set it to MAYBE if instantBreak is set already on lowest priority, to have a rough indicator if a plugin set it, or if the server might have done it. Later we might let FastBreak assume some maximal duration for either case, instead of ignoring these.
2014-06-04 22:29:51 +02:00
import fr.neatmonster.nocheatplus.compat.AlmostBoolean;
Review dual wielding. * Account for off hand in more places. * Use bridge methods to get rid of warnings for now. * Adds utility methods to CheckUtils. * Do not allow left click on off hand (knockback).
2016-06-01 19:31:53 +02:00
import fr.neatmonster.nocheatplus.compat.Bridge1_9;
Do move Permissions where it belongs.
2012-11-06 10:11:17 +01:00
import fr.neatmonster.nocheatplus.permissions.Permissions;
[BROKEN] Data storage overhaul (basics). (+) (SAFETY COMMIT) Largely breaking change. * Interfaces in front of data types (and 'managers'), some interfaces removed. * Data and configuration fetching. * Check activation checking (config flags, isEnabled, hasBypass). * CheckType (activation checks, factories removed). * Lots of collateral signature changes, including IPlayerData. The (I)WorldDataManager stores per-world data (+ per world per check type). * Raw configurations. * Typical flags: check activation, debug, lag adaption. * Generic data, such as check configurations or per world check data. The (I)PlayerDataManager stores per player data. * Check Data. * Typical flags: debug * Exemption * Check data (and config cache). * Further mappings and later OfflinePlayerData. * The registration interface will allow defining, how instances are handled for registered types (factory, proxy, what on world change, what on logout, global removal handler, per player removal handler). (I)PlayerData is intended to be/become the central access point. * External interface is IPlayerData now. * Per player debug flags, exemptions. * Fetching configuration and data: local cache, relaying fetching to registered factories and proxy-registries/storage (e.g. fetching configuration from per world storage). Other fixes/changes: (+) Extend the debug player command (set true/false, reset to world default, arbitrary check types). (+) PlayerData maintains a currentWorldIdentifier (to be used instead of ChatData in future). (+) The WorldConfigProvider getAll implementation returns a LinkedHashSet now, avoiding duplicates. (+) Move DefaultGenericInstanceRegistry to NCPCore. (+) Thread-safety considerations for DefaultGenericInstanceRegistry. (+) Don't log errors on hasBypass checking. TBD: Instead intercept during listener methods (or even as a feature within the listener node: e.g. @ThreadContext(primaryThread=true, skipOffContext=true, cancelOffContext=true). (+) Add fight.wrongturn permissions to plugin.yml. (+) Missing GPLv3 headers. Broken/Missing: * WorldData inheritance from default: propagate all changes done directly to the default config to children (all worlds that don't have an explicit world_config.yml set) - possibly add an OverrideState or similar, (NONE, FROM_DEFAULT, EXPLICIT) and don't override EXPLICIT if coming from the default. Calling override on the default WorldData is not to be confused with calling override for WorldDataManager (override for all worlds as EXPLICIT). * Organize overriding for special circumstances (version dependent activation and the like). Might want to add registered override handlers to be called on reload automatically. * Store generic per check type per world data in the WorldDataManager, such as configurations and per-world check data. TBD: Factories, cleanup (!). * Most efficient referencing (IWorldCheckTypeNode, IHandle<something>?). * All the registry stuff (see PlayerData). * Use interfaces for auto registry (and a flag within RegistrationContext?) - world unload, world change, player join / leave. * (Data expiration handling including transition to IOfflinePlayerData, because now data is a little heavier.) * Further details.
2018-02-13 15:15:23 +01:00
import fr.neatmonster.nocheatplus.players.IPlayerData;
More haste.
2013-02-05 11:02:47 +01:00
import fr.neatmonster.nocheatplus.utilities.PotionUtil;
[Bleeding] Account for lag in blockbreak.fastbreak.
2013-01-04 14:21:08 +01:00
import fr.neatmonster.nocheatplus.utilities.TickTask;
[BREAKING] Move more classes around. This time the focus is on the utilities package. Possibly used, but not really official API: * Move block cache to a 'map' sub-package. * Move RichBounds/RichEntity/Player-Location and TrigUtil to a location sub-package. Not really official API, likely not used: * Move AttribUtil to compat, since it belongs there. * Split off direction check methods to collision.CollisionUtil. * Move static BlockCache methods to map.MapUtil. * Move food related methods from CheckUtils to InventoryUtil. * Move vehicle/passenger related methods from CheckUtils to PassengerUtil. Not breaking: * Move IdUtil to commons.
2016-06-21 09:31:21 +02:00
import fr.neatmonster.nocheatplus.utilities.map.BlockProperties;
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
/**
Clean up fastbreak: Add check for frequency of block breaking to leave the survival block breaking duration to the fastbreak check. Adaptions to the configuration. Fix creative / speed.
2012-09-12 08:01:32 +02:00
* A check used to verify if the player isn't breaking blocks faster than possible.
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
*/
public class FastBreak extends Check {
[Development] An other day of work, wow so much changes: some issues fixed (some others left), new API introduced, new way of declaring checks, etc.
2012-08-08 01:24:31 +02:00
/**
* Instantiates a new fast break check.
*/
public FastBreak() {
super(CheckType.BLOCKBREAK_FASTBREAK);
}
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
/**
Small cleanup for fastbreak: creative mode is not handled by this check.
2014-06-13 10:58:41 +02:00
* Checks a player for fastbreak. This is NOT for creative mode.
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
*
* @param player
* the player
* @param block
* the block
Adjustments to fastbreak + debug output.
2012-09-16 23:40:19 +02:00
* @param isInstaBreak
Fix issue with replacing broken blocks.
2012-09-12 20:28:36 +02:00
* @param data
* @param cc
Updated dependencies. New messages if an update is available/configuration is outdated. Improved FastBreak, NoPwnage and SurvivalFly checks. Re-added the 'Moved too quickly fix' (it needs to be manually enabled in the configuration).
2012-08-22 02:41:28 +02:00
* @param elaspedTime
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
* @return true, if successful
*/
[BLEEDING][BREAKING][INSTABLE] Swiftly throw in permission caching. Benefits: * Improves performance, where permission lookup has major impact, with timeout based lookup, static permissions (skip permission check entirely), and world/offline based invalidation. (Once fully implemented.) * Hopefully more efficient: use Bukkit Permission for faster defaults. * (Allows control over how which permission is to be updated/invalidated, which is useful per se.) Risks: * Complex changes yield bugs. * Other plugins depending on NCP might break. * Cache incoherence might happen (permissions are changed dynamically +- unintended malconfiguration, or in case of bugs). * (Endless loops certainly have all been fixed.) Breaking: * Lots of more or less internal API has been changed or removed: Check, CheckType, CheckUtils, TickTask, ... * Permission checking behavior has been altered. Rough points: * Implement a permission cache within PlayerData. * Remove the player tasks and permission updates in favour of handling those within DataManager and PlayerData. * Adjust everything else to it (partly TBD). * Updating sets of permissions (e.g. for CHAT) is done more lazily now, i.e. one per 10 ticks). An actual permission check would still yield an update next tick (asynchronous). * Fixed/extended random spots (DualCollection, MiniListener registration support, StringUtil). Missing: * Basic implementation * Cleanup after logout (stages: 1. non-essential like permissions, 2. unrecoverable like set-back location, 3. complete data removal). * Coverage * Might have missed spots. * NoCheatPlus.nameSetPerms should be replaced by caching + default config for world-wise updating. * Command permissions are always checked. At least for players, cache based lookup should get implemented. * More unit tests. * Extended configurability: Per-world settings/policies. * Efficiency * Not all parts of the implementation are 100%/optimal yet.
2018-01-28 18:52:51 +01:00
public boolean check(final Player player, final Block block, final AlmostBoolean isInstaBreak,
[BROKEN] Data storage overhaul (basics). (+) (SAFETY COMMIT) Largely breaking change. * Interfaces in front of data types (and 'managers'), some interfaces removed. * Data and configuration fetching. * Check activation checking (config flags, isEnabled, hasBypass). * CheckType (activation checks, factories removed). * Lots of collateral signature changes, including IPlayerData. The (I)WorldDataManager stores per-world data (+ per world per check type). * Raw configurations. * Typical flags: check activation, debug, lag adaption. * Generic data, such as check configurations or per world check data. The (I)PlayerDataManager stores per player data. * Check Data. * Typical flags: debug * Exemption * Check data (and config cache). * Further mappings and later OfflinePlayerData. * The registration interface will allow defining, how instances are handled for registered types (factory, proxy, what on world change, what on logout, global removal handler, per player removal handler). (I)PlayerData is intended to be/become the central access point. * External interface is IPlayerData now. * Per player debug flags, exemptions. * Fetching configuration and data: local cache, relaying fetching to registered factories and proxy-registries/storage (e.g. fetching configuration from per world storage). Other fixes/changes: (+) Extend the debug player command (set true/false, reset to world default, arbitrary check types). (+) PlayerData maintains a currentWorldIdentifier (to be used instead of ChatData in future). (+) The WorldConfigProvider getAll implementation returns a LinkedHashSet now, avoiding duplicates. (+) Move DefaultGenericInstanceRegistry to NCPCore. (+) Thread-safety considerations for DefaultGenericInstanceRegistry. (+) Don't log errors on hasBypass checking. TBD: Instead intercept during listener methods (or even as a feature within the listener node: e.g. @ThreadContext(primaryThread=true, skipOffContext=true, cancelOffContext=true). (+) Add fight.wrongturn permissions to plugin.yml. (+) Missing GPLv3 headers. Broken/Missing: * WorldData inheritance from default: propagate all changes done directly to the default config to children (all worlds that don't have an explicit world_config.yml set) - possibly add an OverrideState or similar, (NONE, FROM_DEFAULT, EXPLICIT) and don't override EXPLICIT if coming from the default. Calling override on the default WorldData is not to be confused with calling override for WorldDataManager (override for all worlds as EXPLICIT). * Organize overriding for special circumstances (version dependent activation and the like). Might want to add registered override handlers to be called on reload automatically. * Store generic per check type per world data in the WorldDataManager, such as configurations and per-world check data. TBD: Factories, cleanup (!). * Most efficient referencing (IWorldCheckTypeNode, IHandle<something>?). * All the registry stuff (see PlayerData). * Use interfaces for auto registry (and a flag within RegistrationContext?) - world unload, world change, player join / leave. * (Data expiration handling including transition to IOfflinePlayerData, because now data is a little heavier.) * Further details.
2018-02-13 15:15:23 +01:00
final BlockBreakConfig cc, final BlockBreakData data, final IPlayerData pData) {
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
final long now = System.currentTimeMillis();
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
boolean cancel = false;
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
Small cleanup for fastbreak: creative mode is not handled by this check.
2014-06-13 10:58:41 +02:00
// Determine expected breaking time by block type.
Reduce use of using block-ids in more places. * Use Material directly in more places. * Hide id-getting within BlockProperties. TODO: * BlockInit, BlockFlags + use of those. * Possibly other.
2014-06-13 11:27:42 +02:00
final Material blockType = block.getType();
final long expectedBreakingTime = Math.max(0, Math.round((double) BlockProperties.getBreakingDuration(blockType, player) * (double) cc.fastBreakModSurvival / 100D));
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
Add "strict" flag to blockbreak.fastbreak. This allows to count break...break instead of interact...break, if set to false.
2012-12-28 20:00:05 +01:00
final long elapsedTime;
Small cleanup for fastbreak: creative mode is not handled by this check.
2014-06-13 10:58:41 +02:00
// TODO: Concept for unbreakable blocks? Context: extreme VL.
Add "strict" flag to blockbreak.fastbreak. This allows to count break...break instead of interact...break, if set to false.
2012-12-28 20:00:05 +01:00
// TODO: Should it be breakingTime instead of 0 for inconsistencies?
Small cleanup for fastbreak: creative mode is not handled by this check.
2014-06-13 10:58:41 +02:00
if (cc.fastBreakStrict) {
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
// Counting interact...break.
elapsedTime = (data.fastBreakBreakTime > data.fastBreakfirstDamage) ? 0 : now - data.fastBreakfirstDamage;
Add "strict" flag to blockbreak.fastbreak. This allows to count break...break instead of interact...break, if set to false.
2012-12-28 20:00:05 +01:00
}
Small cleanup for fastbreak: creative mode is not handled by this check.
2014-06-13 10:58:41 +02:00
else {
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
// Counting break...break.
elapsedTime = (data.fastBreakBreakTime > now) ? 0 : now - data.fastBreakBreakTime;
Add "strict" flag to blockbreak.fastbreak. This allows to count break...break instead of interact...break, if set to false.
2012-12-28 20:00:05 +01:00
}
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
Clean up fastbreak: Add check for frequency of block breaking to leave the survival block breaking duration to the fastbreak check. Adaptions to the configuration. Fix creative / speed.
2012-09-12 08:01:32 +02:00
// Check if the time used time is lower than expected.
Small cleanup for fastbreak: creative mode is not handled by this check.
2014-06-13 10:58:41 +02:00
if (isInstaBreak.decideOptimistically()) {
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
// Ignore those for now.
// TODO: Find out why this was commented out long ago a) did not fix mcMMO b) exploits.
// TODO: Maybe adjust time to min(time, SOMETHING) for MAYBE/YES.
Ra-add the instant-break compatibility code. For whatever reason it was commented out, it is now put back, assuming that the reason was "it did not help with mcMMO", because mcMMO used to fire extra BlockBreakEventS. Now we use a tri-state and set it to MAYBE if instantBreak is set already on lowest priority, to have a rough indicator if a plugin set it, or if the server might have done it. Later we might let FastBreak assume some maximal duration for either case, instead of ignoring these.
2014-06-04 22:29:51 +02:00
}
Small cleanup for fastbreak: creative mode is not handled by this check.
2014-06-13 10:58:41 +02:00
else if (elapsedTime < 0) {
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
// Ignore it. TODO: ?
Account for TickTask resetting.
2013-01-23 03:06:52 +01:00
}
Small cleanup for fastbreak: creative mode is not handled by this check.
2014-06-13 10:58:41 +02:00
else if (elapsedTime + cc.fastBreakDelay < expectedBreakingTime) {
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
// lag or cheat or Minecraft.
// Count in server side lag, if desired.
[BROKEN] Data storage overhaul (basics). (+) (SAFETY COMMIT) Largely breaking change. * Interfaces in front of data types (and 'managers'), some interfaces removed. * Data and configuration fetching. * Check activation checking (config flags, isEnabled, hasBypass). * CheckType (activation checks, factories removed). * Lots of collateral signature changes, including IPlayerData. The (I)WorldDataManager stores per-world data (+ per world per check type). * Raw configurations. * Typical flags: check activation, debug, lag adaption. * Generic data, such as check configurations or per world check data. The (I)PlayerDataManager stores per player data. * Check Data. * Typical flags: debug * Exemption * Check data (and config cache). * Further mappings and later OfflinePlayerData. * The registration interface will allow defining, how instances are handled for registered types (factory, proxy, what on world change, what on logout, global removal handler, per player removal handler). (I)PlayerData is intended to be/become the central access point. * External interface is IPlayerData now. * Per player debug flags, exemptions. * Fetching configuration and data: local cache, relaying fetching to registered factories and proxy-registries/storage (e.g. fetching configuration from per world storage). Other fixes/changes: (+) Extend the debug player command (set true/false, reset to world default, arbitrary check types). (+) PlayerData maintains a currentWorldIdentifier (to be used instead of ChatData in future). (+) The WorldConfigProvider getAll implementation returns a LinkedHashSet now, avoiding duplicates. (+) Move DefaultGenericInstanceRegistry to NCPCore. (+) Thread-safety considerations for DefaultGenericInstanceRegistry. (+) Don't log errors on hasBypass checking. TBD: Instead intercept during listener methods (or even as a feature within the listener node: e.g. @ThreadContext(primaryThread=true, skipOffContext=true, cancelOffContext=true). (+) Add fight.wrongturn permissions to plugin.yml. (+) Missing GPLv3 headers. Broken/Missing: * WorldData inheritance from default: propagate all changes done directly to the default config to children (all worlds that don't have an explicit world_config.yml set) - possibly add an OverrideState or similar, (NONE, FROM_DEFAULT, EXPLICIT) and don't override EXPLICIT if coming from the default. Calling override on the default WorldData is not to be confused with calling override for WorldDataManager (override for all worlds as EXPLICIT). * Organize overriding for special circumstances (version dependent activation and the like). Might want to add registered override handlers to be called on reload automatically. * Store generic per check type per world data in the WorldDataManager, such as configurations and per-world check data. TBD: Factories, cleanup (!). * Most efficient referencing (IWorldCheckTypeNode, IHandle<something>?). * All the registry stuff (see PlayerData). * Use interfaces for auto registry (and a flag within RegistrationContext?) - world unload, world change, player join / leave. * (Data expiration handling including transition to IOfflinePlayerData, because now data is a little heavier.) * Further details.
2018-02-13 15:15:23 +01:00
final float lag = pData.getCurrentWorldDataSafe().shouldAdjustToLag(type)
? TickTask.getLag(expectedBreakingTime, true) : 1f;
final long missingTime = expectedBreakingTime - (long) (lag * elapsedTime);
if (missingTime > 0) {
// Add as penalty
data.fastBreakPenalties.add(now, (float) missingTime);
// Only raise a violation, if the total penalty score exceeds the contention duration (for lag, delay).
if (data.fastBreakPenalties.score(cc.fastBreakBucketFactor) > cc.fastBreakGrace) {
// TODO: maybe add one absolute penalty time for big amounts to stop breaking until then
final double vlAdded = (double) missingTime / 1000.0;
data.fastBreakVL += vlAdded;
final ViolationData vd = new ViolationData(this, player, data.fastBreakVL, vlAdded, cc.fastBreakActions);
if (vd.needsParameters()) {
vd.setParameter(ParameterName.BLOCK_TYPE, blockType.toString());
}
cancel = executeActions(vd).willCancel();
}
// else: still within contention limits.
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
}
}
else if (expectedBreakingTime > cc.fastBreakDelay) {
// Fast breaking does not decrease violation level.
data.fastBreakVL *= 0.9D;
}
[BROKEN] Data storage overhaul (basics). (+) (SAFETY COMMIT) Largely breaking change. * Interfaces in front of data types (and 'managers'), some interfaces removed. * Data and configuration fetching. * Check activation checking (config flags, isEnabled, hasBypass). * CheckType (activation checks, factories removed). * Lots of collateral signature changes, including IPlayerData. The (I)WorldDataManager stores per-world data (+ per world per check type). * Raw configurations. * Typical flags: check activation, debug, lag adaption. * Generic data, such as check configurations or per world check data. The (I)PlayerDataManager stores per player data. * Check Data. * Typical flags: debug * Exemption * Check data (and config cache). * Further mappings and later OfflinePlayerData. * The registration interface will allow defining, how instances are handled for registered types (factory, proxy, what on world change, what on logout, global removal handler, per player removal handler). (I)PlayerData is intended to be/become the central access point. * External interface is IPlayerData now. * Per player debug flags, exemptions. * Fetching configuration and data: local cache, relaying fetching to registered factories and proxy-registries/storage (e.g. fetching configuration from per world storage). Other fixes/changes: (+) Extend the debug player command (set true/false, reset to world default, arbitrary check types). (+) PlayerData maintains a currentWorldIdentifier (to be used instead of ChatData in future). (+) The WorldConfigProvider getAll implementation returns a LinkedHashSet now, avoiding duplicates. (+) Move DefaultGenericInstanceRegistry to NCPCore. (+) Thread-safety considerations for DefaultGenericInstanceRegistry. (+) Don't log errors on hasBypass checking. TBD: Instead intercept during listener methods (or even as a feature within the listener node: e.g. @ThreadContext(primaryThread=true, skipOffContext=true, cancelOffContext=true). (+) Add fight.wrongturn permissions to plugin.yml. (+) Missing GPLv3 headers. Broken/Missing: * WorldData inheritance from default: propagate all changes done directly to the default config to children (all worlds that don't have an explicit world_config.yml set) - possibly add an OverrideState or similar, (NONE, FROM_DEFAULT, EXPLICIT) and don't override EXPLICIT if coming from the default. Calling override on the default WorldData is not to be confused with calling override for WorldDataManager (override for all worlds as EXPLICIT). * Organize overriding for special circumstances (version dependent activation and the like). Might want to add registered override handlers to be called on reload automatically. * Store generic per check type per world data in the WorldDataManager, such as configurations and per-world check data. TBD: Factories, cleanup (!). * Most efficient referencing (IWorldCheckTypeNode, IHandle<something>?). * All the registry stuff (see PlayerData). * Use interfaces for auto registry (and a flag within RegistrationContext?) - world unload, world change, player join / leave. * (Data expiration handling including transition to IOfflinePlayerData, because now data is a little heavier.) * Further details.
2018-02-13 15:15:23 +01:00
// TODO: Rework to use (then hopefully completed) BlockBreakKey.
if (pData.isDebugActive(type)) {
tailDebugStats(player, isInstaBreak, blockType,
elapsedTime, expectedBreakingTime, data, pData);
}
else {
data.stats = null;
}
// (The break time is set in the listener).
return cancel;
}
private void tailDebugStats(final Player player, final AlmostBoolean isInstaBreak,
final Material blockType, final long elapsedTime, final long expectedBreakingTime,
final BlockBreakData data, final IPlayerData pData) {
if (pData.hasPermission(Permissions.ADMINISTRATION_DEBUG, player)) {
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
// General stats:
[BLEEDING][BREAKING][INSTABLE] Swiftly throw in permission caching. Benefits: * Improves performance, where permission lookup has major impact, with timeout based lookup, static permissions (skip permission check entirely), and world/offline based invalidation. (Once fully implemented.) * Hopefully more efficient: use Bukkit Permission for faster defaults. * (Allows control over how which permission is to be updated/invalidated, which is useful per se.) Risks: * Complex changes yield bugs. * Other plugins depending on NCP might break. * Cache incoherence might happen (permissions are changed dynamically +- unintended malconfiguration, or in case of bugs). * (Endless loops certainly have all been fixed.) Breaking: * Lots of more or less internal API has been changed or removed: Check, CheckType, CheckUtils, TickTask, ... * Permission checking behavior has been altered. Rough points: * Implement a permission cache within PlayerData. * Remove the player tasks and permission updates in favour of handling those within DataManager and PlayerData. * Adjust everything else to it (partly TBD). * Updating sets of permissions (e.g. for CHAT) is done more lazily now, i.e. one per 10 ticks). An actual permission check would still yield an update next tick (asynchronous). * Fixed/extended random spots (DualCollection, MiniListener registration support, StringUtil). Missing: * Basic implementation * Cleanup after logout (stages: 1. non-essential like permissions, 2. unrecoverable like set-back location, 3. complete data removal). * Coverage * Might have missed spots. * NoCheatPlus.nameSetPerms should be replaced by caching + default config for world-wise updating. * Command permissions are always checked. At least for players, cache based lookup should get implemented. * More unit tests. * Extended configurability: Per-world settings/policies. * Efficiency * Not all parts of the implementation are 100%/optimal yet.
2018-01-28 18:52:51 +01:00
// TODO: Replace stats by new system (BlockBreakKey once complete), commands to inspect / auto-config.
[BROKEN] Data storage overhaul (basics). (+) (SAFETY COMMIT) Largely breaking change. * Interfaces in front of data types (and 'managers'), some interfaces removed. * Data and configuration fetching. * Check activation checking (config flags, isEnabled, hasBypass). * CheckType (activation checks, factories removed). * Lots of collateral signature changes, including IPlayerData. The (I)WorldDataManager stores per-world data (+ per world per check type). * Raw configurations. * Typical flags: check activation, debug, lag adaption. * Generic data, such as check configurations or per world check data. The (I)PlayerDataManager stores per player data. * Check Data. * Typical flags: debug * Exemption * Check data (and config cache). * Further mappings and later OfflinePlayerData. * The registration interface will allow defining, how instances are handled for registered types (factory, proxy, what on world change, what on logout, global removal handler, per player removal handler). (I)PlayerData is intended to be/become the central access point. * External interface is IPlayerData now. * Per player debug flags, exemptions. * Fetching configuration and data: local cache, relaying fetching to registered factories and proxy-registries/storage (e.g. fetching configuration from per world storage). Other fixes/changes: (+) Extend the debug player command (set true/false, reset to world default, arbitrary check types). (+) PlayerData maintains a currentWorldIdentifier (to be used instead of ChatData in future). (+) The WorldConfigProvider getAll implementation returns a LinkedHashSet now, avoiding duplicates. (+) Move DefaultGenericInstanceRegistry to NCPCore. (+) Thread-safety considerations for DefaultGenericInstanceRegistry. (+) Don't log errors on hasBypass checking. TBD: Instead intercept during listener methods (or even as a feature within the listener node: e.g. @ThreadContext(primaryThread=true, skipOffContext=true, cancelOffContext=true). (+) Add fight.wrongturn permissions to plugin.yml. (+) Missing GPLv3 headers. Broken/Missing: * WorldData inheritance from default: propagate all changes done directly to the default config to children (all worlds that don't have an explicit world_config.yml set) - possibly add an OverrideState or similar, (NONE, FROM_DEFAULT, EXPLICIT) and don't override EXPLICIT if coming from the default. Calling override on the default WorldData is not to be confused with calling override for WorldDataManager (override for all worlds as EXPLICIT). * Organize overriding for special circumstances (version dependent activation and the like). Might want to add registered override handlers to be called on reload automatically. * Store generic per check type per world data in the WorldDataManager, such as configurations and per-world check data. TBD: Factories, cleanup (!). * Most efficient referencing (IWorldCheckTypeNode, IHandle<something>?). * All the registry stuff (see PlayerData). * Use interfaces for auto registry (and a flag within RegistrationContext?) - world unload, world change, player join / leave. * (Data expiration handling including transition to IOfflinePlayerData, because now data is a little heavier.) * Further details.
2018-02-13 15:15:23 +01:00
data.setStats();
data.stats.addStats(data.stats.getId(blockType+ "/u", true), elapsedTime);
data.stats.addStats(data.stats.getId(blockType + "/r", true), expectedBreakingTime);
player.sendMessage(data.stats.getStatsStr(true));
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
// Send info about current break:
Review dual wielding. * Account for off hand in more places. * Use bridge methods to get rid of warnings for now. * Adds utility methods to CheckUtils. * Do not allow left click on off hand (knockback).
2016-06-01 19:31:53 +02:00
final ItemStack stack = Bridge1_9.getItemInMainHand(player);
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
final boolean isValidTool = BlockProperties.isValidTool(blockType, stack);
final double haste = PotionUtil.getPotionEffectAmplifier(player, PotionEffectType.FAST_DIGGING);
[BLEEDING] Double trouble potential: NaN, infinity. + random Formatting + random fix (same angle checked twice in TrigUtil).
2016-12-27 15:10:08 +01:00
String msg = (isInstaBreak.decideOptimistically() ? ("[Insta=" + isInstaBreak + "]") : "[Normal]") + "[" + blockType + "] "+ elapsedTime + "u / " + expectedBreakingTime +"r (" + (isValidTool?"tool":"no-tool") + ")" + (Double.isInfinite(haste) ? "" : " haste=" + ((int) haste + 1));
[BREAKING][BLEEDING] Adjust the API to the upcoming penalty framework. This is a first step in, which doesn't change the default behavior, however it might break plugins that rely on certain internals. PenaltyAction allows to do something with probabilities to consider, including the possibility to select the first applicable penalty or applying several penalties. There will be player-specific penalties, which are applied during ViolationData.executeActions always, and there will be input-specific penalties, e.g. for applying within the event listener. Potentially breaking: * Return value of executeActions is now void for Action + ViolationData. * Return value of Check.executeActions is ViolationData now. * CancelAction is now extending PenaltyAction. * CancelPenalty may cancel, but might not, due to probability. * IViolationInfo.hasCancel -> deprecated, now returns willCancel(). * IViolationInfo.willCancel is now used, applicable penalties are estimated on creation of ViolationData. * Custom actions can no longer be used to cause cancel. Only penalties can do so now (due to the return type change). CancelAction is still there to keep a simple action for canceling. Not yet: * InputSpecificPenalty support for fight checks and using them in the default actions. * Configuration for penalties (currently only a plugin could override the action factories, later penalties may have a probability to apply, reference each other, allow first match, apply several at once).
2016-02-10 00:05:11 +01:00
player.sendMessage(msg);
[BROKEN] Data storage overhaul (basics). (+) (SAFETY COMMIT) Largely breaking change. * Interfaces in front of data types (and 'managers'), some interfaces removed. * Data and configuration fetching. * Check activation checking (config flags, isEnabled, hasBypass). * CheckType (activation checks, factories removed). * Lots of collateral signature changes, including IPlayerData. The (I)WorldDataManager stores per-world data (+ per world per check type). * Raw configurations. * Typical flags: check activation, debug, lag adaption. * Generic data, such as check configurations or per world check data. The (I)PlayerDataManager stores per player data. * Check Data. * Typical flags: debug * Exemption * Check data (and config cache). * Further mappings and later OfflinePlayerData. * The registration interface will allow defining, how instances are handled for registered types (factory, proxy, what on world change, what on logout, global removal handler, per player removal handler). (I)PlayerData is intended to be/become the central access point. * External interface is IPlayerData now. * Per player debug flags, exemptions. * Fetching configuration and data: local cache, relaying fetching to registered factories and proxy-registries/storage (e.g. fetching configuration from per world storage). Other fixes/changes: (+) Extend the debug player command (set true/false, reset to world default, arbitrary check types). (+) PlayerData maintains a currentWorldIdentifier (to be used instead of ChatData in future). (+) The WorldConfigProvider getAll implementation returns a LinkedHashSet now, avoiding duplicates. (+) Move DefaultGenericInstanceRegistry to NCPCore. (+) Thread-safety considerations for DefaultGenericInstanceRegistry. (+) Don't log errors on hasBypass checking. TBD: Instead intercept during listener methods (or even as a feature within the listener node: e.g. @ThreadContext(primaryThread=true, skipOffContext=true, cancelOffContext=true). (+) Add fight.wrongturn permissions to plugin.yml. (+) Missing GPLv3 headers. Broken/Missing: * WorldData inheritance from default: propagate all changes done directly to the default config to children (all worlds that don't have an explicit world_config.yml set) - possibly add an OverrideState or similar, (NONE, FROM_DEFAULT, EXPLICIT) and don't override EXPLICIT if coming from the default. Calling override on the default WorldData is not to be confused with calling override for WorldDataManager (override for all worlds as EXPLICIT). * Organize overriding for special circumstances (version dependent activation and the like). Might want to add registered override handlers to be called on reload automatically. * Store generic per check type per world data in the WorldDataManager, such as configurations and per-world check data. TBD: Factories, cleanup (!). * Most efficient referencing (IWorldCheckTypeNode, IHandle<something>?). * All the registry stuff (see PlayerData). * Use interfaces for auto registry (and a flag within RegistrationContext?) - world unload, world change, player join / leave. * (Data expiration handling including transition to IOfflinePlayerData, because now data is a little heavier.) * Further details.
2018-02-13 15:15:23 +01:00
// net.minecraft.server.Item mcItem = net.minecraft.server.Item.byId[stack.getTypeId()];
// if (mcItem != null) {
// double x = mcItem.getDestroySpeed(((CraftItemStack) stack).getHandle(), net.minecraft.server.Block.byId[blockId]);
// player.sendMessage("mc speed: " + x);
// }
Adjustments to fastbreak + debug output.
2012-09-16 23:40:19 +02:00
}
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
}
[BROKEN] Data storage overhaul (basics). (+) (SAFETY COMMIT) Largely breaking change. * Interfaces in front of data types (and 'managers'), some interfaces removed. * Data and configuration fetching. * Check activation checking (config flags, isEnabled, hasBypass). * CheckType (activation checks, factories removed). * Lots of collateral signature changes, including IPlayerData. The (I)WorldDataManager stores per-world data (+ per world per check type). * Raw configurations. * Typical flags: check activation, debug, lag adaption. * Generic data, such as check configurations or per world check data. The (I)PlayerDataManager stores per player data. * Check Data. * Typical flags: debug * Exemption * Check data (and config cache). * Further mappings and later OfflinePlayerData. * The registration interface will allow defining, how instances are handled for registered types (factory, proxy, what on world change, what on logout, global removal handler, per player removal handler). (I)PlayerData is intended to be/become the central access point. * External interface is IPlayerData now. * Per player debug flags, exemptions. * Fetching configuration and data: local cache, relaying fetching to registered factories and proxy-registries/storage (e.g. fetching configuration from per world storage). Other fixes/changes: (+) Extend the debug player command (set true/false, reset to world default, arbitrary check types). (+) PlayerData maintains a currentWorldIdentifier (to be used instead of ChatData in future). (+) The WorldConfigProvider getAll implementation returns a LinkedHashSet now, avoiding duplicates. (+) Move DefaultGenericInstanceRegistry to NCPCore. (+) Thread-safety considerations for DefaultGenericInstanceRegistry. (+) Don't log errors on hasBypass checking. TBD: Instead intercept during listener methods (or even as a feature within the listener node: e.g. @ThreadContext(primaryThread=true, skipOffContext=true, cancelOffContext=true). (+) Add fight.wrongturn permissions to plugin.yml. (+) Missing GPLv3 headers. Broken/Missing: * WorldData inheritance from default: propagate all changes done directly to the default config to children (all worlds that don't have an explicit world_config.yml set) - possibly add an OverrideState or similar, (NONE, FROM_DEFAULT, EXPLICIT) and don't override EXPLICIT if coming from the default. Calling override on the default WorldData is not to be confused with calling override for WorldDataManager (override for all worlds as EXPLICIT). * Organize overriding for special circumstances (version dependent activation and the like). Might want to add registered override handlers to be called on reload automatically. * Store generic per check type per world data in the WorldDataManager, such as configurations and per-world check data. TBD: Factories, cleanup (!). * Most efficient referencing (IWorldCheckTypeNode, IHandle<something>?). * All the registry stuff (see PlayerData). * Use interfaces for auto registry (and a flag within RegistrationContext?) - world unload, world change, player join / leave. * (Data expiration handling including transition to IOfflinePlayerData, because now data is a little heavier.) * Further details.
2018-02-13 15:15:23 +01:00
[Development] BlockBreak, BlockPlace, Chat & Moving checks rewritten but untested. This version is far from being complete.
2012-08-03 16:48:06 +02:00
}