Am Freitag, 7. März 2008 15:50:39 schrieb Giel van Schijndel: > 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. Yes, that was the plan.
> > 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. (That info could be displayed in a WZMM (Warzone 2100 Mod Manager). > 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'd prefer just referencing a script by path, not providing an own file for it. This keeps it simpler and more flexible. > > 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. That works for how models currently work. It does not work for almost any other kind of file. (Though about that, too. ;) ) And it also does not work if you would like to make models independend from textures. Eg. if you would like to spawn different models, each having an own texture. This gets worse when we go for shaders, etc. Another thing I've been thinking about is translation. The most easy approach would work like this: We can ever only load exactly one mod, and if that mod contains a "/locale/<?>/LC_MESSAGES/*.mo" file, we switch textdomain to the one we found. (We'd need to find a way to feed gettext with our data...) This is an easy approach, because other solutions I thought about were more complicated, eg: - Merging base.wz and <mod.wz> translation would require merging of messages at runtime. - Using "warzone2100" as textdomain for strings originating from original warzone2100 and "<mod>" for strings from the <mod> would require figuring out the origin for every string. - If we would allow more than one mod, we could get into trouble when both provide translations for the same string - etc --DevUrandom
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
