Closed User4716 closed 4 months ago
I see what you're suggesting, but this isn't really something thats globally applicable. For one, imagine how this would work with worlds. If the game would read worlds from one directory, and write them to another, that would mean any changes you make to a world would be saved separately from the actual world. Then when you close and reopen the world, it resets to the state in the reading directory, and overwrites any changes in the writing directory.
Aside from that, you're misunderstanding how selected resource packs are stored. While the resource packs themselves are all inside the resource packs folder, the selected packs are actually loaded from options.txt
. So disabling syncing of that should actually have the effect you're looking for already.
Agreed, when I made this post I didn't think how it would affect the other settings. And if the options.txt controls the active resourcepack then the "incoming/outgoing control for resourcepacks" is unneeded in my opinion. And I'll probably disable the sharing for the options.txt so that each instance has unique settings.
Config ❌ This would probably only overcomplicate things. Even if we had the option to separately choose what config files we want to share, I don't see a case where you would want to disable the outgoing traffic for example.
Data packs ❌ I see no use in here as well. The world save file probably controls the active datapacks so I think everyone has no problem that the datapacks are the same everywhere.
Options ❌ There's no need for more control than disabled/enabled sharing here.
Saved hotbars ❌ Just sharing in and out traffic at the same time is probably fine for everyone. So no need for anything here..
Replay recordings ❌ No. Just think about it. It wouldn't work, has to share in/out traffic at the same time.
Saves ❌ Either you use the global world list, or you have your own. As @enjarai mentioned above, it would cause problems if we could mess with this.
Screenshots ❌ No, just keep everything the same, no need for anything.
Servers ❌ No need for anything.
Shaders ❌ Nope.
⚠️The problem:
As of now, the config file controls that what parts of the global directory will the client use and modify.
If there's a change in the equipped resourcepacks from another modpack that shares the global resourcepacks, All other modpacks that link the resourcepacks will have that change as well.
I kinda want to have seperate resourcepacks enabled for each modpack, but still have the left side list of all of my resourcepacks be the same to save storage space. (Since all of my resourcepacks are in the same folder, and not copied to each modpack seperately)
I share my global resourcepack folder to my heavily modded modpack to get the normal resourcepacks there as well. But when I have some custom resourcepacks enabled in the heavily modded modpack, it will get activated on the vanilla side as well. And it's annoying to disable any modded resourcepacks in my vanilla instances every time I have played my modded modpacks.
💡The smart solution
To fix this I came up with a creative idea. Basically, as of now we can configure what resources we want to share. Meaning if the option is enabled in the list below, if you make changes to it in that area locally, all other linked instances will get that change. And if another instance has made changes, you would replace your possible local changes with the global changes. And all I'm trying to ask for, is to allow us to control incoming and outgoing changes. (Explained more below the image)
So what I mean by allowing us to "control incoming and outgoing changes" Well it would mean that we would have 2 lists of "what we want to share"
The first list will control incoming data. With it you can specify what areas of the game you want to get updated by the global directory.
The second list will control outgoing data. With it you can restrict what locally changed data would actually go into the global directory.
🎨Here's a little demonstration image I made in Paint
As you can see, if we pretend that "Modpack 2" is my modded modpack, I could use all of the global resourcepacks in there, but the changes I make in that modpack locally would never translate to the global file. Also keep in mind that each option can have a different configuration profile, the image below only demonstrates one option and how it could work.