Re: [Wesnoth-dev] Toward a modular Wesnoth

[Guillaume Melquiond]

On Sun, 13 Feb 2005 15:03:19 -0600, David White wrote:
> Sorry for taking so long to respond to this proposal. I've been trying
> to fully understand it and its implications.

No problem. As I said, I don't have time right now to tackle this
project anyway.

> I redescribe this idea, not because I think your description is
> insufficient, but so you can correct any misconceptions I might have.

You got it right. Except maybe for the files lookup:

> Also, when a package is loaded, any images that the package refers to
> would be searched for in the package's images/ directory, sounds in the
> package's sounds/ directory, and so forth. This mechanism would supplant
> the current "binary_path" system.

When an image is refered to, it will be looked up, not only in the
package's images/ directory, but in the images/ directories from all
the loaded packages, starting from the less-depended-on package.

For example, let's suppose a scenario wants a go-here-cross on the
map. It will put "items/gohere.png" as an overlay. This file would not
be provided by the campaign package, but by one of Wesnoth's core
packages, since it is quite common. So when the image loader try to
find this file, it will first look in the campaign images/ directory
and not found it, then it will go through the images/ directory of the
depended packages, until it finally reaches the core package that
contains it.

It also means that this system can be used to overwrite files. This
time, let's suppose an art designer finds Konrad too wimpy, and
decides to provide his own version of HttT with buffed up Konrad
images. It just has to create a campaign package, that will depend on
the HttT package, and will contain only the index.cfg file to load the
campaign, and an images/ directory containing the images of the new
Konrad. They will hide the images of Konrad in the HttT package.

I was speaking about binary files here, but it would also apply to
.cfg files (to any file in fact). To produce a Konrad with stronger
stats, it would suffice to put the three modified .cfg files of Konrad
in a unit/ directory of the package. They would then hide the older
version of the files.

That's how I see the package mechanism. It would provide a lot of
flexibility. Maybe too much?

Regards,

Guillaume