World Travel in the editor
Last updated
Was this helpful?
Last updated
Was this helpful?
World travel is now available to test in the editor. It uses a Morpheus plugin called MorpheusMultiServer, which allows you to specify and start multiple servers locally; most of the setup is to get these extra servers working, and then you can travel between them using portals or gates in your game world in the same way you would in a cloud deployment.
A lot of the below stuff is going to look scary, but it’s not that bad once you get used to it.
We do plan to remove some of the extra setup requirements in the longer-term (e.g. the Launch Settings section) but unfortunately due to time restrictions on development, at the moment there are a few extra steps.
Firstly, a nice simple one: go to your Editor Preferences, search for “World Travel” and enable Use Editor Mode for World Travel.
It depends, but in general no - it’s fine to keep this option enabled all the time. If you’re testing elements of the web service flow for world travel (eg. sending an Http request for available worlds) then you’ll want to make sure it’s disabled for that, as this option overrides that request. Incidentally, that’s why this option defaults to false - to preserve existing workflows for other people.
To start out, go to Editor Preferences and select Morpheus Multi Server Settings. You should see the following screen:
This is where you’ll configure your extra servers. You’ll need one server for each extra map - for example, if you’ve got maps A and B and you’re starting PIE from map A, just set up a server for map B.
So, for each extra server you want, add an element to Extra Server Processes to Create.
There’s a bunch of numbers and options there. What do they mean? Let’s cover the simple ones first:
For Deployment Map, choose the level that server should be running.
For Deployment Name, what you put doesn’t really matter as long as it’s unique - but we recommend something human-readable.
If you need to pass command line arguments to a specific server, type them in the Additional Command Line Arguments box! In the majority of situations you can leave this blank.
Next up, there’s a bunch of port options. What’s up with those?
A very non-technical explanation of a port is that you can think of it as being like a USB slot on your laptop or PC, except it holds a program instead of your mouse or keyboard or headset. If a port already has a program using it then other programs can’t use that port as well.
So, how do you fill out the port numbers in a way that doesn’t conflict with other programs? Here’s a good strategy:
For Server Port, use 7778 for the first extra server and add one for each extra new server;
For Deployment Redis Port, use 6380 for the first extra server and add one for each extra new server;
For Deployment Proxy Port, use 9001 for the first extra server and add one for each extra new server.
Why does this work?
If you’re curious - the default server port for our PIE sessions is 7777. Similarly, for the redis port it’s 6379 and for the proxy port it’s 9000. Adding one for each new server will generally ensure you get an unused value.
In rare situations, the above strategy might not work. If it fails, you should get an error somewhere that reads Skipping creation of <deployment name> because the <name> port specified for it is occupied.
Here are some rules of thumb for situations where you have to guess at port numbers:
Rules of thumb for choosing port numbers if the above doesn't work
Choose Unique Numbers: In short, don’t reuse the same port twice on this settings page.
Choose High 4-digit Numbers: Generally, if you choose a high 4-digit number, you should be fine.
Yay! You should see at least one extra window open up - these are the standalone servers running each extra map.
You should be able to world travel between them as you would normally - see World Travel.
WorldTravel.TravelToDeployment [DeploymentName] - Travels to input deployment. Uses partial matching.
WorldTravel.TravelToMap [MapName] - Travels to input map. Uses partial matching.
WorldTravel.List - Prints list of available worlds to travel to.
There are two extra options in the Multi Server settings which are extremely useful and worth understanding:
Should Create Extra Servers on PIE Start: defaults to true. When set to false, the extra servers you’ve specified will not be created. This is extremely useful if you want to go back to normal non-world travel testing but want to retain your extra server setup for later.
Should Destroy Extra Servers on PIE Finish: defaults to true. When set to false, the extra servers created when you hit Play will not be destroyed when you hit Stop. This is useful if you want to retain state on a server between tests, or to speed up schema generation (see Known Issues).
Two important notes on the above
If you have extra servers still running from a previous PIE session, they won’t be recreated regardless of your choices. You’ll have to close them manually if you decide later on you don’t want them.
The server on which you start your PIE session will always shut down when you hit Stop, regardless of your editor preferences. There's no workaround for this currently, but can be investigated if it becomes a necessity.
If you’ve definitely followed the above guide to the letter, the most common cause of this is that your port numbers are already taken. Check your logs (both server and client) for the following message:
Skipping creation of <deployment name> because the <name> port specified for it is occupied
where the angle brackets are replaced by a specific deployment name/port type. If you find this message, the solution is to change the relevant port number until you find one that works - it shouldn’t take long.
