Scribbles to run a X52Pro as two virtual gamepads via moltengamepad

Put this in ~/.config/moltengamepad/gendevices/x52-pro.cfg

[events="superset" vendor="06a3" product="0762" driver="hid-generic"]

# 06a3:0762
# Options file is license as WTFPL
name = "x52_pro_controller"
devname = "x52_"
exclusive = "false"
change_permissions = "false"
flatten = "false"
rumble = "false"
1.device_type = "gamepad"
2.device_type = "gamepad"
# btn_east = "cross", "The cross (X) button"
# Event mappings
# 1.key(288) = "cross", "Primary fire button"
1.btn_trigger = "left_trigger", "Gun Button Step 1"
# 1.key(302) = "right_trigger", "Gun Button Step 2"
1.btn_trigger_happy15 = "bbb", "Gun Button Step 2"
1.btn_thumb2 = "a", "A button"
1.btn_top = "b", "B button"
1.btn_top2 = "x", "C button"
1.btn_thumb = "y", "Safety fire button (Fire 2)"
1.btn_pinkie = "guide"
1.btn_base2 = "button_16"
1.abs_x = "left_x", "Left stick X axis"
1.abs_y = "left_y", "Left stick Y axis"
1.abs_rz = "right_x", "Right stick X axis (Z axis)"
1.abs_z = "right_y", "Right stick Y axis (Throttle axis)"
1.abs_hat0x = "leftright", "HAT POV up"
1.abs_hat0y = "updown", "HAT POV right"
1.btn_trigger_happy4 = "right_thumb", "POV2 up"
1.btn_trigger_happy5 = "right_shoulder", "POV2 right"
1.btn_trigger_happy6 = "left_thumb", "POV2 down"
1.btn_trigger_happy7 = "left_shoulder", "POV2 left"
2.btn_trigger_happy3 = "left_trigger", "Scrollwheel click"
2.btn_dead = "right_trigger", "Mouse button (click)"
# 2.btn_trigger_happy15 = "x", "I button"
2.btn_base = "a", "D button"
# 2.btn_base2 = "b", "E button"
2.key(719) = "left_shoulder", "Function button"
2.key(722) = "left_thumb", "Function page up"
2.key(723) = "left_thumb", "Function page down"
2.key(726) = "right_shoulder", "MFD select button"
2.key(724) = "right_thumb", "MFD select button up"
2.key(725) = "right_thumb", "MFD select button down"
2.abs(004) = "left_x", "Left stick X axis"
2.abs(003) = "left_y", "Left stick Y axis"
2.abs(040) = "right_x", "Mouse X"
2.abs(041) = "right_y", "Mouse Y"
2.btn_trigger_happy8 = "up", "Throttle POV up"
2.btn_trigger_happy9 = "right", "Throttle POV right"
2.btn_trigger_happy10 = "down", "Throttle POV down"
2.btn_trigger_happy11 = "left", "Throttle POV left"
2.btn_trigger_happy17 = "start_stop", "Start/Stop"
2.btn_trigger_happy18 = "back", "Reset"
# Aliases
# 1.btn_trigger = "primary"
alias primary a
alias secondary b
alias third x
alias fourth y
alias start start_stop
alias select back
alias mode guide
alias thumbl left_thumb
alias thumbr right_thumb
# right shoulder
alias tr right_shoulder
# right trigger
alias tr2 right_trigger
# left shoulder
alias tl left_shoulder
# left trigger
alias tl2 left_trigger

Run this with moltengamepad --num-gamepads 2 --mimic-xpad and press button on the joystick _first_ and on the throttle _second_ so they get assigned in the correct order.

This should result in two gamepads _and_ the X52Pro so even really braindead games that do only support gamepadS should be able to read this at least in any way.

AntiMicroX showing X52 Hotas mapped to two virtual gamepads

If the game does support only one gamepad consider binding joystick _buttons_ to keyboard presses (e.g. with AntiMicroX instead).

Deliver Us The Moon by KeokeN InteractiveKeokeN Interactive (Deliver Us the Moon)
Deliver Us The Moon is a Sci-Fi thriller set in an apocalyptic near future where Earth's natural resources are depleted. In an effort to solve the energy crisis, global powers created the World Space Agency and secured a promising new source of energy on the moon.

Played Deliver Us The Moon on Linux PC. What a ride. Took me 6h 21m to complete and I only left the keyboard twice briefly. The story had me hooked from the very beginning 🤓

Got it on GoG, installed it with Lutris and played it without a hitch or single crash [of the game *cough].

Can recommend. Thrilling, casual puzzles, some sneaking around and very thick atmosphere (without much oxygen at times).

Some weeks ago I started making a ship for based on NZ-43 (14C) and while I was happy with the basic result it helped me mostly to get an understanding how such ships were made.

I never cared much about ships before and had absolutely no idea about this topic at all. During my research to close that gap, which consisted mostly of reading into Flevobericht, 331 (ISBN 9036910862) and following the awesome actual model builds by @silverman834 at did I decide to reapply the lessons learned and go for the famous so called “Bremen Cog” ship.

This is a very specific ship type that was widely used from the 12th century on for trade via the sea. It was between 15 to 25 meters long, had one square sail and was crewed by approximate 12 people that worked in shifts. Unlike other sailing ships it was very reliant on wind direction but it’s flat bottom permitted it to be beached without taking damage so it could be unloaded everywhere e.g. during low tide. The aftercastle on it’s stern deck makes for a very distinct impression and can be recognized from many period depictions of ships. Several full sized replica have been built to this date.

The “Bremen Cog” is the best preserved example of this ship type. It’s wreck from ~1380 was discovered in the Weser in 1962. It took almost 40 years until it could be presented to the public. It’s my understanding that the conservation techniques applied had to be developed first. It’s on display in the German Maritime Museum and the cog apparently played a huge role in the founding of the museum itself:

The museum is located in 27568 Bremerhaven / Germany (and closed during the wintertime). No idea when I’ll get the chance to visit this but the museum does also foster a YouTube channel and one of the most recent videos up on their channel is a drone flight around and through the Bremen Cog made by Dennis Vogt so make sure to check this out:

So why did I take this effort on me to recreate this famous ship type once more in a game? Curiosity and hyper focus I guess. I can tell you it was cumbersome because the game does not support bend objects so everything is basically a block. It does also not feature tools for e.g. Bézier curves or something. I spent quite some hours trying to get the hull and proportions right and while the superstructures are kinda opinionated I’m really happy with the end result. I also saved a lot on the ropes and while I know in theory how this should work and look it’s just _too much work_ to get this right in the game. So I only went with the most important running ropes. I hope any navigators reading this can forgive me 😉

The final result of the Bremen Cog under sails

I also prepared a variant without a sail and maybe I’ll even create a version with a reefed sail and with another version of the bow someday. I don’t know yet for I feel very exhausted from this little side project for now.

The final result of the Bremen Cog without sails

It’s also very sparse on final details because I can imagine that the blueprints for this ship will see a lot of reuse on various servers of the game so it should be really easy to individualise each placement with different colours or textures or cargo.

Speaking of: The blueprints for Rising World (Unity) can be downloaded from here:

You’re free to share and adapt this work as indicated by the CC-BY-SA 4.0 license. Please do inform me if you make use of this simply because that would make me very happy. It’s not required though.

Working on a loosely based on NZ-43 (14C). It’s approximately 12m long 🙂

First time I’m trying my luck with a vessel and not a building. The curving is difficult to realise in tho.

It started life in the old Java version of the game because the new Unity version has no posters yet. I had to segment the plan of the cog (carved in a very bad resolution from a PDF) into several in-game posters that had to be aligned in-game again to get the proper measurements.

After that I moved the blueprint of the frame over to the new version and started putting planks on it. A cumbersome process during which I learned a lot. I’ll probably make another and more improved hull based on the gathered know how.

I also fell straight into another “not yet implemented” trap. RisingWorld has a flip command to mirror an object and I kinda assumed this would work with blueprints too. It does not. And I was really not looking forward to put plank on both sides of the frame.

Luckily most of the leg work to read the binary blueprints was done by @paulevs before who released under the MIT license. It has been a while that I touched Java but I could come up with some code of my own that would flip the planks only (I used rounded cubes for the planks exclusively) making use of this lib and the very first try at it looked promising already.

Here is the source I came up with in case you wonder:

package blueprint.flip.maybe;

import java.util.ArrayList;

import paulevs.bluelib.blueprint.Blueprint;
import paulevs.bluelib.blueprint.BlueprintIO;
import paulevs.bluelib.blueprint.element.BlueprintElement;
import paulevs.bluelib.blueprint.element.BlueprintElementType;

public class App {
    public static BlueprintElement cloneBlueprintElement(BlueprintElement el) {
        BlueprintElement element = new BlueprintElement(el.type);
        element.setPosition(el.posX, el.posY, el.posZ);
        element.setSize(el.sizeX, el.sizeY, el.sizeZ);
        element.rgba = el.rgba;
        element.setRotation(el.rotX, el.rotY, el.rotZ, el.rotW);
        element.setSurfaceOffset(el.surfaceOffsetX, el.surfaceOffsetY, el.surfaceOffsetZ);
        element.texture = el.texture;
        return element;

    public static Blueprint readBlueprint(String pathname) {
        File file = new File(pathname);
        Blueprint blueprint = null;
        try {
            blueprint =;
        catch (IOException exception) {

        return blueprint;

    public static void main(String[] args) {
        final Blueprint blueprint = App.readBlueprint("/path/to/Blueprint-flip-maybe/cog_base_split_1670726695.blueprint");
        System.out.println("Opened " +;
        System.out.println("Blueprint has " + blueprint.elements.size() + " elements");

        ArrayList<BlueprintElement> elements = new ArrayList<BlueprintElement>();

        blueprint.elements.forEach(element -> {
            if(element.type == BlueprintElementType.ROUNDED_BLOCK) {
                System.out.println("T: " + BlueprintElementType.getElementName(element.type));
                System.out.println("pX: " + element.posX + "pY: " + element.posY + "pZ: " + element.posZ + " rX: " + element.rotX + "rY: " + element.rotY + "rZ: " + element.rotZ);
                BlueprintElement el = App.cloneBlueprintElement(element);
                el.posX = el.posX * -1;
                el.rotY = el.rotY * -1;
                el.rotZ = el.rotZ * -1;
                System.out.println("pX: " + el.posX + "pY: " + el.posY + "pZ: " + el.posZ + " rX: " + el.rotX + "rY: " + el.rotY + "rZ: " + el.rotZ);

        elements.forEach(element -> {
        }); += "_flipped_X";

        File outputFile = new File("/path/to/Blueprint-flip-maybe/" + + ".blueprint");
        try {
            BlueprintIO.write(blueprint, outputFile);
        catch (IOException exception) {

I’m kinda happy with the result. This Lib also allows me to change the texture of the elements so I don’t have to worry how the used texture during the construction may look in the end.

Now onwards to improve the curves. I really wish for a bend mode where the beginning would snap on to an existing object and the opposite plane could be moved around individually.

With (Unity) improving a lot lately we’re feature wise almost on par with the old Java version again. Due to my hobbies I’m playing on the server where I usually construct buildings based on specific periods according to my understanding of timber-framed constructions. Which may not be the best to rely on but hey, it’s a game after all.

One of the features still missing is an ingame map. We do have the compass already though and with debug enabled we even get an exact position on the current map. And the new maps are huge! And since we’re building here in multiplayer it’s no wonder that this is a dire missed feature to get an idea where the others are and what they are building, because it’s not fun navigating with X,Y,Z alone to visit other players (and keep note of where the own spot is located).

So I was intrigued to see that the player @Bamse did what gamers tend to do when a feature is missing. They start some sort of helper app (or wiki or whatever). This resulted in a Cloud map project at where players from the same server may add POIs and do the leg work of surveying the “new” world.

The only drawback (haha. sorry.) is: It’s a PITA to do the surveying because stopping every few meters to note down a bunch of coordinates takes hours! Someone had to do this though, because “my” isle – a piece of rock I randomly stumbled over after the latest server reset – was still missing! And while I clocked roughly ~700h on this game already I was not going to do that. I’m a programmer – which equals to lazy in my opinion. So I started scripting and after a few minutes came up with the following still crude solution:

echo "" > move.log
while true; do
	gnome-screenshot -w -f /tmp/snapshot.png && convert /tmp/snapshot.png -crop 165x30+905+975 /tmp/snapshot-cropped.tiff && tesseract /tmp/snapshot-cropped.tiff - -l eng --psm 13 quiet | awk 'match($0, /([[:digit:]]+[.][[:digit:]])+.([[:digit:]]+[.][[:digit:]]+).([[:digit:]]+[.][[:digit:]]+)/) { print substr($0, RSTART, RLENGTH)}' | awk '{ printf "%0.0f,%0.0f,%0.0f\n", $1, $2, $3}' >> move.log 
	sleep 2

This surely can be improved a lot but… minimum viable product. We’re still talking about a game. Here is what it does:

* Take a screenshot of the active window (Rising World while playing)

* Save it to /tmp (that’s in my RAM disk)

* Crop out the coordinates and convert it to tiff using `imagemagick`

* Run `tesseract` for OCR detection

* Pipe the result to awk and use a RegEx to identify three numbers

* Reformat the 3 numbers (remove the precision) and dump it in as csv-like log

* Sleep for 2 seconds and repeat until terminated

And in case you wonder why I used gnome-screenshot: I’m on and the usual suspects written for X do simply not work. I did recompile gnome-screenshots tho to disable the annoying flashing though so it’s silent now.

Why the awk program? Well, tesseract is good but the raw data looked something like this in the end and the RegEx cleans that up somewhat:

serene ep)
9295.2 95.4 2828.0 |
9295.2 95.4 2828.0 |
9296.4 95.4 2828.5 |
9303.1 95.4 2838.5 |
9295.0 98.4 2857.65
9289.1 98.7 2868.1 (7
9296.5 96.7 2849.0 |»
9301.1 95.4 2835.5 |
9301.1 95.4 2835.5 |

So I put this to a test and jogged around “my” isle and here are the results:

One(!) data point was misread during the ~15 minutes run. Not too shabby! That could easily be fixed manually and who knows… mebbe I’ll improve on the script to check for implausible spikes like that at some point.

I demoed the script to other players on the same server and some already started investigating into solutions to adapt this script to Windows. Just don’t ask me how to do that – I really wouldn’t know 😛

Updated 10th Dec 2022: A solution to do the same on Windows PC appeared on

Bagged on GoG today and had a blast. Needed some fiddling to get my X52 Pro up and running since the game only supports _one_ Gamepad but that’s nothing that would stop my 😂

Video: Flight tutorial snippets from Rebel Galaxy Outlaw played on Linux PC

Update: I found _way later_ that there is a switch in the launcher to enable joystick support (which brings up my X52 just fiine). What a strange design decision.

Yesterday I tried various ships in StarCitizen (some “free” event). I launched at Everus Harbor, a station orbiting Everus. When I tested the Dragonfly Black it became old fast circling around on the small landing pad so… why should I now attempt an atmospheric decent instead?

(Sorry for the extra shaking – I had my DIY headtracker on :D)

StarCitizen – Dragonfly Diving (on Linux PC)

Tried to run SteamWorld Dig2 from GoG. It just died with this:

ERROR: ShowErrorMessage: Failed to initialized OpenGL extensions (GLEW), error: Unknown error

This is from my understanding a fixed bug in GLEW on Wayland but requires an update of that lib – which is probably not gonna happen any more.

Fun enough we can work around this by starting it with SDL_VIDEODRIVER=X11 ./Dig2 under Wayland, with from my understanding invokes|provokes XWayland and brings us back to Wayland. And since I want to play this on my couch with my Steam Link I added the game to my library and set it’s start parameters to SDL_VIDEODRIVER=X11 %command% – Et voila…

Fly Dangerous 5.0 was released and it is packed with new features like reflections on the ship, Steam leaderboards and ghosts! So you can basically race against yourself or others from the leaderboards!

As usual I gave it a spin and had a blast.

First things first though. The Linux version defaults to OpenGL and this resulted in like 25 FPS for me and the input of my X52 Pro (mapped as XBOX controller) was so laggy that I could sip coffee during each course correction. This was when I remembered the magic parameter -force-vulkan from other Unity games and from here it was smooth sailing. Eventually I ended up with the game start options obs-gamecapture for recording, mangohud for some FPS info and -force-vulkan for… well, FPS.

obs-gamecapture mangohud %command% -force-vulkan

As usual YMMV.

The flight mechanics changed a little bit and @jayleefaulkner explains this in great detail in the video Alpha 7: so I’m having a learning curve ahead of me… again!

Anyway, I’m not doing too bad after some rounds. Only issue left is that I can not disable the flight assist for some reasons. Probably a bad binding but I was eager to play so I went with it.

Fly Dangerous (on Linux PC) – with Vulkan

Oh and did I mention that this little gem is still for free and even opensource?