On Sat, Mar 15, 2008 at 12:42:54PM +0100, Jon Daniel wrote:
> Distinguishing the userdata and data will be unnecessary and therefor
> should not be supported.
> The WML preprocessor resource path specification simplifies to:
> - {path} for a resource relative to the global wesnoth base
> - {~/path} for a resource relative to the local package base path
This is a very good idea.
It used to use the following macro to do this :
#define INCLUDE PATH
[EMAIL PROTECTED]/Package_Name/{PATH}}
#enddef
(that macro was undefined at the end of Package_Name.cfg)
Btw how does it work in there rare case you have two files that have the same
path, one relative to the main data directory and one relative to the user data
directory ?
Other than that, i think it would be nice to change a little bit our syntax so
we can distinguish more easily file inclusion from macro inclusion.
Currenlty when you do
{SOMETHING}
you don't know if you include a file called SOMETHING or if you call a macro
with the same name.
Perhaps we should use a leading / instead of just {path} (ie {/path}) to mean
it's a ressource relative to the global wesnoth base so this problem would no
longer exist ?
> Herein the following restrictions to 'path' apply:
> - mut not contain ".." or "./'
> - must not be "."
> - must not start with "/"
> - must not contain whitespaces
> - must not contain antything outside the 7bit ASCII range
> - the resource specified by 'path' should be
> locatable by prepending the appropriate base path to 'path'
How about case-sensitiveness ?
Currently you can design scenarios that work under case-insensitive OS like
Windows, but are broken under case-sensitive OS. It would be nive to have a
common behaviour here.
Does PhysFs deal with this ? (i gave a quick look, but probably too quick)
> The only writable directory will be the userdata directory and all of
> its subdirectories. Add-on packages should not be allowed to write
> outside of their respective add-on package local base path.
I think WML should not be able to write any file...
You're talking about savefile and addons fetch, right ?
> Compressed add-on packages or data directories can be added to the
> search path at any time using PhysFs.
This looks like a nice feature :)
> This thread should not be used to discuss why we should add PhysFs
> or if we should add PhysFs support. If you want todo so please create
> a new thread linking to this one.
--
Benoit Timbert
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
