MaximilianVINCENT

I wish i could shoot laser beams from my eyes..

Too bad your eyelids aren't laser-proof. Also that they stay on for 24 hours each time you use this power.

I wish to be able to teleport myself and anything I am carrying to any place I have seen before.

Better yet, take a look at the source code for /bin/install.lua. Modify it with an update parameter and relevent code to prevent the overwriting of config files. When working, put a pull request(?) on github for that file.

Good thinking, by the way.

Bravo, my good man! A most excellent book. I like your introduction to Open Computers more than the one I did.

A big thank you! I have no idea how you did that, but is incredibly cute. Consider me motivated to get moving with the next tutorial.

(Now if only I could get it to shoot frickin' laser beams from its head.)

While my attempts to program a drone have so far failed, a quick look at http://ocdoc.cil.li/component:leash gives you the commands you can use with the Leash Upgrade.

Once a creature is leashed (component.leash.leash(sides.bottom) returns true), get it off the ground by moving up. Move normally, making sure you are high enough that the animal won't run into anything. Once done, unleash the animal over a body of water or it may die (long standing Minecraft bug).

I would like a Special Thinger™ as well.

• I have started and kept up a series of tutorials for OpenComputers, adding sorely needed documentation.
• Been active in finding bugs and suggesting features.
• I regularly check Reddit's FeedTheBeast subreddit and include information and assistance about OpenComputers where relevent.
• Do the same on these forums.
• Also really proud of my CompressCobble program.

IGN is StoneNomad, requested color is 205 197 191: seashell 3 according to http://cloford.com/resources/colours/500col.htm

Looks like the schematic should be in the same directory as the 'build' program.

As for the dungeon disk, try either putting a floppy drive in one of the upgrade slots or copy the program to the robot's Hard Drive before building it.

Ask any questions, I and others will be glad to help.

edit: poor grammar

autorun.lua does work in root, had it print "Hi there" and show me the error caused by os.execute and sleep for a few seconds. It also works on other media, commonly to mount it to a certain location on the root filesystem (/home, for instance).

I am going on vacation for a while, when I get back I will be trying out the rc system. Thank you!

Wanted a good subject to learn more about OpenComputer programming, this definitely worked.

CompressCobble

• Uses a minimal Robot to continually compress Cobblestone, up to Octouple Compressed Cobblestone.
• Uses about 83 cobblestone per second, or 7.2 million per day. (If you want more, put four Robots around a Charger, each with its own cobblegen.)
• Stores over 225 Octouple Compressed Cobblestone internally before quitting. May optionally be put in chest above Robot for extend run time.
• Cheap in power, up to 3 RF per tick. A couple of Solar Panel Upgrades may be enough. You can use a Generator Upgrade as well.
• Checks to see if needed components are available and will list any problems.
• Can be run on a 'headless' (no screen, graphics card or keyboard) Robot to save on resources.
• Enough compressed cobblestone for a Deep Dark Portal or Bedrockium Drum in much less then a day.

Minimum Robot Required:

•   Tier 1 Computer Case
•   Tier 1 CPU
•   Tier 1.5 Memory
•   Tier 1 Hard Drive with OpenOS installed (suggest adding this at the same time)
•   2 Chest Upgrades: Tier 1 robot needs a Tier 1 Upgrade Container
•   Crafting Upgrade: Tier 1 robot needs a Tier 2 Upgrade Container
•   Some way to keep it powered, I suggest a Charger

DOWNLOAD:   Link to Dropbox Folder, v1.5 as of 23 March 2015.

Thanks to Sangar for help with getting events working!

Edit: Almost forgot 'no pics, no clicks'!

I have a program at /usr/bin/cc.lua that I want to run after booting is complete. If possible, add an argument as well (i.e. cc v )

I tried cp /usr/bin/cc.lua /autorun.lua and nothing.

Then tried adding

•    cc
•    /usr/bin/cc.lua
•    os.execute("cc.lua v")  -- really expected this one to work
•    os.execute(cc.lua)
•    os.shell(cc.lua)
•    os.shell("cc.lua v")

  to a clean autorun.lua and still nothing. Grr.

What is the correct way to do this?

Close. I had to adjust event.pull(0,"key_down") to event.pull(0.6,"key_down"). Any smaller of a delay and it does not reliably recognize a key_down event the first time through. Working great, chews through cobblestone.

Is using the keyboard API better in some way over string.byte(" ")?

What I would like is something simple:

char = next char from keyboard buffer

if char == " " then quittingTime() end

or a background process that looks for the space bar being pressed and then runs quittingTime(). (Faster response time to user input, yeah!)

or understand how you meant for it to be done.

What I did do:

I tried os.sleep() and event.pull() right before if hasDisplay then updateScreen() end, near the end of my program.

os.sleep(0) does not work.

os.sleep(0.1) very rarely works. When it does work, it is many seconds after pressing a key or many keys that it runs quittingTime.

Skip this, going to event.pull directly.

event.pull(0.1,"key_up") is getting the enter key from starting the program, so that won't work.

event.pull(0,"key_down") does not work at all.

event.pull(0.1,"key_down") works very, very poorly.

event.pull(0.25,"key_down") works but loops around 3-6 more times before realizing I had hit a key.

event.pull(1,"key_down") works on the first try.

I do not like adding another second's delay to the main loop, this program is slow enough already (especially when pulling in cobblestone).

But it works, so 'oh well'. Thank you for the help, Sangar!

The way I see how this works:

event.pull(0, "key_down") goes though the table of signals with key_down as the key and returns its value. if not null or zero seconds have passed, get back to what I was doing. Obviously wrong, so I tried various ways to look at the event.pull function but all of them were wrong as well, print(string.dump(event.pull)) was just weird.

How do I dig deeper? I really want to understand how signals and events work (processes too, but later).

I have also learned the importance of event.ignore() at the end of your program. I had to restart the robot because every time I hit the space bar it would run through the quittingTime function, even while in the shell or running edit (probably because they were both always trying to get key_down events).  It seemed to work better outside of my program than in it!

I've spent a few hours now trying to figure this one out, I need another pair of eyes, if you please.

In learning about how events work, I wrote a simple program: http://pastebin.com/HfBtgxhz
 

With a little play, I got it working so pressing the space bar will exit. Yeah! So I used the same set up in my current program (which will be posted when this last problem is fixed).

And nada, testing shows it does not run QuittingTime() when any key is pressed. I don't see a difference in the code.

Why does the first program work but the second program does not?

Thanks to sangar, I learned something new!

I posted the robot.chestCount() as a suggestion on the bug tracker and he came back with robot.inventorySize().

Testing showed that component.inventory_controller.getInventorySize(sides.back) is an unsupported side and error. I actually expected that to work, but I am glad I do not need yet another Upgrade (Those Tier 3 Robots are expensive).

dgelessus, it was printing a reason for the error and a stack traceback. I would call the blue screen a crash. Procedure calls are something I have no experience in yet, but do need to eventually learn. That and signals and events are still mysterious to me.

The only thing to do now is to create a login for the wiki and add this little beauty. Thank you for the help, guys!

I would like to make sure at least two Inventory Upgrades are available.

• trying access a slot the robot does not have causes an error
• /bin/components.lua inventory returns nothing, so component.isAvailable() will not work.

I was hoping something like robot.chestCount() existed, but not yet.

Any ideas out there?

I finally have something worth sharing. Would you set up a repo for GoneNomad?

Doing some cross mod testing, just having fun. I gave an activated A class Terra Shatterer and a full mana tablet from Botania to my Tier 2 Robot.

My mistake was giving it an infinite loop to dig with. I thought I could just catch up and break it, but it is moving so fast, it won't stay still long enough. The Solar Panels weren't helping either.

Its off to the loaded chunk boundry sunset. Along the way it tore through a village and made a nice tunnel.

Definitely one for the notebook.

This is a good chance to practice your code-reading, Saddamo. Go to http://pastebin.com/x8G9XRrt and start at the top. If you aren't sure what a portion of code does, skip it.

I definitely learned a few things and look forward to using this program. Thank you 2016mfransen!

A quick test with Creatix shows it not working here as well. If the problem is repeatable, this is when you post a bug report.  Go to the Bug Tracker and let fnuecke know about it so he can test and fix it. Also give what version of OpenComputers you are using and how to replicate the error.

Nah, once you know exactly what you want, it gets a lot easier. Look at Black Hole Tutorials 4 and 5 on this forum for some tips. I like the modern vending machine concept, that is a lot more fun to watch work. I had more of an automat-style setup in my head. Keeping it filled might be an interesting challenge if it is far way from your place of production.

My Tandy Model 100 still works great, so yes.

I can see doing that but without the pipes. Above ground is a building with a ring of spots for each liquid. A sign above and trapped chest for each one. The redstone singal from the trapped chest could goto a multi-color cable or just a ring of redstone dust. That signal would let the robot know to:

• find out which chest has the payment in it
• take the payment
• put into chest in basement
• get the approriate liquid from a holding tank in the basement
• come back up and hover over the drop point
• wait until a tank is available and fill it, then drop off payment to basement chest
• or when 5 minutes is up return fluid to basement and return payment

You could also use a computer as the input (show prices and availability), use a piston wall to show/hide the chest or hopper, and robot to transfer fluid to temporary tank internal to the building with a pipe sticking outside.

Lots of ways to do it, this is only two of them.

A cheap Tier 1 robot with a tank upgrade (16 buckets max) could be used as a programmable holding tank and only allow what you want to pass. A better robot can have multiple tanks. What are you trying to set up?

for OpenComputers 1.51 on Minecraft 1.7.10
Black Hole Tutorial 05- Pretty Pretty Program

"If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization."

- Gerald Weinberg

Before we got into writing anything useful, I wanted to go over some commonly preferred practices to be used when writing your programs. This is purely selfish on my part, since I would like to be able to read that elegent bit of code that took you a week. These practices should also make things easier on you.

Writing your Program

1) Write the documentation first.
As in the last tutorial, knowing exactly what you want done makes writing code easier. Start by writing the .man page first.
edit /usr/man/programName.man
NAME - name of your program
SYNOPSIS - how your program is started, what arguments are used
DESCRIPTION - What does your program do? Any options available?
EXAMPLES - examples of your program in use, how arguments affect the outcome

With documentation done first, you might be able to throw out ideas you at first thought to be great without writing a line of code. Once done, your docs will guide and help keep your focus during coding.
If you do choose to do the documentation later, you will have less reason to do a good job (I know how it works, that's good enough!) and will know the program too well, probably leaving out things new readers should know.

2) Write from comments to code.
Determine the flow of your program before actual code. Start at general ideas of how you want it (put wood in furnace) and break it down. This makes it easier to see additional requirements, what is missing or backwards, etc.

put wood in furnace
move to top of furnace - drop wood in top
move back, up, back - select slot with wood - dropDown 8 at a time - return to home
t.back() t.up() t.back() - t.select(woodSlot) - while t.count() >= 8 do t.dropDown(8) end - t.forward() t.down() t.forward() - select previous slot

OK, you get the idea (and I learned a new button!)

3) Start small, test often.
Write a prototype with the most miminimal imaginable functionality (like our treeMuncher program from the last tutorial).
Gradually add features one at a time (planting a sapling, checking for a grown tree, etc) after making sure the program is currently working. When debugging you will know any problems must be in the recently added code. This is better then spending four hours writing out every part of a complicated program and then over six hours the next two days debugging it. (I would have been better starting over.)

4) Do the easy thing first.
This gives your subconscious time to break down the difficult parts.
Trying to tackle the most difficult bits first will make Reddit or Netflix look like a good alternative (Still haven't seen Game of Thrones, maybe just the first episode). You want to do it all eventually, so ease into it.
On the other hand, stay away from easy low-priority work that does not really need doing (get the furnace interaction working before playing with the soundtrack).
If you're stuck, go to bed and let your brain stew on it for a while.

5) Read (and use) other people's code.
There is always someone who is better then you, learn from them. Look at programs similiar to what you want done. If you find something useful, thank them and write it down in your notebook (If you do not have one by now, I REALLY SUGGEST getting something. A text file, wiki, pen and paper, whatever. Pale ink (or pixels) beats a bright mind.)


Formatting your Program

"Code is read much more often than it is written."  - Guido van Rossum

The following is a style guide of how to make your code look, based upon available Lua style guides online and some personal preferences.

Consistency
Consistency means to do things the same way most every time. There will be times when doing it differently makes it easier to read, the art is knowing when.
Even if you don't intend anybody to read your code but you, then think of the you twelve months from now (you are going to be amazed how bad you were back then).

Comments
Comments that contradict the code are worse than no comments at all. Keep comments up-to-date with code changes.
Use block comments (--[[ and --]]) for long comments and important notes. Use line comments (-- ) for short, unimportant and temporary comments. Keep a space between the -- and your comments.

Inline Comments
An inline comment is a comment on the same line as a statement. Inline comments should be separated by at least two spaces from the statement. Inline comments are unnecessary and in fact distracting if they state the obvious. Tell us why, not what.
Example: xMax = x + 1  -- Increment x  Leave room for window frame

Indentation
I indent two spaces, though I've seen three and four used as well.
Spaces are the preferred indentation method. Tab sizes can vary by user and editor. This helps to keep code easy to follow by eye, find missing closures, etc.

Bad Example:

if next(idx) == nil then
print this and that
show some examples
else
for i,v in pairs(idx) do
all of this and that
end
end

Good Example:

if next(idx) == nil then
  print this and that
  show some examples
else
  for i,v in pairs(idx) do
    all of this and that
  end
end

Naming
It's a general rule that variable names with larger scope (seen by more of the program) should be more descriptive than those with smaller scope. For example, 'x' is probably a poor choice for a global variable in a large program (better would be 'homeCoordX'), but it's fine as a counter in a small loop.

Constants:
Constants, particularly ones that are simple values, are often given in ALL_CAPS, with words optionally separated by underscores.
Example: CONNECT_RETRY_FOR = 300  -- in seconds

Lua internal variables:
Names starting with an underscore followed by uppercase letters are reserved for internal global variables used by Lua.
Example: _VERSION

Variables:
should start with a lower case letter with each embedded word capitalised.
Examples: maxTreeLevel, moveToTarget, HTTPAddress (while not consistent it is easier to read, so a good exception to the rule)

Functions:
Functions follow similar rules as variables. A function name consisting of multiple words may run together (getmetatable), as done in the standard Lua functions, though you may choose to use underscores (get_metatable) or like variables (getMetaTable).

Booleans:
It can be helpful to prefix variables that contain or functions that return only boolean values with 'is'
Example: isChickenDone = false

Names to Avoid:
Never use the characters 'l' (lowercase letter el), 'O' (uppercase letter oh), or 'I' (uppercase letter eye) as single character variable names. In some fonts, these characters are indistinguishable from the numerals one and zero. When tempted to use 'l', use 'L' instead.


Code
Compartmentalize your program
Always start with a comment header, then keep similar parts of your program together: required libraries, variable and constants definitions, etc. Keep functions close to where they are called from.

Use local variables rather than globals whenever possible.

When you type anything that requires closure, do it now and move back.

This way you are done and have no need to remember to do it later.
Examples:
 ( ), " ", [ ], --[[ --]]
 function() end
 if then end  -- Ooh, triple word score (might be tired)
 
When unsure, parenthesize.
While the order of operations is correct for our needs, parentheses will ensure future readability. Even if you are absolutely sure it doesn't need them, consider the next person who uses the code without you there, who will probably put parentheses in the wrong place.

Editor

While editing a program in the Robot works fine for simple programs and bug hunting, you'll eventually find yourself wanting to use a proper IDE(Integrated Development Environment). An IDE will use color to highlight key parts, hide function bodies you don't need to be looking at, have multiple files open or the same program open at different points, auto-completion of variable or function names and much more. Just try one and then go back, I dare ya.

If you want to be editing your programs while Minecraft is running, you need to open /config/opencomputers.cfg and change bufferChanges to false.

These are some free IDEs I have tested.

• Been some time since I used Windows, but I remember Notepad++ being my primary choice for an editor.
• Currently I am running Kubuntu, so Kate is available. Works fine for my simple stuff and what I use most often.
• Zerobrane Studio: This is the one I would recommend, the interface is fairly intuitive and I like the amount of documentation. Available for Linux, Mac and Windows.
• jEdit:I have spent the least amount of time with this one, so I can't say much other than it works.

Liscense
Only because this is a silly world we live in. If you worry about how others might use your programs, I suggest learning about the GNU General Public License, here is how to use it.

Least Signifigant Bits

• OK, I lied. This is actually for me. I get ideas popping and then get messy and then have to start over. You can use it if you want.
• In the next tutorial we are playing with computers and cards!
• If you are having problems, post it on the Support Sub-Forum. Additional information, constructive critism or praise of this tutorial should be posted below.

End of Line.

The RAID is an external filesystem, like the Floppy Drive but on steroids. If the RAID is connected to a computer by wire or proximity (next to the computer), you should be able to see it by typing 'df' in the shell, look for 'raid' on the left side of the output.

My testing says a RAID has to have three Hard Drives. Any Hard Drives inserted into a RAID will be wiped. If you remove any of the Hard Drives in a RAID, the entire RAID will be wiped. You can pick up and move a RAID without disturbing the Hard Dirves within.

If your RAID was found above, it has been mounted to your boot filesystem in /mnt (look for the first three characters of the RAID's address) and could be accessed through there. It might be easier for you to mount it elsewhere on the filesystem, /home might be a good choice.

I wrote a tutorial about this, look for Black Hole Tutorial 03. As for finding documentation, Black Hole Tutorial 01. If you need more help, reply here.