Page 1 of 1

More export filename flexibility.

PostPosted: Wed Nov 15, 2006 2:03 am
by aeyr
Two things:

1. Allow '.' in filenames. Currently, this generates an error if I try to export, say, Foo.Bar.png.

2. Allow a customization of the X/Y coordinate formatting in exported filenames. Perhaps make this pattern based or something: E.g. "{name}-{x}-{y}.{ext}".

PostPosted: Wed Nov 15, 2006 3:05 am
by Aaron
Hi Aeyr,

1. Allow '.' in filenames.


In some ways that's not a huge change, as I just have to slightly modify the file_GetExt function to call itself recursively. This will then parse filenames down to the very last extension. Note in some cases I use double-extensions like '.def.xml' and '.ini.xml', which is why I return the 'whole' extension. Furthermore file_GetExt doesn't consider dots in the full path name to be parts of the extension, so you can have dots in directory names, just not extras in the name of the file itself.

The only risk in this change is that L3DT uses '.' to delimit nested members in lists, much in the same way as it delimits nested members in structs/classes in C/C++. If I use a filename as a variable name anywhere (and I might, having first called file_GetFilenameNoExt to strip the extension), then changing this behaviour could leave a dot in the variable name, which is going to cause errors. In any case, I'm sure I can change things such that map_LoadFile/SaveFile will accept filenames with dots in them, but I'll have to tread a bit carefully in doing so.

2. Allow a customization of the X/Y coordinate formatting in exported filenames.


I think that's on the to-do list somewhere. It's half-implemented in L3DT, but I kind of lost enthusiasm when I started to enumerate the possible combinations (a bad approach.) Instead I guess I'll use a string-based approach such as you suggest.

Cheers,
Aaron.