Replies: 11 comments 3 replies
-
What do you mean, "orphaned"? If you are hosting a game, it's perfectly sane to have server processes running and nothing else. Normal even. Can you not start up snis_client a 2nd time and kill the servers off with that? |
Beta Was this translation helpful? Give feedback.
-
|
As we discussed many moons ago, a flatpak only has access to the processes
it starts. So once the flatpak shuts down, the server processes are still
running on the host pc, and if you start flatpak again they can't see them.
For some strange reason they conflict with a second flatpak run though.
So if we forgot to shut down servers when shutting down a flatpak session,
we would need to htop op ps / kill them. Icky
…On Sat, Mar 15, 2025 at 10:02 AM smcameron ***@***.***> wrote:
Issue: The current the exit game options allow for easy exit which, when
running in flatpak, will leave orphaned server processes.
What do you mean, "orphaned"?
If you are hosting a game, it's perfectly sane to have server processes
running and nothing else. Normal even.
Can you not start up snis_client a 2nd time and kill the servers off with
that?
—
Reply to this email directly, view it on GitHub
<#392 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACMU44PUVRNHWUV6AZTDFE32UQXF7AVCNFSM6AAAAABZCPEA56VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJQHE4TGNI>
.
You are receiving this because you authored the thread.Message ID:
<smcameron/space-nerds-in-space/repo-discussions/392/comments/12509935@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Oh, right. It's running in a container. Alright. I'll come up with something. |
Beta Was this translation helpful? Give feedback.
-
|
How about this idea ... I can detect if it is running inside a container (variety of ways), and if it's inside a container, by default, when they quit snis_client, just kill everything (with a button on the options screen to enable orphans to be left if they want for some reason, .e.g. maybe it's a custom docker container.) |
Beta Was this translation helpful? Give feedback.
-
|
eef8c5d snis-client: improve quitting experience when containerized |
Beta Was this translation helpful? Give feedback.
-
|
Whatever is easiest. I do like my flow suggestions, but that is just how my brain works. |
Beta Was this translation helpful? Give feedback.
-
Possible? Yes. Easy? No. The current state of affairs is a result of the whole warp gate system not being part of the original design, but rather just bolted onto the side of the simpler original design in which there was only several snis_clients and a single snis_server. In order for snis_client to know which solarsystem the ship is in, it has to ask snis_multiverse, but it can't even find snis_multiverse without first contacting the lobby. But it could do something like contact the lobby, find multiverse, ask multiverse "dude! where's my ship!?!?", multiverse could say "it's over there!" or, "I dunno, never heard of it." So, yeah, it could be done, but is quite a bit of work. |
Beta Was this translation helpful? Give feedback.
-
|
The simplest thing to do, might be ... if you join the wrong solarsystem, you just immediately get redirected to the correct one as if you just went through a warp gate. But, it is not guaranteed that the correct snis_server instance is even running, so that is a complication. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe just have multiverse tell lobby what ships are available for each server and lobby will display available ships? |
Beta Was this translation helpful? Give feedback.
-
|
multiverse doesn't actually know which ships are where, what it knows are what hashes of shipname/password are where. |
Beta Was this translation helpful? Give feedback.
-
|
Cheat and store ship name and last server in text file too? What does 3646 and 5666 signify here? snisdb\3646\5666 |
Beta Was this translation helpful? Give feedback.
-
|
That ... is a symptom of my megalomania, ha. Those are 4 bytes of the hash of the shipname/password. I could have just stored all the files in a single directory, but (megalomania alert), what if there were millions of files? Searching a single directory with a million files in it is not cool, performancewise. But, if I take a few bytes of the hash, make subdirectories named after those few bytes, and put the files in the subdirectories, even if we have millions of files, no one directory has very many files in it. Git uses a similar scheme, take a look in .git/objects |
Beta Was this translation helpful? Give feedback.
-
|
There's another aspect to this. There is nothing in ssgl_server that makes it specific to SNIS. Someone (most likely me) could write an entirely different, unrelated game or network server application that used ssgl_server, and SNIS and this other hypothetical game/application could coexist using the very same instance of ssgl_server. It's purely hypothetical, but still possible, and I'd prefer to keep ssgl and snis separate that way -- i.e. not introduce SNIS specific stuff into ssgl_server. ssgl_server is like a really simplified cut-down minimal version of apache zookeeper which is to say, it provides very minimal "service discovery" to network applications. |
Beta Was this translation helpful? Give feedback.
-
|
e3ceb73 snis_server: if you join the wrong system, redirect to the right one |
Beta Was this translation helpful? Give feedback.
-
I am sorry for lumping these three suggestions together, but they are all logically related.
Suggestion:
Screens go forward in order from
-Process Launcher (Main Start Screen)
-Network Setup
-Lobby
-Game
Screens are only backed out in the reverse order by using esc key or back button.
On any exit game trigger, first a popup dialogue box presents option to shut down servers or leave them running with a warning, that if this is a flatpak, the servers will be orphaned and must be shutdown by other means (htop, ps/kill, etc)
On Process Launcher (Main Start Screen) maybe visually differentiate the two paths that can be taken. Server path and Client path.
Eg: Server buttons on the left and client button on the right with the lobby IP box underneath the client button. The IP should be on this screen as the client requires the lobby IP and we should not be choosing client unless we have it. Advanced settings button could be in the lower right of this screen.
The Client button (with IP) would then open the Ship selection screen (currently Network Setup).
It would be the same as it is now but without lobby IP. There would be no Process Launcher button if the initial suggestion above was used..
Ship Selection would lead to the Server Lobby page.
Server choice leads to the Ship screens.
On the Server Lobby page, is it possible to indicate what ship if any is currently on what server so the crewmembers know which server to choose?
Beta Was this translation helpful? Give feedback.
All reactions