Tag: EliteDangerous

Another night in the verse 🚀

Made some progress on the HUD (I think I need a name for that). It does provide me with some additional informations depending on what I’m doing. The Route Plan e.g. disappears automatically when the destination is reached (yeah yeah the Jump count is off, will fix that eventually).

Same for scan targets – that also reveal bounties (with rewards in Cr so I know if it’s worth the hassle :D).

Really like where this is going.

Posted on
by

Here are the humble beginnings[1] of a working example to read the ship status of in a format very similar to the Status File of

Both games are quite similar and by using a “well established” format it should be possible to use this with existing companion apps – like my own

It uses the “Named Pipe API” of “sn_mod_support_apis” – on PC 😁 This was not supported by this MOD so far but I made it work.

Well, at least on my machine 🤓

And yes, the pipe server works with some minor adjustments for other _existing_ apps as well. Here is a demo of with a data feed directly from X4: Foundations – it does not use the though, since that is not really needed, so I had to make some small adjustments in it’s connection routine but that was like 2 lines of code 🤷

[1] TBF the humble beginnings were back in 2021 (https://beko.famkos.net/2021/05/01/getting-into-x4-foundations-modding-on-linux/) but I kinda let it slide to tinker and build my Primary Buffer Panel (https://beko.famkos.net/category/simpit/) first. Other games made it easier to retrieve game data and I did learn a lot during that time but it was X4 that started it all.

Posted on
by

I’m wondering how to present ultra wide screenshots for a while now, because most people will not have an ultra wide display at hand or not run their browser in fullscreen on such a device. A scaled down version with retained ratio also just don’t really cut it:

Now what if we could wrap this in some sort of 360° image? This isn’t really 360°, of course but you get the idea. A quick search usually yields JS libs like Pannellum (https://pannellum.org/), which look great for this use-case as well and yes we could also solve this in CSS by using an animation and go for a little camera ride.

What if we could optionally also make use of a gyroscope though? You know, that sensor every mobile phone, tablet and VR device comes along with. So the user could device where to look just by moving the device around?

This was when I stumbled over A-Frame (https://aframe.io), which is basically a library for building 3D AR or VR experiences and while I may only scratching it’s surface with my quick tests here it does deliver exactly what I was looking for.

I built demos for various games today and I don’t know how long I’ll host the files here but they all follow the very same code pattern that I’ll add in the end:

https://beko.famkos.net/aframe-elite-dangerous.html

https://beko.famkos.net/aframe-fly-dangerous.html

https://beko.famkos.net/aframe-nms.html

https://beko.famkos.net/aframe-rebel-galaxy-outlaw.html

https://beko.famkos.net/aframe-spacebourne2.html

https://beko.famkos.net/aframe-starcitizen.html

https://beko.famkos.net/aframe-x4-foundations.html

Please be aware that I’m loading a ~5mb blob of JS code directly from A-Frame in the demos so don’t check them out if that is a problem for you. The image asset adds another whopping MB so please be patient. The best experience is on a mobile phone where you should be able to look around by moving the phone left and right. It works on a desktop browser too where the mouse can be used to look around.

Here is a code snippet that shows hows it’s done:

<!DOCTYPE html>
<html>
<head>
  <script src="https://aframe.io/releases/1.4.1/aframe.min.js"></script>
</head>
<body>
  <a-scene loading-screen="dotsColor: #ff6a00; backgroundColor: black">
    <a-assets>
      <img id="sky" src="./wp-content/uploads/2023/03/elite_dangerous_odyssey_for_my_valentine.jpg">
    </a-assets>
    <a-entity id="rig" position="-8 0 0" rotation="0 90 0">
      <a-entity id="camera" camera="fov:45; zoom: 1" far=90 look-controls></a-entity>
    </a-entity>
    <a-text color="#fff" value="Elite Dangerous ...on a canvas" width="3" position="-10.5 -0.5 1.5"
      rotation="0 135 9"></a-text>
    <a-curvedimage src="#sky" height="20.0" radius="10" theta-length="180" rotation="0 180 0"
      scale="2.5 1 2.5"></a-curvedimage>
    <a-sky rotation="0 0 0" position="0 0 0" color="#000"></a-sky>
  </a-scene>
</body>
</html>

Feel free to copy this snippet and play around with it. Just keep in mind that you have to use _local_ assets too or they won’t show up. Make sure to read the documentation too and play with the built in inspector opened with the key combination ctrl + alt + i.

And yes I’ll happily take a CSS only variant too but I really doubt that’s possible without loosing features like gyroscope data usage.

CC

This content is licensed under a Creative Commons Attribution 4.0 International license.

FIY Should update within 24h https://youtu.be/RIGkmqzJdfQ

It’s a 6dof racing game with a flight model similar to .

It does have a 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.

Posted on
by

A lot happened since my last update on the simpit – under it’s hood. Function wise it changed not so much so the older demonstration video is still better for a quick demo. I still assembled a new video from clips of the first evening with the new hardware:

Quick trip from Armstrong Orbital over to the huge crater on HIP 117029-4 and back

So what changed? I got rid of the CY-822A USB joystick controller that, while good, was also limiting. Especially in inputs and how they would react. The Raspberry Pi, that I used to drive the status indicators, is also gone. This is all replaced by one single Arduino Mega that is connected via serial over USB.

A custom joystick daemon written in Rust is listening for data from the and feeds back the flags of Elite Dangerous to drive the blinken lights. I also extended the source to add me some rotary encoders (with push button function) and I’m very happy with the result of this. That makes a whopping amount of 48 buttons and 6 axis (where 2 axis make one hat). And it feels _so good_ to have e.g. self destruct or eject cargo save under a protective cover now 😀

An enemy vessel exploded, the bounty is mine
That rocket was too close for comfort
Limping to a hangar after taking battle damage
Evading a firestorm from behind by moving sideways
Various screenshots from a gaming session of StarCitizen

The panel also got an external PSU with enough ampere to drive as many LED as I may imagine so I no longer abuse a phone charger for that or risk frying of the PCB / USB.

With all that in place I streamlined my pre-flight check-list quite a lot because way less hardware is involved and most of this is automated by now. It wasn’t all fun n giggles tho and while the new hard- and software “just worked” in e.g. it was that gave me a hard time to actually use most of the new buttons.

Getting all the precious buttons into Elite as well (okay, limited to 32 thanks to an old dinput library but who is counting at this point – will simply set the rest to keyboard macros instead)

Turns out it had no idea about the device and model identifiers reported by the joystick daemon and that the kernel assumed a gamepad based on declaring e.g. ButtonNorth via the more recent xinput system really didn’t help – because that limited the amount of read buttons via xinput severe! In the end I set it’s identifier to a “vJoy” device. That I found in the DeviceMappings.xml of Elite and since this could be basically anything I gave it a try (and removed all “offending” magic gamepad buttons from the code) and sure enough Elite started accepting the inputs as expected and from there it was smooth sailing – got even the hat working.

Oh and for everyone who is wondering what exactly they are seeing on the “MFD” when I’m playing Elite: That’s basically a Website using the FUI framework. Find a quick demo video here. Without the cardboard covering up parts of the screen it looks basically like this:

What the game shows
What the ARWES website shows as MFD

I also started doodles for a version 2 – now that I have an idea what I really want.

Plans for another based on a Valkyrie Cockpit

CC-BY-NC-SA

This content is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license.

Fly Dangerous on Steam by Jay FaulknerJay Faulkner (store.steampowered.com)
Extremely high skill-ceiling 6dof flight racing in a variety of environments with leaderboards, multiplayer and VR support

https://store.steampowered.com/app/1781750/Fly_Dangerous/ released today as early access. It’s free, fast, opensource and has . The flight model is inspired by games like (Newtonian flight model). Oh and it has . o7

Posted on
by

The last update has been a while. I focused my attention to the MFDs (Multi-function display). This part didn’t get much attention yet and I was caught between the difficult choice to learn yet another fancy framework, like Raylib, that would do OpenGL ES 2.0 without X11 on the Raspberry – or just throw the might of my CoffeeLake at it and go with ReactJS since most of the data was already available via NodeRED anyway. Also… ARWES is just so cool 🤩

I went with ReactJS and ARWES again, simply because I have some experience in this by know thanks to my Streaming Overlay I wrote with it. Hobbling it up to NodeRED was just a matter of installing SocketIO to transport the messages. It’s all a very hacky mess but it gets the job done.

Video demonstration of my simulated cockpit made from cardboard on a budget mainly used to play Elite Dangerous in early 2022. This is work in progress.

While seeking through the available data I noticed that I don’t get velocity values from Elite. That’s not so important in space but _kinda_ interesting for me in planetary flight to satisfy the flight sim gamer in me as well. I noticed tho that I do get timestamped latitude, longitude and altitude values so shouldn’t it be possible to “simply” calculate this, right? Right?

This was when I dived into the rabbit hole of calculating velocity and heading on planetary objects using a spherical coordinate system and while I didn’t nail it exactly how Elite does it the result is close enough. The game provides the required data to go crazy here – most important the radius of the current object. In _theory_ I could start writing some primitive AFS (Auto Flight System) routines now, which I’m totally going to explore at some point in the future just because 🤓

Checking my maths – yes, altitude is added to the mix so velocity is mostly correct as long as no rapid course changes are made

After spending way too much time with this and the Pythagorean theorem (Yes mum, a game made me do maths. MATHS! 🤯) I settled with some calculations and data for my current ship to the right and targeted ship data on the left. This is sort of tricky because many game events update different parts of the data so timestamps have to be kept in mind and a game specific parsing strategy is required. See the last part of the demonstration video to get an idea how this looks.

Improving situational awareness by putting the video feed of wingman / gunner on the central MFD.

Another point to tick off my list was getting the head tracking to work in Elite (again). Now this is very Linux PC specific so you may tune out on this paragraph. On Linux PC I’d usually compile Opentrack with the Wine Glue, patch in my appdata dir for Proton and hope that it’s still ABI compliant to Just work™. Alas recent Proton is sandboxed within pressure vessel and the usual approach of memory mapping is simply no longer working, if I got the gist of this right.

So my _current_ strategy is to download and drop the Windows build of Opentrack into the game folder and chain-load the EXE with the game where the Opentrack EXE would listen on UDP while my native Opentrack BIN would send via UDP. A task not made easy with Proton but it is possible. The following snippet may give you some pointers:

#!/bin/bash
export STEAM_COMPAT_DATA_PATH=/games/steam/steamapps/compatdata/359320
export STEAM_COMPAT_CLIENT_INSTALL_PATH="$HOME/.steam/steam"
python3 /games/steam/steamapps/common/Proton\ -\ Experimental/proton run opentrack.exe

Why running Opentrack twice? The native build performs a lot better with my webcam and every frame really count here. Reading data via UDP is not much of a burden for Proton. This also saves me the trouble of fiddling with Wine Glue, a painful compile process nobody should endure involving installation of many many additional 32bit libraries. Hilarious but it works.

CC-BY-NC-SA

This content is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license.