Hi everyone. Sorry, I haven’t really tried to do the patching system yet (so I could be really wrong and could be just jabing here), but after reading on how it works, would it not better instead of having a static patching (one where you build s patch for every change) to have a dynamic patching. By this I mean, instead of building new patches for every way to build up to the newest code you just build one on the fly.
How?: Using a tree that keeps track of whats inside the file and their versions on the client and one that keeps track on server side. Server would just have to ask client for this file and then server would just have to compare it and build a patch base on that to send to client instead of just sending length patches to get to the newest code.
This would work for both people that just need maybe one change in the file to people that need sub changes.
&Note, I’m not saying this way is better, but would just be another option people could do.
You’re proposing building a patch at runtime based on the observed differences between the client and the server files?
That is indeed possible, and that’s the approach that programs like rsync use, for instance. But rsync only does this because it has to–it has no way of knowing ahead of time what the client might have installed and how it might different from the server version.
If you know ahead of time which version(s) the client might possibly have installed–which we do–then you can take advantage of this and generate a precomputed patch file. A precomputed patch file is many times more efficient than dynamic patching–it can deliver much smaller patches, with much less overhead.
You would have to premake a lot of patches to cover all grounds…(or from what I gather what wiki said) aka, v1 to v5- v2 to v5… v4 to v5… so on~
Wouldn’t it just just be better to gather their dir tree of the .p3d (the the version number at the top of the tree list) and just see what is needed off that instead of trying to build and store all thos? You would see a little more overhead, of course, as the file has to be made right on the spot, but less mess over all…no? With version key at the top, you can also just check againast that for a quick opt, too. Both ways would/should be small in size, but one has a little more control I would think. Remember, this is just another options… it’s not to be use to replace the current patching system cus you could use both.
version #5
Game
|_Main.py(v3.4)
|_w/e else(v2.4)
|_Music
|_SoundFile.ogg(v1.0)
You misunderstand the way the system works. It doesn’t generate NxN patches, it generates N patches. There is a patch from v1 to v2, and one from v2 to v3, and one from v3 to v4, and so on. In the event that a user needs to update from v1 to v4, he downloads three patches and applies them in series.
If you want to implement something more sophisticated in your own app, you are welcome to do so.