Linux Dedicated Server Binaries

agree and push.

Linux is the way to go for multiplayer (server-) perfomance!

I mean with some work they could use VKD3D. The actual game runs quite well on Linux

Hopefully a dedicated headless server build doesn't need any binding to DirectX whatsoever. It's unlikely to actually be needed for anything on the server, but it could be that it's not separated enough that it can just be removed from a build.

It's not at all simple to do so. The simplest and best solution would be to just depend on VKD3D. This way they can continue to incorporate the server into the client. Leaving out the need for a separate binary entirely.

i wanted to reply to the thread not this

@DaemosDaen: the server should not use dx12 at all, its a server not a client with gui?

@kill2die A simple and good permanent solution is to incorporate the server and client on the same executable. The downside side is that it has to depend either on OpenGL, Vulkan and/or DirectX as a result of the server and client using the same executable. Regardless if it uses those graphics APIs at all. Which this is fine because you can still use them on your Linux Headless Server. You just need to install the graphic driver, which all servers are required to have an iGPU or dedicated GPU for maintenance and initial setup.

@Karutoh:

I don't think it's a GOOD solution to incorporate both, it would be rather a quick and dirty solution.

The dedicated does not need at all the stuff from the client, like rendering etc.

I don't want fancy graphics stuff on my linux machine, If it's not really needed why should it be included? this does not makes that much sense.

SE 1 had windows dedicated which worked fine, lets just go for linux compatibility for SE2, that would be awesome to have and would boost server perfomance alot!

@kill2die It's not a quick and dirty solution. By doing it this way there's no need to design the server and client separately. Which is huge. When you launch the server with that same executable, it will not be using a Rendering API such as Direct X. It will depend on it still.

the most elegant solution is to create a development pipeline that builds the binaries for respective platforms with the shared logic and only needed components. Incorporating into a monolithic structure is bad design and will lead to all sorts of fun stuff down the road.

@Gerben D. What kinds of fun things? Please elaborate.

increased storage on headless machines

containers ballooning to huge sizes to accomodate all assets

updates resetting headless mode (when head is attached)

generally more complexity by using switches to turn off behaviour instead of compiling purely whats necessary to achieve the intended application, especially for such a big application as SE. Because if all the work is put into switching between two running modes, why not split already. If on every render it needs to be checked whether headless=false, its just unnecessary (ofc doing that is silly but it serves the argument)

@grave The only assets you should be loading are the ones you use for collision data. Having a single boolean or enumeration check every frame is the least of our worries.

@Karutoh: I think we mean the same ,just express it different.

Of course I mean we need a executable that makes it possible to run the server headless without rendering etc..

If it's the same file or not doesn't really matter in my opinion, that depends heavily on the build pipeline of the devs.

If it's possible with one, cool, if not, nothing speaks against another executable just for the server.

There is also a big benefit of having it seperated : server size!

Many steam games have a seperate branch for the dedicated server to make it as small as possbile and include just the needed.

They should have directly go the Vulkan way instead of DX12. It is not that difficult to change it and way less problems to support Linux and consoles.

emulating stuff (especially with wine) is not a real solution, rather a workaround.

Could imagine some API would be nice to have and that could be used to build also easily some webinterface, sounds good!

Unfortunately, I very much doubt it's going to be an easy feat by any stretch.

If any of their dependencies required server-side only support .NET Framework, they're still tied to Windows only, unless they can replace it with something that has broader compatibility which could mean significant changes to the game. And if they don't depend on many third-parties, they might still have to rewrite significant portions of the codebase to be OS agnostic as well.

We're asking for quite a lot of dev time here away from other game features that everybody wants, so I'd be very pleasantly surprised if they actually pull this off 🙏

Even if they couldn't do a proper Linux DS binary, I would take a docker container. Or heck, even just tweak the code a little bit to make it easier for others to make such a container. The last attempt works well, save a problem with connecting via vrage remote. Apparently the issue is with WINE not supporting some particular magic windows behaviour WRT HTTP. If an alternative method was used, there would be several containers to choose from.

After trying to get the server running under Linux, it seems the server includes some graphical components, which causes it to fail when run via WINE. On Windows, there's also an administrative GUI that starts alongside the server. According to modern standards, a server application really shouldn't include any graphical interfaces.

That's why I mentioned in my previous comment that the admin GUI could easily be replaced by a web-based application. Of course, implementing the required interface for this within the server is some work—but it would enable the server to be a simple ("dumb") console application.

If the existing SP1 server is written in .NET Framework, migrating to modern .NET would be highly advisable. Although .NET Framework might continue to be included in Windows for a while, SP2 development might reach a point where future Windows versions no longer support the old Framework. Microsoft's long-term strategy is clearly moving toward the new .NET, which is also highly compatible with Linux. This transition is especially relevant since support for .NET Framework officially ended in 2022.

If Keen Software has utilized some exotic libraries for data processing or network communication (beyond just graphical interfaces), those would obviously require replacement, and admittedly, that could be a significant amount of work. However, standard native Framework code typically ports quite smoothly to modern .NET.

Since SP2 currently lacks multiplayer functionality, now is exactly the right time to approach this properly. It means you wouldn't need to alter the existing game logic, given there's no existing multiplayer code yet. Especially for a server that needs every bit of performance it can squeeze out, it shouldn't become some Frankenstein's monster that somehow barely manages to run inside a Docker container.