Slick Forums

This is probably a more difficult task. I am designing an orpg and I would like it to search for available updates on the program splash. I have not done much networking, so this gets to be a learning experience. I am using the Kryonet library.

So I have a server running and the client connects to it on startup. The client then sends an update request to the server with it's version, and if the game is outdated it will send the files it needs to be updated and overwrite the old ones. My problem is the sending files part. Does anyone know a good way to do this?

Hey,
sorry for the topic bump, but my question fits in with what has been postet here.

I am programming a game engine that makes use of Slick and I am thinking about how to solute a Updater API since multiple weeks. My API currently works like dime said - except that I prefer to not compress the data,

and I can't find the best way to patch the main-jar itself. The updater is part of an API and won't force devs who want to use my API to create a seperate program as launcher / patcher, i need a way to let the executed program patch itself.

I could update main.jar by downloading the new instance as mainNEW.jar, then mainNEW.jar gets executed by the running main.jar and mainNEW.jar forces main.jar to close. Secondly, mainNEW.jar notices that its name is not "main.jar" and downloads a new instance as main.jar, then main.jar gets executed and kills mainNEW.jar,

but this way seems not to be that efficient. Is there a solution for the problem? How does getdown handle that?

I plan on going with a simple incremental patcher. It starts off with 0.patch to 9999.patch or more. The client would store the last .patch increment in a .dat file to determine the next increment. So if the last patch was 99 the client would know to ask if patch 100 exists and then it repeats this after patch 100 has downloaded. If the user has 0.patch and the newest patch is 100.patch then the server knows.. "we need to get patches 0-100 for this user from the file database."

In the .patch file you'd have a list of md5 checksums for all the files for validation so every time the client starts the updater you'd check the validation of the last .patch and make sure the files are all there otherwise you redownload that patch. Sorry if this is confusing you.

1. Download patch 99
2. Install patch 99
3. New patch 100 found
4. Scan patch 99 md5 checksums if fail goto step 1
6. Download patch 100.
7. Install patch 100.
8. New patch 101 found
9. Scan patch 100 md5 checksums if fail goto step 6

I like this approach to updating very much because its simple and most users will know what is going on.

Unfortunately mine is in C# but the same idea can still be applied to java.