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? - Per _______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
