Default worlds configuration vs portals

[xoft]

People are starting to call for this feature more and more - they want to travel between the Overworld and the Nether, and between the Overworld and the End. And they want this to work without setting up too much stuff. On the other hand, there are people who like to configure their server too exactly.

So how about this solution. We make the server to create three worlds by default, the Overworld, the Nether and the End, and bind them together with portals. Of course when there are no players in any of those worlds, that world doesn't consume (much) RAM or CPU, that's already how multiworld works with us. We then let the admins create any new world of any type, but they'll need to configure their portals manually, if they want those to work.

I propose we change the format of the [Worlds] section of settings.ini:

Code:

[Worlds]
DefaultWorld=<Overworld's name>
NetherWorld=<Nether world's name>
EndWorld=<End world's name>
AdditionalWorlds=<world1>, <world2>, <world3>, ...

This way we remove the ini-format-breaking stuff that's going on now (multiple World entries) while giving a proper meaning to three specific worlds. Of course, the admin may want to remove the Nether for a certain server, so they can use an empty name for the NetherWorld and the server won't load such a world.

To define the portal mechanics between the worlds, we can add these settings to the world.ini of each world:

Code:

[Portals]
;blocktype=worldname|coordstrategy|spawnportalstructurename

blocktype is the type of the block that acts as the portal. NetherPortalBlock or EndPortalBlock, or possibly even Water (?)
worldname is the name of the world that this portal teleports to
coordstrategy is the strategy to use for changing the coords from current world into the new world. One of:
- Multiply:x:z - multiply current coords by given constants
- Spawn - always move to spawn
- Bed - always move to last bed; spawn if no bed used there yet
spawnportalstructurename is the name of the schematic file that is spawned at the destination coords; empty for no structure

The following line declares the standard Overworld -> Nether portal:

Code:

NetherPortalBlock=NetherWorld|Multiply:0.125:0.125|NetherPortalFrame

The following line declares the standard Overworld -> End portal:

Code:

EndPortalBlock=EndWorld|Bed|EndPortalFrame

Fun portal - every time the player enters water, teleport them to WaterWorld:

Code:

Water=WaterWorld|Multiply:1:1|

Note that these declarations provide a one-way travel only, both worlds need to specify these bindings in order for the portals to be two-way. Of course, this allows for some creative things, such as the Overworld portals going to the Nether, but the Nether portals going to a third world (Purgatory?), and from there, back to Overworld.
The server would automatically configure the portals in the three built-in world, so that the portals work out of the box as expected.

Is this understandable, and is this a reasonable way to implement things? Comments, ideas?