Re: [Wesnoth-dev] Toward a modular Wesnoth

[David White]

Sorry for taking so long to respond to this proposal. I've been trying 
to fully understand it and its implications.

As I understand it, what this proposal would do is introduce a concept 
of a 'package'. There would be two directories that would be scanned for 
packages: one under the shared Wesnoth data directory, and one under the 
user's Wesnoth data directory.

A package would not be loaded in full when the game is started, only the 
index.cfg file. When a user selects to, for instance, play a certain 
campaign, then that campaign's package would be loaded in full, as well 
as any dependent packages, while none of the other packages would be loaded.

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.

Likewise, cfg files would be searched for in the package's directory, 
and this would supplant the address@hidden syntax.

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

I would imagine that most of the images, sounds, and music shipped with 
Wesnoth would appear in some kind of 'common resources' package, which 
all standard campaigns and most user campaigns would depend on. 
Campaign-specific images, such as an image of Konrad, would appear only 
in the 'Heir_to_the_Throne' package. This means that a user campaign 
wanting to use an elvish fighter would depend on the 'common resources' 
package, while if the user campaign used an image of Konrad for some 
purpose, then it would either have to include the image of Konrad, or 
set Heir to the Throne as one of its dependencies.

I do like this proposal, and I think it'd make the game more modular, 
and easier to add campaigns. I also do think that it'd be relatively 
easy to code. I think that it should be slotted as a change that we 
intend to make somewhere between the 0.9 release and the 1.0 release.

David

Guillaume Melquiond wrote:

> Hi,
>
> I already sent a mail about my thoughts on packaging a modular
> Wesnoth. But I recently had to go through some part of the code base
> when trying to fix some bugs with zipios and user campaigns, and when
> trying to figure the recent "textdomain" failure. So I now have a more
> precise idea on what could be achieved; I'm posting it here, because I
> won't have time to work on it it right now, and later a 1.0 release
> may preclude it.
>
> One of the goals is to remove all the "textdomain", "binary_path",
> "address@hidden" stuffs, so as to simplify the design of
> campaigns/multiplayer/etc. There wouldn't be any difference between
> user and mainline campaigns: a mainline campaign could be moved to the
> user directory and would still work, and reciprocally. And they would
> have the same translation mechanisms, no need to go to great length
> anymore to translate a user campaign.
>
> Another goal is to clean the WML cache handling of Wesnoth. For
> example, when looking at my cache directory, I see a file labeled
> "CAMPAIGN_THE_DARK_HORDES-EASY-MULTIPLAYER-lang_default". What?!
> Wesnoth does support multiplayer campaigns and it wasn't even written
> in the Changelog?! More seriously, there is also the whole
> campaign-ifdefing idea that I find quite disturbing. It would be a lot
> better if we hadn't to use it, by design.
>
> At the moment, the "data/" directory is a mess; and there are
> "images/", "sounds/", "music/", "translations/" (named "po/" during
> development, renamed during installation) directories. So, here is my
> proposal: remove all these directories. And replace them by a unified
> model. One single "packages/" directory, located at two places to
> provide per-system and per-user storage (as is the "data/" directory
> at the moment).
>
> This directory would only contain other directories, or zipfiles
> containing a compressed directory. Each of these directories/zipfiles
> would contain an "index.cfg" file describing the package and its
> dependencies (see my previous mail if you don't understand what I mean
> by dependencies). It would also contain "data/", "images/", "sounds/",
> "music/", "translations/", etc. sub-directories.
>
> All these sub-directories (except for "translations/") would be
> merged: all the "images/" directories of the opened package tree would
> be seen as a single directory "image/"; kind of an union mount point
> for those familiar with this BSDism. That way, there would be no need
> for "binary_path", "address@hidden", and campaign-ifdefing anymore. As for
> translating a package, the strings would be taken from the
> "translations/" subdirectory during WML parsing. No need for
> "textdomain" anymore, and it would be as easy to have a translated
> user campaign than a mainline user campaign.
>
> As for the cache, the file would be named after the top-level package
> that opened all the needed others. In a sense, it wouldn't be that
> much different from the current scheme where the cache file is named
> after the campaign name. The name would still contain all the defined
> macros (except for campaign-ifdefing that wouldn't exist anymore), in
> particular the difficulty setting.
>
> I don't think it would be that hard to implement. But there are some
> details that wouldn't work. For example, musics can't be stored in
> zipfiles at the moment, but I wouldn't be surprised if it was only a
> matter of time (it is the remaining part of the SDL not yet
> converted). More annoying, .mo files can't be stored in zipfiles, they
> would have to be decompressed, or we would have to ship our own
> enhanced intl library.
>
> But other than these two problems (that don't happen when using plain
> directories), such a mechanism would work just fine in my opinion. Any
> thoughts on this?
>
> Regards,
>
> Guillaume
>
>
> _______________________________________________
> Wesnoth-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/wesnoth-dev
>
>