Ensuring enb is around for the long term

[Xiaolinmantis]

Is there any chance you guys would ever consider doing a self-hosted (Docker) version of the enb server? That way, in the event that it ever becomes financially unfeasible to continue operating your own, then at least enb could live on in some capacity.

[griever]

Does the modern emulator server run on Linux? I remember a super old version was Windows, and Windows is pretty chunky on Docker.

 

If it's feasible, and the team is interested (eg. I understand if they don't want to disclose the binaries) and wants any volunteer help, then let me know. I'm on vacation pretty soon here but some time in August or later I could put in some work if needed.

[Kyp [LDEV]]

In order:
 

• Has it been considered? Yes
• Does the modern emulator run on Linux? No, there is a mix of Windows, Linux, and FreeBSD operating systems.
• Will Docker be something we look at in short order?  Probably not, but mainly because there's plenty of stuff to fix before we create a standalone container that everyone could use reliably. As it is, you sorta have to know what interacts with what to prevent breakages.

[Joe[IS]]

On 7/21/2024 at 9:52 AM, Kyp said:

In order:
 

• Has it been considered? Yes
• Does the modern emulator run on Linux? No, there is a mix of Windows, Linux, and FreeBSD operating systems.
• Will Docker be something we look at in short order?  Probably not, but mainly because there's plenty of stuff to fix before we create a standalone container that everyone could use reliably. As it is, you sorta have to know what interacts with what to prevent breakages.

 

Is this something you guys need help with or is it infeasible that someone who hasn't worked on the server could help here?

[Kyp [LDEV]]

33 minutes ago, Joe said:

 

Is this something you guys need help with or is it infeasible that someone who hasn't worked on the server could help here?

Are you referring to the game server being run on Linux? If so, containerization is probably something I would put off until we can hammer out some bugs the rest of the way that have long persisted because ultimately if we were going to release a containerized version for others to use, it would need to be set up in a default state that lets someone run it with their credentials and not referencing anything from the actual game servers today.

Right now, that would be comprised of a fair amount of database cleanup and normalization first, then a port of the database with some default credentials. Then, everything else that is required, and ultimately, would probably want to look at a fork in using pure TCP communication, given that UDP is so problematic. Someone who was working with us started down that road a long time ago, but we were still testing when he left to move on to another project.

[Joe[IS]]

Yeah, I was wondering about the containerization or generally having a server I could run locally and screw around with. I have that old server source from a long time ago archived, but I assume it's ridiculously out of date and probably doesn't contain much, if any, of the actual database info needed to set up a working game server.

 

Is the dev team interested in having a new developer take a look at the current code and architecture to try working on those issues?

[griever]

Ah ya that makes sense that a large portion of the work would be just cleaning up the database in a way that it could be distributed.

 

So then I if I am hearing it right, there are a few portions of work that would need to be done?

- make db portable / distributable

- deal with windows-specific code as Windows on containers = sucks

- (maybe tangentially related) some netcode cleanup (UDP -> TCP as Kyp mentioned?) although it wasn't clear to me if that would be a blocker or more of a nice to have

- the actual work of building a runnable set of containers that easily work together (eg. like setting up individual containers, linking them together with something like a Docker Compose file, so people could just run it with 1 command)

- not sure if there's any licensing concerns, you guys might want to revisit what type of license to distribute it under if the server was accessible to the public (eg. AGPL? force people to contribute the code for any modifications maybe?)

 

For the "deal with windows-specific code as Windows on containers" specifically, one thing you guys could consider is testing out how much work it would be to get the windows part running on linux via wine, in a container. I've seen some successes with that with a quite minimal dockerfile and 0 edits to the windows application.

 

For context, I just led a ~1 year migration at my dayjob of a 1.1 million LOC monlith server that was heavily windows based and we actually got it natively running on Linux, but it was a huge amount of work. For EnB, something like that might not be worth large changes in the server where that effort could be better spent elsewhere. But it would be worth a short proof of concept to try to put the windows part in wine and slap that into a container. It doesn't have to run the live servers on that, it is more of just a stopgap to get a convenient way for others to run the server more easily and help preserve EnB for all to enjoy.

 

Of course there's still the other items (and likely other ones I am not even aware of) to do so I am assuming this is all a large project.

[Doctor]

Just chiming in to say that a TCP/UDP mix is probably best. TCP for chat, loot messages, XP gain events, buff gains are all good. UDP is a better fit for things like damage numbers, shield/hull HP updates, reactor updates, toggling weapons, etc.

 

Why? TCP knows what order things are supposed to happen in. You do NOT want a player spamming their fire button to be held up while TCP waits for a reactor update that's going to take 20 seconds to run its way around the world due to some fluke of core network routing. TCP creates two problems in 'realtime' systems:

 

1. You get old data in 'new time'. Meaning you can get an old update that is no longer relevant. (caused by #2)

2. You are blocked on processing new data until that old data arrives.

 

All modern MMOs use this mixed approach and have for decades for these exact reasons. Also, IIRC, Westwood and Blizzard both tried TCP-only and both realized you HAD to use UDP for realtime updates and build a state machine that could handle it.

[VonBon]

I'm glad to see the game is still going. i haven't played in years , hard to believe its been over 20 years... 

[Spa[IS]]

I'm still here Mate

[Overtkill]

Count is 27. Man, that's low for "prime" hours.

[Codemonkeyx]

Summer time and WoW just launched a new content patch, not terribly surprising.

[Kyp [LDEV]]

On 7/24/2025 at 10:52 AM, griever said:

Ah ya that makes sense that a large portion of the work would be just cleaning up the database in a way that it could be distributed.

 

So then I if I am hearing it right, there are a few portions of work that would need to be done?

- make db portable / distributable

- deal with windows-specific code as Windows on containers = sucks

- (maybe tangentially related) some netcode cleanup (UDP -> TCP as Kyp mentioned?) although it wasn't clear to me if that would be a blocker or more of a nice to have

- the actual work of building a runnable set of containers that easily work together (eg. like setting up individual containers, linking them together with something like a Docker Compose file, so people could just run it with 1 command)

- not sure if there's any licensing concerns, you guys might want to revisit what type of license to distribute it under if the server was accessible to the public (eg. AGPL? force people to contribute the code for any modifications maybe?)

 

For the "deal with windows-specific code as Windows on containers" specifically, one thing you guys could consider is testing out how much work it would be to get the windows part running on linux via wine, in a container. I've seen some successes with that with a quite minimal dockerfile and 0 edits to the windows application.

 

For context, I just led a ~1 year migration at my dayjob of a 1.1 million LOC monlith server that was heavily windows based and we actually got it natively running on Linux, but it was a huge amount of work. For EnB, something like that might not be worth large changes in the server where that effort could be better spent elsewhere. But it would be worth a short proof of concept to try to put the windows part in wine and slap that into a container. It doesn't have to run the live servers on that, it is more of just a stopgap to get a convenient way for others to run the server more easily and help preserve EnB for all to enjoy.

 

Of course there's still the other items (and likely other ones I am not even aware of) to do so I am assuming this is all a large project.

In order:
Yes, portable, so you'd have one admin credential and then could fire up and configure your own little instance, connect your client, and so on. Challenges here are normalizing the database and releasing all non-net7-specific content only in line with the official game and documentation, as well as a set of containers that you can run together. Our code is licensed pretty openly once you're in it; we just keep the actual repos private to the team to prevent headaches.

This all said, the 'game server' everyone plays on is currently Windows code; we had a developer, I think, as I said, who was trying to look at a transition to Linux and pick up on the TCP. The UDP works great for a lot of things that you don't necessarily need the responses on, but things like your hull and shield indicators seemingly get outta sync once in a while, and that sorta thing is a result of lost UDP packets.

[Joe[IS]]

On 8/8/2025 at 9:44 PM, Kyp said:

In order:
Yes, portable, so you'd have one admin credential and then could fire up and configure your own little instance, connect your client, and so on. Challenges here are normalizing the database and releasing all non-net7-specific content only in line with the official game and documentation, as well as a set of containers that you can run together. Our code is licensed pretty openly once you're in it; we just keep the actual repos private to the team to prevent headaches.

This all said, the 'game server' everyone plays on is currently Windows code; we had a developer, I think, as I said, who was trying to look at a transition to Linux and pick up on the TCP. The UDP works great for a lot of things that you don't necessarily need the responses on, but things like your hull and shield indicators seemingly get outta sync once in a while, and that sorta thing is a result of lost UDP packets.

 

Has this gotten any traction? I started working on a project based on that old server source to inject a DLL into the game client to read and categorize packets to and from the server a while back, but I eventually got sidetracked on it. The goal was to try reimplementing the game client in a cross-platform engine like Godot and use the existing game assets, but at some point I realized I would also need to reimplement the proxy's packet handling and game memory injects as well. The old proxy source has far fewer game memory injects than the current version so I put it on the back burner for a later push.

[Kyp [LDEV]]

On 5/7/2026 at 12:14 PM, Joe said:

 

Has this gotten any traction? I started working on a project based on that old server source to inject a DLL into the game client to read and categorize packets to and from the server a while back, but I eventually got sidetracked on it. The goal was to try reimplementing the game client in a cross-platform engine like Godot and use the existing game assets, but at some point I realized I would also need to reimplement the proxy's packet handling and game memory injects as well. The old proxy source has far fewer game memory injects than the current version so I put it on the back burner for a later push.

Recently, it's mostly just me keeping things safe, running, and the GMs managing the game. Want to get some more down these paths, but right now there's not enough time in the day (for me, at least). We have been doing some toying around with some potential new tools and using AI to help identify some places that could improve some of these long-standing issues. No containerization or anything just yet, though. I have an ambition to eventually release that so that others can try to run their own instances but there would be some prep work to set up what I was describing.

[Joe[IS]]

20 hours ago, Kyp said:

Recently, it's mostly just me keeping things safe, running, and the GMs managing the game. Want to get some more down these paths, but right now there's not enough time in the day (for me, at least). We have been doing some toying around with some potential new tools and using AI to help identify some places that could improve some of these long-standing issues. No containerization or anything just yet, though. I have an ambition to eventually release that so that others can try to run their own instances but there would be some prep work to set up what I was describing.

 

Is that something you want help with?