Hello I have been working during last week on major changes to the way add-ons are handled by the game. There are various aspects involved, including the publish-information WML (.pbl files), the data stored by campaignd in the server, and the preprocessor sequence when loading/starting a game. Although I have made most of the changes already in my working copy of SVN, I would appreciate feedback on them, including things that I could have done in the wrong way, things that are wanted by users/developers since long ago and I didn't know of, or just things that would be nice to do while at it.
I intend to commit my current changes by June 8th on the evening (GMT-4), to get appropiate (torture-)testing before 1.5.1 is out, in the hopes of set with this the start of a series of development releases that I hope will give us a shiny and nice 1.6 release when completed. My changes (a.k.a. "reorganizing user-made add-ons") affect the following parts of the code: - campaignd (by storing additional fields in the add-on files) - The WML interface for add-ons (specifically, the .pbl file format), adding new properties. - The way add-ons' WML is installed and preprocessed by the game. - The in-game add-ons manager dialog. The campaign server program (campaignd) on my test machine stores the uploader's email address if specified, as it currently does with his/her IP and passphrase, e.g. it is not revealed to clients. I took the idea from http://www.wesnoth.org/wiki/User:SkeletonCrew#Server, after talking with its author about it. It also stores the 'type' of the add-on as specified in the .pbl file, which is, unlike the previous one, a publicly available property. And this is the part where both server and client have to handle the same terms. This new 'type' property is a WML attribute which can have either no value ("unknown" type), or one of the following, based from http://www.wesnoth.org/wiki/User:SkeletonCrew#Client_side_changes: - Single-player addons: "campaign", "scenario", "media"/"mod"/"gui" (see Issues) - MP addons: "era" (equivalent to "era_mp"), "faction" (equivalent to "faction_mp"), "maps_mp" (equiv. to "maps", "map_pack" or "map_pack_mp"), "scenario_mp", "campaign_mp" Add-ons that fall into the "unknown" type by having a missing valid 'type' value specified in the .pbl file/campaignd storage file, are regarded as single-player ones under this new scheme. Then come the filesystem hiearchy and preprocessing changes. Multiplayer add-ons (eras, campaigns, scenarios, etc.) are installed onto <preferences dir>/data/multiplayer, while singleplayer ones (or those not marked to pertain to a particular class, for compatibility with old .pbl files) are stored at <preferences dir>/data/campaigns. One of my intentions when writing the code for this was to disable preprocessing of <preferences dir>/data/campaigns when launching a MP game, saving variable amounts of time to the user, depending on how many single player add-ons he or she had installed, and the complexity/effect of their "stub" code (the [campaign] nodes and possibly some other information, like external [binary_path]s and [textdomain] declarations). Another intention was to organize add-ons on even deeper subdirectories (i.e. <pref.>/data/multiplayer/eras, <pref.>/data/multiplayer/campaigns). And finally, the changes to the GUI we have in the game for managing add-ons. Since Mordante/SkeletonCrew wants to finish his new widget set in order to build a new, improved, more user-friendly management interface for add-ons, I decided not to attempt much at it, except by adding a new "Multiplayer (yes/no)" column to the list, which the user can then... use, to change the sorting order of add-ons. That way he/she can tell which add-ons are of their general area of interest or not. Although I could as well show them information about their particular area of interest (campaigns, scenarios, eras, etc.), my conclusion was that any (temporary) solution I could make up would be unelegant, specially lacking a proper GUI toolkit which is what Mordante is writing, as far as I know and can see. So this is it so far for the users. A screenshot made with my custom set of test add-ons can be checked here: http://i144.photobucket.com/albums/r176/shadowm2006/temporary_addons_gui.png Issues ------ Zookeeper and ESR (if I recall correctly) had suggested already, before I went to craft this scheme, that the <user.>/data/campaigns dir where all kind of add-ons are stored was renamed to <user.>/data/add-ons or similar. I don't recall why (and I admit that my memory and patience fails to search for the reason), but it was rejected for "symmetry" with the mainline directory hiearchy for /data. Okay, I decided to keep that symmetry in mind while coding this change, but, let's say that the night-before-the-release I came to realize that it may create unnecessary isolation and complexity in the way add-ons cooperate with each other. It is very common for *singleplayer* User Made Content to rely on multiplayer eras, which is not something I personally like, but it makes sense nevertheless, both for users (saving space on disk) and content maintainers (saving space on distribution package, and reducing maintenance costs by efficiently reusing other UMC, treating them as software libraries). Single player content may still use that MP content, even if it is inside a different parent directory than the SP add-ons, but it could seem awkward to the long-time user to have them so clearly separated from each other in their file systems. A matter of taste, I say. But there is another issue involved, and that is the naming of directories for every add-on classes that exist (and may exist). I for one expect the following UMC types to exist: - Campaigns (SP/MP) or single scenarios - MP Eras, stand-alone factions, add-on factions for other MP eras - Music & sound packages for both SP and MP campaigns/scenarios - WML resources for UMC authors of any of the above cathegories, such as units, terrains or sets of general-purpose macros - New themes for the user interface (predicted by the new toolkit's inner workings) - Complete modifications of the way the game works, looks and feels, by WML But there could be more, I guess, and I personally would not like to have a <user>/data subdirectory named after each and every possiblity. It can be confusing or frustrating to people who a) manage their add-ons by hand; b) are newcomers learning to make new add-ons; c) want to write their own utilities relying on where add-ons are located. Even my temporary /data/[multiplayer/campaigns] scheme introduces an issue that I'm still trying to figure out how to solve: name conflicts. A user could possibly install/create add-ons in both content directories, and lead to undefined behavior from the game engine. The only solution I can think of easily is completely isolating both content "lands" from each other, managing them in separate ways, making it impossible for single-player content to depend on multiplayer content *or viceversa*. Thus it is not a good one. All this leads me to think that perhaps continuing with the old unique-directory approach, while keeping the goodness of the other changes mentioned here, would be a better approach as permanent solution, easy to adopt by users, content authors, and (eventually) developers. It would be a good idea, though, to take this opportunity to rename the <pref.>/data/campaigns dir to <pref.>/data/addons or anything else that is not so misleading as the current. So, well, I'd appreciate any comments/opinions/thoughts on this matter. Also, I'm willing to wait for after 1.5.1 is released if it is considered more appropiate for the users. Regards -- Ignacio R. Morelle (Shadow Master/ShikadiLord) P.S. Apologies for my bad English. But I'm not used to write long letters/e-mails in my native language, either. :) _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
