[00:36:04] <-- wjp has left IRC ("Zzzz...")
[02:04:51] --> Kirben has joined #pentagram
[02:04:51] --- ChanServ gives channel operator status to Kirben
[08:31:30] --- DarkeZzz is now known as Darke
[11:11:43] --> Colourless has joined #Pentagram
[11:11:43] --- ChanServ gives channel operator status to Colourless
[13:24:30] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[14:20:21] --> wjp has joined #pentagram
[14:20:21] --- ChanServ gives channel operator status to wjp
[15:23:51] <wjp> I think I'll go work on conf/ a bit
[15:24:21] <wjp> let's see... required features:
[15:24:38] <wjp> multiple files (including read-only files)
[15:25:13] <wjp> I guess it would indeed be easiest to have a separate tree for each file
[15:25:45] <Darke> *nod* Wasn't there also read-only flags wanted.
[15:25:46] <Colourless> yeah
[15:25:51] <wjp> then we have attributes for each node
[15:26:10] <Darke> And something like a 'write this to a file as soon as it's modified' flag?
[15:26:30] <wjp> hm, that would be tricky as it would require writing partial trees
[15:26:47] <wjp> or you'd have to remember the original value and the current value for each node
[15:27:13] <Darke> Or rather a 'write the entire file as soon as this is modified' flag I'm guessing the original was. Don't know if it was *actually* requested, just a memory. *grin*
[15:28:29] <wjp> multiple files/tree would obviously have an order. Reads are from the last tree containing a node, I guess
[15:28:48] <wjp> and writes would be to the last non-readonly tree?
[15:29:36] <wjp> might be necessary to require write access to the last tree
[15:30:15] <wjp> (otherwise writes could be overridden by nodes in a later tree)
[15:31:05] <wjp> Colourless: you also wanted reference-returning 'get' functions, right?
[15:31:10] <Colourless> yes
[15:31:30] <Colourless> doesnt' matter exactly how it's implemented, but it's a useful feature to have
[15:31:40] <Colourless> the returned references should be read only though
[15:31:41] <wjp> is there a thing such as read-only references?
[15:31:45] <wjp> :-)
[15:31:46] <Colourless> no :-)
[15:32:04] <Colourless> most obvious way is to use a container class
[15:32:27] <Colourless> which then has a get_value() func or similar
[15:32:31] <Darke> Isn't `const string &foo()` returning a const reference?
[15:32:46] <Colourless> hmm, yes i think it would...
[15:33:03] * Darke is pretty sure it is, just half asleep at the moment. *grin*
[15:33:20] <Colourless> references though can be slightly annoying because you can't have them unitialized (for better or for worse)
[15:33:32] <Darke> *noddle*
[15:33:59] <wjp> A& = *((A*)0)? :-)
[15:34:05] <wjp> A& x = ...
[15:34:08] <Colourless> i consider that a 'flaw; in the language
[15:34:19] <Colourless> and *that* is a hack
[15:34:27] <wjp> and an ugly one, at that :-)
[15:34:58] * Darke admits he rarely encounters a 'null reference' being a problem. Even the stl returns special 'not a value' references. He actually considers it to be a *great* benefit of the language. Pointers without the primary disadvantage of them! *grin*
[15:35:43] <wjp> anyway, when we use a container class for them, we could also support writes
[15:39:23] <Colourless> yes indeed, and that is most useful too
[15:41:58] <wjp> ugh, iterating over children of nodes is going to be quite ugly
[15:42:11] <wjp> you'd have to take all the children in all the trees
[15:52:40] <wjp> hm, what exactly would be the use of the delayed-write/immediate-write flag?
[15:52:49] <wjp> (and what should be the scope of such a flag?)
[15:53:36] <Colourless> not that much use
[15:53:38] <Darke> Changes to the configuration settings of the game. Vs changes to other game state. IIRC there were plans to use conf for some of the generic game state stuff.
[15:54:21] <Colourless> the idea is for everything to be delayed-write
[15:54:56] <Colourless> the immediate-write flag/function would act like the exult/old config->set method
[15:55:08] <Colourless> however, that is rather inefficent
[15:55:54] <wjp> immediate-write of a single value?
[15:56:49] <Colourless> yes
[15:57:01] <wjp> will be interesting to implement
[15:57:20] <wjp> we'd need to keep the original values of all nodes, and some way to ignore new nodes
[15:57:53] <Colourless> yes, it would somewhat 'annoying' to code :-)
[15:59:47] <wjp> ok, so let's see... we'll have a basic Configuration class, an (internal) XMLNode class, an (external) ConfigNode/ConfNode/CNode/NodeRef (?) class
[16:01:06] <wjp> any objections to naming the directory 'conf' again?
[16:01:31] <Colourless> no objections here
[16:02:07] <Darke> *wavepaw* Tab completion is a pain when you're competing with the thousands of other 'conf'* stuff in the root directory? *grin* But no, that's really not a 'real' objection.
[16:02:10] <wjp> Darke: is there a difference between the conf from exult and from pentagram/old?
[16:02:32] <wjp> (and if so, which one should I 'borrow' code from? :-) )
[16:02:55] * Darke ponders. Probably not. Maybe do a checksum check to see if they *are* different?
[16:03:28] <Darke> pentagram/old's conf is probably going to spit out less warnings and *might* have a few things fixed in it. But I think I would have backported most of that to exult's.
[16:03:48] * wjp looks at 100's of lines of diff
[16:04:02] <wjp> they're, um, not quite the same :-)
[16:04:47] <Colourless> :-)
[16:05:34] <Darke> Erf. Umm... In which case I've no idea. I'd probably go for pentagram/old's stuff, since I was really the only person touching conf in exult. Probably want to glance over the changelog to see if anything's been touched in exult's recently?
[16:05:50] <wjp> exult's seems newer, somehow
[16:06:01] <Darke> (Where recently==last 6 months or so *grin*)
[16:07:58] <wjp> ah, I added support for custom config files 5 months ago
[16:09:01] <Darke> *grin* Looks like it's probably best to grab exult's then. Like I said mine were mostly bugfixes so they would have been backported.
[16:09:35] <wjp> the things I added will have to be rewritten anyway, so I don't think it matters
[16:09:49] <Colourless> just to be notify everyone, Audio stuff doesn't need to added for a while. The exult Audio code is disgustingly bad, so a complete rewrite is in order
[16:10:26] <Colourless> and since audio isn't a 'vitial' component it can wait a bit
[16:12:43] * Darke seconds Colourless. *grin*
[16:14:13] * wjp isn't planning on touching any audio things
[16:15:14] <wjp> hm, were config files going to be written through the FileSystem?
[16:15:24] <wjp> s/written/accessed/
[16:16:10] <Darke> Yes I think. I'm pretty sure we wanted everything to go through the FS.
[16:16:20] <Colourless> for consistancy they 'should'
[16:16:35] * wjp shudders
[16:16:59] <Darke> Else we need two sets of 'mess with the path/filename/homedir/whatever' stuff.
[16:17:09] * wjp prepares to rewrite most of the I/O code in conf/
[16:17:42] <wjp> although there seems to be string I/O code already. Maybe I'll just use that
[16:17:58] <Colourless> the initial config file that points to where pentagrams data is, will be in constant place
[16:18:36] <Darke> IIRC, it just dumps the entire file into a string and works with that. There really shouldn't be much fileio to mess with.
[16:18:56] <wjp> yes, there should be one or two config files in fixed places
[16:19:22] <wjp> (a system-wide, and a user config file)
[16:19:41] <Colourless> yes
[16:20:45] <Darke> *noddle* And a third game-specific one?
[16:21:09] <Colourless> yes
[16:21:09] <wjp> hm, shouldn't the location of that be specified in one of the first two?
[16:21:32] <Colourless> yeah the game specific ones would be listed in the system wide one
[16:21:38] <Colourless> IMO that is
[16:22:21] * Darke nods. Will probably be implied to be 'somewhere' by a global 'this game dir' variable or something.
[16:22:27] <Colourless> user config file in windows has been something that i've been thinking about a bit. WinNT oses are multiuser aware so i've been thinking that we could chuck the user config into the users profile dir as well as savegames. I've noticed that MaxPayne does that
[16:22:56] <Colourless> (MaxPayne will also use the profile dir in Win9x too)
[16:23:13] * wjp nods
[16:23:24] <wjp> sounds good
[16:23:40] <wjp> I'll remove all path logic from conf/, btw
[16:23:46] <Colourless> will require some system specific code, but i think it's the right way of doing things
[16:24:27] * wjp hmms.. IDataSource/ODS are quite lacking in string I/O functions
[16:24:52] <wjp> Darke: what does conf/ do wrt endlines?
[16:26:03] <Colourless> eventually when required i expand on IDataSource to include things it's missing
[16:26:21] <Colourless> some string I/O functions would be most useful
[16:26:30] <Colourless> depends on how advanced you want to go
[16:28:43] <wjp> just readline and writestring should be enough
[16:29:15] <Darke> wjp: Umm... strips them out like all other spaces, IIRC.
[16:29:19] <Colourless> yeah
[16:29:45] * Colourless was replying to wjp
[16:30:01] <Darke> wjp: Actually, no. It keeps them in in the 'data' area of a tag. That way you can have multiline data in a tag and it'll keep it's formatting when output. I think. *grin*
[16:30:34] <Darke> It should generate an error if it finds something like "<start_of_tag\n>"
[16:30:58] <wjp> does it want \n's or can it handle it any of \r, \n\r, \n?
[16:31:45] <Darke> If you open the textfile as a textfile it handles all of the dos/unix line endings since they're all translated into a stock '\n'.
[16:32:06] <Darke> Doesn't care about anything else, will actually probably strip them out since they're technically a space I think.
[16:32:22] <Colourless> but what happens if you use a dos formatted config file in unix?
[16:33:15] <Darke> The same thing as if you did the reverse.
[16:33:26] <Darke> It's what the standard mandates isn't it?
[16:33:47] <Colourless> not true, windows is quite happy to accept unix formatted text files when opened as ascii
[16:34:22] <Colourless> since the line endings are converted from \n\r to \n, so reading a \n doesn't cause problems
[16:34:45] <Colourless> but i've seen a number of cases when unix programs will die if they counter a \r in a text file
[16:34:56] <Colourless> s/counter/encounter/
[16:34:58] <Darke> And if you open them as text, when it encounters a \n it checks to see if it's got a \r after it and silently 'losses' it. That's the whole point of text isn't it?
[16:35:42] <Colourless> but is that the actual behaviour of the c-library?
[16:36:04] * Darke suggests it's because the programmer was either stupid enough to open a text file as a binary file instead.
[16:36:10] <Colourless> exult (and pentagram) in places were opening binary files as text files, and not showing any ill effects on linux
[16:36:13] <Darke> Yes, I'm almost 100% sure it's the case.
[16:36:22] <Colourless> but would die almost instantly on windows
[16:37:14] <wjp> "the ``b'' is ignored on all POSIX conforming systems, including Linux."
[16:37:19] <wjp> (fopen manpage)
[17:31:41] <-- Colourless has left IRC ("casts invisibility")
[19:08:33] --- Darke is now known as DarkeZzz
[20:39:05] <-- DarkeZzz has left IRC (capek.freenode.net irc.freenode.net)
[20:46:21] --> DarkeZzz has joined #pentagram
[20:46:21] --- ChanServ removes channel operator status from DarkeZzz
[23:37:46] --> Kirben has joined #pentagram
[23:37:46] --- ChanServ gives channel operator status to Kirben
[23:40:29] --> Dark-Star has joined #pentagram