I like your ideas overall... with regard to changing the directory layout, I think the best approch is to leave it untouched for the moment... I see no good reason to separate SP/MP content, and you are not sure yourself what a good layuot would be....
It's better to change the layout later once we know what we want than do it now, and do it again once we know what we want especially since we would have to sort all sorts of path problems in the addons... Regards Boucman On Sun, Jun 8, 2008 at 5:01 AM, Ignacio Morelle <[EMAIL PROTECTED]> wrote: > 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 >
_______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
