dgelessus

well that's also a way. but isn't your sleep function the wrong way to let the computer "sleep" and is calling os.sleep(x) not the better way?

You'd be surprised how OpenOS does it. Though the OpenOS version is slightly better, as it uses event.pull, which means that signals happening during sleep are properly passed on to any listener functions instead of being swallowed by the sleep loop.

Uh... it's a collection of GitHub repos, does that really need screenshots? I mean, click the link and see for yourself.

Do commands work that don't require op rights? Like say Hi, I'm a debug card!

The screen switch is because the "primary" component system is provided by OpenOS, not the Lua BIOS or the sandbox. The BIOS binds the first GPU to the first screen, and that is what OpenOS will show the boot progress log on. Once OpenOS' component additions are loaded, the last screen with a keyboard is set as the primary screen, which is then bound to the primary GPU. The definitons of "first" and "last" are basically random. All that is guaranteed is that the primary screen will have a keyboard, unless there is no screen with a keyboard.

FYI you can put some upgrades in the adapter block I.E. an inventory_controller

To see chest contents and I believe manipulate them.

IIRC that requires a config setting that is not enabled by default. I might be wrong though.

1. Documentation. OC Is an extremely complex mod, possibly the most complex I have ever seen, even more complex than the popular engineering mod 'rotarycraft'. But it has a serious lack of documentation and is put down by a serious learning curve. Most people I speak to say it simply isn't worth attempting to learn to use the mod because of it's steep learning curve. The documentation we do have (such as the wiki/youtube tutorials) don't do enough to demonstrate 'real-world' applications and don't go into enough depth nessecary to understand such a complex mod.

In more recent versions there is a built-in manual item, which is the main documentation for the mod (AFAICT). If you have NEI installed you can also look up documentation for items by checking their crafting usage - this will show a short description, a list of all component methods (if the item provides a component) and a button to open the corresponding manual page.

2. Power supply. OC simply has no inbuilt power system, and due to the lack of documentation it can be rather frustrating to manage power. I for one don't like to waste too much power on my OC builds, but it's very difficult to gauge exactly what I need for a particular build to run. I'd very much appreciate some notes on items, or notes on the analyser which show how much power my system is using, and how much excess power I'm providing. OC also lacks a 'power-cable', from what I've seen it doesn't have a copper cable/kenesis pipe that other tech mods such as IC2/BC offer. I'm currently using capacitors as cabling, which is awful.

While there is no built-in power system (in fact computers don't need power unless you have a mod installed that provides a power system) the normal cables can be used to transfer power. There is also the Power Distributor block that passes power through, but does not relay network messages or share components.

3. Capacitor multiblock. I'd like to see capacitors turn into a multiblock when placed together, similiar to how screen's behave. I'd be find with them operating individually, It'd just be a nice graphical update.

Capacitors don't really connect in any way, but they get an "adjacency bonus" to their capacity.

How would that be easier than directly connecting two projectors to one computer? If you're having problems with the component limit, get a server and install component busses, that way you can connect up to four times as many components as with a normal computer case.

@nvmqpa et @sshikamaru: Il y a des tables Unicode sur Wikipédia pour les caractères "filets" et "pavés". Sur Windows il y a aussi une application qui s'appelle "Character Map" en anglais (ma version de Windows n'est pas française, donc je ne connais pas le nom en français) et sur Mac il y a un "visualiseur de caractères". Pour voir certains caractères Unicode, vous devez installer la fonte Unifont (qui est aussi utilisé par Minecraft et OpenComputers). Surtout sur Windows il y a beaucoup de caractères qui ne sont inclus dans aucun des fontes défaut.

(Pardon si mon français n'est pas le meilleur, ce n'est pas ma langue première )

If you ask me, writing to an EEPROM chip is not that hard:

• Write your BIOS in Lua
• Stick an empty EEPROM chip into your computer
• Run flash yourbioscode.lua
• Take out your EEPROM (and put the old one back in, otherwise your dev computer won't start)

Or if you want to do it from Lua:

local component = require("component")
component.eeprom.set("-- your BIOS code here")

Writing data to an EEPROM is not hard, it's writing a program in only 4 KB with only basic APIs that's difficult. The reason for that is that you're not programming an Arduino, you're programming a computer on its lowest level. I don't know Arduino much, but I assume that you can write Arduino programs with more high-level and easy-to-use libraries than a BIOS.

First question:

Why must I have this at the beginning of the code to call commands?

local robot = require("robot")

Unlike in ComputerCraft, not all APIs are loaded into the global namespace by default. Lua itself provides a few standard functions and libraries in the global environment, but anything other than that must be loaded using require. In the case of robot the library is actually loaded from a file /lib/robot.lua, like many other of OpenOS's libraries. It would make no sense to automatically load all libraries in /lib when the computer starts. Not only would it make the OS take a lot longer to load, it would also be quite messy.

Issue:

When I start off with a simple

robot.swing()
robot.forward()

the robot will not move forward after it finishes swinging. However if it says to move back it will move backwards.

Most robot commands won't generate a Lua error and stop the script when they fail for some reason - not every failed robot command is a programming error. Instead they return true if the command succeeded, and false plus an error message if it failed. To see the return value, wrap the robot command in a print call:

robot.swing()
print(robot.forward())

In Lua, variables declared local are only local after this declaration. For example, in this code block:

local function early_use()
    return later()
end

local function later()
    return 42
end

print(early_use())

The use of later in the early_use function refers to the global later, because it has not yet been declared local, and in Lua all variables are global by default. Because there is no such global, the function will error out.

To change this, you need to declare later as local before you use it the first time. You also need to remove the local from the definition of the later function - otherwise it will create a new local variable that is also named later, but is not the same as the first later. It is good practice to put a comment on both the forward declaration and the definition afterwards - it is not very clear what the local later does if you don't know the code, and the function definition later on might look global if you don't remember the early local declaration.

local later -- Forward declaration, function is defined later

local function early_use()
    return later()
end

-- later was declared as local earlier
function later()
    return 42
end

print(early_use())

This code block should properly print 42.

Of course all of this should only be done if you actually have to use a variable before it is assinged a value. If you can swap the two function definitions without breaking the code, you should absolutely do that instead.

Because it was probably uploaded as a guest, and Pastebin doesn't keep guest pastes forever. By the way, if you want to know the maximum resolution of a GPU, use gpu.maxResolution().

OpenComputers' filesystem contents and computer state is stored in a "opencomputers" subfolder of the world, make sure that that folder has been migrated over and that the server has read and write permission for it.

What I was thinking with point 1 was a continuous sequence of objects (with no nils in between) that stores one clear display order - basically an ordered version of objects that replaces layerT. Because every object has a single position in the display order, and two objects never have the same position, there can be no z-fighting.

Both systems have their advantages - the current one means that you can set a layer number for an object that will never change, but looping over all layers isn't as easy. The single-display-order one means a clear ordering of objects and easy iteration, but moving objects around in the display order could be confusing, because other objects' indexes would change.

Had some time to look through the GUI.lua source code, so here come my usual questions/complaints/suggestions:

1. An idea about layers - make layerT a sequence of objects. One layer == one object, which means no z-fighting (in the tech demo, move the two squares into the same layer, then move both of them around). Use table.insert to move objects/layers around inside layerT. This would mean that layer numbers would not be absolute - they would change with the order of objects - but it would be much more efficient to loop over layerT.

2. I'm not entirely sure what the objects table is good for - what is the advantage of tracking all objects? The ones that are displayed are already stored in layerT (or subsequences) so there's no risk of them being removed.

3. What is this "request handler" thing about?

4. opt_res can't work perfectly because of an unclarity with the screen.getAspectRatio method. See MightyPirates/OpenComputers#1284.

This might be what you're looking for. I've added comments (like -- comment) in many places to explain what the code does, you don't need to copy them into your program.

-- Open the file statistics.txt in "w" (write) mode. This will overwrite existing files!
local f = open("statistics.txt", "w")

-- Run this loop 10 times and increase i each time
for i = 1, 10 do
  local a, b, c = -- This data needs to come from your reactor
  
  -- table.concat converts a table to a string, with a string (in this case ";") added between all elements
  local line = table.concat({i, a, b, c}, ";")
  
  -- Write line to f and add a newline at the end
  f:write(line .. "\n")
  
  -- Wait a second between measurements
  os.sleep(1)
end

-- Close the file
f:close()

Not quite. Backslash escapes (like \n for newline) need to be inside the string, like "first line\nsecond line". It is important that you use a backslash (\), not a forward slash (/). Wikipedia tells me that on AZERTY keyboards the backslash is on AltGr + 8.

sorry, it isn't this rotate, I would want that the program executes the hologram in continuous rotation

You could read the entire hologram into memory and write it back to the projector in a different rotation, but that would not be very fast. There's also no way to rotate holograms in anything except 90° angles, so a continuous rotation wouldn't look very nice anyway.

If you want to "combine" multiple projectors, you need to do that manually in your program. OC has no built-in feature to link up projectors and make them act like one. The projector size can probably be changed in the config if you want.

Files don't know "lines", they are a sequence of bytes. You can use file:seek(pos) to move the current position, then the file:read and file:write functions will start reading/writing from that position. (Note that those two functions also move the current position to where they stopped reading/writing.) You'll need to manually find where line breaks ("\n") are though.

By the way, if you want to display a number as hexadecimal, it's much easier to use string.format:

("%x"):format(256) -- = "100"

But as said above, color values aren't strings, meaning that you don't need to convert them to any specfic number format. 0x100 and 256 are both of the type number and are equal.

Never use globals in Lua. Lua globals are evil. Lua globals want to take over the world and enslave humanity. Every time you use a global in Lua, Hannibal Lecter violently murders a kitten.
 
*ahem*
 
The problem with globals is that they stick around even after the program is done running. Locals are automatically deleted when they are no longer accessible (i. e. when the function/program ends and they aren't stored elsewhere), but any object assigned to a global takes up extra memory until the global is reassigned. This can also cause odd bugs in other programs that run afterwards, which is the other big reason why you should never use Lua globals.
 
Looking through the first few functions, there are a few things that definitely should *not* be global:

• tmp and tmp2 are set to nil after the three for loops anyway and can be safely made local.
• inProgress, index, craftables, items and failed should all be local. If you need to see them for debugging reasons, make getters for all of them, like you did with p.listTasks and p.listFailed.
• local getIdent: ret is not meant to be used elsewhere and should be local.
• p.initialize: f only seems to be checked once in an if block at the end of p.produce. Since p.produce is never used outside of p.initialize that block should never run. Just write handler.addTask(p.produce) and see if that works.
• p.produce: me should be local.
• p.produce: Near the end last_i could be left out entirely, just reuse it.
• check_time and check_production should be stored in p.

None of these look like they would cause any major memory leaks though. In any case, I'd try making all variables local to see if that helps. If you use locals for everything, you shouldn't need to worry about manually setting them to nil, especially in functions.

But... that's just one beep at a time, ten times in a row. (If computer.beep doesn't block while the tone plays, you can always use os.sleep.)

Maybe computer.beep is enough for you.

Did you mount the hard disk at /hdd yourself? Boot from the floppy disk, and if the HDD still mounted there, try unmounting it (with umount /hdd) and then try to install OpenOS again.