Setup a proper Terasology game server instance

[msteiger]

Hi,
I was wondering if it would (be fun/make sense/help with debugging/bring real user base/bring other benefits) if we had a (headless) TS server instance running somewhere.

It could be triggered by Jenkins: whenever a a new commit comes in, Jenkins compiles and builds the latest version. Maybe this could be extended to also run a new instance in headless mode and load a previously saved game.

Adding this instance to the list of available servers would allow people to quickstart the game on the internet with their friends.

 

[Esereja]

I wonder what we modules would load to that server. As whitout any you cant do much. And I wonder if we need to restrict users, so they won't destroy all in server.

 

[Cervator]

We could totally do this on our primary webhost, it is very beefy and mostly idle. What we'd need:

1. Add just a little more polish to headless to make it truly usable - this might just be better graceful shutdown when catching an escape character in the terminal running it (like a screen session - did that with the MC server we've had up occasionally). Maybe allow a way to determine selected modules / world type via command line parameter? The pending player name / color stuff would be handy too, as would an actual player avatar. Finally maybe a hook so Jenkins can inject messages into the running world when it is about to be replaced?
2. Add some console commands so a connected client can do some server admin stuff, like graceful shutdown and kicking/banning anybody just connected to troll (would probably have to be an IP ban)
3. Do a security check to see if we can spot anything risky related to running a server (don't want a connected user to be able to make the server itself misbehave) - maybe extend the Malicious module with some server tests? If that makes sense. I think restricting actual gameplay would be out of scope for a test server like this (and a fair way into the future to do properly anyway) - you still pretty much need giveBlock + giveItem
4. Harden the release process so modules will build in a natural order (currently the huge set from Marcin Sciesinski tend to fall all over themselves and break out of order) + ignore snapshots so only author-promoted versions will release and be used for the server. This is on me and probably still a fair bit of work ..
5. Maybe add some more analytics to the webhost so it'll be clear if something goes unusually wrong (I've got some limited stuff in place)

I expect we could run the standard lineup of moduleswe bundle with the game, although we can only run in one world type. Unless we run 2-3 different instances of the server in parallel. Maybe one with Wood & Stone and one with Light & Shadow (including Cities) ? Maybe a debug one with no modules other than Core, but perhaps only on-demand if something's wrong.

How would we deal with the saved world? Even if we get a graceful shutdown working I suspect we'll still be breaking things on a regular basis. Console command to reset and restart the server? Or maybe just run the Jenkins job with a reset parameter when the world gets brokeny. Or should we even attempt to maintain the world after a new build?

I have an old offer from a MC hosting provider to get a hosted instance there in return for us making Terasology server binaries available push-style to their setup (so they can offer hosting for others). That was a while ago though and probably still needs some more stability.