Allow world library to be supplied to interface

[sshipway]

It should be possible to provide a library of saved worlds in a directory, that can be mounted with -v to the container. Then, the web interface should give a selection between

• Give a URL for a world to download
• Upload a world save zip
• Select a world from the directory (dropdown list -- hide if no saves in dir)
• Enter a world seed

[itzg]

Capturing some points from Gitter:

• Use flow-nbt to ingest the level.data file
• Extract the seed
• Can also identify if it is a 1.8 world by searching for BorderSize
• LevelName can hold a default description
• If the world requires forge mods, then you should be able to find them in the (Undocumented) FML/ModList array as a package of ModId and ModVersion (strings)

[sshipway]

Example level.dat files now under src/test/resources/level.dat/

[sshipway]

Should be able to upload/maintain world library in the same way that modules can be uploaded.

[itzg]

Regarding

If the world requires forge mods, then you should be able to find them in the (Undocumented) FML/ModList array as a package of ModId and ModVersion (strings)

the sample file 1.7.10-with-forge-mods.nbt doesn't have any "fml" or "forge" tags. We may need to save the Forge heuristic for later, after more investigation.

[sshipway]

The sample file does have these. but the case is significant so look for Forge and FML.

At the top level, you have the Data tag with all the level data. At the same level, you find the FML and Forge tags.

Under FML is the ModList array. These entries are ModId and ModVersion strings.

So, /FML/ModList[]/ModId are the required module names.

Open the file in NBTExplorer and you'll see the items (I've just checked to make sure I didn't accidentally upload the wrong file, and they are there)

[sshipway]

Note that the modules 'FML', 'Forge' and 'mcp' are always included as part of Forge so don't count these.

[sshipway]

[itzg]

Oh...it's at the same level as Data. Thanks for digging in and providing details.

[sshipway]

I guess they wanted to minimise the chance of colliding with any actual Minecraft data when they added their new namespace, so kept out of the /Data branch

[itzg]

@DanTheColoradan and @sshipway, I'm thinking of blending Forge Mod, Bukkit Plugin, and World management all into one concept since there's conceptually and data model-wise a lot of similarities.

Here's a rough diagram where I'm sketching out the data model. For now, I'm abstracting all of those under the term "Uploadable"...but that doesn't feel like the best term. Do you all have any ideas?

As such, I'd like to blend the UI the same way where filters would be used to narrow the "management view" down to a particular type of "uploadable" (name pending). For one thing this will avoid having four UI actions in the sidebar:

• Upload mod/plugin
• Manage mod/plugin
• Upload world
• Manage worlds

Speaking of which, I'm thinking upload and manage can also be blended into one in the same view. The upload drop area would be at the top of the new, combined view. When something is uploaded it is placed into a "staging" area just below the upload box but otherwise resides along with the filterable list of everything else.

If you all agree, I'll start thinking deeper about how this applies to the Elasticsearch data model.

[danpolanco]

👍

[sshipway]

I'm not concerned so much about how the underlying data model looks; keeping all uploadables together makes sense here. However, I think that for the UI it might be a bit counterintuitive for most users.

While I think most Minecraft users would have no problem in thinking of Forge mods and Bukkit plugins as the same family, I believe they would have difficulty extending this to World saves as well. Most MCCY users in the future would likely just want to play minecraft, and possibly be kids who really just want to select a world and go (possibly selecting a Minecrfat type at the same time, though if world saves are parsed and defaults set sensibly then this problem disappears as well). If they can upload worlds simply through a 'World image manager' and plugins/mods are in a 'Mod manager' then this is likely to make more sense to them, even if they are stored in the same place under the covers.

So, maybe have just 2 menu items - "Mod/Plugins" and "Worlds" where the upload/delete/edit/list is all on the same page? The sidebar is not overcrowded, so having these separate would probably make the UI more useable. Of course, under the covers they could just be objects in the same class, but users will see them as being very different.

TLDR - I think the UI should keep worlds and mods separate, but they can be together in the data structure

[itzg]

Excellent points. Yes, the data model doesn't need to dictate presentation and vice versa. The same goes for any UI templates.

I also like the compromise where we combine upload/manage for each so it avoids clutter in the sidebar.