NoShieldOverlay

[ThisTestUser]

Lowers the shield in the offhand when blocking and when idle to prevent it from blocking the screen.

Summary by CodeRabbit

• New Features
  • Introduced a new NoShieldOverlayHack feature allowing players to adjust shield overlay visibility and position when blocking or not blocking in-game.

[github-actions]

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

[Alexander01998]

Still relevant. Potential implementation of https://wurstforum.net/d/215.

[coderabbitai]

Walkthrough

The update introduces a new feature to a Minecraft mod that allows players to adjust the position of the shield overlay when blocking or not blocking. This enhancement includes the addition of a new hack, corresponding settings, and modifications to the item rendering system to apply these adjustments in real-time during gameplay.

Changes

File Path	Change Summary
.../hack/HackList.java	Added NoShieldOverlayHack global variable to manage the new shield overlay feature.
.../hacks/NoShieldOverlayHack.java	Created new class with settings for shield position adjustment when blocking and not blocking.
.../mixin/HeldItemRendererMixin.java	Added methods to adjust shield position during rendering based on blocking state.

🐰 In the midst of fall, with leaves underfoot, 🍂
A shield tweak slides in, with a soft, silent hush.
No more shall the overlay clutter our sight,
For the rabbits have coded, and made it just right. 🛡️✨

---

Tips

Chat with CodeRabbit Bot (@coderabbitai)

• If you reply to a review comment from CodeRabbit, the bot will automatically respond.
• To engage with CodeRabbit bot directly around the specific lines of code in the PR, mention @coderabbitai in your review comment
• Note: Review comments are made on code diffs or files, not on the PR overview.
• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Note: For conversation with the bot, please use the review comments on code diffs or files.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• The JSON schema for the configuration file is available here.
• 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/coderabbit-overrides.v2.json

[coderabbitai]

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between e7f60fe and ad7f189.

Files ignored due to filter (2)

• src/main/resources/assets/wurst/lang/en_us.json
• src/main/resources/wurst.mixins.json

Files selected for processing (3)

• src/main/java/net/wurstclient/hack/HackList.java (1 hunks)
• src/main/java/net/wurstclient/hacks/NoShieldOverlayHack.java (1 hunks)
• src/main/java/net/wurstclient/mixin/HeldItemRendererMixin.java (1 hunks)

Additional comments: 7

src/main/java/net/wurstclient/hack/HackList.java (1)

• 138-144: The addition of NoShieldOverlayHack to the HackList class is consistent with the pull request's goal of introducing a new feature to the Wurst Client. This change registers the new hack within the mod's system, allowing it to be accessed and used like the other existing hacks.

Ensure that the NoShieldOverlayHack class is properly implemented and follows the conventions and structure of the other hack classes in the codebase. Also, verify that the hack is being initialized and managed correctly within the game's lifecycle.

src/main/java/net/wurstclient/hacks/NoShieldOverlayHack.java (4)

• 1-45: The introduction of the NoShieldOverlayHack class appears to be well-structured and follows Java coding conventions. The class is correctly placed within the net.wurstclient.hacks package and includes appropriate imports and settings.

• 18-23: The slider settings nonBlockingOffset and blockingOffset are well-named and include descriptive tooltips for the user. The range and step values seem reasonable, but it would be important to ensure that these values provide a good user experience and that the shield can be adjusted to a position that is both useful and visually appealing.

• 25-31: The constructor for NoShieldOverlayHack is straightforward and correctly sets the category and adds the settings to the hack. This is a good use of the constructor to initialize the hack's properties.

• 33-42: The adjustShieldPosition method is concise and only performs the shield position adjustment if the hack is enabled. The use of the MatrixStack to translate the shield position is appropriate for rendering transformations in Minecraft. The check for whether the player is blocking to determine which offset to apply is logical.

Overall, the code is clean, and there are no apparent issues with logic, security, performance, or maintainability. The use of clear naming conventions and the organization of the code should make it easy to maintain and understand.

src/main/java/net/wurstclient/mixin/HeldItemRendererMixin.java (2)

• 1-50: The mixin implementation for HeldItemRendererMixin seems to be correctly structured, following the conventions of SpongePowered's Mixin framework for Minecraft modding. The @Inject annotations are used to inject custom code into the renderFirstPersonItem method of the HeldItemRenderer class at specific points (denoted by the @At annotations with ordinal values to specify the exact injection points).

The methods lowerShieldBlocking and lowerShieldNonBlocking are designed to adjust the shield's position based on the player's blocking state, which is determined by the hand parameter and the type of item held. The calls to WurstClient.INSTANCE.getHax().noShieldOverlayHack.adjustShieldPosition(matrices, true/false) are used to apply the actual position adjustments, with the boolean parameter indicating whether the player is blocking.

It's important to ensure that the ordinal values used in the @At annotations correctly correspond to the intended injection points in the renderFirstPersonItem method after any updates to the game or the HeldItemRenderer class, as these values are dependent on the method's bytecode and can change with updates.

Additionally, the mixin does not seem to directly modify any fields or methods in the target class, which is a good practice to avoid conflicts with other mods that might also be modifying the same class.

Overall, the code appears to be correct and should function as intended if the ordinal values are accurate and the WurstClient.INSTANCE.getHax().noShieldOverlayHack.adjustShieldPosition method is implemented correctly.

• 48-49: This conditional check ensures that the shield position is only adjusted when the player is holding a shield in the off-hand and is not blocking. This is a good example of defensive programming, ensuring that the mixin only affects the game behavior when the specific conditions for the feature are met.