Mote's headless server is the 1st step in creating an online service where users can request a cloud-hosted server instance of Mote, effectively bypassing the need to set one up on a user's end. One of the greater advantages of this is UPnP and port forwarding are eschewed, both of which have been a bane to MapTool users over the years.
As of the moment, there is no such service yet. But it is only a matter of time before one is made. For now, a headless server is useful for those who wish to host games over a more lightweight version of Mote, making it possible to run the application on portable, but usually, less resource-capable, machines.
There are actually 2 arguments to get this going. The first is to pass the "-headless" argument when running Mote on the command line i.e. "java -jar mote.jar -headless". The second argument is "-server", basically telling the application to fire up a server instance using the server preferences found, or default values, when no preferences are set.
Why not just combine these 2 arguments? Well, we argue that using one exclusively from the other has its own uses. For example, just using "java -headless" along with the "-campaign" argument, allows the leanest possible instance of a game session, which we on our end use to profile performance etc. The "-server" argument is a scripting convenience that can be used to "quickstart" a session in GUI mode, without having to go through pains of doing a couple of clicks within the application itself.
Ultimately, using these 3 arguments ("-headless", "-server", and "-campaign") will produce the environment sufficient to create a remotely controlled host. Note that the value passed for "-campaign" should be a relative path to the remote instance of Mote, and not one (a path) for a file found on the local device (i.e. "-campaign" does not upload to the remote location).. Alternatively, and more flexibly, a GM can run a headless server without using "-campaign", and instead, start the headless server and load the campaign or framework to use, on his/her end, instead. From that point on, the headless server will maintain the campaign state even if the GM who loaded the file drops out of the session.
As of the latest changelog, a headless server now tracks the # of connected clients once it is ready to accept connections. If the this # ever drops to 0, it will automatically terminate itself, preventing server administrators from doing this themselves.
There are 2 ways to run Mote with arguments, but only the first of these will be able to launch Mote at a remote location. The first options if through the command line via java -jar mote.jar -headless -server. Here, server settings can be overridden (thus overwritten as well) by passing parameters with the "-server" argument. Parameters should be a comma-delimited list containing key-value pairs that are separated by the "=" sign. Possible entries: are the following:
The second method is by using the internal launcher, which is either accessible during the first time you run Mote, inside the Mote GUI., at the toolbar, or by running Mote through the command line with the "-reset" parameter.
Do try this feature out, and let us know if you have any questions, either here, or through the G+ community. Thank you.
As of the moment, there is no such service yet. But it is only a matter of time before one is made. For now, a headless server is useful for those who wish to host games over a more lightweight version of Mote, making it possible to run the application on portable, but usually, less resource-capable, machines.
There are actually 2 arguments to get this going. The first is to pass the "-headless" argument when running Mote on the command line i.e. "java -jar mote.jar -headless". The second argument is "-server", basically telling the application to fire up a server instance using the server preferences found, or default values, when no preferences are set.
Why not just combine these 2 arguments? Well, we argue that using one exclusively from the other has its own uses. For example, just using "java -headless" along with the "-campaign" argument, allows the leanest possible instance of a game session, which we on our end use to profile performance etc. The "-server" argument is a scripting convenience that can be used to "quickstart" a session in GUI mode, without having to go through pains of doing a couple of clicks within the application itself.
Ultimately, using these 3 arguments ("-headless", "-server", and "-campaign") will produce the environment sufficient to create a remotely controlled host. Note that the value passed for "-campaign" should be a relative path to the remote instance of Mote, and not one (a path) for a file found on the local device (i.e. "-campaign" does not upload to the remote location).. Alternatively, and more flexibly, a GM can run a headless server without using "-campaign", and instead, start the headless server and load the campaign or framework to use, on his/her end, instead. From that point on, the headless server will maintain the campaign state even if the GM who loaded the file drops out of the session.
As of the latest changelog, a headless server now tracks the # of connected clients once it is ready to accept connections. If the this # ever drops to 0, it will automatically terminate itself, preventing server administrators from doing this themselves.
There are 2 ways to run Mote with arguments, but only the first of these will be able to launch Mote at a remote location. The first options if through the command line via java -jar mote.jar -headless -server. Here, server settings can be overridden (thus overwritten as well) by passing parameters with the "-server" argument. Parameters should be a comma-delimited list containing key-value pairs that are separated by the "=" sign. Possible entries: are the following:
- "uid" - user Id
- "role" - valid values are "gm" or "player"
- "gmpass" - the password to use if the set role is "gm"....
- "pass" - if the role is set to player, this is password to use.
- "upnp" - valid values are "sbbi", or "cling" the 2 upnp libraries used in Mote. Only useful with UPnP capable routers
- "port" - the port that listens receives connections.
- "strictownership" - game setting for token ownership, valid values are "true" or "false"
- "playerreveal" - game setting for fog revealing on player movement, . valid values are "true" or "false"
- "autoreveal" - game setting for revealing fog automatically, valid values are "true" or "false"
- "individualviews" - game setting for individual views per client, valid values are "true" or "false"
- "individualfog" - game setting for individual fog settings per client, valid values are "true" or "false"
- "restrictimpersonate" - game setting for restrict impersonation, valid values are "true" or "false"
- "campaignmacros" - game setting that controls whether players receive campaign macros or not. valid values are "true" or "false"
- "rolltooltips" - game setting that formats inline rolls with tooltips, valid values are "true" or "false"
The second method is by using the internal launcher, which is either accessible during the first time you run Mote, inside the Mote GUI., at the toolbar, or by running Mote through the command line with the "-reset" parameter.
Do try this feature out, and let us know if you have any questions, either here, or through the G+ community. Thank you.