Directional Support for turtle.place

[PeenDev]

Added support for the following parameters in the turtle.place function.

north, south, east, west these are self explanatory.

face_up, and face_down are for things like dispensers, though you can also use it for something like a modem for example.

left, right, up, down just calculate the cardinal direction relative to the turtles facing direction.

top, bottom for things like slabs

ground for things like torches when you don't want to place them against a wall

upside_down for stairs

you can pass multiple for example turtle.place("upside_down", "north")

if it cant resolve the orientation, cant apply them to a block, or no parameters are passed it falls back to the previous placement logic so nothing should change for existing programs.

Directionality seems to be handled differently by different sets of blocks for some reason.

logs use axis, shulkers use facing, furnaces use horizontal facing, modems use their own enum, stairs use half, slabs use type
tried to account for all the variation, there may be a better way feel free to discuss.

Happy to accept criticism or pointers! Thanks!

[SquidDev]

Thank you so much for PR! Especially all the tests — it's relaly, really appreciated! Apologies for taking so long to look at this — laptop died on me, so haven't been able to run Minecraft for the past few weeks :/.

When this was first discussed in #204, I did have some worries about how many edges cases we'd have to handle here. I think this is definitely better than I was expecting, but there are always going to be edge cases. I wonder if there should be an API method to register the block-state transforms (e.g. ComputerCraftAPI.registerOrientationProvider(Block, BiFunction<BlockState, OrientationParameters, BlockState>).

A couple of other smaller thoughts:

• I'm in mixed minds about the cardinal direction specifiers (north, south, etc...). CC:T generally tries to avoid using any absolute positions. However, block states are a bit of a special case, as they're available with turtle.inspect().

  My instinct is to remove them, but happy to discuss further!

• The relative directions are sometimes flipped. Doing turtle.place("left") with a monitor, turtle or dispenser ends up placing a block facing to the right. Wired modems do face the right way, so I suspect they're inconsistent in some annoying way :/.

• I wonder if we could merge some of the other specifiers? e.g. upside_down and up; bottom and ground.

• There's some ambiguity here whether turtle.place("left") on a sign should place a sign with the text "left", or place a sign facing to the left. I wonder if it we should instead have turtle.place accept a table, so you do turtle.place { facing = { "left" } (also accepting a sign_place argument, so you can do turtle.place { facing = { "left", "ground" }, text = "hello!" }).

  As part of this, it probably makes sense to do the parsing when the TurtleAPI function is called, and just pass the orientation/text parameters to the place command.

[PeenDev]

Hey thanks for the review!

• Yeah I had initially done the cardinal direction placements and then thought it wouldn't be that helpful without already knowing the direction you're facing so I implemented the relative direction. I am happy to remove the cardinal direction placements- though I don't feel the same instinct about removing them, getting the turtle to resolve its direction is pretty simple and can be done multiple ways, but again happy to remove it!

• as far as the placement inconsistencies I think its a different understanding of "left", the way I interpreted it was not "facing" it was simulating as if the turtle had clicked the "left" block, this seemed like a more consistent way to handle it to me. (though the turtle placement is one that doesn't work how you would expect if you place it yourself in game)

• Yeah some of the specifiers can be merged, I think I just got caught up in all the edge cases I added more than needed, I'll clean that up. I do think that "ground" should stay though or we could flip it and have it default to placing on the ground and instead have a parameter that places it against the wall (toches, lightning rod, end rod)

• had not even considered a sign, thats a great callout I will make the appropriate changes!