This is heavily distilled early gameplay of X4: Foundations, where I started another play-through slowly expanding my little empire with trade, side missions, station building, border patrol (loosing the the “Misfit”, my good old starter-ship), a surprise Xenon attack on a station where I was just for shopping and eventually good old fashioned piracy with unexpected guest appearance of some Kha’ak trying to crash the party.
01:11 Setting up trade routes aboard The Law Abiding Windrunner 02:20 Switching over to the Misfit 03:05 Witnessing the death of a trading station (while escorting my own ships to safety) 03:50 Patrolling for money (and looting stuff) 05:48 Repairing satellites (in EVA suit) 07:32 Docking at the impressive Teladi ring station for shopping 08:45 Surprise attack on the ring station by a Xenon K (and it’s demise) 14:32 Extending my own station and buying more mining ships 11:26 Switching over to my frigate for border patrol (lots of pew pew) 14:30 Loosing the Misfit to Kha’ak (and avenging it) 16:07 Going for resupplies and preparing for piracy 16:39 Ambushing the prey, a fat water freighter looking for a new owner 17:59 Starting the boarding operation 18:40 Realizing I need more support to deal with surprises 18:58 Stumbling over mentioned surprises, Kha’ak trying to crash the party 19:51 Sending more boarders as the first group fails 20:22 Finally going home with the price, a “slightly banged up” L water freighter
The official website of indie game studio DBK Games, the developer of SpaceBourne series and Mesel.
So this was recommended to me by Patola and while I usually do not buy into an early access game I made an exception. I’ve only seen one hour of the game so far but this promises a lot of fun. It’s still very rough, that I can tell – and often inputs do not register or register double. Nonetheless I felt right at home and after a lot of fiddling with the inputs I was happy enough to give it a spin with my X52 Pro (that was indeed detected just fine after the initial tutorial).
So after learning the basic ship navigation and shooting up some drones during the first quest I got ordered to investigate some asteroids.
There were of course some pirates hanging around and the shoot-out did take more time than I’d like to admit. For some reasons I could not for my life get any target lock so all the shooting had to be done with the good old Mk 1 eyeball without having an idea about reach (or even arcs?) of the weapons. Probably a bug. Or user error. The jury is still out on that.
Next was a surprise. After parking the ship in stealth I was ordered to exit and do a little space walk to clear a hidden platform of hostiles. Space diving was not on the things I expected 🤯
Anyway, after some more shooting, and some more explosions, I was back with the contractor and the reward was for reasons yet unknown a freakin robot head. That kicks off a quest to reassemble that poor thing. For some reasons this unfolded into an epic space battle where two different fractions slugged it out in the middle of an old battlefield with me, the contractor helping with the parts and the robot head in the middle – also somehow attacked by scavengers as a 4th faction. What a chaos!
After surviving this I got recommended to someone else to get the robot assembled again. The person that would be able to do this resides on a station in another system though, which means travelling through a… stargate. Awesome! After filing a flight plan and requesting passage I had to line up my entry and found myself in another system – surrounded by illuminated advertisement of all things, of course.
An in-system jump later I docked at a station and found the contact that would help me with the robot. For a price, of course.
This was where I decided to stop for today. So much stuff happened during the first 60 minutes of this and judging by the in-game menus there is a lot more to come. There are skill trees, load-outs, factions and many systems to explore. Yes, it’s not as beautiful as StarCitizens but it’s perfectly playable already and I’m getting Wing Commander vibes from that and this feels rather good.
I didn’t use my Steam Link for some time and was kinda surprised by the new UI in Big Picture Mode. And also very unhappy because it was a stutter feast with buffer artefacts all over the place. Once I could get a game running it was butter though so something was up with the streaming mode of the UI. I’ve no really an idea what’s going on there but this was always a problematic thing with my AMD GPU under Gnome using Wayland when it comes to streaming and remote play. I ticked off the basics and disabled the blocklist for unknown GPUs, made sure that AMD hardware acceleration was enabled for the host in the Big Picture setting and even tried to launch it with the old big picture mode but no dice:
steam pipewire -pipewire-dmabuf -oldbigpicture
After reading around a lot on the bugtracker at https://github.com/ValveSoftware I eventually learned that the hardware acceleration for remote play is usually done with VAAPI and that there is debug information in ~/.local/share/Steam/logs/streaming_log.txt and sure enough here it was:
ffmpeg verbose: libva: VA-API version 1.16.0
ffmpeg verbose: libva: User environment variable requested driver 'radeonsi'
ffmpeg verbose: libva: Trying to open /usr/lib/dri/radeonsi_drv_video.so
ffmpeg verbose: libva: Found init function __vaDriverInit_1_16
ffmpeg verbose: libva: va_openDriver() returns 0
ffmpeg verbose: Initialised VAAPI connection: version 1.16
ffmpeg verbose: VAAPI driver: Mesa Gallium driver 22.3.5 for AMD Radeon RX 6700 XT (navi22, LLVM 15.0.7, DRM 3.49, 6.1.11-200.fc37.x86_64).
ffmpeg verbose: Driver not found in known nonstandard list, using standard behaviour.
ffmpeg verbose: Input surface format is nv12.
ffmpeg verbose: Compatible profile VAProfileH264Main (6) is not supported by driver.
ffmpeg error: No usable encoding profile found.
So the profile was missing and a check with vainfo confirmed this:
This was the moment when my brain did pull off one of it’s tricks and remembered me about the story about Fedora _disabling_ hardware acceleration for H264 due to proprietary concerns some months ago and yes I did recently upgrade to Fedora 37 🤯
Thankfully the community stepped in already and fixed mesa drivers are only one dnf install away on rpmfusion, so there is no need to recompile this with h264 support (and some others) manually. There is a caveat though because the swap command would happily delete the needed 32bit versions for Steam and only install the 64bit version of the swapped package. Keeping this in mind the required commands are basically this (and if this breaks your system I do not want to hear about it – use your brain!):
I usually play #FlyDangerous on Linux PC. I switched to Proton because I was eager to see some upcoming changes, like #headtracker support, on the public_beta branch. And while this works I was once more flabbergasted how complicated it is to set my desired display resolution of 5760×1200. I’m using a multihead setup with several displays and as usual the game engine would not let me _simply_ set that. Even in windowed mode (I mean I get that this won’t work with fullscreen).
There are several ways to work around this, especially with Proton, but I was looking for the prefs file I know from Linux. I found it in the end in the file compatdata/1781750/pfx/user.reg (that’s like the Windows registry but as plain file read by Wine) where the values are stored as dword under [Software\\StarGoat\\FlyDangerous]. In hex.
"Screenmanager Resolution Height_h2627697771"=dword:000004b0
"Screenmanager Resolution Width_h182942802"=dword:00001680
"Screenmanager Resolution Use Native_h1405027254"=dword:00000000
So 0780 and 04b0 are in the end 5760 and 1200. And sure enough, on the next game start I get _my_ desired resolution:
Sadly when I change settings in the game this gets overwritten again – so keep a backup around and drop it in again. This may even be added to a script – let’s see how long until this gets on my nerves and I automate that.
For the interested: This is how the same thing looks on the native version in the file ~/.config/unity3d/StarGoat/FlyDangerous/prefs
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).
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: https://www.dsm.museum/en/exhibition/exhibitions/bremen-cog
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: https://www.youtube.com/watch?v=KjYigiyF014
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 😉
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.
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:
Working on a #cog 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 #RisingWorld 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 https://github.com/paulevsGitch/BlueLib 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: