Open rom1504 opened 9 years ago
related to #256 ?
proposed API : bot.placeBlock(referenceBlock, faceVector [, cursorPos]) with cursorPos being {top:true} or {top:false} (or BlockFace.BOTTOM and BlockFace.TOP but how to implement that ?) Are top and bottom really the only possibilites ? What do they correspond to cursor wise ? (which is currently default to 8,8,8 ?) What would be the default value ?
It's also needed to figure out a test case for which the current implementation doesn't work, and then to test the new implementation fixes it. (stairs ?)
cursorPos
and lookingDirection
== faceVector
are two independent properties. You can look up and place a slab at the top half of a block, but also look up and place a slab at the bottom half of it.
lookingDirection
is already a parameter. But cursorPos
is not.
Title should be "Make placeBlock cursor position more flexible"
Right, I changed that.
It seems the direction the stair is placed is somehow dependant to where the bot is looking at.
Need to figure out how this work before this issue can be fixed. (be able to place a stair in all the possible ways)
22:33 < rom1504> any clue how does stair placement can be done ? is it related to the cursors in http://wiki.vg/Protocol#Player_Block_Placement ? 22:36 <+Thinkofdeath> its a combination of your position relative to the block and the cursor position (if I remember right) 22:38 <+Dinnerbone> It should be the "cursor position" (we call it sub block position), it's the position on the face of the block you clicked.
direction = 0
means upside-down, as you place below the reference blockdirection = 1
means "upside-up", as you place above ref blockdirection >= 2
(placing on a side of the reference block), cursor_y = 0
means "upside-up", 15
means upside-downWith that in mind, placing stairs in all 8 directions is possible without cursor_pos
. But placing blocks mid-air might be denied in future versions, so allowing all possible cursor_pos
values might be more future-compatible.
yeah so cursor_pos should be available as an optional parameter.
Then a second function, in mineflayer or not could take metadata to figure out the correction direction (for example http://minecraft.gamepedia.com/Data_values#Stairs ). The data on http://minecraft.gamepedia.com/Data_values#Stairs should be in minecraft-data.
The angle data is available in the block state files (see https://github.com/PrismarineJS/minecraft-data/issues/18 )
It's currently hard coded to 8,8,8 (see https://github.com/andrewrk/mineflayer/blob/master/lib/plugins/inventory.js#L248)
For example useful for stairs