cabaletta / baritone Goto Github PK
View Code? Open in Web Editor NEWgoogle maps for block game
License: GNU Lesser General Public License v3.0
google maps for block game
License: GNU Lesser General Public License v3.0
An addition to the chunk caching system: whenever an inventory is opened, store its coordinates, type, and contents in the caching system.
This is just a feature I need for myself, basically /pathToAndOpenClosestChestContaining minecraft:leather
Ideally, some of the values that you are unsure of we can optimize. We can do this assuming we have a good test path and speed up the tick speed of Minecraft. I think the easiest way is just to have a random search with early stopping. The hardest part of this is just overfitting to the test path.
I would be interested in implementing this, but I need a list of all tunable values.
Even a short path cuts my framerate in half, can't really explain why. Well not quite in half, but significant drop. Like 60 to 45.
they dont work
I just put it as the same as water but that was a guesstimate. How fast do you actually walk on soul sand?
They don't work
We jump ourselves, and it messes up MovementDiagonal edging around blocks (it jumps on top because it thinks we want to, for example if we were edging around magma this would cause us to take damage and lose the path, and continue to take damage while recalculating)
Should add a check to make sure the door is wood.
Right now if you tell it to cancel
while it's calculating a path, it will be completely ignored.
For example, during a path it might be interesting to see which movement types consistently underestimated vs overestimated how many ticks they would take.
Also, I think a warning of when the onTick handler took more than X milliseconds would be helpful, same for renderFrame (but in nanoseconds).
they dont work
Files which are easily testable and require unit tests:
it's not COST_INF but it should be
I just guessed you'd jump after 0.5 blocks of walking but that isn't accurate. What should the cost really be for movementascend?
Would this affect behavior at all?
Right now there's a tick of inaction between when one path ends and the next begins. You can see this where it stops sprinting for a second in the recordings. We should do something akin to how PathExecutor jumps to the next Movement in the same tick that the previous one finishes, maybe recursively in the same way.
Related to #29
Currently the API can give you the ticks remaining in the current path segment fairly accurately, by summing up the freshly recalculated costs of the remaining movements.
This could be easily extended to the planned next path.
However, for longer distance paths this doesn't work, as the segments aren't calculated yet. How can we give an ETA of the entire thing, from start to goal, even if it isn't calculated yet?
I'm considering something like: goalHeuristic(currentPos) * ticksElapsedSoFar / (goalHeuristic(startPos) - goalHeuristic(currentPos))
For future features, a map should be generated not unlike Dynmap in 2D mode that is cached, to allow for cool visualizations and the likes.
Perhaps it should be a little more complicated than just rendering every subcomponent of the goal... or maybe that should just be it
There are two applications of this:
While doing long distance pathing, some blocks are better than others. Right now, anything that is canWalkOn
is stored as SOLID
, however that doesn't capture things like magma, soul sand, etc. Storing the locations of those alongside might be beneficial. This is somewhat mitigated by path trimming to loaded chunks (it will already avoid the first part of the soul sand / magma patch, and when it plans the next segment it'll avoid the next) but it isn't great because it can get trapped in corners and stuff. (see #18)
Valuable blocks. For example, /pathToAndRightClickNearest minecraft:ender_chest
. Obvious reasons. We should store the locations of:
Only mob spawners spawn commonly from this list, but they're interesting enough that I think it's no big deal to keep them. Uncommon natural spawns include brewing stands in igloos and end ships, loot chests in nether fortresses, strongholds, villages, etc, End portals in strongholds, furnaces in villages and igloos.
Right now it just looks at the destination and holds W, it should instead consider looking away and holding S if close enough. Basically, something like MovementManager.moveTowardsCoords
from MineBot: https://github.com/leijurv/MineBot/blob/master/mcp918/src/minecraft/minebot/movement/MovementManager.java#L136
Right now, every Movement just expects that the player is standing in src
. However when things get screwed up that isn't the case. And there are some really crappy heuristics that it uses. For example traverse jumps when its Y level is below what it expects it to be even though that's NOT its job. Instead of canceling the path if it's been more than 2 blocks away for more than 5 seconds, it should immediately cancel it when the player is off the path. This also helps if the real player is trying to take over (like if there's a mob) and doesn't want to type cancel, they can divert away from the path.
For example, while under fire resistance, path through lava. Maybe even detect fire resistance potions on hotbar and use them.
Walking is 4.63 ticks per block, and sprinting is 3.56.
If sprinting is allowed, any heuristic greater than 3.56 is an overestimate.
The default is 3.5 right now.
However, if you can't sprint, this is such an underestimate that pathing becomes practically very difficult and almost Dijkstra-like.
It should be 3.5 when sprinting is possible, and 4.6 otherwise.
Possibly? Maybe we could analyze what blocks it would power. For example, a pressure plate that just opens a door is fine, but one that goes to a line of redstone should probably be avoided.
Currently, block hardness calculation (in ToolSet.java) does this:
// Set the best slot
player().inventory.currentItem = slot;
// Calculate the relative hardness of the block to the player
float hardness = state.getPlayerRelativeBlockHardness(player(), world(), pos);
// Restore the old slot
player().inventory.currentItem = oldSlot;
This is bad because your hotbar flickers all around while pathing, and there's a race condition where if you really set your hotbar currentItem while pathing in the other thread in between these instructions it could get a wildly inaccurate result.
This isn't an issue with Baritone pathing per se... but if you set a 10k block path, leave your computer, and come back, you might be surprised to discover that it brought you to your destination, but your destination was in an ocean, and the moment the path ended it stopped floating and you drowned.
Perhaps if a path ends in water it should continue floating until some keyboard input is detected?
Worth implementing?
Right now its COST_INF, it should instead be sqrt(2)*SNEAK_ONE_BLOCK_COST and during execution it should know to sneak over magma to avoid damage.
Follow-up issue (to #15): if it's bucket falling onto ground, and there's a torch on that ground, it'll never actually place the bucket because torches have a real hitbox (unlike bushes) and it would place above.
I think the check should be converted from any kind of raytrace to a simple right click hold starting when the ground it's intending to hit should be within range.
It should be able to walk on top of them, but recognize it can't do so in a 2 high space, and recognize it can't jump onto them from the ground. This might be more trouble than it's worth.
Currently there's no way to clear the goal (set it to null).
Perhaps it should even look at what food items are currently in their inventory, for how many blocks of sprinting is reasonable?
Probably not really necessary, but cool!
It should be able to right click and open them just like doors
For example, decide whether end rods and flower pots should really be canWalkThrough since they do collide (even in a small way).
Should we make shulker boxes canWalkOn even though they expand when opened?
In general, should canWalkOn's bounding box check be changed to only do the Y coordinate? Or maybe something smarter...
Should anvils be canWalkOn?
Should grass_path and farmland be canWalkOn?
Should glass be canWalkOn?
Magma should probably be a separate check due to the sneaking cost, it's good that it's not canWalkOn
Basically, it breaks the lower sand, which causes the stack to fall. In this time, they're falling entities, so the blocks are actually AIR. It thinks "oh i'm done breaking time to jump up" and does. It gets slightly into the falling space, but in then pushed back. However, while it's glitched into the falling sand stack, it calls the movement over and goes onto the next one.
It should
Right now, if playerFeet
intersects with any position of next
, it jumps immediately onto that path. This is fine and good if, for example, next
begins with a bit of a backtrack of current
, you'll never end up executing those redundant parts at all and can skip to what happens next on next
.
However, it doesn't always backtrack the same way. A few times I've seen it make a big loop where it goes ~10 blocks diagonal into a corner, then next
moves one block to the side and goes all the way back. It never intersects with next
but it's really really close and should totally just jump on it.
A duct tape patch solution would be to calculate all movement costs from playerFeet
and if any of them intersect with next
, take it... but that only applies to a gap of 1 block.
A more interesting solution would be to have more than one start
node in the A* pathfinding. Normally, you start off by setting one node (your start node) to be 0 cost and adding it to your open set, then starting the graph search loop from there. I wonder if it would be possible to set the blockpos of every node in current
to be 0 cost while calculating next
. That way it would get the current full path, but be able to jump off it anywhere it wants instead of just at the very end. And with the goal heuristic combined cost in the openset selection process, it would (most of the time) end up just popping off the end node first (because it has the lowest goal heuristic, because current and next were calculated with the same goal), and running from there. So it wouldn't have any negative impact on normal splicing with no backtracking, but would allow more efficient backtracking.
So the TODO is figure out if this would have any negative impacts or gotchas that I'm not thinking of, and to try it out.
This might tie in with #20
I'm thinking both small scale (almost like unit tests) and large scale.
Small scale would be like "in this scenario of blocks, this movement should be COST_INF". However, that would be really time-consuming to create for not much benefit. I think larger scale integration-style tests give way more bang for you buck (the amount of functionality it tests vs how time consuming it is to write).
Perhaps something like "can the bot path from 0,0 to 1000,1000 in a world generated from seed _____ within X minutes without taking damage?"
it raytraces and thinks it's looking at bushes so it doesn't place the water
When falling, the bot will take a high jump and fail to cushion its fall with water if the bottom block is something like a shrub.
This is most likely because the block is considered "passable" when calculating the cost for the path, however, the raytrace fails to hit the actual desired block and instead says it can't be seen.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.