Dennis Schridde schreef: > Currently we have: warzone.wz, which contains the basic stuff and the > campaign > data. And mp.wz which contains differences for multiplayer games. > I would like to change the naming to better work out those differences. > > My current ideas: > - base.wz: Contains the stuff needed by everything > - cam(paign).wz: Contains just the campaign relevant things > - m(ulti)p(lay).wz: Contains just the multiplayer relevant data > > I think that would make it clearer for modders where which files can be > found, > what is relevant for what types of mods, etc.
Sounds good to me, and I agree that this'll most likely be easier to understand for others (modders included). Obviously this would imply that mp.wz can be renamed to multiplay.wz (or kept the same?). And warzone.wz would have to be split into campaign.wz and base.wz. > In addition to that, I would propose stackable mods (mods can have 0 or 1 > dependencies, which they are stacked upon). Means: If I want to do a mod > which replaces a few textures, I stack on base.wz, which ensures that (a) > when I am mounted, base.wz is in PATH, too, and (b) that I am located before > base.wz in PATH. > To support that I would add a metadata file for each .wz, which contains > basic > information like on what it is stacked (falling back to base.wz if missing). > Additionaly, we could provide fields for authors, email, web-address, > license, > and possible scripts to run on mount, etc. This approach sounds somewhat like the DEBIAN directory in 'deb' archives, and I like the simplicity of that. So I suggest that for such a meta-data system we use a similar approach. I.e. putting the package dependencies, descr, etc. in a single file in a meta-data directory (e.g. WZ) alongside with preinst/postinst and prerm/postrm scripts (i.e. the "mount scripts" you mention above) perhaps. > I've noticed some rumors about wrf-less mods, which could maybe be done in > one > run with this. I would like to get a proposal for how this could work, for > which filetypes (if not all), about flexibility and other impacts, etc. A possible method of implementation would be by using some kind of "dependency walker" which, for example when loading a PIE model checks whether the given texture page is loaded already, if it isn't it'll load the texture page before continuing. -- Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
