This behavior is more useful than "local" mode because the user does not have to know to reconfigure the client and restart the world in order to host a game. At the same time, it does not needlessly open a network port until it is requested, so if you are just testing something from the compiler, you will not have an open invitation in your pager location for people to connect to your game. Of course, if you _want_ that, you can change the default port from "auto" to 0 for a random port assignment. Basically, "auto" strikes a balance between ease of use and reasonable security.
In "local" mode, world.OpenPort() still works, but it prompts the user for permission before continuing. If you really don't want people connecting to a particular world while you are running it, use "local". Otherwise, it is better to use "auto" or 0.
The port setting 0 allows the server to pick any available port. The value "any" is now synonymous with that. I have also added "none" as a synonym of "local", since that is a clearer description of its purpose. We will stop advertising "local" and just phase it out eventually.
In summary, these are the possible values for the client's default network port setting:
| none or local | (never open a network port without asking the user) |
| auto | (only open a port if requested by the world code) |
| any or 0 | (automatically open an available port) |
| 1234 or any other number | (open this particular port if it is available) |
I should clarify that although the request to open a port is made by world.OpenPort() in the code, this will normally be called at the request of the user. For example, in a standard hubified game, the first user to connect is given an option to open a live link from the hub so more players can join. When they click that, world.OpenPort() is called along with a number of other calls to the hub.