Vive Linux

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

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

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

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:

All Singing, All Dancing and the Music to Puke

May 20th, 2016

Apparently it’s now a Hollywood trend to end your movies in some all-singing-all-dancing scene, everytime with non-fitting, mood-destroying cheap bad pop.

Case in point: Descpicable me. It’s starts out with a ballet of swan lake,in which the turntable is taken over by some drone which strangles off swan lake, and replaces it with some miserable pop straight from the garbage-bin, after which everyone starts dancing happily. Apparently Hollywood wants to tell the kids that swan lake is no fun, and everybody should like this abyssmal concotion of uninspired and amelodious malware.

Another one is Ice Age 4, if I remember correctly. I’m not quite sure, because I immediately tried to get it out of my memory, because it was that bad.

In any case, would you let your children be indoctrinated with such a message? “It’s only good if it’s bad pop”?

But if the movie really can’t have any all-singing-all-dancing scene in it, well, there’s always the credits. There you can do you worst, and the people watching the movie can only hope to flee before the mood of the film is destroyed completely, because either some 12 year old boy-band fan chose the music for this, or some exec of one of those instant-band chose it to further his dark plans. Like not allowing anyone to listen to Tchaikoswky instead of the bollocks he wants to sell them.

Shrek 3 is an example of this. I guess in Shreck 4 they put the waste again into the all-singing-all-dancing.

Yes, the most obnoxious examples are all rendered movies, but the trend can be seen in other movies as well, where they exert themselves with choosing the most unfitting music for the credits. Narnia for instance, where the pop is bad, but at least the singer can sing. For what its worth, to sing bad pop.

What is good music for credits? Well, the one that fits. Like the one for “The Madagascar Penguins in a Christmas Caper”. It doesn’t actually matter what style, along as it is consistent. The Lego Movie features astoundingly bad pop to make a point. And in that case it’s absolutely right to return to that for the credits (Actually, they even feature a different (and much better) version of it at the end).

Windows Unity-Games on Linux

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

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

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

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).

Con-Takt 2015, das College of Wizardry und das Schweizer LARP

January 23rd, 2015

LARP, das ist “Live Action Role Play”, Liverollenspiel. Dabei geht es darum in einer hypothetischen Welt eine erfundene Person zu spielen, und mit anderen Spielern die ebenfalls eigene erfundenen Personen, “Charakter” genannt, in derselben Welt darstellen, zu interagieren. Das Spektrum dieser Welten reicht von “Herr der Ringe” zu “USA in den 20er Jahren” bis zu “Battlestar Galactica”, und allem nur erdenklichen dazwischen. Und ich spiele und organisiere seit fast 20 Jahren LARP.

Dieses Wochenende war der erste LARP-Kongress in der Deutschschweiz, der Con-Takt 2015. In den Nordischen Ländern gibt es seit 1997 den Knutepunkt und in Deutschland seit 2006 den MittelPunkt. Aber in hier war dies das erste mal dass wir wirklich darüber geredet haben was wir da eigentlich tun, und was man tun könnte und wohin wir wollen.

Ich habe auf dem Con-Takt 2015 gleich zwei Referate gehalten, eins über die Geschichte des Schweizer LARP, das andere über Kampf und Regeln:

Die “Geschichte” war logischerweise eher rückblickend, so “mit was hats angefangen” bis zu “was haben wir eigentlich so tolles gemacht”. Wie wir festgestellt haben aber durchaus nicht abschliessend; ein Plan ist es im larpkalender.ch auch alle Spiele in der Deutschschweiz zu erfassen die vor 2005 stattgefunden haben um damit eine bessere Basis für historische wie auch statistische Arbeiten zu bekommen.

Was die “Geschichte” auch gezeigt hat, ist dass wir hier schon ein sehr breites Spektrum von Settings, Genres und Spielarten ausprobiert haben. Von Fantasy und Vampire über Steampunk und Cyberpunk zu Zombies, Plüschtieren und einem Gefängnis. Von Schatzsuchen und Weltrettungen zu Krimis, Dorfspielen und Stellvertreterkriegen. Von herkömmlichen “Viele Spieler, wenig NSC” zu “Wenig Spieler und viel NSC”-Railroading bis hin zu gecasteten Spielen mit komplett offener Handlung und alles dazwischen.

Eher in die Zukunft gewandt war der zweite Vortrag, in dem ich im wesentlichen Kämpfe angeschaut habe, wie sie funktionieren und wie sie durch Regeln modifiziert werden. Es ging vor allem darum den Leuten einerseits zu zeigen “so sind Regeln typischerweise jetzt, das sind die Auswirkungen” und andererseits auch aufzuzeigen “Wir können die (fast) beliebig ändern”.

Die weiteren Referate (und hoffentlich bald auch die Unterlagen dazu) sind auf con-takt.ch zu finden. Besonders interessant war die Vorstellung vom LARP “Transit”, die Anleitung zum modifizieren von Nerf-Waffen und ‘Schränken die CH-Lokationen “Pfadiheime” die Larp-Weiterentwicklung ein?’, plus in der gleichen Stossrichtung den ad-hoc Vortrag von Kendra über den “LARP mixing desk”.

Kurz vorher dem Con-Takt ist das hier aufgetaucht: College of Wizardry – Documentary. Die Dokumentation über ein Harry Potter LARP in Polen. Dazu gibt es noch Behind the scenes of the larp College of Wizardry with organizer Claus Raasted und Claus Raasted: On hyping larps (for Mittelpunkt 2014). Das letzte davon ist ganz offensichtlich auf LARP Organisatoren in Deutschland, spezifisch auf diejenigen auf dem MittelPunkt gerichtet.

Und ein paar der Sachen betreffen uns in der Schweiz genauso. Vor allem “2. Tell us that it’s cool” und “5. Tell us what’s going to happen”. Das, und obig erwähnte Vorträge zur LARP-Theorie haben für extrem viel Gesprächsstoff gesorgt.

Wir haben angefangen uns bewusst zu werden dass wir an sehr viel mehr Stellen herumschrauben können. Zum Teil haben wir das vorher schon gemacht, aber es war uns eigentlich nicht wirklich klar was wir da eigentlich tun. Seit jeher war das LARP in der Deutschschweiz zum Beispiel sehr Regelarm, und in den 90ern vielen immer mehr Regeln unter den Tisch, so dass wir zu den Vorreitern von “Du Kannst Was Du Darstellen Kannst” oder teilweise auch “Du Kannst Was Du Kannst”-Bewegung gehört haben, zu einer Zeit in der in Deutschland noch massive Regelsysteme mit Erfahrungspunkten der Usus war. Auch dass die Spielleitung in unauffälligen Rollen mitspielt war eigentlich immer so. Und ganz viele solche Sachen haben wir auch nicht öffentlich kommuniziert; es war so selbstverständlich dass man erst begriffen hat dass es anders sein könnte wenn man auf Spiele in Deutschland ging.

In dem Zusammenhang haben wir auch über den larpkalender.ch gesprochen, einer dessen Betreiber ich ja bin, und wie wir Spielern, prospektiven Spielern und Orgas helfen können. Ideen sind Location-Datenbank, Orgas in Reviews dazu zu bringen Felder wie “Was war unser Ziel des Spiels” und “Wie wollten wir das erreichen” auszufüllen sowie ganz allgemein besser darüber zu informieren was wir eigentlich tun.

Ich glaube wir können als Fazit vor allem diese beiden Punkte aufführen:

a) Wir können viel mehr machen als uns bewusst war; und manchmal haben wir das sogar getan, aber da ist immer noch eine Welt von Möglichkeiten die wir noch nie ausprobiert haben.

b) Wir sprechen zu wenig darüber was wir tun. Diskussionen finden immer noch in geschlossenen Foren statt, und wir sagen prospektiven Spielern eigentlich gar nicht was wir da tun. Wenn im Larpkalender jemand nachfragt und die Antwort “Standard Fantasy” bekommt, dann weis man trotzdem nicht was denn der “Standard” sein könnte, ausser man war schon mal an einem Spiel.