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
