[00:45:08] <-- Edheldil has left IRC ("Really?")
[03:27:21] <tomprince> My refactor is ready for testing. And then can be applied.
[03:27:31] <tomprince> Patch at https://sourceforge.net/tracker/index.php?func=detail&aid=2906450&group_id=10122&atid=310122
[03:47:11] <xrogaan> hu ?
[03:47:29] <xrogaan> oh, right, i'm not on the sourceforge channel
[06:00:28] <wjp> tomprince: cool; I'll try to take a look today
[06:19:38] <Gekz> what is it?
[07:39:30] --> barra_desktop has joined #gemrb
[07:58:40] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[09:30:44] <-- |Cable| has left IRC (Remote closed the connection)
[09:43:20] --> barra_home has joined #gemrb
[10:12:48] --> Gekz has joined #GemRB
[10:58:41] <-- barra_home has left IRC ("Verlassend")
[11:12:59] --> lynxlynxlynx has joined #gemrb
[11:12:59] --- ChanServ gives channel operator status to lynxlynxlynx
[11:51:42] <-- tomprince has left IRC (kornbluth.freenode.net irc.freenode.net)
[11:51:42] <-- fuzzie has left IRC (kornbluth.freenode.net irc.freenode.net)
[11:52:46] --> fuzzie has joined #GemRb
[11:52:46] --> tomprince has joined #GemRb
[11:53:17] <-- tomprince has left IRC (kornbluth.freenode.net irc.freenode.net)
[11:55:16] --> tomprince has joined #GemRb
[13:06:22] <-- Forgetful_Lion has left IRC (" HydraIRC -> http://www.hydrairc.com <-")
[13:50:58] --> barra_library has joined #gemrb
[14:08:40] <-- xrogaan has left IRC (Read error: 104 (Connection reset by peer))
[14:44:25] <-- tombhadAC has left IRC (Remote closed the connection)
[15:46:20] <-- barra_library has left IRC ("Verlassend")
[18:02:28] --> Maighstir has joined #gemrb
[18:15:36] <-- Maighstir has left #gemrb ()
[19:23:12] --> barra_away has joined #gemrb
[19:40:03] <-- barra_desktop has left IRC (Read error: 110 (Connection timed out))
[19:49:24] <tomprince> Is there a reason that GemRB seems to prefer creating its own hashtables, rather than using STL containers?
[19:50:15] <fuzzie> are there standard STL hashtables? i thought there weren't
[19:51:21] <tomprince> Not hashtables, but there are associative containers.
[19:51:48] <tomprince> And hashtables are a common extension, with essentially them same interface.
[19:52:00] <fuzzie> well, yes, but 'common extension' means 'it doesn't work everywhere' :_)
[19:52:10] <fuzzie> i can't remember where we use them, whether speed is important or not
[19:53:04] <tomprince> Well, it is in TR1, and C++0x.
[19:53:22] <fuzzie> but people are compiling with ten-year-old compilers :p
[19:54:23] <fuzzie> we *do* use std::map, but i imagine it was avoided on the basis of speed
[19:54:32] <fuzzie> lots of premature optimisation in gemrb
[19:54:54] <fuzzie> but it might also be trying to duplicate original engine behaviour for the variables somehow. don't know.
[19:57:05] --- barra_away is now known as barraAway
[19:57:45] <tomprince> Well, I was just wondering for new maps, whether i should code up my own, or just use STL.
[19:58:42] <tomprince> So, if std::map is already used that answers my question.
[19:58:51] <fuzzie> i think maybe it's a substitute for MFC's CMap, actually..
[19:59:01] <fuzzie> the API looks suspiciously familiar
[20:00:51] <tomprince> Well, there are at least two implementations in GemRB, I didn't want to add a third. :)
[20:10:50] <lynxlynxlynx> std::map is already used
[21:11:43] --> tombhadAC has joined #gemrb
[22:08:05] <tomprince> Is there a list anywhere of all the files in all the games? I would like to treat BMP, PNG, MOS, and PLT all exactly the same, so that you can't ask for any one individually. I was wondering if there are any resource conflicts to doing that, or anything else I should be aware of.
[22:08:23] <fuzzie> do you have all the games?
[22:09:45] <tomprince> I do have a copy of them.
[22:09:55] <fuzzie> you can just run weidu with --list-files for a list
[22:10:01] <fuzzie> http://fuzzie.org/nfs/pst_files.txt being example output
[22:12:00] <fuzzie> i could run it and put them all up for you, but maybe you find it more convenient to run it yourself
[22:16:15] <tomprince> I guess it is a good excuse to install the IWD games.
[22:16:53] <fuzzie> iwd2 and pst are the 'wierder' engine variants where usually the bad things happen
[22:20:49] <lynxlynxlynx> a file list is not good enough for finding real conflicts, as you an only spot name overlap with it
[22:21:35] <lynxlynxlynx> which we know occurs a lot (eg. unused bg1 resources in bg2)
[22:22:40] <lynxlynxlynx> some mos files do really conflict too, since the general framework is the same
[22:23:48] <lynxlynxlynx> or did you mean it in the scope of the same game and different formats? :s
[22:23:50] <fuzzie> well, i assume for the purposes of tomprince's proposal, you only need to know if there are conflicts within a game
[22:24:24] <fuzzie> otherwise i suppose you'd have to extract all conflicting files and compare, and that sounds like no fun
[22:25:25] <lynxlynxlynx> it's not much harder with weidu than just listing them
[22:26:48] <tomprince> Well, for BG2, it looks like the only duplicates are in progtest(|2).bif, a bunch of xr* files.
[22:28:52] <tomprince> None for BG1 or PsT.
[22:29:19] <lynxlynxlynx> xr huh
[22:29:38] <lynxlynxlynx> the biff name sounds suspicious :)
[22:30:23] <tomprince> It is one of the ones that don't exists. :)
[22:41:47] <-- lynxlynxlynx has left IRC (Remote closed the connection)
[23:08:16] --> Forgetful_Lion has joined #GemRB
[23:53:27] --> |Cable| has joined #gemrb