dgelessus

This may or may not be related to your problem, but you're running OpenOS from the read-only floppy disk. Try running the install program to copy all OpenOS files to the hard drive, restart and boot from the HD (take the floppy out of the drive to be sure) and then try to install OPPM again.

You need to have the raytracer library installed, download it and put it in your /lib or /usr/lib folder.

Files on Pastebin expire after some time if uploaded by unregistered users. If you want to keep your code for more than a week, use GitHub.

re. deflate: There is a new item in the works, the Data Card, which provides various hash functions as well as base64 and deflate codecs in component form. At the moment it is still an open pull request to the OC repo, but it seems to be mostly finished from the technical side. No idea when it will get merged, probably once the comment section is done arguing about how the corresponding Lua libs should be distributed

Line endings may be the same to Lua, but they might not be to the compression code. For instance, if I were to replace all instances of "local " with "\0\13" and put that in a long string and read it in, my algorithm would break. (\13 is \r)

That makes sense. I guess you could include the number 13 in the dictionary and always map it to e. g. an empty string, but never actually use it in any "compressed escape" sequence. That appears to be the only character that is treated specially in long strings. The short test

for i = 0, 255 do
    fn, error = load("return [[>" .. string.char(i) .. "<]]")
    if fn == nil or fn():byte(2) ~= i then
        print(i, fn and fn():byte(2) or error)
    end
end

only produces the output

13      10

meaning that all other characters should be safe to use. The only other problematic cases are \n at the start of the string (which is ignored) and ] at the end of a level 0 long string (which causes a syntax error). The former shouldn't cause any real issues when compressing text, and the latter can be prevented by increasing the level of the long string.

actually, \n and \r characters at the begining and end will be striped out, and \r will be converted to \n

True, it does assume that the contents are text. For Lua code that shouldn't be an issue though - leading newlines don't matter, and line endings are all the same to Lua.

Or use [[raw multiline strings]], which take all characters literally, except for the closing brackets. This is even possible if there are such strings in the code itself - Lua allows you to add any number of equals signs between the two brackets, and they will still be valid, as long as the opening and closing ones use the same number of equals signs. For example, the text

This string has [[brackets]] in it for some reason.

[=[This string has [[brackets]] in it for some reason.]=]

Interesting idea. The only issue is that the epsilon, lambda and fancypants-s are non-ASCII characters and take multiple bytes when encoded as UTF-8:

Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] on win32
>>> len("Ελ∫".encode("utf8"))
7
>>> "Ελ∫".encode("utf8")
b'\xce\x95\xce\xbb\xe2\x88\xab'

Though I guess two or three bytes are better than three (end), five (local) and eight (function). Alternatively you could use ASCII characters that are not allowed in Lua code, like !$?`@ or some control characters.

By the way, it isn't possible to do attribute access with . or : on literals (e. g. 42.5, "string", [[long string]]). The literals need to be wrapped in parentheses:

Lua 5.3.0  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> "foo":len()
stdin:1: unexpected symbol near '"foo"'
> ("foo"):len()
3

If the keyboard is in the way, you can also e. g. place it behind the screen. Last I checked you can even place the keyboard on the screen by sneak-placing it, and you're still able to use keyboard input when right-clicking the screen.

How to edit the code? I tried it, I unpacked the files, changed the line, but now I don't know how to change it back to a .jar file, and google can't help me either. But I can't edit the .jar file without unzipping it. Could you guys tell me how it works? Thanks

That's not how you should edit a mod's code. Unless you fluently speak Java bytecode you shouldn't be editing the jar file, there's nothing you could understand or change in a useful way. In any case there's no need to modify the mod's code. Everything you need to change is in the config files, which are by default at .minecraft/config/opencomputers.

By default hard drives don't have any data on them, so the server has nothing to boot from or run. The EEPROM chip only checks each file system if it is bootable, it doesn't provide an actual operating system. You probably want to install OpenOS, the procedure to do that is the same as with a regular computer. Connect a disk drive (make sure the server rack's sides are set up correctly, the server can only access components on the side that its slot is assigned to) and insert an OpenOS boot disk. Start the server, connect to it with a remote terminal. Run the install command and select the hard drive you want to install OpenOS on (hold shift while hovering over the hard disk item to see its address). Now shutdown the server, disconnect the disk drive, and the server should be able to boot from the hard drive.

If ported over directly the program wouldn't work correctly, due to OC robots having a flight height limit of 8 blocks above ground. That can be increased using Hover Upgrades, though those might not yet be available in the latest stable release. There is also a "dig" program included in OC, which can be found on floppy disks in loot chests. (Or you can copy-paste it from the GitHub repo. )

As I understand it robots are intentionally unable to use external components. The different computer types all have their own features and limitations, but are all meant to be equally useful, and not one superior to the other. (Well, except for lower tiers being less powerful than higher tiers, of course.) Robots can move (relatively) freely and interact with the world in many ways, at the cost of only being able to use components hard-wired into them. A robot dock may be convenient, but it would basically make robots "computers that move". The only advantage of computer cases would be the ability to install and remove internal components without needing to disassemble and reassemble it, in all other aspects robots would be equal or superior.

A "computer hopper" would still only be able to transfer items from and to blocks directly next to it, anything more would require multiple blocks or robots. Using an entire robot just to shift a few items is kinda ridiculous.

Maybe there should be multiple tiers of "computer hopper" as well. Tier 1 is basically a glorified hopper that can pull (from above) and push (to a fixed side) on command. Tier 2 can handle stacks and reorganize its internal inventory to control which item to push next. Tier 3 can dynamically change input and output sides.

1. Global variables are evil. The only place where you can safely use globals is the interactive Lua shell, which runs inside its own sandbox. Everywhere else you should make all variables local. So far I've never had a situation where I needed to use globals, but I certainly had a few cases where I accidentally used globals instead of locals, which caused some hard to find bugs.

2. Variables are stored in RAM, which is very limited in OC compared to real computers. /tmp is a special filesystem, which (I think) does not count towards computer RAM usage.

3. It's a convenient place to put files when working in the shell without occupying space on the real hard disk.

4. It's guaranteed to be a writable location. The default OpenOS boot disk for example is loaded from the mod files and read-only, however you can still work in /tmp.

But i had to add this line to the user.recipes

Right - if you had an existing user.recipes file before the update, it won't be overwritten with the new version and it won't have the line by default. All the other .recipes are automatically updated though.

But is it possible that there is a Peaceful Recipe missing for Drones?

I think it's impossible to get to the End in Peaceful, isn't it?

It is possible to get Eyes of Ender by trading with villagers, then you can get to the End normally and slay the dragon. You need a bit of luck with finding the right villager, but who said that going to the End is easy? There was also a change recently that adds a recipe for end stone, which will be available in a future update. The default recipe uses ender pearls, but that could be changed in the peaceful.recipes.

Recipe sets can be enabled by editing the user.recipes file in config/opencomputers. Open it with a good plain text editor (such as Notepad++, default Windows Notepad will break things). There should be a line saying #include file("peaceful.recipes"). Remove the # before the include, save and start the game. The peaceful recipes should now be loaded. The other recipe sets can also be enabled this way, and you can also add your own recipe files if you want.

Wasn't the point of the OP that this side-based behavior should be allowed for non-server computers?

I'll need to check out cedit, that sounds useful, even if it may be slow. Have you considered putting your code on GitHub? That would make it easier to keep track of changes and version history. It would also allow viewing the code in the browser (without needing to download the archive) and people could submit pull requests (suggested code changes or additions, such as bug fixes).

• Removed hard coded aliases from shell.

Dunno, I haven't seen any Linux distro that doesn't do this. This would make more sense with the third change you suggested, then they could be part of the default config rather than /bin/sh.lua.

 

• Removed hard coded environment variables from os.
• Added persistence of environment variables to os in /etc/env.cfg".
• Added environment variable export command _{(for saving to disk)}.

 

Well, the point of envvars is that they normally aren't permanent. On a normal Unix you'd set "permanent" envvars in the appropriate profile script, but there is no such thing in OpenOS, so the boot files are the most logical place to put those. Some kind of profile.lua would make more sense IMO.

• Added LS_OPTIONS environment variable read by ls command _{(for default options)}.

Why not alias ls="ls --some --options --you --like"?

• Fixed os.setenv to check for empty strings as well as nil for deletion of environment variables.

AFAICT empty-string is a valid envvar value. What my real sh says:

$ env
[...]
TMP=/tmp
USER=dgelessus
_=/usr/bin/env

$ env FOO='bar'
[...]
TMP=/tmp
USER=dgelessus
_=/usr/bin/env
FOO=bar

$ env FOO=''
[...]
TMP=/tmp
USER=dgelessus
_=/usr/bin/env
FOO=

Note how the first env call lists no FOO (obviously), but the third one does, even though FOO is an empty string. Thus there is an extra --unset option for env:

$ env --unset TMP FOO='bar'
[...]
USER=dgelessus
_=/usr/bin/env
FOO=bar

If any of the above sounded harsh, I didn't mean it that way. I've given my feedback on the things that I would disagree with if they were added to base OpenOS. This doesn't mean that I find the idea in general or the other changes bad - consider my opinion on everything that I didn't reply to "Good idea, don't see anything wrong with that."

Huh, apparently rc is the only thing that has its config on the OpenOS disk, all other programs seem to generate their configs on first run. By the way, I wrote a modified version of install that accepts an --ignore option, and an update program to update OpenOS. I'll make a PR once I figure out how to git again.

There's also /etc/filesystem.cfg or whatever it's called, the one where you can disable autorun. If install doesn't copy directories destructively (i. e. delete any files that aren't in the source folder) then the rest should be okay though.

It's not just a memory thing - though memory is a much bigger concern on OpenComputers than on a real computer - using global variables for everything clutters the global namespace and can cause odd bugs if you use the same name in different places. Because every computer has a single global namespace for every script (unless the script is called using pcall, which gives it an own "global" namespace) this means that a global variable from an external library can "leak" into your program, or even into other libraries.

The green OpenOS floppies appear to load OpenOS directly from the mod files, so they always have the latest version of OpenOS on them. But what is the best way to update an OpenOS installation on a hard disk, which of course won't receive the update automatically?

Running install from an OpenOS floppy isn't a great solution, because that will overwrite config files under /etc, and possibly other things, depending on how destructive the installer is. Is there a way to make install copy only certain files?

If there's no good way to do this yet I might write up my own script to do this.

Den Forge-Installer findest du auf http://files.minecraftforge.net/. Ob du die Version für 1.7 oder 1.8 nimmst ist nicht allzu wichtig, nur müssen logischerweise der Client und der Server dieselbe Version haben. Dann lässt du den Installer zweimal laufen, einmal um Forge im Minecraft-Launcher zu installieren, und ein zweites Mal um den Server einzurichten.

Bevor du jetzt Mods installierst, solltest du einmal den Client und Server mit Forge starten, um zu sehen ob alles läuft. Um den Forge-Client zu starten wählst du einfach das Forge-Profil im Launcher aus, und den Server startest du indem du die Forge-Jar im Serverordner öffnest.

Wenn das alles läuft, kannst du Mods installieren, indem du die Mod-Datei in den "mods"-Ordner vom Client und Server kopierst. Der mods-Ordner vom Client ist standardmäßig unter %APPDATA%/.minecraft (den Pfad kannst du so in die Adressleiste vom Windows-Explorer eingeben), und der vom Server ist im selben Ordner wie die Forge-Jar.