GH-189 EternalCombat 2.0. #189
Conversation
* Multification setup * Bump version of multification * Override adventure API. Bump LiteCommands * Fix import * Fix minor issues with notices * Change BukktiNotice to Notice * Resolve Rollczi's suggestions * MAJOR FIX * uncomment dev.rollczi.litecommands needed for testing --------- Co-authored-by: Rollczi <ndejlich5@gmail.com>
* Refactor config description. * fix. * Update eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/PluginConfig.java Co-authored-by: Jakub Kędziora <77227023+Jakubk15@users.noreply.github.com> * Follow review feedback. * Refactor default messages. * Remove gradient from combatNotification. * Improve some messages. * Add ASCII tag of EternalCombat in config --------- Co-authored-by: Michał Wojtas <80779749+CitralFlo@users.noreply.github.com> Co-authored-by: Jakub Kędziora <77227023+Jakubk15@users.noreply.github.com> Co-authored-by: CitralFlo <wojtas.michal90@gmail.com>
…ble every time (#205) * Add on FightUntagEvent allow player flight again, coz its disable every time * Update config, update var * Check Creative gamemode
WalkthroughThe changes involve extensive refactoring across the project. Multiple classes have been renamed, removed, or converted to interfaces to emphasize a service-based design. Notification handling was updated by replacing the old announcer with a new notice service. Package declarations and dependency versions were modified in build files, and the README was updated to reflect these version changes. Key functionalities in combat, drop management, region handling, border control, and effect application have been reorganized. New configuration classes with nested settings were introduced while outdated config files and plugins were removed. Additionally, command handling and event management code have been updated for consistency. ✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
* Implement border * More important changes * Add blocks updater * Implement it * Include combat limitation for border * Fix knockback * Fix region resolving * Remove useless comments * Cleanup code. Add caches for chunk snapshot * Code style changes * Add config for the border and the knockback, cleanup * Bump actions * Minor configuration adjustments Took 30 minutes * Follow Jakubek review * Follow DMK review --------- Co-authored-by: Michał Wojtas <wojtas.michal90@gmail.com>
* Refactor config v2. * Move to minimessages.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (46)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderLazyResult.java (2)
13-15: Simple method for adding lazy border points.This method provides a clean way to add lazy-loaded border points to the collection. Consider adding a brief comment explaining its purpose for better code readability.
1-24: Consider thread safety.If this class might be accessed by multiple threads, you may want to make the borderPoints list thread-safe or add synchronization to the methods.
eternalcombat-api/src/main/java/com/eternalcode/combat/region/RegionProvider.java (1)
16-17: Good addition of the getRegions methodThis new method lets you get all regions in a world, which adds useful functionality to the interface.
Consider adding a simple comment to explain what this method does for anyone implementing it in the future.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleTypeTransformer.java (1)
12-42: Nice transformer implementation, but could use a few improvements.The class looks solid but consider adding null checks for the input parameters in both transformation methods to prevent NullPointerExceptions. Some brief JavaDoc comments would also make the code more maintainable for other developers.
public class ParticleTypeTransformer extends BidirectionalTransformer<String, ParticleType<?>> { + /** + * Returns the generic types for this transformer. + */ @Override public GenericsPair<String, ParticleType<?>> getPair() { return this.generics(GenericsDeclaration.of(String.class), GenericsDeclaration.of(ParticleType.class)); } + /** + * Converts a string to a ParticleType. + * + * @param data The string to convert + * @param serdesContext The serialization context + * @return The corresponding ParticleType + * @throws IllegalArgumentException if the particle type is unknown + */ @Override public ParticleType<?> leftToRight(String data, SerdesContext serdesContext) { + if (data == null) { + throw new IllegalArgumentException("Particle type cannot be null"); + } + if (!data.contains(":")) { data = ResourceLocation.normString(data); } ParticleType<?> type = ParticleTypes.getByName(data.toLowerCase(Locale.ROOT)); if (type == null) { throw new IllegalArgumentException("Unknown particle type: " + data); } return type; } + /** + * Converts a ParticleType to its string representation. + * + * @param data The ParticleType to convert + * @param serdesContext The serialization context + * @return The string representation of the ParticleType + */ @Override public String rightToLeft(ParticleType<?> data, SerdesContext serdesContext) { + if (data == null) { + return null; + } + ResourceLocation location = data.getName(); if (location.getNamespace().equals(ResourceLocation.VANILLA_NAMESPACE)) { return location.getKey().toUpperCase(Locale.ROOT); } return location.toString(); }eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightTagImpl.java (2)
15-19: Constructor parameter naming could be improved.Consider renaming
personToAddCombattotaggedPlayerto match the field name for better readability.
9-53: Consider adding parameter validation.The constructor doesn't check for null values that could cause errors later. Consider adding null checks for critical parameters.
FightTagImpl(UUID personToAddCombat, Instant endOfCombatLog, @Nullable UUID tagger) { + if (personToAddCombat == null) { + throw new IllegalArgumentException("Tagged player cannot be null"); + } + if (endOfCombatLog == null) { + throw new IllegalArgumentException("End of combat log cannot be null"); + } this.taggedPlayer = personToAddCombat; this.endOfCombatLog = endOfCombatLog; this.tagger = tagger; }eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/FightUntagEvent.java (1)
62-64: Good handler reference update!Updated the static
getHandlerList()method to returnHANDLER_LIST.Consider adding the
@NotNullannotation to this method too for consistency withgetHandlers().eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleSettings.java (2)
38-54: Good implementation of particle creationThe particle creation methods are well-structured. Consider adding JavaDoc comments to explain the methods' purposes.
60-74: Type handling works but could be improvedThe method correctly handles DUST and ENTITY_EFFECT particles. Consider adding validation for supported particle types rather than returning empty data for unsupported types.
private <T extends ParticleData> T createData(ParticleType<T> type, BorderPoint point) { if (type.equals(ParticleTypes.DUST)) { Color color = this.color.getColor(point); return (T) new ParticleDustData(orElse(scale, 1.0F), color.getRed(), color.getGreen(), color.getBlue()); } if (type.equals(ParticleTypes.ENTITY_EFFECT)) { Color color = this.color.getColor(point); AlphaColor alphaColor = new AlphaColor(color.getAlpha(), color.getRed(), color.getGreen(), color.getBlue()); return (T) new ParticleColorData(alphaColor); } + // Log warning for unsupported particle type + System.out.println("Unsupported particle type: " + type.getName()); return ParticleData.emptyData(); }eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/impl/PlayersHealthDropModifier.java (1)
35-41: Logout Check in modifyDrop:
The early return when no logout is found is clear. Consider a more explicit error handling, if possible, to avoid any potential null issues later.eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleColor.java (2)
28-28: Use getter instead of direct field access.For consistency, use the getter method instead of directly accessing the field.
-if (name.equals(RAINBOW.name)) { +if (name.equals(RAINBOW.getName())) {
1-41: Add Javadoc comments to improve documentation.Adding Javadoc would help other developers understand how to use this class, especially explaining what format the color name should be in (hex code).
For example:
/** * Represents a color for particles in border animations. * <p> * This class provides functionality to create and retrieve colors based on a name. * Color names can be either "RAINBOW" for dynamic rainbow colors or hex color codes. */ public class ParticleColor { // ... /** * Creates a ParticleColor from a name. * * @param name "RAINBOW" for rainbow effect or a hex color code (e.g., "#FF0000") * @return The particle color instance * @throws NumberFormatException if the name is not "RAINBOW" and cannot be decoded as a color */ public static ParticleColor fromName(String name) { // ... } }eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleController.java (4)
38-49: Check for null playerAdd a null check for the player in case they disconnect between event firing and processing.
@EventHandler void onBorderShowAsyncEvent(BorderShowAsyncEvent event) { if (!particleSettings.enabled) { return; } + Player player = event.getPlayer(); + if (player == null) { + return; + } - this.playersToUpdate.add(event.getPlayer().getUniqueId()); + this.playersToUpdate.add(player.getUniqueId()); for (BorderPoint point : event.getPoints()) { - this.playParticle(event.getPlayer(), point); + this.playParticle(player, point); } }
51-61: Add null check here tooSimilar to the previous handler, add a null check for the player.
@EventHandler void onBorderHideAsyncEvent(BorderHideAsyncEvent event) { if (!particleSettings.enabled) { return; } + Player player = event.getPlayer(); + if (player == null) { + return; + } - Set<BorderPoint> border = this.borderService.getActiveBorder(event.getPlayer()); + Set<BorderPoint> border = this.borderService.getActiveBorder(player); if (border.isEmpty()) { - this.playersToUpdate.remove(event.getPlayer().getUniqueId()); + this.playersToUpdate.remove(player.getUniqueId()); } }
38-38: Consider making event handlers publicStandard practice is to make event handlers public for clarity, though package-private works too.
-@EventHandler -void onBorderShowAsyncEvent(BorderShowAsyncEvent event) { +@EventHandler +public void onBorderShowAsyncEvent(BorderShowAsyncEvent event) { -@EventHandler -void onBorderHideAsyncEvent(BorderHideAsyncEvent event) { +@EventHandler +public void onBorderHideAsyncEvent(BorderHideAsyncEvent event) {Also applies to: 51-51
83-87: Add null check in playParticle methodIt's good practice to add parameter validation.
private void playParticle(Player player, BorderPoint point) { + if (player == null || point == null) { + return; + } WrapperPlayServerParticle particle = particleSettings.getParticle(point); PLAYER_MANAGER.sendPacket(player, particle); }eternalcombat-api/src/main/java/com/eternalcode/combat/fight/FightManager.java (2)
15-15: Add brief doc
A quick note on “inCombat” conditions might help clarity.
22-22: Additional tag method
Consider an optional object for ‘tagger’ if needed.eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockTypeTransformer.java (1)
15-23: Remove unnecessary null check.Based on the
BlockType.fromName()implementation (from the provided code snippets), it never returns null - it either returns a predefined type or creates a new one with the given name.@Override public BlockType leftToRight(String data, SerdesContext serdesContext) { BlockType blockType = BlockType.fromName(data); - if (blockType == null) { - throw new IllegalArgumentException("Unknown block type: " + data); - } return blockType; }eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/ChunkCache.java (1)
19-31: Add error handling and consider async pattern.The snapshot loading could block the thread when calling
.join(). Consider adding try/catch for error handling and potentially returning the result asynchronously.public ChunkSnapshot loadSnapshot(Player player, ChunkLocation location) { ChunkSnapshot snapshot = chunkCache.getIfPresent(location); if (snapshot != null) { return snapshot; } + try { ChunkSnapshot chunkSnapshot = PaperLib.getChunkAtAsync(player.getWorld(), location.x(), location.z(), false) .thenApply(chunk -> chunk.getChunkSnapshot()) .join(); chunkCache.put(location, chunkSnapshot); return chunkSnapshot; + } catch (Exception e) { + // Log the error and handle gracefully + return null; // Or another fallback strategy + } }eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockType.java (2)
14-17: Simple lambda expressions can be method referencesYou can make the code cleaner by using method references instead of lambdas.
- public static final BlockType RAINBOW_GLASS = new BlockType("RAINBOW_GLASS", point -> xyzToGlass(point)); - public static final BlockType RAINBOW_TERRACOTTA = new BlockType("RAINBOW_TERRACOTTA", point -> xyzToTerracotta(point)); - public static final BlockType RAINBOW_WOOL = new BlockType("RAINBOW_WOOL", point -> xyzToWool(point)); - public static final BlockType RAINBOW_CONCRETE = new BlockType("RAINBOW_CONCRETE", point -> xyzToConcrete(point)); + public static final BlockType RAINBOW_GLASS = new BlockType("RAINBOW_GLASS", BorderBlockRainbowUtil::xyzToGlass); + public static final BlockType RAINBOW_TERRACOTTA = new BlockType("RAINBOW_TERRACOTTA", BorderBlockRainbowUtil::xyzToTerracotta); + public static final BlockType RAINBOW_WOOL = new BlockType("RAINBOW_WOOL", BorderBlockRainbowUtil::xyzToWool); + public static final BlockType RAINBOW_CONCRETE = new BlockType("RAINBOW_CONCRETE", BorderBlockRainbowUtil::xyzToConcrete);
45-47: Use built-in functional interfaceSince TypeProvider is a simple functional interface, you can use the built-in Function interface.
- private interface TypeProvider { - StateType provide(BorderPoint point); - } + // Use java.util.function.Function<BorderPoint, StateType> insteadWith this change, you'll need to update the field declaration and method:
- private final TypeProvider type; + private final Function<BorderPoint, StateType> type; - public StateType getStateType(BorderPoint point) { - return type.provide(point); + public StateType getStateType(BorderPoint point) { + return type.apply(point);.github/CONTRIBUTING.md (1)
21-21: Fix typo in error reporting instructionsThere's a small typo where "messages" and "Settings" are merged together. This might confuse contributors when they're reporting issues.
- possible, including the version of Minecraft and the plugin you are using, as well as any error messagesSettings or logs. + possible, including the version of Minecraft and the plugin you are using, as well as any error messages or logs.eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/RegionSettings.java (1)
8-14: Consider using a more descriptive default region nameThe default value "your_region" seems like a placeholder. It might be better to use an empty list or a more descriptive example like "spawn" to avoid confusion for users who don't modify the default config.
- public List<String> blockedRegions = Collections.singletonList("your_region"); + public List<String> blockedRegions = Collections.singletonList("spawn");eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/DropKeepInventoryService.java (1)
13-13: Rename parameter for clarityThe parameter name "item" is used for a list of items. Consider renaming to "items" to match what it represents.
- void addItems(UUID uuid, List<ItemStack> item); + void addItems(UUID uuid, List<ItemStack> items);eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderShowAsyncEvent.java (2)
5-5: Remove unused importThe UUID import isn't used in this class.
-import java.util.UUID;
16-34: Consider documenting mutability choiceThe points field is mutable by design, with both a getter returning the internal Set and a setter method. Based on project guidelines, this is intentional for performance reasons. Consider adding a brief comment to document this design decision.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/BlockPlacementSettings.java (1)
31-32: Add blank line for consistent formattingThere's no blank line between the blockPlacementYCoordinate field and the restrictedBlockTypes comment, unlike the spacing between other fields.
public int blockPlacementYCoordinate = 40; + @Comment({eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/MessagesSettings.java (1)
102-199: Well-organized admin messages sectionKeeping admin messages in a separate nested class improves code organization. Each message has clear documentation about its purpose and available placeholders.
One minor note: line 191 has an empty message for
playerTagOutOff. Is this intentional? Players might benefit from some feedback when their tagging is re-enabled.Consider adding a simple message for
playerTagOutOffinstead of an empty string:-public Notice playerTagOutOff = Notice.chat(""); +public Notice playerTagOutOff = Notice.chat("<gradient:#00ff88:#00b300>✌ <gray>Combat protection removed</gray></gradient>");README.md (1)
97-97: Fix typo in error messages textThere appears to be a typo: "error messagesSettings or logs" should probably be "error messages or logs".
- possible, including the version of Minecraft and the plugin you are using, as well as any error messagesSettings or logs + possible, including the version of Minecraft and the plugin you are using, as well as any error messages or logseternalcombat-api/src/main/java/com/eternalcode/combat/fight/pearl/FightPearlService.java (1)
7-16: Consider adding Javadoc commentsThe interface methods have clear names, but adding brief Javadoc comments would make it easier for other developers to understand:
- What each method does
- What happens when
markDelayis called- Any default behavior users should know about
public interface FightPearlService { + /** + * Gets the delay timestamp for a player + * @param uuid The player's UUID + * @return The instant when the delay was set + */ Instant getDelay(UUID uuid); + /** + * Gets the remaining delay time for a player + * @param uuid The player's UUID + * @return The duration left in the delay + */ Duration getRemainingDelay(UUID uuid); + /** + * Checks if a player has an active delay + * @param uuid The player's UUID + * @return True if the player has an active delay + */ boolean hasDelay(UUID uuid); + /** + * Marks a delay for a player + * @param uuid The player's UUID + */ void markDelay(UUID uuid); }eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTrigger.java (1)
14-18: Consider adding a more descriptive method nameWhile
isTriggeredworks, a name likecontainsPointorisPointInTriggerAreamight better describe what the method is checking.eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/ConfigService.java (1)
50-54: Consider adding error handling for config reload.The reload method could benefit from try-catch blocks to handle potential file access or parsing errors.
public void reload() { for (OkaeriConfig config : this.configs) { + try { config.load(); + } catch (Exception e) { + // Log the error but continue reloading other configs + System.err.println("Failed to reload config: " + e.getMessage()); + } } }eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackService.java (1)
31-47: Consider adding safeguards for player disconnects.The current implementation might leave entries in the
insideRegionmap if a player disconnects before the scheduled task runs.public void forceKnockbackLater(Player player, Region region) { if (insideRegion.containsKey(player.getUniqueId())) { return; } insideRegion.put(player.getUniqueId(), region); scheduler.laterSync(() -> { insideRegion.remove(player.getUniqueId()); + if (!player.isOnline()) { + return; + } Location playerLocation = player.getLocation(); if (!region.contains(playerLocation)) { return; } Location location = KnockbackOutsideRegionGenerator.generate(region.getMin(), region.getMax(), playerLocation); player.teleport(location, PlayerTeleportEvent.TeleportCause.PLUGIN); }, this.config.knockback.forceDelay); }eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropController.java (4)
18-19: Variable name inconsistency.The variable is named
keepInventoryManagerbut its type isDropKeepInventoryService, creating a naming inconsistency.private final DropService dropService; -private final DropKeepInventoryService keepInventoryManager; +private final DropKeepInventoryService keepInventoryService;
23-25: Update variable assignment for consistency.The parameter name matches the variable name in the constructor, but should also be updated to match the suggested variable rename.
-public DropController(DropService dropService, DropKeepInventoryService keepInventoryManager, DropSettings dropSettings, FightManager fightManager) { +public DropController(DropService dropService, DropKeepInventoryService keepInventoryService, DropSettings dropSettings, FightManager fightManager) { this.dropService = dropService; - this.keepInventoryManager = keepInventoryManager; + this.keepInventoryService = keepInventoryService;
57-57: Update remaining references tokeepInventoryManager.If you rename the variable as suggested, update this reference too.
- this.keepInventoryManager.addItems(player.getUniqueId(), result.removedItems()); + this.keepInventoryService.addItems(player.getUniqueId(), result.removedItems());
69-75: Update remaining references tokeepInventoryManagerin this block.If you rename the variable as suggested, update these references too.
- if (this.keepInventoryManager.hasItems(playerUniqueId)) { + if (this.keepInventoryService.hasItems(playerUniqueId)) { PlayerInventory playerInventory = player.getInventory(); - ItemStack[] itemsToGive = this.keepInventoryManager.nextItems(playerUniqueId) + ItemStack[] itemsToGive = this.keepInventoryService.nextItems(playerUniqueId) .toArray(new ItemStack[0]);eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/effect/FightEffectServiceImpl.java (3)
36-39: Consider null check before removing player effectsIt might be safer to check if the player exists in the map before removing.
@Override public void clearStoredEffects(Player player) { - this.activeEffects.remove(player.getUniqueId()); + if (player != null) { + this.activeEffects.remove(player.getUniqueId()); + } }
46-65: Effect application logic could be improvedThe logic for checking and applying effects has redundant conditions.
@Override public void applyCustomEffect(Player player, PotionEffectType type, Integer amplifier) { PotionEffect activeEffect = player.getPotionEffect(type); if (activeEffect == null) { player.addPotionEffect(new PotionEffect(type, INFINITE_DURATION, amplifier)); return; } - if (activeEffect.getAmplifier() > amplifier) { + // Don't replace if current effect is stronger or already infinite with same/higher amplifier + if (activeEffect.getAmplifier() > amplifier || + (activeEffect.getDuration() == INFINITE_DURATION && activeEffect.getAmplifier() >= amplifier)) { return; } - if (activeEffect.getDuration() == -1) { - return; - } - this.storeActiveEffect(player, activeEffect); player.addPotionEffect(new PotionEffect(type, INFINITE_DURATION, amplifier)); }
67-80: Consider replacing amplifier comparison with equalityUsing
equals()for Integer comparison would be more precise than!=.- if (activeEffect.getAmplifier() != amplifier) { + if (!Integer.valueOf(activeEffect.getAmplifier()).equals(amplifier)) { return; }eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTriggerIndex.java (1)
63-77: Location trigger detection could be optimizedConsider caching the rounded coordinates to avoid multiple math operations.
public List<BorderTrigger> getTriggered(Location location) { BorderTriggerIndexBucket index = borderIndexes.get(location.getWorld().getName()); if (index == null) { return List.of(); } int x = (int) Math.round(location.getX()); int y = (int) Math.round(location.getY()); int z = (int) Math.round(location.getZ()); return index.getTriggers(x, z) .stream() - .filter(trigger -> trigger.isTriggered(x, y, z)) + .filter(trigger -> { + // Single evaluation of isTriggered with our pre-calculated coordinates + return trigger.isTriggered(x, y, z); + }) .toList(); }eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackOutsideRegionGenerator.java (2)
15-28: Consider world checks in Point2D.
Iflocation.getWorld()is null, it could cause errors. Adding a null check can avoid surprises.
65-69: Handle log calculations carefully.
Using logarithms for weighting is clever, but zero or negative distances would be problematic. Consider a small offset or a guard.eternalcombat-api/src/main/java/com/eternalcode/combat/fight/effect/FightEffectService.java (1)
14-24: Consider non-null amplifier.
If the amplifier cannot be null, using a primitiveintmight simplify the code and avoid null checks.eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightTagCommand.java (1)
77-123: Tag multiple command needs cleanup.The implementation is mostly good, but there's a redundant check at lines 112-114. If either of the first two checks fails, the method would have already returned.
- if (firstTagEvent.isCancelled() && secondTagEvent.isCancelled()) { - return; - }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (107)
.github/CONTRIBUTING.md(1 hunks).github/workflows/gradle.yml(2 hunks)README.md(2 hunks)buildSrc/src/main/kotlin/Versions.kt(2 hunks)buildSrc/src/main/kotlin/eternalcombat-java.gradle.kts(1 hunks)buildSrc/src/main/kotlin/eternalcombat-publish.gradle.kts(1 hunks)buildSrc/src/main/kotlin/eternalcombat-repositories.gradle.kts(1 hunks)eternalcombat-api/build.gradle.kts(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/CombatCommand.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/EternalCombatApi.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/command/InvalidUsage.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/command/PermissionMessage.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/config/ConfigService.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/config/implementation/PluginConfig.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/FightManager.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/FightTag.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/bossbar/FightBossBar.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/bossbar/FightBossBarRegistry.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/bossbar/FightBossBarService.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/Drop.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/DropKeepInventoryService.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/DropModifier.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/DropResult.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/DropService.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/DropType.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/effect/FightEffectService.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/CancelTagReason.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/CauseOfTag.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/CauseOfUnTag.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/FightTagEvent.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/FightUntagEvent.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/pearl/FightPearlService.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/tagout/FightTagOutService.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/tagout/TagOutCommand.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/notification/Notification.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/notification/NotificationAnnouncer.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/notification/NotificationType.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/notification/implementation/ActionBarNotification.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/notification/implementation/BossBarNotification.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/notification/implementation/ChatNotification.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/notification/implementation/SubTitleNotification.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/notification/implementation/TitleNotification.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/notification/serializer/NotificationSerializer.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/region/DefaultRegionProvider.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/region/Region.java(1 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/region/RegionController.java(0 hunks)eternalcombat-api/src/main/java/com/eternalcode/combat/region/RegionProvider.java(1 hunks)eternalcombat-plugin/build.gradle.kts(3 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/CombatPlugin.java(8 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/EternalCombatReloadCommand.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderActivePointsIndex.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderLazyResult.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderPoint.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderResult.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderService.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderServiceImpl.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderSettings.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTrigger.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTriggerController.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTriggerIndex.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTriggerIndexBucket.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/BorderColorUtil.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockSettings.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockType.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockTypeTransformer.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BorderBlockController.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BorderBlockRainbowUtil.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/ChunkCache.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/ChunkLocation.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleColor.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleColorTransformer.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleController.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleSettings.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleTypeTransformer.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderHideAsyncEvent.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderShowAsyncEvent.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/bridge/BridgeService.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/bridge/placeholder/FightTagPlaceholder.java(3 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/ConfigService.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/AdminSettings.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/BlockPlacementSettings.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/CombatSettings.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/CommandSettings.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/MessagesSettings.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/PluginConfig.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/RegionSettings.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightManagerImpl.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightTagCommand.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightTagImpl.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightTask.java(3 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/controller/FightActionBlockerController.java(8 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/controller/FightMessageController.java(4 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/controller/FightTagController.java(6 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/controller/FightUnTagController.java(2 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropController.java(3 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropKeepInventoryServiceImpl.java(2 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropServiceImpl.java(2 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropSettings.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/impl/PercentDropModifier.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/impl/PlayersHealthDropModifier.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/effect/FightEffectServiceImpl.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackOutsideRegionGenerator.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackRegionController.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackService.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackSettings.java(1 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/logout/LogoutController.java(2 hunks)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/pearl/FightPearlController.java(3 hunks)
⛔ Files not processed due to max files limit (12)
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/pearl/FightPearlServiceImpl.java
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/pearl/FightPearlSettings.java
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/tagout/FightTagOutCommand.java
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/tagout/FightTagOutController.java
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/tagout/FightTagOutServiceImpl.java
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/handler/InvalidUsageHandlerImpl.java
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/handler/MissingPermissionHandlerImpl.java
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/notification/NoticeService.java
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/region/DefaultRegionProvider.java
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/region/WorldGuardRegionProvider.java
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/updater/UpdaterNotificationController.java
- eternalcombat-plugin/src/main/java/com/eternalcode/combat/updater/UpdaterService.java
💤 Files with no reviewable changes (20)
- eternalcombat-api/src/main/java/com/eternalcode/combat/notification/implementation/ActionBarNotification.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/notification/Notification.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/notification/implementation/TitleNotification.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/notification/implementation/ChatNotification.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/config/ConfigService.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/notification/implementation/SubTitleNotification.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/notification/NotificationType.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/region/DefaultRegionProvider.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/command/InvalidUsage.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/CombatCommand.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/fight/bossbar/FightBossBar.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/notification/implementation/BossBarNotification.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/fight/tagout/TagOutCommand.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/fight/bossbar/FightBossBarRegistry.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/region/RegionController.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/config/implementation/PluginConfig.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/notification/serializer/NotificationSerializer.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/notification/NotificationAnnouncer.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/command/PermissionMessage.java
- eternalcombat-api/src/main/java/com/eternalcode/combat/fight/bossbar/FightBossBarService.java
🧰 Additional context used
🧠 Learnings (2)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderShowAsyncEvent.java (2)
Learnt from: Rollczi
PR: EternalCodeTeam/EternalCombat#204
File: eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderHideAsyncEvent.java:28-30
Timestamp: 2025-03-17T22:36:10.147Z
Learning: In the EternalCombat project, defensive copying of collections in event objects should be avoided due to performance concerns, even if it means sacrificing immutability guarantees.
Learnt from: Rollczi
PR: EternalCodeTeam/EternalCombat#204
File: eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderHideAsyncEvent.java:28-30
Timestamp: 2025-03-17T22:36:10.147Z
Learning: In the EternalCombat project, while most collections are designed to be immutable, defensive copying is selectively applied at strategic points rather than throughout the codebase, balancing immutability guarantees with performance considerations.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderHideAsyncEvent.java (2)
Learnt from: Rollczi
PR: EternalCodeTeam/EternalCombat#204
File: eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderHideAsyncEvent.java:28-30
Timestamp: 2025-03-17T22:36:10.147Z
Learning: In the EternalCombat project, defensive copying of collections in event objects should be avoided due to performance concerns, even if it means sacrificing immutability guarantees.
Learnt from: Rollczi
PR: EternalCodeTeam/EternalCombat#204
File: eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderHideAsyncEvent.java:28-30
Timestamp: 2025-03-17T22:36:10.147Z
Learning: In the EternalCombat project, while most collections are designed to be immutable, defensive copying is selectively applied at strategic points rather than throughout the codebase, balancing immutability guarantees with performance considerations.
🧬 Code Definitions (23)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockTypeTransformer.java (1)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockType.java (1) (1)
BlockType(12-49)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/ConfigService.java (3)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockTypeTransformer.java (1) (1)
BlockTypeTransformer(8-30)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleColorTransformer.java (1) (1)
ParticleColorTransformer(7-24)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleTypeTransformer.java (1) (1)
ParticleTypeTransformer(12-43)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackRegionController.java (1)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/notification/NoticeService.java (1) (1)
NoticeService(15-48)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleColor.java (1)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/BorderColorUtil.java (1) (1)
BorderColorUtil(5-18)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockSettings.java (1)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockType.java (1) (1)
BlockType(12-49)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/bridge/placeholder/FightTagPlaceholder.java (1)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/util/DurationUtil.java (1) (1)
DurationUtil(8-28)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/impl/PercentDropModifier.java (2)
eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/Drop.java (1) (1)
Drop(12-87)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropSettings.java (1) (1)
DropSettings(6-23)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BorderBlockController.java (2)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderHideAsyncEvent.java (1) (1)
BorderHideAsyncEvent(10-41)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderShowAsyncEvent.java (1) (1)
BorderShowAsyncEvent(11-46)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTriggerIndex.java (1)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTriggerIndexBucket.java (1) (1)
BorderTriggerIndexBucket(9-84)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/impl/PlayersHealthDropModifier.java (2)
eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/Drop.java (1) (1)
Drop(12-87)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropSettings.java (1) (1)
DropSettings(6-23)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackService.java (2)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/PluginConfig.java (1) (1)
PluginConfig(13-129)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackOutsideRegionGenerator.java (1) (1)
KnockbackOutsideRegionGenerator(13-98)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/controller/FightMessageController.java (1)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/notification/NoticeService.java (1) (1)
NoticeService(15-48)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/EternalCombatReloadCommand.java (3)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/ConfigService.java (1) (1)
ConfigService(22-64)eternalcombat-plugin/src/main/java/com/eternalcode/combat/notification/NoticeService.java (1) (1)
NoticeService(15-48)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightTagCommand.java (1) (1)
Command(23-160)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BorderBlockRainbowUtil.java (1)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/BorderColorUtil.java (1) (1)
BorderColorUtil(5-18)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleSettings.java (1)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleColor.java (1) (1)
ParticleColor(7-40)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockType.java (1)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BorderBlockRainbowUtil.java (1) (1)
BorderBlockRainbowUtil(13-122)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightTagCommand.java (5)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/MessagesSettings.java (1) (1)
MessagesSettings(10-200)eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/PluginConfig.java (1) (1)
PluginConfig(13-129)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/FightTagEvent.java (1) (1)
FightTagEvent(13-84)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/FightUntagEvent.java (1) (1)
FightUntagEvent(13-65)eternalcombat-plugin/src/main/java/com/eternalcode/combat/notification/NoticeService.java (1) (1)
NoticeService(15-48)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleColorTransformer.java (1)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleColor.java (1) (1)
ParticleColor(7-40)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/PluginConfig.java (5)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderSettings.java (1) (1)
BorderSettings(9-40)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropSettings.java (1) (1)
DropSettings(6-23)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/effect/FightEffectSettings.java (1) (1)
FightEffectSettings(10-26)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackSettings.java (1) (1)
KnockbackSettings(7-19)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/pearl/FightPearlSettings.java (1) (1)
FightPearlSettings(10-35)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightManagerImpl.java (3)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/event/EventCaller.java (1) (1)
EventCaller(6-20)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/FightTagEvent.java (1) (1)
FightTagEvent(13-84)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/FightUntagEvent.java (1) (1)
FightUntagEvent(13-65)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderServiceImpl.java (3)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderHideAsyncEvent.java (1) (1)
BorderHideAsyncEvent(10-41)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderShowAsyncEvent.java (1) (1)
BorderShowAsyncEvent(11-46)eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTriggerIndex.java (1) (1)
BorderTriggerIndex(16-79)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/controller/FightActionBlockerController.java (3)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/BlockPlacementSettings.java (1) (1)
BlockPlacementSettings(8-43)eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/FightUntagEvent.java (1) (1)
FightUntagEvent(13-65)eternalcombat-plugin/src/main/java/com/eternalcode/combat/notification/NoticeService.java (1) (1)
NoticeService(15-48)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/CombatPlugin.java (6)
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropServiceImpl.java (1) (1)
DropServiceImpl(6-38)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightManagerImpl.java (1) (1)
FightManagerImpl(19-86)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/effect/FightEffectServiceImpl.java (1) (1)
FightEffectServiceImpl(13-81)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/pearl/FightPearlServiceImpl.java (1) (1)
FightPearlServiceImpl(10-41)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/tagout/FightTagOutController.java (1) (1)
FightTagOutController(10-28)eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/tagout/FightTagOutServiceImpl.java (1) (1)
FightTagOutServiceImpl(9-37)
🔇 Additional comments (272)
eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/DropType.java (1)
1-1: Package Declaration Updated!The package change is clear and helps keep drop-related code in a more organized spot. Nice simple update!
eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/DropResult.java (1)
1-1: Clear Package RestructuringThe package change to
com.eternalcode.combat.fight.dropneatly reflects the new organization within the fight context. Great job on making the hierarchy more intuitive!eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/DropService.java (1)
3-8: Clean interface designNice work on this new interface! It's simple and has a clear purpose with just two well-named methods. This service-based approach will make it easier to manage drop modifications in your combat system.
eternalcombat-api/src/main/java/com/eternalcode/combat/fight/tagout/FightTagOutService.java (2)
6-6: Clean conversion to interface.This change from a concrete class to an interface follows good design principles and makes the code more flexible.
8-12: Method signatures look good.The core functionality is preserved with clear method signatures that will be easy for implementing classes to understand and follow.
eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/Drop.java (1)
1-1: Package Reorganization:
The package declaration has been updated to "com.eternalcode.combat.fight.drop" which neatly reflects the refactoring towards fight-related drop functionalities. Please make sure that all import statements and references to this class across the project have been updated accordingly.eternalcombat-api/src/main/java/com/eternalcode/combat/region/Region.java (3)
9-11: Added essential boundary methods.These new methods provide a way to get the minimum and maximum points of a region, which is needed for the new containment checks.
13-15: Good implementation of Location containment check.This method nicely handles Location objects by passing their coordinates to the more detailed containment method.
17-23: Well-designed coordinate containment check.The method correctly checks if coordinates fall within the region's boundaries. The use of >= for minimum bounds and < for maximum bounds is a standard approach for defining regions.
eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/DropModifier.java (2)
1-1: Excellent Package Revamp!
The package declaration now fits the reorganization nicely. Just make sure all related classes and imports are updated accordingly.
3-9: Interface Looks Clean!
The method signatures in the interface are clear and straightforward. No issues here!eternalcombat-plugin/src/main/java/com/eternalcode/combat/bridge/placeholder/FightTagPlaceholder.java (6)
41-41: Good use of explicit this reference.Adding
thiskeyword makes it clearer you're accessing a class field. This style improves readability.
46-46: Good use of explicit this reference.Similar to the previous change, this makes field access more explicit.
53-53: Variable name update improves clarity.Renaming from
fightTagtofightTagInterhelps distinguish the lambda parameter from other similarly named elements.
64-64: Good use of explicit method call.Adding
thiskeyword clearly shows you're calling an instance method.
70-70: Good use of explicit method call.Consistent with previous changes, making the method call explicit.
80-80: Variable name update for consistency.Renaming matches the earlier change, maintaining naming consistency throughout the file.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/bridge/BridgeService.java (3)
33-34: Nice configuration update.Your change to use
this.pluginConfig.regions.blockedRegionsshows that configuration has been reorganized more logically. Also, passing the whole config object gives the provider more flexibility.
36-36: Good consistency in configuration.This follows the same pattern of moving region settings to a dedicated section, making the code more organized.
42-42: Fixed variable reference.Using
this.plugininstead of justpluginensures you're referencing the class member variable correctly.eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleColorTransformer.java (3)
7-12: Class structure looks good!The class correctly extends BidirectionalTransformer and implements the required getPair method to specify the conversion types.
14-17: String to ParticleColor conversion looks goodSimple and effective implementation using the ParticleColor.fromName method.
19-22: ParticleColor to String conversion looks goodThe method correctly extracts the name from the ParticleColor object.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderLazyResult.java (3)
1-8: The imports look good.All the necessary imports are included and properly organized.
9-11: Good class design with clear implementation.The class implements BorderResult interface and uses a list to store lazy-loaded border points. This approach helps with memory efficiency by loading border points only when needed.
17-22: Efficient stream-based collection method.The collect method effectively gathers all border points from lazy suppliers into a single set. The use of unmodifiableSet is good for ensuring immutability of the result.
eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/CauseOfTag.java (4)
4-7: Great documentation for PLAYER.
The comment clearly explains when the PLAYER tag is used.
10-13: Clear explanation for NON_PLAYER.
The updated comment nicely clarifies how non-player interactions apply the combat tag.
16-18: Good documentation for COMMAND.
The comment succinctly outlines when a tag is applied via a command.
21-23: Excellent clarity for CUSTOM.
The detailed comment helps understand custom tagging from external sources.eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/pearl/FightPearlController.java (6)
4-4: Import updated to use the new notification serviceThe import has been updated to use NoticeService instead of the previous notification system.
24-26: Service-based fields updatedField types have been changed to match the new service architecture:
- NoticeService for notifications
- FightPearlService for pearl delay management
This looks good and aligns with the move toward services.
28-32: Constructor updated to use service parametersThe constructor now accepts the new service types, which matches the field changes.
60-64: Improved notification sending with builder patternThe notification code now uses a cleaner builder pattern instead of direct method calls, which makes the code more readable.
68-78: Pearl delay check updated to use service methodsThe pearl delay logic now uses the FightPearlService methods and the builder pattern for notifications. This is more consistent with the new architecture.
82-82: Updated delay marking to use service methodThe delay marking now uses the FightPearlService, which is consistent with other changes.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/impl/PercentDropModifier.java (2)
1-1: Package Declaration Refined.
The package declaration now clearly places this class within thecombat.fight.drop.implstructure, making it easier to understand its role.
3-7: Updated Imports for Consistency.
The imports have been updated to reflect the new package structure. This change improves code organization and ensures that components stay aligned with the recent reorganization.eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/CauseOfUnTag.java (7)
4-7: Great documentation addition!Clear explanation of when the combat tag expires naturally.
9-12: Documentation looks good!Clear explanation of the death-related untag reason.
14-17: Nice documentation!Good distinction between general death and player-caused death.
19-22: Clear documentation!Simple and effective explanation of the logout scenario.
24-27: Good comment!Clearly explains the command-based removal.
29-32: Well documented!Explains the attacker release scenario clearly.
34-37: Good catch-all documentation!Helpful explanation for extensibility with external systems.
eternalcombat-api/src/main/java/com/eternalcode/combat/region/RegionProvider.java (2)
3-3: Added imports look good!The new imports for Collection and World match what's needed for the new method.
Also applies to: 6-6
13-13: Small style update works fineAdding "this." makes it clearer where the method call comes from, but doesn't change what the code does.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightTagImpl.java (4)
1-14: Clean imports and class setup.The class is well-organized with appropriate imports and clear field declarations.
21-34: Methods look good.The getter methods and the
isExpired()check are implemented clearly.
36-45: Nice handling of negative duration.Good defensive coding by returning
Duration.ZEROwhen the combat tag has already expired.
47-51: Experimental feature properly marked.Good use of the
@ApiStatus.Experimentalannotation to indicate this feature might change.eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/FightUntagEvent.java (10)
8-8: Good import addition!Adding the NotNull annotation import helps make your API more robust by providing compile-time null safety.
10-12: Great documentation addition!Adding class-level documentation clearly explains what this event does, making it easier for other developers to understand.
15-15: Nice naming improvement!Changing from
handlerstoHANDLER_LISTfollows Java naming conventions for constants (static final variables).
19-19: Good variable renaming!The change from
isCancelledtocancelledmakes the code more consistent.
22-23: Good constructor update!Explicitly calling
super(false)makes it clear that this event is not asynchronous.
28-35: Great method documentation!Adding clear Javadoc for the
getPlayer()method helps other developers understand what this method returns.
37-44: Helpful documentation!The Javadoc for
getCause()clearly explains what the method returns, including the return type.
46-49: Good variable reference update!Updated to use the renamed
cancelledvariable in theisCancelled()method.
51-54: Good variable reference update!Updated to use the renamed
cancelledvariable insetCancelled()method.
56-60: Good annotation and reference update!Added
@NotNullannotation and updated to useHANDLER_LISTin thegetHandlers()method.eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/controller/FightActionBlockerController.java (9)
5-5: Updated imports reflect the new architectureThe imports have been updated to support the new service-based design and additional functionality. The NoticeService replaces the old announcer, and new imports support the untagging event handling.
Also applies to: 7-9, 11-11
29-29: Field type change and server additionThe announcer field now uses NoticeService instead of NotificationAnnouncer, and a Server field was added to access online players. The constructor was updated to match these changes.
Also applies to: 31-31, 33-33, 37-37
42-42: Updated configuration property referencesBlock placement settings now use the new configuration structure with the dedicated blockPlacement section instead of the old settings structure.
Also applies to: 56-56, 58-58
62-68: Improved notification handlingThe code now uses a fluent API provided by NoticeService instead of direct message sending. This makes the code more readable and consistent with the service-based approach.
Also applies to: 76-82
87-89: Updated block placement check logicThe method now uses the new BlockPlacementSettings.BlockPlacingMode enum for determining if placement is blocked based on Y-coordinate.
94-94: Updated combat settings referencesThe combat-related checks now use the dedicated combat configuration section properties instead of the previous structure.
Also applies to: 114-114, 152-152, 168-168
132-148: Added untagging event handlerNew method that restores flight ability for players in creative or spectator mode when they're untagged. This improves user experience by automatically enabling flying again when appropriate.
181-185: Updated inventory message handlingThe inventory access notification now uses the same fluent API pattern as other notifications, making the code more consistent.
199-199: Updated command restriction logicThe command blocking logic now uses the dedicated commands configuration section and follows the same notification pattern.
Also applies to: 202-202, 208-212
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleSettings.java (4)
1-17: Good imports and package structure!The imports are well-organized and appropriate for the functionality.
18-19: Class setup looks goodThe class extends OkaeriConfig which is perfect for configuration management.
21-36: Well-documented configuration settingsThe comments clearly explain each setting's purpose, which helps users understand how to configure particles.
56-58: Simple and effective utility methodThis null-check helper is clean and reusable.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/impl/PlayersHealthDropModifier.java (4)
1-7: Package and Import Update:
The package declaration and import statements have been updated correctly to reflect the new structure. Great job aligning with the new design!
22-28: Constructor Injection Looks Good:
The constructor cleanly assigns the dependencies. This straightforward injection enhances modularity.
30-33: getDropType Implementation:
This method clearly returns thePLAYERS_HEALTHdrop type, which fits nicely with its intended role.
44-60: Drop Modification Logic:
The health percentage calculation, item adjustment, and experience rounding are implemented cleanly using the utility methods. The logic is simple and easy to follow.eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/controller/FightTagController.java (8)
38-38: Config path updatedUpdated to use
combat.ignoredProjectileTypesinstead ofsettings.disabledProjectileEntities, matching the new config structure.
54-54: Config path updatedUpdated to use
settings.combatTimerDurationinstead ofsettings.combatDurationfor clarity.
58-64: Better code organizationGood move to replace inline checks with the new
cannotBeTaggedmethod. This makes the code easier to read and maintain.
66-66: Config path updatedUpdated to use
combat.disableFlyinginstead ofsettings.shouldPreventFlying, which matches the new naming pattern.
84-84: Config path updatedUpdated to use
combat.enableDamageCauseLogginginstead ofsettings.enableDamageCauseLogging.
96-98: Improved code reuseGood use of the
cannotBeTaggedmethod here as well.
104-105: Config path updatedUpdated damage cause configuration paths to use the
combatnamespace.
137-147: Good method extractionThis new method centralizes the logic for checking if a player can be tagged. It improves readability and reduces duplicate code.
The checks now reference:
admin.excludeCreativePlayersFromCombatfor creative mode playersadmin.excludeAdminsFromCombatfor operatorseternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropSettings.java (2)
1-1: Great Package Update!
The package declaration now fits the new structure for the combat module. Please double-check that all other files referencingDropSettingshave been updated to use this new package.
8-12: Clear and Helpful Comments!
The multi-line comment for drop types explains the options very well. This makes it easier for everyone to understand the design intent.eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleColor.java (1)
7-10: Good implementation of the particle color concept.Nice job defining the ParticleColor class with a RAINBOW constant. The use of the functional interface with the lambda expression is clean.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleController.java (1)
31-36: Good job with dependency injectionClean constructor that takes in all dependencies and sets up the timer task.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/controller/FightUnTagController.java (2)
3-3: Import looks good.
This maintains clarity by referencing the newFightManagerinterface.
37-37: Nice configuration usage.
This condition is straightforward and aligns with the reorganized combat settings.eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/CancelTagReason.java (1)
1-7: Enum addition is clean.
This provides a clear reason for canceling tags.eternalcombat-api/src/main/java/com/eternalcode/combat/fight/FightTag.java (1)
9-21: Interface approach is neat.
This design keeps things flexible and easy to extend.eternalcombat-api/src/main/java/com/eternalcode/combat/fight/FightManager.java (6)
13-13: Nice interface transition
Ensure there’s a proper implementation class taking care of combat logic.
17-17: Looks good
No concerns here.
19-19: Collection return
No issues.
24-24: Simple overload
All good.
26-26: Untag method
Implementation details likely exist elsewhere.
28-28: Bulk untag
No concerns at this time.eternalcombat-api/src/main/java/com/eternalcode/combat/fight/event/FightTagEvent.java (14)
8-8: @NotNull import
Clear indication of non-null usage.
10-12: Helpful Javadoc
Nicely explains the event.
15-15: Constant naming
Matches recommended style.
18-19: Cancellation fields
Straightforward approach.
22-22: Non-async event
Standard usage of super(false).
28-32: getPlayer docs
Clear explanation.
37-41: getCause docs
Well-defined reason reference.
48-48: isCancelled
No issues found.
53-53: setCancelled
Simple and effective.
56-63: getCancelReason
Great for clarity around cancellation.
65-72: setCancelReason
Keeps cancellation logic flexible.
74-74: @NotNull on getHandlers
Good for clarity.
77-77: Handlers getter
Matches typical pattern.
81-81: Static handler list
No concerns.eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/BorderColorUtil.java (1)
5-17: Looks good! Simple utility for color transformations.The utility class correctly implements the non-instantiable pattern with a private constructor. The
xyzToRainbowmethod nicely transforms coordinates into rainbow colors with brightness adjustment based on height (y-value).Consider adding a brief documentation comment to explain the mathematical formula used.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/ChunkLocation.java (1)
3-4: Perfect use of Java record for chunk coordinates.This concise implementation provides all needed functionality for tracking chunk positions.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockSettings.java (5)
7-8: Neat and straightforward class structure.This keeps the configuration clean by extending OkaeriConfig.
9-10: Great default value.Enabling block animation by default is a nice choice for an engaging effect.
12-17: Clear comment for block type.The list of options is helpful, guiding users to pick the right border rendering style.
19-24: Good balance for smooth animation.A default delay of 250 ms seems fine for most scenarios.
26-31: Helpful explanation for chunk cache delay.This encourages users to tune performance based on their system.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BorderBlockController.java (11)
33-45: Tidy class setup.The use of final fields and storing references keeps things organized.
46-57: Constructor scheduling looks good.Running the update task in an async timer is a nice approach for smooth updates without blocking.
59-71: Border show event logic is succinct.It properly updates relevant sets and calls the show method. Looks good!
73-88: Clean handling of hide events.Using the lock prevents concurrency issues when removing and adding blocks.
90-104: Periodic update approach.Removing players who are offline each cycle is a neat detail to keep things tidy.
106-118: Straightforward per-player update.Checks for empty borders and reverts nicely to remove from the update list.
120-124: Efficient chunk-splitting approach.Sending a single multi-block packet per chunk is a great optimization.
134-146: Hide logic mirrors show logic well.This consistency helps maintain clarity.
161-177: Good use of snapshots.This loads chunk data to determine air blocks. Double-check the logic if you invert the filter above.
179-188: Neat grouping by chunk.This method organizes border points by chunk nicely.
190-194: Smart block encoding.Using the settings' type provider to get the final ID is a clean approach.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BorderBlockRainbowUtil.java (6)
13-14: Simple utility class.Declaring it final clarifies it's just a helper class.
15-33: Helpful rainbow glass mapping.Organizing these in a map is very neat and easy to maintain.
34-51: Terracotta mapping is consistent.The approach matches the glass logic, promoting consistency.
53-70: Wool mapping is well-structured.Good variety of dye colors included here.
72-89: Concrete block handling mirrors the rest nicely.This uniform mapping helps with easy expansions later.
91-121: Color-based logic is straightforward.The transformation to nearest dye color keeps everything fun and colorful.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderResult.java (1)
1-9: The interface looks goodNice and clean interface with a single method. It follows good Java practices.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderPoint.java (1)
5-19: Well-structured record implementationThe BorderPoint record is clear and follows good practices. The toInclusive() method is a nice convenience function.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/CommandSettings.java (1)
8-26: Clear configuration class with good documentationThe CommandSettings class is well-structured with helpful comments explaining each option. The default settings seem reasonable for typical gameplay.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/AdminSettings.java (1)
1-20: Clean and well-structured configuration classThis new AdminSettings class looks great! The boolean settings for excluding admins and creative players from combat are clearly defined with helpful comments. The defaults are sensible (false), which means everyone participates in combat by default.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackSettings.java (1)
1-19: Good implementation of knockback configurationThe knockback settings look well-designed! The multiplier has a helpful default (1.0) with clear comments about how it affects gameplay. The 1-second force delay is a reasonable starting value. Nice job with the documentation.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/RegionSettings.java (1)
15-25: Good implementation of region protection settingsThe region settings for PvP and radius restrictions are well-defined and clear. The default values make sense, and the comments explain each option nicely.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropServiceImpl.java (2)
6-12: Good transition to service-oriented designThe class now properly implements the DropService interface, following good design principles. This change aligns with the overall shift toward a service-based architecture in the plugin.
14-37: Appropriate method implementationsThe methods are correctly annotated with @OverRide and maintain their original functionality. The error handling for null or invalid drop types is well implemented.
eternalcombat-api/src/main/java/com/eternalcode/combat/fight/drop/DropKeepInventoryService.java (1)
7-16: Interface looks well-designedThe interface is clear and follows a consistent pattern. Methods are focused on a single responsibility and have descriptive names.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTriggerIndexBucket.java (1)
9-84: Well-implemented spatial indexingThe class provides an efficient way to manage border triggers with good documentation. The bit manipulation is clearly explained, and the spatial indexing logic is sound.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/BlockPlacementSettings.java (1)
8-43: Configuration class looks goodThe settings are well-documented with clear comments and appropriate default values.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/CombatSettings.java (1)
1-75: Well-structured config class with clear documentationThis new configuration class is nicely organized with good documentation for each setting. The comments clearly explain what each option does and provide helpful context for server administrators.
A few points to note:
- Good use of clear boolean names that describe their function
- Sensible default values for each setting
- Well-organized grouping of related settings
- Helpful links to external documentation for enum values
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/MessagesSettings.java (1)
1-101: Clear message organization with good documentationThe main messages section is well-structured with descriptive comments and appropriate default values. Each message includes helpful comments explaining its purpose and any placeholders.
The use of Notice objects with gradient formatting makes the messages visually appealing for players.
buildSrc/src/main/kotlin/eternalcombat-publish.gradle.kts (1)
7-7: Version bump to 2.0.0-SNAPSHOTThe version has been updated to 2.0.0-SNAPSHOT, indicating a major version change. This aligns with the significant refactoring mentioned in the PR description.
buildSrc/src/main/kotlin/eternalcombat-repositories.gradle.kts (1)
8-15: Simplified repository syntax and added CodeMC repoThe repository declarations now use a more concise syntax, and a new CodeMC repository has been added. This simplification makes the build file cleaner and easier to maintain.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderService.java (1)
7-15: Clean interface design!The BorderService interface has a clear purpose with well-named methods that follow good API design principles.
README.md (1)
75-75: Check API version downgradeYou're downgrading the API version from 1.3.3 to 1.3.2 while upgrading the main project to 2.0.0. Is this intentional?
buildSrc/src/main/kotlin/eternalcombat-java.gradle.kts (1)
6-6: Version update looks goodThe version change to 2.0.0-SNAPSHOT matches the PR title and indicates a major update.
.github/workflows/gradle.yml (2)
25-25: Good practice for GitHub ActionsUsing major version tags (v4) helps automatically get minor updates without changing workflow files.
39-39: Good practice for GitHub ActionsSame here - using major version tags simplifies maintenance.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTrigger.java (1)
3-20: Good use of Java records with clear constructor designThe
BorderTriggerrecord is well-structured with a helpful secondary constructor that calculates trigger points based on distance. TheisTriggeredmethod provides a clean way to check if coordinates fall within the trigger area.eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTriggerController.java (3)
14-26: Well-structured dependency injectionGood job using constructor injection to provide all dependencies. This makes the class easier to test and maintain.
28-46: Efficient movement checkThe event handler properly checks if the player has actually changed blocks before processing, which is good for performance.
68-74: Player null check is importantGood practice to check if the player is null before attempting to clear their border.
eternalcombat-api/src/main/java/com/eternalcode/combat/EternalCombatApi.java (2)
3-10: Clean import organizationImports are well-organized with the updated service classes replacing the previous manager classes.
17-25: Consistent interface updatesMethods have been updated to use service interfaces instead of manager classes, maintaining a consistent approach across the API.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderSettings.java (1)
9-39: LGTM! Cleanly designed border configuration.The class correctly extends OkaeriConfig and provides good configuration options for border animations. The comments explain each setting clearly, and the utility methods are well-implemented.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/ConfigService.java (2)
22-48: Well-structured config management implementation.The configuration creation logic properly initializes and loads config files with appropriate serializers.
56-63: Good use of transformer registration.The DefaultSerdesPack correctly registers the custom transformers for specialized types.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackService.java (3)
15-25: Good service implementation with proper dependency injection.The constructor properly initializes the service with its dependencies.
27-29: Simple and effective delayed knockback implementation.The method leverages the scheduler to execute knockback after a specified duration.
49-58: Well-implemented knockback vector calculation.The method correctly calculates the direction away from the center and applies the configured multiplier.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropController.java (2)
1-1: Package reorganization is good.Moving to a more structured package hierarchy improves organization.
48-48: Service method call updated correctly.The call is properly updated to use the new service implementation.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightTask.java (4)
4-5: Nice import additions.
They look clean and necessary for the new logic.
18-18: Good choice to store the NoticeService.
It simplifies notification handling.
20-20: Constructor looks consistent.
Easy to see how it handles the new announcer argument.
45-49: Great streamlined notification usage.
The placeholders make the messages more dynamic.eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackRegionController.java (5)
1-7: Neat package and imports.
Everything is well structured for the new controller class.
19-33: Constructor looks good.
All required services are injected neatly.
35-72: Nice approach to handling movement.
Cancelling movement and scheduling knockback is clear and prevents unintended entry.
74-90: Teleport event handled well.
Blocking entry into regions keeps combat rules consistent.
92-114: On-tag logic is straightforward.
Delaying knockback and notifying the player feels smooth.eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/event/BorderHideAsyncEvent.java (4)
1-9: Class introduction is clear.
Easy to see its purpose as an event.
14-15: Straightforward fields.
Storing the player and points directly fits your performance guidelines.
17-21: Constructor logic is neat.
No extra copying, aligning with project best practices.
31-39: Event handlers and static list look standard.
Follows Bukkit event conventions nicely.buildSrc/src/main/kotlin/Versions.kt (5)
9-9: New dependency added: JetBrains AnnotationsThis adds support for code annotations like
@NotNullwhich helps with code safety.
12-13: Added Multification and Packets Events dependenciesThese new dependencies align with the service-based refactoring. Multification is a notification framework and Packets Events helps with event handling.
16-16: Updated Adventure dependencyReplaced ADVENTURE_TEXT_MINIMESSAGE with ADVENTURE_API, keeping the same version number.
33-33: Added PaperLib dependencyThis dependency helps with cross-version compatibility for Paper servers.
18-18:Details
❓ Verification inconclusive
Updated LiteCommands version
The significant version bump from 2.8.9 to 3.7.0 might require code changes to maintain compatibility.
🌐 Web query:
What breaking changes were introduced in LiteCommands between version 2.8.9 and 3.7.0?💡 Result:
Between versions 2.8.9 and 3.7.0 of LiteCommands, several significant changes were introduced, with the most notable being related to permissions handling, API improvements, and dependency requirements:
Core Infrastructure Changes
- Dependency Requirements: Users must now add the Panda Repository (
https://repo.panda-lang.org/releases) to access LiteCommands artifacts[1][6].- Gradle/Maven Syntax Update: Dependency declarations changed format, requiring explicit platform artifact replacement in
{artifact}placeholders[1][6].API Improvements
- Programmatic Command Registration: Introduced a new builder pattern for dynamic command setup:
this.liteCommands = LiteBukkitFactory.builder("example-plugin") .commands(new HelloCommand()) .build(); [1]- Cooldown API: Exposed a dedicated cooldown management system in v3.9.2[3][6].
- PlatformSender Factory: Added factory patterns for creating platform-agnostic senders[3].
Permission System Overhaul
While the major permissions syntax change arrived in v3.10.0, groundwork began earlier:
- Transitioned from stacked
@Permissionannotations to array-based declarations:// Old (AND behavior) @Permission("admin") @Permission("time.set") // New (v3.7.0+ compatible) @Permission("admin", "time.set") [1][3]- Default permission evaluation changed to OR behavior for unmodified configurations[1].
Validation & Parsing
- Argument Range Validation: Stricter validation for numeric arguments in v3.9.2[3].
- Improved Parser Caches: Enhanced argument parser caching mechanisms in v3.7.1[3][6].
Platform-Specific Fixes
- Fabric Fixes: Resolved
FabricServerSender#getIdentifierissues in v3.9.2[3].- JDA Integration: Added guild-specific command registration support[3][6].
Critical Migration Steps:
- Update build scripts with new repository and dependency syntax
- Convert stacked permissions to array format
- Replace deprecated sender/cooldown implementations
- Add
-parameterscompiler flag for full feature compatibility[1][6]The changes emphasize improved type safety, better platform integration, and more explicit configuration patterns. Developers should review their command classes and build configurations carefully when upgrading[1][3][6].
Citations:
- 1: https://github.com/Rollczi/LiteCommands
- 2: https://www.rcac.purdue.edu/knowledge/biocontainers?all=true
- 3: https://github.com/Rollczi/LiteCommands/releases
- 4: https://packages.debian.org/stable/allpackages
- 5: https://forums.spongepowered.org/t/unofficial-sponge-categorized-plugin-list/12501
- 6: https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/1286593-dynmap-dynamic-web-based-maps-for-minecraft?page=74
- 7: https://www.blackspigot.com/downloads/citizens-2-0-30-pre.24963/
LiteCommands Version Update – Please Verify Migration Changes
The update to LiteCommands 3.7.0 introduces breaking changes that may affect your code. In particular, please double-check the following:
- Build Script Adjustments: You'll now need to add the Panda Repository and update your dependency declaration syntax.
- Permissions Handling: Stacked permissions should be replaced with the new array-based format.
- API Changes: Review usage of command registration, sender, and cooldown APIs for any required updates.
Please review these changes to ensure full compatibility with the new version.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/effect/FightEffectServiceImpl.java (2)
13-17: Good implementation of the effect serviceThe service properly implements the interface and uses a HashMap to store player effects.
18-23: Effect storage implementation looks goodThe method handles adding new player entries to the map when needed.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/EternalCombatReloadCommand.java (2)
16-23: Command setup looks goodThe command is properly configured with permissions and a well-formatted reload message.
32-45: Great implementation of the reload functionalityThe method:
- Uses @async annotation for non-blocking execution
- Measures reload time with a stopwatch
- Provides user feedback
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderTriggerIndex.java (3)
32-36: Simple world iteration methodThis method efficiently iterates through all server worlds to update their borders.
38-55: Border trigger creation logicCreating border triggers asynchronously is a good practice to avoid server lag.
57-61: Smart factory method implementationUsing a static factory method with timer setup is an elegant approach to initialize this service.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/controller/FightMessageController.java (5)
7-7: Updated import to use new notification system.The change to import
NoticeServicealigns with the overall refactoring of the notification system.
17-17: Updated field type to use NoticeService.Field type has been properly updated to match the new notification service pattern.
21-21: Updated constructor parameter.Constructor signature has been simplified by removing the
FightBossBarServiceparameter that's no longer needed.
40-43: Updated notification approach.The new method chain using
create(),player(),notice(), andsend()provides a cleaner approach to sending notifications.
54-58: Consistent use of the notification pattern.The notification pattern is consistently applied here, which is good for code maintainability.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/logout/LogoutController.java (4)
5-5: Updated import to use new notification system.The import has been updated to use the new
NoticeServiceas part of the notification system refactoring.
16-16: Updated field type to use NoticeService.Field type has been properly updated to match the new notification service pattern.
20-20: Updated constructor parameter.Constructor signature has been updated to use the
NoticeServicefor consistency with the new design.
38-42: Updated notification approach with placeholder support.The new pattern allows for placeholders to be used and messages to be sent to all players in a clean way.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderActivePointsIndex.java (5)
10-12: Good class design with thread-safe implementation.This new class is well-structured and uses
ConcurrentHashMapfor thread safety when managing border points.
14-21: Thorough null check implementation.The
hasPointsmethod properly checks if the world registry exists before trying to access it.
23-31: Efficient registry update method.The
putPointsmethod usescomputeIfAbsentto efficiently handle the case where the world registry doesn't exist yet.
33-41: Immutable return value for safety.The
calculateRemovedPointsmethod returns an unmodifiable set, which is a good practice for immutability.
43-50: Consistent null handling.Both
getPointsandremovePointsmethods have consistent checks for null registry and return empty sets when appropriate.Also applies to: 52-64
eternalcombat-plugin/build.gradle.kts (3)
12-58: Comprehensive dependency updates.The added dependencies support the new service-based architecture and provide important functionality for the refactored code.
73-73: Updated Minecraft version.The Minecraft version has been updated from 1.21.1 to 1.21.4 for the run server task.
104-105: Added new package for relocation.The
com.eternalcode.multificationpackage has been added to the list of packages to be relocated in the shadowJar task.eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/knockback/KnockbackOutsideRegionGenerator.java (3)
1-2: File placement looks fine.
Nice to see a dedicated package for knockback logic.
30-59: Watch out for distance = 0.
If the player's location coincides with a generated point, the log function could yield infinity for the weight. This might skew selection unintentionally.
71-91: Check boundary offsets.
Expanding the bounding box by 1 block is likely intentional for safety. Just be sure you want potential out-of-bounds teleportation.eternalcombat-api/src/main/java/com/eternalcode/combat/fight/effect/FightEffectService.java (1)
8-11: Well-documented interface.
The comments clearly explain usage and purpose.eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightManagerImpl.java (3)
21-22: Concurrent map is a good choice.
Well done ensuring thread safety for combat sessions.
39-48: Good event usage in untag.
Publishing and checking cancellation keeps it flexible for other plugins.
55-70: Straightforward tag logic.
Simple approach to handle start and end times with optional tagger. Easy to follow.eternalcombat-api/build.gradle.kts (1)
8-12: Good cleanup of dependencies.The API module has been simplified by removing multiple external dependencies and adding only JetBrains annotations. This makes the API cleaner and more focused.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/config/implementation/PluginConfig.java (2)
13-107: Well-structured configuration class.The main config class organizes all plugin settings into clear, logical sections with helpful comments. Each section is properly initialized with default values.
108-128: Good use of strongly typed configuration.Using Duration for time values and providing default values for all settings makes the configuration more robust and prevents errors.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/drop/DropKeepInventoryServiceImpl.java (2)
1-12: Good service implementation pattern.The class has been properly renamed and now implements a service interface, which is consistent with the move toward a service-based architecture.
16-19: Appropriate method overrides.Methods are correctly annotated with @OverRide and implement the service interface contract.
Also applies to: 21-24, 26-29, 31-40
eternalcombat-plugin/src/main/java/com/eternalcode/combat/fight/FightTagCommand.java (5)
23-34: Good command structure with dependency injection.Command class is well-organized with proper dependency injection through the constructor.
36-50: Clear status command implementation.The status command checks combat state and sends appropriate notifications.
52-75: Tag command handles events properly.Good implementation that checks for cancellation and handles different tag reasons.
125-149: Clean untag command implementation.Good checks for combat status before attempting to untag a player.
151-159: Simple error handler method.Helper method for handling tag cancellation reasons is clean and focused.
eternalcombat-plugin/src/main/java/com/eternalcode/combat/CombatPlugin.java (28)
3-7: Looks great!
New border imports are well organized.
9-17: Neat additions!
These new fight-related imports seem fine.
20-25: All set here!
These new classes for drop and fight logic look consistent.
32-34: Looks fine!
Imports for manager and effect service are good.
38-43: All good!
These new fighting and notification imports are on point.
45-45: No changes found.
49-50: Nice approach!
The new scheduler references look straightforward.
51-52: Neat references!
The Notice and PacketEvents look good.
55-57: Looks good!
Added litecommands imports fit right in.
76-76: Nice addition!
New FightPearlService field is helpful for ender pearl handling.
82-83: Looks handy!
These new drop service fields align with your approach.
92-96: Neat initialization!
Loading PacketEvents in onLoad is a clear approach.
108-108: Good use of scheduler!
This helps with asynchronous tasks.
112-115: Nice logic!
Creating these services during onEnable is neat and tidy.
117-119: All good!
New drop services are set up properly.
131-133: Looks solid!
Using a dedicated border and knockback service is tidy.
134-134: Great addition!
Centralizing notices is user-friendly.
136-138: Good job!
The command framework setup is clean.
140-141: Good improvement!
Custom handlers for invalid usage and missing permission are helpful.
143-147: Clear design!
These commands fit well with the new command framework.
149-153: Nice syntax!
Displaying notices through the command result is neat.
156-156: Great approach!
Scheduling a fight task maintains the combat logic well.
162-163: Smart usage!
Registering drop modifiers is straightforward.
168-168: Nicely organized!
All these controllers are registered in one streamlined step.Also applies to: 170-170, 172-172, 173-173, 175-175, 177-177, 178-178, 179-179, 180-180, 181-181
195-195: Good practice!
Unregistering commands on disable is clean.
203-205: Tidy cleanup!
Ending fights and terminating PacketEvents ensures no leftover data.
218-219: Looks correct!
Returning FightPearlService provides easy access to pearl logic.
233-234: All set!
Exposing DropService is consistent with the plugin's structure.eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/BorderServiceImpl.java (13)
1-2: No issues found.
3-17: Looks fine!
All these imports seem necessary.
19-19: Nice structure!
This class effectively implements BorderService for border updates.
21-28: Neat fields!
They build a clear foundation for border logic and indexing.
29-34: Good constructor!
Dependencies are well injected, ensuring easy setup.
36-65: Looks clear!
Update logic checks existing points, then clears or shows new border points asynchronously.
67-78: Easy to follow!
Clearing border points and triggering events asynchronously is well-structured.
80-83: Good accessor!
Provides a direct way to fetch current border points.
85-98: Neat approach!
Collect triggers into a lazy result. Clean and flexible.
100-170: Straightforward logic!
Calculates border walls efficiently. Nicely done.
172-176: Nice helper!
Simple function to add visible points to the list.
178-180: Clear check!
Distance-based visibility is straightforward and efficient.
182-183: No concerns!
...bat-plugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleColor.java
Show resolved
Hide resolved
...lugin/src/main/java/com/eternalcode/combat/border/animation/particle/ParticleController.java
Show resolved
Hide resolved
...lugin/src/main/java/com/eternalcode/combat/border/animation/block/BorderBlockController.java
Show resolved
Hide resolved
eternalcombat-plugin/src/main/java/com/eternalcode/combat/border/animation/block/BlockType.java
Show resolved
Hide resolved
|
Since the most important work on eternalcombat has been done. i have made the decision to merger it. |
No description provided.