Archive for the 'Computers' Category

Vive Linux

Monday, December 5th, 2016

I’ve got a HTC Vive, and I managed to get it to work, and – more importantly – to get several applications to work with it.

Kernel

The Vive comes with a link box that connects to USB and HDMI, so you need to have some drivers compiled in. The following might be somewhat nonstandard, or at least I haven’t had to use them before I got the Vive.
CONFIG_USB_HIDDEV=y
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_HDA_CODEC_HDMI=y

Also, you need to give your user some permissions on these devices via udev-rules. The debian-package steam-devices will actually install one, but apparently this is not enough, thus:
ACTION=="add", KERNEL=="hidraw*", ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="2c87", TAG+="uaccess"
ACTION=="add", KERNEL=="hidraw*", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="2000|2101", TAG+="uaccess"

Or something thereabouts. Using TAG+="uaccess" is the modern version you should use instead of MODE="0666" or somesuch.

X11

I actually wasn’t able to tell my system it should use the DisplayPort first, if a HDMI device was plugged in. So I need to boot first, and only then plug in the HDMI cable to the link box. This also has the effect that my X11 usually has no idea about the Vive, and it needs to be activated to work. You can set the Vive display as active in nvidia-settings (for nvidia, GPUs obviously). This looks like this then:
$ xrandr --listmonitors
Monitors: 2
0: +DP-0 1920/477x1080/268+0+0 DP-0
1: +HDMI-0 2160/122x1200/68+1920+0 HDMI-0

Building Vrui

The first thing I read about anything working with the Vive on Linux, was this post: I Am Using VR on Linux with My Vive and Vrui. I actually had tried an earlier version of Vrui before, but failed. But 4.2-006 actually works. However, there are no debian-packages, it’s not even available to clone from some RCS, there seems to be only a tar-ball, and along with it even a bash-script to build it.

Since I think bash-scripts and wget to build software is 1980ies I only followed it somewhat. First, get dependencies:
apt-get install build-essential g++ libudev-dev libdbus-1-dev libusb-1.0-0-dev zlib1g-dev libpng-dev libjpeg-dev libtiff5-dev libasound2-dev libspeex-dev libopenal-dev libv4l-dev libdc1394-22-dev libtheora-dev libbluetooth-dev libxi-dev libxrandr-dev mesa-common-dev libgl1-mesa-dev libglu1-mesa-dev libxine2-dev
Note the libxine2-dev which the script doesn’t install.

I then edited the makefile, where I changed a load of hard-coded variables around, and also set known paths like STEAMVRDIR to where I knew it would find it, because it would otherwise do find over my home-directory.

As it turned out, my build environment was also too new, it bombed on the C++ 11 ABI. I had to put
CFLAGS += -D_GLIBCXX_USE_CXX11_ABI=0 into the makefile. And since we’re on it, put it into ExamplePrograms/makefile as well, but take care that it goes below the include-statements.

After compiling and installing, it’s ready to run. If you haven’t installed the udev-rules yet, Vrui comes with some decent ones. And you can also change directory to ExamplePrograms, and build and install these as well. And copy over the Share/RunViveTracker.sh to where its useful.

Running Vrui

First off, start RunViveTracker.sh and keep it running.

Now you first want to run EyeCalibrator -rootSection Vive, which will display a window within the Vive, that will show you to how many millimetres you set the interpupillary distance with the knob on the right of the Vive. Read Technology Transfer for more information.

The next thing is RoomSetup Vive. Note that you don’t want to set a rootSection here, as you want it to display on the desktop. Vive la Vrui! will basically walk you through this. The room setup will define the area for the Screen Protection (that is the green wireframe) which will pop up if you move too near to the room borders.

After that, you’re ready to go, to use something like ClusterJello -rootSection Vive. See I Am Using VR on Linux with My Vive and Vrui for more.

VruiXine

If libxine2-dev was already available while building the Vrui examples, VruiXine should already have been compiled. As usual, it’s started with VruiXine -rootSection Vive, if you want it to use a different audio output than pulseaudio, you can set that with -ao alsa or something like that.

For me, VruiXine always starts with the window at an angle about three metres to the left. Upon clicking on “theatre”-mode in the menu, this gets fixed and the window is in front of me. Or I can start it with -vo theater (careful: American spelling: “theater”). Also menus appear in five metres distance initially, but pulling them up again will subsequently display them near me and readable. The “Save”-button in the DVD menu, will save the streaming settings and display mode (window/theatre), but not the window size and position, and it will save it into the folder the movie is in, with the name of the movie and .cfg added. So all the settings are movie-specific.

Also, unless you’re sitting in the middle of your VR space, you might need to disable the Screen Protector lest you constantly have green wire frame in your movie. Apparently you can do this in the menu “Vrui System”->”Devices”, but I just set screenProtectorDevices ( ) in ~/.config/Vrui-4.2/Vrui.cfg.

You can see which config-files are used by starting it with the -vruiVerbose flag.

See also the “Watching Movies” section on Vrui on Oculus Rift DK2

CaveQuake

CaveQuake is a Quake3 map viewer that sets up on Vrui. See Quake III Arena Maps in VR, under Linux, with Vive+Vrui on how to set this up.

One important thing to note is that here as well, I had problems with the C++ 11 ABI. In the installed share/Vrui-4.2/make/BasicMakefile I put in EXTRACSYSFLAGS += -D_GLIBCXX_USE_CXX11_ABI=0 So everything compiled against Vrui in the future would get this flag set. For CaveQuake itself, I also did set export EXTRACSYSFLAGS += -fPIC temporarily to compile.

The controls you get with “Walk” are this green thing on the floor, which is meant to be leaned on/off to move you. Which is really made for use in a Cave, and not in a Couch. Sadly, I have not yet found any option to control movement via keyboard, or even via those Vive controllers.

Apparently, most menu items in the Vrui control menus are really not menu items, but tool bindings, things you can bind to your controllers, save with “Vrui System”->”Devices”->”Save Input Graph” and load with -loadInputGraph on the commandline. Still, I don’t quite understand how this works.

Vivecraft

Vivecraft on Linux

Vivecraft on Linux

There is a Minecraft mod for using the Vive, called Vivecraft. You can get it from https://github.com/jrbudda/Vivecraft_110 but I haven’t been able to build it myself yet. So I used this: vivecraft-1.10.2-Vivecraft-jrbudda-6r4-installer.jar.zip
There are some other versions flying around, but they may lack the native Linux libraries. Also, you need Minecraft of course.

Now, in order to get this working, I needed the 64bit versions of the SteamVR libraries driver_lighthouse.so and libaitcamlib.so. The main problem were dependencies, since my system does not usually have such outdated libraries as libudev.so.0. The first attempt was to use the Steam-environment, but that includes dozens of outdated libraries, which in turn resulted in java not working. So I symlinked only the necessary libraries to where they were needed:
cd ~/.steam/SteamApps/common/SteamVR/bin/linux64
ln -sf ~/.steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libudev.so.0.13.0 libudev.so.0

And wrote a little startup-script:

#!/bin/sh
DRIVERDIR=~/.steam/SteamApps/common/SteamVR/drivers/lighthouse/bin/linux64
COMMONDIR=~/.steam/SteamApps/common/SteamVR/bin/linux64

export MESA_GL_VERSION_OVERRIDE=4.1
export MESA_GLSL_VERSION_OVERRIDE=410
export __GL_SYNC_DISPLAY_DEVICE=DFP-5

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$DRIVERDIR:$COMMONDIR
cd ~/.minecraft
/usr/lib/jvm/java-8-openjdk-amd64/bin/java -Xms2048M -Xmx2048M -jar Minecraft.jar

You might need to change that DFP-5 there, that’s the HDMI port your Vive sits on.

With that, it starts, and as long as the Vive can not see the base stations it displays the main menu. However, when I put it on, the menu is only visible up to the far right. There’s a “Reset Origin” menu item, and if you place your mouse on that before putting on the Vive, and click on it afterwards, Vivecraft kinda works. You can walk around, destroy and place blocks and so on. All with you mouse and keyboard. What’s not working for me is the menus and inventories, as I suspect they pop up somewhere where I can’t see them.

See also the issue on github.

The Biggest Threat to Cyber-Security is Surveillance

Thursday, September 8th, 2016

The biggest threat to cyber-security is surveillance. Or rather the will, ability and legal status of organisations who prioritise surveillance and active attack abilities above defence and security.

The point is, that surveillance does not mean passive wire-tapping. It means attacking infrastructure where the data you want is available unencrypted, or infrastructure through which the message or data travels. Infrastructure which might not be under control of the entity trying to gain these surveillance-capabilities. For instance it might target the sender or the recipient of an encrypted e-mail or instant-messenger message. Or an intermediary, in order to know who communicates with who in the first place. All these actions are not comparable with passive wire-tapping, in fact, these attacks are indistinguishable from hacker-attacks aimed towards any other goal, like the enactment of botnets; and they also enable the attacker not just to eavesdrop, but to do whatever else he pleases, from launching man-in-the-middle attacks to denial-of-service, ransomware, attacking somebody else and so on. So surveillance is an attack as any other.

The problem now stems from the fact, that in order to attack somebody, you need knowledge of insecure systems, vulnerabilities, on their part. Typically, what you use are exploits, and if they’re not published yet, they’re called zero-day-exploits. Now, as long as you don’t tell anyone, these vulnerabilities don’t get fixed. They might be found by somebody else, and published or not. As soon as they get published, they loose their value for attack. Now, during that period when you have a zero-day-exploit on your hands, you might mitigate that vulnerability on your systems. But you actually can’t mitigate them on all systems of your allies, because then the secret would go out. So you don’t. Which leads to one outfit having knowledge of vulnerabilities leaving every other outfit at risk.

In a practical example, 2013 a server was hacked, that was used by the NSA as staging system for attacks. The Shadow Brokers hack was made public only in 2016, and it turned out, the NSA had stashed a load of zero-day-exploits there, some of which were still zero-days in 2016, but the majority of them had already been made public. Now, not only illustrates this that independent researches will find these “secret” vulnerabilities eventually, but also something much more sinister: The NSA had actually put every other US-agency, including FBI and DOD, the government, critical infrastructure (including power plants, water supply and hospitals) and finally all its own citizens at risk.

With all the secret services world-wide, and often also police-units (For instance, the Zürich Police bought surveillance software from Hacking Team containing three zero-day-exploits) involved in ramping up their cyber-attack-capabilities, most often with the goal of surveillance, we can see an extreme effect on creating a market for zero-day-exploits. Where fifteen years ago no noticeable market existed at all, we now have one whose prices start at USD 40’000 and go up to USD 500’000 per exploit, as evidenced by the price-list published by Zerodium In other words, secret services and police are actively undermining the security of everyone on this planet, friend and foe alike.

The trouble is, highly technological societies are much more vulnerable to this. For guerillas, insurgents and terrorists the benefits of being able to exploit vulnerabilities is much greater, and they don’t really have to defend any friends from such attacks. So the ones that suffer the most, are the people and governments of exactly the same nations and states whose secret services and police are actively undermining their security. This is a grave situation, as most governments have not even realised what it is they have their secret services and police doing, and are actively trying to destroy their own security with initiatives that call for weakening of crypto or for government back doors. Or at least, trying to explicitly legalise these practices as seen with Switzerlands NDG, which of course will have a very much adverse effect of security.

The solution is surprisingly simple, the only impediment is, as usual, the widespread incomprehension of the problem itself. Since every vulnerability that is made public eliminates the exploitation of it for everyone, the only solution is to make every vulnerability public as soon as possible. The usual, and in fact “best practice” of the computer industry, is called “responsible disclosure”, where the manufacturer of a software or product is informed a few days or maximum weeks in advance, so he can fix the vulnerability, before the issue is made public. And in the end, it’s the only solution that will really make us more secure.

Minecraft: Item Sorting System

Sunday, May 22nd, 2016

This is not a new concept, instead it is just an implementation of a massive item sorting system in Minecraft. I already posted this on planetminecraft, but I thought it would be sensible to post it here as well.

  • Can sort up to 432 stackable items
  • Sorts out non-stackables into separate chests
  • Sorts out potions into separate chests
  • Overflow-protection, sadly, somewhat noisy
  • Filters are already pre-configured, but chests are (mostly) empty
  • The load/framedrop comes from the item frames, not the hoppers or the
    pistons
  • two manual inputs, one for items to smelt/cook, one for the rest
  • two input hoppers to connect farms
  • incorporates workspaces, brewing stands and enchanting area, and has
    some little space left for more
  • footprint 56x56x10, the schematic is a bit bigger to accomodate for
    the floor and the inputs from farms
Item Sorting System - Overview

Item Sorting System – Overview

Item Sorting System - View From The Entrance

Item Sorting System – View From The Entrance

Item Sorting System - Upper Maintenance Floor

Item Sorting System – Upper Maintenance Floor

Item Sorting System - Brewing Stands

Item Sorting System – Brewing Stands

Item Sorting System - Enchanting Area

Item Sorting System – Enchanting Area

Of course here’s

The license is CC-by-sa.

Minecraft: Silent Dropper Item Elevator

Sunday, May 22nd, 2016

This is an older design of a silent dropper item elevator. It’s not initially by me, but it could be that I modified it. Still, I think it’s one of the best designs, because:

  • silent
  • items can be inserted at any level
  • Either has a footprint of 2×9 or can be arranged in an L-shape.
Silent Dropper Item Elevators, Front

Silent Dropper Item Elevators, Front

Silent Dropper Item Elevators, Back

Silent Dropper Item Elevators, Back

It does have a problem, and that is that sometimes the dropper(s) that get fed with items can get filled up and stuck.

Anyway, here’s the schematic:

Windows Unity-Games on Linux

Wednesday, January 13th, 2016

The fact is, beginning with Unity 4, just about all games run on Linux as well. Unless they’re buggy, explicitly check for the platform or use plugins not available on Linux.

I found this Howto in Russian on how to fix an incomplete Unity runtime so it runs on Linux, could reproduce the effects, and so here’s the writeup in English on how it’s done.

This is how the minimal Unity-runtime for Linux looks:

├── player_Data
│   ├── Mono
│   │   ├── etc
│   │   ├── x86
│   │   │   └── libmono.so
│   │   └── x86_64
│   │   . └── libmono.so
│   ├── Plugins
│   │   ├── x86
│   │   │   └── ScreenSelector.so
│   │   └── x86_64
│   │   . └── ScreenSelector.so
├── player.x86
└── player.x86_64

The word “player” is replaced by the actual name of the game. Note that these files are the same for every game that uses the same Unity version.

Find Version

Within the existing player_Data directory, you’ll find a file named mainData. This contains the Unity version, and you will need to add the correct version of the Linux runtime, so you’ll first need to extract that version:

head mainData | strings | head -1

if this doesn’t get you the version, the game uses a very old Unity, which has the version information towards the end of the file, but for which no Linux support exists anyway.

Get runtime

Now you need to find the correct runtime. You can check mainData of Unity games supported on Linux, and copy the respective files over. Something like this:

find . -name mainData -print0 | xargs --null grep --with-filename "4.5.5f1"

of course, some people already have collections of runtimes, like this: https://cloud.mail.ru/public/6SdA/BBgyg3kjy

if the runtime you need isn’t available on your system, you can extract it from the official releases with 7z. The not-so-nice part is, every release comes as a huge .exe with a size of 1GB or more. And there are a lot of releases:

The useful files within the extracted release are below linuxstandalonesupport/Variations/ you’ll need the files libmono.so, ScreenSelector.so and LinuxPlayer per 32bit/64bit environment.

Find Plugins

After you have all the files from the runtime in the right places, and have renamed them accordingly, you might have noticed, that there are some dll-files in the Plugins directory. You’ll need to add Linux versions for most of these.

Luckily, there are some very well known plugins, they are used all over the place, and some come with the source as well:

The .unitypackage-files can be extracted with tar xvaf, but they consist of a salad of directories. file */asset can tell you what is what, the corresponding filenames are in */pathname.

Fix .unitypackage files

The .unitypackage-files a lot of plugins are delivered in can be extracted with tar xvaf, but they consist of a salad of directories. file */asset can tell you what is what, the corresponding filenames are in */pathname.

This here makes a directory tree from the pathname files:
for i in *; do mkdir -p `dirname $(head -1 $i/pathname)` ; done
And this here moves the assets into it and renames them:
for i in *; do mv $i/asset $(head -1 $i/pathname) ; done

Cosmetics

You now can do some cosmetics. Fix the ScreenSelector background:
convert ScreenSelector.bmp ScreenSelector.png
And the Icon:
wrestool -x --type=14 Game.exe | convert ico:-[6] Game_Data/Resources/UnityPlayer.png

Testing

Start the game with a logfile parameter to get warnings about missing libraries and other problems:
player.x86 -logfile out.log
As mentioned before, “player” needs to be replaced with the actual name of the game, and the binaries named accordingly.

Results

I basically went over my whole collection of not-yet-available for Linux Unity games I have on steam. I annotated the runtime version and troubles they might have.

Working Games

  • 1954 Alcatraz (4.0.1f2)
  • Coldfire Keep (4.3.4f1)
  • Dead Bits (4.1.3f3)
  • DeadEffect (4.6.0f3)
  • Depths of Fear Knossos (4.6.1f1)
  • Final Dusk (4.6.1f1)
  • Gravi (4.5.5f1)
  • Huntsman The Orphanage (4.2.2f1 needs LD_LIBRARY_PATH for libsteam.api.so)
  • Last Inua (4.2.2f1)
  • Lifeless Planet (4.6.7f1)
  • Once Bitten, Twice Dead! (4.6.1f1)
  • Overcast – Walden and the Werewolf (4.1.3f3)
  • PaperSorcerer (4.1.5f1)
  • Red Lake (4.3.4f1)
  • StickItToTheMan (4.3.2f1)
  • The Dead Linger (4.6.0b20 Some black textures)
  • The Hat Man Shadow Ward (4.3.4f1)
  • Train Town (4.5.0f6)
  • Urja (4.5.4f1)
  • YearWalk (4.5.5f1)

Games Having Trouble

Most of these run, but are also unplayable. Some are playable, but not enjoyable because of missing textures or missing sound.

  • Air Buccaneer (4.2.0f4 can’t connect to network?)
  • BridgeProject (4.5.3f3 x86 crashes, x86_64 does not accept input)
  • Dead Island Epidemic (4.6.1f1 libs missing, among them http://www.squaretangle.com/FMODUnity.html)
  • Deus Ex The Fall (4.3.4f1 needs LD_LIBRARY_PATH for libsteam.api.so; Wwise sound engine wrong version, playable)
  • Empyrion – Galactic Survival (5.2.3f1 hanging?)
  • Joe Dever’s Lone Wolf (4.5.4f1 self-written plugins)
  • Melissa K and the Heart of Gold (4.5.3f3 hanging?)
  • Might & Magic X – Legacy (4.2.2f1 hanging?)
  • realMyst Masterpiece Edition (4.5.5p4 broken menu, needs uWebKit)
  • Slender – The Arrival (4.5.1p3 Texture problems, playable)

Shader Problems

The following games all have shader problems. Which basically means you would need to decompile Managed/Assembly-CSharp.dll and replace the shaders to use there, or to extract the .asset-files and create them anew. Some of these games are playable as they are, but certain things will show up pink.

  • Astral Terra (5.1.2f1 Shader Problems)
  • Avenging Angel (5.1.0f3 Shader problems)
  • Godus Wars (5.2.2f1 Shader problems)
  • GunsNZombies (5.2.2f1 Shader problems, crashes)
  • Reign Of Kings (5.1.1p2 Shader problems, needs LD_LIBRARY_PATH for libsteam.api.so)
  • StarForge (4.5.5f1 Shader problems, needs LD_LIBRARY_PATH for libsteam.api.so)
  • The Forest (5.1.3p3 Shader problems)
  • The Tower (5.1.2f1 Shader problems)
  • Treeker – The Lost Glasses (5.1.2f1 Shader problems, playable)

Broken on Purpose

  • BlockStory (4.6.8f1 Steam-Error: “Not available on your current platform”)
  • Magnetic Cage Closed (4.3.4f1 Steam-Error: “Not available on your current platform”)
  • Republique (5.2.2p4 Steam-Error: “Not available on your current platform”)
  • Stranded Deep (5.2.2f1 Steam-Error: “Not available on your current platform”)
  • Subnautica (5.2.3f1 Steam-Error: “Not available on your current platform”)

Unsupported

  • Blackguards (3.5.6f4)
  • Cognition (3.5.7f6)
  • Commander Jack (3.5.7f6)
  • creavures (3.4.2f2)
  • Dementium 2 (3.5.7f6)
  • Dungeonland (3.5.6f4)
  • DysanTheShapeshifter (3.4.2f2)
  • Seamulator 2009 (2.1.0f5)
  • ShadO (3.5.2f2)
  • Shelter (3.5.7f6)
  • Theatre Of The Absurd (3.5.0f5)
  • Them – The Summoning (3.4.2f2)
  • The Witcher Enhanced Edition (3.5.2f2)
  • Truffle Saga (3.5.7f6)
  • UnearthedEpisode1 (3.5.7b1)

Minecraft: Most Efficient Branch Mining Technique

Sunday, November 1st, 2015

There are a lot of hearsay and rumours on what is the most efficient mining technique in minecraft. I decided to test them.

Setup

The setup consists of 4 chunks, adding to 64×64 blocks, with a height of 16, from the bottom of the world up. I tried with one chunk only, but the results were inconclusive, since I managed to stumble upon chunks that did not contain certain resources at all. Since diamonds happen to be the most sought-after resource, and they only appear on height-levels 16 and below, I capped the setup there. These 4 chunks were then copied with mcedit, it’s resources counted with the “analyze” function of mcedit and then mined according to specific patterns. After this, I used mcedit again to count the new remaining totals.

The chunks were chosen more or less randomly, but so that they did not contain any lava or air. The setup has 65536 blocks in total, of which are 12222 bedrock, resulting in 53314 mineable blocks.

Efficiency is determined by the most resource-blocks mined for the least amount of blocks mined in total. It is completely irrelevant whether the chunks still contain resources after mining, as the minecraft world is infinite.

The Patterns

The patterns were aligned so that they cover as much of the height up to 16 blocks and down to bedrock; they were also aligned so that bedrock wouldn’t disturb the mining too much, so only the pattern with peekholes actually has tunnels within the uppermost layer where bedrock can occur, because since there are very few tunnels, this was deemed acceptable.

The green blocks signify visible blocks, red invisible ones. The bottom is left red because it consists mainly of bedrock.

Tunnels separated by two blocks, vertically aligned

 Tunnels separated by two blocks, vertically aligned

Theoretical amount of tunnel air-blocks is 11264, visible are 27136 other blocks, per tunnel air-block are 2.41 blocks visible. Coverage of mineable blocks is 72%.

Usually this is chosen by inexperienced players, who think they do have to get every resource within a certain space.

Tunnels separated by two blocks, vertically diagonally aligned

 Tunnels separated by two blocks, vertically diagonally aligned

Theoretical amount of tunnel air-blocks is 11008, visible are 32704 other blocks, per tunnel air-block are 2.97 blocks visible. Coverage of mineable blocks is 82%.

This makes it immediately clear that this option is much better than the first version. For about the same amount of blocks mined, the ratio to visible blocks and the overall coverage is much bigger. Actually, depending on how the two patterns are aligned to each other, it is possible that both need exactly the same amount of tunnel air-blocks; and this pattern covers 20% more space.

So if you still think you need to get every resource within a certain space, this is still much better a pattern than the above.

Tunnels separated by three blocks, diagonally aligned, one space

Tunnels separated by three blocks, diagonally aligned, one space

Theoretical amount of tunnel air-blocks is 8192, visible are 23552 other blocks, per tunnel air-block are 2.875 blocks visible. Coverage of mineable blocks is 59%.

The theory behind this is, that ores usually appear in veins, consisting of 2 to 20 blocks within some three.dimensional space. Thus the chance to stumble upon ore should not be greatly diminished by the added space.

Tunnels separated by three blocks, diagonally aligned, two spaces

Tunnels separated by three blocks, diagonally aligned, two spaces

Theoretical amount of tunnel air-blocks is 6144, visible are 18432 other blocks, per tunnel air-block are 3 blocks visible. Coverage of mineable blocks is 46%.

The same as above, but with one space added in the vertical direction.

Tunnels, separated by ten blocks, with peekholes every two blocks

Tunnels, separated by ten blocks, with peekholes

Theoretical amount of tunnel air-blocks is 7944, visible are 23704 other blocks, per tunnel air-block are 2.97 blocks visible. Coverage of mineable blocks is 59%.

This also relies on the fact that ores rarely only occupy one block in a certain axis. Also, the use of peekholes instead of tunnels leads to less tunneling that needs to be done, for very similar numbers as the tunnels separated by three blocks, diagonally aligned with one space. This one also has the added benefit that mobs cannot spawn in the peekholes.

Tests

From the above, one could easily conclude that the pattern with the biggest visibility per tunnel-block or the pattern with the biggest coverage would be the most efficient. But this would only be the case if resource were distributed uniformly; instead they’re distributed random, and in bunches. Since we don’t have any numbers or mathematical model on that, we test instead.

Mined was every block needed for digging the tunnels, and every visible resource block from there. If mining that resource block turned another resource block visible, that one was mined too. Sometimes another block was mined as well, if that was needed to get to a visible resource block.

Baseline is our setup, which 53314 mineable blocks, of which we have:

Uninteresting Blocks 51518
Gold Ore                47
Iron Ore               382
Coal Ore               818
Lapis Ore               40 
Diamond Ore             38
Redstone Ore           471

And these are the results of the first two tests done. I will refrain from testing the 2 rectangular pattern, since its obviously inferior to the 2 diagonal one. I might do the other two pattern as I find time. Numbers are what’s left in the ground after mining:

                     2 Diagonal    Peekhole
Uninteresting Blocks 40613          43531
Air (Tunneled out)   12497           9710
Gold Ore                 4              8
Iron Ore                48             46
Coal Ore                89             83
Lapis Ore                4              1
Diamond Ore              5              4
Redstone Ore            56            111

These are very similar, except the first version needed a lot more tunneling for the same amount of resources. And the first version covers a whopping 82% of the whole space, while the second one covers only 59%; which makes it quite obvious there is something going on with ore bunching.

This makes the pattern with peekholes roughly 128% as efficient, and just as thorough, as the tunnels separated by two blocks arranged diagonally.

Minecraft: 1891 Fruit Co. Fully Automatic Farm

Monday, July 6th, 2015

This is the reviced version of my Semi-Automatic Farm (which was called 1890 Fruit Co.) for Minecraft.

1891 Fruit Co. Building 1891 Fruit Co. Building

it’s gotten much smaller, less than half the volume

1891 Fruit Co. Front Front

And it produces much more different fruit

1891 Fruit Co. Entrance Entrance

1891 Fruit Co. Reception View Reception View

It produces patatoes, carrots, wheat, bread, seeds, pumpkins, melons, cactus, sugar cane, poppies, dandelions, peonies, roses, lilacs and sunflowers. And other flowers in low quanties.

1891 Fruit Co. Output Produce

All you need to do by hand is feeding in copious amounts of bonemeal. Everything es is automated (and the produce gets sorted; except the less common flowers). The farms for patatoes, carrots, wheat and bread will work without bonemeal, albeit very slowly. The flower farms won’t.

1891 Fruit Co. Factory Floor Right Factory Floor Right

1891 Fruit Co. Factory Floor Left Factory Floor Left

The schematic

The license of these files and my screenshots is the OPL 1.0 or CC-by-sa.

Minecraft: Baroque Windmill

Monday, May 11th, 2015

This has been lying about on my disk, so here’s just a quick post with it:

To make my Minecraft world a bit more lively, I did an 18th Century windmill to place into it:

18th Century Windmill

And another view, at sunset:

18th Century Windmill

It’s based upon an english windmill of around 1750. The interior isn’t exactly as it should be, with minecraft lacking round things. I just did an approximation of it with placeholders. And of course, here’s the schematic for mcedit.py:

18thCenturyWindmill.schematic.

The license of these files and my screenshots is the OPL 1.0 (which is about the same as CC-by-sa).

Minecraft: Castle Good Hope Construction Site

Tuesday, November 18th, 2014

I somehow lost interest in this (more on that later), so it’s basically a construction site, but I thought I write up how I constructed it.

I was looking around for some more baroque things I could build, maybe a small fortified city or something like that. Initially I came upon the Peter & Paul Fortress in St. Petersburg, but I could not find any useful plan or schematic.

And then I found this: Castle Of Good Hope, Overview. It has a scale, measures around 240×240 meters, and the layout looks gorgeous. The picture has around 2 pixel per meter, so that can be scaled easily. This star-shaped fortress was built between 1666 and 1682 by the Dutch East India Company (VOC).

I loaded the layout into gimp, fiddled around with the colours so that the black pixels were blacker and thicker, and the colours deeper. Then I made a custom palette with five coulors: black, white, orange, blue, green, and converted the image from RGB to indexed with that palette, replaced white with alpha, and rotated it 60 degrees counterclockwise (because I wanted the walls of the building in the middle to be straight). Finally I scaled it to 50%. Which gave me this: GoodHope

This image I then converted to an mcedit-schematic. There’s some free online-tools which can do this, some standalone programs and even some mcedit filters. Which gave me this: Floorplan Schematic which of course is not very precise. This I placed on the ground with mcedit, and then I started building up, while interpolating and correcting.

This is how it looks right now, from a bit up the ground

CastleGoodHopeView

And from above:

CastleGoodHopeFromAbove

Including the woollen plan beneath it, and with various sandstone blocks to mark where buildings should go.

Now, if you take a close look (or look at a View of Castle Good Hope or a Closeup of the Gate of Castle Good Hope) you realize what this consists of: Basically (granite) cobblestone topped off by red brick! Ugh!. That was the moment I slowly started to decide that I would not finish this.

Add to this that I could not find an elevation-plan of it (only of the earlier square-shaped fortress) and various details remained opaque (although google map view of Castle Good Hope helped a bit; you can see where stairs are), I decided to leave it after I’ve brought into some kind of shape.

So if anyone wants to continue this (perhaps someone frome cape town?) I publish it here. License is public domain, you can do whatever you wish with it. It’s in 1:1 scale, as accurate as possible. The walls are maybe 70% done, although I don’t know if I’ve got the height right, and the topping-off is a bit higher, since I wanted to have half-slabs on top to stop spawning. Also, there’s only grass where It didn’t interfere with the rest of the walls. The Oranje and Leerdam bastions have their gun emplacements, Buuren only two of the five it should have; the rest none yet. And I’m not quite happy with how they look. The entrance lacks everything. The buildings are somewhat staked out, some with approximate height.

The world save is just what you can see in the pictures, the schematic however is the walls only, so you can put it into your world and fill in the rest with whatever you want.

Here they are

On Ebooks and pricing

Monday, November 17th, 2014

I’m an avid reader. And I’ve got quite a collection of books. But apart from some pdfs I bought at rpgnow and some I’ve got from humblebundle, I bought exactly one ebook on the internet.

One reason for this is DRM. I can’t stand it, and I vote with my boots. I will never support such a completely consumer-hostile scheme, not with my money, and I even try to boycott the most egregious abusers of it by not buying their other products as well. Amazon for instance. There are of course some other abuses producers can indulge in which might want me to boycott them, like lobbying for extensions of copyright or ripping of the academic communities with journals and other such rent-seeking activities. But I won’t go into detail here; if buying a book is not as easy as can be or the book has antifeatures like DRM, you can stop right now, you’ve already lost.

Another reason is price. I’m very well aware that producing an ebook has a lot of the same fixed costs as one on paper has, but still, ebooks are much, much too expensive. The one thing that most people seem to forget, is that while ebooks have the same fixed costs (basically the writer and the editor; see Charlie Stross‘ Blog for details) there are practically no costs associated with the individual file you sell. So that base price of the individual unit which came beforehand from printing, stock and distribution, falls away, what remains is the amount for writer, editor, marketing, etc. which can be spread out over as how many units you like.

The question is, where actually is the “right” price for ebooks (and movies, by the way, which also seem to be much too expensive)?

The facts to keep in mind are: Budget and time are constrained on the buyers side. For most books, the things that tell stories are the immediate competition: Movies and computer games, But basically everything else that entertains people is competing with books, like forums and blogs and other places of discourse on the internet. And the public domain will also compete with newer books. Also, while people can (and will, no matter of copyright) share books with their friends they can’t actually resell them and recoup some of the money they spent. So the price needs to be rather low, to compete with all the other offerings, with public domain books, and with used books on paper.

Now, I’ve noticed from my behaviour regarding computer games, that I actually bought a lot of games I already had again, at gog.com or steam. Why? Mostly because they were cheap. With some autumn- summer- and christmas-sales, I’ve just about re-bought all the computer games I’ve already had.

This leads me to the conclusion of what the “sweet price” for ebooks is: The price where I can re-buy all the books I’ve ever had on paper or ever read within the space of maybe a year or two. In my case, that’s probably around 2000 books, some of which I’ve gotten for SFR 1 at garage sales, some I lent out from libraries, some I bought at retail price. The price for all of them should probably be below SFR 10’000; and with the SFR 1 paper ones as measuring stick, probably not a lot more than that. Say between SFR 1 and 4 (one swiss franc, by the way, is slightly more than a dollar nowadays).

Of course, you won’t want to make every book this price; you might want to put prices of popular ones more towards SFR 4 and unpopular ones more towards SFR 1, and of course, for new releases you want to have prices rather towards the prices of the paper version, SFR 15 maybe. Still, even new releases should have prices markedly lower than the paper version, since you really don’t have to take any logistics into account. Plus, you might want to have sales with huge discounts, and bundles, like “all the works of Isaac Asimov for SFR 30”. Take a look at steampowered.com around christmas, and you’ll see what I mean.

Exactly the same thinking can of course be applied to other digital goods, like movies and television series. I suspect the prices there could be a bit higher, maybe something around SFR 3-10 for movies, and maybe SFR 1-4 for single episodes, or SFR 10-20 for whole series. And again, newer ones priced above that, And bundles (“all the James Bond movies for SFR 50”).

The main point here is: There is a price that is so low, people will buy these things just to have them (or even fear that “it will cost more after this sale”), regardless of whether they even get around on reading or watching them. Just for the sake of collecting. Because they remember them, or because they’ve heard about that author and plan on reading something of him some time in the future. It doesn’t even matter if they already have gotten that book from a friend, for free. And, most importantly, it doesn’t matter if they will even find the time to read it; or even expect to find the time.