Archive for the 'Minecraft' 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.

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:

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

Minecraft: Semi-Automatic Farm

Thursday, October 24th, 2013

Welcome, this is my “1890 Fruit Company”, an automatic farm for Minecraft, which isn’t even about fruit. It looks rather 1890ies, though, and I couldn’t resist the name.

1890 Fruit Co.

It produces patatoes, carrots, wheat and seeds. You need to sow and plant yourself, fertilizing and harvest are pretty much automated, and the products are automatically sorted.

The schematic

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

Minecraft: Mob Factory

Tuesday, December 18th, 2012

I noticed some time ago that multiple spawners could be active at the same time, as long as the player was within 16 blocks of each of them. However, if too many mobs of the same kind the spawner spawns were within 9x16x16 around the spawner, it would stop spawning after 6 mobs or so.

So in principle, it must be possible to have a lot, maybe 8, spawners, completely with their delivery- and killing-system within a sphere of 16 blocks around the player, all churning out mobs and items. So that’s where I started:

In green you can see the 16 block sphere around where the player would be standing, in yellow are the 9x16x16 areas where no mobs of the same type should be (and consequently, the area any spawned mobs need to leave as soon as possible). The cyan circle is the ground layout, and of no consequence. The spawners along with their spawn-boxes are in brown and in stone. Those structures made of end-stone are elevators and droppers, to the left is one for skeletons, to the right one for cave spiders.

This made for a rather cramped internal layout, with 7 spawners and all the mobs which needed to be lead out, upwards, thrown down, and led to the middle again. Plus the redstone, mostly for lighting. it was a mess, the spider-grinder didn’t really work, for blazes and endermen I hadn’t implemented any automatic system, and I didn’t know where to put them because of lack of space.

Then I watched Etho Plays Minecraft – Episode 234: Egg Delivery where he demonstrated with Minecraft 1.4 items will go up a solid block, if there’s no other space around where they could go. So I redesigned the whole interior. I decided that only blazes would be left to kill for XP, and the other mobs would just get killed as soon as possible, and their items sent up to the central room.

This I did. And I moved the spiders to one side, making space for another spawner, slimes, making it the whole 8 spawners I initially envisioned. Of course, if I hadn’t cared for isolating zombies, creepers and skeletons from each other, it would have been possible to put in more spawners. Probably all of them. So this isn’t as efficient as it could be.

I initially had some problems with the redstone-circuits, but I finally realised that something simpler would do the job just as well. Now it’s only tow clocks, one for the item elevator and one for the grinder, a T-flipflop, also for the grinder, and a pulser, for sweeping out items.

The two mobs posing the biggest problems were blazes and slime. blazes, because they need a light level of 11 or higher in order not to spawn (which I solved with lots of redstone lamps and a smaller spawn-area) and the slimes, which would spawn in any light. I now put half their spawn area under water if spawning is turned off, but small slimes still spawn. For the cave spiders, I just turned the above item elevator into a killing machine, killing spiders and sending up items at the same time.

Right now, I’m still not entirely happy with the blaze-situation, I would like to have them delivered to the central room, so I can kill blazes while I wait for items, but I’ve not yet found a good solution.

Finally, I couldn’t resist to give the thing a facade, and I decided upon a late 19th century industrial look. Half of it is buried in the ground, so this makes the main control room in the middle of the structure easily acessible from ground level:

I call it “The Manufacture”, although it’s of course none. But this fits with the 19th century theme, where factories sometimes still were called manufactures, although the production wasn’t really “handmade” any more. And it works day and night ;):

Level and schematic:

Update:

Mob Products

Minecraft 1.5 is out, and it makes item-handling so much easier. So this is the totally revamped mob factory, now called “Mob Products”, featuring lettering on the roof (idea and font by Etho), and using hopper conveyors, dropper elevators and an item sorter.

Also, I went over it with 1.6.2 and the HostileSpawnOverlay mod, and fixed some lighting.

Update 2:

Mob Products Front

I fixed the typo on the roof ;).

No new level but simply the schematic:

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

Minecraft: Medieval/Baroque Town

Sunday, December 2nd, 2012

If you go to Planet Minecraft or mcschematics and look for schematics of levels of towns, you’ll notice something: Just about none of them are. They’re villages with walls and maybe a castle. Rarely, there are some that somehow make sense, like Skycrown (Nothing historically correct in this one, but plausible).

There are, however, cities that look like cites. This Imperial City is simply unbelievable.

But I didn’t want a city, but simply a fortified town for the NPCs. And I wanted a town which looked like it, and not like a village: Neither totally flat, nor with too straight roads, nor one with dispersed single-story buildings — the latter being the defining characteristic of a village. Towns need to be cramped, buildings built in rows and blocks right next to each other, with a small footprint but multiple stories high to maximize real estate.

I decided to go for a rather medieval look in general, with upper stories protruding in front of the building, sometimes with arcades in front of the houses. Also, with firewalls between the houses which are slightly higher than the roofs. Most houses feature a stall/shop behind double doors, and another entrance for entering the workshop and the living quarters.

However, the medieval looks is not drawn trough. Think of a medieval town that was modified in the later centuries, and arrived in the 18th century. Most buildings are still of older types, and only the most modern buildings really have a baroque look. In that case, it’s the city walls, which are already in the model of a star-shaped fortress of the late 17th century, including the gate-tower, the town hall with it’s tower, and the church. The church is actually the uppermost part of this cathedral inspired by the Frauenkirche in Dresden. I won’t include it in the schematic (so I can put the town under a free license), but you’ll notice the big round place at the top of the town — just copy paste in either the cuppola of above cathedral, or something else there. And the lighthouse is actually too modern, these turned up in this form later in the 19th century.

The schematic is a cut-out from my usual map, since the town didn’t lend itself nicely to being placed on flat ground. It’s supposed to be on a hill towards the sea. If you want to set it into its original setting, the world seed is “3327780” (structures, cheats, no bonus chest, type default). You’ll find the place at +850/+600, southeast of the spawn point. There’s a village there (which in fact, was the base of my town and supplied its population).

Here’s the level and schematic:

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