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 the correct files, arizona cyborgs can have desert camo
> colours, and so on).
> Thoughts?
You mean I may only override files in my module which were already overriden 
by the modules I depend on?

If a module gets a file removed in a future version, all childs may break?

How shall this be verified? Will WZ abort if it finds a module violating that 


Attachment: signature.asc
Description: This is a digitally signed message part.

Warzone-dev mailing list

Reply via email to