sebadorn.de

Mastodon – Das wiederentdeckte soziale Netzwerk

Das Mastodon-Logo mit der Startseite von mastodon.gamedev.place im Hintergrund

Seit der Übernahme von Twitter durch Elon Musk sehen viele Benutzer die dortigen Entwicklungen mit Sorge: Große Kündigungswellen; Angestellte, die im Büro über­nachten; mangelnde Moderation und Abschalten der Pressestelle; Hin-und-Her um das blaue Verifizierungshäkchen, welches durch Twitter Blue nichts mehr mit Verifizierung zu tun hat und so Identitäts-Imitation Tür und Tor geöffnet hat; das Killen von Dritt­anbieter-Apps … Ich habe bereits ein paar Punkte ausgelassen, aber solange es die Seite noch gibt, werden sicherlich weitere dazukommen.

Wenig erstaunlich also, wenn Nutzer stetig und besonders beim nächsten Vorkommnis abspringen oder zumindest parallel andere Social Media-Dienste ausprobieren.

Twitter-Gründer Jack Dorsey hat einen neuen Dienst namens Bluesky gegründet, der sich aktuell in der Beta-Phase mit Warteliste befindet, Meta hat kürzlich Threads gestartet, welches an Instagram gekoppelt ist – Anmeldungen sind innerhalb der EU jedoch bisher nicht möglich.

Und dann gibt es da wie üblich auch wieder die Open Source-Community, mit einer eigenen, nicht kommerziellen Antwort: Mastodon. Wobei dieses nicht neu ist, sondern jetzt aufgrund der Entwicklungen etwas vom Platz im Scheinwerferlicht erhält.

Read more

Dead Cells: Unlocking the Daily Challenge blueprints in the bugged Linux GOG version

Dead Cells error message.

Dead Cells has a Daily Challenge or Daily Run mode, but it is just a minor optional part. Except that is required in order to unlock three weapons (“blueprints”) for the main game. Just by starting a Daily Run on different days unlocks the following blueprints:

  1. Swift Sword (internal name SpeedBlade) the first time
  2. Lacerating Aura (internal name DamageAura) after the fifth time
  3. Meat Skewer (internal name DashSword) after ten starts

However, specifically the Linux version on GOG has an issue where it is impossible to start the Daily Challenge. The Linux version on Steam is not affected. To use anything online-related in Dead Cells – which thankfully is not a lot as it is a local single-player game – the GOG GALAXY client is required. Which does not exist for Linux. Until a GOG GALAXY client for Linux is released, I probably should not buy games from GOG any­more and just go with Steam, because otherwise I cannot trust that all features will work. Which is a pitty because I really like GOG for being DRM-free.

The Dead Cells issue is known for years and by now it seems rather unlikely it will be fixed. At some point a note was added to the store page:

Additional Notes: Galaxy client is required to access Daily Runs and Streaming features.

Let's hack the game

The blueprints dropped in a level.

At the point of writing I was using Ubuntu 20.04.2 and the Dead Cells game version 1.14.0 / v24. You will need a hex editor which can handle big files of around 1 GB. I used and can recommend GHex. You can install it with:

$ sudo apt install ghex
Read more

Changing the message language for Bash

The system language of my Ubuntu installation is set to German. Per default this also means that my command line output is in German if the application supports it. This can be a bit of a hindrance when developing, because error messages and warnings will also be in German which makes it harder to search for solutions – most discussions in help forums and blogs are in English.

So let's change the terminal language. In your ~/.bashrc file add the following lines:

unset LC_ALL
export LC_MESSAGES=C

If LC_ALL had a value, it would overwrite the setting for LC_MESSAGES, so it has to be unset first. I first tried setting LC_ALL=C, but this had the undesired side effect of certain keys behaving differently. I have a German keyboard with QWERTZ layout, but keys like “ä”, “ö”, “ü” suddenly did different things. I can only assume I would have run into some other issues as well. So keep it simple and just change the messages.

The next terminal you open will have the setting applied. Also note that this only affects your terminal and no other applications – except those launched from said terminal.

To check your language settings you can use locale. My output using Bash looks like this:

$ locale
LANG=de_DE.UTF-8
LANGUAGE=de_DE:en
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES=C
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=

Side note: I also tried LC_MESSAGES=en_US.UTF-8, but that didn't work – no idea why. I also didn't look further into it since I have a working solution.

Sources


Dead Cells: PS4 controller support on Linux

Dead Cells is a game, it is really good, and it is available for Linux. However right after installation (version 1.0 from GOG) it did not recognize my PS4 controller. It could not be a problem with the controller itself or Linux in general, because the DS4 worked with other applications – for example it showed up perfectly fine in jstest-gtk (0.1.0).

After some research I came across this reddit post. Dead Cells uses the SDL library, so maybe that's it. I followed the instructions and built and ran sdl2-jstest. The output should contain an entry like this for the DS4 (2nd gen):

Joystick Name:     'Sony Interactive Entertainment Wireless Controller'
Joystick GUID:     030000004c050000cc09000011810000
Joystick Number:    0
Number of Axes:     6
Number of Buttons: 13
Number of Hats:     1
Number of Balls:    0
GameControllerConfig:
  Name:    'PS4 Controller'
  Mapping: '030000004c050000cc09000011810000,PS4 Controller,a:b0,b:b1,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:b4,leftstick:b11,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b12,righttrigger:a5,rightx:a3,righty:a4,start:b9,x:b3,y:b2,platform:Linux,'

… or like this for the DS4 (1st gen):

Joystick Name:     'Sony Computer Entertainment Wireless Controller'
Joystick GUID:     030000004c050000c405000011810000
Joystick Number:    0
Number of Axes:     6
Number of Buttons: 13
Number of Hats:     1
Number of Balls:    0
GameControllerConfig:
  Name:    'PS4 Controller'
  Mapping: '030000004c050000c405000011810000,PS4 Controller,a:b0,b:b1,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:b4,leftstick:b11,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b12,righttrigger:a5,rightx:a3,righty:a4,start:b9,x:b3,y:b2,platform:Linux,'

Take the value behind Mapping and add a line in your /etc/environment file like this:

SDL_GAMECONTROLLERCONFIG='030000004c050000cc09000011810000,PS4 Controller,a:b0,b:b1,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:b4,leftstick:b11,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b12,righttrigger:a5,rightx:a3,righty:a4,start:b9,x:b3,y:b2,platform:Linux,'

After the next reboot everything should be working. Or if you want to test it right away without reboot, then you can just add it to the start script of the game. Assuming you used the standard installation path from the GOG installer, the file is located at ~/GOG Games/Dead Cells/start.sh. Change the file so it now begins with:

#!/bin/bash
# GOG.com (www.gog.com)
# Game

export SDL_GAMECONTROLLERCONFIG='030000004c050000cc09000011810000,PS4 Controller,a:b0,b:b1,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:b4,leftstick:b11,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b12,righttrigger:a5,rightx:a3,righty:a4,start:b9,x:b3,y:b2,platform:Linux,'

That's what worked for me. If it still doesn't for you, try adding some udev rules as described in my article Using NW.js to communicate with a DS4 controller.


JavaScript source protection with NW.js

You can minify and uglify JavaScript files, but technically the source code of your distributed NW.js application is still readable. But NW.js also provides the means to compile JavaScript to a binary file and then load it as part of the application. The command line tool nwjc to create the binary file is included in the SDK version.

Assuming you have a JavaScript file js/private.js:

'use strict';

function secretFunction( foo ) {
    return foo * 4;
};

Then you can compile it like this to a file js/private.bin:

$ ./nwjs-sdk-v0.30.5-linux-x64/nwjc js/private.js js/private.bin

Internally the tool uses the V8 snapshot feature, which means the versions have to match. A binary file created with NW.js 0.30 can only be loaded by 0.30. Binary files also do not work cross-platform. For each platform it is necessary to compile its own binary file with the SDK for the same platform.

To then load the binary file in your application, it works like this:

let win = nw.Window.get();
win.evalNWBin( null, 'js/private.bin' );

let value = secretFunction( 4 ); // returns 16

Note however that the loading is per window. If you open another window in your application, the file has to be loaded there again.

Using the DevTools you can of course find the functions and variables which have been loaded from the file. The function implementation however is protected:

> String( secretFunction )
< "function secretFunction() { [native code] }"

DevTools issues

Update 2018-12-15: Since NW.js 0.34 this issue seems to be fixed. Loading binary files works even with the DevTools open.


There is an issue with loading binary files and the DevTools. Basically you cannot have the DevTools open and then load the file. There will be no error, but the contents will not be available. This is a known issue.

My temporary solution is to just close the DevTools. But just closing them right before is not enough, you also have to use a timeout before loading the file:

let win = nw.Window.get();

// Function is only available in the SDK build.
if( typeof win.closeDevTools === 'function' ) {
    win.closeDevTools();
}

setTimeout( () => {
    win.evalNWBin( null, 'js/private.bin' );
}, 500 );

But why not check first if the DevTools are open? Then you could open them again afterwards. According to the API documentation there is win.isDevToolsOpen(). But it exists only in the documentation. Using the SDK build there is de facto no such function. This too is a known issue.

Wine for Windows

I successfully used Wine 3 to compile a binary file for the Windows version of a NW.js application and then load it there. So if you are on Linux or macOS you will not need Windows for your build process. You should of course still test your application to make sure it works on all targeted platforms.