cabaletta / cabaletta/baritone

Automatically detect protected areas

Open
#220 3 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Java
Stars
9.2k
Forks
2.1k
Avg merge
4d 3h
Merged PRs (30d)
3

Description

I'm not sure if there's another issue for this already.

When you break or place a block, and the server immediately sends a restoration packet, mark that. Maybe something like a `HashMap, Integer>` where you go from a chunkX, chunkZ to the number of times that a break or place has failed in that chunk, in this run of the client. And this doesn't refer to a movement timing out and failing, it refers to the block breaking or placing successfully and then being removed by the server. Once this count reaches, say, 30, we could mark that chunk as unbreakable and unplacable for, say 15 minutes. We should also separately turn off allowBreak and allowPlace for, say, 1 minute, because it's likely neighboring chunks might be protected too and then we can skip the whole process of waiting for a break to fail 30 times, and instead just breeze right through on an alternate route. And if turning off allowBreak and allowPlace makes the next chunk impassable, then it's just a 1 minute delay in the path.

There is a glitchy thing where ascend tries to place a throwaway for it to immediately jump on, and it appears and disappears a few times fast before it actually backs up and places it properly, we should account for that.

Also we need to detect what's just low tps and what's actually a protected area.

Also, oh god, water bucket falling.... oh god. what if it's your first time in the chunk and you don't know if it's protected or not and you try and water bucket fall but it doesn't work lollollol.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by tracing the client’s block break/place handling, restoration packets, chunk tracking, and the ascend placement path. Determine how to distinguish protected-area failures from low TPS and transient placement glitches. Done means the behavior, thresholds, cooldowns, and interactions with allowBreak and allowPlace are specified and covered by tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
game-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.