Changable World Names

[SiriusAshling]

It could be convenient to allow changing world names after generating the seed.

This would affect the messages such as "Ori's Keystone" and "Gorlek Ore from Sein", where "Ori" and "Sein" would currently be the world names assigned at seed generation time.

These messages could instead contain a specialized syntax that gets filled with world names fetched from the server. This way they could stay up to date when changing world names in the multiworld interface.

[SiriusAshling]

It might still be desirable to provide the default value for world names through the seed, e.g. when using the cli to generate a multiworld seed.

A potential concept could be to use the initially provided world names as identifiers for the worlds, using syntax such as $WORLD(Ori)'s Keystone / Gorlek Ore from $WORLD(Sein).
This would then also provide the default values.

Other places where world names are used are the generator.log and the comments in seeds used as spoiler data.
Both are intended to be read as text files and don't necessarily have any randomizer-related application running, so these would keep using the default values directly as world names.

[timoschwarzer]

It might still be desirable to provide the default value for world names through the seed, e.g. when using the cli to generate a multiworld seed.

I'd get rid of world names altogether in the seed generation process and just specify the world count, so you get Seed 1 - n every time. The world IDs are not predictable and can change as well, so the server has to keep a mapping between seed ID and world ID anyways.

It would be very confusing if you could specify yet another set of world names that are not used anywhere. Especially if two people swap worlds and change the world names respectively, the log and actual world names are mixed up.

Thus I'd write seed IDs (1 - n) to the spoiler comments and have a small tooltip in the UI to show the seed ID for a world. The in-game spoiler map can show actual world names.

[SiriusAshling]

Also possible.
Personally as a user I'd prefer the more readable logs/spoilers even if they have the caveat to desync if you change names, I feel like losing that readability in exchange for the ability to change world names would be a net loss.

[SiriusAshling]

I'll ask some other players

[SiriusAshling]

Numeric identifiers seem to be generally accepted.
This would also allow to automatically name the worlds as players enter them, making the creation of multiworlds more convenient.

$WORLD(1) syntax would parallel existing interpolation syntax from header language. (from memory it's case insensitive in the header language, just idiomatic to capitalize)
Seeds on the breaking changes branch already contain a line // This World: <number> (to identify the world's settings from the configuration json), this could be used to identify seeds reliably

[timoschwarzer]

Sounds good. Ping me with the new seedgen CLI arg that takes the world count once it exists (currently there isn't one, is it?) so I can update the server.

[SiriusAshling]

Another hurdle I came across: What about split-settings multiworld?

On same-setting multiworld there isn't a strict assignment between seeds and players at generation time, so having players enter the unnamed worlds at will and auto-naming them then could make sense.

But with split settings the individual seeds are strictly intended for specific players. Wouldn't naming the worlds upfront be more intuitive here? When deciding on the settings for a specific world the ui could display who these settings are for, and when auto-creating the worlds on the server they can be named after the players their seeds are for.

[timoschwarzer]

Good point. Either give the option to name the seed configs, or show seed settings, that are not common between all seeds (e.g. if not all seeds use the same difficulty, show the difficulty for each world's seed)

[timoschwarzer]

This is implemented on the client and seedgen side, moving to server