ServerSync

ServerSync

48.5k Downloads

Query: New handling of client files, should I prepare a PR?

Oekn5w opened this issue ยท 5 comments

commented

Hey,

in my fork I changed the behaviour of the client files as following:
There is a "client" folder in server root directory expected, whose substructure mirrors what should be additionally added to the client root directory, i.e. mods, resources, etc. subfolders.

I pretty much cobbled it together to support the matmos lightmod, which requires a resource pack and to be put in a lightmods folder. I didn't do much testing regarding the handling of configs or change the documentation.

Is this something you are interested in? If so, I can see if I have time to prepare a "proper" PR.

commented

Closing this, feel free to reopen if you would like to bring your changes across.

commented

Hmm, have you tried the latest versions of ServerSync?

Sounds like it natively supports what you want to do already with the directory include list.

e.g. to sync a folder in the root dir called litemods you would just add the following to your directory include list.

directory_include_list<
    litemods
>
commented

I based it on 2.6.22, from the wiki I couldn't see a change with respect to that (clientonly files) behaviour. The example above was meant to be as clientside only, see the attached screenshot ("data" is server's root).

BTW what I said in the OP is wrong regarding the lightmods folder, nevertheless the resource sync (i.e. files that cannot be put in the clientmods folder) was necessary.
That would probably work with the include list, however I find the changes I made to make it cleaner for UX standpoint: Throw everything you want on the client only in the subfolder, and the server doesn't "see" anything out of order (Why is there a resourcepacks folder on the server?!).

image

commented

I would prefer something like #124 so that users are not locked down to specific file/folder structures.

Recap on clientmods design for clarity:
The clientmods feature is designed for files that could be used by the client but are not required to connect, much like a suggestion. The client is always in control of accepting/refusing these suggestions.

Redirecting would allow you to set up anything you like e.g.

./optionals
--| optifine
./client
--| litemods
--| resourcepacks

config:

directory_inlcude: {
  "optionals": {redirectTo: "./", optional: true},
  "client": {redirectTo: "./"},
  "mods",
  "scripts"
}

Something along those lines.

commented

Your changes look good, I would need them to be updated to 3.x.x though. I do not intend to continue support for 2.x.x