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!