Am Freitag, 11. April 2008 20:30:18 schrieb Per Inge Mathisen:
> On Fri, Apr 11, 2008 at 8:12 PM, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> >  Can you then please explain
> >
> > > 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.
> >
> >  and the surrounding paragraph?
>
> Let me try to put it another way: The restriction is that the data set
> has to be a child directory of the last data set selected.
What benefit do we gain from that?

> The effect 
> is the same as if you use physfs to mount the selected directory and
> add it to the end of the physfs path list.
Why not do that, if it is the same?

> You can no longer select
> a data set which does not work against the parent data set.
Why can I not do that with your approach? And why is this a specific problem 
of the old approach?

My idea would be:
data/
data/base/
data/base/.metadata
data/cam_base/
data/cam_base/.metadata
data/cam1/...
data/cam1/.metadata
data/mp_base/...
data/mp_base/.metadata
data/mp_cam1/...
data/mp_cam1/.metadata

... represents an arbitrary amount of files and folders
The .metadata files could look like this
-- data/base/.metadata --
MetadataVersion: 1
Name: Base
Description: Files common to all modules
Version: 2.1
Author: WZR
License: GPL2
Dependencies:
[data/base/ would contain the very elementary things, like frontend images, 
etc]
-- data/cam_base/.metadata --
...
Dependencies: base
[data/cam_base/ contains stuff common to all campaigns, like basic AI]
-- data/cam1/.metadata --
...
Dependencies: cam_base
-- data/cam1_kevlarbaba/.metadata --
...
Dependencies: cam1
[contains your favourite kevlar for baba in cam1 mod]
-- data/mp_base/.metadata --
...
Dependencies: base
-- data/mp_cam1/.metadata --
...
Dependencies: mp_base, cam1

Loading cam1_kevlarbaba results in this dependency tree:
cam1_kevlarbaba -> cam1 -> cam_base -> base
PhysFS mounts look the same.

Loading mp_cam1 is a bit more interesting:
mp_cam1 -> mp_base -> base
        -> cam1 -> cam_base -> base
PhysFS mounts:
mp_cam1 -> mp_base -> cam1 -> cam_base -> base
(You get that by adding the last Depdendecies first, in case the module 
depends on more than one other.)

This would mean the user has to take care, that modules he depends on are 
listed in the correct order.
If he would want mp_base to override cam_base but not cam1, he would have to 
give this input:
Dependencies: cam1, mp_base, cam_base

This is a quick and dirty thought, and an even more quick and dirty example, 
so please be nice to me. ;)
But currently I think this direction will take us somewhere in the end. (Even 
if the current proposal has rough edges or may not be userfriendly enough in 
some parts.)

--Dennis

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

_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Reply via email to