GH-276 Extract bypass conditions to controller class.

[CitralFlo]

Fixes: #276

[gemini-code-assist]

Summary of Changes

Hello @CitralFlo, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refactors the combat tagging system by centralizing the logic for bypassing combat tags. Previously scattered within the FightTagController, these conditions are now consolidated into a new FightBypassController. This change enhances code organization and maintainability, making it easier to manage and extend bypass rules. Additionally, the PR includes updates to various plugin dependencies and introduces LuckPerms, ensuring compatibility and potentially expanding permission-related functionalities.

Highlights

• Refactored Combat Bypass Logic: Extracted combat tag bypass conditions (permissions, admin status, creative mode) into a new FightBypassController class, centralizing this logic for improved modularity.
• Centralized Bypass Reasons: Introduced new PERMISSION_BYPASS, ADMIN, and CREATIVE_MODE enum values to CancelTagReason to explicitly define why a combat tag might be prevented.
• Dependency Updates: Updated the target Minecraft version from 1.21.8 to 1.21.10 and refreshed several plugin dependencies including WorldEdit, PacketEvents, and WorldGuard to their latest versions.
• New Dependency Added: Included LuckPerms as a new dependency, likely to enhance permission handling capabilities within the plugin.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively refactors the combat tag bypass logic by extracting it into a new FightBypassController class. This is a good improvement for code organization and separation of concerns. It also appears to fix a bug where bypass permissions were not consistently applied. I have one suggestion for the new controller to prevent potential logic fall-through and make the code more robust.

[CitralFlo]

@gemini-code-assist suggest better names for this class that match project structure and features in the class

[gemini-code-assist]

Hello @CitralFlo,

That's a great question! The current name FightBypassController is quite descriptive of the class's function, which is to control the bypassing of combat tags. However, you've rightly pointed out the need to match the project structure.

Looking at the existing project structure, classes that act as event listeners and end with Controller (e.g., FightTagController, FightUnTagController, FightActionBlockerController) are typically located in the com.eternalcode.combat.fight.controller package. Your new FightBypassController is currently in com.eternalcode.combat.fight.

To better match the project structure, I would suggest the following:

1. Move FightBypassController to com.eternalcode.combat.fight.controller: This is the most direct way to align with the existing package structure for event-handling classes. The current name FightBypassController would remain appropriate in this location.

If you are looking for alternative names while still maintaining consistency with its role as an event listener, here are a couple of options:

2. CombatTagBypassController: This name is slightly more explicit by including "CombatTag" instead of just "Fight", making its purpose even clearer. It still uses the Controller suffix, fitting the pattern for event listeners, and would ideally be placed in the com.eternalcode.combat.fight.controller package.

3. CombatTagBypassHandler: Using Handler as a suffix is also common for event listeners and clearly indicates that this class handles the logic for bypassing combat tags. This could also be placed in the com.eternalcode.combat.fight.controller package.

My primary recommendation would be to move the existing FightBypassController to the com.eternalcode.combat.fight.controller package. If you prefer a slightly different name, CombatTagBypassController or CombatTagBypassHandler are good alternatives that maintain clarity and consistency.

[Pawelusze]

good job 👍

[Jakubk15]

^ Other than that looks good to me