Category: Programming

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am going over my completed pure ComputerCraft prototype automated spawner. Let’s get started.

I now have a turtle program I’m mostly, but not completely happy with. The notepad++ doc I originally coded now has the bugfixes I missed while parallel coding, but there’s still a bug when the program is deployed across many turtles. As of this writing, I have yet to look into it, but it’s simple enough to repair for a functional prototype.

I’ve turned my attention to the other two programs. I have a program to attack the gathered mobs, and it works at about 98% for a pretty heavy load, but it’s sloppily coded. I will be reworking it before publishing. When will I publish? I honestly don’t know. Whenever it’s done. At this point, I doubt I have anyone waiting on it, but at the same time, if I did, I’d be asking for help.

Long story short, I’m focusing on a program to filter out matching items before the attack program. Already, I’m considering potential benefits of making a custom library. One function, itemOut(), should be useful for a lot of turtle programs. As long as I use the same variables it depends on, I can just copy it into each program. A library would let me just access it without having to have it in each program. With a little modification, I might even be able to write some code to read a comment in the header and get library version numbers… and with a little expansion, I could setup a software update system.

Unfortunately, that neat idea is unlikely to save me any time. I don’t think it’s likely to happen unless I come back to ComputerCraft in a while. I want to get back around into more real world applications some time here.

Getting back on topic: the sorting program. I’m trying to recycle as many of my ideas for the loot repair program as possible. I started with the getState-action structure. As mentioned earlier, itemOut() is exactly the same. I do have an evalItem() function in both programs, but I have no desire to try and reconcile the two. Even if there were a way to make a unified evalItem() function, getState() itself must be different; the two programs have different possible states. Of course, good programming gives you a “control panel” of variables to edit.

Final Question: For anyone who knows: What is the best tutorial for Gazebo?

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?

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am returning to the modded MineCraft world where I am working on exactly what I said I wanted to move on from last week. Let’s get started.

The smeltery program I wrote for last week was nice and all, but it had a bunch of potential improvements. For one, it was blind to its environment. It could only send out pulses when it was time for the next one. Plus, with the “analogue” capabilities of the regular computers, and my previous experience with dealing with analogue redstone, I was tempted beyond my ability to resist to tear out some space around the smeltery and upgrade the hardware.

Observer blocks were capable of giving off a pulse when a basin or table was filled and quickly emptied by a hopper. There are six sides in total for the computer to work with, but the front is on display and the top of this one is occupied with another block while the tight quarters makes threat of cross wiring redstone lines very real. Given these limitations, I set about working on a new setup capable of taking advantage of  the rs.setAnalogueOutput(string side) and rs.getAnalogueInput(string side) functions.

While I was working on the new hardware, I decided to combine the programs, and add functionality so I could pour from both places at once. I set to work with three modes in mind, meant to run almost the same code at once: “Basins”, “Tables”, and “Both”. (For the aspiring coders and grammar critics, the punctuation outside the quotes is intentional; the quotes mark the beginning and end of strings, or lengths of characters (a single symbol like a letter or digit).) The code quickly became messy, and I started going into writing functions to modularize the more deeply nested segments of code. I used a little trick I learned while writing assignments in C++ where I made a comment consisting of the comment character such that it covered a line of the editor.

//////////////////////////////////////////////////////////////////////////////////////////////////////////

The section break I just put in works in C++. Unfortunately, when I tried the Lua equivalent, WordPress changed the repeated — into a single line. Anyway, the trick is that after the comment signal, the rest of it can be either an odd or even number of character repetitions, even if the first  is double. The trick helped a little, and I pushed on, working from the extremities of the code to the main loop until I realized a bit of a mistake.

My original program was designed to loop over a number of pours to a single output. I wanted the new program to handle both at once and possibly more. I was nearing completion when I when I came to halt. The main loop was incompatible with handling both outputs at once. Ouch!

I went about redesigning it in my head, but the project just kept inflating and inflating. Soon enough, it was too big without additional notes, so I just modified my old program to work with my new hardware. Funny, how an estimated one day project ended up taking half the week and it wouldn’t have worked anyway. At this point, I am content to just leave that as it is. The hardware is set up such that the computer can tell which set of outputs to trigger and which outputs are responding, but the program doesn’t use the full functionality.

/*********************************************************************************************/

Another example of my section break for C++. This one uses the long comment format. I’ve thrown together a few more programs, but nothing amazing, and nothing refined. I have noticed a consistent pattern: once I get the code working, I want to make another, better version. ‘Maybe if I just make it do this a little bit differently…’

For my automated skeleton grinder, I already have coded up the turtles to kill the skeletons. They aren’t perfect, but they sort out the unstackables by themselves. I also learned a little more about their inventory management, so I have another idea on how to make them handle better. Besides, I also want to use more turtles to move the items about better and free up the attack turtles to actually do their main job.

My goal for this week is to fully automate the farm, at least in code even if I don’t get a presentable design in order.

Final Question: Problems can usually be solved from any different number of angles. What was the last time you scrapped progress in favor of an easier approach?

Good Morning from my Robotics Lab! This is Shadow_8472 and today, I am taking a field trip. My sister set up a modded MineCraft World, and I am into the ComputerCraft mod. Let’s get started.

ComputerCraft is a MineCraft mod that adds computers that run actual code using Lua, a scripting language. While a lot of programs are written, compiled (turned into something the target machine can run), and executed; scripting languages are more often just run off the text file as written. They will be slower, but easier to write.

ComputerCraft itself adds basic and advanced versions of both regular computers and their robot counterparts or “turtles” as well as a few other peripherals. All computers come with a Command Line Interface. Advanced computers will even let you use your mouse and show you colors while editing a program. Nevertheless, it’s the perfect mod for dealing with computers from a programmer’s point of view. In a multi-player environment, one might even get into hacking other’s networks while defending one’s own with encryption.

One mechanic within MineCraft proper I will be relying on is redstone. Think of it as a simple wire. Signal in one end,

I have dealt with ComputerCraft before. It was a few years ago, but it’s not totally new to me. Back then, I was a complete stranger to Lua and was only interested in the early game mining abilities. Other stuff was a little low level for my patience. I eventually set to modify the code for a mining turtle’s default pit digging program. In my research before reprogramming the turtle, I did not find the copy command, so I retyped the whole thing in myself before attempting the modification. Not a smart move without a second screen. But I did get the gist of the syntax of Lua and an insight into how the program was structured. It was a good way to learn the language.

In the present, I am looking to use in-game computers to manipulate the world in more ways than just mining it. I have already used a script to automate a tedious task from another mod, in this case Tinkers’ Construct, where I would otherwise have my time taken up by micromanaging the pouring of blocks and ingot casts. It provided a refresher course on programming and in Lua in particular.

I started with a description of the problem: Automatically pour from the smeltery. I formed a mental picture of how I wanted the program to do it: Send redstone pulses to the appropriate spouts. At this point, I start mapping out the logic of the system. Normally, such a stage would be done on a whiteboard or a piece of paper, but this was a small enough job, I broke good programming practice and skipped this step.

Coding the smeltry program was fairly easy. I pulled up the source code for the default mining program on my second screen and referenced it for syntax. I usually find examples a lot easier to follow than a paragraph explanation in some documentation.

What I do find helpful is bringing up the API’s (Application Programming Interface) for ComputerCraft elements I’m working with, so I can see what variables of what types the lower level functions want and in what order they want them. Think about it as tying an extra fancy knot and someone gives you a box of strings so you don’t have to make your own rope.

Debugging for the smeltery program wasn’t the smoothest. A programming practice I failed to follow was postponing the debugging until the program was fully written. I don’t like syntax errors. I don’t remember all the errors I had, but one of them stuck out as being stubborn. I eventually got it figured out and I could start debugging the logic.

The completed program has two inputs, both integers. The first is how many pulses to send, and the second is how long to wait between each pulse, as the a premature pulse can stop the flow. The final smeltery has two copies of this program, each a slightly modified to send the pulse to the correct place. Now that I think about it, I could have combined them with an in-program menu. Of course, I could always make it fancier and fancier, but it works for now, and I want to work on other things.

***

What? I underestimated the basic computer’s abilities. It CAN use analogue redstone signals. I will have to take advantage of that later on…

Final Question: Have you ever overestimated something and later took advantage of the previously overlooked abilities?