#gemrb@irc.freenode.net logs for 31 Jan 2012 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:16:04] <gembot> build #93 of osx-xcode-binary is complete: Exception [6exception upload_1] Build details are at http://buildbot.gemrb.org/builders/osx-xcode-binary/builds/93 blamelist: avenger_teambg@sourceforge.net
[00:33:19] --> brad_a has joined #gemrb
[00:40:07] <brad_a> tomprince: i think we ought to change the flag on the buildbot command from "release" to "Debug" except when building for stable releases.
[00:54:28] --> mrugiero has joined #gemrb
[00:56:22] <-- mrugiero has left #gemrb
[01:03:41] <-- Baldurer has left IRC (Ping timeout: 276 seconds)
[01:04:39] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[01:27:04] <-- kettuz has left IRC (Quit: Leaving)
[01:29:09] <brad_a> i dont understand how to use INIImporter...
[01:29:20] <brad_a> namely what a "tag" is
[01:30:05] <brad_a> oh
[01:30:12] <brad_a> ok [whatever] is a tag
[01:30:13] <brad_a> right?
[02:25:26] <-- exultbot_ has left IRC (signing off...)
[02:26:41] --> exultbot has joined #gemrb
[02:26:41] --- Topic for #gemrb is: GemRB 0.7.0 | http://gemrb.org | Be wary of your words for there are Modron sensors in this channel: http://log.usecode.org/gemrblog.php | Hey <CHARNAME>, we need some awesome screenshots! | import pdb; pdb.set_trace()
[02:26:41] --- Topic for #gemrb set by lynxlynxlynx!~quassel@sourcemage/warlock/lynxlynxlynx at Fri Dec 30 14:46:00 2011
[02:53:29] --> mrugiero1 has joined #gemrb
[03:09:45] --> mrugiero has joined #gemrb
[03:11:43] <-- mrugiero1 has left IRC (Ping timeout: 276 seconds)
[03:13:26] <brad_a> um is autopause set in baldur.ini?
[03:15:01] --> mrugiero1 has joined #gemrb
[03:17:34] <-- mrugiero has left IRC (Ping timeout: 276 seconds)
[03:18:34] --> Hellcommander has joined #gemrb
[03:18:59] <-- mrugiero1 has left #gemrb
[03:22:28] --> mrugiero has joined #gemrb
[03:23:52] <-- mrugiero has left #gemrb
[03:24:08] <Hellcommander> anyone find the cause of the problems with my gemrb install?
[03:24:58] <Hellcommander> thanks for the work on gemrb btw
[03:28:44] --> mrugiero1 has joined #gemrb
[03:28:46] <-- mrugiero1 has left IRC (Client Quit)
[03:29:47] <brad_a> i dont think anybody has gotten around to looking
[03:30:29] <brad_a> but i am currently authoring a patch that should make it easier for you
[03:31:03] <-- gembot has left IRC (Remote host closed the connection)
[03:33:22] <Hellcommander> still messed up :(
[03:33:36] <Hellcommander> can't go in inventory without crashing
[03:33:51] <tomprince> Hellcommander: You got or diagnosis earlier.
[03:33:52] <Hellcommander> thanks
[03:34:26] <Hellcommander> I can make another log file if you need
[03:34:47] <tomprince> If it doesn't show anything different, it won't make a difference.
[03:35:01] <tomprince> Can you give us a log of a working session with an unmodded game?
[03:36:22] <Hellcommander> I'll start a wildmage on bg2 just to test for you
[03:36:38] <Hellcommander> with my clean install folder
[03:39:49] <brad_a> tomprince: i cant seem to figure out how to make a std::pair<char*, int>
[03:39:58] <brad_a> i suppose i should use sdt::string?
[03:40:11] <tomprince> make_pair
[03:40:15] <tomprince> But, what are you doing.
[03:40:48] <brad_a> that. :-P -> std::make_pair("3D Acceleration", 0),
[03:41:06] <tomprince> You have a const char*
[03:41:35] <brad_a> well i changed it to std::string and it still doesnt work
[03:42:38] <brad_a> but now i think the problem is later on...
[03:43:00] <brad_a> heh
[03:43:09] <brad_a> im silly i had my map parameters reversed :_P
[03:43:36] <brad_a> yet i was getting errors about std::pair and not the map
[03:43:45] <brad_a> c++ errors are so hard for me to understand!
[03:44:09] <tomprince> I don't know if there is a cast for pair<char*,int> to pair<string,int>
[03:44:29] <tomprince> Unfortunately, there isn't overloading based on return type
[03:44:56] <tomprince> (Which you do get in things like ocaml and haskell)
[03:45:16] <brad_a> no my std::pair errors were because i had the map params mixed "whatever" will get turned into std::string magically
[03:45:31] <brad_a> as long as i declare my pair as such of course
[03:46:04] <brad_a> of course i may go const char* since thats what i will need later...
[03:46:20] <tomprince> Yes, but make_pair("str", 5) will be of type pair<const char*, int> which won't change.
[03:47:32] <brad_a> i guess i should have specified that im making a pair array and the declaration of std::string in the array makes the {make_pair("str", 5)} into std::string
[03:47:38] <brad_a> unless thats not standard
[03:47:47] <brad_a> then i should avoid that before i break msvc++ again
[03:48:51] <tomprince> I don't know if there is a conversion, that comes standard.
[03:49:01] <tomprince> I guess it is reasonable for there to be.
[03:57:59] <Hellcommander> how can I enable wildmages for elfs in gemrb
[03:58:16] <Hellcommander> what override file do I edit
[03:58:57] <brad_a> im not sure. it may be benificial for you to post on the forums or come back while the europeans are awake :)
[03:59:24] <Hellcommander> elfs can be wildmages in bg2 by defualt but with gemrb they can't
[04:00:10] <Hellcommander> that might be a little to late for even me I live in Maryland
[04:00:45] <Hellcommander> might be morning for them though lol
[04:01:14] <Hellcommander> it's 11:01 PM here
[04:03:33] <Hellcommander> sorry can't help you much with any copy c++ just not my thing (even though I had a c++ class when I was in high school)
[04:03:53] <Hellcommander> - the copy lol
[04:07:33] <brad_a> tomprince: i cant seem to figure out how to iterate a map within a map
[04:07:35] <brad_a> for( std::map<const char*, std::map<const char*, int> >::const_iterator iter = iniVarMap.begin();
[04:07:35] <brad_a> iter != iniVarMap.end(); ++iter )
[04:07:51] <brad_a> wont compile
[04:09:05] <brad_a> and google is being unusually quiet about it :-/
[04:11:18] <brad_a> i guess maybe something with pair instead?
[04:23:23] <Hellcommander> crash on char gen on the color dark red lol
[04:23:54] <brad_a> or maybe i need a map of map pointers instead?
[04:24:08] <Hellcommander> don't see anything in error log oddly enough
[04:24:21] <Hellcommander> not any error anyway
[04:24:39] <Hellcommander> want me to paste log
[04:25:28] <Hellcommander> http://paste.debian.net/154134 is the log
[04:26:22] <tomprince> Well, so stop trying to get the modded game to work, until the unmodded game works.
[04:26:43] <Hellcommander> thats the clean install lol
[04:27:40] <tomprince> Yes, so that needs to be fixed (which I don't have time for now), but until it is, it wastes everybodys time trying to figure out why the modded game doesn't work.
[04:28:43] <Hellcommander> ill see if I can reproduce crash
[04:32:01] <brad_a> arg i finally figured out i can just type def stuff to make the compiler happy
[04:59:45] <Hellcommander> encountered a looping sound bug when loading save lol
[05:05:10] <brad_a> i kinda doubt it considering you havent really gotten it to run
[05:05:20] <brad_a> which is weird considering all the other windows users
[05:07:01] <Hellcommander> I see why it crashes when the dark red pallet is clicked on, Its becuase its blacked out on the customize option
[05:08:15] <Hellcommander> crash was caused by clicking on a invalid pallet from what I can see
[05:14:42] <-- Dude-X_ has left IRC (Ping timeout: 255 seconds)
[05:15:02] <brad_a> that wouldnt suprise me
[05:15:10] <brad_a> i doubt those have been tested in a long time
[05:15:20] --> Dude-X_ has joined #gemrb
[05:15:28] <brad_a> have you tried the stable 0.7.0 code?
[05:25:35] <Hellcommander> is it normal for character that is polymorped to be at half health (never used polymorph spell when I first played the game maybe 2 years ago
[05:29:36] <-- Hellcommander has left IRC (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
[05:30:23] <brad_a> yes i think that may be normal
[05:35:44] <-- kamui has left IRC (Ping timeout: 272 seconds)
[05:39:10] --> kamui has joined #gemrb
[05:39:14] <-- kamui has left IRC (Read error: Connection reset by peer)
[05:39:41] --> kamui has joined #gemrb
[05:39:46] <-- kamui has left IRC (Read error: Connection reset by peer)
[05:40:32] --> kamui has joined #gemrb
[05:40:41] <-- kamui has left IRC (Read error: Connection reset by peer)
[05:41:03] --> Hellcommander has joined #gemrb
[05:42:25] <Hellcommander> I can't use the binary that you have up for 0.7.0 since by paths to python are different
[05:42:52] <Hellcommander> I'll use the source you have on source forge though
[05:52:51] <-- Hellcommander has left IRC (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
[06:00:55] <nutron> bg1, bg2, and iw1 support but no iw2 right?
[06:01:10] <nutron> err icewind dale 1 =)
[06:01:23] <tomprince> iwd2 is actively being worked on.
[06:01:25] <nutron> tried sounding l33t there. Pardon me.
[06:01:45] <nutron> Ok, is it playable-ish?
[06:02:13] <tomprince> I don't know, I just watch the commits scrolling by here.
[06:03:13] <tomprince> bg1/2 and iwd1 are certainly the most playable.
[06:11:28] --> gembot has joined #gemrb
[06:17:35] <-- brad_a has left IRC (Quit: brad_a)
[06:17:41] <-- gembot has left IRC (Remote host closed the connection)
[06:18:26] --> gembot has joined #gemrb
[06:50:40] <nutron> ps:t?
[07:27:18] --> lynxlynxlynx has joined #gemrb
[07:27:18] <-- lynxlynxlynx has left IRC (Changing host)
[07:27:18] --> lynxlynxlynx has joined #gemrb
[07:27:18] --- ChanServ gives channel operator status to lynxlynxlynx
[08:06:56] <fuzzie> nutron: still in-progress
[08:15:20] --> edheldil_ has joined #gemrb
[08:25:46] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[08:30:27] --> edheldil_ has joined #gemrb
[08:42:33] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[08:51:01] <-- wrotek has left IRC (Ping timeout: 276 seconds)
[08:56:24] <edheldil> hello!
[08:56:38] <cj_schnell> Mornin'!
[09:41:20] --> Baldurer has joined #gemrb
[10:17:57] --> SiENcE has joined #gemrb
[11:29:17] --> kettuz has joined #gemrb
[11:38:11] <cj_schnell> edheldil: I saw on the forum that you are hunting for a manifest for BG1 without TotSC. Can I help out, or is this for a specific install?
[11:39:42] <cj_schnell> Non-GOG version I presume
[12:28:17] <edheldil> cj_schnell: non-specific. I collect them for the theoretical case they come useful or someone tries to write linux installer again. If you are willing to provide some, more power to you. Just please include filesize as well
[12:31:58] <cj_schnell> Ok, I'll get on it.
[13:02:08] <cj_schnell> BG1 Manifest (w/o TotSC): http://pastebin.com/r7x6d1n4
[13:02:36] <cj_schnell> BG1 Baldur.ini (w/o TotSC): http://pastebin.com/3Wy2yCKF
[13:06:02] <cj_schnell> Chitin.key contains paths to the data folder, i.e data\AREA400X.bif
[13:41:15] --> demitar has joined #gemrb
[14:44:39] <edheldil> thanks
[14:44:59] <cj_schnell> No problem.
[14:45:13] <cj_schnell> Just let me know if you need anything else.
[15:03:38] <-- demitar has left IRC (Quit: Ex-Chat)
[15:25:05] <-- kettuz has left IRC (Quit: Leaving)
[16:39:35] --> joneirik has joined #gemrb
[17:18:59] --> Kiranos_ has joined #gemrb
[17:19:19] <-- Calchan has left IRC (Ping timeout: 276 seconds)
[17:20:39] --> fuzzie_ has joined #gemrb
[17:24:50] <-- fuzzie has left IRC (Ping timeout: 244 seconds)
[17:24:51] <-- Dude-X_ has left IRC (Ping timeout: 240 seconds)
[17:24:51] <-- Kiranos has left IRC (Ping timeout: 240 seconds)
[17:25:21] --> Dude-X_ has joined #gemrb
[17:33:33] --> edheldil_ has joined #gemrb
[17:38:58] <-- SiENcE has left IRC (Quit: @all: cya)
[17:40:54] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[17:45:17] --> maighstir has joined #gemrb
[17:46:40] --> Calchan has joined #gemrb
[18:34:09] <CIA-36> GemRB: 03avenger_teambg * r4ef3f51f844c 10gemrb/gemrb/core/Inventory.cpp: fixed critical hit aversion (the flag is in the item header, not in the extended header)
[18:34:10] <CIA-36> GemRB: 03avenger_teambg * r822ec3f4d46a 10gemrb/gemrb/ (core/Item.h plugins/ITMImporter/ITMImporter.cpp): use dexterity flag hacked into item
[18:38:52] --> Avenger has joined #gemrb
[18:39:11] <Avenger> help, what's wrong with this line if ( !(flag&IE_ITEM_TOGGLE_CRITS) != (i==SLOT_HEAD) ) return true;
[18:39:27] <Avenger> it says: comparison between signed and unsigned integer expressions
[18:39:33] <Avenger> but i'm comparing 2 bools
[18:40:42] <wjp> i and SLOT_HEAD maybe? (without looking closely)
[18:41:10] <Avenger> !(flag&IE_ITEM_TOGGLE_CRITS) vs. (i==SLOT_HEAD)
[18:41:14] <Avenger> ahh
[18:41:16] <Avenger> i see
[18:41:18] <Avenger> ok
[18:41:41] <Avenger> true
[18:41:55] --> brad_a has joined #gemrb
[18:42:02] <Avenger> i didn't suspect that, because it was around earlier
[18:42:56] <brad_a> Avenger, lynx, fuzzie, tomprince: part 1 of my proposed loading changes: http://dl.dropbox.com/u/13866402/iniload.patch
[18:42:58] <Avenger> i messed up the commit again with some last minute change :)
[18:44:00] <CIA-36> GemRB: 03avenger_teambg * rfcffaec2ca2b 10gemrb/gemrb/core/ (Inventory.cpp Scriptable/Actor.cpp): weapon finesse, fixed critical hit aversion
[18:46:31] <brad_a> heh i accidentally left strcpy(iniStream->originalfile, filename); in there
[18:48:07] --> kingron has joined #gemrb
[18:48:30] <Avenger> brad: std pair --> EEEEK
[18:48:47] <Avenger> just how much std:: we use?
[18:48:47] <brad_a> thats bad?
[18:48:53] <brad_a> oh heh
[18:48:54] <Avenger> yeah, std is so weird
[18:49:07] <Avenger> i'm looking at the iwd2 source
[18:49:11] <brad_a> well its only for the scope of the function
[18:49:15] <brad_a> the map i mean
[18:49:16] <Avenger> std stuff is totally bloated
[18:49:52] <Avenger> it is full with thread handling and refcounts and crap
[18:50:28] <Avenger> i'm just talking about iwd2's string handling (actually they store mere resrefs in these)
[18:51:04] <Avenger> just the base 'simple string' structure is 16 bytes (resref is 8), and then it just points to a string.
[18:51:15] <tomprince> if (!IsAvailable) { error; return }, instead of adding an extra level of indent. same with if (inistream)
[18:51:29] <brad_a> well im not using any of the std stuff for permanant purposes there
[18:51:31] <Avenger> yeah, reducing indents is cool
[18:51:43] <brad_a> ok :-P
[18:52:51] <Avenger> hmm, those 'std simple strings' maybe more than 16 bytes, 32 is more like it...
[18:53:08] <Avenger> anyway, i guess an std pair has 2 of those?
[18:53:40] <Avenger> oh ok, it is just const char and int
[18:53:48] <brad_a> yes :)
[18:54:14] <tomprince> std::pair<T,S> is just stuct { T t; S s; } essentially.
[18:54:38] <tomprince> Actually, potentially smaller, if either T or S is empty.
[18:54:54] <Avenger> anyway, i would rather reduce the ini stuff than bloat it. Usually i just need the ini settings in a static variable global to the module (in good old C style)
[18:55:07] <brad_a> none of the std stuff lves outside the function… does it matter?
[18:55:08] <Avenger> that's faster than always looking it up
[18:55:19] <Avenger> hmm... ok
[18:55:51] <Avenger> though... i still wonder if every silly platform that tries to compile gemrb can do it
[18:56:05] <brad_a> if anything this reduces size since it only loads what we ant from the ini
[18:56:33] <Avenger> but we don't know what we want :(
[18:56:46] <Avenger> there are 5 games
[18:57:00] <brad_a> well true but i loaded everything we were using (i think) and threw in some stuff i think we should and i could easily implement
[18:57:04] <Avenger> we want all tiny bits currently we don't support
[18:57:22] <Avenger> because eventually, we want to write this stuff back
[18:58:15] <Avenger> i don't want to corrupt (leave out a key) from the user's ini file, even if we don't use some option
[18:58:56] <brad_a> i think it would be easy for me to write coe to merge our vars and keep what is in their ini that we dont have
[18:59:15] <Avenger> ok
[18:59:32] <brad_a> unless we want to be writing out a while bunch it shouldnt be a problem
[18:59:37] <brad_a> whole
[19:00:38] <Avenger> i think we will need to write a setting when the user leaves the options submenu
[19:01:05] <Avenger> at that point it is about 10-15 fields, i guess
[19:01:15] <Avenger> most of those are not changed
[19:02:36] <brad_a> im not too worried about a bit of temporary overhead for that situation
[19:03:06] <tomprince> Avenger: Have you actually tested, to see if there really is a performance hit? Certainly, there is more code, and as I was discussing with fuzzie, std::string is somewhat ineffecient, for backwards-compatibility reasons. But does it have a *measureable* impact?
[19:04:04] <Avenger> it is not performance issue
[19:04:21] <Avenger> it is just the internal ugliness plus compatibility
[19:04:42] <Avenger> the ini file handler doesn't need to be a super optimised code
[19:05:48] <brad_a> im not big in c++ so i dont know what to say about compatibility
[19:05:54] <brad_a> but we use maps other places iirc
[19:07:19] <Avenger> brad: always against my will :)
[19:07:44] <Avenger> i try to keep the number of these things low, and the codebase close to simple c
[19:08:11] <tomprince> And I don't. :)
[19:08:24] <Avenger> we had some problem earlier, with someone implementing the openal plugin with some weird embedded class
[19:08:29] <brad_a> i do too (sometimes to the chagrin of tomprince :-P) but in this case it would take much more code in c
[19:08:33] <Avenger> it didn't compile even on msvc :)
[19:08:37] <brad_a> heh
[19:09:57] <tomprince> I do try to keep most of the code straightforward, and wrapping uglyness in simple to use wrappers.
[19:10:31] <brad_a> im curious why msvc couldnt compile
[19:11:05] <tomprince> msvc6 is pre c++-98
[19:11:16] <tomprince> So, doesn't support quite a few things.
[19:12:05] <tomprince> Especially related to member templates, and template overloads.
[19:12:10] --> kettuz has joined #gemrb
[19:12:49] <fuzzie_> my main annoyance about templates is that they are incredibly inefficient wrt compile/link times
[19:13:24] <brad_a> suggestions?
[19:13:28] <brad_a> rewrite in c?
[19:13:29] <fuzzie_> i think that patch is really hideous though
[19:13:42] <brad_a> i thought you suggested using a map :-P
[19:14:03] <fuzzie_> map or hashmap isfine
[19:14:09] <fuzzie_> the array of pairs is hideous :)
[19:15:18] <brad_a> what would you do?
[19:15:39] <tomprince> Write it in c++11?
[19:15:43] <tomprince> :P
[19:15:45] <brad_a> heh
[19:15:48] <brad_a> i thought about that
[19:16:01] <fuzzie_> well I'm not quite sure what all the code is tryin to do
[19:16:24] <brad_a> well you said to whitelist what we wanted from the ini
[19:16:24] <Avenger> fuzzie: the array of pairs keeps the original order, at least
[19:17:02] <Avenger> i still think we'll be handling more options than we know, and i don't want to list all of them in the code
[19:17:04] <fuzzie_> i mean
[19:17:10] <tomprince> That array of pairs is simply to initialize the map.
[19:17:12] <fuzzie_> why isn't it just using a struct?
[19:17:31] <Avenger> it would be much better to just load everything that is there, then use what we need
[19:17:38] <brad_a> well maybe i dont know much about c++??? :D
[19:17:54] <fuzzie_> Avenger: what I suggested is that we keep the INIImporter there, so we preserve all the fields
[19:18:06] <fuzzie_> and then we have a whitelist of the integer variables which we want to load
[19:18:18] <fuzzie_> so that we don't destroy strings in the original file by trying to handle them as ints.
[19:18:29] <Avenger> yeah, that's a good idea ;)
[19:18:44] <fuzzie_> and I guess this is a first step towards that
[19:18:47] <tomprince> Well, so you can probably use { ,} to intialize the array of pairs.
[19:19:19] <Avenger> uuugly :)
[19:19:22] <fuzzie_> in pre-standard C++?
[19:19:24] <brad_a> well it sounds like we still want to load everything i guess
[19:19:40] <Avenger> my c can't even handle {}
[19:19:42] <fuzzie_> well, there's a difference between 'load' and 'load into vars'
[19:19:53] <fuzzie_> and the theory here is just fine for 'load into vars'
[19:20:01] <tomprince> I'd guess so. std::pair is a POD, so struct style intialization should work?
[19:20:05] <fuzzie_> just it doesn't keep the ini importer around so of course it's throwing the rest away, but you can fix that later
[19:20:07] <Avenger> ok, see you people later! I guess fuzzie will defend my stance :D
[19:20:11] <-- Avenger has left IRC (Quit: bye!)
[19:20:26] <fuzzie_> haha. if std::pair is POD then i am unlikely to object :)
[19:20:36] <fuzzie_> argh, ipv6 here is down.
[19:20:48] <fuzzie_> my google!
[19:21:28] <brad_a> im a bit lost as to what it is ishould do i guess
[19:22:10] <fuzzie_> well, i'm not sure it's as bad as you seem to think
[19:22:12] <fuzzie_> i mean, the idea is fine
[19:22:19] <fuzzie_> unless i am missing something
[19:22:29] <brad_a> i think im the one missing something :)
[19:22:48] <fuzzie_> i think avenger probably forgets that these all need to be in the vars for the gui/etc
[19:24:08] <brad_a> i wish we could use c++11 so i could just init with a nested {} structure
[19:24:21] <fuzzie_> does that really not work here?
[19:24:44] <brad_a> it works for when i turn on c++11
[19:24:44] <fuzzie_> i mean, you are using a C-style [] array, and as tomprince says, std::pair is a POD
[19:24:57] <brad_a> well maybe it would for the pairs
[19:25:14] <fuzzie_> maybe the iniOptions[] wouldn't work, but I'm a bit dubious about the value of that anyway
[19:25:21] <brad_a> i was talking about map = {{"thing", 1}, {"otherthing", 2}}
[19:25:33] <fuzzie_> but just because it seems like you actually *increase* the code with the iniOptions[] loop
[19:26:04] <fuzzie_> unrolling it is pretty inelegant but makes things a lot simpler
[19:26:43] <brad_a> so what im doing is right, but i should do it a better way?
[19:26:46] <fuzzie_> well
[19:26:57] <fuzzie_> as usual, I am not in fact the arbiter of all that is good
[19:28:23] <fuzzie_> but I imagine if you construct it like {"Bored Timeout", 0} and just use those arrays of pairs directly in a setting loop, Avenger will be less likely to cast the finger of death by confusion at you
[19:28:28] <brad_a> should we just import everything into vars?
[19:28:40] <fuzzie_> (i.e. get rid of progOptionsMap/gameOptionsMap/iniOptions/iniVarMap entirely)
[19:28:51] <brad_a> sure
[19:29:02] <brad_a> well
[19:29:09] <fuzzie_> well obviously I suggested the whitelist so I am biased..
[19:29:18] <fuzzie_> and imo it is a far better way to do defaults in one place
[19:29:19] <brad_a> well i agree ith the whitelist
[19:29:41] <brad_a> but to get from ini importer i need more than just a key
[19:29:50] <brad_a> unless null suffices for a tag
[19:30:01] <brad_a> and it searches everything and returns the first occurance
[19:30:01] <fuzzie_> well, you can just do two loops, I figured
[19:30:12] <brad_a> ok
[19:30:24] <fuzzie_> right now you have .. 18 lines of code to support your iniVarMap loop
[19:30:50] <fuzzie_> so my theory is that it would be clearer to simply have two loops and to hard-code the std::pair array and tag name for both?
[19:31:01] <fuzzie_> but that theory rather depends on there only being two sections which are used, frankly
[19:31:09] <brad_a> yes
[19:31:33] <brad_a> what about having ini importer accept null for tag and jsut return the first occurance?
[19:31:45] <fuzzie_> that would also make sense, but .. you want to write these to the ini file again
[19:31:50] <fuzzie_> so I think the lists will be required
[19:32:47] <fuzzie_> unless you are happy with it writing incorrect ini files if all the keys aren't present initially
[19:34:05] <fuzzie_> i sort of have an automatic "this should really be a constant global --> argh, global constructors, die evil fiends, die" reaction to this sort of thing due to scummvm
[19:34:16] <fuzzie_> but it is completely irrelevant for gemrb
[19:34:17] --- fuzzie_ is now known as fuzzie
[19:34:25] --- ChanServ gives channel operator status to fuzzie
[19:35:07] <fuzzie> and for a std::pair it is irrelevant anyway
[19:36:36] <fuzzie> so really I'm not sure there's anything to worry about after careful consideration, other than what are frankly readability tweaks..
[19:36:41] <fuzzie> clearly I am letting Avenger down here :)
[19:36:55] <brad_a> :)
[19:39:05] <brad_a> i cant really imagine needing to read more than those 2 ini sections in this way
[19:39:23] <brad_a> i do read from config, but those are all special cases that need to be handled individually
[19:39:39] <fuzzie> well, our coffee machine tripped our circuit breakers, and I am still bringing things back up, so I don't actually have the ini files to look at
[19:41:06] <fuzzie> but if you can convince yourself about it then I think I don't need to look anyway :)
[19:42:25] <brad_a> ill think of something
[19:42:29] <fuzzie> must say that I really prefer having the added levels of indentation, btw
[19:42:45] <fuzzie> just because it's a lot easier to follow control flow at a glance..
[19:42:59] <fuzzie> but clearly tomprince and Avenger think otherwise so I am outvoted :-p
[19:43:00] <brad_a> thats what i think, but we've been outvoded i think
[19:43:10] <brad_a> heh exactly :)
[19:43:22] <fuzzie> hehe
[19:47:30] * wjp votes with fuzzie on that
[19:47:41] <wjp> hiding everything on one line is horrible
[19:47:54] <fuzzie> is there anything you don't vote with me on, nowadays? :)
[19:48:20] <wjp> interesting question
[20:03:50] --> wrotek has joined #gemrb
[20:05:30] --> Beholder has joined #gemrb
[20:05:42] <Beholder> hi all
[20:06:22] --> SiENcE has joined #gemrb
[20:18:18] --> Yoshimo has joined #gemrb
[20:48:46] --> demitar has joined #gemrb
[21:07:10] <lynxlynxlynx> i support you on the indentation one too :)
[21:07:40] <lynxlynxlynx> p(read) > p(write) and all that
[21:11:01] <tomprince> I don't mind identation, except for early exits. :)
[21:12:50] <tomprince> especially, since the code was missing error handling that is obvious with the erarly eixt.
[21:14:04] <brad_a> early exit? the problem was lack of exit other than the return false at teh bottom :-P
[21:15:05] <lynxlynxlynx> and that avenger's combat patch will induce more whitespace noise
[21:15:18] <lynxlynxlynx> it is clearly indented differently in the commit mail
[21:20:23] <tomprince> 'if (!) return' is an early exit.
[21:21:23] <tomprince> that is equivalent to than if () { .............} else { }
[21:21:57] <brad_a> are you not talking about my patch?
[21:22:11] <brad_a> the only return in mine is at the end of the function
[21:22:24] <brad_a> which is a mistake but not an early exit :-P
[21:22:29] <-- wrotek has left IRC (Ping timeout: 240 seconds)
[21:26:19] <tomprince> No, I was suggestint you turn those ifs into early exits, to cut down on the indentation.
[21:27:02] <brad_a> oh i was confused then
[21:27:17] <brad_a> happens a lot :-/
[21:36:52] <-- Yoshimo has left IRC (Quit: Yoshimo)
[21:54:34] --> edheldil_ has joined #gemrb
[21:54:48] <-- demitar has left IRC (Ping timeout: 252 seconds)
[22:02:58] <lynxlynxlynx> ah, that's fine, I thought it was about using single-line if blocks
[22:03:25] <lynxlynxlynx> irc is not for drawing :)
[22:08:47] --> Drakkar has joined #gemrb
[22:09:26] <-- PixelScum has left IRC (Ping timeout: 272 seconds)
[22:09:47] <-- Beholder has left IRC (Quit: Beholder)
[22:41:28] <tomprince> no, not that. :) That's crazy.
[22:44:58] <fuzzie> yeah, that is also what I thought
[22:50:21] <-- kingron has left IRC (Quit: Leaving)
[23:20:18] --> wrotek has joined #gemrb
[23:47:54] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:52:29] <-- SiENcE has left IRC (Ping timeout: 240 seconds)
[23:56:40] --> PixelScum has joined #gemrb
[23:58:21] <-- CIA-36 has left IRC (Ping timeout: 255 seconds)
[23:58:38] <-- Drakkar has left IRC (Ping timeout: 240 seconds)