[06:46:58] --- Darke|afk is now known as Darke
[07:14:19] <Darke> wjp: No I wasn't actually. *grin* I was in at work at uni and just committing the stuff I'd written before. *grin*
[07:17:26] <Darke> I wasn't sure if Colourless was going to remove the exceptions or not, since he was trying to get it to complile on the non-standard WinCE C++ compiler. I meant to ask him about it before I commited, but forgot. *grin* That's why it's testing against a null pointer or not.
[07:18:30] <Darke> But yeah, it should be testing against !rawopen() anyway. *grin*
[13:45:08] --- Darke is now known as Darke|afk
[14:04:44] --> Colourless has joined #Pentagram
[14:04:45] --- ChanServ gives channel operator status to Colourless
[14:12:19] <Colourless> attempt to avoid exceptions if possible
[14:16:29] <Colourless> thankyou for your time
[16:17:41] --> wjp has joined #pentagram
[16:17:41] --- ChanServ gives channel operator status to wjp
[16:28:37] <-- Colourless has left IRC ("warcraft iii... one mission left...")
[18:22:43] --> Colourless has joined #Pentagram
[18:22:43] --- ChanServ gives channel operator status to Colourless
[20:39:36] <wjp> Colourless: how did you plan the 'system_path' and/or 'mounting' functionality of the FileSystem?
[20:41:54] <wjp> roughly the same as in Exult? (i.e., replace any 'special' tags by some other directory), or by something more complex (e.g., representing a 'system_path' by a separate FileSystem object)
[20:43:04] <Colourless> ideally it wouldn't have any sort of special tags. it would just be a text string
[20:44:21] <Colourless> at it's simplest it would be like exult, just without the < and >
[20:45:06] <Colourless> something a little more complex, would also allow for a virtual paths that is more that is not in the top level
[20:45:33] <wjp> so the first component of every path would always be 'virtual'? (unless it maybe starts with /)
[20:46:03] <Colourless> no, doesn't have to be
[20:46:26] <Colourless> pentagram would just check the virtual path table to see if that path name wanted has been mapped to something else
[20:46:33] <wjp> wouldn't that give problems with name clashes?
[20:47:55] <Colourless> in theory yes it could, but it we wanted to be really special we could have overriding so pentagram would attempt to read from both locations, virtual path first, and then the real path second.
[20:48:42] <wjp> hm, what exactly would be the advantage over having specially-marked tags?
[20:49:17] <wjp> (either by something like <static>, or maybe by having a separate filesystem root for virtual paths?)
[20:50:16] <Colourless> just a preference thing of mine.
[20:50:58] <Darke|afk> Just a quick question, why would we want to read directly from a 'real' path anyway? *grin* All real paths 'should' be mounted on the vpath, and if it isn't, we can always mount it anyway.
[20:51:24] <wjp> good question :-)
[20:51:50] <Colourless> i tend to agree. it might be an idea to lock the file system
[20:51:54] <wjp> maybe config files? or during game detection?
[20:52:38] <Colourless> default during game detection, but also settable by config?
[20:52:57] <Darke|afk> `mount ~/.pentagram /config` `mount / /gamedetect`
[20:53:40] * wjp hmms
[20:53:49] <Darke|afk> (AddVirtualPath() or whatever. I'm sure you get my meaning. *grin*)
[20:54:12] <wjp> ok, allowing direct path access probably won't be necessary
[20:54:34] <wjp> I'd still prefer virtual paths to 'stand out' from native paths somehow, though
[20:54:37] <Darke|afk> If we don't mount everything as a vpath, it means all our directory/file manipulation routines need to be duplicated. Which would be bad. *grin*
[20:55:32] <Darke|afk> We can always chuck a $ or % or : as the first character of them if we need to make them stand out. *grin*
[20:55:40] <wjp> not necessarily. (re. duplication)
[20:57:19] <wjp> how about mounting a virtual path onto another virtual directory?
[20:57:39] <Colourless> recursion?
[20:58:03] <wjp> this would probably also be how we'd handle zips?
[20:58:13] <Colourless> yes, exactly :-)
[20:58:22] <Colourless> you mount a zip file to the path structure
[20:58:22] <wjp> (oh, as an aside, uwadv is using some kind of transparent zip library; might be nice to check it out)
[20:59:05] <wjp> (it's called...
[20:59:15] <wjp> zziplib)
[21:00:06] * Darke|afk pawwaves and disappears off to work. If you're unlucky (and here in an hour), you may see him again. *grin*
[21:00:33] <wjp> bye :-)
[21:00:40] <Colourless> cya
[21:01:10] <wjp> this would probably mean there would be multiple FileSystem objects, right?
[21:01:46] <wjp> although...
[21:01:48] * wjp thinks
[21:01:53] <Colourless> more with the zip stuff, you would mount a zip (or even multiple zip files if you wanted to be really special) to a single virtual directory name, and we'd search through each zip for the requested file
[21:02:02] <Colourless> na, i would only use a single object
[21:02:25] <wjp> hm, multiple objects on a single mount point?
[21:02:44] <Colourless> yeah
[21:03:03] <wjp> tricky... especially for write support
[21:03:26] <Colourless> well, writing to a zip file isn't exactly going to work well :-)
[21:03:45] <wjp> yeah, we should probably mount zip files read-only :-)
[21:04:12] <wjp> mounting a zip and a 'real' directory on the same v-path should be possible too
[21:04:30] <Colourless> yeah, i actually really would like that
[21:04:40] <Colourless> makes developing new content easier
[21:04:48] * wjp nods
[21:04:50] <Colourless> you don't have to recompress the zip file every time
[21:09:51] <Colourless> well, i should be going
[21:10:01] <-- Colourless has left IRC ("bye")
[21:44:57] <-- wjp has left IRC ("Zzzz...")
[23:03:41] --> darke has joined #pentagram
[23:03:46] <-- darke has left IRC ("*fluff!*")