Month: May 2018

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am updating my progress on my LootRepair program. Let’s get started.

It wasn’t easy, but I finished pulling the crippling bugs out of my program. Using the turtle’s actual state as the program’s state was a good call. It can more easily handle an unexpected situation and sometimes auto-correct in the case of a minor inefficiency, like when I was missing a line of code to select slot 1 before crafting.

I think the biggest bug I had was my use of an OR statement. The line was:

elseif state == “good2” or “new2” then

I thought the logic was

IF state MATCHES (EITHER “good2” OR “new2”) THEN DO THIS CODE.

When it was more like,

IF (state MATCHES “good1”) OR (“new1” ISN’T false) THEN

Note the elseif statement. I had two such options in my huge list of things to do. I ended up just removing all traces of the “new” states  since they did exactly the same thing as the “good” states.

Another bug I pulled out involved confusion over bitwise operations. I was having trouble with what I thought was the “correct” way to bitshift a set of 2 bit flags for comparison; the exact required steps of which escaped me, so I pulled a programmer’s trick and did it slightly differently, by shifting the flag to be read to the 1’s and 2’s places, instead of moving the mask reading the code.

Pulling that tough bug was an interesting journey, taking up a couple days. For a while, I thought it was a problem with the limitations of the 80’s style computing model (tiny floppies can get filled up when you have about 5 backup copies of a program with 200-300 lines of code.) I had it printing the program state from a variable at each elseif statement for handling the state, but it was only after I appended a hard-coded confirmation of the state that I spotted the error.

With the prototype program thoroughly tested and (hopefully) debugged, I set it to work on four turtles. The good news is that they can work, but the bad news is that they still need someone to check in from time to time; one of the turtles keeps losing track of the item it’s supposed to repair. I haven’t even tried to tackle that one yet.

My program is almost ready. Once I finish this round of it, I plan on redoing the melee turtles under the same state-do something model. If I’m bored and don’t have anything else to do, I may even look into redeveloping this into either a custom API or framework (I’m not sure what the proper word is here).

Final Question: ComputerCraft has been perfect for getting into coding, but I feel I’ve been lacking in the presentation of actual code. Any idea on how you’re supposed to denote that with WordPress?

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am reporting my progress once again on my lootRepair program. Let’s get started.

Last week, I left off with my discovery of the failed premise of my first program. It works well enough if treated properly, but the core function, turtle.craft(), didn’t behave as nicely as I would have hoped in unexpected situations. My whole design philosophy was

1. Wait for an item to be shoved in
2. Make sure everything was all good to craft
3. Craft
4. Output
5. Check inventory for any more items to evaluate
6. Repeat

Problems arose when too many items clogged up in the turtle inventory at once. My new design will focus around a turtle opening itself up for an item when it’s ready and closing itself up again when one arrives. Hoppers shut off when powered, so I’m going to have the turtles follow the same protocols. While I’m at it, I want to make a second signal so the turtles can activate an error mode and turn on a light when there’s a problem.

This re-write, I want to actually write my program in such a way that it will be a versatile, well written program. Good code is easier to maintain, though it might be harder to write at first.

I started the rewrite by opening Notepad++, an awesome plaintext editor for Windows, and wrote my program in what was supposed to be pseudocode, but ended up growing into attempted proper Lua. Funny how a better tool can clear the head, because the editor that came with ComputerCraft does not have cut and paste, and when I developed several functions and wanted to order them according to other functions each one calls, retyping a chunk of code longer than a few lines gets a bit discouraging.

I transferred the files to the server computer and onto the very in-game disk I was using for my computer setup. Once again, I ended up in the same low-end, default editor for debugging my program. Admittedly, my program is still incomplete. At this point, I’m not even sure if it has the “next item” code correct.

One thing I do like about my working prototype program is how I can hot swap items… I just had an idea, but implementing it might involve rewriting the way it’s supposed to work, but maintenance should be a bit easier. Right now, I have the turtle’s state follow a cascade controlled by a series of spaghetti-code if-then statements. My new idea would have the main loop get the turtle’s state each event and act on that. I don’t even know if it’s reasonable. Honestly, I think I should be fine with my working prototype and another turtle to regulate the item speed, but I want to publish my code here.

Final Question: A good artist of any discipline should be able to work with any set of tools they have to work with. When you don’t care about formatting, or wish to avoid it, what plaintext editor do you use?

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 with matching, non-stackable items with durability.
3. Reject items that don’t work.
4. Craft valid items together.
5. Accept like new items once they are mended.
6. Be able to handle being unloaded and restarted from any state.

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.

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.

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().

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.

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.

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?