Okay so I did a test to see if server sync had changes instantly known like a hash. Could you add a file comparison log? So whenever serversync syncs things to client it should generate a serverside (noted changes and a clientside changes log) serversync should then read the json and compare file difference and only add the changes and delete things that have been added that have not been set to ignore. Just a thought.

I believe (correct me if I'm wrong) that this use case is:

• Using forge loaded (server takes a while to start up)
• Add/Remove/Change files
• Have serversync auto update it's file lists with the changes made
• No server restart required

Sounds easy enough with watchers, though standard mods are inherently synchronous and would require a server restart regardless.

This would allow sync of:

• Configs with updated values
• Misc non mod files that require no server restart
• Client side only mods

Correct ; I knew you would understand :) Yeah so each mod jar can have a value why not just use file name value? So if client file a does not match b replace a with b. If client says file a server matches file a client skip.

Not sure I fully understand what you mean.

Currently serversync holds a List in memory of 'mods' (files) which contain various information. This is a 'snapshot' of the directories that serversync has been told to sync at the time of starting

Key parts of the list being:

• Name: usually the file name
• Location: where the file is located on the server

Getting these by scanning the directories or by loading from a parsable text file would be essentially the same in terms of performance. The files are not actually accessed (read into memory) until they are the current file being transferred between server -> client.

Comparison to see if files are different is done via mcmod.info 'version' if it exists else the files are hashed and compared to see if they are the identical file. In theory the version property is faster but the difference is negligible in practice.

Oh then yeah XD this is already in there.

Closing in favor of a backlog research ticket in project 2.7. Need to test viability of having directory changes observed.

I haven't actually done anything around this ticket yet 😀, although if SS does what you need already that's good.

The atuo update on changes is being tracked in project 2.7

Testing for you now.