dgelessus

The question is whether that setting is stored on the actual card item. If not, then there would be no way to set that setting on a fresh robot without manually powering it on.

Robots can't use GUIs, so in this case robot.use() does nothing. If you run robot.swing() afterwards it will try to punch/mine the robot. The reason why I suggested the sneak-right-click method was because that doesn't require any GUI interaction, but unfortunately robots cannot do a sneak-use, so that isn't an option either.

Any kind of computer (including robots) can be powered on by sneak-right-clicking, but I don't think robots can "sneak"... Item exchange between robots shouldn't be hard, you should be able to put items into the other robot as if it were a chest.

Tja, diese Forum-Software ist genial und mir ist gerade mein ganzer Post verloren gegangen. Kurz gesagt: Forge und Bukkit sind zwei unterschiedliche Sachen. Forge braucht man für Mods, Bukkit braucht man für Plugins. Der Unterschied zwischen Mods und Plugins ist, dass Plugins nur auf dem Server installiert werden, während Mods sowohl auf dem Server als auch auf allen Clients installiert sein müssen. Mods können deshalb viele Dinge im Spiel ändern, die Plugins nicht ändern können. OpenComputers ist ein Mod, kein Plugin, daher kannst du es nicht auf einem Bukkit-Server installieren. Forge und Bukkit sind von Haus aus nicht kompatibel, und allgemein wäre es nicht empfehlenswert Mods auf einem bereits existierenden Bukkit-Server zu installieren. Deshalb solltest du für Forge einen separaten Server in einem eigenen Ordner anlegen und Bukkit dabei ganz aus dem Spiel lassen. Welche Minecraft-Version du dafür nimmst, ist am Ende nicht besonders wichtig, es sei denn du willst noch andere Mods installieren.

Both Minecraft 1.7 and 1.8 are supported. There are almost no other mods out yet for 1.8, but that will probably change soon. This means that at the moment all computers run for free and don't require power, and obviously most mod interaction isn't possible. The 1.8 version may also have a few small bugs that the 1.7 version doesn't. If you're okay with those things, then you can try the 1.8 version. The differences between the two versions aren't very major.

Sowohl Minecraft 1.7 als auch 1.8 werden unterstützt. Es unter 1.8 bisher kaum andere Mods, das wird sich wahrscheinlich aber bald ändern. Das bedeutet, dass zur Zeit alle Computer ohne Strom laufen, und logischerweise fehlt die meiste Integration mit anderen Mods. Außerdem hat die 1.8-Version eventuell ein paar kleine Bugs, die es unter 1.7 nicht (mehr) gibt. Wenn du damit kein Problem hast, kannst du die 1.8-Version ausprobieren. Die Unterschiede zwischen den beiden Versionen sind nicht besonders groß.

Control schema 1: Shift-right-click with a floppy disk onto a disk drive to insert the floppy into the drive.

I didn't know that was even possible Probably a good thing now that you mention it.

My suggestion would be to change the wiping control so that putting a floppy disk by itself into a crafting grid wipes its data instead of a shift-right-click.

Full support.

Unless you guys are evil and this kind of madness is exactly what you want.

"Removing a disk wipes the raid."

Hard to say much without seeing the actual API and code, but it definitely sounds interesting.

How exactly do different scripts access and control the GUI? Does every script have access to all frames, or are frames bound to a script? Does the "process tree" have something to do with the GUI, or is that just another feature of the OS? Do all processes run simultaneously, and can they interact with each other in some way? (I'll stop throwing questions at you now )

Regarding import, does it do anything GUI-specific that require doesn't? Because if it's basically the same as require (load a module and make a table out of it) it would be better to not change the name, because require is a standard Lua function and not something specific to OpenOS.

As I understand it OC automatically doesn't require power if you don't have any power-generating mods installed. (Unless that was recently changed.)

The proper way to do this would be using the rc system (/etc/rc.cfg and /etc/rc.d/). I can't find any documentation on how to use it, so here's a rough guide:

1. In the /etc/rc.d/ folder, create a new Lua script (e. g. autorun_cc.lua).
2. The script must define a start function that can take at least one argument. That function is executed when the system is started, and can contain whatever code you want. In your case that would probably be os.execute("cc.lua v").
3. Now edit the /etc/rc.cfg config file. Add the name of the script (e. g. "autorun_cc") to the "enabled" list.
4. Done.

This is only the most basic thing you can do with the rc system. If you want to see how it works internally, check the /boot/99_rc.lua and /lib/rc.lua files.

FYI, the autorun.lua is only executed when freshly connecting a storage device. (Might even only work on floppies.) It does nothing on the boot drive as far as I'm aware.

pcall is really straightforward. Say you have this function:

function errorOnDemand(param)
  if param then
    error("You asked for it.")
  else
    return "some stuff", "you'll see this later"
  end
end

(if you pass it true, it errors out.)

To run the function and catch errors, do this:

success, returned1, returned2 = pcall(errorOnDemand, true)
print(success, returned1, returned2)
-- false        you asked for it

success, returned1, returned2 = pcall(errorOnDemand, false)
print(success, returned1, returned2)
-- true         some stuff        you'll see this later

The first argument to pcall is the function you want to call, any further arguments are passed to that function. The first return value of pcall is true or false depending on whether it succeeded. If so, the remaining return values are those of the called function, otherwise the error message. Or in code form:

-- Normal call
ret1, ret2, ret3, etc = func(arg1, arg2, arg3, etc)

-- Protected call
success, ret1_or_error_message, ret2, ret3, etc = pcall(func, arg1, arg2, arg3, etc)

• trying access a slot the robot does not have causes an error

Does "error" mean a normal Lua error (where you get a traceback) or a blue screen/OS crash? In the first case you can use the standard Lua `pcall` function to check whether the function ran successfully and catch any potential errors.

And I thought my Windows 95 laptop with a whole gigabyte of hard drive space was funny nowadays. That thing became unusable a few years ago though due to a lack of usable floppy or CD drive. Its Win95 soul has since passed on into my VirtualBox, where it runs at a 1600*1200 True Color resolution that it could only dream of before.

There was also that one Macintosh running Mac OS whatever version, which got the computer mutation of Alzheimer's disease. It kept forgetting that its screen actually supported colors. And sixteen of them even. But hey, at least it could run Pac-Man. Oh how fun that was to play with the arrow keys all located on the same keyboard row in the most counterintuitive order possible. (Seriously who thought that was a good design choice?)

TCPNet perhaps? Linked Cards are so much simpler though... Your decision, if you want to do it this way, go ahead.

For inter-dimensional communication you can use a pair of Linked Cards. That way you don't have to rely on an external server to return all data to the sender. You just need to make sure that both computers are in loaded chunks (either near the spawnpoint or manually loaded using a chunk loader block). To communicate between servers you'd need an extra program running on the real computer on both sides that passes network signals through to an in-game computer, because by default the Minecraft server doesn't do that. I'm not sure how exactly that could be done though, it might involve writing an add-on mod for OC. (Or am I missing a much simper solution here?)

So I was looking how to eeprom, lets check the wiki, couldn't find anything...

Small tip: there are a few places in-game where you can find documentation as well. First of all checking an item's NEI usage page will have one page with a general description, and a second one with a Lua API reference, if any. For components you can also check their API from the interactive Lua prompt:

lua> component = require("component")
lua> component.eeprom
{
... a list of all EEPROM methods ...
}

(btw still not sure if it uses the same apis!)

Not entirely. EEPROMs only have access to Lua's built-in functions and a few core OC APIs, a full list can be found on the wiki's tutorial on writing custom operating systems. (That list might indeed be a little out of place there.)

All I found out was a flash program, which says that it "holds the power to bend eeproms to its will!!! or reflash it" so I downloaded this "program" flashed a eeprom, put it in my drone, used the client to talk to the drone. And by "talk" I mean nothing happened, if you type anything then you basically get a *beep* and if no-one understands, the computer is basically telling you to f***k off.

By default it just downloads the normal Lua BIOS to the EEPROM chip, which you can also do via crafting. In a drone that won't be of much use though, because (IIRC) they don't support screens and keyboards.

"How to make your own os" you should seriously put an "Advanced" prefix next to it, because I didnt under stand crap.

It's realism quickly killed the experience using it.

OC was quickly killed because of the documentation.

Well you did choose possibly the most complicated part of OC to try and learn. EEPROMs are not easy to use, that's why there's OpenOS to let you write programs more easily using its higher-level APIs. If you want to program an EEPROM you need to do a lot of things yourself that the OS would otherwise do for you, so don't expect it to be very straightforward. I understand that the lack of tutorials on the matter doesn't help, but if this isn't your cup of tea then maybe ComputerCraft is indeed the better choice for you. No one is forcing you to use OC, so if you don't like it there's nothing stopping you from switching to CC instead.

Except that the guards are basically people on irc not wanting to share their knowledge about open computers. And that sucks, everything there is off-topic.

The forums are also a good place to ask for help. OT discussion here happens in a separate subforum, so you can skip it if you don't like it.

The current forum skin hides the action buttons below posts by default unless you hover over the post. On touch devices (smartphones and tablets) there is no way to do that, so it is impossible to quote people or edit posts. Not a major issue, I can of course just use a regular computer, though it can sometimes be inconvenient.

Nice tutorial, I like the detail - I have a good amount of experience with the OpenOS shell, but I could probably still learn something from here.

A few comments:

• The whole case sensitivity thing is not entirely true. Although ls ≠ Ls, if you're on Windows you still can't have ls.py and Ls.py in the same folder, because Windows is case-insensitive like that.
• In a normal Unix shell you'd assign envvars using "export name=value", "set name=value" or simply "name=value". I think there is a "set" command in OpenOS.

FYI, you can use hexadecimal number notation anywhere. Lines 8-14 could be written like this:

local red = {}
red[1] = 0x000000
red[2] = 0x330000
red[3] = 0x660000
red[4] = 0x990000
red[5] = 0xCC0000
red[6] = 0xFF0000

The whole color brightness thing now also makes much more sense. In your first post it sounded like you just wanted all distinct colors to loop through all the values more efficiently. I don't know enough about color sciences (is that a thing? lol) to say anything constructive about that part, but hopefully you'll figure it out.

It's certainly not impossible to do this, though it is definitely a lot easier to keep everything in-game. It might be easier to first implement everything in OC Lua, and once you have that working try to port the server to a stand-alone language. I have never tried to write a server from scratch myself, so I can't help you with any specifics there.

If you're looking for a language to write the server in, you should give Python a try. It is a scripting lanugage like Lua and you'll quickly see certain similarities between the two, though they are very different in many aspects. In general Python is less simplified in certain aspects (e. g. foo.bar is not the same as foo["bar"]), but that doesn't make it harder to understand, once you know the differences you'll know their uses as well. Unlike Lua, Python also comes with an extensive collection of modules included in the base installation. This means that you may even be able to write your server without the need for any external libraries.

See my reply in your other thread on this topic. (Trying to keep the discussion in one place.)

OpenComputers indeed only supports 8-bit colors, but still uses hex notation, which can reference over 16.7 million colors, so iterating through all of them would be highly inefficient and would lead to a lot of technically identical colors.

@Eunomiac has created a nice reference image showing all colors supported in OC and their hex values, you may find that useful: http://oc.cil.li/index.php?/topic/442-/#entry1751

As Sangar said, you should never need to use the numerical ID of a block or item, ever. Since Minecraft 1.7 Forge does all ID assignment automatically, and in almost all cases you should be using unlocalized names like minecraft:cobblestone instead. There is no guarantee that IDs remain consistent if you add, update or remove mods, and they can vary even across worlds and servers. As of Minecraft 1.8 it is also impossible to use numerical IDs in-game, at least in commands such as /give. (Reading numerical IDs is also somewhat agains OC's concept of remaining "in-character" and not being able to access information that isn't visible to the player without the F3 screen.)

Perhaps don't try to do this over the internet? Seriously - it would be much easier to connect your vending machine to a second computer via an (in-game) network cable, or if necessary a wireless network or two Linked Cards. If you were to send the data over the internet you'd need to worry about having a real server running on some computer and have it accessible over the internet. You'd also need to find some other language to write the server in. Lua is meant to be an embedded language used to script other applications, and although you can run Lua standalone I don't think there are any real libraries that you could use to run a server. If you already had a running server I would understand why you'd want to do this, but from what I can tell from your post it sounds like an unnecessary extra step to go over the internet.

Looking at the source code for event.lua it looks like you should be able to clear all timers like this:

local event = require("event")
event.timers = {}

Be aware that this might break things relying on timers - I don't believe the default OpenOS shell has any background timers running, though the same might not be true for other scripts.

Programming an EEPROM is technically writing an OS, because there is nothing else on the microcontroller itself that could have an OS. But yes, as the page says, many of the high-level libraries are not available outside of OpenOS and you'll need to use their lower-level counterparts.

The wiki search is terrible btw. A search for "microcontroller" returned no results, and "computer" gave me only a few hits on the home page. No matter how extensive your wiki searches are, you won't be finding anything with the search function.