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?

[NiLSPACE]

I think I'd rather have a [Portal] section in a world.ini

[Portal]
Nether=world_nether
End=world_end

If the name of the world is empty the portal will not transport an entity to another world. If it isn't empty and the world exists then the entity will be transported to that world. This way you could even link multiple worlds to a single world. (Not sure why someone would want it but it could be usefull)

[xoft]

Your linking doesn't provide the coord transformations (they are different in each direction) and doesn't support portal blocks other than the built in,

[NiLSPACE]

Ok then

[Portals]
NetherPortalBlock=world_nether|0.125|NetherPortalBlock

but I don't see a reason to change the settings.ini.

[LO1ZB]

I would suggest a similar solution like @STR_Warrior
settings.ini:

Code:

[worlds]
[WorldName]
default=true
nether=Dimension _Nether
end=Dimension _TheEnd
[2ndWorld]
nether=cookies
[3rdWorld]
end=banana

and allow to create custom portals via plugin.
Default value for "default" is "false".

[xoft]

Changing the settings.ini will allow us to provide defaults. We want people who try MCS out for the first time to get as good an experience of the server as possible, and that includes nether portals working. We don't want to tell them "you need to link your worlds through world.ini and use a plugin to use portals", we want it to work out of the box.

LO1ZB, that has a problem, the settings.ini already has other sections, the server wouldn't know which one to use as the world and which one not. And what does the "default=true" do? I don't really understand your proposal at all.

[NiLSPACE]

Can't we do something that if it doesn't see the world.ini it generates a default one + Nether/end world?
EDIT:
I now vote for the first suggestion xoft gave, because I thought that each MCServer would have an Nether/End without you being able to change it.

[xoft]

I have received some feedback, I'll try to react to it here:

You're mixing up worlds and dimensions. They are separate things.

Unfortunately not in MCServer's current state. We've decided to go the multi-world way, which allows us to have unlimited various worlds, but it'd be difficult to stick dimensions to each of those worlds. So instead, we emulate dimensions by worlds.

What if the admin wanted portals to be round, or limited to 2x3 square?

This proposal has no direct implication on portal shapes. It only defines what happens when the player stands in a portal block, it doesn't define how that portal block gets to be there. If a plugin places portal blocks in a sphere, then this proposal will gladly link the whole sphere as the portal.

But you need to put the linkage to both worlds.

Yes, each linkage defines only one direction of the portals. This makes portals more flexible, as it allows loops of more than 2 worlds. Unfortunately it means that there'll be more configuration. Luckily, the linkage will be generated automatically for the default worlds, that's where the settings.ini change comes into play. It makes the server aware of what defaults to apply to each of the three default worlds.

If a luser misconfigures the server, it won't work and they'll blame the server

There are two kinds of misconfiguration:
1, The luser enters a non-existent world name. The server will warn them about this upon startup, when it checks the linkages for each world. Portals won't work, if the luser doesn't see the log and complains, we can still direct them.
2, The luser enters an existing world, but bad parameters. The portals will take them to wrong places / wrong worlds. They can always remove the linkage line altogether and the server will re-generate the correct linkage (if it's the default world).
I don't see any major issues with this, we're giving them all the help we can.

But I don't want a Nether / End dimension on my server at all

If you set the NetherWorld / EndWorld to an empty value, the server will recognize that and won't generate those worlds, nor will it generate any linkage for those missing worlds. Of course, portals won't work for you then.

What if I want a plugin that makes signportals?

There's nothing wrong with that, the server won't get in your way, this is completely separate.

[xoft]

No more comments from anyone?

[tigerw]

I think the portal branch has implemented configuration for world linkage. Portal creation isn't working yet, so nothing on that.

Configurable portal structure spawning seems to contribute to incomprehensible configuration files - I remember seeing the Vanilla configuration for the first time: "What is the RCON thing? What does the IP field do? What are these structure things? What unit is the monster spawn interval in?" and etcetera. I think people will be also confused if they are presented with inexplicable values and names, for example, "0.125|NetherPortalBlock".

Maybe do it in a plugin?