MovingBlocks / Terasology

Terasology - open source voxel world
http://terasology.org
Apache License 2.0
3.69k stars 1.34k forks source link

Use the new explicit world name on the Game Details page, allow custom name? #3583

Closed Cervator closed 5 years ago

Cervator commented 5 years ago

Edit: partially completed, just the custom name textbox is left - see #3591 for what's been implemented so far

With the partially completed multi-world functionality individual worlds can now have names (defaulted to "WorldGenName-#", in addition to the overall game name (defaulted to "Game #")

2018-12-23 18_13_10-terasology _ alpha

With the game details overhaul you can see a "main" world entry on a saved game

2018-12-23 18_13_33-terasology _ alpha

It would be nice if that "main" could be changed to load the actual name out of the game manifest somehow.

Bonus: It would be even better if the user could give a given world a custom name, maybe with a bit of flavor (creative planet or dimension names instead of "Perlin-1"). I think this would go well as a new text box at the top of the individual world config page:

2018-12-23 18_13_21-terasology _ alpha

See the GameManifest class and its usages for some clues on how to achieve all this, look at the involved UI screens, and if needed consult the NUI tutorial: https://github.com/Terasology/TutorialNui/wiki

Snooober commented 5 years ago

Hi, I'm a beginner so let me know if I'm mis-understanding something with my question:

The StoragePathProvider class currently depends on TerasologyConstants.MAIN_WORLD for file paths. This depends on the main world being saved in folder "main". Is this something that would be changed in the future? Will each world get saved in a folder with it's own custom name as the folder name?

I believe this would affect the approach to take for the open issue.

Snooober commented 5 years ago

I made a new String member variable in WorldInfo() called "customTitle" which holds the world name rather than TerosologyConstants.MAIN_WORLD ("main"). I preserved the "Title" variable in WorldInfo() as the StoragePathProvider() class is dependent on it.

I added an ItemRenderer() to the "gameWorlds" UIList in the GameDetailsScreen() which draws the "customTitle" text to each widget in the "gameWorlds" UIList.

I have tested it and it now shows the world name correctly instead of "main". Is this a good approach? Should I make a pull request?

Cervator commented 5 years ago

Hi @Snooober and welcome! :-)

Yes I believe when multi-world matures further there'll be a world directory for each. So your approach sounds solid. Please proceed with a PR! No need to ask either PRs are always welcome 👍 They're also great for discussing if any further tweaks to an approach seem warranted

Cervator commented 5 years ago

Re-opening as this is only partially complete: we can still hook up a customization field to change the world names during world setup. Building on top of merged PR #3591 this should now be pretty easy :-)

Cervator commented 5 years ago

Addendum: if you "quick start" a game then there is no world name yet (as there is no selected world - I'm guessing that picks some defaults later). I fixed a null pointer exception real quick (see #3591) but that results in a world entry with a blank name.

Probably we can figure out a way to improve that a bit further, such as setting the world name in an additional place where it is deduced via defaults :-)

Cervator commented 5 years ago

Maybe relevant as well: #3586

shaunakdixit commented 5 years ago

hy @Cervator I would like to work on this issue. So what I understood from above conversation is 2 tasks are still remaining 1- We need a customization field to change world name during a world setup 2- and to solve a issue during "quick start" in which world name is not getting printed on screen.

please let me know if I'm wrong and can you tell me what are the changes made by @Snooober like a screenshot or something :-)

Cervator commented 5 years ago

Belated heya @shaunakdixit - yeah that sounds about right, and you don't necessarily need to confirm before starting, especially on a relatively recent issue. For related work just check out the links, such as PR #3591's diff showing what was changed for that set and the PR itself describing what was changed.

If you have short term pressing questions it is better to come ask on Discord as GitHub notifications can be easy to miss when you get a ton of them :-)