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 principle? --Dennis
Description: This is a digitally signed message part.
_______________________________________________ Warzone-dev mailing list Warzonefirstname.lastname@example.org https://mail.gna.org/listinfo/warzone-dev