Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am reviewing my progress with programming a ComputerCraft Turtle to craft like items together for repair purposes. Let’s get started.<\/p>\n
The program I spent my week putting together is supposed to:
\n1. Make sure its environment is good.
\n2. Ensure it is working with matching, non-stackable items with durability.
\n3. Reject items that don’t work.
\n4. Craft valid items together.
\n5. Accept like new items once they are mended.
\n6. Be able to handle being unloaded and restarted from any state.<\/p>\n
I started out with my code, building up the lower level bits and moving on to the higher lever functionality. Whenever I had a question on how something was supposed to work, I quickly made a tiny program on another computer to test the syntax or output format.<\/p>\n
I designed my virtual workstation around this philosophy, and ended up with a main computer with a large screen on one side for viewing code at once, and a disk drive on the other where I save all my programs. Other computers, almost always turtles (robots), can also access the disk drive, and since I can’t properly test my turtle program on anything but a turtle, I end up saving my program from the larger terminal and testing it on a turtle attached to “A_drive” (Named for the in-game representation of a floppy disk drive). Later in the debug phase, I ended up building an even bigger monitor and using a network cable. I logged another avatar in and pulled the keyboard over so I could edit with a little more area than the advanced computer.<\/p>\n
As I went, I had new ideas on how to do things, and do them better. But toward the end, those ideas were a little too low level to implement, so I just shelved them. Bug testing is important, especially when your program is intended for deployment on a fleet of identical systems and you don’t have an “update all” option. I eventually finished my program and started bug testing. An attempt to call nil proved to be a typo in a function name, in this case a lower case ‘i’ as in getitem() where the function was named in camel case: getItem().<\/p>\n
One of the methods of making a good program is doing it over again once you’ve finished it. I learned that lesson when another bug popped up where it shouldn’t have. It turns out the function, turtle.craft(), needs a little more babysitting than I gave it credit for. I never really understood this low-level function, but knew it could pull off amazing feats if controlled properly. The documentation said it could craft any item as if on a regular crafting table, but extra items present in the recipe were okay. I understood my bug when I made a tiny test program to tell me if things could be crafted at that moment or not. The turtles’ inventory is a 4×4 grid and a crafting table is 3×3. But turtle.craft() apparently doesn’t like it when things in the inventory can’t be fit into the crafting table’s smaller area when is called to try and craft something.<\/p>\n
The next step is to reprogram what I already have, as stated above. This time, though, I want to have that tighter leash on turtle.craft(). While I’m at it, I intend to implement a low-level error code to make maintenance of the system a little easier.<\/p>\n
Final Question: This LootRepair program is the most complex program in the suite of programs for my mob farm automation. What features should I include in a future release if I ever publish this program?<\/p>\n","protected":false},"excerpt":{"rendered":"
Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am reviewing my progress with programming a ComputerCraft Turtle to craft like items together for repair purposes. Let’s get started. The program I spent my week putting together is supposed to: 1. Make sure its environment is good. 2. Ensure it is working … <\/p>\n