A headless facade that acts as a game host and provides web-based administration. Automation category: Terasology Facade. See https://forum.terasology.org/threads/facadeserver-headless-server-with-web-interface.1906
The code on this branch adds support for management of the savegames stored on the server from the web client/API, as described in the 16 July (week 7) devlog update.
Before merging
I'm marking this as WIP since there are a couple of parts that I think need to be improved before this branch is merged:
The getLoggingPhase() method of the StateLoading and StateInGame engine states is used to determine the name of the game which is running or loading, which, as pointed out in the comments in the code, works but in my opinion is not a very good idea, because for example the getLoggingPhase() might be changed in the future to provide additional information. So I'm considering opening a pull request in MovingBlocks/Terasology which adds a more suitable method to get this information (e.g. getGameTitle() or something like that). Fixed in 1a087c4 by using currentState.getContext().get(Game.class).getName();
As pointed out in the blog update AvailableModulesResource is an hack to circumvent the fact that CORS is not enabled on the Meta Server,thus the list of available modules can't be obtained directly from a web browser, so the game server is being used as a proxy. As described in the blog post we could either enable CORS on the meta server or improve AvailableModulesResource to provide different or additional information, for example only listing the modules installed on the game server.AvailableModulesResource now provides information about installed modules and world generators.
When creating new games, any module can be specified from the web frontend, but if a module is not installed on the game server the dependency resolution fails. This is also the reason I still haven't implemented the feature to modify an existing savegame's module list (actually existing savegames can be deleted, backed up or renamed). Two possible solutions could be:
Download the missing modules on-the-fly when the game is created.
Picked this solution in commit 2e15c95:
Show only the installed modules on the game creation screen, and add a separate resource class (and a new tab in the frontend application) to install new modules in the server.
Also, as pointed out at the end of the blog post, the engine can be started in this new state (StateEngineIdle) suggested by @msteiger by specifying the -dontStartDefault command line switch, but at the moment there is no way to actually avoid the creation of a default game because you can't login to the web interface without a valid client identity certificate, which is generated when connecting to a running game. The planned solution to this problem is to set up a sort of admin password that can be used to login to the web interface to only administer savegames without a client identity (but obviousluy as always any idea is welcome); let me know if I should add it on this branch or wait for this pull request to be reviewed and add it later.
How to test
It's possible to access the new resources through the "Games and Modules" tab in the web client, you can either use the version hosted on GitHub Pages here or clone the repository locally and following the build instructions in the README (basically, you need to have npm installed, install the dependencies including the development ones and run npm run web). I'm aware that there is still some small usability problem in the frontend application but it shouldn't be a problem when using it for testing the server. For example, if you connect to an not existing server, no warning is shown and various buttons become unresponsive (as pointed out by @skaldarnar last week). This week I mainly focused on the server and I'm going to fix this soon, in the meanwhile please press the "Connect" button on the "Server Address" dialog only when the local server is running and has completed initialization. Fixed.
msteiger
commented
7 years ago
Contents
The code on this branch adds support for management of the savegames stored on the server from the web client/API, as described in the 16 July (week 7) devlog update.
Before merging
I'm marking this as WIP since there are a couple of parts that I think need to be improved before this branch is merged:
TheFixed in 1a087c4 by usinggetLoggingPhase()method of theStateLoadingandStateInGameengine states is used to determine the name of the game which is running or loading, which, as pointed out in the comments in the code, works but in my opinion is not a very good idea, because for example thegetLoggingPhase()might be changed in the future to provide additional information. So I'm considering opening a pull request in MovingBlocks/Terasology which adds a more suitable method to get this information (e.g.getGameTitle()or something like that).currentState.getContext().get(Game.class).getName();As pointed out in the blog updateAvailableModulesResourceis an hack to circumvent the fact that CORS is not enabled on the Meta Server,thus the list of available modules can't be obtained directly from a web browser, so the game server is being used as a proxy. As described in the blog post we could either enable CORS on the meta server or improveAvailableModulesResourceto provide different or additional information, for example only listing the modules installed on the game server.AvailableModulesResourcenow provides information about installed modules and world generators.When creating new games, any module can be specified from the web frontend, but if a module is not installed on the game server the dependency resolution fails. This is also the reason I still haven't implemented the feature to modify an existing savegame's module list (actually existing savegames can be deleted, backed up or renamed). Two possible solutions could be:Download the missing modules on-the-fly when the game is created.Picked this solution in commit 2e15c95:Also, as pointed out at the end of the blog post, the engine can be started in this new state (
StateEngineIdle) suggested by @msteiger by specifying the-dontStartDefaultcommand line switch, but at the moment there is no way to actually avoid the creation of a default game because you can't login to the web interface without a valid client identity certificate, which is generated when connecting to a running game. The planned solution to this problem is to set up a sort of admin password that can be used to login to the web interface to only administer savegames without a client identity (but obviousluy as always any idea is welcome); let me know if I should add it on this branch or wait for this pull request to be reviewed and add it later.How to test
It's possible to access the new resources through the "Games and Modules" tab in the web client, you can either use the version hosted on GitHub Pages here or clone the repository locally and following the build instructions in the README (basically, you need to have
npminstalled, install the dependencies including the development ones and runnpm run web). I'm aware that there is still some small usability problem in the frontend application but it shouldn't be a problem when using it for testing the server.For example, if you connect to an not existing server, no warning is shown and various buttons become unresponsive (as pointed out by @skaldarnar last week). This week I mainly focused on the server and I'm going to fix this soon, in the meanwhile please press the "Connect" button on the "Server Address" dialog only when the local server is running and has completed initialization.Fixed.