User:Nital

Welcome to my userpage! You can read about my ideas and projects connected with Wesnoth here.

My ideas

My main interest as for now is easing the process of patching Wesnoth binaries. That is mainly because my friends has requested a method that would allow them upgrade without downloading ~200 MB every time. Another reason is because Ivanovic told me than nobody bothered about that before, and I see this part quite important ;)

Wesnoth binary patch problem

Be warned - since my friends are using Windows, this problem will be considered mostly from Windows perspective. However, it may be applicable to other OSes as well, I don't know. As everyone knows, official Wesnoth packages are getting bigger and bigger with each release. It is obvious that downloading a >100 MB file every time isn't convenient.

Solutions so far

There was a try with providing xdeltas (read more here: Download Xdeltas) for Windows binaries, but as it's stated there - xdeltas of binaries have two major cons:

• They are incremental, no patch unification is possible (to upgrade from 1.2.3 to 1.2.5 you have to download 1.2.3->1.2.4 and 1.2.4->1.2.5 xdeltas, unless devs provide 1.2.3->1.2.5 xdelta)
• Due to unstable character of inner structure of the installation binary, xdeltas of these tend to have large sizes.

However, developers of professional games somehow manage to keep their patches small, working and sometimes even quite unified (so the patch can handle updating several different versions). They usually achieve that by working on an already installed game and that is also my approach.

Goal

The goal is to make creating patches for stable branch easy. Patch in this context means a small executable that user:

1. Copies to his/her wesnoth folder from 1.6
2. Runs it.
3. Removes it. (optional)
4. Forgets about the process and starts enjoying upgraded Wesnoth.

I mentioned stable version because of three reasons:

• not many files are (or should be) changed and added during development of stable branch
• there is a good starting point upon which the unified patch would be created, i.e. first release of the branch (for example release 1.6 for 1.6.x branch)
• it is aimed to be used by the majority of Wesnoth players.

Overview

My approach is simple: compare two filetrees "wesnoth1.6/" and "wesnoth1.6.5/" and include in one package all files that have been added or changed between these two. Then compress it with 7-Zip and make it a self-extracting archive. Benefits of this approach:

• Patches are not incremental, a 1.6.7 patch will work with 1.6.6 as good as with 1.6.1 or 1.6.
• Allows easy exclusions of patched files (for example Hungary fansite will be able to provide substantially smaller patches with only English and Hungarian translations included)
• Cross-platform (will work on all OSes that 7-Zip supports)

Some statistics of 7-zipped data:

Part	Original MB	7-zipped MB
wesnoth.exe	13.6	2.55
translations/	56.8	8.85
data/ * (see below)	~5	~0.5

data/ - excluding graphics, sounds, music and campaigns (only because campaigns contained lots of new graphics and I was too lazy to exclude them manually from their directories)

It can be seen that if there are no changes to graphics or sounds, the patch size can be easily kept below 20 MB (even below 10 MB if you don't want to update translations). Concerning translations, there could be two patch files for one release - one containing only English[US] update for English people and others that care only about gameplay fixes. The second one would contain all translations, and would be about 9 MB bigger.

Things that should be avoided

To keep patch files as small as possible, developers should avoid (in stable branch):

• Adding/changing graphics and sounds (especially sounds). Since their formats are already compressed, changing a 6 MB ogg file will result in a 6 MB larger patch.
• Reorganizing structure of wesnoth/ tree (i.e. renaming or moving files or directories). Unless there is a better tool developed, it's a very bad idea since every file and dir which changed location will be included in the patch, even if it wasn't changed at all.
• Adding any references to Wesnoth version in default menu Start shortcuts etc. since it doesn't introduce anything useful to average player and increases the difficulty of patching it correctly.

Progress

I am currently working on getting first working beta. It is being written in Python, like the rest of Wesnoth tools.

My contributions

patch #1124 - adding "hidden" attribute to SideWML