Reader

Brief Explanation of OpenMW and its modding capacity

    One of my favorite video games of all time is Morrowind, and that is in no short part due to the modding community and their wonderful creations. Whether it is for bug fix mods, quality of life mods, or content expansions, there is plenty of reason to find yourself on sites like NexusMods when you are a fan of this game. For myself, my go to setup at this point in time is a modlist designed for the OpenMW engine called I Heart Vanilla, a package that focuses on vanilla gameplay, bugfixes, and QOL enhancements.

    For those unaware, OpenMW is a total engine replacement for the original game. The original engine is marred by technical issues that this open source engine aims to utlimately resolve, as well as preventing the game from being lost to time should the original engine fail on future operating systems. With OpenMW, anyone can take the code and port it to whatever platform they wish, and update the libraries behind it which in theory will allow Morrowind to “live forever,” which in the world we live in where media is lost to time constantly is quite a blessing. The engine is also designed to be capable of expanding the original game in a way that the official engine never could. It has early support for LUA mods as of the 04.9 release, although incompatible with the prior “Morrowind Script Extender” classifications of mods, it proves to be as malleable if not moreso than the prior scripting solution.

    With that explanation of what OpenMW is out of the way, let us get to the topic of today: installing mods for the OpenMW engine on Linux. Thankfully, with the recent 0.49 release of OpenMW this is easier and more comprehensive than ever before. Through websites like Modding OpenMW (MOMW), we have the ability to quickly download and install curated mod lists designed explicitly for OpenMW. The process was difficult prior to the official release of OpenMW 0.49, as LUA scripting was only available in developer builds and these mods heavily relied on those builds. If you were on a distrobution that does not ship git packages, you were forced to set up a build environment and compile the game for yourself, as well as all of the tools provided by the MOMW website. This is no longer the case, although if you find yourself stuck on an LTS distro that still does not ship the 0.49 release package of OpenMW, you may be forced to rely upon Flatpak. This guide will not be covering the automatic modding of Flatpak versions of OpenMW, and the MOMW Tools Pack does not officially support Flatpak installations, although I suspect if you were to use a tool like flatseal to enable the package to use the Home folder you would be able to otherwise follow this guide.

Installation

    The first step to modding OpenMW is quite simple. You need to acquire a copy of the game, either through GOG or Steam, or alternatively install from a CD should you have the original physical release available to you. Installation of Morrowind will require either utilizing innoextract to take the GOG package apart, WINE to install the GOG package or official release disc to a chosen bottle, a WINE manager such as Bottles, Heroic Launcher or Lutris, or the Steam client to install a Steam copy of the game or alternatively using Steam's Proton integration to install other versions. You will then want to install your native package of OpenMW, I am on Arch Linux at the time of writing this so the process for me was as simple as using the package in the official repos with sudo pacman -S openmw. For Debian-based distros, the command would look something like sudo apt install openmw, though you should check your distrobutions repos to confirm that there are no alternative packages needed as some distros may divide things up into multiple packages.

Setting Up MOMW Tools Pack

What is the MOMW Tools Pack?

Well, it is a pack of tools that allow you to install the aforementioned premade mod lists from the Modding OpenMW site. These tools are designed to make it easy to download, install and manage your modlists for OpenMW, and the mod list we will be installing today is a pretty fantastic base to start with for adding your own customizations on top of.

    The next step for setup is something that can vary quite heavily due to factors such as:

• Personal preference

• Repository packages

• OS/Distro choice

   As such, this section is more of a “how I set this up” than a recommendation for your personal setup.

The first step will be to download the official release of the MOMW Tools Pack and extract it to a directory within your path. In my instance, I chose to put the files extracted in /usr/local/bin after removing the momw-configurator-linux-arm64 binary from the directory. Alternatively, you could create a directory in your home folder such as mkdir ~/bin and then adding it to your PATH as per the standard of your chosen shell. Note that while the Arch User Repository (AUR) does have packages for these tools, several of the tools fail to build properly under the current PKGBUILD and I didn't want to put the time or effort into troubleshooting why they were failing. This is the easier, and likely safer, route of getting these files on your system.

    Once you have the tools added to your path, you should restart your shell so that it can pick up the new binaries. You should now be able to run commands such as s3lightfixes and momw-configurator-linux-amd64 directly from any folder without needing to specify where these binaries are.

Synchronizing A Modlist

    Now that we have our tools configured, it is time to pick a mod list and get it downloaded to our system for the installation stage. This is made extremely easy now that we can execute the files from anywhere. Simply open your terminal emulator of choice and run umo setup to get started.

    Upon launching, umo will ask you for a number of things. First of all, your default browser will pop up and ask you to authorize access to your NexusMods API key. If you don't have a NexusMods account, now is the time to create one.

    Once the tool has been given authorization to the API key, you can close the browser window and return to the shell where you will see umo now asking you for a directory to store its mod files. Be aware that these mod files will reside decompressed at the location you choose to store them until you personally remove them, so make sure you have enough space for the mod list you choose. In the case of the I Heart Vanilla mod list, it is a total of 4.8GiB on the disk. That puts this mod list at over 4x the size of the original game, at 1.1GiB. If you want to add more mods to the list, it will only grow from there. With this in mind, and the knowledge I have a 1TB NVMe drive as my boot drive, I chose to create a directory called ~/.mods to have all of my lists managed in.

    Similar to above, umo will ask you to specify a directory for cache. The same considerations should be kept in mind, I left the cache directory to its defaults which are ~/.cache/umomwd. The compressed files downloaded from NexusMods are kept here, compared to potential updated versions, and managed by umo. You should *not delete this cache unless you absolutely need to save space and do not intend on altering any modlists that are installed, or you have fast enough internet to not care about needing to re-download these files again.

    The final thing umo will attempt to do is discover all of the other utilities the MOMW Tools Pack ships with. It should be able to pick them up automatically, but if it fails ensure that you specify not only the directory the utilities are in, but the name of each binary as umo asks for it. For instance, if it asks you for the groundcoverify utility directory, you would type in something like /usr/bin/groundcoverify, taking into account the directory you chose to store the tools in.

    Now that umo is set up, you can use it to install the list you have decided upon from the MOMW homepage. For I Heart Vanilla, this is done by simply typing umo install --sync i-heart-vanilla into your shell and hitting enter. If you are not a Nexus Premium member, a browser window will pop up for each file that needs to be downloaded. Simply click the 'Slow Download' button, and once the page shows the download has started feel free to close the tab. If you miss any of these pages, the install may stall. In this situation, you simply re-run the install command from above to resume installation from where you left off. After all of the downloads complete, umo will extract them to the mods folder you specified earlier inside a sub-directory for each list you sync and install. For my setup, this looks like ~/.mods/i-heart-vanilla

Configuring Your Modlist

    Now that the list is installed, we need the MOMW tools to configure our copy of OpenMW to be aware of these directories. This is done with the momw-configurator tool. It will automatically make OpenMW aware of the directories, set the load order in accordance to the modlist specifications, and enable plugins that need to be enabled. You should not modify the enabled plugins of the modlist you install. If there are plugins left disabled, this is for a good reason. Obviously, if you install your own mods on top of the list you are heading outside of supported territory and must know what you are doing.

    The configuration process is as simple as opening your terminal and running the command momw-configurator-linux-amd64 config i-heart-vanilla --run-navmeshtool --run-validator --verbose for the 0.49 release version. If you are on the dev build, currently 0.50, you should run momw-configurator-linux-amd64 config i-heart-vanilla --run-navmeshtool --run-validator --verbose --dev instead.

    At this point the configurator may ask you to enter the location of the openmw-iniimporter utility as well as the openmw-navmeshtool utility. If installed via your package manager, these should be found automatically. If in a directory inside your PATH, they should also be found automatically. If they are not found automatically, you will need to find where you have put them for your build of OpenMW and manually direct the tool to them.

    A step the official guide appears to be missing is running the tool s3lightfixes to generate a .omwaddon file called S3LightFixes.omwaddon. Simply run the s3lightfixes command in your terminal, and it will output this file in your home directory. Once generated, you can simply move it into the modlist directory and once the configurator asks you to specify its directory, you input the modlist directory. For example, I moved it into ~/.mods/i-heart-vanilla so I would specify that directory as the location of the file.

    The process of configuring the modlist can take quite some time, and is lengthened by the inclusion of the navmesh generation. If you are on a slower computer that is taking far longer than you would find acceptable to generate the navmesh, you can remove teh —run-navmeshtool flag from the configuration command. Keep in mind that this will have performance implications, especially on load times in-game.

    If something occurs to stop the configuration, it can be resumed in-place by using the momw-configurator-linux-amd64 setup command.

    At this point, you are essentially done with the setup! Congratulations! You can hop in and play now, or you can continue tinkering with options made available to you by the OpenMW game engine in its launcher.

Optional Game Configurations

    Before we get into actually changing any of the settings in the launcher, we first should make clear some caveats. If you change any settings in the launcher, ensure you are not simultaneously modifying the settings.cfg file for OpenMW simultaneously. The same applies in the opposite direction,if editing the settings.cfg file you should not have the launcher open. This can cause problems with the MOMW Configurator's changes, and may lead to situations where changes made in the file directly are not reflected or preserved in the launcher.

    The official guide for the MOMW Tools recommends that you read the official documentation for OpenMW, as well as the MOMW's own Getting Started: Tweak Settings pages. These are great starting points to get a feeling for what settings are available to you, and what you may want to consider changing. They additionally note that you can re-run the MOMW Configurator to reapply all default values, meaning any changes made are reversable to sane defaults for the modlist. For the remainder of this section, I will be detailing my own personal choices made in each section of the launcher as well as why I personally made those choices.

Data Files

    The first category of settings in the OpenMW Launcher is the Data Files page. This is a place where you can change load order, active mods, and even create your own lists of mods. You should not modify the load order or the active mods of the pre-made modlists unless you know what you are doing. With that said, the changes I make here are pretty simple. OpenMW will name each content list by the date it was created by default. I don't like this, and would rather my content list reflect the name of the mod list I am using. So, in the dropdown box at the bottom of the screen I simply select the modlist that was created by the MOMW Configurator and then delete the name, typing in “I-Heart-Vanilla”. These are the only changes I make here, and you should not need to make further changes unless you are specifying custom content to be added to your mod lists. In that case, you may want to go to the “Data Directories” sub-category, make a folder for your own custom additions somewhere on your filesystem, and then point the OpenMW Launcher to that directory.

Display

    This category gives you some very basic display options, you should set them as you see fit but for an example of my configuration it is as follows:

• Window Border is Enabled

• Framerate Limit is enabled and set to 144, as I use a 144Hz monitor. It defaults to 300, but the game engine is still heavily limited in multi-core utilization at the moment so it will swing quite wildly. I advise putting it closer to your desired average framerate to prevent some stuttering (although you will still see some, it is the nature of the game and the current iteration of the OpenMW engine)

• Vertical Synchronization is enabled. You can turn this off if you don't mind screen tearing, or otherwise limit your FPS in a way to prevent tearing. I had it enabled in an attempt to reduce some of the occasional stutters, but was fruitless so this may change in the future.

• Window Mode is set to Windowed Fullscreen. I stream, I record videos, I like to be able to alt-tab without the window freaking out when I try to go back into the game. Exclusive Fullscreen is the better option if you have your attention solely on the game and don't need/want to interact with other windows, but for me this is my go-to for all games.

• Anti-Aliasing is set to 0. You can enable this, it goes up to 16x. I just don't see a point in enabling it unless you are heavily modding the game, as aliasing is fairly minor in the vast majority of this game due to the low detail of the graphics.

• Screen is set to Screen 1 and Standard Resolution. Set this as you see fit for your preferences and display.

      Although this is the end of the “Display” section, this is not where visual tweaking ends. For that, we will address some in the next section as well as in-game when we finally launch the game.

Settings

    This category is where the bulk of the changes to OpenMW can be made, and you should take your time going through this and deciding for yourself what changes you want to make and what you value. This category is split into several sub-categories that we will tackle one at a time. I am going to detail what settings I am using, and why. These are not recommendations, and you should feel free to tweak these to your wants and needs.

Gameplay

    These are settings that affect some of the mechanics of the game. These are heavily preference based, and the defaults are a good starting point. I have the following settings enabled:

• Steal from Knocked out Actors in Combat – Why wouldn't you be able to steal from someone unconscious?

• Always Allow Actors to Follow over Water – Default setting, likely fixes pathfinding issues

• Permanent Barter Disposition Changes – In the vanilla game, you can spam trade attempts until you either succeed or get the merchant to 0 disposition and then when you close the dialogue window and talk to them again, their disposition is back to what it initially was. This fixes that, and prevents some cheesing of easy early game money.

• Use Navigation Mesh for Pathfinding – Another default option, affects how the AI is aware of the world around them. I would only disable on low spec machines, or for closer to classic gameplay reasons.

• Followers Defend Immediately – Fixes your followers just standing around waiting for someone to attack once combat starts. In the vanilla game, if someone initiates combat with you (or vice versa) but nobody has swung their sword the AI companions will act like nothing is happening. This makes the AI feel more aware and sentient.

• Merchant Equipping Fix – In the vanilla game any item you sell to a merchant that is better than their current equipment will automatically be equipped by them. This leads to silly but annoying situations where by end game merchants will be wearing all daedric gear and similar. Merchants won't change with this enabled, but to me it is more immersive than the alternative.

• Day Night Switch Nodes – Another default option, I just leave it as is.

• Classic Reflected Absorb Spells Behavior – Restores the vanilla functionality of reflected absorb spells behavior

• Can Loot During Death Animation – Allows you to loot corpses before they have finished falling to the ground. Maybe less immersive, certainly more convenient.

• Enchanted Weapons Are Magical – Restores vanilla behavior around enchanted weapons. Some enchanted weapons may not be flagged as magical in OpenMW, which means they would miss targets like ghosts that are only affected by magic weapons. This makes that no longer the case.

• Classic Calm Spells Behavior – Restores vanilla functionality around the calm spell, stopping NPCs affected by the spell every frame. Disabling it mimics the old Morrowind Code Patch, and may be more balanced than vanilla.

• Swim Upward Correction – Makes it so that in third person your character keeps their head above the water when you are swimming at the surface. In vanilla, it is quite clunky to swim just on the surface of the water in third person.

• NPCs Avoid Collisions – Modifies NPC pathfinding behavior to prevent them from colliding with one another. They may still bump into each other once in a while, but it should be significantly less than vanilla.

• Graphic Herbalism – Allows you to pick supported plants without opening a menu when activating the plant. This mod is included in the I Heart Vanilla list, so I enable this.

• Factor Strength into Hand-to-Hand Combat: Affect Werewolves – Self-explanatory, in vanilla the value of your Strength does not affect damage dealt in Hand-to-Hand combat. This fixes that, and makes it apply to werewolves as well. Might be unbalanced for werewolves.

• Background Physics Threads: 1 – OpenMW can use more than one thread for this, but it seems to not really affect anything. I leave it default.

• Actor Collision Shape Type: Axis-Aligned Bounding Box – Default collision shape, I see no reason to change it.

Visuals

    This section affects the rendering and animations of the game and has several sub-categories of its own. We will break them down by page.

Animations

    The following are enabled in my launcher:

• Player Movement Ignores Animation – Prevents camera sway during movement while in third person

• Use Magic Item Animation – Uses casting animation for magic items, just like spells would. In vanilla magic items did not animate their casts.

• Use Additional Animation Sources – Allows mods to load custom animations

• Weapon Sheathing – If you install a mod to include sheathes and scabbards, this will allow them to render

• Smooth Movement – Filters out the jittery movements the NPCs and player may make.

• Turn to Movement Direction – When combined with the above setting, makes movement much smoother than vanilla and more realistic. Recommended to enable if the above setting is on.

• Smoth Animation Transitions – Makes animations lead into each other more smoothly, and is configurable with YAML modding.

• Shield Sheathing – If you install mods to keep your shield on your character model, this setting enables that to be rendered.

Shaders

    The following are enabled in my launcher:

• Bump/Reflect Map Local Lighting – Fixes objects with Bump/Reflect maps glowing in the dark. Uses shaders to fix affected objects.

• Weather Particle Occlusion – Makes it so particles will no longer fall through roofs and other solid objects

• Soft Particles – Changes how particles are rendered to make them softer.

• Adjust Coverage for Alpha Test – Default setting, affected by mods

• Use Anti-Aliased Alpha Testing – Allows Alpha Tested meshes to use MSAA.

Fog

    Under normal circumstances I would modify these settings, for the purposes of this playthrough and guide I left them default which should more closely mimic vanilla Morrowind.

Terrain

    These settings will allow you to enable distant land and change the view distance past vanilla Morrowind's limited 0.875 cells limit. I left these vanilla, for that vanilla vibe.

Post Processing

    I enabled Post Processing to allow me to change the gamma in-game, as the game appears a bit darker than I would like on my current monitor. Gamma is hidden behind post-processing currently, and you can also use this option to enable other modded post process effects, such as the included bloom. Transparent Postpass and Auto Exposure Speed I left to default.

Shadows

    The following are enabled in my launcher:

• Enable Player Shadows

• Enable Actor Shadows

• Enable Object Shadows

• Enable Indoor Shadows

• Enable Terrain Shadows

• Shadow Planes Computation Method: Bounds

• Shadow Map Resolution: 1024

• Shadow Distance Limit: 8192 Units

• Fade Start Multiplier: 0.90

    This enables all types of shadowing in my game while keeping them looking close to vanilla detail.

Lighting

    I have the Lighting Method set to Shaders, as I have a modern mid-range GPU that is fully capable of running these. On older or weaker devices, Legacy mode or shaders(compat) mode may be necessary.

Audio

    I have changed none of these settings, but if you have interest in having 3D audio you can modify the settings here to enable HRTF and tweak it to your preferences.

Interface

    I have left these vanilla as well, but if you are new to Morrowind there are some nice QOL things in here. Additionally, if you have a monitor above 1080p, you may be interested in the GUI Scaling Factor and Font Size options. I would recommend the following settings:

• Show Owned objects – On (if you are new to the game)

• GUI Scaling Factor – 1.25 at 1080p for closer to vanilla feel

• Font Size – 16 or if you are struggling with the default font, increase up to somewhere around 18-20

• Change Dialogue Topic Color – Should be enabled by default, but keep this on

• Can Zoom on Maps – On – Allows you to get a better idea of what you're looking at on the maps in your player menu.

• Stretch Menu Background – Disable this to keep the original aspect ratio of the artwork. No idea why this is default.

• Enable Controller Menus – On (if you are using a controller)

• Show Controller Tooltips By Default – On (if you are using a controller)

Miscellaneous

    Here you can change the number of maximum quicksaves (I suggest 5) and the format of screenshots taken by the game (PNG is default) and whether you wish to be notified of screenshots being saved.

Testing

    The only option here I suggest changing (unless you are using an experimental modlist) is “Grab Cursor.” This functionality may cause some bugs in certain situations, but prevents your mouse from leaving the game window in multi-monitor setups.

In-Game

    Keeping in mind that I am on Arch Linux and my package is therefore newer than most distros, I am on Release 0.50 currently. This is a release candidate build which means that there may be some differences in the options available to me as compared to the builds in your repos.

    After we start the game we immediately want to head into the Options menu before even starting a new save. A majority of the settings in this menu are very much personal preference and familiarity, but I will detail by category what I chose for my setup.

Prefs

• Menu Transparency – Left it at default. You can make it not transparent or fully transparent, but I llike how vanilla Morrowind does it.

• Menu Help Delay – Left at the default (fastest speed) as I do not like delay on my tooltips

• Difficulty – 0 is the most balanced starting point. You can read on how dificulty works in Morrowind here but a TLDR is that the slider determines how much damage you do to enemies, how much damage enemies do to you, and other RNG manipulations. If you are absolutely lost and unsure how to play, -100 makes the game almost entirely peaceful to play even with your skills untrained.

• Actors Processing Range – Far (7168). This is the maximum currently allowed in-game. This setting determines the distance at which actors will animate and path around. While you can increase the game rendering above this value, it is very rare you will be observing NPCs from further than this. Modifying this in settings.cfg may be possible, but may not have an effect past this value.

• Auto-Save when Rest – On. Creates an autosave when you use the rest command or sleep in a bed.

• Always Use Best Attack – Off. Although if you want to meta-game, turning this on is better. I personally like having the option of attacking in different ways by changing the movements my character is making. This option disables that mechanic, and always uses the strongest attack type your weapon has.

• Subtitles – On. I'm hard of hearing.

• Crosshair – On. This isn't Skyrim, the crosshair is pretty damn necessary for picking up some of the games smaller items.

Audio

    This is heavily preferrential so I won't dive into my settings, but I suggest increasing the Voice volume and decreasing footsteps volume. Voices I max out, footsteps I keep around 20% or so, and then Music I keep around or below 50% as some of it is quite loud.

Controls

    This is again heavily preferrential, my personal changes are that I lower the sensitivity from the default and I swap the “Always Run” button to Shift because I disable my Caps Lock key entirely, and I hate holding Run to move fast. If you have a controller, there is an additional sub-category you can use to bind your controls there.

Video

    More video settings! A lot of these are identical to the Launcher, I will only document the changes made that are not in the Launcher. Note that some of these changes are under sub-categories themselves.

• Field of View set to 85

• Texture Filtering – Trilinear. This is under Detail Level.

• Anisotrophy – 16. This is under Detail Level.

• Water shader – On. This is under Water.

• Refraction – On. This is under Water.

• Sunlight Scattering – On. this is under Water.

• Wobbly Shores – On. This is under Water.

• Texture Quality – High. This is under Water.

• Reflection Shader Detail – World. This is under Water.

• Rain Ripple Detail – Sparse. This is under Water.

• Max Lights – 64. This is under Lights.

• Maximum Light Distance – 8192. This is under Lights.

Scripts

    Currently I am using none of the changes available here, however I recommend reading through each of these scripts and deciding for yourself what features to enable. If you like playing in third person, I suggest the Camera script especially as it allows you to have a more modern camera system in third person.

Language

    Here you can configure primary and secondary languages. I only speak English, so that is what I have set.

Starting a New Game!

    Whew, we're finally to the point where we can return to the main menu proper and click new! You'll have a cutscene to sit through, and then some dialogue. A guard will soon approach and ask you to follow him off the boat. At this point, you can sit down and just play. However, you may be questioning something that I mentioned earlier. Gamma. Where do you change that? Well, at the time of writing this Gamma and other Post Process effects are hidden away under a secret menu bound to F2. Once you are in-game, press F2 and the Post Processor HUD will pop up. Here you can see and activate any and all shaders included with OpenMW, or others you may have installed with mods. Activate the adjustments shader, and change the gamma there until the indoor lighting of the ship is comfortable for you. I have mine set to 1.300 at the time of writing. Contrast can also be adjusted here, though I didn't find a need to on my display. Additionally, you can enable bloom if that is your thing with the bloomlinear shader. Beyond this, you are ready to settle in and play Morrowind. If this is your first time, maybe watch some guide videos or read the UESP's Starting Out page for some beginner's tips.

Conclusion

    Whew, that was a ot. Over 5,000 words, in fact. This is something I chose to write very spur of the moment, and made sure to walk myself through it step by step as I wrote to verify I wasn't forgetting anything. If I have forgotten something, if there are issues with the formatting, or if there is a detail you would like me to include you can contact me on the Fediverse! My signature to each post will explain how to do this.

    While this was a lengthy article and may make the process seem complicated, it is only because I broke things down step by step and included more than necessary detail in hopes that this would be a valuable contribution to the Elder Scrolls community and those with less technical knowledge who find themselves on Linux. There's definitely areas this guide could improve, such as being re-written to be distro specific. I don't have the time, nor the energy to do that, so if you want to adapt this to a distro-specific guide (or Flatpak specific guide!) feel free, and if you see fit to credit me it is appreciated! I'm a huge fan of The Elder Scrolls 3 Morrowind and I've wanted to contribute something to its community for quite some time. Maybe this passionately written article will be the spark that drives me to learning to mod. After all, I did make a simple beast race patch with the OpenMW Content Editor to allow Khajiit and Argonians to wear shoes

I was gonna title this state of the union, then state of the “fenion” and so here I've landed on onion. Congrats, welcome to the onion. No, not that onion.

Superficially, zoner.work looks a lot like it did a month or two ago. The instance is a misskey fork, it has S3 storage, it's roughly instance-shaped. That's about where it stops, though. A lot has changed since even just the start of 2024.

Fired Fish

In late December, it became very much clear that Firefish (formerly Calckey) support and development was going to be at best stagnant, and at worst abandoned. The bulk of the team forked to Catodon and were going in a direction very different from Firefish and the bulk of Misskey, and were still some time away from a public release. The project lead was offline, rightfully so, dealing with serious personal items, some of which stemmed from his involvement in the Fediverse. In short, the future wasn't looking hopeful for the platform.

The question naturally arose – what next? It became pretty important to start scoping out migration routes. As it was, we were already having some serious issues with image processing and usercard generation that had broken in places in just the short time we'd been on Firefish, so staying wasn't viable. While there's a load of Misskey forks, and even some Firefish forks, only a small few presented anything resembling a sensible path. Of the options available, I considered three -

• Iceshrimp – forked from Firefish but with some heavy backend modification, and a forward path focusing on the essentials over the usual Misskey fluff. In particular, the backend rewrites and database optimizations were really attractive. Misskey forks tend to carry a lot of database heft. You can see it in firefish.social crumbling under its own weight. Migration here would be relatively trivial, but with further changes of the database building on what Firefish had changed itself from vanilla Misskey, how far afield would this be putting the instance in the event that Iceshrimp, in turn, became unmaintained?
• Sharkey – A soft fork of Misskey that builds in additional user and administration tools. At the time of evaluation, it was almost like a half-step between Misskey and Firefish in terms of supporting some of the nicer add-ins Firefish had handled in the database (eg longer IDs, more complex passkey hashing) and different from either had added in much finer control of moderation and administration tools regarding users, registrations, and so forth that I'd been missing since leaving Akkoma in September. Structurally, this was closer to moving back “upstream” while keeping migrations easy (the dev had documented a route to move from Firefish to Sharkey). Because it's a soft fork, this also leaves the option to pull in upstream Misskey changes manually should the actual Sharkey project become unmaintained.
• Vanilla Misskey – This one is the full “just move all the way back upstream” to the core Misskey project. There's some odd choices in Misskey itself, but it's a project that's been maintained for several years now, and the dev has shown they're committed to support. I like that kind of stability.

Iceshrimp ended up being ruled out as an option as that felt like moving further down the rabbit hole and increasing risk in terms of support, losing exit routes should things go bad and, I'll be forthright, lack of trust in the development team.

Vanilla Misskey and Sharkey both were attractive. I like the additional Sharkey administrator control features (even if they've proven to be a little convoluted at times) and the ability to add approvals for account registrations, along with the control added by the roles system. The easy initial migration was a bonus. Realizing that I'm doing a ton of handwaving with the whole “I could theoretically pull in upstream changes if Sharkey goes unmaintained” thing is absolutely just kicking the issue down the road, but it wasn't going to be an easy task to migrate directly to Misskey from Firefish anyway, and then there was the potential to have to squash other issues as they arose through natural operation.

All this to say zoner.work is now a Sharkey instance. It hasn't been completely smooth sailing, but the migration rectified a lot of the niggling instance issues I'd been having and were headscratchers we couldn't fix. Usercards generate, SVG instance icons generate, and now I've got much finer control over the onboarding experience. It's been a net positive thus far.

Other Instance Updates

Server Box

I'd documented a while back the migration from DigitalOcean to Hetzner as far as provider for the VPS. zoner.work is still on vCPU-based Hetzner box, but has moved from a shared vCPU to a dedicated one. Thus far, this has kept the server out of trouble during load spikes, and the additional RAM has been necessary as additional services have been added to this same server.

Object Storage

Following multiple outages in the same week, S3 compatible storage has moved from DreamHost DreamObjects to DigitalOcean Spaces. This a few dollars more expensive per month for the level of usage the instance needs, but has been much more stable and reliable.

Backups

zoner.work has always had 7 days of daily snapshot backups via Hetzner's built-in backup features which has been super handy. As of this week, the instance also has 7 days of 4x per day Sharkey postgres database backups stored in a Hetzner volume attached to the server, with offsite copies of the backups kept for 14 days. My hope is that, in the event of a failure, this will allow Sharkey to be moved or restored independently with a minimum of data loss.

Status Monitoring

Status monitoring was previously driven by Upptime. While it was nice to have upptime run out of github pages so as to be completely remote from the cloud VPS, it was unfortunately unreliable and lacked the reporting options I truly wanted (showing only response time graphs is completely unintuitive). status.zoner.work is now driven by Uptime Kuma, with better, more frequent availability reporting, easier maintenance scheduling, and more connection options. The trade-off is that it does live on the same VPS as the majority of services so a full and total outage might take a couple extra minutes to notice, but there's a fair number of failure states between “everything's fine” and “it's a complete disaster” that it's already been able to help catch. Status reporting has been configured for all zoner.work services and their components, not just Sharkey.

Email

All zoner.work services now use ProtonMail SMTP servers for sending email communications (previously, Mailjet was the sender, however there were reliability issues). zoner.work instances, where applicable, will require emails for signup as both a component of bot-limiting measures and to be able to send account recovery emails for self-service password resets. In line with the zoner.work privacy policy, zoner.work will never share email addresses and the only emails you'll ever receive are those that are a part of user-initiated platform functionality, such as the aforementioned password recovery email or user-scheduled digest emails. zoner.work will never send you any solicitations or advertisements via email of any kind.

New & Upcoming Services

In addition to the Sharkey and this writefreely instance, here's what's new and planned for the future:

Matrix – Available Now

zoner.work has a matrix server with aliasing so that it displays the zoner.work domain as hostname. Registration is currently freely open, with a Variance web client (a fork of Cinny) available at m.zoner.work. Feel free to register for an account. At some point registrations will be closed to invite-only. As of now, the matrix server is covered by Hetzner daily backups, but does not have dedicated postgres backups, which will be implemented soon.

Nextcloud – Available Now

The nextcloud instance has been relaunched under the nc.zoner.work subdomain. Registration is by invite only, but feel free to message me if you'd like to test things or set up a space. This is running on its own dedicated VPS due to the resource requirements and in an effort to prevent implosion should things go wrong. 7 days of backups are being kept, and all files are being kept in S3 storage in order to mitigate the need to add non-reducible volumes later. Nextcloud encrypts data into blocks when loading to S3, so that it can't be publicly viewable no matter the settings on the bucket. Due to the functionally limitless but pay-as-you-go storage, I'm able to offer about 50 GB per user. If more was needed, I'd ask for some contribution to the hosting cost. That said, having an ad-free free-free RSS reader option, CalDAV, CardDAV, document editing, cloud storage general space free of the corporate options has been very, very nice.

Invidious – Coming Soon

Despite all my de-googling, youtube has still been a necessity for me in some way. Especially when it comes to hosting stream and personal best VODs from my speedrunning, among other needs for video watching and sharing. I've been scoping out hosting an Invidious instance as part of the zoner network. This, as with the rest, is planned to be public but not completely open registration.

Owncast – Coming Soon

I plan on re-launching the Owncast instance that formerly was at oc.zoner.gay under the zoner.work domain. Initial state will be single-user but I plan on making the platform available to those who need/want it. Still working the structure out on this.

Peertube – On the horizon

I'm still struggling with video content hosting. On the previous peertube instance I tested, using static storage made management a challenge due to the storage needs of the video content, particularly with my need being for longer-length content. I do want to eventually move away from Youtube entirely, but thus far I've found the Peertube instance I'm currently on and contributing to be inadequate for my needs. I'm again looking into bringing back up a Peertube instance with S3 storage as the solution and better hardware, and if needs are met, making this available via invite.

Landing Page

At some point I'll have a proper zoner.work landing page for listing out the available services. Right now the closest to this is status.zoner.work having the appropriate web services linked in the status rows. Eventually, that'll be dressed up, because there's also additional documentation, like about pages, privacy policies, and terms of service, that I want to expand to include the entire service network. As of now, all that is just hosted in pages on the zoner.work Sharkey instance. — That wraps up current state. For anyone using or interested in using any of the zoner.work services, please contact me on the fediverse at @fen@zoner.work by email at fencore@zoner.work, or on matrix at @fen:zoner.work to talk through.

I send this to everyone who ever registers for any of my services, but I'll reiterate it here – my first priority is having services that are available, responsive, and work in the way they're intended. If there's ever any issue, please let me know, nothing is too small. I can't fix the things I don't know about, and while the high-level monitoring is good, it doesn't see functionality-related problems.

For those of you who are zoner.work users, I continue to value the trust you place in me as an administrator of the platform in which you base your online presence. I treat this responsibility with care, and it's important that I'm doing all that I can to provide a stable, sustainable, and safe space.

I went on a bit of an adventure over the past few weeks in a move from Windows to Linux full time. Over a few months of dual-booting I'd taken care of the big, critical hurdles, and finally decided to pull the trigger. One that was still on the list was getting Portal 2 and its speedrunning tools up and moving, and jumped in knowing more or less that there are people who run on Linux, but not necessarily how. Through some trial and error, I got things working for my setup and hope to capture here some of what I learned.

The major hurdles were getting Portal 2 to display correctly and learning how to configure Adrift – I've detailed things below but the major bullet points are:

• Download and install Steam and Portal 2
• Download and install the Linux plugin for SourceAutoRecord (SAR) and optionally also install srconfigs
• Configure Portal 2 to launch in the correct resolution and position using launch arguments
• Download and unpack Adrift Speedrun Timer and the sar_split autosplitter
• Place adrift executable, splitter, splits, and config files in the same folder
• Run adrift and Portal 2

Steam and Portal 2

For Steam, use your preferred method of install for your distro. Many distros have current versions of steam in their package repos, but a .deb/.rpm package straight from valve or install from a flatpak/snap store should be just fine. Install Portal 2, but don't sweat turning Proton on – we need to run Portal 2 as its native Linux version for compatibility with the current version of Adrift.

Install the Linux release of SAR by placing sar.so in your Portal 2 install folder (usually .steam/steam/steamapps/common/Portal\ 2/. Optionally, consider also installing srconfigs in addition to SAR, which provides enhanced functionality and control. Both are cross-platform.

Finally, launch Portal 2. If you're on a single-monitor setup, or you have a multi-monitor setup where your leftmost monitor is your primary, odds are Portal 2 will have launched at the right resolution and position. You're good to move on to setting up Adrift. If you're like me and have a non-conventional monitor setup, or even just a multi-monitor where you don't want the game on the far left monitor, there will likely need to be a little extra to do. This will take some adjusting depending on your specific needs.

I found that if I launched Portal 2 with no parameters, it would try to display at the full resolution of the “rectangle” that encloses my monitors display area, and lock to my center monitor with scaling that wouldn't allow me to interact with anything but the top-left of the window via mouse, and an inability to confirm settings changes via keyboard. This means configuring, generally, through the in-game menus is out.

In Steam, you can add launch parameters by right-clicking on the game in your gameslist and selecting “Properties”. The key options that got 90% of the way there were:

• -sw (-startwindowed): forces Portal 2 to start windowed (as opposed to the default fullscreen) so that its position can be altered with the following options
• -w (-width): sets the game's horizontal resolution
• -h (-height): sets the game's vertical resolution
• -x: sets the horizontal position of the window, larger numbers position further to the right
• -y: sets the vertical position on the window, larger numbers position the window lower

For a full list of launch options, see here.

For my particular use case, -sw -w 1920 -h 1080 -x 1280 was the right combination to position the Portal 2 window on my center monitor at the right resolution.

Past this, you may need to take care of a desktop panel, if applicable, as any existing panels will likely try to draw over top of the Portal 2 game window. In KDE, I set an Application Window Rule to force Portal 2 to be fullscreen from the DE (as opposed to the application). This locks Portal 2 to the monitor and allows it to draw on top of the KDE taskbar panel. Alternatively, one could set the panel to hide automatically or move it to another location. Continue to work the settings until you're satisfied with where Portal 2 launches and displays.

Setting Up Adrift

For Adrift, pre-compiled binaries are avaialble on the releases page. v0.1.1 was most current as of this writing. If you go this route, grab both the “adrift” binary download and the “splitters.tar.gz” archive.

If you'd prefer, you can compile from source – adrift requires a special build of vtk to also be built and installed from source, which itself requires libcairo2-dev and libgtk2.0-dev on Debian-based systems (or the equivalent for your system). More detail is on each project's page for building.

As a high-level overview, Adrift is a timer built on using autosplitters for program control, and cannot be manually controlled, and is pretty bare-bones, which means it's really only suitable for Source engine games such as Portal 2. Being pretty minimal, that means there's a little setup Adrift needs before it can be used.

By default Adrift will look for three files – splits, splitter, and config – in the same directory where the adrift executable is located, but a directory with a set of files for a particular game can be specified at launch time by passing the directory as an argument (eg, ./adrift p2_amc), which can be useful if you run multiple games or categories. For example, if you run both Portal 2 singleplayer and co-op, you might have a directory for portal2_nosla and portal2_amc that each have their own splits and config for Singleplayer No SLA and Co-Op All Main Courses specifically, which will also allow gold splits and peronal bests to be separated. For the rough purposes of this guide, we'll assume a flat structure with all files in the same directory as the Adrift executable – you can always restructure for your particular need if you choose to later.

1. Make a splits file – it is required that a splits file be present, otherwise Adrift will not start. Each line will have a split name. Typically, one split for each chapter or course will suffice with a default SAR configuration. This file should be named “splits”.
2. Extract the splitter file – the splitters.tar.gz archive has a few contents, but what we need is the sar_split file. Place this in the same folder as the Adrift executable and rename it to “splitter”.
3. Create a “config” file – The Adrift github page has details on what options Adrift supports, but at minimum you'll likely want to change the category name to match what you're running. By default, Adrift shows Portal 2 No SLA, with white text on a transparent window.
4. Make Adrift executable – Change adrift's permissions to allow it be executable from either your file manager (Right-click –> Properties), or by running chmod +x /path/to/adrift/executable From here, Adrift can be run either by double-clicking the executable in your file manager, or navigating to the folder where you have adrift stored in your terminal and executing with ./adrift.

Adrift should launch using your config files, and if you launched from terminal you should also see status messages as Adrift searches for the Portal 2 application process. If Portal 2 hasn't yet been launched, do so and verify that Adrift finds the process via the terminal messages. If there are issues, Adrift will give confirmation both when it finds the portal2 process and when it makes connection with SAR, which should help to give indication of where to start troubleshooting.

Start Running

That's the critical minimum to get up and running. From here, Reference SAR and Adrift documentation for additional configuration and customization to meet your needs. Speedrun timing should start when you launch either a Single Player or Co-Operative Game, and using the do_reset command during or following a run should reset the timer and your game both for a fresh run.

Be sure also to visit the Portal 2 Speedrunning Discord server for dicussion, help, and support. Much of the information here is an amalgamation of information from P2SR and the members' effort in gathering resources and creating tools are what allow this to be possible in the first place.

Domains are expensive.

I didn't really put much thought into overall, longterm stability when I started zoner.gay, mostly with regard to cost. Frankly, I'm still surprised that the whole “hosting your own copy of a whole-ass microblogging site” thing has generally gone pretty well. The host migration from Digital Ocean to Hetzner that I talked about in my last post cut my actual hosting cost roughly in half. The other component is domain registrations. Zoner.gay was cheap to pick up, but renewal is going to run $50 when it next comes up. It's not for another 8 months, but that's not never.

The good news is I have a domain I've maintained for years that only runs $10/year – zoner.work. I've basically had zoner.work tied to a hosting plan with dreamhost for years running a managed WordPress site. I don't much like WordPress, so I never really used it as much more than a landing and the one time I made a JSON adapter for Super Mario 64 Bingo. In hindsight, I probably should've held on to that.

Tied to this, I'd been very curious to try one of the *key forks, so I spun up a test Firefish instance and spent a couple days exploring and configuring before falling in love with how polished the frontend felt and finally pulling the trigger and moving over myself. Its not been perfect, but its a great UI experience, at least compared to *oma. At time of writing, I'm about two weeks in and while I have a couple things on the wishlist for admin controls, and there was a weird import bug that led to me opening my first issue on a repo ever, I think this was the right choice.

All of this has been more or less in service of a larger goal – I'd like to open up my instance. If not to public, at least to friends. And even for my own sake, making things sustainable, stable, and affordable are solid long-term goals. I posted up a soft opening and we'll see if we get any takers – moving instances is a big deal and I'm not exactly someone people immediately jump instances for but maybe next time they need a backup or are looking to move, they'll remember me.

So, Firefish is the target for the new instance under the new domain. I absolutely still want to have writefreely for these longer-form posts. Owncast is a pretty easy move since there's only four followers. Nextcloud will be an absolute nightmare though, and I'm not looking forward to it. I'm sure I'll have a long post to write for when that ordeal comes.

The sorta cool thing about having the new instance up now is that, looking at a longer-term option, I've also set up S3 compatible storage for the instance. Obviously that adds a little bit of cost in dedicated storage in the short term (looking at about $4ish per month? we'll see when this month closes for billing), but I think long-term it'll save a lot of headache as the data store gets larger over time. We're already at 13 GB between the two of us, and it'll only get bigger from there.

I do want to take a moment, though, and despite joking about it earlier in the post, truly put to record a thanks to @andy@zoner.work for trusting me enough to make a jump with what is basically his entire social media presence. I didn't ask him to, but he wanted to check it out and then dove in the deep end to do it. It's humbling, it's warming, it's scary, it's emboldening, to have someone willing to completely put their presence in your hands. I treasure that. I can't fully put together a string of words that captures what I think I feel because I'm pretty sure that combination doesn't exist. In lieu of that, I will say this: thank you.

Part of me wants to say 'I hope that to be the first of many' but I don't really think that's what I feel. I do hope at some point it's more than just the two of us on zoner.work, but I don't want that to be because of any individual. I hope to be part of a community of people who share, respect, and dignify each other in a way that I felt when I joined tech.lgbt back in November. I hesitate to say it feels like a calling, but I do think as far as contributions I can make, that being a part of building a safe space within the fediverse is something that I would be suited to, and something that I want to participate in.

Time will tell.

It only took, what, three weeks? It's finally done though. As happy as I was with Digital Ocean (or, thought I was), the cost was just getting to be more than I could afford long-term for what I was getting. All of the active zoner.gay network has been moved to Hetzner, which includes this weblog, the zoner.gay Akkoma instance itself, plus Owncast and a shiny new Nextcloud instance. More on that in a bit.

This whole thing is just one big exercise in learning Docker really – and that it's a little bit more of a hassle than I expected.

I'm running this Writefreely instance directly on the host. That makes for a really easy move the way it's built – just copy the data folder, port over the systemd service, and rerun certbot. Cake.

Owncast is in a docker container but also ends up being an easy move – the docker volume has all the persistent data exposed to the host, so move that and run the single docker run command to get things going again, not a problem.

Nextcloud got stood up in place – I'd set it up from scratch on the host server, so aside from monitoring resource usage, it's a pretty self-contained setup. I do not look forward to the day where it ends up needing to be moved, though, because i opted for the AIO master container installation which was super easy, but I have next to no idea how it works or if/where it's storing persistent data. That's on the investigative to-do list.

Aside from that worry, though, Nextcloud is a pretty neat piece of kit. It's nice to have control of my own cloud storage, notes, tasks, calendar, etc, which is what I had intended to use it for when I set it up. With a shift away from Google on my Pixel 7's fresh install of grapheneOS too, it became the perfect place to also sync my phone contacts outside of my Google account. De-googling as much as possible is really nice.

The feature I've actually come to use the most though, and unexpectedly so, is the News applet's synced RSS feeds. I have both my phone and tablet with a Nextcloud-compatible RSS reader app, and have been slowly building a library of RSS feeds. whatyearisit.jpg

Now, back to Akkoma. Let me preface this next bit – this migration took so long not because Akkoma is difficult (quite the opposite, actually), but because I am woefully inexperienced and past me wrote a check that she didn't know how to cash, which suddenly became present-me's problem.

I had expected, naively, that I might just be able to export or commit the docker containers, copy them over to the new host machine, and then bring them online. Maybe this is doable. Beats the fuck out of me, though, because I spent about two nights trying to get docker to load and connect the frontend and backend containers (yes, i know about the docker network to support this). I think my issue is that I expected docker to behave similarly to a traditional VM container, and it doesn't really.

I also had a sort of nebulous understanding of file handling between host and container which I don't think truly clicked until last night as I was making a second attempt at migration, which may have also been a part of the problem. In short, last week all I had to show for my effort was a broken frontend and no evidence that it was connecting to the postgresql container where my DB was supposed to be.

Over the weekend, I also noticed that I was one release version out of date. That was an issue i wanted to tackle before attempting to migrate again, so pulled and started running the necessary mix tasks which, for some reason, absolutely failed. Compilations did not work, db migration did not work, and the containers would start, but, well, “broken” is the mild way to put it. I should've grabbed a screenshot.

Remember that part where I said I thought I was happy with Digital Ocean? There was this one nagging feeling I'd had for a while which I'd had the foresight to compensate for – that was backups. DO allows for instant snapshots anytime, but backups are completely automated and only happen once a week, usually overnight Thursday into Friday Eastern US time. [Contrast this with Hetzner, which takes backups daily for a rolling 7 days, and both backups (temp) and snapshots (long term) are able to be triggered manually, I love it].

Guess who forgot to take a backup before she started the update process.

Guess who got a really, really unwelcome lesson in hubris.

I was very, very lucky that I was doing this on a Friday night (who doesn't hang out at home rolling The Old Republic and update their web services on a Friday night? What are you, a bunch of shut-ins?) and so the last backup had occurred less than 24 hours before. I could live with a day of lost posts, after all the instance is just me. I restored the backup, but there was still the lingering question of why the update failed in the first place. It was giving me errors and throwing warnings that I needed to verify that there was a compiler installed.

After some poking, I stumbled on that apparently git was pointed to the dev branch. That shouldn't be right. I pointed it back to the stable branch with a reset and re-pulled the new version. Git listed the new files being pulled in. This time the update worked fine, migrations and all. I don't know what exactly was different because I have a feeling there was some other me-specific weirdness happening there, but I didn't care to spend time digging into it. If it happens again, maybe I'll put effort into tracing the issue. Update complete, now back to the migration situation.

It'd been about a week again since I last tried the docker image method. Thinking about it, migrating akkoma is all about just the static folder and the postgres db. Those just lay overtop more or less the same base installation. I'd already gone through that once moving from the OTP install to docker to begin with, why not just, y'know, do it again?

I wish this had occurred to me sooner. Exporting the static content folders and dumping the db was far, far easier. Migration was complete about 2:30 AM Monday morning ET. We're now fully on Hetzner, and as I write this, I destroyed the last droplet I was maintaining. Goodbye Digital Ocean, I'll think of you fondly as my first place to have been supporting my first venture into this...digital...ocean... :

But wait! Fen! Didn't you have a Peertube instance too? What happened to that?

Great question, person I completely made up for the loose purpose of a segue. I debated a bit on moving Peertube over – I really, really love the idea of Peertube as a distributed and federated platform for sharing videos. It's youtube with the power of bittorrent! How cool is that!? Like lemmy and kbin before it, the issue really came down to scope and usefulness. From a resource standpoint, Peertube is heavy, especially when it swallows the rest of the server trying to transcode an upload that's 1-2 hours in length. All I want out of it is to be a place to stash past stream broadcasts and speedrun PB vods, it's just more than is needed and even if I thought it might be useful to open up to friends, video storage isn't exactly a trivial matter.

As an alternative, I'm seriously looking into what I can do with Nextcloud to just make the videos available in a fileshare-type deal and stream in-browser. If that works, I might just do that as the easy answer. If it doesn't look like that's going to be viable in a satisfying way, then I might just sign up for a peertube instance elsewhere and chip in a few bucks to whomever's ko-fi or whatever. That maps same as kbin, where I'm currently on kbin.social instead of continuing to try to host my own. Some things just don't really make sense as a single-user instance.

Speaking of which, the RSS reader via Nextcloud has almost killed entirely my usage of my kbin.social account. I discussed my Reddit and Lemmy/kbin habits in my previous post, but the short version is I was a passive consumer of content for news and my hobbies and interests. Now I've got the news, and the interests never really made a 1:1 jump to Lemmy/kbin fedispace, so I'd already come off that some. I get more of that through Akkoma than I'd really expected anyway.

As is, I think I have a relatively stable configuration of instances that I'm pretty happy with. Next projects are building on what's there – I'd like to get a volume going and give some extra dedicated storage to both Akkoma and Nextcloud, maybe even a proper CDN. Akkoma has some clerical and administrative paperwork I want to take care of with the intent of maybe someday opening it up to friends, but I need to put some polish into it before doing that because it is a very me space.

Whatever you do, pay no mind to the shadowy figure in the background that is a nagging desire to want to set up a Firefish instance just because. You don't need it Fen, you're happy, you're stable, it offers you no benefit. Don't do it.

(i'm probably going to do it eventually, because I'm weak >_<)