rheimus
commented
2 years ago Sounds more like a patch mode, the 1000 mile overview:
Theoretical patch mode
| Client has | Server has |
|---|---|
| 🐟1.0 | 🐟 2.0 |
| 🐠1.0 | 🦈2.0 |
client requests [🐟,🐠], client 🐟 is different; server sends [🐟 2.0], client does not have 🦈; server sends [🦈2.0].
| Result | Client |
|---|---|
| 🐟2.0 | |
| 🐠1.0 | |
| 🦈2.0 |
Is this different from push mode?
Push mode
| Client has | Server has |
|---|---|
| 🐟1.0 | 🐟2.0 |
| 🐠1.0 | 🦈2.0 |
client requests mods server sends [🐟2.0, 🦈2.0], client 🐟 is different; server sends [🐟 2.0], client does not have 🦈; server sends [🦈2.0].
Managed directories are set to push, client skips deletion phase.
| Result | Client |
|---|---|
| 🐟2.0 | |
| 🐠1.0 | |
| 🦈2.0 |
In anything other than mirror mode SeverSync can not guarantee that a client will be able to connect, the client could have any number of conflicting mods.
Presumably the desire is to allow clients to have any arbitrary file preserved or 'ignored' during the sync process, while this is more likely than not to leave a client unable to connect it was the original intent behind push mode.
Clients can currently add any file/pattern to their config file, you did explicitly not want the client to need this but it is essentially unavoidable as we do not currently have a way to determine what is or is not a client mod.
"rules": {
"files": {
"ignore": ["mods/mitts-off/**", "**/*.clientmod.jar"]
}
}Admittedly this is not terribly user friendly as it requires some knowledge of Json, Glob and SeverSync, there was some discussion and possibly an issue around allowing servers to send ignore patterns so you could add something like **/*.clientmod.jar server side and just tell clients to rename the mods they want ignored e.g. my-cool-mod.clientmod.jar.
The most ideal solution to the client mod problem is some sort of data/manifest/inspection that can identify client mods. Some ideas there: 1) inspect the source files in the jar for code that defines the 'side' the mod runs on This is probably the only reliable option, but it requires mods to be built in a way that has identifiable 'sides'.
2) query public API's for mod information (mod websites, curseforge etc) This might work, it needs some way to identify the mod on the host though, file names are not terribly reliable.
Serversync Version:
4.2.0
Minecraft Version:
1.18.1
Issue:
Hey, I love this project, as it seems to be exactly what I'm looking for, but I had a concern. I want a way, which doesn't involve a 3rd party Minecraft manager or launcher, to keep all of the individual player's client-side mods from getting deleted, while also fully synchronizing all files on the server to the client's mods folder. This also includes replacing existing mods in a client's mods folder with a newer version of the mod that may be in the server's mod folder, whilst keeping all mods that aren't in the server's mods or clientmods folder in the client's mods folder so they can use the mods without anyone having to explicitly edit the JSON files to tell ServerSync to ignore that particular mod, or list thereof, so it doesn't get deleted when syncing with the server. If there already is a way that I overlooked after researching this topic and GH project extensively, then I'm sorry for making this thread.
I've been reading into many people's requests and discussions in the Issues section, and have read up on the wiki, and have tried thinking of and making different ideas to make this work like renaming server mod's names with "api" or "server" or "client" depending on the type of mod it is, and creating .bat scripts which copy all mods already in the client's mods folder to a temporary location, syncing the mods folder with ServerSync, and then moving the mods back into the mods folder, but haven't found anything that works in an ideal way since each thing I've tried has a fundamental flaw.
I noticed that this exact matter has been discussed and mentioned a few times in the Issues section, but I've not found anything that actually does this. I'm aware of Mirror mode and Push mode, as well as push_client_mods, but it feels like each of their respective functions don't accomplish what I feel is a good middleground between them all.
I don't exactly know how complicated this would be, but my idea to remedy this was to have a 3rd mode aside from Mirror or Push that takes aspects from both and mixes them together. How I think this could work is that it would replace any mod on the client's end that shares the same name with a mod on the server, but has an older number or date in its name, thereby allowing mods to be updated to a newer version (like comparing the names of two mods and then keeping the one with the larger version number in its name and removing the one with the smaller version number), and to also be able to retain any client-side mods that did not have anything in common with the server mod's or file's names (example: potato.jar in the client's mods folder, but nothing that has the word "potato" in the file name on the server would allow the potato.jar to be retained in the client's folder). This would allow all server-required mods or client mods in the server to be mirrored on the client's side while also allowing that client to keep their own custom client mods and prevent them from being deleted whenever it gets synced with the server.
I wasn't sure of what name to give it, but I was thinking maybe calling it "Build" mode (like building on top of what exists, but also improving the foundation by letting mods get updated automatically), or maybe "Append" mode?
Thanks a lot for reading and helping me with this!