What are SNIS's effective minimum system requirements?

[Shadow8472]

I understand this is going to be a very complicated answer owing to the modular nature of the game and variable weight of Linux, but I couldn't find anything except [Not a Raspberry Pi] or more recently: [Nothing weaker than Pi 4B for most stations].

I just got to a SNIS client running its own servers using a system with 2GB of RAM and a Core 2 CPU with 2 cores (originally built to run XP). The game took minutes to load, the weapons were sluggish, and the main screen degraded after a couple minutes into displaying random tri's with simple rgb colors, but the other stations appeared to work for a few minutes of testing. (I had no speakers hooked up, so I couldn't test sound.)

So while I understand it doesn't make much sense to ask the minimum/recommended specs on the simple stations as about anything with a window manager can run them, what is needed for Main Screen/Weapons?

[smcameron]

That's a reasonable question, but I don't have a precise answer. According to Google, windows XP was discontinued in 2014, and Core 2 discontinued int 2012 so I suppose it is safe to assume this machine of yours is more than 10 years old, correct?

The requirements for SNIS have also changed over time... in the early days (2013, 2014), it was quite easy to run on low end hardware, and there used to be a "limited client" that didn't even need a GPU (though it was ugly, esp. for main screen and weapons), but when I converted from GTK2 to SDL2 a few years ago, the limited client didn't survive, and now it makes a lot of use of the GPU with some hefty textures for the planets. (planets typically have 6 1024x1024 textures, which, when decompressed will require something like 25M of RAM per planet, then this gets copied to the GPU, and there are typically 6 planets, so lets call it 150M just for planet textures.

Looking at snis-client in htop, on my system, I see it consuming 2.4G of virtual memory (VIRT), 700M of physical memory (RES), and 570M of shared memory(SHR). The latter is probably shared libraries.

That VIRT is 2.4G and your machine has a total of 2G physical memory might be problematic, but it might not, it's hard to say. You can use up a lot of virtual memory address space mapping the same phyiscal memory to different virtual addresses, etc. In any case, I am suspicious that 2G may not be big enough. I believe my raspberry pi 4B's have 4G.

What do you have for a GPU?

That you're seeing weird things on the screen rather than only low FPS makes me think you might be running out of GPU memory.

As an experiment, you could try replacing the planet textures in share/snis/solarsystems/default with smaller textures (e.g. just scale them down to 128x128 in the gimp or with ImageMagick or something) and see if that helps (will look ugly, but might make it run if GPU memory is the only problem because it should reduce memory foot print of planet textures to 1.5%) "make update-assets" should restore them to normal after such an experiment. I'm not too hopeful this will actually help though.

Is there anything interesting in snis_client_log.txt? A "normal" snis_client_log.txt should look something like this:

ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:869:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:869:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:869:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:869:(find_matching_chmap) Found no matching channel map
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
Portaudio reports 19 sound devices.
Portaudio says the default device is: 18
Portaudio reports 19 devices
0: HDA Intel PCH: ALC257 Analog (hw:0,0)
1: HDA Intel PCH: HDMI 0 (hw:0,3)
2: HDA Intel PCH: HDMI 1 (hw:0,7)
3: HDA Intel PCH: HDMI 2 (hw:0,8)
4: HDA Intel PCH: HDMI 3 (hw:0,9)
5: HDA Intel PCH: HDMI 4 (hw:0,10)
6: sysdefault
7: front
8: surround40
9: surround51
10: surround71
11: hdmi
12: samplerate
13: speexrate
14: pulse
15: upmix
16: vdownmix
17: dmix
18: default
Decoding audio data...Done.
Reading solarsystem specifications...done
Reading starbase model specifications...done
Re-loading per solarsystem textures
load_per_solarsystem_textures, loading
splash screen pipe read EOF.
snis_client: connect to gameserver thread
snis_client: connect_to_gameserver_thread, lobby_selected_server = 0
snis_client: connecting to 192.168.1.169/56415
voice_chat: setup threads
Initialized GLEW
OpenGL 3.0 available
sRGB framebuffer supported
sRGB texture supported
reading 'asteroid.stl'
reading 'asteroid2.stl'
reading 'asteroid3.stl'
reading 'asteroid4.stl'
reading starbase model 1 of 6 'starbase/starbase.obj'
parsing material library: mtllib starbase.mtl
ignoring unknown data '4':o Starbase
ignoring usemtl: usemtl Material.001
ignoring unknown data '2882':s 1
ignoring usemtl: usemtl Material.001_NONE
reading starbase model 2 of 6 'starbase2/starbase2.obj'
parsing material library: mtllib starbase2.mtl
ignoring unknown data '4':o Starbase2
ignoring usemtl: usemtl Material.001
ignoring unknown data '890':s 1
reading starbase model 3 of 6 'starbase3.stl'
reading starbase model 4 of 6 'starbase4.stl'
reading starbase model 5 of 6 'starbase5.stl'
reading starbase model 6 of 6 'starbase6.stl'
parsing material library: mtllib carrier01.mtl
ignoring unknown data '4':o Mesh_LP_Mesh
ignoring usemtl: usemtl Material.001
ignoring unknown data '10033':s 1
parsing material library: mtllib battlestar.mtl
ignoring unknown data '4':o Mesh_LP_Mesh.001
ignoring usemtl: usemtl None
ignoring unknown data '4847':s 1
parsing material library: mtllib disruptor.mtl
ignoring unknown data '4':o Disruptor
ignoring usemtl: usemtl Material
ignoring unknown data '1788':s 1
parsing material library: mtllib research-vessel.mtl
ignoring unknown data '4':o Research-Vessel
ignoring usemtl: usemtl Material
ignoring unknown data '7839':s 1
parsing material library: mtllib conqueror.mtl
ignoring unknown data '4':o Conqueror
ignoring usemtl: usemtl Material.001
ignoring unknown data '1335':s 1
parsing material library: mtllib snis3006.mtl
ignoring unknown data '4':o Wombat.001_Wombat.000
ignoring usemtl: usemtl Paint.001
ignoring unknown data '9359':s 1
parsing material library: mtllib dreadknight.mtl
ignoring unknown data '4':o Dreadknight
ignoring usemtl: usemtl Material.001
ignoring unknown data '1495':s 1
parsing material library: mtllib enforcer.mtl
ignoring unknown data '4':o Enforcer
ignoring usemtl: usemtl Material
ignoring unknown data '18467':s 1
triangle 828, vertices 0 and 1 are welded together 0x561239e0e614.
triangle 1134, vertices 0 and 2 are welded together 0x561239e0e614.
parsing material library: mtllib cargocontainer.mtl
ignoring unknown data '4':o Cargocontainer
ignoring usemtl: usemtl Material.001
ignoring unknown data '456':s 1
snis_client: connect to lobby pressed
lobbyname = 'localhost'
shipname = 'Revenge'
snis_client: connecting to lobby...
Trying to connect to lobby.
snis_client: connecting to lobby localhost:-1
snis_client: Connected to lobby localhost:-1
lobby connect to server button pressed
Notifying server, opcode update player
Wrote update player opcode
starting gameserver reader thread
started gameserver reader thread
starting gameserver writer thread
started gameserver writer thread
snis_client: gameserver reader thread
update_universe_timestamp i=0, update_time=1684496422.720725, timestamp=164, time_delta=0.006500 offset=1684496406.314225
SET MY SHIP ID to 837
Saving default shipname as 'Revenge'
SET SOLARSYSTEM TO 'default'
Reading solarsystem specifications...done
Re-loading per solarsystem textures
load_per_solarsystem_textures, loading
update_universe_timestamp i=1, update_time=1684496422.744999, timestamp=164, time_delta=0.030967 offset=1684496406.314032
update_universe_timestamp i=2, update_time=1684496422.769999, timestamp=164, time_delta=0.055954 offset=1684496406.314045
update_universe_timestamp i=3, update_time=1684496422.795034, timestamp=164, time_delta=0.080942 offset=1684496406.314092
update_universe_timestamp i=4, update_time=1684496422.820575, timestamp=165, time_delta=0.006423 offset=1684496406.314152
calc universe_timestamp median=1684496406.314092 sd=0.000082 n_average=4 average_offset=1684496406.314080
lobby socket = 4, done with lobby
73291 frames / 1226 seconds, 59.7806 frames/sec
server netstats: 86103137 bytes sent, 209441 bytes recd, secs = 1230, bw = 70172 bytes/sec

[Shadow8472]

This computer came out of a church secretary office, and its successor is now in need of replacement. I know it does for sure have a graphics card, though. I've been referring to it as the "Old Church Computer" (OCC).

Dell DXP016
NVIDIA GeForce 7900 GS (Rev a1)
2GB RAM
Bodhi Linux 6 (Ubuntu base) installed on an 8GB thumb drive (USB 2)

I'm just impressed I got as far as I did. It was my first time compiling without using the AUR. My tests with OCC were a feasibility check for some post-school Thinkpad E580/E590's I'm anticipating getting my hands on in the near future with the [very] reasonable expectation that they are more powerful. My immediate goal is a set of thumb drives.

For the record, I left it running all night with damage control up, and it's a little slow, but hardly unresponsive.

[smcameron]

Out of curiousity, I tried my experiement of converting all the planet textures (I used share/snis/solarsystems/zolon, not share/snis/solarsystems/default, because the latter is a bit weird for reasons I won't go into right now).

The memory usage reported by htop was:

VIRT: 1962M, RES: 460M SHR: 331M

compared to (with the original, large planet textures):

VIRT: 2400M, RES 700M, SHR: 570M

So, fairly hefty savings.

Surprisingly, it looked a lot better than I expected with the 128x128 textures.

If you want to try this, install ImageMagick, and run this script in the share/snis/solarsystems/zolon directory:

#!/bin/sh

for x in e10.png e11.png e12.png e13.png e14.png e15.png e1-normalmap0.png e1-normalmap1.png e1-normalmap2.png e1-normalmap3.png e1-normalmap4.png e1-normalmap5.png p010.png p011.png p012.png p013.png p014.png p015.png p20.png p21.png p22.png p23.png p24.png p25.png p30.png p31.png p32.png p33.png p34.png p35.png p3-normalmap0.png p3-normalmap1.png p3-normalmap2.png p3-normalmap3.png p3-normalmap4.png p3-normalmap5.png p50.png p51.png p52.png p53.png p54.png p55.png p60.png p61.png p62.png p63.png p64.png p65.png redstar.png skybox0.png skybox1.png skybox2.png skybox3.png skybox4.png skybox5.png
do
	mv $x victim.png
	convert victim.png -resize 128x128 $x
done

Then run with "zolon" as the solarsystem snis-server is serving.

[Shadow8472]

I'll try running this variation of the experiment. One of the modifications I did to Bodhi was stripping out Chromium. Long-term, I'd be all too happy if SNIS could run straight off a TTY + X or Wayland. (I talk near the boundary of my knowledge here.)

In the meantime, perhaps it would be of benefit to automatically scale or otherwise ship the scaled-down textures for low-end computers.

[smcameron]

perhaps it would be of benefit to automatically scale or otherwise ship the scaled-down textures for low-end computers.

I had the same thought, but let's see if it helps first.

[Shadow8472]

OK, fresh reboot running just Bodhi Linux, with two instances of terminology and Htop:

Mem: 221M/1.94G, CPU cores 1 and 2 go between .7% and 3.3%, Swp 0K/327M

+SNIS_launcher

Mem: 282M, cores going as high as 6% or so.

• loby, multiverse (Zolon) servers

Mem: 248M, cores between 6%-12% each.

• SNIS server

Mem:250M, cores showing 8%-13%.

• SNIS client

Immediate crash per my first-ever attempt.

Same setup, take 2 after copying snis_client_log.txt to ~:

Client took ~6 minutes (I was grabbing a joystick) to start with one core or the other maxing out at all times (Can this possibly be multi-threaded?), but it flickered between black and the desktop upon entering full screen until I alt-tabbed out. Client was terminated with launcher, but I forgot to record mem/CPU stats.

Attempt 3 -- using previous attempt's same lobby/multiverse/SNIS servers:

load time: 5:30, and showed the exact same flickering.
Mem 1.03G/1.94G, cores 10%-21% Load average: 0.26

Attempt 4 -- I rebooted, [forgot to specify Zolon]

client load: 2:43 to lobby
comparable stats to attempt 3 post-lobby
Assigned roles Main Screen to Communications, omitting sound, projector, demon, and tts.
I created a ship and found 4 game instances: Karado, Polaris, Default, and Zolon
"Prepare for the jump to lightspeed, space nerd" (I've never seen that one before.) It froze.

Attempt 5 -- Reboot. The client seems to do worse when I wait around documenting attempts after boot.

Forgot to time load
Same Lobby experience as before, but I accidentally went for Default.
Made it to in-game (Main Screen or Weapons) for a split second, but failed bridge verification.
Attempted joining Zolon again, apparent crash, but toying with the launcher showed it only re-draws the screen when updating it.
I was able to load the bridge multiple times, but I got kicked out quickly (0.2-3 seconds) each time after a red planet loaded in the distance with obvious, black lines that looked like the edges of a cube projected onto a sphere. I remember a tan one loading the first time, but it wasn't there later on. Limiting my roles didn't help.
Mem: 1.41G, Swp 268K

I stopped all processes, and Mem was left at 760M and Swp at 268K.
snis_client_logs.tar.gz

Note that this is a baseline. I have yet to lower the resolutions. I'm feeling my concentration slip bigtime.

[smcameron]

Immediate crash per my first-ever attempt.

This could mean it's running out of memory, because linux overcommits, so malloc() will return what appears to be a valid pointer, but then when you try to use it it, the kernel fails to find physical pages of RAM to back it up, and kills your program with a SIGSEGV.

I noticed this in the logs:

0:1(10): error: GLSL 1.30 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES

However, in this case, those are all related to an anti-aliasing shader which isn't used by default, so I don't think that's a problem.

One of the log files (crash4) contained this... which is a bit strange.

Out of entities at entity.c:68
Out of entities at entity.c:68
Out of entities at entity.c:68
Out of entities at entity.c:68
Out of entities at entity.c:68

You somehow got a lot of entities going.

I created a ship and found 4 game instances: Karado, Polaris, Default, and Zolon

This means you said "y" (or took the default) when it asked you "Autowrangle snis_servers (y/n, default = y)?" so it started 4 instances of snis_server, the idea being that you can travel from one solar system to another through warp gates. Better to say "n" for that since memory is constrained so it will only start 1 instance of snis_server.

It's not looking too good for getting it to run on this old machine though.

[Shadow8472]

I still have the scaled-down graphics to try. For the sake of respecting the baseline, I'll run a trial with and without autowrangling. I'm having issues finding exactly where to execute the de-res script, though. (EDIT: I found Zolon's files, will make an attempt at running it shortly.)

[Shadow8472]

Looks like the lower resolution and no wrangling may have done it. I'm very sure this machine has no business running SNIS, but I managed a screenshot using the lower textures and no wrangling.

This attempt was at the mercy of the client failing to start a few times. I wonder in the future if starting a client first and will be more consistent. 5:35 loading time average is a bit much for exhaustive testing, though.

[smcameron]

Well good that it runs at all, I suppose. 5:35 loading time does seem excessive. My guess is most of this time is decoding PNGs. 20FPS isn't great either. Pressing F11 to take it out of full screen mode, and shrink the window down to a smaller size might get the FPS a bit faster. Or run the screen at a lower resolution (maybe it's already low on such an old machine).

Or, if memory pressure is driving it to swap, that would kill performance.

[Shadow8472]

One last post as I get off for at least the weekend, here. The simulation has been idling for a couple hours now, and it's still recognizable. Htop appears to be having similar performance with load average at 0.79, 0.80, 0.86. The only glitching I'm seeing is the wash from ion drives growing to unreasonable on both NPC and my own ship. Both earlier and now, firing phasers kills the frame rate from where it already sits.

Thank you for your attention this week in exploring the low end of what it takes to run your game. The fun was in getting it to run at all.

[Shadow8472]

I'm working again on this project. At the moment, it's heading in the direction of building a custom .ISO for personal use. What all does SNIS expect to be present before it will compile and run? I just tried running it from a TTY to save on GPU RAM, but SNIS_launcher didn't even seem to notice it lacked a graphical server in which to start the client.

[smcameron]

Everything other than snis_client should run fine without video.

For the client, if you look in snis_client_log.txt, you'll probably see this:

$ cat snis_client_log.txt 
Unable to initialize SDL (Video):  No available video device
Unable to initialize SDL (Video):  No available video device

Maybe this will help: https://askubuntu.com/questions/443053/could-not-initialize-sdl-no-available-video-device-dont-move

[smcameron]

BTW, there's this project: https://github.com/hugglesfox/snis-live although it hasn't been updated in quite some time, and I've never tried it.

[Shadow8472]

Cool project, I should have remembered it. I tried it using my EndeavourOS workstation and got:
-[mkarchiso] ERROR: Profile '/path/to/snis-live/init' does not exist!

According to a comment on a totally unrelated github, nchevsky/systemrescue-zfs#7, archiso's profile system has evolved, seemingly around three years ago. https://wiki.archlinux.org/title/Archiso#Prepare_a_custom_profile looks like a good place to continue research. I'm starting to understand it, but I'm afraid it might take a little longer than a Saturday night + Sunday to coax into a working state, and I'll probably want to brave a vanilla Arch environment before I go too much farther.

[smcameron]

I've not tried Arch either, and I'd probably look for ISO solutions for a distro I was already familiar with before trying that. Ages ago, I had step by step instructions for creating SNIS ISOs for Linux Mint, using, iirc, mintconstructor, but over time those instructions suffered excessive bitrot so I removed them.

[smcameron]

Oh... wait, I forgot I have this:

https://smcameron.github.io/space-nerds-in-space/new_bootable_media_instructions.html

Maybe that's some help? Those instructions weren't written by me, but they are a replacement since mintconstructor disappeared. They might also be too old now though, since they talk about Mint 18, and I'm currently running Mint 20, and Mint 21 is current, and that file was last touched in 2018. At a minimum, the packages have changed, e.g. GTK2 stuff is no longer needed, SDL2 is needed, etc. The dependencies under "Step 2: Install Dependencies" on this page https://smcameron.github.io/space-nerds-in-space/#buildinstructions should be pretty accurate.

Oh, and I didn't delete the mintconstructor based instructions, they're here: https://smcameron.github.io/space-nerds-in-space/old_bootable_cd_instructions.html last touched in Jan of 2017 ... was still living in California then.

[Shadow8472]

Sweet! I was just considering how a live image --as opposed to an install-to-USB-- is much more in line with what I'm looking to do. Even better would be if the whole thing can run from RAM and the same USB be used to boot the entire bridge. Bonus points if using Ventoy.

[Shadow8472]

Yeah, the instructions would be useless for terminal rookies, but they're good enough for my purposes. Long story short: Linux Live Kit. I already have Bodhi Linux running SNIS, so I'm going to try mastering that. If it works, I'll look into making a smaller and cleaner .ISO and publishing my own set of instructions. The lighter, the better.

[Shadow8472]

I got Linux Live Kit going, but it took a bit of fiddling. I ran out of disk space, though. I think I want to try again with a Puppy Linux base, even though they're a little harder to work with in terms of networking.

[Shadow8472]

I... ended up overwriting Bodhi with Debian 11. I'm gunning for running SNIS on X without a window manager. Is there an easy way to start the client without going through the launcher and I just plan on using TTY2 for the server?

Note: install prequisates missed libttspico-utils on Debian 11. pkgs.org shows it as part of NonFree repositories. If my attempt is to make a set of instructions for a lightweight iso, Debian was a POOR choice for a base.

[smcameron]

You can start snis_client without snis_launcher. snis_launcher is there just because there are a lot of command line options, and it's hard to remember, type and explain them all. So snis_launcher figures them out for you easily.

However, you can see what it's doing.

$ git diff
diff --git a/snis_launcher b/snis_launcher
index 0c427754..ead906fc 100755
--- a/snis_launcher
+++ b/snis_launcher
@@ -289,8 +289,11 @@ start_snis_client()
                SPLASH_SCREEN_OPTION=""
        fi
        CLIENT="$1"
-       ${CLIENT} --lobbyhost "${LOBBYHOST}" $ASPECT_RATIO_ARG --fullscreen \
-               ${TRAP_NANS} ${SPLASH_SCREEN_OPTION} > snis_client_log.txt 2>&1 &
+       # ${CLIENT} --lobbyhost "${LOBBYHOST}" $ASPECT_RATIO_ARG --fullscreen \
+       #       ${TRAP_NANS} ${SPLASH_SCREEN_OPTION} > snis_client_log.txt 2>&1 &
+       env | sort > /tmp/env2
+       echo ${CLIENT} --lobbyhost "${LOBBYHOST}" $ASPECT_RATIO_ARG --fullscreen \
+               ${TRAP_NANS} ${SPLASH_SCREEN_OPTION} \> snis_client_log.txt 2\>\&1 \&
        sleep 1
        # --starship "$shipname" --pw "$password" $@
 }

I made the above change so that it prints out what it would have done, and also captures the shell environment.

Then, I can do:

$ env | sort > /tmp/env1
$ ./snis_launcher
[ ... launch client ... ]

And it prints out:

./bin/snis_client --lobbyhost localhost --fullscreen > snis_client_log.txt 2>&1 &

So that is the command it's running. Well, snis_client doesn't have so many mandatory options these days as it used to.

And we can see what changes were made to the environment:

$ diff -dup /tmp/env1 /tmp/env2
$ diff -dup /tmp/env1 /tmp/env2
--- /tmp/env1	2023-05-30 20:23:24.985738745 -0400
+++ /tmp/env2	2023-05-30 20:23:29.845605432 -0400
@@ -32,12 +32,13 @@ QT_ACCESSIBILITY=1
 QT_QPA_PLATFORMTHEME=qt5ct
 SESSION_MANAGER=local/falcon:@/tmp/.ICE-unix/1254,unix/falcon:/tmp/.ICE-unix/1254
 SHELL=/bin/bash
-SHLVL=0
+SHLVL=1
+SNIS_ASSET_DIR=./share/snis
+_=./snis_launcher
 SSH_AGENT_PID=1326
 SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
 TERM=xterm-256color
 USER=scameron
-_=/usr/bin/env
 VTE_VERSION=6003
 XAUTHORITY=/home/scameron/.Xauthority
 XDG_CONFIG_DIRS=/etc/xdg/xdg-cinnamon:/etc/xdg

I think the only important difference is:

SNIS_ASSET_DIR=./share/snis

If you don't want to use libttspico, it will fall back to espeak. (The quality of libttspico is miles and miles better than espeak though, especially with the British lady voice.)

[Shadow8472]

My observations are just for research at this point. Raw Debian additionally needed make and wget before I could compile and make it to the launcher. My next SNIS distro goal is an X or Wayland environment with nothing but SNIS. Eventually, I'd like to get boot straight into the client and manage servers from TTY2. If I feel like showing off, I'll number the USB's 1-8 and have it self-assign a static IP so I can go without a router based on its number.

I looked at dcore today, but it appears to be unmaintained at present.

[Shadow8472]

A bit of a doozy, but here's my new setup in exploring a low-overhead install:

Debian 12 installed with SSH and no desktop environment
Cage, a Wayland compositor for displaying exactly 1 (one) full screen graphical application (I'm banking on Cage using less of my precious GPU than X+some random kiosk window manager)
Git, make, and wget (Aptitude was installed for utility)
SNIS

In addition to libttspico being missing like before, libglew1.5-dev is also missing. Substituting for libglew-dev allowed SNIS to compile. Launcher works up until I try to launch a client, at which point it displays a mouse pointer (black with white outline) in the upper-left of the terminal and eventually crashes back to the launcher.

snis_client.log is as follows:

ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Portaudio reports 15 sound devices.
Portaudio says the default device is: 13
Portaudio reports 15 devices
0: HDA Intel: STAC9227 Analog (hw:0,0)
1: HDA Intel: STAC9227 Digital (hw:0,1)
2: HDA Intel: STAC9227 Alt Analog (hw:0,2)
3: sysdefault
4: front
5: surround21
6: surround40
7: surround41
8: surround50
9: surround51
10: surround71
11: iec958
12: spdif
13: default
14: dmix
Decoding audio data...Done.
Reading solarsystem specifications...done
Reading starbase model specifications...done
Apparently not X11, no aspect ratio constraining for you!
Failed to initialize GLEW
Re-loading per solarsystem textures
load_per_solarsystem_textures, loading
splash screen pipe read EOF.

Poking around, I know SNIS is X native, but I don't know for sure that the Debian 12 repository version of Cage was compiled with XWayland,

"Failed to initialize GLEW" has me wondering if my substitution of libglew-dev, which comes with libglew2.2, might be the issue as opposed to Cage not being compiled with XWayland.

Otherwise, I'd say this is shaping up to be a brilliant SNIS-live successor.