Space Engineers: How to Balance Thrust with Gravity

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I have been working on a ship in Space Engineers. Let’s get started!

Space Engineers is a game where you mine resources on planets, moons, and asteroids to build bases and ships. Over my time playing it so far, I’ve noticed many simplifications, like just how step rough terrain can be before my character slips, or the peculiar arrangement of planetary ore. The physics of moving things around, on the other hand, remains more true to life.

Early Game

For context, I’ve been playing “survival” mode: that is to say I started in the Solar System map on the Earthlike planet. It took me a couple tries before I got a self-sufficient base, but I have successfully made my in-game home in the mountains at a high elevation.

Early on, ore is carried by hand in a backpack. I eventually built a little flying truck and taught myself how to fly by trial and error. Without enough downward thrust when fully loaded, I involuntarily go bumping along the ground, and landing gear explodes, leaving scrap metal behind.

I quickly outgrew my little golf cart, so I built my first ship with an interior and equipped it with mining drills. Each time I rearranged its insides, a little more character became permanent features on the hull. I installed multiple systems I didn’t strictly need, like a Hydrogen tank and engines to generate power from an ice splitter. The trickiest of all was making the whole thing airtight and pumping in Oxygen from a tank.

My finished product was about twice as long as I expected, and quite a bit wider. In practice, I have to make multiple passes at the same area, slowly opening it up until I can reach in and get what I’m after. I’m prone to bumps and nicks, and if I drill too far in, I will catch on something, twist on my axis, and start losing control.

Just as important to an individual ship’s success is the ground station’s work. I did the math once, and found my eight little engines could hardly keep up with the power output of one of my batteries. Left to itself, in theory, it can fly roughly 1 minute for every 5 it spends recharging from an on board Hydrogen supply. If it has to split the ice itself, I could be looking at a quarter of the productivity. A well equipped base can generally top the batteries off in three minutes when I tell them to recharge.

New Ship: Concept

The game has two “grid” sizes for building: large and small. Coorisponding blocks take more components to build on larger grids. Storage blocks have much more volume; the biggest coming not quite to half a million Liters of capacity on a large grid. I want to fill one with a small grid ship. At the same time, I’m remembering when that little shovel of a vehicle I built turned upside down on me because it was overloaded. I want to fly the first time without any accidents due to skipping the math, because this ship will be a lot harder to “just unload.”

How Many Thrusters?

The actual number pulled from in-game is 421,875 L. Small grid large containers are 15,625 L, an 27 (or three cubed) fold increase. I spent some time designing a cargo bay with these numbers, and came up with a repeating design with 7 segments of 4 where I can access each container by hand if need be, leaving me with 28 containers and a cargo capacity of 437,500 L.

My experience to date is only on the Earthlike planet, so that’s where I’ll be designing it to operate. Ores can be really deep in the ground, so I’ll want enough reverse thrust to hover when pointing straight down under full load so I can back out of a hole I’m digging. The densest (and only) density among all the ores is .37 L/kg. Paying close attention to the units, I divided my earlier capacity by the density, coming up with a total cargo weight of 1,182,432.432 kg!

The real Earth has a gravitational accelleration of 9.8 M/s/s. Multiplying the weight of the cargo, I get 11,587,837.838 KgM/s/s. Force from the engines are given in Kilonewtons, but conversion is simple if counterintuitive: the Newton is equivalent to the mess of units already present and the decimal just needs to move over. A little rounding lands at 11,588 kN. The thrusters I’ll be using provide 576 kN. From here, it’s a simple matter of division to find I need a hair over 20 thrusters just to lift the payload.

Ship Layout

For this craft, I started with the cargo hold. I stuffed as many batteries as would fit in the gaps and calculated that I’d need the full output of at least 15 batteries. I already have more than that, though I may want additional units for longer battery life.

Moving forward, I have a habitation section. When building, I like to pretend there’s more going on than is mechanically present, so a living space is in order. The cargo hold was tall enough that I had enough space for a second deck, where I added an airlock for entering and exiting the ship, as well as a few ship’s systems: fuel tank, ice splitter for Oxygen and Hydrogen, Oxygen tank, several large Hydrogen tanks. I was having trouble deciding how long to make the habitation section until I took a cue from the length of the big tanks I installed for future space travel, assuming I don’t make yet another one before I blast off.

The third pressurized section is a long neck leading to the cockpit. I’m following the same general idea for a floor plan as my last ship, and this was where my batteries ended up. In this design though, it’s just there to look cool, but in theory should afford a little more leeway when digging. I’ve also included two conduit lines for moving ore back to the cargo hold in case one side gets damaged.

Up in the front is the “spherical” cockpit with a crazy number of drill heads poking out on both the top and bottom. When I took a break for my write up, I was figuring out windows for it, but they’re being a pane to put in without provision for corner blocks that aren’t just a 2D slice. I’m also looking to have redundant ship’s systems below deck. In the case I come under heavy enemy fire (I’m on peaceful for all I know) and the neck snaps, the surviving part can escape to safety and undergo repairs.

All the way in the back, I’m planning on a redundant command center. In the case I’m backing out of a hole I’ve dug or the more dire scenario discussed above, the ship won’t be without a command seat. If I’m going to have Hydrogen powered generators, here is where I’d stack them. I also need a place to stash a whole lot of gyroscopes for rotation control. The overall ship’s design is practically begging for a set of wings, and I’ve read about a so-called gravity drive I can design and build. I’ll be sure to include some connectors to attach such an apparatus if they don’t double for unloading cargo.

Takeaway

Planning a ship is serious business. I’m far from done –probably another couple full days out– but when I checked the weight from the command chair, the dry mass is lumbering in the direction of my earlier ship’s fully loaded mass of about 300,000 kg. I plugged that figure into my spreadsheet, and it told me to expect to need at least 26 engines for neutral lift capability. I’ll of course want to plug the actual number in when I get there, but such is the nature of iterative design: enough extra engines will call for more batteries, etc.

I still have much to learn, like how I’m going to automate that airlock so I don’t vent Oxygen when I go to space, or how to unload all those cargo containers when I dock with home base.

Special thanks go to my father who was there for reviewing simple Newtonian physics.

Final Question

This week was supposed to be a Raspberry Pi week, but I’m out of SD cards, and the cards on order are lost in the mail. What was the last thing the post misplaced for you?

Space Engineers: WINE Is Not an Emulator

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am forcing a Windows game to run on Linux. Let’s get started!

WINE Is Not an Emulator

Gaming on Linux hasn’t always had the best reputation. Software written with one operating system in mind may require the presence of libraries only found in that system, and for the past few decades, that’s meant Microsoft Windows has become the standard for PC gaming.

WINE is a compatibility layer. Their mission is to replace the proprietary Windows libraries with their own open source ones that anyone can freely use. Using WINE, Windows exclusive titles run in “Wine bottles” (or Wine prefixes) that make the correct system calls to either Linux or Mac.

Due to copyright reasons, WINE isn’t allowed to copy-paste any code they look at. Imperfections in execution are an inevitability. Some programs work no questions asked, while others refuse to work all together rated from platinum to garbage.

Steam Proton

I remember seeing someone play Portal 1 on Linux about ten years ago. It one of the earliest titles Steam had running on Linux, but all the walls were blackened like some sort of dark mode. It’s been fixed by now, and Steam will now happily run thousands of titles through Proton, their custom version of WINE. For tech savvy users, they have an option to let any game try to run with no promises provided.

Space Engineers: A Pain to Run

The first time I successfully beat a game into running on Linux with no promises given was Among Us. That game only needed an environment variable or something Proton couldn’t find on its own. Space Engineers, though… it’s something else. ProtonDB lists the game as Silver meaning “[A program] works excellently for normal use, but has some problems for which there are no workarounds” according to WINE’s online database, WINEHQ.

I don’t fully understand what I did in my success. No, Space Engineers will not run easily. My journey started in this community thread on Steam, though the GitHub page they link to is referenced several times over. Just follow the instructions there, and you have a portable black box solution.

But it wasn’t so easy for me. I believe I kept having trouble in creating my WINE prefix. I tried the usual black box rites like rebooting, reinstalling the program, and trying multiple solutions. It wasn’t until I slowed down to find some process hanging in the log that Engineer Man user jeffz instructed me in how to kill the process. Prior to this, I was just using Ctrl+C to kill the process directly in the WINE setup terminal and it would appear to work without the actual game going. I think I managed to rack up a total of 8 to 10 minutes of “play time” in Steam while debugging because not every attempt closed itself.

Followup Work Potential

I pretty much called it good as soon as the game started. Linux discussions kept mentioning “flying grass,” so I was prepared when I saw that, though I have it from a fellow player that there are many bugs even when running it in its native Windows. The only bug I keep running into is an early audio cutoff, usually between the words “Inventory Full.”

My computer is barely fast enough to run Space Engineers smoothly. One of my usual optimizations is ditching the Steam client and running whatever game directly. For a WINE game, though, I’m guessing I’d need to go through the whole process again with another setup, avoiding Proton (I’m using a custom Proton fork by Glorious Eggroll, a recommendation from the ProtonDB page). Unless there’s a DRM requirement where I must use Steam, I’m fine not getting the achievements or other end-user visible hooks. I expect I’ll first try getting Among Us to run from Lutris before tackling Space Engineers.

Takeaway

It is my belief that nothing is impossible to get running on Linux given enough time, talent, and compatible hardware are involved. It is also not unheard of for some games to run better on Linux/WINE than on their native Windows due to the lower overhead from the operating system.

I’ve also noticed a discrepancy where WINEHQ has Space Engineers as low as Bronze or Garbage. Looking at both the age and source of available reports, one needs to not draw conclusions about the runability of a particular piece of software in WINE. ProtonDB had reports near both extremes; most reports are summed up as, “It doesn’t work!” but there are more than a few people who gave detailed specifications on how they got it running. I have a working assembly through a lot of hammering until I found the right spot.

Final Question

If you could run any game on a platform it has no buisness running on, what game would you get running on what system?

Manjaro: Kernel Error

Good Morning from my Robotics Lab! This is Shadow_8472, and my main tower broke last night, so I’m getting a head start on this week’s post. So today, I’m teaching myself how to fix it. Let’s get started!

The Error

I wish I was writing this week about my experience getting Space Engineers to run in WINE. I had spent my Monday in another game only for it to glitch and lose a bunch of stuff. I needed a break, but not like this:

Warning: /lib/modules/5.10.2-2-MANJARO/modules.devname not found – ignoring
mount: /new_root: unknown filesystem type ‘ext4’.
You are now being dropped into an emergency shell.
sh: can’t access tty; job control turned off
[rootfs ]# _

A lack of keyboard response wasn’t encouraging. Neither was a lack of a response from my usual Linux help places. Still, it’s polite to at least drop the error off for an Internet search, but that is a lot of information to throw around. Any relevant results I got were obscured by my inability to understand them.

As if I weren’t having a bad enough day, I went to try booting to an install disk, thinking it to be for Manjaro. It was for Ubuntu — and it was corrupt. All I saw was what looked like a spaghettified terminal in the pattern glitched spots on the screen were appearing.

Understanding the Error

I tried finding my GRUB disk, but it’s lost. After eliminating bad USB ports as the cause of the corruption, I burned a new Manjaro drive over Ubuntu using my Manjaro ARM card in the Pi 400.

Line-by-line Internet searching for the error didn’t get me much farther than before, but breaking the first line apart was the key because it contains a file path. I booted to my newly reeducated drive and mounted my file system to look around.

/lib/modules/5.10.2-2-MANJARO/modules.devname sounds like a file path, so that was a good place to start. Sure enough, no such file exists, but there is a modules.devname.old file. Looking one directory up, there are a few other similarly named directories in a similar format — the next most recent being 5.9.16-1-MANJARO. It did contain a modules.devname. I considered renaming the old version or copying in the previous one, but I’d have had no idea what I was doing, and there were some slight differences I later found by overlapping transparent terminals — not just side-by-side comparison.

I already knew Manjaro has the ability to install and switch between multiple kernels, but I had no idea where they’re kept or how they work. Using this new information, I looked up the names, and I’m reasonably certain I ended up with a bad kernel on my system.

Fixing the Problem

Now that I had a lead on what to pay attention to in search results, I learned that people are complaining a lot about this and similar kernels released around New Year’s. I would like to try reverting a single kernel and seeing how that works.

One problem: every guide I’m finding appears to assume I’ve already booted to Manjaro and gives either a GUI or command line options for reverting.

In my experience to date, I would have expected I could just go in, flip some strings in config files around and call it a day. It appears I have no such luxury though. That or the kernel is so central to the system that “luxury” is not having to flip 45 such config files, not all of which are meant to be human readable (I have no idea here). Nevertheless, the tool of choice appears to be a command called chroot.

Chroot –as I understand it– is essentially used to CHange ROOT (the directory, not the superuser). It opens a new shell with a root directory of your choosing within reason. It can be used to repair broken operating systems using an external kernel, but there’s a similar concept I am not covering today called chroot jail where users accessing a system from the outside are only shown a subset of the system’s actual root directory.

For this post, I will be using the guide “How to: Chroot into a broken system via live CD/ISO or alternate Linux system” on the turnkeylinux.org to set up a chroot and the command line instructions from “How to Switch Kernels in Manjaro Linux” to revert my kernel.

Side note: a different guide than linked brought up a program called os-prober. I found it in both Manjaro and Debian. When I ran it on my tower, it quickly found my main Manjaro install, but didn’t find my Windows drive I believe to be connected but not mounted. Other methods showed me evidence that it’s still there.

Attempt 1

I didn’t completely follow the set of instructions on how to set up the chroot. I performed them from my root directory ‘/‘. Things started going wrong when my second chosen set of instructions weren’t clear at all about how to manage multiple kernels from the command line.

I started improvising. I tried to launch the GUI version of systemsettings5. Going through the menu pointed straight to the live USB’s kernel, and all its settings no doubt. Going through the command line was fruitless until I had exited out of the chroot and umounted all extra directories, even when I used su shadow8472 to switch to my normal account, a procedure which root could not reproduce after the chroot ended. In short: I did something right, but I’m not done yet.

Attempt 2

This time, my plans required access to the terminal. My plan was to proceed with the same chroot setup, then work my way into a graphical interface hosted with enough elements from my actual tower to work. Any attempts to use a shortcut using Ctrl+Alt+<function keys> only switch to close representations of the true console, but in reality are running on top of that x server I needed to free up. I followed another set of instructions found here, set up the chroot, and it failed.

Third Try

Left with no other options I begin to understand, I moved on with the command line method of actually uninstalling a kernel. I received a stiff warning about how removing the suspect kernel, linux510, breaks a dependency required by linux-latest.

This attempt was interrupted by someone who sounded like he knew what he was talking about suggesting a few things.

The Actual Solution

Changing direction again, I found this Reddit thread that showed me how to expose a GRUB menu for which kernel to boot. From there, I was able to boot a working kernel and get in.

Out of curiosity, I did try to remove the bad kernel from the GUI tool, and it appeared to work until it was still there after a successful report. I was able to bring up the same failure message from the command line in a dialogue box.

Minor Developments

I’ve had tons of issues with my Wi-Fi card, so I turned it off and this week while focused on it, I’ve opened the case, cleaned it, and pulled the card. Maybe it’s software, maybe it’s hardware, but as of this week, I’m using my Pi 400 as a Wi-Fi to Ethernet receiver full time until a suitable replacement can be arranged.

Takeaway

I never realized how far I could get myself sans help on a problem I’ve never seen before. Perhaps I’ve reached a point where my skills are not readily surpassed by those around me. The one recommendation from a person who sounded like he knew what he was talking about turned out to be a dead end (removing the .old extensions from all the kernel modules).

Computer problems can happen to anyone. They’re just easier to learn how to fix without special training on Linux.

Final Question

When was the first time you solved a complex problem you had never encountered before without help?

Family Photo Chest Part 11: PiCore

Good Morning from my Robotics Lab! This is Shadow_8472, and what a week it’s been! Today, I’m telling you the story of how I’m building up an operating system just to scan photos. This is also a follow up to last week’s topic, where I introduced PiCore as a base. Special thanks to Rich and Juanito of the TinyCore forum who have been answering my questions as I learn about this amazing, little Linux distro. Let’s get started!

Window Manager

I feel like I could do a post or two just on window managers, and I may do so in the future. Long story short, a window manager is responsible for drawing windows within a window server, and not much else.

I now know I used to judge a desktop environment by its window manager without much thought to all the other individual programs going on in the background: a file manager, menus, text and document editors, sometimes even a browser and often a calculator. All of that is bloatware for my purposes. My goal is to have as slim of a system as possible for running GIMP without spending days on end cinching the last megabyte out of the system. After all, I still have to look at it.

Which brings me to my choices in window managers for PiCore. With a smaller tce repository due to being off the main TinyCore branch for X86, I only found a few options. FLWM (Fast Light Window Manager) ships with TinyCore in the main branch. I installed it, and hated all the stuff on the left side. I suppose someone must like it, and I can admit it takes up less vertical space, but I do need at least a few familiar points of reference.

I started researching window managers, but only when I searched tce for keywords: ‘window manager’ did I realize just how short my list was. Least of which was a package that looks like it only multiplexes terminals. One of the admins helping me pointed out FLWM_Topside, but I’m not really a fan of jumping cursors, and I had already selected JWM (Joe’s Window Manager).

I found JWM simplistic and appealing. I had already used it in the past as part of the MATE desktop environment, like what I’m using now. The base version is configured by a text file, which I modified by hand to display a panel at the bottom as opposed to the top. There isn’t even support for calculating that automatically!

I was also sure to remove FLWM packages from tce/optional. There are other spots where it’s left hooks for proper execution, and I’ll weed those out when I see them.

NFS Auto-Mount

Network File System: I’m getting the basics, only for TinyCore, my usual method of mounting shares gets flushed out on reboot. But I can work with the system I have. I can’t give the TinyCore people enough credit: they produced a shell script I could customize and told me how to install it.

Color Depth

Just a note, really: Color depth is a thing. The scanners I’m working with each use 16 bits to say how much of each primary color is present in a pixel. I was warned by user barefootliam on the Gimp Discord server that a XSANE plugin may only use 8 bits. I don’t know for sure at this time, but it’s worth noting.

Amusing Errors

Along the way, the system broke — a number of times even. Early on, I found how to hold Ctrl+C to close xorg as it started and to drop to the command line. Sometimes it was root, other times it was the default user, tc. Now that root has a password, it won’t let me pull that one, thankfully.

Another time, I was changing the default GIMP icons from plain white to color. It crashed JWM. I tried several times, and the result was always the same: All the window decorations around the outside were gone, and I was left with GIMP selected, unable to switch to the terminal so I could save the changes with filetool.sh -b as you do when using TinyCore. I found the sleep command and set a delay to restart JWM using sleep 15s && jwm. At first, I was adding a restart command to jwm, but without JWM running, I was left with a dud command and a brick to forcefully reboot.

Toward the end of this development cycle, I was debugging JWM and moved the config files to a separate directory and restarted the program. Yikes! Turns out it came from the tce repository with a theme of its own. Rebooting once again restored the theme to default, but didn’t solve the empty config file issue.

Future Plans

A computer system is hardly ever a static setup. When I have another SD card, I will want to look into a clean build on the aarch64 version of PiCore. Turns out I’m in the 32 bit version. My dream though is to build it on the 8 GB Pi 4 once I know what I want here.

I may not end up using a Pi at all if it just can’t keep up with my old laptop on its scanner.

Takeaway

TinyCore is a fun operating system. It may be a bit limited due to low popularity, but the community I’ve now contacted gets back pretty quickly. Just know that connections to their site are unencrypted, so if you go there, USE A UNIQUE PASSWORD! It’s just good practice anyway. Here’s a link here to the help thread I’ve been lurking in.

Final Question

What kind of long duration projects have you completed?