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
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<Tuple<Integer, Integer>, 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.
The text was updated successfully, but these errors were encountered:
CalculationContext still decides whether or not we can break or place, but now it has the coordinate in question and can use that to decide.
Maybe like a ProtectedAreasManager or something? Like once we detect a re-placement we just say ProtectedAreasManager.notifyBreakOrPlaceFailure(int x, int y, int z) and it would increment that chunk. Then CalculationContext could call ProtectedAreasManager.mightBeProtected(int x, int y, int z) and it would look up that chunk and if we failed in that chunk 30 times within the last 15 minutes, return true, or if we hit our failure count within the last minute, return true regardless of chunk. Or something like that.
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<Tuple<Integer, Integer>, 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.
The text was updated successfully, but these errors were encountered: