Allow enabling multiple texture packs with precedency

[appgurueu]

See https://github.com/minetest/minetest/issues/10829#issuecomment-781793942

[AFCMS]

100% aggreed

[jkf16m]

mmm hi, let me see if I understand @appgurueu

This feature request is about, being able to select more than one texture pack (because right now, we can only have one enable per time).

So, in a new menu for example, a new tab, we could select which textures pack to have enable, and select the order in which one will precede to the other, in case a certain texture was already found.

For example, let's say we have the texture packs: "default", "TX1" and "TX2"

having default as the first one, will be overridable for any texture pack (being the top of the list). then TX1 will be the second one, overriding the textures "door" and "grass" and then TX2 will be the third one overriding the "door" texture.

If this is what I understood, actually the same design minecraft follows.

[jkf16m]

the only problem that I see is, how should we organize "packages"? from what I've seen, packages tab includes:

• texture packs
• mods
• games

shouldn't we make subtabs of some sort, inside "Content"? or we can make this feature work without the need of making new tabs?.

[NA0341]

I agree with @jkf16m: we should make subtabs. And we should also consider the fact that there might be more than textures in the future. So essentially we're talking about Resources in general.

I suggest three tabs:

• Games
• Mods
• Resources

In the Resources Tab, you can (de)activate & reorder packs. With the Information Section to the right - remaining as is.

• This is a very simple approach that doesn't conflict with the way Minetest's UI is built.
• Splitting Content into Tabs brings the benefit of enhanced UX - especially when dealing with lots of game resources.
• The ability to arrange packages regardless of whether they are enabled or disabled enables flexible use of a wide variety of scenarios. In other words: You can have arrangements for several scenarios and easily switch between them by enabling or disabling the respective packs.
• The KISS approach I described also offers more possibilities than MC's implementation!

This should do the trick for the most common scenarios.

---

I want to highlight again that this is not just some convenience thing. Putting together a new pack from all resources you want to use has Major Drawbacks!

• You loose automatic texture updates.
• If you want something else, you may need to start over from scratch.
• You need to upload your new pack in order to share your configuration.
• All maintenance of the pack is on you.
• etc.

---

Since this is directly related to this topic - I'll share this information here as well.

Scenario: You'd like to use this Texture from this Pack and that Texture from that Pack - and there's more… …there's sounds from Mod you'd like to use in Game - and so on.

Introducing » Resource Remixer «

Resource Remixer is a Tool that allows you to do the following:

• Mix existing resources together (sounds, textures, etc.).
• Share your Mixes with others via a simple text file or line of text.
• Keep your remixes up to date (by applying updated content from ContentDB & maybe other locations).
• Create, update & maintain Resource Packs.
• View 3D Textures (texture models like ingame).
• Batch process resources (examples: convert image format, colorspace, etc; convert audio format; change audio pitch; etc.).
• Create, mange & share Scripts for batch processing.
• Manage & share Color Spaces & Profiles.
• Manage & share Sound Profiles & Samples.
• Manage & share Game Configurations.
• Your Idea 💡

⮱ Mixing Resources can be done by creating a new Pack with all the wanted Resources symlinked. That way they are always up to date if you update from the Client, have minimal impact on storage space, can be easily edited, etc. ⮱ Sharing can be done simply by a .properties file or some nested JSON (one-line).

[rollerozxa]

The absolute minimum to support enabling multiple texture packs on the client-side (excluding a graphical dialog for enabling and moving texpacks up and down) would be to make getTextureDirs() be able to split texture_path on a separator and return a list of paths:

std::vector<std::string> getTextureDirs()
{
	std::vector<std::string> paths;

	std::vector<std::string> texture_paths = str_split(g_settings->get("texture_path"), ':');
	for (auto path : texture_paths)
		fs::GetRecursiveDirs(paths, path);

	return paths;
}

This will take care of priority, i.e. the firstmost path is top priority and then it goes downwards when looking for textures.