You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Players could lockpick containers they could already open because the shipped debug setting skipped the access check. Normal container lockpicking now always applies the same single/double chest access rules as opening, including owner, public, guild, faction and staff access. The separate staff test command remains available, and the config comment clarifies that the old debug option now applies only to displays.
Validation: tfmc-mvn -o -B --no-transfer-progress clean verify passed 1,028 tests with zero failures, errors or skips and all 100% coverage gates. Includes 24 new access/debug regression cases; eight Python rollback tests, report validation and runtime JAR validation also passed. Sol review found no actionable issues.
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.
📝 Summary
Summary by CodeRabbit
Bug Fixes
Lockpicking is now denied when you already have access to a container, including both halves of a double chest. These attempts stop before clues or the lockpicking challenge.
Documentation
Clarified that display lockpick testing applies only to display locks; use /thievery testpick for containers.
Lockpicking now stops when a player can already access the target container. The check applies regardless of the debug setting and accounts for both halves of a double chest. Tests cover access rules and confirm that later lockpicking operations do not run.
Changes: Container lockpicking
Layer / File(s)
Summary
Accessible-container check and test coverage src/main/java/net/tfminecraft/thievery/door/ContainerManager.java, src/test/java/net/tfminecraft/thievery/door/ContainerManagerTest.java, src/main/resources/config.yml
The access check rejects lockpick attempts when the player can access a single container or both halves of a double chest. Parameterised tests cover access types and both debug settings. The config comment directs container lockpick testing to /thievery testpick.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size:XS0-9 effective changed lines (tests excluded in mixed PRs).
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Players could lockpick containers they could already open because the shipped debug setting skipped the access check. Normal container lockpicking now always applies the same single/double chest access rules as opening, including owner, public, guild, faction and staff access. The separate staff test command remains available, and the config comment clarifies that the old debug option now applies only to displays.
Validation:
tfmc-mvn -o -B --no-transfer-progress clean verifypassed 1,028 tests with zero failures, errors or skips and all 100% coverage gates. Includes 24 new access/debug regression cases; eight Python rollback tests, report validation and runtime JAR validation also passed. Sol review found no actionable issues.