Automata Core do not use turtle's heading as fake player's direction

[ZeekDaGeek]

Describe

When using the .digBlock() function of the Automata core it doesn't break blocks from the side that the turtle would be interacting with. As an example this is a problem when using tools that dig 3x3 or 5x5 areas.

It should also be noted that the .digBlock() function has one extra reach when it breaks blocks which is inconsistant with vanilla ComputerCraft .dig() where the block has to be against the turtle's nose.

Steps to reproduce

1. Make turtle.
2. Equip Automata Core.
3. Give a hammer that digs larger sizes.
4. lua
5. auto = peripheral.wrap("left")
6. auto.digBlock()

Multiplayer?

No

Version

1.18.2-0.7.23r

Minecraft, Forge and maybe other related mods versions

Minecraft 1.18.2 - Forge 40.1.92

Screenshots or Videos

https://clips.twitch.tv/VastZanyAardvarkNinjaGrumpy-GOCZDA493yvF-eLB

Crashlog/log

No response

[SirEdvin]

Well, digBlock is supposed to emulate player left click, so extra range is fine, I guess..

[ZeekDaGeek]

I was unaware that digBlock was supposed to be the generic left click action, some things to consider when making digBlock the defacto left click.

Sometimes you want to emulate a simple left click. eg. Turtle touching monitors without breaking them. Swinging swords without breaking blocks. Using tools that have left click actions in general, and some that can be accessed with a shift left click if your fake player can access them.

Possibly a use case for adding automata.swing(shift)?

digBlock having one extra reach compared to vanilla dig means you can't drop it into programs that are designed around only having one range.

Example: Lets say you found a script on the ComputerCraft forums and you wanted it to have silktouch with your fancy Automata upgrade, The script digs a zig zag through a wall.

-- Start
-- #########
-- #########
-- #########
-- #########

-- Desired
-- #####  ##
-- ####  ###
-- ###  ####
-- ##  #####
while true do
  turtle.dig()
  turtle.forward()
  turtle.turnRight()
end

If you're attempting to upgrade a program that doesn't account for empty spaces all of a sudden the zigzag would break extra blocks if runs into a hole.

-- Start
-- #########
-- #########
-- ### #####
-- #########
-- uh oh
-- #####  ##
-- ###   ###
-- ###  ####
-- ##  #####

For a small program retrofitting in an extra detect before every dig isn't too bad, but for large programs it's definitely a bigger problem when two dig functions don't work the same.

[SirEndii]

Currently thinking about how I could do that without a breaking change
Something like an optional parameter would be the best, I guess

I also found a bug(?) where some "harder" blocks do not get destroyed instantly.
Tested with an iron pickaxe and an iron block. The block only gets destroyed after the second time digBlock gets called
Not sure if Edvin made that on purpose - but I need to look into that

[SirEdvin]

The most of this logic comes from original Plethora logic. So, Plethora has logic that tries to care about tool performance (harded block mines faster with better tools), I migrated this code as much as I can.

But in any case, you can just change this method in way that you would think will be best. This also the reason, why this will not work for retrofitting, it was supposed to be used in pair with look method.

digBlock having one extra reach compared to vanilla dig means you can't drop it into programs that are designed around only having one range.

In my case it was designed to retrofit into plethora code, I hope.

Something like an optional parameter would be the best, I guess

I guess, you can just add optional "mode" parameter

[zyxkad]

for the parameter, maybe is the yaw and pitch relative to the heading?

[zyxkad]

dup IntelligenceModding/Advanced-Peripherals-Features#43