Skip to content

Add auto-select mode to nuker #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from

Conversation

arvi18
Copy link

@arvi18 arvi18 commented Apr 16, 2025

Type of change

  • Bug fix
  • New feature

Description

Added a new whitelist mode 'AutoSelect'. It can just select the block you are looking at when active.
This is convenient when using keybind to mine specific blocks and also can be switched through activation.

Related issues

Mention any issues that this pr relates to.

How Has This Been Tested?

It works on my local test.

Checklist:

  • My code follows the style guidelines of this project.
  • I have added comments to my code in more complex areas.
  • I have tested the code in both development and production environments.

Summary by CodeRabbit

  • New Features
    • Added an "AutoSelect" mode to the Nuker module, allowing automatic targeting of the block type currently under the player's crosshair.
  • Improvements
    • Enhanced block selection logic for more flexible block breaking based on the selected mode.

@gandalf-repo
Copy link

@coderabbitai full review

Copy link

coderabbitai bot commented Apr 16, 2025

✅ Actions performed

Full review triggered.

Copy link

coderabbitai bot commented Apr 16, 2025

Warning

Rate limit exceeded

@visz11 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 8 minutes and 11 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between a548ee7 and 692621f.

📒 Files selected for processing (1)
  • src/main/java/meteordevelopment/meteorclient/systems/modules/world/Nuker.java (6 hunks)

Walkthrough

The Nuker module was updated to introduce a new ListMode option called AutoSelect. This mode enables the module to automatically target and break only the block type currently under the player's crosshair when the module is activated. The implementation includes a new private field to store the selected block type, logic to set and clear this field on activation and deactivation, and updated block filtering to utilize this new mode. Additionally, a public getter for the selected block was added, and the ListMode enum was extended to include AutoSelect.

Changes

File(s) Change Summary
src/main/java/meteordevelopment/meteorclient/systems/modules/world/Nuker.java Added AutoSelect to ListMode, introduced autoSelectBlock field, updated activation/deactivation logic, modified block filtering, added getAutoSelectBlock() method, and made minor formatting changes.

Sequence Diagram(s)

sequenceDiagram
    participant Player
    participant NukerModule

    Player->>NukerModule: Activate (with ListMode = AutoSelect)
    NukerModule->>Player: Get block under crosshair
    NukerModule->>NukerModule: Set autoSelectBlock
    loop OnTickPre event
        NukerModule->>NukerModule: Check block matches autoSelectBlock
        alt Match
            NukerModule->>NukerModule: Break block
        end
    end
    Player->>NukerModule: Deactivate
    NukerModule->>NukerModule: Clear autoSelectBlock
Loading

Poem

In the world of blocks, a new trick to detect,
Nuker now learns to AutoSelect!
With a glance of your eye, it knows what you seek,
Breaking just that, week after week.
A bunny hops by, with a wink and a cheer—
“Precise destruction is finally here!”
🐰✨


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.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@visz11
Copy link
Collaborator

visz11 commented Apr 23, 2025

@coderabbitai full review

Copy link

coderabbitai bot commented Apr 23, 2025

✅ Actions performed

Full review triggered.

@arvi18
Copy link
Author

arvi18 commented Aug 1, 2025

/refacto-test

Copy link

refacto-test bot commented Aug 1, 2025

Refacto is reviewing this PR. Please wait for the review comments to be posted.

Copy link

refacto-test bot commented Aug 1, 2025

Solid Implementation - Address Critical AutoSelect Mode Issues

Review Summary

This PR adds a useful AutoSelect mode to the Nuker module with generally good implementation quality. The feature allows automatically targeting specific block types and follows existing patterns. However, our analysis identified several important issues that need addressing before merging, primarily around error handling when no block is targeted during activation. The module currently continues activation even when autoSelectBlock is null, which could lead to unexpected behavior, potential null pointer exceptions, and wasted computational resources.

Well Done!!!

  • Excellent implementation of AutoSelect mode that provides a useful new feature for automatically targeting specific block types
  • The code properly initializes and cleans up the autoSelectBlock field in onActivate and onDeactivate methods
  • The implementation follows a consistent pattern with the existing ListMode options and maintains compatibility

Files Processed

src/main/java/meteordevelopment/meteorclient/systems/modules/world/Nuker.java 187-495

📌 Additional Comments (3)

Security Enhancement

Lack of Continuous Validation in AutoSelect Mode

Explanation: The AutoSelect mode sets the target block only once at activation and lacks a mechanism to update or validate the selected block during operation. If the user mistakenly selects the wrong block type or wants to change the target during operation, there's no way to do so without deactivating and reactivating the module. This could lead to unintended block destruction if the user forgets which block type was initially selected.

switch (listMode.get()) {
                        case AutoSelect -> {
                            if (autoSelectBlock == null || !blockState.getBlock().equals(autoSelectBlock))
                                return;
+ // Add at the beginning of onTickPre method, before any other code
+ if (listMode.get() == ListMode.AutoSelect && mc.options.keyUse.isPressed()) {
+     HitResult hitResult = mc.crosshairTarget;
+     if (hitResult != null && hitResult.getType() == HitResult.Type.BLOCK) {
+         BlockPos pos = ((BlockHitResult) hitResult).getBlockPos();
+         autoSelectBlock = mc.world.getBlockState(pos).getBlock();
+         info("Updated auto-select block to: " + autoSelectBlock.getName().getString());
+     }
+ }
References

Standard: CWE-20: Improper Input Validation
Standard: OWASP Top 10 2021: A04 - Insecure Design

---

Maintainability Enhancement

Missing Documentation for AutoSelect Mode

Explanation: The new AutoSelect mode is added to the ListMode enum but lacks documentation explaining its purpose and behavior. This reduces code readability and makes it harder for other developers to understand how this mode differs from Whitelist and Blacklist modes without reading the implementation details.

public enum ListMode {
    Whitelist,
    Blacklist,
    AutoSelect
+ /**
+  * Defines how the Nuker module selects blocks to break
+  */
+ public enum ListMode {
+     /** Only break blocks in the whitelist */
+     Whitelist,
+     /** Break all blocks except those in the blacklist */
+     Blacklist,
+     /** Break only blocks of the same type as the initially targeted block */
+     AutoSelect
References

Standard: Java Code Conventions - Documentation Comments, Clean Code Principles - Self-Documenting Code

---

Maintainability Enhancement

Field Declaration Placement Reduces Cohesion

Explanation: The autoSelectBlock field is placed in the middle of setting declarations rather than grouped with other state fields. This reduces code cohesion by separating related state fields and makes the code structure less organized. Fields that represent module state should be grouped together to improve code organization and readability.

private Block autoSelectBlock = null; // Internal field to store the selected block for AutoSelect mode
+ // Fields to track module state
+ private Block autoSelectBlock = null; // Internal field to store the selected block for AutoSelect mode
References

Standard: Clean Code Principles - Code Organization, Java Code Conventions - Class Structure

---

Comment on lines +273 to +280
if (listMode.get() == ListMode.AutoSelect) {
HitResult hitResult = mc.crosshairTarget;
if (hitResult != null && hitResult.getType() == HitResult.Type.BLOCK) {
BlockPos pos = ((BlockHitResult) hitResult).getBlockPos();
autoSelectBlock = mc.world.getBlockState(pos).getBlock();
} else {
autoSelectBlock = null;
warning("No block is being targeted for auto-select mode.");
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing Validation for AutoSelect Block Target

The AutoSelect mode initializes the target block only once when the module is activated, but does not validate that a block is successfully selected before allowing the module to run. If no block is targeted during activation (autoSelectBlock is null), the module will still be enabled but won't break any blocks, potentially confusing users. More critically, if the module is activated with no block in sight and then the user looks at a block, the module will remain ineffective without any clear indication of the problem.

if (listMode.get() == ListMode.AutoSelect) {
    HitResult hitResult = mc.crosshairTarget;
    if (hitResult != null && hitResult.getType() == HitResult.Type.BLOCK) {
        BlockPos pos = ((BlockHitResult) hitResult).getBlockPos();
        autoSelectBlock = mc.world.getBlockState(pos).getBlock();
        info("Auto-selected block: " + autoSelectBlock.getName().getString());
    } else {
        autoSelectBlock = null;
        error("No block is being targeted for auto-select mode. Please look at a block and try again.");
        this.toggle(); // Disable the module if no block is targeted
        return; // Exit early
    }
}

References

Standard: CWE-754: Improper Check for Unusual or Exceptional Conditions
Standard: OWASP Top 10 2021: A08 - Software and Data Integrity Failures

Comment on lines +409 to +412
switch (listMode.get()) {
case AutoSelect -> {
if (autoSelectBlock == null || !blockState.getBlock().equals(autoSelectBlock))
return;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potential NullPointerException in Block Selection Logic

The AutoSelect mode implementation checks if autoSelectBlock is null or doesn't match the current block, but there's no safeguard against autoSelectBlock being null during module operation. While the onActivate method attempts to initialize it, there could be cases where it remains null (e.g., if the target block changes after activation). This could lead to unpredictable behavior or crashes when the module is running.

                        case AutoSelect -> {
                            if (autoSelectBlock == null) {
                                error("Auto-select block is null. Disabling module.");
                                toggle();
                                return;
                            }
                            if (!blockState.getBlock().equals(autoSelectBlock))
                                return;
                        }

References

Standard: Design by Contract - Precondition Validation

Comment on lines +409 to +410
switch (listMode.get()) {
case AutoSelect -> {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Redundant Block Type Checking in AutoSelect Mode

The AutoSelect mode performs an equality check on every block in range, which is inefficient. For large ranges, this can result in thousands of object equality comparisons per tick. The current implementation also doesn't handle the case where autoSelectBlock is null efficiently, as it will still iterate through all blocks in range before determining none match.

                        case AutoSelect -> {
                            // Skip all processing if no block is selected
                            if (autoSelectBlock == null) return;
                            // Use == for faster reference comparison before equals()
                            if (blockState.getBlock() != autoSelectBlock && !blockState.getBlock().equals(autoSelectBlock))
                                return;

References

Standard: Java Performance Best Practices - Object Comparison Optimization

@arvi18 arvi18 closed this Aug 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants