I just set https://simpit.dev/ live.
Primary Buffer Panel – The #SimulatedCockpit On A #Linux PC For More Immersion In #Space Pew Pew
A glorified #DIY joystick controller with an LCD (‘MFD’) and plenty of RGB.
Best viewed WITH an ad-blocker (thanks @stefan)
I’m kinda blind by now after hacking away on this page for days so I’d appreciate feedback.
Especially if something is broken.
Yes, #NoMansSky does only support one gamepad. Single digit. This gamer doesn’t care. Here have #Headtracking and #HOTAS in #NMS. Vanilla. No mods. Thanks #OpenTrack, #AntiMicroX and #MoltenGamepad ❤️
Mebbe I’ll do a proper recording someday:
Wondering about that button box? Didn’t use it in this demo but you can find plenty more examples on the channel and more details on my blog: https://beko.famkos.net/category/simpit/
How it’s done? NMS does support a gamepad but it also reads/maps all gamepads to a single device. It makes no difference between multiple gamepads!
This leaves me with a very limited amount of possible buttons on the HOTAS after mapping that to one virtual gamepad using MoltenGamepad (I usually split that one up into multiple gamepads for braindead games).
So for additional buttons I used AntiMicroX to map the rest as keyboard presses.
Doing so I noticed that NMS does “look-around” on the right stick and this is where OpenTrack comes into the play. It offers a joystick output (using evdev) and that is also just… a gamepad! Needs some remapping though to get pitch and jaw to the proper axis for NMS. This is done via SDL env (basically what Steam does under the hood but boy their GUI for that sucks): SDL_GAMECONTROLLERCONFIG="000022e86f70656e747261636b206800,opentrack-to-nms,rightx:a3,righty:a4,platform:Linux,crc:e822,"
And there you have it. NMS with my trusty old X52 Pro and a DIY headtracker for 5 bucks 🤓
PS: I’m aware that the recording quality sucks. This was very spontaneous with a webcam sitting on my chair. I basically just finished my happy dance that this started working properly and decided to smash that recording button. PC was not even in “gamemode”.
This content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International license.
I hacked a mod for X4: Foundations to get ship telemetry and targeting data to my “Primary Buffer Panel” via a socket. This is a demonstration of my simulated cockpit made from cardboard on a budget usually used to play Elite Dangerous now also used for X4: Foundations. This is work in progress.
In use:
This is loosely based on the Python Pipe Server mod for X4 that is sadly Windows only using Named Pipes. I fixed that for Linux PC by side-loading the library LuaSocket and starting a socket server directly in X4. That’s right, the Python Server is simply not needed now and companion tools may directly connect to the socket. It’s a nice bonus that LuaSocket also allows a UDP or TCP server depending on how it is started. That was some piece of work though and I’m still wrapping things up to publish my code changes. I’m also still looking for testers so if you’re interested get in touch!
So you _still_ think you can’t space pew pew on Linux PC? Think again. I do it all the time: https://beko.famkos.net/2021/10/16/space-pew-pew-on-linux-pc/
This content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International license.
Another night in the X4 sandbox: https://www.youtube.com/watch?v=665hXLKSfek / https://tube.tchncs.de/w/pHFP8jZf7PYLyLZSARZQ4T
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
FIY Should update within 24h https://youtu.be/RIGkmqzJdfQ
It’s a #foss 6dof racing game with a #Newtonian flight model similar to #EliteDangerous.
It does have a #Linux version but the world gen lib is single threaded on Linux so Proton may be a better choice for now.
It also features access to full ship telemetry and head tracking including OpenTrack via UDP thanks to my nagging 🤪
No idea about VR. Apparently it works but I can’t test that.
Okay, I did some recording of SpaceBourne 2 and added a voice over and even subtitles… and I conclude that is way too much work but in case you’re interested into a sneak peak of this early access go ahead: https://www.youtube.com/watch?v=Vz4uK2Irofo / https://tube.tchncs.de/w/5h9VoeHs5vTAu3bgptc7bN
This content is licensed under a Creative Commons Attribution 4.0 International license.
DBK Games (SpaceBourne 2)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 -oldbigpictureAfter 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:
vainfo --device /dev/dri/renderD128 --display drm
Trying display: drm
libva info: VA-API version 1.16.0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_16
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: 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)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileAV1Profile0 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
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!):
dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
dnf update
dnf swap mesa-va-drivers mesa-va-drivers-freeworld
dnf install mesa-va-drivers-freeworld.i686And sure enough vainfo now has a way more complete list – including the previous missing VAProfileH264Main profile:
libva info: VA-API version 1.16.0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_16
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: 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)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileAV1Profile0 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
And sure enough the Steam Link started working again. Somewhat. Now I have issues that some games don’t get captured or loose focus eventually but that I’ll debug another day 😩
Linux Gaming in 2023 is easy. Remote Play… not so much.
This content is licensed under a Creative Commons Attribution 4.0 International license.
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[1] 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:00000000So 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
<pref name="Screenmanager Resolution Height" type="int">1200</pref>
<pref name="Screenmanager Resolution Width" type="int">5760</pref>
<pref name="Screenmanager Resolution Use Native" type="int">0</pref>Why games|engines in 2023 still seem to have ideas about screen layouts is frankly beyond me.
Update: #gamescope really eases the pain here as well. See also https://SimPit.dev/games/fly-dangerous/ how to use that with Steam.
[1] Headtracker quick test recordings: https://www.youtube.com/watch?v=13L0GlQyf_Q / https://tube.tchncs.de/w/fTYSUc9fTBmnTLHp2fpW4n
This content is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license.
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 http://www.wtfpl.net/
name = "x52_pro_controller"
devname = "x52_"
exclusive = "false"
change_permissions = "false"
flatten = "false"
rumble = "false"
split=2
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.
If the game does support only one gamepad consider binding joystick _buttons_ to keyboard presses (e.g. with AntiMicroX instead).