#gemrb@irc.freenode.net logs for 19 Nov 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:00:08] --> brad_a has joined #gemrb
[00:03:35] --> |Cable| has joined #gemrb
[00:11:16] <-- |Cable| has left IRC (Remote host closed the connection)
[00:12:43] --> |Cable| has joined #gemrb
[01:00:19] <-- Yoshimo has left IRC (Quit: Yoshimo)
[02:09:28] <-- brad_a has left IRC (Quit: brad_a)
[02:41:31] <-- Maighstir has left IRC (Read error: Connection reset by peer)
[03:24:47] --> brad_a has joined #gemrb
[03:49:33] --> joneirik has joined #gemrb
[03:51:51] <-- joneirik has left IRC (Remote host closed the connection)
[04:05:35] --> pugvader has joined #gemrb
[04:11:14] <-- pugvader has left IRC (Disconnected by services)
[04:11:52] --> pugvader has joined #gemrb
[04:12:40] --- pugvader is now known as pugvadr
[04:55:23] <-- PixelScum has left IRC (Read error: Connection reset by peer)
[04:55:33] <-- brad_a has left IRC (Quit: brad_a)
[05:06:19] <-- joneirikb has left IRC (Remote host closed the connection)
[05:50:42] --> spike411 has joined #gemrb
[08:09:17] <-- spike411 has left IRC (Quit: Manga & anime pokec na Jabberu: manga.cz@conf.netlab.cz)
[08:55:02] --> lynxlynxlynx has joined #gemrb
[08:55:02] <-- lynxlynxlynx has left IRC (Changing host)
[08:55:02] --> lynxlynxlynx has joined #gemrb
[08:55:02] --- ChanServ gives channel operator status to lynxlynxlynx
[09:30:21] <CIA-44> GemRB: 03lynxlupodian * r42fd14c5c156 10gemrb/gemrb/core/Spellbook.cpp: spellbook: fixed quickspells not working anymore with the new bar
[09:35:43] --> Yoshimo has joined #gemrb
[09:55:16] <-- Yoshimo has left IRC (Quit: Yoshimo)
[09:56:12] --> Yoshimo has joined #gemrb
[10:35:01] <-- pugvadr has left IRC (Quit: leaving)
[10:47:53] <CIA-44> GemRB: 03lynxlupodian * r381865b07735 10gemrb/gemrb/ (7 files in 4 dirs):
[10:47:53] <CIA-44> GemRB: unhardcoded the reckless dweomer into splspec.2da
[10:47:53] <CIA-44> GemRB: also made silence not disable the spell buttons
[11:42:04] <gembot> build #250 of mingw32 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/250
[11:53:54] <gembot> build #269 of msvc++6 is complete: Exception [exception git] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/269 blamelist: lynxlupodian@users.sourceforge.net
[14:44:59] --> edheldil_ has joined #gemrb
[14:49:14] --> D_T_G has joined #gemrb
[14:52:47] <D_T_G> hey!
[14:59:46] <-- D_T_G has left IRC (Quit: D_T_G)
[16:31:00] --> Maighstir has joined #gemrb
[16:32:16] --> brad_a has joined #gemrb
[16:46:52] --> pugvader has joined #gemrb
[16:52:55] <-- edheldil_ has left IRC (Ping timeout: 260 seconds)
[16:58:03] --> SiENcE has joined #gemrb
[17:02:55] --> hanicka has joined #gemrb
[17:11:19] <CIA-44> GemRB: 03lynxlupodian * r45e154d15c3e 10gemrb/gemrb/GUIScripts/ (GUIWORLD.py bg1/GUIWORLD.py bg2/GUIWORLD.py iwd/GUIWORLD.py):
[17:11:19] <CIA-44> GemRB: merged iwd, bg1 and bg2 GUIWORLD
[17:11:19] <CIA-44> GemRB: pst is too different, iwd2 not so viable
[17:29:28] <pugvader> dark matter is cthulhu's pubic hair
[17:35:28] --> Drakkar has joined #gemrb
[17:47:42] <-- SiENcE has left IRC (Quit: cya)
[17:49:37] <lynxlynxlynx> simian reports GUICommonWindows.py 189 times, which is the most mentions of any file
[17:50:18] <lynxlynxlynx> at 1kloc, this should be a pretty effective merge
[17:56:18] <pugvader> good evening good sir lynxlynx
[17:57:23] --> Kiranos_ has joined #gemrb
[17:57:23] <-- Kiranos has left IRC (Read error: Connection reset by peer)
[18:11:53] <lynxlynxlynx> oj
[18:31:20] --> Joshua__ has joined #gemrb
[18:36:07] --> pugvader_ has joined #gemrb
[18:37:19] <lynxlynxlynx> 24 users :O
[18:39:03] <-- pugvader has left IRC (Ping timeout: 240 seconds)
[19:01:26] <Yoshimo> would gemrb hande infinity animations?
[19:01:59] <lynxlynxlynx> you mean that mod?
[19:02:04] <Yoshimo> yea
[19:02:30] <lynxlynxlynx> yes, but i think some issues were reported already
[19:02:36] <lynxlynxlynx> something was pink?
[19:03:27] <Yoshimo> i thought we blamed pink on the extended palettes from 1pp?
[19:04:11] <fuzzie> doesn't it extensively mod the exe?
[19:04:25] <fuzzie> it sure does
[19:04:42] <fuzzie> $ grep -c WRITE_BYTE infinityanimations/patch/t-exe_patch.tpp
[19:04:42] <fuzzie> 19224
[19:05:06] <Yoshimo> whats the 1pp report on that line?
[19:05:13] <fuzzie> much less :P
[19:06:27] <fuzzie> 1pp replaces one pattern at 35 locations, using only a single WRITE_LONG line.
[19:07:26] <lynxlynxlynx> oh, i thought it just added new data
[19:07:32] <tomprince> I think it would envolve modifying avatars.2da and maybe CharAnimations.cpp
[19:07:44] <fuzzie> yes.
[19:07:55] <fuzzie> unfortunately t-exe_patch.tpp *only* contains 19224 WRITE_BYTE instructions.
[19:08:40] <fuzzie> I imagine infinityanimations/documentation/devnotes.txt has sufficient notes to work out what it's doing though.
[19:08:57] <tomprince> I suspect most of that is data tables, or code to parse them.
[19:09:13] <fuzzie> Maybe. Or inefficient moving code around.
[19:09:37] <fuzzie> The animation slot code in the original executable is unfortunately largely hardcoded.
[19:09:46] <fuzzie> As in, big switch tables.
[19:10:01] <fuzzie> Spread across a variety of functions.
[19:11:17] <fuzzie> (Also I imagine anything unclear would probably get an explanation from the original authors, mind.)
[19:23:42] <Yoshimo> the ia textfile says its deleting invalid duplicates of old animations to free space
[19:24:04] <Yoshimo> "Space for these is freed mostly by removing invalid animation duplicates", which would explain the rather big patch
[19:25:14] <fuzzie> there's a *lot* of useless stuff in the new monster animation code which are invalid duplicates of the old monster anim code which is actually used
[19:25:18] <fuzzie> as i imagine i've complained about before
[19:27:25] <lynxlynxlynx> aha
[19:28:13] <fuzzie> but i refer to tomprince's statement above about avatars.2da and CharAnimations
[19:28:29] <fuzzie> i imagine it's easier just to look at what they changed avatars-wise!
[19:28:50] <lynxlynxlynx> much of it should just work
[19:29:42] <fuzzie> and otherwise it'll hopefully be obvious enough.
[19:46:10] <CIA-44> GemRB: 03lynxlupodian * r199f93e4237b 10gemrb/gemrb/GUIScripts/ (3 files in 3 dirs): made GUICommonWindows shared
[19:46:12] <CIA-44> GemRB: 03lynxlupodian * r1bd9eeaab000 10gemrb/gemrb/GUIScripts/bg2/GUICommonWindows.py: merged bg1 GUICommonWindows into bg2
[20:36:34] <-- Joshua__ has left IRC (Quit: Page closed)
[20:42:16] <CIA-44> GemRB: 03lynxlupodian * rac2045fd6588 10gemrb/gemrb/GUIScripts/ (GUICommonWindows.py iwd/GUICommonWindows.py): merged iwd version of GCW into the shared one
[20:47:02] <lynxlynxlynx> 2 files changed, 58 insertions(+), 914 deletions(-) :)
[20:47:15] <-- hanicka has left IRC (Quit: Leaving.)
[20:47:32] <lynxlynxlynx> i thought it would be more annoying, since i already tried once
[20:47:58] <lynxlynxlynx> the problem then was that i started small, trying to share function by function and the core expects them in certain modules
[20:55:11] <brad_a> nice work :)
[20:57:17] <brad_a> while trying to figure out my mysterious crash i think i noticed a problem
[20:57:34] <brad_a> in BIFImporter::OpenArchive
[20:58:29] <brad_a> there is an if..elseif..else and they all delete "file" except for 1
[20:58:33] <fuzzie> yes
[20:58:40] <brad_a> i cant see why tho
[20:58:51] <fuzzie> because all of them create a new file
[20:59:06] <brad_a> then shouldnt they all delete file
[20:59:07] <fuzzie> except the one which isn't compressed, which just returns a copy of the file in the common case
[20:59:19] <brad_a> oh
[20:59:43] <fuzzie> (and CacheStream will delete the passed parameter itself if you're running with SlowBIFs on)
[21:00:16] <fuzzie> compare the signature check there with the sanity-check signature check at the end of the function, if that helps it make sense
[21:00:25] <brad_a> i see
[21:00:27] <brad_a> thank you
[21:00:28] <fuzzie> and feel free to add comments of course!
[21:00:32] <brad_a> ha ha
[21:00:40] <brad_a> maybe i will :)
[21:00:41] <fuzzie> i mean it, if you have any patience to do so
[21:00:46] <brad_a> i will
[21:00:58] <fuzzie> great :)
[21:01:59] <brad_a> maybe i should have joshua try running with slow bifs?
[21:02:13] <fuzzie> i wouldn't advise it - i don't know if SlowBIFs even works
[21:02:21] <brad_a> well it wouldnt matter
[21:02:34] <brad_a> the crash hppens immediately in cachestream
[21:02:38] <fuzzie> and you still hit that Seek first :(
[21:02:40] <brad_a> yes
[21:03:22] <brad_a> and it isnt crashing even in the seek call itself..
[21:03:31] <brad_a> its as if src were null
[21:03:52] <brad_a> in fact i put a test in ther and just if (src) caused a crash
[21:04:07] <fuzzie> that sounds .. bad
[21:04:43] <brad_a> i probably need to examine FileStream::OpenFile
[21:05:19] <brad_a> but i dont see why that would break with a bif and not all the other files
[21:05:50] <brad_a> and clearly its able to read from file into signature
[21:05:52] <fuzzie> random thoughts: extra slashes?
[21:06:06] <fuzzie> there's actually a seek inside OpenFile, so that can't be it
[21:06:08] <brad_a> let me check
[21:06:41] <brad_a> doesnt look like it
[21:06:43] <fuzzie> hm
[21:06:49] <fuzzie> you're not actually running the same binary, are you?
[21:07:04] <brad_a> you mean simulator vs device?
[21:07:08] <brad_a> no
[21:07:36] <fuzzie> in which case: perhaps your _MAX_PATH is different
[21:07:37] <brad_a> but as i said before it works fine when running outside of the sandbox
[21:07:51] <fuzzie> i mean, if the sandbox involves different builds
[21:08:05] <fuzzie> or perhaps just if your sandbox involves very long pathnames, in fact
[21:08:13] <brad_a> oh thats true
[21:08:23] <brad_a> the sndbox path is extremely long
[21:08:50] <brad_a> i wouldnt think long enough to caus ea problem but its work checking
[21:09:19] <brad_a> bif path is 92 chars
[21:09:44] <fuzzie> well, it depends what size _MAX_PATH (or FILENAME_MAX) is on iOS
[21:10:52] <brad_a> chitin.key loads fine and it is 95
[21:11:01] <fuzzie> also you could theoretically encounter problems if you have _MAX_PATH defined during one include but not during another include of course, if FILENAME_MAX differs from _MAX_PATH
[21:12:48] <fuzzie> but, well, 92 chars plus a bif filename could exceed 100? that sounds spectacularly unlikely to be so low though
[21:12:52] <brad_a> ill bet i would have figure it out by now if i had an actuall device to test on
[21:13:04] <brad_a> very frustrating developing without one
[21:13:09] <fuzzie> yes.
[21:13:53] <brad_a> im guessing FileStream is a subclass of datastream?
[21:13:56] <fuzzie> yes
[21:14:41] <Yoshimo> is there something that compares ida databases to see what changed between the 2 original binaries?
[21:14:42] <brad_a> i dont understand how its possible to crash just by referencing src
[21:14:50] <fuzzie> Yoshimo: yes
[21:14:51] <brad_a> without even trying to perform anything on it
[21:16:25] <fuzzie> Yoshimo: turbodiff and patchdiff2 are two free ones
[21:16:32] <fuzzie> neither are much fun to use though.
[21:16:48] <fuzzie> and if you want it for IE they will be useless due to data overload and not being good tools
[21:16:51] <Yoshimo> burden of free tools
[21:17:47] <fuzzie> Google bought Zynamics and now the price of BinDiff is now only $200, which is a *lot* cheaper than it was, but .. Google will only sell to US customers anyway, so sigh.
[21:18:28] <fuzzie> but scummvm people have used both turbodiff and patchdiff2 to spot differences in engine versions.
[21:18:56] <fuzzie> brad_a: yes, it sounds like an underlying corruption bug
[21:19:07] <fuzzie> brad_a: which is why i was thinking of issues with the path sizes as an obvious culprit
[21:19:14] <brad_a> you mean like a buffer overflow?
[21:19:16] <fuzzie> yes
[21:19:30] <brad_a> ime to figure our how to run valgrind in the simulator...
[21:19:34] <brad_a> probably not easy
[21:19:59] <fuzzie> in fact
[21:20:47] <fuzzie> ExtractFileFromPath might be overflowing the class in any case.
[21:21:05] <fuzzie> It's doing strcpy into a 16 byte buffer, admittedly one which *should* have the _MAX_PATH filename directly after.
[21:21:24] <-- Drakkar has left IRC (Ping timeout: 240 seconds)
[21:21:29] <fuzzie> but oh gosh that is a Very Bad Thing
[21:21:35] --> Drakkar has joined #gemrb
[21:22:07] <brad_a> that sounds like a promising culprit tho.
[21:23:27] <Yoshimo> why would google which should be keen on money, cut itself in the finger and not sell to everyone?
[21:23:39] <brad_a> thats what cares me about google
[21:23:54] <brad_a> sometimes i wonder how they make money without selling my personal information...
[21:24:00] <fuzzie> i think probably because bindiff sold for thousands of dollars before, and they probably already had agreements with resellers outside the US
[21:24:07] <fuzzie> but that is uninformed speculation :)
[21:27:16] <lynxlynxlynx> or the crypto law
[21:27:48] <Yoshimo> what does a binary diff tool have to do with cryptography?
[21:27:50] <fuzzie> well my limited knowledge about it is that it's some kind of contract stuff.
[21:28:38] <fuzzie> "it will be available in europe shortly", 3 months ago.
[21:30:17] <lynxlynxlynx> the language is vague iirc
[21:30:28] <Yoshimo> shortly, okeee
[21:30:47] <fuzzie> and decompression/decryption of binaries is not uncommon i guess?
[21:30:54] <fuzzie> i am sticking to my theory though.
[21:31:32] <fuzzie> besides by the time I get time to want to use it again, it'll no doubt be available :p
[21:32:28] <Yoshimo> wasnt zynamics using nasty java? looks like it
[21:41:36] <tomprince> brad_a: You can crash on referencing src, if you are in a member function, and referencing a member variable, if this is NULL
[21:43:27] <brad_a> CacheStream doesnt appear to be a class method
[21:46:50] <brad_a> i did change strncpy to use strncpy tho. dont think it will matter but ive been suprised before :)
[21:47:46] <tomprince> strncpy to itself?
[21:48:25] <brad_a> it was just strcpy
[21:48:39] <brad_a> so strncpy with _MAX_PATH
[21:48:48] <brad_a> and _MAX_PATH == FILENAME_MAX
[21:48:55] <fuzzie> strncpy is bad
[21:49:04] <brad_a> i thought thats what you said to do
[21:49:38] <fuzzie> i thought we had a less stupid version of it lurking.
[21:49:48] <fuzzie> but can't see it.
[21:50:24] <fuzzie> but that ExtractFileFromPath stuff is writing into a 16-byte buffer anyway, not _MAX_PATH, right?
[21:52:24] <brad_a> oh i guess i didnt understand what you were saying
[21:52:45] <brad_a> i tought it was copying into a char[_MAX_PATH] buffer
[21:52:57] <fuzzie> i don't imagine i am being very coherent, sorry
[21:53:41] <brad_a> no you are right its char[16]
[21:54:06] <brad_a> i should learn to always use "jump to definitin" instead of using find
[21:56:00] <tomprince> We are actually quite bad about string lengths, when hadnling path names.
[21:56:29] <brad_a> maybe thats my problem :(
[21:57:44] <brad_a> but i wont count on that
[21:57:53] <fuzzie> i complained about using strncpy everywhere when it started appearing at the top of my profiling
[21:58:24] <brad_a> what is wrong with stncpy? i was always told to use it over strcpy
[21:58:32] <fuzzie> it pads the entire target string with null bytes, so it starts using crazy amounts of CPU time when you use it with huge buffers
[21:58:44] <brad_a> oh
[21:59:05] <brad_a> i thought it just promised to only cpy x bytes
[21:59:16] <fuzzie> well, we should really have a function which does that
[21:59:31] <fuzzie> but at a glance, i can only see the ones which do upper/lowercasing
[21:59:52] <tomprince> Yes, but it *always* copies x bytes, even if you only need a few << _MAX_PATH
[22:00:33] <brad_a> i didnt realize it always copied i thought it was copy x or less if null is encountered
[22:00:49] <fuzzie> honestly, I had completely forgotten it did that before encountering this slowness
[22:01:03] <fuzzie> i can't imagine it will hurt in that function though
[22:01:16] <brad_a> well i shouldnt use _MAX_PATH there
[22:01:22] <fuzzie> oh, well, that too
[22:01:27] <brad_a> :)
[22:01:27] <fuzzie> :)
[22:02:10] <brad_a> im just trying to figure out what is failing. i know strncpy wont magically fix it but maybe it will manifest the point of failure
[22:02:24] <brad_a> i doubt it tho
[22:02:32] <fuzzie> well, i thought it might be it, but then there's that _MAX_PATH buffer directly after it anyway..
[22:02:45] <fuzzie> i was looking for a strcpy onto the stack, which would be a more likely culprit
[22:03:04] <fuzzie> do you have a full stacktrace?
[22:03:18] <brad_a> let me see it its still up
[22:03:27] <brad_a> only part of it was symbolicated tho
[22:04:22] <brad_a> seeing as how i have no device i can only get what is in the crash report
[22:05:35] <brad_a> http://dl.dropbox.com/u/13866402/gemcrash.txt
[22:05:47] <brad_a> that is the relavant/symbolicated portion
[22:07:18] <gembot> build #53 of nmake-msvc++6 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B6/builds/53
[22:07:27] <brad_a> i wish i could see what was at 0x2fd05adc
[22:08:14] <brad_a> i guess thats irrelavant
[22:09:11] <fuzzie> so, that GetHighestProjectileNumber is the first thing which tries loading anything?
[22:09:36] <brad_a> jsut FYI i have even tried removing my wrapper entirelly and the crash still happens at FileCache.cpp:57 so i think my wrapper is fine
[22:09:38] <fuzzie> one question: is this using GameType 'auto' or something hardcoded?
[22:09:50] <brad_a> no gametype bg2
[22:09:56] <fuzzie> ok
[22:10:14] <brad_a> let me get you a run log too
[22:10:45] <brad_a> grr dont have one anymore
[22:11:05] <fuzzie> the path could be invalid
[22:11:13] <brad_a> for the BIF?
[22:11:31] <fuzzie> maybe
[22:11:32] <brad_a> i would like to think that wouldnt crash that way
[22:12:08] <brad_a> i cant image its wrong. ill have joshua verify it tho
[22:12:13] <brad_a> ist trying for /var/mobile/Applications/01C38D52-F856-47D4-866D-F91FC9E25593/Library/Caches/bg2/Default.bif
[22:12:15] <fuzzie> we don't sanity-check bifnum for range in KEYImporter::GetStream :(
[22:12:38] <brad_a> well i guess you are right that that doesnt exist then
[22:12:50] <fuzzie> no
[22:12:56] <fuzzie> i mean, i don't think that can go wrong
[22:13:05] <fuzzie> just poking through code and you get my ramblings
[22:13:10] <brad_a> :)
[22:13:17] <brad_a> well i appritiate your ramblings
[22:13:21] <tomprince> I'd be curious to see what happens if you just return src. Taht will break other things, but might give us some more information.
[22:13:53] <brad_a> i will try next time joshua is on
[22:13:56] <fuzzie> it looks like it's probably the first time it tried loading a bif at all, but verifying that would need a log
[22:14:06] <brad_a> yeah and here is a kicker
[22:14:10] <brad_a> youre gonna love this
[22:14:24] <brad_a> the gemrb log output goes into a balck hole whenever it crashes
[22:14:33] <brad_a> the log shows the output from my wrapper
[22:14:38] <brad_a> and from python and sdl
[22:14:46] <brad_a> but gemrbs stuff is vaporized
[22:14:47] <fuzzie> maybe we need to flush it more
[22:15:08] <brad_a> well normally dont those get flushed automatically after a crash
[22:15:24] <fuzzie> no idea
[22:15:47] <tomprince> Not after a segv.
[22:15:48] <brad_a> then i will try to flash on the line its crashing
[22:15:54] <brad_a> flush
[22:16:05] <tomprince> You could try adding a fflush(0) on the line .. :)
[22:17:00] <tomprince> or ffluish(stdout); fflush(stderr); (or whaterve the appropriate FILE*s are.
[22:17:06] <brad_a> thats what i did
[22:17:12] <brad_a> they are stdout and stderr
[22:17:24] <brad_a> so hopefully that will help
[22:17:34] <brad_a> also for the record we have tried with diffrent games
[22:17:51] <tomprince> The other thing you could try, if you enable rtti, is to get the typeinfo of src. It wouldn't suprise me if that is corrupted.
[22:17:52] <brad_a> same failure no matter what
[22:18:10] <tomprince> If src is not null, but points to garbage ..
[22:18:12] <brad_a> i wouldnt be either
[22:18:38] <brad_a> that must be what is happening
[22:18:43] <brad_a> because i already tested for null
[22:18:47] <brad_a> so its not that
[22:19:55] <brad_a> i cant thank you guys enough for trying to help :)
[22:21:05] <pugvader_> if you offer the most thanks for no help, how much thanks do you offer for real help?
[22:21:29] <pugvader_> :)
[22:22:13] <brad_a> well im already at my maximum level of thankfulness ;-)
[22:26:39] <brad_a> if i had devece i would just have gdb watch src for changes
[22:26:53] <brad_a> to see where its getting turned into garbage
[22:27:12] <pugvader_> pixels in display yes?
[22:28:29] <pugvader_> i remember your issue i think
[22:28:39] <pugvader_> good luck
[22:30:22] <brad_a> im super perplexed. file->Read is obviously successful then the next time it is used is CacheStream(file) where it is garbage immediately. does that mean the corruption is happening in Read itself?
[22:31:32] <brad_a> i dont see how since it should just be reading
[22:32:20] <pugvader_> for loading the font, right?
[22:32:24] <brad_a> no
[22:32:26] <pugvader_> oh
[22:32:34] <brad_a> loading a BIF
[22:32:48] <brad_a> code that hasnt been touched in ages i assume
[22:35:05] <pugvader_> i have no chance of catching up to actually help
[22:35:21] <brad_a> nothing even happens between file->read and cachestream(file)
[22:35:27] <brad_a> i lied
[22:35:42] <brad_a> only the strncmps happen
[22:44:35] <Yoshimo> which file could cause the speech after gorions death from sarevok to loop on the first sentence?
[22:46:45] <brad_a> probably the same thing that causes looping during chapter sequences?
[22:46:56] <brad_a> im purely guessing
[22:47:33] <lynxlynxlynx> i thought it's just a textarea flag, i don't know why everyone is making a big deal out of it
[22:47:43] <brad_a> i dont eaither
[22:47:45] <brad_a> either
[22:48:26] <brad_a> if i could fix all these other problems i have i would be happy to look into fixing it :)
[23:05:05] <Yoshimo> sounds that you have quite a lot of problems
[23:09:47] <brad_a> indeed :(
[23:13:29] <CIA-44> GemRB: 03lynxlupodian * r6bf9fc09f076 10gemrb/gemrb/GUIScripts/GUICommonWindows.py: GCW: remove an unneeded iwd special case
[23:14:19] <brad_a> at least lynx is making good progress on gemrb :)
[23:14:29] <Yoshimo> I decided to help with the point "make sure the bg trilogy is playable from start to end" too^^
[23:14:48] <Yoshimo> he seems busy cleaning up the code
[23:15:05] <fuzzie> very good thing to do
[23:16:31] --> CJS|2 has joined #gemrb
[23:18:39] <-- _CJS_ has left IRC (Ping timeout: 240 seconds)
[23:23:00] <lynxlynxlynx> Yoshimo: how far have you come?
[23:23:39] <lynxlynxlynx> i still have a negative loc balance :)
[23:24:18] <Yoshimo> not far yet, had a full expert install for testing automated bugfixing scripts before, not playable it was
[23:24:51] <Yoshimo> a loc balance?
[23:25:46] <lynxlynxlynx> lines of code removed/added
[23:26:18] <lynxlynxlynx> i ripped out/modified more code than added/modified
[23:29:24] <brad_a> nice :)
[23:30:44] <Yoshimo> lynx what do you refer to by "action system fixes bg2 completable again" on your todo?
[23:31:45] <tomprince> brad_a: most of the fs code has been touched fairly recently.
[23:31:59] <lynxlynxlynx> Yoshimo: something i poke fuzzie about any vague chance i get
[23:32:36] <lynxlynxlynx> as far as i know, this amounts to only one known crash, but the point of the triple run was to check everything is still fine
[23:35:02] <brad_a> tomprince: im seeing 6+ moths ago in git history
[23:35:15] <lynxlynxlynx> she (re)wrote most of that code, but it's not complete yet, so it's hard for me to fix it instead
[23:36:21] <tomprince> brad_a: i.e. not too long ago.
[23:36:31] <brad_a> oh :)
[23:37:12] <brad_a> well it hasnt changed since porting to iOS tho
[23:44:56] <tomprince> I guess it really depends on when on stated hacking on gemrb ... :)
[23:45:43] <brad_a> yes 6 months ago i had no idea what gemrb was
[23:45:57] <brad_a> i stumbled upon it when researching icewind gate 2
[23:48:00] <tomprince> Well, FileCache.{h,cpp} are new since the relase before last.
[23:49:35] <brad_a> git says it was added 8 moths ago and last modified 6 months ago...
[23:49:40] <tomprince> I did quite major surgery on the FS code in march.
[23:50:35] <brad_a> looks like
[23:53:38] <-- lynxlynxlynx has left IRC (Remote host closed the connection)