dgelessus

In event.lua, computer.pullSignal is replaced with a wrapper that calls dispatch before returning the signal that happened. dispatch then goes through the handlers table and calls all listeners for the event that happened.

This is certainly *not* the intended behavior of the editor. Do you have Optifine installed? Optifine likes to cause issues like the text randomly changing color depending on previous output, maybe it's causing the flashing too.

Probably not. To be honest, the hs_err log files are basically useless unless you are the developer of the native library that's crashing (the graphics driver in this case) so I wouldn't worry too much about it. Any useful information will be in the Minecraft log files and crash reports.

I think that "trailing aeparator" thing refers to separators *in* the table braces (like {1, 2, 3,}). The issue here is (or at least might be) that there is a comma *after* the closing brace

Maybe you need to remove the trailing comma from the lines - every line except the last one has a comma at the end, and a trailing comma isn't valid table/serialization syntax, that would explain why only the last line loads.

OpenOS doesn't have proper support for multiple monitors built in. Last time I tried there were even some issues where a different screen might be used during early boot than when the OS is running, though that is kind of random and might also have been fixed. Having two monitors isn't as useful as in real life either - OpenOS is just a command line, there's no real use for the second monitor since you can't put anything on it. And you can only open one monitor's GUI at a time, so switching between them is kind of a pain unless you use them in touch-only mode without their GUI. If you want t

Java's Unicode support is a little weird, its char and String types use UTF-16 code units, which means that any characters above U+FFFF are likely to be messed up. Although on the Lua side OC uses UTF-8 to store Unicode, the text still goes through Java/Scala a lot, so you may still have some issues with Unicode characters higher than U+FFFF.

I think this is because of the library that Minecraft uses to read keyboard input, which doesn't work properly with certain keys on non-US keyboards. On my German keyboard for example, the < key (which I think is where your \ key is) registers as "NONE" in the Minecraft controls options. The same goes for the key codes from the key event. IIRC the key event also includes the typed character in one of the other event data values, which should match the actual keyboard layout, maybe you can check against that.

That is not valid Lua code (you have one end too much). Can you post the full code that's causing the problem? Also by the way \n\r is not a valid line terminator. On Unix-like systems (including OC) you'd just use \n, and the Windows default is \r\n. Arrays in Lua are indexed starting at 1. Lua doesn't have a dedicated array type, it only has table, which is a mapping/dict/object/whatever, so accessing element 0 doesn't produce an error. In the OpenOS shell you can use normal Unix pipes, like mycommand > output.txt.

To load a library like robot, you need to write local robot = require("robot"). It's not enough to write just require("robot"), that loads the library but doesn't store it in a variable, so it effectively does nothing.

No, there's no way to make a hard drive or floppy disk read-only. The only thing you could do is write a custom operating system that doesn't allow writing.

Wipe the HD on which you installed the OS (by putting it into a crafting grid) and use the OpenOS floppy to boot. Hard disks are always writable, and floppies added by the mod (such as the OpenOS floppy) are read-only.

Do other blocks from the mod work? (i. e. is Forge/OpenComputers installed properly?)

edit <filename> in the OpenOS shell. Other than that, it's just a basic plain text editor.

If you want to register a function to be called whenever an event of a given type happens, you can use the event API (specifically event.listen).

The OC wiki uses DokuWiki and not MediaWiki as far as I know. FWIW, I'm one of the sysops of ftbwiki.org aka atlwiki.net, and we use some MediaWiki/IP.Board bridge. I don't host the site, so I don't know if there are multiple plugins like that and which one exactly we use. All I know is that we've used it for years and never had any real issues with it.

And for me it's broken on OS X and Windows. If it matters, I'm using Firefox Developer Edition (the preview/beta-ish version of Firefox), not sure if that makes a difference. The Cmd-click issue has been like this for a while now, so any changes related to that should be in release Firefox too.

Middle-click works fine for me in Firefox, but Ctrl/Cmd-click still has the behavior that the OP described. Trackpads don't have middle-click, so I need to use Ctrl/Cmd-click when I use my laptop without a mouse plugged in.

Wouldn't it be nicer to put the addons above the "off-topic and fun" section? Dunno what others think, but to me anything below the off-topic section(s) on a forum feels like "there's nothing interesting here, no need to read this". It's a good place for "locked thread archives" and such, but not for normal on-topic forums.

As I said, I was referring to running cmd.exe under OC. That would require something Windows-like (I assume cmd.exe cannot run on MS-DOS or a variant). Other than that, yes, Linux is probably the most logical OS to try to run under OC. Maybe I should stop talking, I am kind of tired. If my posts make no sense or I sound rude, please don't take it personally.

By "proper" I meant "current", regarding the question whether cmd.exe could run under OC. Yes, MS-DOS is a functional operating system. Not really a good candidate to run on OC though, because it's not freely available - you'd need to actually own a copy of MS-DOS, and a real working floppy drive to read it. The newest you could use is MS-DOS 1 or 2 available in source and binary form from here.

Which one is that? If this is the only change that needs to be done, then there's no need to replace the OpenComputers jar file. You could simply install OpenOS from the OC 1.6 floppy, then download the old system file by hand and copy it over the new one. Then people who can't/don't want to replace the mod file can use the fix too, e. g. when playing a modpack or on a server.

OpenComputers doesn't emulate any real CPU architecture and it's also not a virtualization environment like VirtualBox, so you can't directly install any "normal" operating systems or run Windows exe files or Linux/OSX binaries. The lowest level you can get is writing a custom BIOS on an EEPROM chip, but even that uses Lua. It is theoretically possible to write add-ons that add additional languages to write your BIOSes in, and there have been attempts to write such add-ons for real CPU architectures like ARM, but those are all in their "alpha" stages. Besides, in a Minecraft mod you do not hav

Can you tell us what exactly you changed in the jar file? If it's an actual bug in OpenComputers, please report it on its GitHub page or make a pull request.

Unless I'm mistaken the OpenOS command line has some aliases for DOS commands by default, such as dir for ls. I doubt proper command.com/cmd.exe emulation will ever be a thing though. MS-DOS/Windows Batch lacks a number of useful features - it doesn't have functions, if and for are very limited compared to the Unix shell, variable expansion and quoting behave oddly, pattern expansion is not done by the shell but by the commands. And Windows's backward compatibility features would need to be emulated too, like 8.3 file names, case insensitivity, \ instead of / in paths, / instead of - for comma