Crafting tables put into turtle GUI do not immediately create turtle.craft

[Kan18]

Minecraft Version

1.20.x

Version

1.105.0 - latest SwitchCraft version (cc-tweaked-1.20.1-fabric-1.105.0-ebaf49508f5147ac4169c915dfcd964f7dd946b8)

Details

If a turtle is booted up without a crafting table attached, and then a crafting table is put into its upgrade slots via the GUI, the turtle API will still have a nil value of turtle.craft, resulting in the need to reboot the turtle to recreate the function.

This seems to be because the turtle ROM API, which is responsible for adding the turtle.craft function, only checks for the presence of the crafting table whenever equipLeft or equipRight is called. Using the GUI upgrade slot bypasses this check, however.

A few solutions I was thinking of:

• make turtle.craft always exist and have it return false if there is no workbench, like turtle.attack or turtle.dig does; this would break backwards compatibility if any programs did if turtle.craft
• handle adding turtle.craft on the Java side somehow
• since the workbench addition generates a peripheral event, add a turtle workbench checker to the bios parallel call
• set a metatable on the turtle API table to check for a workbench if turtle.craft is indexed

[SquidDev]

A secret fifth option:

• Deprecate turtle.craft, and encourage people to use the peripheral directly.

[dimaguy]

Yet another secret sixth option, allow turtle.craft() with a 2x2 grid, and have the workbench extend it to 3x3, like how it is with players.

Deprecating turtle.craft sounds like a good idea though

[Lemmmy]

Yet another secret sixth option, allow turtle.craft() with a 2x2 grid

Changing gameplay mechanics doesn't fix this bug

[dimaguy]

Yet another secret sixth option, allow turtle.craft() with a 2x2 grid

Changing gameplay mechanics doesn't fix this bug

You're right, it doesn't. I was merely giving out a suggestion giving this part of the code is being revisited