Wurst7 Add AutoPlaceHack

※ I recreated #1048 because I used the wrong branch, sorry.

Description

Added a simple but cool feature, AutoPlace. This hack allows you to free up your right middle finger when bridging, as it will place the blocks for you when you need to.

When it's enabled, blocks will be placed as long as you aim at side faces of blocks.

Testing

It's working, here's the video _{Don't complain about my aiming though, I'm using a very bad mouse right now}

Notes

😎 I've applied spotless to match the original coding style.

🤔 Not sure if I need to disable some other hacks like ScaffoldWalk when this hack is turned on?

Aug 09 '24 17:08 LilyKensa

📝 Walkthrough

Walkthrough

The changes introduce several new features and modifications across multiple classes in the WurstClient Minecraft mod. A new AutoPlaceHack class has been added for automating block placement, along with instance variables in HackList to integrate this functionality. Additionally, new filtering classes for teammates and NPC-like entities have been introduced, enhancing entity filtering capabilities. The PlayerEspHack now disables teamEspHack when enabled, and various settings have been added or modified in existing hacks to improve user control and gameplay experience.

Changes

File Path	Change Summary
`src/main/java/net/wurstclient/hack/HackList.java`	Added variables `public final AutoPlaceHack autoPlaceHack` and `public final TeamEspHack teamEspHack`.
`src/main/java/net/wurstclient/hacks/AutoPlaceHack.java`	Introduced class `AutoPlaceHack` with methods `onEnable()`, `onDisable()`, and `onUpdate()`, and settings for block placement.
`src/main/java/net/wurstclient/hacks/AimAssistHack.java`	Added `CheckboxSetting onlyHoldingWeapon` to restrict aiming functionality to when a weapon is held.
`src/main/java/net/wurstclient/hacks/AutoReconnectHack.java`	Added `CheckboxSetting buttons` for toggling button visibility on the reconnect screen, and method `shouldShowButtons()`.
`src/main/java/net/wurstclient/hacks/PlayerEspHack.java`	Added logic to disable `teamEspHack` when `PlayerEspHack` is enabled.
`src/main/java/net/wurstclient/hacks/SafeWalkHack.java`	Introduced `SliderSetting minDepth` and `motionPrediction`, and modified `onClipAtLedge` method signature.
`src/main/java/net/wurstclient/hacks/TeamEspHack.java`	Added class `TeamEspHack` for rendering team indicators with customizable settings.
`src/main/java/net/wurstclient/hacks/TriggerBotHack.java`	Added `ItemListSetting blacklistedItems` to prevent trigger bot activation with certain items.
`src/main/java/net/wurstclient/mixin/ClientPlayerEntityMixin.java`	Added multiple event injections and modified movement and item use handling.
`src/main/java/net/wurstclient/mixin/DisconnectedScreenMixin.java`	Updated logic for displaying auto-reconnect buttons based on user settings.
`src/main/java/net/wurstclient/settings/filterlists/EntityFilterList.java`	Enhanced `genericCombat` method with additional filters for teammates and NPCs.
`src/main/java/net/wurstclient/settings/filters/FilterNpcLikeSetting.java`	Introduced class `FilterNpcLikeSetting` for filtering NPC-like entities.
`src/main/java/net/wurstclient/settings/filters/FilterTeammatesSetting.java`	Introduced class `FilterTeammatesSetting` for filtering teammates based on display name color.

📜 Recent review details

Configuration used: CodeRabbit UI Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between d4b624e0a22f9240d6f7036cf97d961b923598de and 40778be7dc8106332248d5b7a929c2b3fbcec8ed.

⛔ Files ignored due to path filters (2)

src/main/resources/assets/wurst/translations/en_us.json is excluded by !**/*.json
src/main/resources/assets/wurst/translations/zh_tw.json is excluded by !**/*.json

📒 Files selected for processing (15)

gradle.properties (1 hunks)
src/main/java/net/wurstclient/WurstClient.java (1 hunks)
src/main/java/net/wurstclient/hack/HackList.java (2 hunks)
src/main/java/net/wurstclient/hacks/AimAssistHack.java (5 hunks)
src/main/java/net/wurstclient/hacks/AutoPlaceHack.java (1 hunks)
src/main/java/net/wurstclient/hacks/AutoReconnectHack.java (2 hunks)
src/main/java/net/wurstclient/hacks/PlayerEspHack.java (1 hunks)
src/main/java/net/wurstclient/hacks/SafeWalkHack.java (4 hunks)
src/main/java/net/wurstclient/hacks/TeamEspHack.java (1 hunks)
src/main/java/net/wurstclient/hacks/TriggerBotHack.java (5 hunks)
src/main/java/net/wurstclient/mixin/ClientPlayerEntityMixin.java (2 hunks)
src/main/java/net/wurstclient/mixin/DisconnectedScreenMixin.java (1 hunks)
src/main/java/net/wurstclient/settings/filterlists/EntityFilterList.java (1 hunks)
src/main/java/net/wurstclient/settings/filters/FilterNpcLikeSetting.java (1 hunks)
src/main/java/net/wurstclient/settings/filters/FilterTeammatesSetting.java (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

src/main/java/net/wurstclient/hack/HackList.java

🧰 Additional context used

🪛 ast-grep

src/main/java/net/wurstclient/hacks/SafeWalkHack.java

[warning] 29-33: Detected a cookie where the Secure flag is either missing or disabled. The Secure cookie flag instructs the browser to forbid sending the cookie over an insecure HTTP request. Set the Secure flag to true so the cookie will only be sent over HTTPS. Context: ( "Motion prediction", "Predict your motion to sneak earlier.\n" + "If not stopping at edges, increase; If not stopping near a wall, decrease.", 2.0, 1, 5, 0.5, ValueDisplay.DECIMAL.withSuffix("x")) Note: [CWE-614]: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute [OWASP A05:2021]: Security Misconfiguration [REFERENCES] - https://owasp.org/Top10/A05_2021-Security_Misconfiguration

[warning] 29-33: Detected a cookie where the HttpOnly flag is either missing or disabled. The HttpOnly cookie flag instructs the browser to forbid client-side JavaScript to read the cookie. If JavaScript interaction is required, you can ignore this finding. However, set the HttpOnly flag to true` in all other cases. Context: ( "Motion prediction", "Predict your motion to sneak earlier.\n" + "If not stopping at edges, increase; If not stopping near a wall, decrease.", 2.0, 1, 5, 0.5, ValueDisplay.DECIMAL.withSuffix("x")) Note: [CWE-1004]: Sensitive Cookie Without 'HttpOnly' Flag [OWASP A05:2021]: Security Misconfiguration [REFERENCES] - https://owasp.org/Top10/A05_2021-Security_Misconfiguration

🔇 Additional comments (23)

gradle.properties (3)

8-8: Verify compatibility with Minecraft 1.21

The Minecraft version has been updated from 1.21.1 to 1.21. This change aligns with the PR objectives.

Please ensure that all features of the mod are compatible with Minecraft 1.21. You may want to run comprehensive tests to confirm full functionality.

9-9: LGTM: Yarn mappings updated

The Yarn mappings have been updated to 1.21+build.9, which is consistent with the Minecraft version change and likely includes more up-to-date mappings.

16-16: LGTM: Mod version updated

The mod version has been correctly updated to reflect the new Minecraft version (1.21). This change is consistent with the other updates in this file.

src/main/java/net/wurstclient/settings/filters/FilterTeammatesSetting.java (4)

1-9: LGTM: Class declaration and package structure are appropriate.

The FilterTeammatesSetting class is correctly placed in the net.wurstclient.settings.filters package. The class is declared as public final, which is good for immutability. Extending EntityFilterCheckbox suggests it's part of a larger entity filtering system, which aligns with the purpose of the class.

36-40: LGTM: Well-designed static factory method for combat scenarios.

The genericCombat method is a well-implemented static factory method. It provides a convenient way to create a combat-specific FilterTeammatesSetting instance with a clear and accurate description.

42-47: LGTM: Consistent design with genericCombat method.

The genericVision method is well-implemented and follows the same pattern as genericCombat. This consistency in design is commendable. The method provides a convenient way to create a visibility-specific FilterTeammatesSetting instance with a clear and accurate description.

1-47: Summary: Well-implemented teammate filter supporting PR objectives.

The FilterTeammatesSetting class is a solid implementation of a teammate filter based on display name color. It provides convenient factory methods for combat and vision scenarios, which aligns well with the PR objectives of enhancing entity filtering capabilities. This class will support features like the new AutoPlaceHack by providing a way to filter teammates during gameplay.

The implementation is generally sound, with thorough null checks and clear logic. The suggested optimizations, such as caching the player's color and using a constant for the filter name, could further improve its performance and maintainability.

Overall, this new class is a valuable addition to the codebase and contributes positively to the goals of this pull request.

src/main/java/net/wurstclient/hacks/AutoReconnectHack.java (3)

14-14: LGTM: Import statement added correctly.

The new import for CheckboxSetting is necessary and properly placed with other import statements.

34-34: LGTM: New setting correctly added to the hack's configuration.

The buttons setting is properly added to the hack's settings in the constructor, ensuring it's included in the configuration.

Line range hint 1-48: Overall assessment: Well-implemented feature addition.

The changes to AutoReconnectHack successfully introduce a new user preference for controlling the visibility of the reconnect button. This enhancement aligns well with the PR objectives and improves user experience by providing more control over the UI.

Key points:

New CheckboxSetting for button visibility.

Proper integration of the new setting into the hack's configuration.

Clean interface method for accessing the visibility preference.

The implementation is clean, well-documented, and integrates smoothly with the existing code. Great job!

🧰 Tools

🪛 ast-grep

[warning] 26-27: Detected a cookie where the Secure flag is either missing or disabled. The Secure cookie flag instructs the browser to forbid sending the cookie over an insecure HTTP request. Set the Secure flag to true so the cookie will only be sent over HTTPS. Context: ("Wait time", "Time before reconnecting in seconds.", 5, 0, 60, 0.5, ValueDisplay.DECIMAL.withSuffix("s")) Note: [CWE-614]: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute [OWASP A05:2021]: Security Misconfiguration [REFERENCES] - https://owasp.org/Top10/A05_2021-Security_Misconfiguration

[warning] 26-27: Detected a cookie where the HttpOnly flag is either missing or disabled. The HttpOnly cookie flag instructs the browser to forbid client-side JavaScript to read the cookie. If JavaScript interaction is required, you can ignore this finding. However, set the HttpOnly flag to true` in all other cases. Context: ("Wait time", "Time before reconnecting in seconds.", 5, 0, 60, 0.5, ValueDisplay.DECIMAL.withSuffix("s")) Note: [CWE-1004]: Sensitive Cookie Without 'HttpOnly' Flag [OWASP A05:2021]: Security Misconfiguration [REFERENCES] - https://owasp.org/Top10/A05_2021-Security_Misconfiguration
src/main/java/net/wurstclient/settings/filterlists/EntityFilterList.java (2)
65-66: Clarify the relationship between entity filtering changes and AutoPlace feature.

The additions to the genericCombat() method enhance the entity filtering capabilities of the mod. However, the connection between these changes and the AutoPlace feature mentioned in the PR objectives is not immediately clear.

Could you please clarify:

How do these new filtering options relate to the AutoPlace feature?

Are these changes part of a broader update to the mod's combat system?

Do these filters affect the behavior of AutoPlace when it's active?

Understanding these relationships will help ensure that the changes are consistent with the overall goals of the PR.

65-66: Verify impact and update documentation for new filtering options.

The addition of teammate and NPC-like entity filters enhances the combat-related filtering capabilities. This change might affect other parts of the codebase that use the genericCombat() method.

Please run the following script to check for potential impacts:

Consider updating the class or method documentation to reflect these new filtering options, explaining their purpose and default behavior.

✅ Verification successful

Impact of New Filtering Options Verified

The addition of FilterTeammatesSetting and FilterNpcLikeSetting enhances combat filtering across the following classes:

TriggerBotHack.java

TpAuraHack.java

MultiAuraHack.java

KillauraHack.java

FightBotHack.java

ClickAuraHack.java

BowAimbotHack.java

TeamEspHack.java

AimAssistHack.java

No unintended impacts were found on other parts of the codebase. Please ensure that the class or method documentation is updated to reflect these new filtering options.
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Description: Check for usages of genericCombat() method and potential impacts

# Search for usages of genericCombat() method
echo "Searching for usages of genericCombat() method:"
rg "genericCombat" --type java

# Search for references to FilterTeammatesSetting and FilterNpcLikeSetting
echo "\nSearching for references to new filter settings:"
rg "FilterTeammatesSetting|FilterNpcLikeSetting" --type java
Length of output: 3350
src/main/java/net/wurstclient/hacks/PlayerEspHack.java (1)
80-80: Approve change, but clarification needed on teamEspHack interaction.

The addition of WURST.getHax().teamEspHack.setEnabled(false); is a good way to prevent potential conflicts between PlayerEspHack and teamEspHack. However, I have a few points to consider:

Could you please clarify the rationale behind disabling teamEspHack when PlayerEspHack is enabled? This interaction isn't mentioned in the PR objectives.

Have you considered a more flexible approach? For example:

Adding a setting that allows users to choose whether teamEspHack should be disabled automatically.

Implementing logic to make these hacks work together harmoniously instead of disabling one.

It might be helpful to add a comment explaining why teamEspHack is being disabled, to improve code maintainability.

To ensure this change doesn't introduce any unintended side effects, please run the following verification script:

✅ Verification successful

Change Verified

The teamEspHack is only being disabled within PlayerEspHack.java, and no other interactions or dependencies affect it elsewhere in the codebase. This ensures that the change is isolated and does not introduce unintended side effects.
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Description: Check for any other interactions between PlayerEspHack and teamEspHack

# Test: Search for other mentions of teamEspHack in PlayerEspHack
echo "Searching for other mentions of teamEspHack in PlayerEspHack:"
rg "teamEspHack" src/main/java/net/wurstclient/hacks/PlayerEspHack.java

# Test: Search for mentions of PlayerEspHack in teamEspHack
echo "Searching for mentions of PlayerEspHack in teamEspHack:"
rg "PlayerEspHack" src/main/java/net/wurstclient/hacks/TeamEspHack.java

# Test: Check if there are any other hacks that disable teamEspHack
echo "Checking for other hacks that disable teamEspHack:"
rg "teamEspHack.setEnabled$false$" src/main/java/net/wurstclient/hacks/
Length of output: 788
src/main/java/net/wurstclient/hacks/AimAssistHack.java (3)

15-18: LGTM: New imports added correctly.

The new imports for AxeItem, Item, and Items are necessary for the added functionality and follow the existing import style.

71-72: LGTM: Entity filters updated appropriately.

The addition of FilterTeammatesSetting and FilterNpcLikeSetting to the entityFilters initialization enhances the entity filtering capabilities as intended. The default values and placement in the list are appropriate.

Line range hint 1-238: Overall assessment: Changes are well-implemented and align with PR objectives.

The modifications to the AimAssistHack class successfully introduce the new onlyHoldingWeapon feature and improve entity filtering capabilities. The code is well-structured, and the new functionality is integrated seamlessly with the existing implementation. The minor suggestions provided earlier will further enhance code readability and maintainability.
src/main/java/net/wurstclient/WurstClient.java (1)
54-54: LGTM: Minecraft version update.

The change from "1.21.1" to "1.21" for the MC_VERSION constant is consistent with the update mentioned in the PR objectives for the gradle.properties file. This update appears to be part of a broader effort to align the project with a specific Minecraft version.

To ensure consistency across the codebase, please run the following script:

✅ Verification successful

Verified: Minecraft version update is consistent across the codebase.

All references to version "1.21.1" have been successfully updated to "1.21". The changes in gradle.properties and WurstClient.java are consistent with the project’s objectives. Comments referencing "1.21" in other files pertain to bug tracking and historical context, which are appropriate and intentional.
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Description: Verify Minecraft version consistency across the codebase.

# Test 1: Check for any remaining references to version 1.21.1
echo "Checking for remaining references to version 1.21.1:"
rg "1\.21\.1" --type java --type gradle --type properties

# Test 2: Verify that all relevant files now reference version 1.21
echo "Verifying references to version 1.21:"
rg "1\.21(?!\.)" --type java --type gradle --type properties

# Note: Review the output to ensure all occurrences are intentional and consistent.
Length of output: 577

Script:
#!/bin/bash
# Description: Verify Minecraft version consistency across the codebase.

# Define a custom type for .properties files
rg --type-add 'properties:*.properties'

# Test 1: Check for any remaining references to version 1.21.1
echo "Checking for remaining references to version 1.21.1:"
rg --pcre2 "1\.21\.1" --type java --type gradle --type properties

# Test 2: Verify that all relevant files now reference version 1.21
echo "Verifying references to version 1.21:"
rg --pcre2 "1\.21(?!\.)" --type java --type gradle --type properties

# Note: Review the output to ensure all occurrences are intentional and consistent.
Length of output: 847

Script:
#!/bin/bash
# Description: Verify Minecraft version consistency across the codebase.

# Test 1: Check for any remaining references to version 1.21.1
echo "Checking for remaining references to version 1.21.1:"
rg --type-add 'properties:*.properties' --pcre2 "1\.21\.1" --type java --type gradle --type properties

# Test 2: Verify that all relevant files now reference version 1.21
echo "Verifying references to version 1.21:"
rg --type-add 'properties:*.properties' --pcre2 "1\.21(?!\.)" --type java --type gradle --type properties

# Note: Review the output to ensure all occurrences are intentional and consistent.
Length of output: 911
src/main/java/net/wurstclient/settings/filters/FilterNpcLikeSetting.java (1)

16-22: :warning: Potential issue

Clarify the filtering logic for player names not matching criteria

The current implementation filters out entities based on specific name characteristics, such as name length and character composition. However, returning true in these cases may not align with the intended filtering behavior. Please confirm that returning true is intended to include the entity when it doesn't match the NPC-like criteria.

To verify the behavior, check how the test method is used in the context of EntityFilterCheckbox and ensure that the return values correctly reflect whether an entity should be filtered out or not.
src/main/java/net/wurstclient/hacks/TriggerBotHack.java (1)
158-159: Verify that "minecraft:air" correctly represents an empty hand

When the player's main hand is empty, the item is represented as Items.AIR. Ensure that "minecraft:air" is the correct identifier returned by Registries.ITEM.getId(Items.AIR).toString(). If not, the blacklist check for an empty hand may not work as intended.

Run the following script to confirm that "minecraft:air" is the correct item name for an empty stack:
✅ Verification successful

"minecraft:air" correctly represents an empty hand

The verification process confirms that "minecraft:air" is indeed the correct identifier used to represent an empty hand in the codebase. This is evidenced by the following code snippet from src/main/java/net/wurstclient/hacks/TriggerBotHack.java:
if(stack.isEmpty())
{
    if(blacklistedItems.getItemNames().contains("minecraft:air"))
        return;
}
This code checks if the player's hand is empty (stack.isEmpty()), and then verifies if "minecraft:air" is in the blacklisted items. This implementation correctly uses "minecraft:air" to represent an empty hand, validating the original implementation.

The use of Registries.ITEM.getId(Items.AIR).toString() is not explicitly found in the codebase, but the consistent use of "minecraft:air" across different parts of the code (including nuker settings and base finder configurations) further supports its correctness.
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Description: Verify the item ID for an empty hand (Items.AIR)

# Test: Get the registry ID of Items.AIR
# Expected output: minecraft:air
echo "Item ID for Items.AIR:"
ast-grep --pattern $'Registries.ITEM.getId(Items.AIR)' *.java --json | jq '.captures[0].name'
Length of output: 273

Script:
#!/bin/bash
# Description: Locate all Java files and verify the item ID for an empty hand (Items.AIR)

# Find all .java files in the repository
java_files=$(fd --extension java)

if [ -z "$java_files" ]; then
  echo "No Java files found in the repository."
  exit 1
fi

echo "Verifying the item ID for Items.AIR in the following files:"
echo "$java_files"

# Search for the pattern in all found Java files and extract the item ID
ast-grep --pattern 'Registries.ITEM.getId(Items.AIR)' $java_files --json | jq '.captures[0].name'
Length of output: 180446

Script:
#!/bin/bash
# Description: Locate and verify the item ID for an empty hand (Items.AIR)

# Find all .java files in the repository
java_files=$(fd --extension java)

if [ -z "$java_files" ]; then
  echo "No Java files found in the repository."
  exit 1
fi

echo "Searching for 'Registries.ITEM.getId(Items.AIR)' in the following files:"
echo "$java_files"

# Search for the pattern with flexible whitespace and display matching lines with 2 lines of context
rg -C 2 'Registries\.ITEM\.getId\s*$\s*Items\.AIR\s*$\.toString\s*$\s*$' $java_files
Length of output: 180401

Script:
#!/bin/bash
# Description: Search for references to Items.AIR and related empty hand checks

echo "Searching for references to Items.AIR:"
rg -C 2 'Items\.AIR' src/main/java

echo -e "\nSearching for potential empty hand checks:"
rg -C 2 'getStack\.isEmpty' src/main/java

echo -e "\nSearching for 'minecraft:air' string:"
rg -C 2 '"minecraft:air"' src/main/java
Length of output: 3499
src/main/java/net/wurstclient/hacks/TeamEspHack.java (2)
78-78: Verify the disabling of playerEspHack when TeamEspHack is enabled

In the onEnable() method, playerEspHack is automatically disabled:
WURST.getHax().playerEspHack.setEnabled(false);
Please confirm if this behavior is intentional. If both hacks should not be active simultaneously, consider informing the user when one hack disables another, or adjusting the UI to prevent them from being enabled at the same time.

103-103: Question the necessity of the Y-coordinate filtering condition

At line 103, there's a filter that limits players based on the Y-coordinate difference:
.filter(e -> Math.abs(e.getY() - MC.player.getY()) <= 1e6);
Given that the vertical build limit in Minecraft is much less than 1,000,000 blocks, this condition might be unnecessary or could be replaced with a more meaningful threshold. If there isn't a specific reason for this large value, consider removing it to simplify the code.
src/main/java/net/wurstclient/mixin/ClientPlayerEntityMixin.java (2)

273-273: Integration of SafeWalk functionality into clipAtLedge method looks good

The addition of || WurstClient.INSTANCE.getHax().safeWalkHack.shouldClip(); correctly ensures that the clipAtLedge() method accounts for the status of the SafeWalk hack.

286-286: Correct invocation of SafeWalk's onClipAtLedge within adjustMovementForSneaking

The call to safeWalkHack.onClipAtLedge() inside adjustMovementForSneaking properly allows the SafeWalk hack to adjust player movement when movement is not null.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ 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 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.

Aug 09 '24 17:08 coderabbitai[bot]

This pull request has been open for a while with no recent activity. If you're still working on this or waiting for a review, please add a comment or commit within the next 7 days to keep it open. Otherwise, the pull request will be automatically closed to free up time for other tasks.

Pull requests should be closed if:

They have been superseded by another pull request
They are out of scope or don't align with the project
They have become obsolete due to other changes
They have bugs or conflicts that won't be resolved

Oct 14 '24 02:10 github-actions[bot]

wait a min did i just done something very stupid again

Oct 20 '24 14:10 LilyKensa

wait what i didn't do that merge

Oct 20 '24 14:10 LilyKensa

bro no way, every time I think "oh I finally learned how to use git" it just slaps me in the face and says "no you don't"

Oct 20 '24 14:10 LilyKensa

This pull request has been open for a while with no recent activity. If you're still working on this or waiting for a review, please add a comment or commit within the next 7 days to keep it open. Otherwise, the pull request will be automatically closed to free up time for other tasks.

Pull requests should be closed if:

They have been superseded by another pull request
They are out of scope or don't align with the project
They have become obsolete due to other changes
They have bugs or conflicts that won't be resolved

Dec 20 '24 02:12 github-actions[bot]

Add AutoPlaceHack

Description

Testing

Notes

Walkthrough

Changes

Chat

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

CodeRabbit Configuration File (.coderabbit.yaml)

Documentation and Community

CodeRabbit Configuration File (`.coderabbit.yaml`)