dgelessus

http://lua.org/manual/5.3/ to be exact.

Real-life time is a little more tricky than in-game time, because OpenComputers/OpenOS has no built-in APIs for that. The most reliable way would probably be to store the real-life time for Day 1, 00:00 in-game time, and then to calculate the current real-life time based on this epoch and the current in-game time. If you want to know the exact time scale of in-game to real-life time, look it up on Minecraft Wiki.

cd.. is a special case that only works in DOS/Windows. The proper way to write it, as said above, is cd .. (cd is the command name, and .. is the single argument to the command). As far as I know cd .. does nothing if the current directory is /, at least it shouldn't cause any errors and such.

Java 6 is a very old Java version, and supporting it is no longer practical for most mods. If your version of OS X is 10.7 (Lion) or newer, then you can go to http://java.com/en/download/manual.jsp and install the latest version of Java 8. If you're still on OS X 10.6 (Snow Leopard) or older, then you're out of luck, sorry.

(If no return inside the function is provided, lua assumes a nil return)

Totally unimportant nitpick, if there is no explicit return, the default isn't a return nil, it is return without any values. In most cases there is little difference between having nils at the end of an argument list and not having them, but there is a difference. This is easiest to see in the interactive prompt:

> return nil
nil
> return
> return nil, nil, nil
nil     nil     nil
> return "hi", nil, 42, nil, nil
hi      nil     42      nil     nil

Also:

> select("#", 42, 24)
2
> select("#", nil, nil)
2

(Yes, this is totally irrelevant to the topic of the tutorial. )

Depends on what you mean by "supercomputer". If you want to link multiple computers together for more RAM and parallel computing, a server rack in internal network mode would be a good start. This would only make sense for calculations that take long and require little communication between computers, otherwise you'd end up wasting more time on network I/O than you'd gain from having multiple computers.

That's precisely what I mean.

Oh, then I was just understanding you wrong before. Sorry for being a derp (and derailing the thread)

(Huh, I'm a "Leading Member" now? Neat.)

By "skipping" do you mean that computer.pullSignal's yield cannot be "caught" by user code?

OpenComputer wraps calls to coroutine.yield and coroutine.resume so that they can bubble sysyields. It's part of how OC handles component methods. (if you want to look at the code that does the yielding stuff you can check here )

Yes, I "knew" that (i. e. I read that piece of code once before). Though I don't understand how this relates to computer.pullSignal and "skipping" coroutines.

Also, computer.pullSignal skips over all user created coroutines

Just curious, what exactly do you mean with that? Coroutines aren't like threads, Lua doesn't automatically run them concurrently. Logically if you call computer.pullSignal in one coroutine, that will block all execution, even if you have some kind of "manual threading" (Plan9k).

If there is no OS on the hard drive yet, then the computer will automatically start from the floppy disk (because it's the only bootable device connected to the computer). After OpenOS is installed, the computer will always start from the hard drive if possible.

HT means "horizontal tab". It means that somebody has indented their code using tabs, but the OpenOS text editor is not good enough to display tabs properly. The easiest way to fix this is to first load the code in Notepad++ (or some other good text editor) on your computer and expand the tabs to spaces.

If you want to install OpenOS onto a hard disk, boot from the OpenOS floppy and run the install command. You'll be asked what hard drive to install the OS on. Once the installation is done and you've rebooted the computer, you can remove the floppy disk. Now OpenOS is installed on the hard drive, and you can now write anywhere, install new libraries and programs, etc.

Could you clarify more on the no memory/ cpu management?  Without it, server and client can't sync together properly?

The OP probably meant that the in-game computer can use unlimited amounts of CPU power and RAM. With the normal Lua architecture, the execution speed and RAM depend on the tier of the CPU and the total size of the RAM modules.

In OpenComputers' main config file (settings.conf) there is a maxPrinterShapes setting, you can change that to how many shapes you need. If you're playing on a server, the setting needs to be changed on the client and the server side.

.. is always the directory containing the current one, and / is always the root directory.

Instead of a loop with event.pull, try registering a listener function for touch events using event.listen. The listener function is called every time a touch event happens, so you don't need to worry about running a loop yourself.

The reason why your range checks aren't working is because they are never even run - the outer condition not x == nil and y == nil is always false. (not has a higher operator precedence than and, meaning that the condition is parsed as (not x == nil) and y == nil. What you probably want is x ~= nil and y ~= nil. (The check shouldn't be necessary at all, I don't think that x and y could ever be nil, since all touch events have coordinates.)

By the way, if you only have a short piece of code, like a small function, there's nothing wrong with putting it into a code block in your post. Long programs should of course go on Pastebin.

@Negi: If you/he do something wrong in /etc/rc.d/script.lua or in /etc/rc.cfg than the system will not boot anymore. So i guess its better to do it over /autorun.lua

Making your system unbootable is always an issue with things that run on boot, no matter where you put them. Writing a rc script is the "proper" way to make something run on boot though - init.lua is the OpenOS "kernel", and the scripts in /boot set up the OpenOS environment. If you put your custom code there, you might be unable to use some of OpenOS' custom libraries and functionality. autorun.lua is an even worse place - it is run everytime the filesystem is mounted on any computer (not just if it's the boot filesystem) meaning that if you do bad things in your autorun you won't even be able to fix it by booting from another filesystem. Unless you disable autorun in /etc/filesystem.cfg, which you really should do.

Solved: I must craft each Wireless card myself, else they dont get an unique address.

The addresses should also be unique if you pull them from the creative menu or NEI - by default components have no address, and they are assinged an address the first time they are inserted into a computer. Of course if you use middle-click in creative mode to clone an "initialized" component, the clone will have the same address.

When hovering over the power button in the GUI it should show you the reason why it crashed the last time (IIRC). Alternatively you can right-click the case with an analyzer to see a few details, including the last error.

From what I can tell your Clients table is a sequence, i. e. it has numerical keys starting with 1 and no nils in between. By the way, Lua has some great built-in sequence manipulation functions in the table library. Most notably table.insert to insert an object somewhere in the sequence (defaults to at the end, i. e. append) and table.remove to remove an item at a given index from the sequence (defaults to last item, i. e. pop). You can be sure that those functions will always work correctly - they are part of Lua's standard library and are well tested and used.

rc allows you to manage "service"-like programs in /etc/rc.d, control which ones are started on boot, and lets you send commands to the services. It doesn't provide any way of running programs in the background.

process is used to load other executable files as coroutines and keeps track of what program a coroutine was created by. process.load returns a normal coroutine, which you still have to run yourself. In Lua there can only be a single running coroutine at a time, which means that you cannot make background processes with this either.

event.listen doesn't create any background processes either. It lets you register functions that are called whenever a certain signal type is received. It might seem like the signal receiving happens in the background, but it doesn't. At the lowest level signals are received using computer.pullSignal, which waits for any kind of signal and returns it. The event library builds on top of that - event.pull calls computer.pullSignal multiple times until the desired signal is received, and also calls any registered signal listeners for all received signals, and runs timers when they are due. No background process "magic" going on there.

Wait this was abandoned because it was unique, say what?

Sadly that's how projects like these go sometimes - the original author loses interest, and the unfinished thing is not in a useful state yet. Happened to me as well. You don't want to know how many unfinished projects I have lying around.

All blocks in OpenComputers function as cables, not just the cables themselves. You can connect a RAID to multiple computers, just like any other component, but this also connects all components together. When OpenOS boots, it uses a random screen with a keyboard as the default and keeps that until it is shut down. When you restart the computer, it might choose a screen that is physically placed next to a different computer, but that is not something that the computer knows - it just takes the first one it gets. If you want to make a RAID accessible by multiple computers without sharing other components, you need to set up a dedicated server to provide network access to the RAID, and connect that to the other computers using switches, so that only network messages are passed through.

OpenOS has no such thing as "background processes" - really all code is executed in a single thread. What you probably want is the event library's listen function, which allows you to register a listener that is called when the computer receives a given signal type.

I'm not sure if this works any differently with TCP sockets, I have no idea how to use those even in real life code. Someone else probably knows though.