#gemrb@irc.freenode.net logs for 21 Apr 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:01:56] <pupnik> :)
[00:04:54] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[00:16:41] <CIA-52> GemRB: 03tom.prince * reb21804af80a 10gemrb/gemrb/core/System/Logging.cpp:
[00:16:41] <CIA-52> GemRB: Fix android printMessage.
[00:16:41] <CIA-52> GemRB: ... this is uncompiled code, obviously. :(
[00:16:41] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[00:16:47] <CIA-52> GemRB: 03tom.prince * r3041721b1898 10gemrb/gemrb/core/Interface.cpp:
[00:16:47] <CIA-52> GemRB: Remove duplicate include.
[00:16:47] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[00:42:53] --> _pickle has joined #gemrb
[01:08:00] --> pupnik_ has joined #gemrb
[01:11:32] <-- pupnik has left IRC (Ping timeout: 276 seconds)
[01:14:34] <-- edheldil_ has left IRC (Ping timeout: 246 seconds)
[01:52:09] --> Cable_ has joined #gemrb
[01:52:09] <-- |Cable| has left IRC (Read error: Connection reset by peer)
[01:53:44] <tomprince> fuzzie: see my error branch on github.
[01:55:03] <tomprince> Unfortunately we can't get make error a macro to get __FILE__ and __LINE__, since gcc 4.2.4 and msvc6 both barf on this in the libc++.
[03:38:34] <-- _pickle has left IRC (Remote host closed the connection)
[04:46:46] <-- Cable_ has left IRC (Read error: Connection reset by peer)
[04:48:08] --> |Cable| has joined #gemrb
[04:55:33] <-- |Cable| has left IRC (Remote host closed the connection)
[04:56:56] --> |Cable| has joined #gemrb
[05:02:11] <-- |Cable| has left IRC (Remote host closed the connection)
[05:03:31] --> |Cable| has joined #gemrb
[05:30:05] <-- |Cable| has left IRC (Read error: Connection reset by peer)
[05:31:33] --> |Cable| has joined #gemrb
[06:49:55] --> edheldil_ has joined #gemrb
[06:55:08] <-- edheldil_ has left IRC (Ping timeout: 258 seconds)
[07:01:32] --> lynxlynxlynx has joined #gemrb
[07:01:33] <-- lynxlynxlynx has left IRC (Changing host)
[07:01:33] --> lynxlynxlynx has joined #gemrb
[07:01:33] --- ChanServ gives channel operator status to lynxlynxlynx
[07:07:19] --> test32894789234u has joined #gemrb
[07:30:17] --> lubos has joined #gemrb
[07:40:26] * fuzzie yawns.
[07:54:37] --> edheldil_ has joined #gemrb
[07:59:30] <-- edheldil_ has left IRC (Ping timeout: 264 seconds)
[08:01:33] * edheldil shakes fuzzie: don't sleep or you freeze!
[08:02:40] <fuzzie> g'morning edheldil :)
[08:06:34] <edheldil> Hi :)
[08:07:16] <wjp> morning
[08:35:38] <nyytit> morning, i tried the troll thing again with an older save, and it still happens :(
[08:42:23] <fuzzie> yeah
[08:42:30] <fuzzie> i think i drew conclusions a bit quickly there
[08:44:16] <fuzzie> there is a '//TODO: script order' in the AREImporter
[08:44:21] <fuzzie> and it sure has the wrong script order
[08:45:14] <lynxlynxlynx> cool, someone volunteered to update our website theme :)
[08:45:28] <fuzzie> but i have a meeting
[08:47:24] <edheldil> lynxlynxlynx: really? Has they posted anything yet?
[08:47:31] <edheldil> Have
[08:47:37] <lynxlynxlynx> just an i-can
[08:49:26] <edheldil> I can't wait :)
[08:50:56] <lynxlynxlynx> oh right
[08:51:10] <lynxlynxlynx> please check that all variants of gemrb.org work fine
[08:51:16] <lynxlynxlynx> we should start using it more often
[08:51:44] <lynxlynxlynx> you can redirect directly to the wiki
[08:52:31] <lynxlynxlynx> (no need for the intermediate sf.net landing)
[09:06:02] <edheldil> I will look into that, but afaik DNS is set correctly, it's only some redirect
[09:10:05] <lynxlynxlynx> gemrb.sf.net uses a meta redirect to the wiki
[09:10:10] <lynxlynxlynx> it could be done directly
[09:16:19] <edheldil> how?
[09:21:57] <wjp> I get a 'This topic does not exist yet' page when going to www.gemrb.org?
[09:23:02] <edheldil> do you still? I was trying some redirects
[09:23:52] <wjp> yes, but not from a different machine now
[09:24:03] <wjp> so I'm guessing the redirect is still cached somewhere
[09:24:21] <wjp> (I'm not sure how to do a force-reload on a redirect :-) )
[09:25:06] <edheldil> clean browser cache
[09:31:50] <edheldil> works ok for me now
[09:32:15] <edheldil> lynxlynxlynx: what did you mean with "directly" ?
[09:33:17] <wjp> we can have SF host www.gemrb.org
[09:33:33] <wjp> (i.e., point the DNS to SF's servers directly)
[09:34:10] <wjp> um, never mind, I'm confused a bit about what you're talking about :-)
[09:35:12] <edheldil> it's done that way already :)
[09:35:16] --> PixelScum has joined #gemrb
[09:35:29] <wjp> yes :-)
[09:35:48] <wjp> but which meta-redirect is lynxlynxlynx talking about? I only see 302-redirects atm
[09:36:02] <edheldil> in index.html
[09:36:29] <edheldil> but the RewriteRule kicks in before it can be used now
[09:36:54] <wjp> it does do a double redirect currently
[09:37:08] <wjp> $ wget http://gemrb.sf.net/
[09:37:11] <wjp> Location: http://gemrb.sourceforge.net/ [following]
[09:37:14] <wjp> Location: http://www.gemrb.org/wiki/doku.php?id=start [following]
[09:37:33] <wjp> but maybe that first one is unavoidable
[09:37:53] <-- Drakkar has left IRC (Ping timeout: 276 seconds)
[09:39:00] <edheldil> I have added .htaccess with:
[09:39:25] <edheldil> RewriteEngine On
[09:39:25] <edheldil> RewriteRule ^$ "http://www.gemrb.org/wiki/doku.php?id=start" [L]
[09:39:25] <edheldil> RewriteRule ^index.html "http://www.gemrb.org/wiki/doku.php?id=start" [L]
[09:40:04] <edheldil> maybe I could come with something better.
[09:40:51] <wjp> should be fine
[09:41:22] <edheldil> Possibly if I redirected on HOST != www.gemrb.org only and added internal redirect for www.gemrb.org, it would save one roundtrip
[09:42:32] <wjp> I wouldn't worry about this gemrb.sf.net case
[09:44:27] <edheldil> actually it would save for www.gemrb.org , but we can optimize that any time later :)
[09:50:13] <edheldil> btw, I get only one redirect when I try http://gemrb.org:
[09:50:54] <edheldil> $ telnet gemrb.org 80
[09:51:03] <edheldil> GET / HTTP/1.0
[09:51:08] <edheldil> Host: gemrb.org
[09:51:20] <edheldil> -> Location: http://www.gemrb.org/wiki/doku.php?id=start
[09:51:52] <edheldil> and from that url I get the actual page
[10:11:00] * fuzzie yawns
[10:20:21] <dhewg> again? :P
[10:22:05] <fuzzie> you should see me irl
[10:22:45] <dhewg> you make it sound like i should not at this time :P
[10:23:16] <fuzzie> thankfully for everyone, narcolepsy is not transmittable :P
[10:24:02] <fuzzie> i think master might actually suck less than 0.6.4, btw
[10:25:56] <dhewg> as in, i should use that from now on for testing?
[10:26:12] <fuzzie> if you're willing to shout about bugs i missed
[10:26:46] <dhewg> totally. its a bg2 playthrough since ages for me. since i plan to finish it, you just have to :P
[10:27:02] <dhewg> actually, im not so sure i finished it back in the days
[10:27:16] <fuzzie> i finally finished SoA at some point
[10:27:20] <fuzzie> still haven't finished ToB
[10:27:56] <dhewg> heh
[10:28:13] <dhewg> i was grepping a little yesterday
[10:28:34] <dhewg> whats the cause DestroyItems doesnt work on that savegame i posted here?
[10:28:48] <dhewg> non of the Destroy* funcs get any calls at that spot
[10:28:52] <fuzzie> yeah
[10:28:55] <dhewg> is it something dialog related?
[10:28:55] <fuzzie> it doesn't get run
[10:29:00] <fuzzie> it's complicated :P
[10:29:24] <dhewg> whats the summary?
[10:29:25] <fuzzie> you can hack it if you need to get past there
[10:29:30] <dhewg> i did
[10:29:48] <dhewg> but since i didnt know where the fail was i commented the minhp code for only that scene :P
[10:30:09] <fuzzie> but basically: only instant actions get run during dialogs, DestroyItem isn't an instant action, and the queue gets wiped during that dialog, and we don't wipe the queue properly because we don't run actions properly
[10:31:32] <dhewg> didnt you mention that destroyitem should be instant?
[10:31:45] <fuzzie> no, it isn't
[10:31:58] <fuzzie> it's stupid that it isn't :P
[10:31:59] <fuzzie> but it isn't.
[10:32:03] <dhewg> but should it?
[10:32:12] <fuzzie> we obey original game data files here, i wouldn't want to fiddle
[10:32:27] <dhewg> so original is queued too?
[10:32:31] <fuzzie> yep
[10:32:33] <dhewg> k
[10:32:47] <fuzzie> it just doesn't get destroyed during the queue wipe because the dialog does a *special* kind of queue wipe which doesn't set breakaction
[10:33:12] <dhewg> those actions are unrelated to your epic trigger commit?
[10:33:25] <fuzzie> yeah
[10:33:31] <fuzzie> well, no
[10:33:44] <fuzzie> but it's complicated and it isn't fixed yet
[10:33:56] <dhewg> heh ok
[10:34:06] <dhewg> well, i managed to get past that
[10:34:21] <dhewg> but i have the next issue ready :P
[10:34:40] <fuzzie> oh, the .sto thing makes master horrible
[10:35:46] <dhewg> "store"?
[10:36:08] <fuzzie> yes
[10:36:23] <fuzzie> bags in player inventories are implemented stores
[10:37:40] <dhewg> its borken on master?
[10:37:54] <fuzzie> two issues
[10:38:05] <fuzzie> file access is slower on master, and we do it way too often
[10:38:42] <dhewg> eh
[10:38:55] <fuzzie> and the underlying issue which is that we close/reopen them every time
[10:39:01] <dhewg> its already slowish on 0.6.4, but didnt i see a filecache on master?
[10:39:14] <fuzzie> yes, the filecache made it worse
[10:39:21] <dhewg> nice cache :P
[10:40:23] <fuzzie> [GameScript]: Couldn't assign function to object: 0 ,k5.~4kav5#c[kn<:jxo"gvc332ku/qzi|<l!#lh|b
[10:40:32] <fuzzie> ^- i'm guessing my attempt to fix that isn't really so awesome
[10:40:43] <dhewg> :P
[10:41:12] <fuzzie> althoguh that's weird since everything else works
[10:42:49] <dhewg> so uhm
[10:42:55] <dhewg> that new issue i mentioned
[10:43:14] <dhewg> maybe thats related to the constantly-dying effect
[10:43:22] <dhewg> sure you remember that :)
[10:43:34] <fuzzie> oh, i forgot the squirrels thing
[10:43:44] <dhewg> its the scene where you run into rejiek for the 2nd time in trademeet
[10:44:14] <dhewg> they trick you to a certain spot, one plays dead etc
[10:44:16] <dhewg> remember that?
[10:44:23] <fuzzie> not at all
[10:44:52] <dhewg> the harper
[10:44:58] <dhewg> skinnig ppl and fun like that
[10:45:15] <fuzzie> i did the whole hero of trademeet thing yesterday
[10:45:34] <dhewg> then you should run into that girl, asking for help
[10:45:42] <fuzzie> but it's been a long time for anything else
[10:49:18] <dhewg> sry, ppl around here :)
[10:49:38] <dhewg> well, i think you need to finish the rejiek murder quest at the docks
[10:49:48] <dhewg> then the girl should come to you
[10:50:11] <dhewg> then the mentioned scene where they try to trick you triggers
[10:50:35] <dhewg> anyway, there's a girl knocked out lying on the floor, stuck in another skin
[10:51:01] <dhewg> you refuse to kill her, rejiek and his buddy turn into skeletons
[10:51:15] <dhewg> and then the weird thing happens after you kill those two
[10:51:44] <dhewg> the girl animation keeps looping the drop-dead ani
[10:51:48] <dhewg> over and over again
[10:52:01] <fuzzie> heh
[10:52:03] <fuzzie> but this is 0.6.4?
[10:52:07] <dhewg> yeh
[10:52:22] <dhewg> the only thing you can do is to force-attack her
[10:52:27] <fuzzie> i would try on master
[10:52:29] <dhewg> after you kill her she talks to you
[10:52:43] <dhewg> which makes it hilarious on multiple levels :)
[10:56:24] <-- |Cable| has left IRC (Remote host closed the connection)
[10:57:45] --> |Cable| has joined #gemrb
[10:58:01] <tomprince> fuzzie: Should the commented out aborts in GSUtils be there, or should they just be deleted?
[10:58:37] <fuzzie> i'm not sure either way right now
[11:00:51] <fuzzie> i'm still trying to work out why the file changes made performance worse
[11:01:53] <fuzzie> and that parsing code is v.tricky
[11:02:23] <fuzzie> *it* would be a good thing to test via guiscript
[11:07:31] <fuzzie> well, i can see why *some* of this stuff is slower
[11:10:03] <tomprince> I was tempted to push getPos, and the instance variable down to FileStream, and just have SlicedStream defer to the contained stream...
[11:11:31] <fuzzie> does that help?
[11:12:58] <fuzzie> i am still poking through the commits
[11:13:12] <fuzzie> it would be helpful if you'd mention when you e.g. remove MemoryStream users
[11:15:45] <tomprince> there was only ever the one.
[11:15:51] <fuzzie> yes :P
[11:16:04] <fuzzie> i think the problem is where you replaced CachedFileStream with CacheFile
[11:16:38] <fuzzie> no, can't be it
[11:16:39] <fuzzie> sigh
[11:17:23] <CIA-52> GemRB: 03tom.prince * rd86c1c4de613 10gemrb/gemrb/core/EffectQueue.h:
[11:17:23] <CIA-52> GemRB: Fix compile errors with gcc 4.6.0.
[11:17:23] <CIA-52> GemRB: There are still a bunch of unused variable warnings.
[11:17:23] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[11:22:25] <tomprince> When is it slower.
[11:22:35] <fuzzie> opening files from BIFs
[11:23:51] <fuzzie> after getting rid of those seeks
[11:26:49] <tomprince> Compressed?
[11:27:34] <fuzzie> i mean, there are lots of little painful bits
[11:27:42] <fuzzie> like SlicedStream delegating to FileStram
[11:27:45] <fuzzie> FileStream
[11:28:12] <fuzzie> so you get extra useless calls for every one
[11:29:57] <fuzzie> and, sorry, no, not compressed
[11:30:44] <fuzzie> i can only guess it's this extra overhead for SlicedStream, but it's not showing significantly on the profile, so unlikely
[11:33:14] <fuzzie> mostly the profile is just fread as usual
[11:34:54] <dhewg> is the whole file access sane?
[11:35:06] <fuzzie> well define 'sane' :P
[11:35:09] <dhewg> it looks a little insane from a user perspective sometimes
[11:35:30] <dhewg> for one, all savegame files are extracted upon loading?
[11:35:36] <fuzzie> yes
[11:35:51] <dhewg> that takes quite a while when progressing in the game :P
[11:36:06] <fuzzie> yeah, but it's a huge simplification
[11:36:41] <dhewg> i know, but a better logic wouldnt be complicated, would it?
[11:36:55] <fuzzie> well, what's a better logic for that?
[11:37:31] <tomprince> Add SAV ResourceManager?
[11:37:37] <fuzzie> well
[11:37:42] <tomprince> And insert it right after the cache?
[11:37:45] <fuzzie> use case: load a quicksave, do a quicksave.
[11:37:49] <fuzzie> your SAV is gone.
[11:38:06] <dhewg> something like scummvm maybe? you have code that decides where to take stuff from (save/override/game), stream classes and archives classes to return streams of (compressed) members
[11:38:09] <fuzzie> so you'd have to do all the I/O anyway to copy it elsewhere.
[11:38:53] <fuzzie> as nice as unlink() semantics may be on some filesystems :P
[11:39:18] <tomprince> On unix we could get away with just keep the fh open, although we would need to make SlicedStream not copy the FileStream.
[11:39:20] <tomprince> :)
[11:40:05] <fuzzie> but i don't know how much this annoys people
[11:40:21] <fuzzie> i mean, to me, the reduced game I/O performance from this recent refactoring is vastly more annoying
[11:41:25] <dhewg> well, that i/o on save would still be there, but its limited to the saving itself
[11:41:45] <dhewg> now you litter the cache dir upon save
[11:41:55] <dhewg> while thats not annoying yet, its also a desktop system
[11:41:58] <fuzzie> that *is* what it's for :P
[11:41:59] <dhewg> read: best case
[11:42:10] <dhewg> try writing 80 mb to sd on android
[11:42:22] <fuzzie> it works pretty well if your device doesn't suck, to be fair
[11:42:51] <dhewg> sometimes its just the manufacturer failing to configure their devices :)
[11:42:57] <fuzzie> putting all your gemrb stuff on FUSE is a good test for this stuff
[11:43:14] <dhewg> i bumped the cache on my tab and saw a 500% improvement :)
[11:43:43] <fuzzie> and for me on FUSE, slower load times are *much* better than having to wait for it during the game
[11:44:42] <tomprince> Could perhaps try reintroduce memory stream.
[11:44:48] <dhewg> erm, also i meant "now you litter the cache dir upon load"
[11:44:55] <fuzzie> yes, i figured
[11:44:57] <dhewg> :)
[11:45:11] <tomprince> And use it instead of sliced stream if length < 1024 or some such.
[11:45:37] <fuzzie> well i'm wondering why this is all so awful in general
[11:45:56] <fuzzie> profiler is not liking this optimised build though
[11:46:34] <dhewg> well, assume you have a "savegame archive" class, that returns stream to from its members, which you use to read to mem directly (not dumping the members to the cache dir first)
[11:46:36] <fuzzie> but MemoryStream for small sizes sounds like a wonderful idea
[11:46:39] <dhewg> you think that would be slower?
[11:47:06] <fuzzie> dhewg: well, the slow bit on everything i tried is the zlib decompression
[11:47:37] <dhewg> hm
[11:47:39] <dhewg> really?
[11:47:41] <dhewg> :)
[11:47:43] <fuzzie> yes
[11:48:43] <fuzzie> but it depends on your device i think
[11:48:50] <tomprince> I did change that to use FileStream, buf if that is a bottle neck then we need to change our abstraction.
[11:49:19] <fuzzie> tomprince: your MemoryStream removal seems irrelevant, if that's what you mean
[11:49:50] <fuzzie> if you mean SlicedStream then i don't actually see a bottleneck in the profile.
[11:50:19] <tomprince> No, we write to a FileStream instead of a FILE* in Decompress.
[11:50:27] <fuzzie> ah
[11:50:34] <fuzzie> no, i think it's zlib.
[11:50:57] <fuzzie> didn't look seriously though.
[11:51:21] <fuzzie> dhewg: do you have large files in your cache which come from the save? or just lots?
[11:52:32] <dhewg> i can paste numbers when im home, but i think its just that i visited many areas in the game, and i see like a wall of "decompressing" entries upon load
[11:52:47] <fuzzie> i'm pretty sure that's mostly zlib
[11:53:04] <fuzzie> my cache dir is mostly 40mb bif files
[11:54:35] <dhewg> i'll check later
[11:56:22] <tomprince> Insane idea: https://gist.github.com/934297
[11:57:54] <fuzzie> it doesn't help
[11:58:02] <fuzzie> the problem is: libc sucks :P
[11:58:35] <fuzzie> it spends a disproportionate amount of time maintaining internal buffers here, i'm not sure why.
[11:59:23] <dhewg> oh i hated the stdio fail buffers on wii
[11:59:31] <dhewg> thats like epicslow on there
[11:59:51] <dhewg> do you guys buffer parts yourself?
[12:00:06] <fuzzie> well tomprince sabotaged our only self-buffering code recently :P
[12:00:11] <dhewg> hehe
[12:00:14] <fuzzie> but it seemed like the silliest thing to buffer honestly, i'd have done the same
[12:00:44] <fuzzie> his suggestion above about using MemoryStream for length<1024 would be self-buffering for small files, and it seems like a good idea
[12:01:19] <fuzzie> but our code is *awful*, i'd forgotten this
[12:01:27] <dhewg> that should already be buffered by stdio i think
[12:01:30] <fuzzie> KEYImporter::GetStream reopens the BIF every time
[12:01:38] <dhewg> dunno what its default bufsize is nowadays
[12:01:57] <fuzzie> so awful awful awful
[12:02:13] <dhewg> well closing handles ruins that buffering too :P
[12:02:25] <fuzzie> yeah
[12:02:35] <fuzzie> the problem is that most of our files are substreams of a bigger frile
[12:02:38] <fuzzie> bigger file
[12:02:57] <tomprince> Well, I wonder, since every time we Slice, which opens anyway, right now.
[12:03:04] <fuzzie> at the moment .. yes, what tomprince said
[12:03:14] <fuzzie> so imo MemoryStream for small files would help
[12:03:20] <fuzzie> but fixing the KEYImporter would probably help more
[12:03:53] <tomprince> I am just wondering if that helps much, if we then open the file again in SlicedStream?
[12:04:06] <fuzzie> PathExists(BIFEntry*, char const char*) is a big problem for some reason?
[12:04:55] <dhewg> open how?
[12:04:58] <dhewg> (f)open?
[12:05:01] <fuzzie> yes
[12:05:09] <dhewg> maybe ddup helps?
[12:05:15] <tomprince> You say the extra seeks don't hurt. Should we share FileStreams there?
[12:05:25] <fuzzie> no
[12:05:30] <fuzzie> i am profiling without the extra seeks in Read().
[12:05:35] <fuzzie> which are terrible.
[12:06:00] <fuzzie> well, i mean
[12:06:03] <fuzzie> i don't *know*
[12:06:07] <tomprince> Do you have GameOnCD true?
[12:06:11] <fuzzie> no :P
[12:06:29] <tomprince> That is the only reason PathExists should be being called except on startup.
[12:06:44] <fuzzie> let me make sure it's on startup
[12:07:53] <fuzzie> it is
[12:08:07] <fuzzie> i shall declare the profiler too unreliable
[12:08:49] <dhewg> what are you using?
[12:09:08] <fuzzie> oprofile and callgrind
[12:09:56] <fuzzie> <3 oprofile
[12:10:06] <dhewg> didnt try the latter, but oprofile is teh awesome
[12:10:30] <fuzzie> callgrind gives you profiling down to the source line
[12:10:54] <fuzzie> complete with GUI tool for navigation
[12:11:21] <dhewg> sounds neat
[12:11:27] <fuzzie> but on the other hand, it's slow like valgrind is slow
[12:11:52] <dhewg> yeah, thats what i like about oprofile. same binary, same speed, no vm
[12:12:05] <dhewg> sometimes profiling in a vm doesnt make any sense
[12:12:13] <fuzzie> so they're both good for different things
[12:12:23] <fuzzie> unlike gprof, which is good for nothing
[12:12:28] <dhewg> hehe
[12:12:45] <dhewg> i wish i had oprofile on my droid
[12:14:24] <fuzzie> anyway i don't really know what's going on. hmph.
[12:21:19] <fuzzie> i guess the initial open() is hideously hideously slow too
[12:22:22] <fuzzie> and that is probably what's so slow here
[12:31:01] <fuzzie> ah we have some new PathJoinExt
[12:31:57] <fuzzie> it is not helping
[12:32:41] <fuzzie> or, rather, we have PathJoinExt being called where it wasn't before
[12:33:10] <fuzzie> FileStream::Create seems to be the issue for me
[12:34:53] <fuzzie> but that doesn't make much sense
[12:51:02] --> SiENcE has joined #gemrb
[12:51:21] <edheldil> what's up with reintroducing MemoryStream?
[12:52:49] <fuzzie> to avoid the large stdio overhead for 110-byte files
[12:54:31] <edheldil> yeah, but how they are accessed now? SlicedStream? I somehow did not get the reason for the change in the first place, I admit :)
[12:54:43] <fuzzie> well the details don't matter
[12:55:01] <fuzzie> the important bit is that right now, they're accessed by fopen()ing the file they're contained in
[12:56:46] <fuzzie> and that hasn't changed.
[12:58:14] <edheldil> That's why I wonder what is the difference :)
[12:58:50] <edheldil> Anyway, has not come time for a unified resource cache? :)
[12:59:01] <fuzzie> yes, but how would you do it?
[13:00:23] <fuzzie> all the edge cases make it tricky
[13:00:24] <edheldil> put (almost) each read resource to a memory cache indexed by resref+type and managed by some LRU algo
[13:01:13] <fuzzie> a generic cache for some resref types would help
[13:01:28] <fuzzie> especially itm :/
[13:01:52] <fuzzie> it would also be great if anyone tested this store stuff, ever
[13:01:56] <edheldil> and add the memcache as a first stop when looking for resources
[13:02:27] <fuzzie> but caching most resources would just make things worse i think
[13:02:51] <fuzzie> don't know
[13:04:23] <edheldil> that's why there would be the LRU algo - when you would exhaust configured memory limit, it would look for things to flush from cache - based on recentness and size
[13:05:31] <fuzzie> i mean, for single-access resources, it might just make things worse
[13:06:28] --> ubermad has joined #gemrb
[13:06:28] <edheldil> you could enhance the API with a flag for locking in memory and noncaching
[13:06:44] <fuzzie> caching items would help a ridiculous amount though
[13:20:07] <CIA-52> GemRB: 03fuzzie * rd3ec3823c4e5 10gemrb/gemrb/ (3 files in 2 dirs): remove DoTheStoreHack
[13:22:08] <-- lynxlynxlynx has left IRC (Ping timeout: 276 seconds)
[13:32:00] <CIA-52> GemRB: 03fuzzie * r231e3eafb90a 10gemrb/gemrb/core/Scriptable/Actor.cpp:
[13:32:00] <CIA-52> GemRB: wrap initial GetHpAdjustment call in class check
[13:32:00] <CIA-52> GemRB: this stops the poor squirrels from dying, thanks to lynxlynxlynx for
[13:32:00] <CIA-52> GemRB: pointing out it could be caused by negative CON bonuses
[13:43:02] --> lynxlynxlynx has joined #gemrb
[13:43:02] <-- lynxlynxlynx has left IRC (Changing host)
[13:43:02] --> lynxlynxlynx has joined #gemrb
[13:43:02] --- ChanServ gives channel operator status to lynxlynxlynx
[13:52:02] <-- ubermad has left #gemrb
[14:27:56] --> Maighstir has joined #gemrb
[15:18:10] <dhewg> what happened to master?
[15:18:16] <dhewg> its like a slideshow
[15:18:23] <fuzzie> the .sto thing probably :P
[15:18:25] <fuzzie> check console
[15:18:35] <dhewg> the bag messages?
[15:18:41] <fuzzie> yes
[15:18:47] <dhewg> wow
[15:19:03] <dhewg> thats like really bad :P
[15:19:04] <fuzzie> well in master itself they're a bit beyond ridiculous
[15:20:07] <fuzzie> http://fuzzie.org/nfs/gemrb/bags_suck.txt is what relevant I have locally
[15:22:51] <dhewg> i have 4 bags, and this is unplayable :P
[15:23:56] <dhewg> and that reijiek scene is as broken on master as on 0.6.4
[15:24:06] <fuzzie> reassuring
[15:24:11] <dhewg> :)
[15:27:46] <dhewg> hm
[15:29:21] <dhewg> want a save for that scene?
[15:29:43] <fuzzie> sure, if you can give dummy-proof reproduction recipe
[15:29:55] <dhewg> yeh
[15:30:04] <fuzzie> original engine is crazy buggy sometimes
[15:30:32] <dhewg> static.hackmii.com/dhewg/reijek_trademeet.tgz
[15:31:05] <dhewg> walk east, talk to right guy, and kill skeletons
[15:31:50] <dhewg> also, yay, living squirrels :)
[15:32:40] <-- lubos has left IRC (Quit: Leaving.)
[15:38:31] <fuzzie> skeletons?
[15:38:53] <dhewg> if you talk to the right guy, they morph
[15:39:02] <dhewg> dont accept to kill the dude on the ground
[15:39:41] <dhewg> just ask a question and they'll give up their moronic trap
[15:40:15] <fuzzie> it breaks if i talk to the person on the ground
[15:40:54] <dhewg> they constant dropping dead?
[15:40:56] <dhewg> *that
[15:41:03] <fuzzie> but you're not meant to be able to do that i think
[15:41:45] <dhewg> i think not talking to the 2 bad guys, and talking to raissa instead is valid, and just another way to trigger this
[15:42:10] <fuzzie> you're probably also not meant to be able to do that
[15:42:35] <dhewg> you mean talk to raissa?
[15:43:24] <fuzzie> if i understand the scene right :P
[15:43:34] <-- test32894789234u has left #gemrb
[15:43:47] <dhewg> i think thats valid
[15:44:03] <dhewg> you're supposed to find out the obvious
[15:44:13] <dhewg> and there're just 2 ways to do that
[15:44:19] <-- SiENcE has left IRC (Ping timeout: 246 seconds)
[15:44:26] <dhewg> maybe not, but i'd guess so
[15:44:55] <dhewg> anyway, if you run into that scene, you see raissa dropping to the floor as she becomes visible
[15:45:27] <dhewg> im not sure if that's the start of the problem, or if thats ok and her dropping state is just not correctly canceled/finished/whatever
[15:45:41] <dhewg> maybe she's supposed to be on the ground already?
[15:45:52] <fuzzie> oh, she isn't for you?
[15:46:02] <dhewg> at least not on 0.6.4
[15:46:57] <fuzzie> i have no idea how this scene is meant to work
[15:47:37] <fuzzie> once you killed Rejiek and Darsidian, tannerpolt2 becomes 3
[15:47:42] <fuzzie> tannerplot2
[15:47:54] <dhewg> she also stands plus falls on master upon running there
[15:48:34] <fuzzie> and then .. some stuff
[15:50:35] <dhewg> http://www.youtube.com/watch?v=U_DiO6JWEx4
[15:50:37] <dhewg> ~5m
[15:51:39] <fuzzie> hmm
[15:51:48] <fuzzie> really dumb
[15:51:53] <dhewg> hard to see, but she's already on the ground there
[15:52:30] <fuzzie> it's probably PlayDead(0)
[15:52:36] <dhewg> and then she just stands up when the 2 skeletons are dead
[15:52:57] <fuzzie> i can't think why though
[15:53:51] <fuzzie> she does PlayDeadInterruptible(2000000) but that shouldn't matter
[15:55:13] <fuzzie> also way to not have restoration memorised
[15:55:22] <fuzzie> but doesn't work either.
[15:56:19] <dhewg> well, if you kill the skeletons, then attack her, get a scroll of rest., you can cast that on her and finish the quest fine
[16:03:03] <fuzzie> heh
[16:03:10] <fuzzie> well i don't know, off th top of my head
[16:03:30] <fuzzie> maybe put a print in PlayDead
[16:04:02] <fuzzie> now i look there, "// TODO: what if parameter is 0? see orphan2", heh
[16:04:11] <fuzzie> will deal with that.
[16:05:48] <fuzzie> but first am sending beloved partner on a quest for aircon.
[16:15:08] <fuzzie> ok, fixing PlayDead fixes it
[16:16:16] <dhewg> if i use "if (Sender->Type != ST_ACTOR || parameters->int0Parameter == 0)" there, it seems to work
[16:16:32] <fuzzie> does she get up properly?
[16:16:35] <dhewg> but she's still dropping instead of lying
[16:17:01] <dhewg> yeah, she gets up and initializes the dialog like in the yt vid
[16:17:32] <fuzzie> intrsting
[16:17:50] <dhewg> but something is still wrong
[16:18:01] <fuzzie> http://fuzzie.org/nfs/gemrb/playdead.txt is what I wrote
[16:18:16] <dhewg> her skin is on the dead body
[16:18:33] <dhewg> i think either she's supposed to get it or im supposed to bring it?
[16:18:37] <fuzzie> yep
[16:18:47] <fuzzie> depending on whether you grabbed it before she got up, or not
[16:18:57] <fuzzie> however the coordinates for this are hard-coded
[16:19:06] <dhewg> hah
[16:19:16] <dhewg> yeah, she walks where rejiek was standing first
[16:19:20] <fuzzie> so presumably the skin is dropped in the wrong place
[16:20:24] <dhewg> does your path work in the same way?
[16:20:32] <fuzzie> not at all
[16:20:53] <dhewg> currentactionstate can underflow there
[16:21:42] <fuzzie> it can't, i think
[16:22:06] <fuzzie> oh, it is signed. why is it signed.
[16:22:44] <fuzzie> hah, they do PlayDeadInterruptible(2147483647) and all
[16:23:33] <dhewg> which means she's bored at some point playing dead and gets up?
[16:24:20] <fuzzie> sure
[16:24:49] <fuzzie> in a mere 4.5 years of real time
[16:25:09] <dhewg> patience is a virtue
[16:28:57] <fuzzie> but yes i'm not sure how that's meant to work, so leaving it alone
[16:30:22] <fuzzie> i always forget which is the signed compare
[16:31:47] <fuzzie> so it checks >0 signed, and does the subtract after
[16:33:08] <dhewg> weird
[16:50:50] --> Beh0lder has joined #gemrb
[16:51:25] <Beh0lder> hello all
[17:26:17] <pupnik_> hi
[17:38:18] <fuzzie> quest for air conditioning has apparently succeeded
[17:39:56] <dhewg> uh, look, found another one: Couldn't load animation: makhg1, cycle 35
[17:40:14] <fuzzie> what's a MAKH.
[17:40:29] <dhewg> ankheg
[17:40:35] <fuzzie> oh ugh, ankhegs
[17:40:49] <fuzzie> that animation is of type MonsterAnkheg
[17:40:54] <fuzzie> hate
[17:41:03] <dhewg> :)
[17:41:25] <fuzzie> it has hacks scattered in the movement etc code too
[17:55:25] <pupnik_> hm
[18:06:19] <fuzzie> Anomen sure is annoying
[18:32:37] <pupnik_> :D
[18:33:40] <dhewg> another one: Couldn't load animation: mglcg26, cycle 62
[18:34:07] <fuzzie> clay golem?
[18:34:23] <dhewg> i think that one is stone
[18:37:09] <fuzzie> g26 seems wrong
[18:37:49] <fuzzie> well i guess i don't know what the stone golems are
[18:43:45] <dhewg> heh
[18:44:19] <dhewg> if a golem casts "slow" in me, and i reequip my boots of speed, it invalidates the slow effect
[18:48:20] <pupnik_> oops
[18:48:28] <pupnik_> might want to file that
[18:59:07] <-- Beh0lder has left IRC (Ping timeout: 252 seconds)
[19:02:51] <fuzzie> misordered effects?
[19:03:54] <fuzzie> anyway hello
[19:04:11] <fuzzie> i am stuck siting around here again, apparently
[19:13:05] <lynxlynxlynx> boots of speed grant haste, but only of the movement speed type
[19:13:41] <lynxlynxlynx> i think only the normal type should cancel slow and vice-versa
[19:30:14] <dhewg> when using tansheron's bow (which needs no arrows), the attack animation is wrong
[19:33:13] <fuzzie> is that the one which uses arrows if you have them in quiver?
[19:35:40] <nyytit> hi, is there any solution to that troll-thing yet?
[19:36:13] <nyytit> or any clues
[19:36:51] <nyytit> i haven't had time to read all the logs from this day
[19:37:28] <fuzzie> i think maybe we corrupt the trolls
[19:37:40] <fuzzie> i maybe have a fix, but i haven't tried it yet
[19:39:49] <nyytit> ok, i am not able to try anything until next tuesday
[19:40:06] <nyytit> btw are you short on developers?
[19:41:18] <fuzzie> we're short on developers who know enough about IE modding to help out
[19:42:25] <tomprince> 3 active, and 2 less active, and me who mucks with everthing but IE.
[19:44:33] <nyytit> ok, i just thought that this could be one open source software i could contribute to, but i have no experince with the IE more than just playing
[19:44:49] <tomprince> We also need testers.
[19:46:47] <tomprince> dhewg's playing has lead to a bunch of bugs being fixed.
[19:47:06] <nyytit> btw how is your testing, just play-testing?
[19:47:42] <nyytit> or do you write unit tests also?
[19:47:43] <tomprince> Yes.
[19:48:04] <lynxlynxlynx> ie knowledge is far from necessary
[19:48:17] <lynxlynxlynx> and even further from unattainable
[19:48:44] <tomprince> Although it would be good to have some automated tests, we don't have a test harness, and for most of the interesting stuff, it isn't clear how one would go about testing it.
[19:49:01] <fuzzie> well
[19:49:12] <fuzzie> for most of the interesting stuff, write the test and you did 95% of the work
[19:49:18] <nyytit> i just wrote my masters thesis about test driven development
[19:50:30] <nyytit> but testing usually goes to the point where you just make yourself a machine
[19:50:44] <nyytit> if it is manual testing
[19:50:54] <fuzzie> the problem is, most of the work for gemrb is working out what is meant to happen
[19:51:41] <fuzzie> if you work enough of that out that you can write some seful automated testing, it's great, but it is pretty rare that happens
[19:52:31] <nyytit> but automated tests are good when you are modifying the software
[19:52:46] <fuzzie> and otherwise you end up with incorrect tests, which are unhelpful
[19:52:46] <nyytit> they ensure that you dont break anything
[19:53:21] <fuzzie> sure, but what do you test?
[19:54:00] <nyytit> yes, i am aware of that problem, usually testers who write the tests assume that current behaviour is right, and dont make the tests like they should be
[19:54:48] <fuzzie> so you can only test when you know what correct behaviour is, and that is not much for a project like gemrb :(
[19:55:15] <nyytit> umm, the smallest tests are usually testing every function and every possibility, yes i know, they are very costly and sometimes hard to do
[19:55:37] <nyytit> haha, good point :D
[19:55:57] <fuzzie> but it would be really helpful for the stuff we *do* know
[19:56:05] <nyytit> yeah
[19:56:47] <nyytit> but i will talk about this again next week when i get home and have more time to contribute :)
[19:56:59] <nyytit> g'night
[20:00:04] <dhewg> fuzzie: yes, the description of the bow reads to not equip normal arrows
[20:00:20] <dhewg> i didnt try it if the ani is correct when using those
[20:00:24] <fuzzie> want to bet on whether it's hacked in? :P
[20:00:28] <dhewg> the projectiles are ok
[20:00:34] <dhewg> i can guess :)
[20:00:53] <dhewg> but the actor is doing a normal attack anim
[20:00:58] <dhewg> which looks stupid :P
[20:01:03] --- pupnik_ is now known as pupnik
[20:01:22] <fuzzie> actually maybe i saw this
[20:02:43] <fuzzie> i wonder what the ext header says for the ability
[20:02:47] <fuzzie> do you have a resref for the bow?
[20:03:04] <dhewg> i have it equiped, how do i find out?
[20:03:29] <fuzzie> ctrl-m on the actor, look for inventory slot matching Equipped
[20:04:14] <dhewg> 1: clck10 - (1 0 0) Fl:0x6ca3 Wt: 1 x 3Lb
[20:04:21] <dhewg> i think
[20:04:23] <fuzzie> oh, sorry, added to the first weapn slot
[20:04:29] <fuzzie> which i don't know off the top of my head
[20:04:44] <fuzzie> i hate the inv stuff
[20:05:05] <dhewg> 36: bow15 - (1 0 0) Fl:0xeee1 Wt: 1 x 2Lb
[20:05:16] <tomprince> fuzzie: Are all the encrypted files in BIFs? It looks like FileStream doesn't handle them. (Least not the offset)
[20:05:16] <dhewg> at least this actor only has one bow
[20:05:48] <tomprince> I am tempeted to just turn them in to MemoryStreams and decrypt in place.
[20:05:57] <fuzzie> tomprince: Seek() doesn't work on encrypted files
[20:06:03] <fuzzie> if that's what you mean
[20:06:11] <tomprince> Yes.
[20:06:21] <fuzzie> my seek-removing patch for SlicedStream breaks it for them too
[20:06:45] <fuzzie> which is why it isn't applied, i started despairing
[20:07:53] <dhewg> i think spells with timing based reoccuring hits are completely off
[20:08:05] <dhewg> like the insect stuff
[20:08:12] <fuzzie> i don't think they're timing based
[20:08:27] <dhewg> they're supposed to hit once a sec
[20:08:31] <fuzzie> stuff with event-based (trigger-based) reoccuring hits are known-broken, we discussed the other day
[20:08:34] <dhewg> at least the description reads so
[20:08:50] <dhewg> k, because they're totally overpowered :)
[20:09:00] <fuzzie> oh right there's a 'once per round' or 'every round' modifier
[20:09:01] <fuzzie> buahwaha.
[20:09:14] <dhewg> yeah, they hit insanely fast
[20:09:30] <dhewg> or the guardians in the dungeon on wind something hills
[20:09:30] <fuzzie> tomprince: we'd *really* better have some tests before that code gets fiddled with any more, though
[20:09:36] <dhewg> they have this fire spell
[20:09:43] <dhewg> its like bam bam bam dead
[20:10:09] <fuzzie> i'm not going to touch that code for now i'm afraid
[20:10:15] <fuzzie> i don't know why it's like ti is
[20:10:36] <dhewg> np, i can imaging that this is something deep in the engine
[20:10:46] <dhewg> good thing they're stupid as fuck
[20:10:50] <fuzzie> well, it's more that it *isn't* something deep in the engine, and it should be :P
[20:11:01] <dhewg> i open the door, shoot with an bow until they drop dead
[20:11:08] <dhewg> they dont do anything then :P
[20:11:24] <fuzzie> since it's meant to fire on event, and instead it's just firing on 'did that event maybe happen sometime in recent months? yay, let's fire!'
[20:11:46] <dhewg> sounds like torgal :P
[20:12:52] <fuzzie> my everhelpful irclog has some fuzzie claiming that fx_apply_effect_repeat's 'every second' actually applies 'every frame'
[20:13:14] <fuzzie> and that does seem to still be the case
[20:13:21] <dhewg> according to the insect swarm that may match
[20:13:34] <fuzzie> 0x110, if you have ctrl-m for relevant actors
[20:14:21] <fuzzie> it's a hilariously bad effect
[20:15:02] <fuzzie> it works in the original engine by maintaining a list of pending repeats, and the list is recreated every time the effect list changes, and the effect itself *adds effects to the list*
[20:15:28] <fuzzie> also it's checking the wrong timer
[20:15:30] <fuzzie> fail
[20:15:44] <dhewg> hehe
[20:16:03] --> edheldil_ has joined #gemrb
[20:16:29] <fuzzie> the more i poke at this file stuff, the more it's horrible
[20:19:22] <dhewg> is this pathfinding like what its in the original?
[20:20:13] <fuzzie> it is bg1-level pathfinding
[20:20:28] <dhewg> hm
[20:20:46] <dhewg> it really is annoying on small paths/spots
[20:20:50] <fuzzie> yes
[20:21:07] <fuzzie> i think starting with iwd it improved
[20:21:30] <fuzzie> but i have original bg2 open and, while it's much less stupid than gemrb, it's still really annoying
[20:22:04] <dhewg> i remember it only vaguely
[20:22:40] <fuzzie> it's a really difficult problem
[20:22:48] <fuzzie> but gemrb doesn't even try
[20:22:49] <dhewg> yeah
[20:23:10] <fuzzie> if someone wants a gemrb project, 'fixing the pathfinder' would probably be a good one
[20:23:45] <dhewg> the most annoying thing is when moving more than one actor from a to b at the same time
[20:23:57] <fuzzie> well, we do some silly things there
[20:24:19] <dhewg> if its a small path, one actor is not even cosidering that the other might move as well
[20:24:23] <fuzzie> the original staggers the actors slightly, and is clever about ignoring actors who it knows will be out of the way
[20:24:45] <fuzzie> people here usually say bumping is the issue, but the original engine really does stupid paths which don't bump, except on a very local basis
[20:24:57] <dhewg> so sometimes one actor makes a loooong way, and sometimes running into rooms loaded with monsters
[20:25:10] <fuzzie> ('bumping' is something they added in iwd i think, where actors will 'bump' each other out of the way to get past)
[20:27:28] <dhewg> and there's a gfx priority issue
[20:29:50] <fuzzie> fireplaces?
[20:30:02] <dhewg> no, loot
[20:30:15] <fuzzie> oh, hm, that's new
[20:30:19] <dhewg> its supposed to be drawn... whats it called?
[20:30:37] <dhewg> what word am i looking for?
[20:30:44] <dhewg> like grid-interlaced
[20:30:46] <lynxlynxlynx> in the foreground
[20:31:34] <dhewg> well, its supposed to be, lets say semi-visible when covered by the area gfx
[20:31:34] <fuzzie> i don't know where we draw loot, honestly
[20:31:45] <dhewg> sometimes it is, but not always
[20:31:53] <fuzzie> seems unlikely to be drawn after wallgroups though
[20:31:56] <dhewg> try to kill a monster with loot near a wall
[20:32:01] <dhewg> you wont see the loot
[20:32:07] <dhewg> save+reload and you'll see it
[20:32:32] <lynxlynxlynx> hint: ctrl-w coalesces all visible loot under the cursor
[20:32:52] <lynxlynxlynx> ctrl-j jumps around for faster travel
[20:33:23] <dhewg> thats cheating :P
[20:33:31] <dhewg> nice for testing
[20:34:07] <fuzzie> sure, but it is nice for testing
[20:35:11] <tomprince> memstream branch on github. used with slices of <= 4096
[20:35:12] <lynxlynxlynx> don't jump to far and it's an ease-of-use enhancement
[20:35:22] <lynxlynxlynx> too far
[20:36:01] <lynxlynxlynx> ctrl-w even more so; but still need to make it fill stacks
[20:36:02] <fuzzie> tomprince: does it work? :P
[20:36:14] <tomprince> I can load games.
[20:36:30] <tomprince> I even actually killed some things this time.
[20:36:32] <fuzzie> in early engine, or bg2?
[20:36:36] <tomprince> bg2
[20:36:52] <fuzzie> ok. well, let me try it
[20:39:01] <fuzzie> although that is not so easy
[20:39:14] <fuzzie> some days git is irritatingly dumb
[20:40:17] <fuzzie> and all days cmake is irritatingly dumb. alas.
[20:40:27] <tomprince> Not working...
[20:40:45] <fuzzie> no?
[20:44:41] <fuzzie> indeed it is not
[20:45:42] <fuzzie> right, because you're calling ReadDecrypted on the wrong stream
[20:47:32] <fuzzie> also passing a size param as int, wah :P
[20:48:13] <fuzzie> hm, so, some hasty patching-up of the decryption later, it now segfaults on me
[20:48:34] <fuzzie> oh, other issue
[20:48:52] <tomprince> just as sec, I think I may have both fixed.
[20:49:00] <fuzzie> pure virtual method called
[20:49:00] <fuzzie> terminate called without an active exception
[20:49:08] <fuzzie> ^- ok, that is an achivement
[21:00:27] <tomprince> New version pushed. I am still not sure about the decryption. I think I may be too eager.
[21:02:06] <fuzzie> not sure if it works?
[21:03:58] <fuzzie> the trouble with the decryption stuff as it stands is that it's got to be done by the Read() on the stream
[21:39:34] <dhewg> awwwww Couldn't create animationfactory: mdr13114 (1200)
[21:39:55] <dhewg> and the same palette issue as on the other dragon
[21:40:33] <lynxlynxlynx> yeah, they're wierd
[21:40:46] <lynxlynxlynx> some frames are perfect, others are all pixelated
[21:41:22] <fuzzie> a 0x12xx anim id?
[21:45:14] <fuzzie> i think doing it methodically is only option, but time-consuming
[21:45:47] <lynxlynxlynx> mhm
[21:48:14] <fuzzie> and looking at the BAMs is definitely not reliable
[21:48:51] <dhewg> i dont know if this is related to the animation, it looks like it is, but the fight itself is kinda messed up too
[21:49:16] <dhewg> he had a few invisible frames, and was mostly doing nothing when stuck there
[21:49:44] <dhewg> i could beat him with basically just clubs :P
[21:50:26] <fuzzie> heh
[21:50:29] <fuzzie> 0.6.4 or master?
[21:50:39] <dhewg> my 0.6.4 branch
[21:50:48] <dhewg> master is really just a slideshow here
[21:51:35] <dhewg> oh, and i got that dialog weirdness again
[21:51:54] <dhewg> after the red one dropped dead i got "minsc: has nothing to say to you"
[21:52:18] <dhewg> he was probably going to say how awesome i am, i guess :)
[21:52:31] <fuzzie> not so good :P
[21:53:37] <dhewg> yeah, but it looks like the same issue again
[21:53:42] <dhewg> 3rd time or so i think
[21:55:04] <fuzzie> right
[21:55:09] <fuzzie> did i get a save for that? i forget
[21:55:49] <dhewg> the broken one
[21:55:57] <dhewg> in front of reijiek's house
[21:56:09] <dhewg> but the locals from nalia are missing in there
[21:56:38] <dhewg> but if you set 'torgaldies' on her, you get that nothing-to-say line
[21:56:55] <fuzzie> this is the one with the DestroyItem coming second?
[21:57:18] <dhewg> uhm, i think so :)
[21:58:32] <fuzzie> i think i'm a bit too tired to make sense of that
[21:59:29] <dhewg> feeling kinda the same
[21:59:41] <dhewg> mostly just clicking random crap here :)
[21:59:47] <fuzzie> the important thing is just that the dialog init needs delaying
[22:05:51] <dhewg> oh, but i think i just noticed why the text in the item description box is cut off
[22:06:02] <dhewg> the first letter is always this fancy gfx
[22:06:13] <dhewg> text next to it is cut off
[22:06:19] <dhewg> lines below that are fine
[22:12:50] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:17:03] <-- edheldil_ has left IRC (Ping timeout: 258 seconds)
[22:17:22] --> barra_home has joined #gemrb
[22:25:40] --> edheldil_ has joined #gemrb
[22:31:59] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[22:40:51] <-- barra_home has left IRC (Quit: Verlassend)
[22:51:06] <CIA-52> GemRB: 03tom.prince * r561c676f85c6 10gemrb/gemrb/core/GameData.cpp:
[22:51:06] <CIA-52> GemRB: GameData: Properly error out when we can't load a BAM.
[22:51:06] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[23:33:22] <CIA-52> GemRB: 03tom.prince * r9e9658635319 10gemrb/gemrb/ (60 files in 19 dirs):
[23:33:22] <CIA-52> GemRB: Remove all the unused autoFree parameters.
[23:33:22] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>