Re: [Warzone-dev] Proposal for warzone data sets
Am Freitag, 11. April 2008 18:46:41 schrieb Per Inge Mathisen: One word about terminology first. The word 'mod' is often understood as third-party, user-created modifications to a game. In Warzone, however, we should look at this in a wider sense, since the game uses overrides quite extensively during the campaign. So any way that one set of data is overridden by another, presumably smaller set of data, I will call a 'data set'. The current system is as follows: You specify an ordered list of .wz files and/or system paths in which files are to be read. When we read a file, we start at the end of the list, and if it is not found immediately, we go down in the list until we find it. Multiplayer is implemented this way - the campaign is the base data set, and multiplayer files override them to provide the multiplayer game setting. End user modifications go on top of that again. However, there is also a second system, implemented in the .wrf and .lev files, which specify which files to load for a given map/level. This is used inside the campaign to load different rules, scripts and textures for campaign levels. For example, sometime during campaign 1, barbarian models get kevlar armour by loading a different texture page. The current system has three large deficiencies: 1) There are two systems, not one. 2) The .lev/.wrf system is very taxing to modify, is very unforgiving to users, and hard to maintain. 3) The limitless list of data set directories is not easy to specify and impossible in practice to verify. The user cannot know which data sets work with which other data sets, and a GUI to specify such many-to-many dependencies is quite hard to make easy to use. So my idea is to replace the current systems with a simpler version of the directory (or .wz) override mechanism. The only difference is actually a small but important restriction: You can only add a data set on top of another if it lies underneath it in the file system hierarchy. This will solve several problems. You can no longer select a data set which does not work against the parent data set. It also becomes easy to enumerate which data sets are available to choose for a user (and will be safe to pick), merely look for some identifier file (which contains a description of the data set) and if selected, mount the whole directory as an override. If you want to run multiple mods at once, this is somewhat more difficult, but achievable. You indicate that you know what you are doing by moving/copying the mod into the other mod you are using. This also sets the order that the mods must to be loaded, which may well be important due to dependencies or possible conflicts. Third parties can aggregate popular mods in this manner, if such were to appear. (However, in my experience, third party mods are far less frequent popular on open source game projects, simply because they tend to be subsumed quickly by the main trunk of development. So this is not likely to be an issue in any case.) The first thing that would have to be done is to untangle the campaign data, which uses the .wrf/.lev system to override files. This would mean that we need to split up the data into data-- shared resources: most graphics, all tilesets, models data/campaign -- campaign files data/campaign/cam1 -- cam1 data/campaign/cam1/kevlar -- cam1 with override png for kevlar armour hack data/campaign/cam2 -- cam2 data/campaign/cam3 -- cam3 data/multiplayer -- multiplayer files data/multiplayer/cam1-- cam1 maps overrides to select correct graphics from base directory data/multiplayer/cam2-- cam2 based maps data/multiplayer/cam3-- cam3 based maps This means we have to split apart campaign and mutiplayer data, instead of having one override the other. As long as we manage to keep the disk intensive graphics and sound in the base directory, this should be manageable. User mods would go under the appropriate directories, as follows data/campaign/cam1/harder -- the 'harder' user mod for cam1 data/campaign/cam2/harder -- the 'harder' user mod for cam2 data/campaign/cam3/harder -- the 'harder' user mod for cam3 data/multiplayer/cam1/mines -- the 'mines' user mod for cam1-based maps data/multiplayer/cam2/mines -- the 'mines' user mod for cam2-based maps data/multiplayer/cam3/mines -- the 'mines' user mod for cam3-based maps As you can tell, mods that intend to apply to all three campaigns must be in triplicate, and that also goes for multiplayer mods that intend to apply to all three map types. For some things this may be somewhat tiresome to duplicate up, but it also allows people to make mods that are entirely correct, so that eg graphics changes are appropriate for each map type (base plates that match the terrain, changed tiles replace
Re: [Warzone-dev] Proposal for warzone data sets
Am Freitag, 11. April 2008 19:32:24 schrieb Per Inge Mathisen: On Fri, Apr 11, 2008 at 7:18 PM, Dennis Schridde [EMAIL PROTECTED] wrote: You mean I may only override files in my module which were already overriden by the modules I depend on? No, you could override any file provided by a parent data set, include base. Or you could provide a new file, referenced by some other file that you override. Can you then please explain The only difference is actually a small but important restriction: You can only add a data set on top of another if it lies underneath it in the file system hierarchy. and the surrounding paragraph? --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Proposal for warzone data sets
On Fri, Apr 11, 2008 at 8:12 PM, Dennis Schridde [EMAIL PROTECTED] wrote: Can you then please explain The only difference is actually a small but important restriction: You can only add a data set on top of another if it lies underneath it in the file system hierarchy. and the surrounding paragraph? Let me try to put it another way: The restriction is that the data set has to be a child directory of the last data set selected. The effect is the same as if you use physfs to mount the selected directory and add it to the end of the physfs path list. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Proposal for warzone data sets
Am Freitag, 11. April 2008 20:30:18 schrieb Per Inge Mathisen: On Fri, Apr 11, 2008 at 8:12 PM, Dennis Schridde [EMAIL PROTECTED] wrote: Can you then please explain The only difference is actually a small but important restriction: You can only add a data set on top of another if it lies underneath it in the file system hierarchy. and the surrounding paragraph? Let me try to put it another way: The restriction is that the data set has to be a child directory of the last data set selected. What benefit do we gain from that? The effect is the same as if you use physfs to mount the selected directory and add it to the end of the physfs path list. Why not do that, if it is the same? You can no longer select a data set which does not work against the parent data set. Why can I not do that with your approach? And why is this a specific problem of the old approach? My idea would be: data/ data/base/ data/base/.metadata data/cam_base/ data/cam_base/.metadata data/cam1/... data/cam1/.metadata data/mp_base/... data/mp_base/.metadata data/mp_cam1/... data/mp_cam1/.metadata ... represents an arbitrary amount of files and folders The .metadata files could look like this -- data/base/.metadata -- MetadataVersion: 1 Name: Base Description: Files common to all modules Version: 2.1 Author: WZR License: GPL2 Dependencies: [data/base/ would contain the very elementary things, like frontend images, etc] -- data/cam_base/.metadata -- ... Dependencies: base [data/cam_base/ contains stuff common to all campaigns, like basic AI] -- data/cam1/.metadata -- ... Dependencies: cam_base -- data/cam1_kevlarbaba/.metadata -- ... Dependencies: cam1 [contains your favourite kevlar for baba in cam1 mod] -- data/mp_base/.metadata -- ... Dependencies: base -- data/mp_cam1/.metadata -- ... Dependencies: mp_base, cam1 Loading cam1_kevlarbaba results in this dependency tree: cam1_kevlarbaba - cam1 - cam_base - base PhysFS mounts look the same. Loading mp_cam1 is a bit more interesting: mp_cam1 - mp_base - base - cam1 - cam_base - base PhysFS mounts: mp_cam1 - mp_base - cam1 - cam_base - base (You get that by adding the last Depdendecies first, in case the module depends on more than one other.) This would mean the user has to take care, that modules he depends on are listed in the correct order. If he would want mp_base to override cam_base but not cam1, he would have to give this input: Dependencies: cam1, mp_base, cam_base This is a quick and dirty thought, and an even more quick and dirty example, so please be nice to me. ;) But currently I think this direction will take us somewhere in the end. (Even if the current proposal has rough edges or may not be userfriendly enough in some parts.) --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Proposal for warzone data sets
Am Freitag, 11. April 2008 21:15:23 schrieb Dennis Schridde: Am Freitag, 11. April 2008 20:30:18 schrieb Per Inge Mathisen: On Fri, Apr 11, 2008 at 8:12 PM, Dennis Schridde [EMAIL PROTECTED] wrote: Can you then please explain The only difference is actually a small but important restriction: You can only add a data set on top of another if it lies underneath it in the file system hierarchy. and the surrounding paragraph? Let me try to put it another way: The restriction is that the data set has to be a child directory of the last data set selected. What benefit do we gain from that? The effect is the same as if you use physfs to mount the selected directory and add it to the end of the physfs path list. Why not do that, if it is the same? You can no longer select a data set which does not work against the parent data set. Why can I not do that with your approach? And why is this a specific problem of the old approach? My idea would be: data/ data/base/ data/base/.metadata data/cam_base/ data/cam_base/.metadata data/cam1/... data/cam1/.metadata data/mp_base/... data/mp_base/.metadata data/mp_cam1/... data/mp_cam1/.metadata ... represents an arbitrary amount of files and folders The .metadata files could look like this -- data/base/.metadata -- MetadataVersion: 1 Name: Base Description: Files common to all modules Version: 2.1 Author: WZR License: GPL2 Dependencies: [data/base/ would contain the very elementary things, like frontend images, etc] -- data/cam_base/.metadata -- ... Dependencies: base [data/cam_base/ contains stuff common to all campaigns, like basic AI] -- data/cam1/.metadata -- ... Dependencies: cam_base -- data/cam1_kevlarbaba/.metadata -- ... Dependencies: cam1 [contains your favourite kevlar for baba in cam1 mod] -- data/mp_base/.metadata -- ... Dependencies: base -- data/mp_cam1/.metadata -- ... Dependencies: mp_base, cam1 Loading cam1_kevlarbaba results in this dependency tree: cam1_kevlarbaba - cam1 - cam_base - base PhysFS mounts look the same. Loading mp_cam1 is a bit more interesting: mp_cam1 - mp_base - base - cam1 - cam_base - base PhysFS mounts: mp_cam1 - mp_base - cam1 - cam_base - base (You get that by adding the last Depdendecies first, in case the module depends on more than one other.) Another reason why it looks like that is that PhysFS will not mount a directory again if it is already mounted. signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
