It seems like a lot of work to have it update on-the-fly and you risk corrupting your files if your client isn't set up just right if they're accessing the same files.
What I've done instead is to script a custom patching tool that clients can run to update their files. Basically, when I edit maps, statics, etc, I run an updater script that compares the MD5 hash of all the files that I have set to sync, then it compares that with the MD5 of the last time it was checked. Then if it was different, it zips them up and adds them to a patching repository.
Then, our users run a patching tool which is designed to act as a launcher program. It does a similar action, comparing the current game files to the downloaded list of MD5s from the repository. If the MD5 is different, it patches the file by downloading it from the repository, then overwriting the existing one after backing up the old one. Though I could probably ditch the backup feature at this point.
The end-user uses a bit more bandwidth since they have to essentially redownload the full file (zipped) every time it changes, but as far as server-side, since we use DropBox for the repository, there's next to no delay between updating it on our dedicated server and having the dropboxes of the administrators synced up. (like 5-10 seconds at the very most.) From change to statics to having it be patchable by clients it about a 3-5 minute delay, but about 90% of that is because of my slow upload speed at home.
It may make more sense to see it: link
What I've done instead is to script a custom patching tool that clients can run to update their files. Basically, when I edit maps, statics, etc, I run an updater script that compares the MD5 hash of all the files that I have set to sync, then it compares that with the MD5 of the last time it was checked. Then if it was different, it zips them up and adds them to a patching repository.
Then, our users run a patching tool which is designed to act as a launcher program. It does a similar action, comparing the current game files to the downloaded list of MD5s from the repository. If the MD5 is different, it patches the file by downloading it from the repository, then overwriting the existing one after backing up the old one. Though I could probably ditch the backup feature at this point.
The end-user uses a bit more bandwidth since they have to essentially redownload the full file (zipped) every time it changes, but as far as server-side, since we use DropBox for the repository, there's next to no delay between updating it on our dedicated server and having the dropboxes of the administrators synced up. (like 5-10 seconds at the very most.) From change to statics to having it be patchable by clients it about a 3-5 minute delay, but about 90% of that is because of my slow upload speed at home.
It may make more sense to see it: link