#gemrb@irc.freenode.net logs for 4 Mar 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[01:11:29] --> thomcom has joined #gemrb
[01:12:22] --> edheldil has joined #gemrb
[01:12:22] --- ChanServ gives channel operator status to edheldil
[01:16:56] <-- edheldil has left IRC (Ping timeout: 250 seconds)
[03:05:09] <-- thomcom has left IRC (Quit: Page closed)
[04:24:44] <-- brada has left IRC (Quit: brada)
[04:27:03] --> brada has joined #gemrb
[04:47:13] <-- brada has left IRC (Ping timeout: 252 seconds)
[04:56:11] --> brada has joined #gemrb
[04:58:37] <-- brada has left IRC (Client Quit)
[05:06:34] <-- psch has left IRC (Ping timeout: 246 seconds)
[05:06:41] --> psch has joined #gemrb
[07:14:40] <wjp> those android pixel format constants should now be fixed in SDL
[07:40:51] --> lynxlynxlynx has joined #gemrb
[07:40:51] --- ChanServ gives channel operator status to lynxlynxlynx
[08:03:52] --> edheldil has joined #gemrb
[08:03:53] --- ChanServ gives channel operator status to edheldil
[09:18:45] --> i30817 has joined #gemrb
[09:19:28] <i30817> psch: in classical java, a IO slowdown like that would mean you're not buffering writes. I don't know if FileChannel is buffered already thou.
[09:20:13] <i30817> Another possibility is that extracting the compressed archive not in the order it 'wants' is slower because it has to begin uncompressing at the end.
[09:20:29] <fuzzie> hm
[09:20:33] <i30817> Solid rar archives are like that (on junrar, a unrar port)
[09:20:36] <fuzzie> what's this referring to?
[09:21:06] <fuzzie> i mentioned before that reading zip files out of apks is no fun because you can't seek
[09:21:08] <i30817> [15:07:40] <psch> okay, i have unhardcoded, GUIScripts and override packaged into the apk, extracting them on run
[09:21:10] <i30817> [15:07:51] <psch> that adds about 3 or 4 minutes to the start up time of the application
[09:21:16] <fuzzie> ah, right
[09:21:23] <fuzzie> i did also mention that there is a Stream class for doing this :-P
[09:22:28] <fuzzie> ZipInputStram, specifically. which, as you mention, avoids the 'not in order' problem by forcing you to do it in-order.
[09:23:21] <i30817> But if you ask for files 'out of order' it may very well be 'restarting' the stream, thus turning it exponential.
[09:23:32] <fuzzie> well, it's actually worse than that
[09:23:56] <fuzzie> with a zip-inside-a-zip, you have to restart every time you seek to anything
[09:24:05] <i30817> lol
[09:24:18] <i30817> wtf
[09:24:22] <fuzzie> so if you use random-access zip code then it will seek again and again and again
[09:24:35] <fuzzie> because decompression has to start again from the beginning, due to the parent zip
[09:25:37] <fuzzie> in theory what psch said about not compressing the apk should help, but it's rather difficult to get google's tools not to secretly compress the apk behind your back when you're not looking
[09:25:51] <i30817> Sad picture, but i guess mounting zips inside of zips is something best left for in-memory only filesystems.
[09:26:39] <i30817> Well, anyway, check the extraction sort order to see if it isn't that.
[09:26:48] <fuzzie> yes, that is definitely a good idea :)
[09:27:02] <fuzzie> thanks for mentiong it, I'll ask psch about it later if you're not around
[10:13:51] <xrogaan> heh, avenger's got a job ?
[10:24:39] <fuzzie> a more time-consuming one :P
[10:27:19] --> WingedHussar has joined #gemrb
[11:27:41] <-- i30817 has left IRC (Quit: ChatZilla 0.9.90 [Firefox 19.0/20130227155931])
[11:56:11] --> kida has joined #gemrb
[12:25:53] <-- |Cable| has left IRC (Ping timeout: 252 seconds)
[12:36:25] <-- kida has left IRC (Quit: Leaving)
[12:38:28] --> |Cable| has joined #gemrb
[12:40:21] --> kida has joined #gemrb
[12:44:20] <edheldil> fuzzie: really? What does he do?
[13:28:56] <lynxlynxlynx> bg2ee by now probably
[14:38:39] --> brada has joined #gemrb
[15:31:01] <-- brada has left IRC (Ping timeout: 252 seconds)
[15:41:19] --> brada has joined #gemrb
[16:05:33] <-- WingedHussar has left IRC (Quit: WingedHussar)
[16:08:54] <psch> http://nopaste.info/b6466288cd.html this is what i'm doing in the gemrb activity
[16:08:58] <Seniorita> Nopaste - powered by project-mindstorm IT Services
[16:09:14] <psch> i haven't created any zip files from override etc, i copied the folders into assets/
[16:10:16] <psch> uncompressed vs compressed apk is about 10 seconds faster, if at all
[16:10:43] <psch> but the uncompressed apk is still only ~6.7mb, whereas the assets folder itself is almost 10mb on my disk
[16:10:52] <psch> desktop disk that is
[16:11:31] <psch> for reference, the compressed apk is around 4mb
[16:13:53] <psch> also, disregard the comment on getExternalFilesDir(null), it should get null for general purpose files
[16:14:17] <psch> iirc, getFilesDir() can't take null because it's for music files or similar, but i'm not sure
[16:14:38] <fuzzie> psch: the question is, how are you extracting them?
[16:15:36] <psch> if anything, the assetManager extracts them
[16:15:50] <psch> which probably has exactly the problem you stated, i.e. starting over for each file
[16:17:21] <fuzzie> well, looking at the code
[16:17:25] <fuzzie> you shouldn't allocate the buffer inside the loop
[16:17:30] <fuzzie> you shouldn't be using buffered input/output streams
[16:17:37] <fuzzie> you shouldn't have a tiny 8192-byte buffer
[16:18:01] <psch> okay
[16:18:19] <psch> plain filestreams?
[16:18:37] <fuzzie> well, an InputStream for in, and a plain FileOutputStream for out, I guess
[16:19:11] <fuzzie> I know very little about Java so I don't know if there's a smarter way here..
[16:19:31] <psch> i did find this http://www.baptiste-wicht.com/2010/08/file-copy-in-java-benchmark/2/
[16:19:33] <Seniorita> File copy in Java - Benchmark - @Blog("Baptiste Wicht")
[16:21:06] <fuzzie> that looks like it makes sense
[16:21:32] <fuzzie> obviously you can't use channels here
[16:21:43] <psch> well, i did use them
[16:21:54] <psch> but it was even slower than what i pasted
[16:21:59] <fuzzie> yeah, i mean, you can't usefully use them
[16:22:16] <psch> i see
[16:22:24] <fuzzie> well.. in theory you should be able to if your apk is truly uncompressed
[16:22:41] <fuzzie> do you have an uncompressed apk somewhere?
[16:23:01] <psch> not uploaded, no
[16:23:03] <psch> i can do that though
[16:24:36] <fuzzie> *how* did you use channels?
[16:25:15] <psch> pretty much exactly as im using streams
[16:25:27] <fuzzie> right
[16:25:28] <psch> with a bit less code, obviously, because they have copyT
[16:25:31] <psch> *copyTo
[16:26:01] <fuzzie> so, transferTo between two channels?
[16:26:08] <psch> yeah
[16:26:34] <fuzzie> how did you get the source channel?
[16:26:44] <psch> from AssetManager
[16:27:03] <fuzzie> yes, but, how? :)
[16:27:21] <psch> let me look it up
[16:27:31] <fuzzie> thanks
[16:35:24] <psch> i think it was assetManager.openFd(file).createInputStream() but im not finding the google results i was referencing and didn't keep the code
[16:35:43] <psch> err
[16:35:48] <psch> that doesn't even make sense
[16:35:52] <fuzzie> no?
[16:35:53] <psch> cause it's not a channel
[16:36:18] <fuzzie> well then .getChannel() on the end
[16:36:22] <psch> yeah i definitely should CVS this stuff i do
[16:36:26] <psch> that could be it, yeah
[16:36:41] <fuzzie> so openFd() is the best option if you can use it
[16:38:50] <|Blaze|_> Have you tried using the SDL_RWOPS stuff at all?
[16:38:54] <fuzzie> but if it's slower than I guess not
[16:38:59] <fuzzie> |Blaze|_: it's just another layer of indirection here
[16:41:35] <fuzzie> I mean: you could make some of our I/O stuff use rwops directly but then you'd still have to deal with python, and you'd presumably want to write custom code anyway to keep track of what is/isn't present, etc.
[16:41:58] <fuzzie> and there's no good reason you can't unpack this stuff in a manner of seconds, you'd think.
[16:42:09] <|Blaze|_> ahh, I guess that makes it a bit trickier
[16:43:34] <fuzzie> it all seems kind of stupid, I assumed this would be trivial :/
[16:45:22] <psch> for reference, copying the files over usb with adb push - all 2026 of them - takes me about 90 seconds
[16:45:30] <psch> that's 1/3 of the time i take to extract from the apk
[16:45:43] <fuzzie> I expect adb is really really inefficient at this too.
[16:46:03] <psch> i wouldn't know how to smartly benchmark this
[16:46:10] <|Blaze|_> yeah, adb seems to run at USB 1 speeds
[16:46:18] <psch> maybe mount the sdcard per sshfs and copy over network?
[16:46:18] <fuzzie> I'd be interested to hear what happens if you allocate the buffer outside the loop, make it a decent size (1mb, maybe?) and don't use the buffered streams.
[16:47:47] <psch> so new byte[1024 * 1024] and toss the new Buffered.. stuff and take the streams directly
[16:48:04] <psch> and move the allocation outside of the loop
[16:48:14] <fuzzie> something like that.
[16:48:15] <psch> that does actually give me pretty much the same speed
[16:48:30] <psch> i did that after you suggested it, sorry for not reporting right away
[16:48:54] <fuzzie> that is quite spectacularly weird then.
[16:48:55] <psch> a notable change i get is loads of GC calls
[16:49:49] --> Coriander has joined #gemrb
[16:50:21] <psch> D/dalvikvm(17613): GC_FOR_ALLOC freed 0K, 6% free 9401K/9976K, paused 14ms, total 14ms
[16:50:24] <psch> D/dalvikvm(17613): GC_CONCURRENT freed <1K, 6% free 9401K/9976K, paused 2ms+2ms, total 14ms
[16:50:27] <psch> pretty much that, over and over
[16:51:12] <brada> ive never been a fan of GC :/
[16:51:16] <wjp> what does your code look like now?
[16:52:33] <psch> http://nopaste.info/4d08eb49a5.html like this
[16:52:34] <Seniorita> Nopaste - powered by project-mindstorm IT Services
[16:54:10] <psch> did i miss something?
[16:55:06] <brada> well if you are getting loads of GC activity it seems something is amiss
[16:55:10] <brada> tho i dont know what
[17:01:25] <|Blaze|_> maybe do a timing without actually doing the write
[17:08:19] <psch> commenting out.write() gives me about 3.5 minutes as well
[17:08:29] <psch> which is kinda good news, as it means writing isn't the slow part, maybe?
[17:09:28] <fuzzie> well as i30817 was saying, it might be ordering issues
[17:10:31] <fuzzie> but if openFd() succeeds then it really shouldn't be a big problem..
[17:10:38] <-- |Cable| has left IRC (Remote host closed the connection)
[17:10:49] <fuzzie> (openFd only works on uncompressed files, which perhaps you already worked out)
[17:12:51] <fuzzie> to further continue with |Blaze|_'s point, what happens if you also comment out the reads, though?
[17:13:08] <-- brada has left IRC (Quit: brada)
[17:13:29] <psch> as in, comment the whole inner while()?
[17:13:53] <fuzzie> yeah
[17:15:25] <psch> http://filebin.ca/Z3Mnt93YRly this is the uncompressed apk btw
[17:15:27] --> |Cable| has joined #gemrb
[17:15:39] <psch> i think i didnt mention the link yet
[17:16:32] <psch> code inside obviously is about 45 minutes old, although there hasn't really been any progress i guess
[17:17:15] <fuzzie> well that is certainly uncompressed
[17:18:10] <psch> the while loop doesn't do much either it seems, im still around 3.5 minutes
[17:18:27] <psch> this points towards assetManager not being clever about opening files, doesn't it
[17:18:32] <|Blaze|_> good news, the copy isn't slow!
[17:19:41] --> brada has joined #gemrb
[17:21:45] <-- |Cable| has left IRC (Ping timeout: 240 seconds)
[17:23:21] --> |Cable| has joined #gemrb
[17:23:46] <-- |Cable| has left IRC (Remote host closed the connection)
[17:26:42] <-- brada has left IRC (Quit: brada)
[17:27:48] --> |Cable| has joined #gemrb
[17:34:30] <-- |Cable| has left IRC (Ping timeout: 252 seconds)
[17:36:00] --> |Cable| has joined #gemrb
[17:40:39] <psch> well, i changed it to open the apk as zip directly
[17:40:46] <psch> and that took about 2.3 minutes
[17:40:57] <psch> and i accidentally extracted everything, not only assets
[17:42:13] <-- |Cable| has left IRC (Ping timeout: 245 seconds)
[17:43:44] --> |Cable| has joined #gemrb
[17:44:41] <psch> but it's faster so that's still good
[17:51:52] --> brada has joined #gemrb
[17:52:40] <fuzzie> i was actually wondering how expensive List() might be, too
[17:52:52] <-- |Cable| has left IRC (Remote host closed the connection)
[17:53:12] <psch> im done to a bit over a minute for only the assets
[17:53:30] <psch> with a code snippet i took off stackoverflow
[17:53:48] <psch> http://stackoverflow.com/a/7108813
[17:53:52] <Seniorita> How to unzip files recursively in Java? - Stack Overflow
[17:54:06] <psch> i did change it to now use buffered streams, and i removed the recursive call because i don't have zips inside zips
[17:54:20] <psch> *not use buffered
[17:54:45] <-- kida has left IRC (Ping timeout: 240 seconds)
[17:54:53] <psch> oh, and 1mb buffer, that too
[17:55:39] <psch> im getting what seems to be even more GC action now
[17:56:00] <|Blaze|_> does Log.d have a timestamp? If so I'd sprinkle a bunch of them around and see where the big jumps are
[17:56:30] <brada> does android not have a profiler?
[17:56:38] <|Blaze|_> if(assetManager.list(inFile.getPath()).length > 0) <-- that may be the slow part
[17:57:55] <|Blaze|_> line 58 in that paste
[17:58:56] <psch> http://nopaste.info/d42eee72a8.html this gets me about 75 seconds
[17:59:01] <Seniorita> Nopaste - powered by project-mindstorm IT Services
[17:59:02] <psch> without using AssetManager at all
[17:59:29] <psch> but the GC seems to dealloc the buffer after every file
[17:59:36] <psch> naively judging by the log output at least
[17:59:45] <psch> I/dalvikvm-heap(19683): Grow heap (frag case) to 9.813MB for 1048592-byte allocation
[17:59:48] <psch> D/dalvikvm(19683): GC_FOR_ALLOC freed 1024K, 13% free 8861K/10144K, paused 16ms, total 16ms
[17:59:51] <psch> D/dalvikvm(19683): GC_CONCURRENT freed 1K, 13% free 8861K/10144K, paused 3ms+2ms, total 17ms
[17:59:54] <|Blaze|_> yeah, no new byte[BUFFER] inside the loop
[18:00:02] <psch> right
[18:00:03] <psch> i missed that
[18:00:04] <psch> thanks
[18:00:43] --> |Cable| has joined #gemrb
[18:01:04] <-- brada has left IRC (Ping timeout: 256 seconds)
[18:02:29] <psch> well, 5 seconds sounds good to me
[18:06:53] <fuzzie> you got it down to 5s?
[18:06:53] --> brada has joined #gemrb
[18:07:01] <psch> yeah
[18:07:05] <-- |Cable| has left IRC (Ping timeout: 255 seconds)
[18:07:11] <psch> that's including deleting the files before
[18:07:18] <psch> and also a moment of gemrb init
[18:07:23] <psch> because my timing isn't really rigorous
[18:07:37] <psch> but, yeah, it's fast now
[18:09:00] <psch> it's the latest paste, with the buffer allocation moved outside the loop
[18:10:41] <fuzzie> great
[18:14:15] <psch> lesson: fuzzie was right all along
[18:18:57] <brada> i thought you said you had already moved it before?
[18:18:58] <psch> now i just gotta get the call SDL_AndroidGetExternalStorageDirectory() out of Interface.cpp i think?
[18:19:16] <psch> brada: yes, i had, but i took code from stackoverflow which had the buffer alloc inside the loop
[18:19:29] <psch> the stackoverflow code is extracting a zip
[18:19:34] <brada> i hate when stack overflow has bad advice lol
[18:19:48] <psch> i previously read each file from the assetManager, which was the slow part
[18:20:20] <psch> because overhead for reopening assets for each file and listing files to see if it's a directory and probably other things
[18:20:44] --> |Cable| has joined #gemrb
[18:21:13] <psch> fwiw, arbitrary paths for the game data also seem to work
[18:21:25] <psch> as in, anything below /sdcard/
[18:21:31] <psch> which makes sense i guess
[18:23:39] --> Cable_ has joined #gemrb
[18:25:23] <-- |Cable| has left IRC (Read error: Operation timed out)
[18:25:36] <-- Cable_ has left IRC (Remote host closed the connection)
[18:38:40] --> |Cable| has joined #gemrb
[18:40:19] <-- |Cable| has left IRC (Remote host closed the connection)
[18:44:56] --> |Cable| has joined #gemrb
[18:52:52] <-- |Cable| has left IRC (Remote host closed the connection)
[18:54:51] --> |Cable| has joined #gemrb
[18:57:17] --> Cable_ has joined #gemrb
[19:00:20] <-- |Cable| has left IRC (Ping timeout: 250 seconds)
[19:03:59] --> Yoshimo has joined #gemrb
[19:18:04] <-- Cable_ has left IRC (Remote host closed the connection)
[19:21:30] --> |Cable| has joined #gemrb
[19:24:07] --> Cable_ has joined #gemrb
[19:27:32] <-- |Cable| has left IRC (Ping timeout: 255 seconds)
[19:50:44] <-- brada has left IRC (Quit: brada)
[19:54:39] <lynxlynxlynx> awesome
[19:56:43] <psch> additionally, setting $HOME with setenv in GemRB.cpp - where we need SDL.h anyway and so have SDL_AndroidGetExternalStoragePath() already - works too
[19:57:23] <psch> afaict, the only change for the user is putting GemRB.cfg into /sdcard/Android/data/net.sourceforge.gemrb/files/.GemRB/ and no autodownload and sdl configure screen
[19:58:00] <psch> no sdl configure screen is a bit sad i think, no autodownload is actually good cause we always have the correct files now and moving a .cfg shouldnt be a huge deal
[19:58:20] <psch> im not sure yet if i need GemRBOverridePath inside my .cfg with HOME set, ill test that now i think
[20:05:43] <psch> okay gemrb doesn't look in $HOME/.GemRB/ for anything but the config i guess
[20:06:17] <psch> everything else is looked in for the current working directory, which doesn't work for android
[20:07:54] <psch> i guess i could setenv("PWD", getenv("HOME"), 1) but that's probably kind of evil
[20:09:46] <psch> if it even actually does everything a chdir() would do..
[20:11:15] --> brada has joined #gemrb
[20:12:51] <brada> setting $HOME is kind of a hack
[20:13:11] <brada> but nobody cares for now
[20:14:06] <psch> well it's cleaner than including SDL.h in Interface i'd guess
[20:14:13] <brada> and nothing is stopping you from reimplementing what ever settings interface you desire
[20:15:12] <psch> i dont follow
[20:15:28] <brada> you said you miss pelyas settings interface
[20:15:43] <brada> configure screen
[20:15:45] <psch> oh right
[20:15:53] <psch> yeah that would be nice, but it's far off for me tbh
[20:15:55] <fuzzie> yes, but it'd be a lot of work and it'd require a bunch of work on the backend too.
[20:16:13] <psch> id rather have users not have to set GemRBOverridePath etc in the .cfg for now
[20:16:21] <brada> well you could at least make a text box that opens gemrb.cfg...
[20:16:27] <brada> that would at least be handy
[20:16:58] <psch> yes, it would be, but it'd still display the (totally justified) comments saying "You probably don't have to change anything below this line"
[20:17:25] <brada> make an android specific copy of gemrb.cfg stub
[20:17:30] <brada> and put it in the apk
[20:18:10] <brada> id still like to decouple the interface from the cfg file at some point...
[20:18:17] <psch> i don't know the path during build time
[20:18:43] <psch> but i guess i can check for gemrb.cfg in the activity
[20:18:47] <psch> and edit it appropriately
[20:19:36] <psch> i think i like that solution, although it might break for the user on android upgrades
[20:19:59] <psch> although probably not, seeing as the paths stay around and just get fuse mounted differently
[20:20:45] <psch> ah no that's wrong, it would break assuming the fuse mount location changes
[20:21:24] <psch> but yeah, that#s really edge-casey so who cares
[20:23:53] <brada> well if you told me you would be willing to make a config interface using gui controls then i would be more driven to finish my work on separating the cfg from the interface
[20:25:09] <psch> in general, yeah, but it'll be probably a month or so until i can start getting to that
[20:26:31] <psch> i do want the general build stuff done, but i gotta get back to some other stuff in the next few days
[20:26:40] <brada> take your time
[20:26:59] <brada> i still have to do the SDL touch update stuff anyway
[20:32:05] <-- Cable_ has left IRC (Remote host closed the connection)
[20:33:48] --> |Cable| has joined #gemrb
[20:36:24] --> Cable_ has joined #gemrb
[20:39:36] <-- |Cable| has left IRC (Ping timeout: 245 seconds)
[20:39:40] --> fizzle has joined #gemrb
[20:46:31] <fizzle> fuzzie: do you have some time to discuss yesterday's scripting issues more?
[20:54:44] <fuzzie> hm, didn't you have a hack which worked?
[20:55:09] <fizzle> there were two issues, but yes
[20:55:40] <fizzle> I just don't know what the thing is supposed to do
[20:56:00] <fizzle> and the first one probably isn't a hack :)
[20:56:47] <fizzle> what's LeaveAreaLUAPanic, for example, and how does it relate to LeaveAreaLUA?
[20:57:33] <fizzle> the bg1 scripts should all work fine when the Panic version simply does nothing at all
[20:57:53] <fizzle> I doubt they'd create a script command for that, though
[21:02:18] --> thomcom has joined #gemrb
[21:03:09] <fuzzie> I dooon't know.
[21:04:05] <-- Yoshimo has left IRC (Quit: Yoshimo)
[21:04:52] <fuzzie> past`fuzzie doesn't know either, judging by irc log
[21:05:27] <fizzle> heh, what did past fuzzie implement? ;)
[21:05:48] <fuzzie> [19:04:38] <fuzzie> i guess the LeaveAreaLUAPanic before the LeaveAreaLUA is some hack to fix a bug
[21:05:57] <fuzzie> [19:04:42] <fuzzie> but perhaps Avenger knows better
[21:06:04] <fuzzie> translation: "I have absolutely no clue"
[21:06:08] <fizzle> any idea whether they always appear in pairs in the other games, too?
[21:06:22] <fuzzie> no, but someone with script dumps should be able to tell you
[21:07:09] <fizzle> alright, anyone with script dumps around?
[21:07:28] <fizzle> also, did you have a look at the GetActorFromObject patch?
[21:08:08] <fuzzie> also not
[21:08:12] <fuzzie> it sounded like it was the wrong approach though
[21:08:21] <fuzzie> but I didn't look so that is a stupid thing for me to say :P
[21:08:26] <fizzle> in what way?
[21:08:52] <fizzle> time to look at it now if I reupload the patch?
[21:08:58] <fuzzie> well, it sounded like the caller shouldn't be passing null if it expects to get itself?
[21:09:01] <fuzzie> um, maybe.
[21:09:10] <fizzle> it did pass NULL
[21:09:18] <fizzle> but didn't get itself
[21:09:32] <fuzzie> yes, but why can't it just use itself right away?
[21:10:13] <fizzle> it could, but none of the action implementations seem to short-circuit it this way
[21:10:14] <fuzzie> you made it sound in logs like it was going through GetActorFromObject for no good reason
[21:10:39] <fizzle> they all rely on GetActorFromObject
[21:10:47] <fizzle> I don't know if there's a good reason
[21:10:50] <fuzzie> well
[21:10:57] <fuzzie> i guess first question, what's the script line that fails?
[21:11:00] <fizzle> well, extending the trigger for gemrb purposes could be one
[21:11:12] <fizzle> NumTimesTalkedTo(0)
[21:12:01] <fuzzie> I would be tempted to fix it by checking for NULL, I guess.
[21:12:25] <fizzle> many other triggers are likely to fail for the same reason, though
[21:12:27] <fuzzie> but let me look at your patch too.
[21:12:32] <fuzzie> well, which other triggers?
[21:12:42] <fuzzie> I mean, if you have actual examples then that'd be great.
[21:13:12] <fizzle> everything that calls GetActorrFromObject with NULL
[21:13:17] <fuzzie> which is how much, though?
[21:13:22] <fuzzie> that sounds like a pretty odd situation
[21:14:02] <fizzle> http://paste.debian.net/hidden/ba4346f1/
[21:14:07] <Seniorita> Debian Pastezone
[21:14:52] <fuzzie> patch looks harmless.
[21:15:07] <fuzzie> i.e. I have no problem with you applying that.
[21:18:27] <fizzle> alrighty, one down, on to go
[21:40:43] <fizzle> so, I'll leave this here in case somebody with a script dump (edheldil?) reads the backlog
[21:41:30] <fizzle> it'd be great if you could verify whether a call to LeaveAreaLUAPanic is always followed by a LeaveAreaLUA (not necessarily immediately following it)
[21:41:57] <fizzle> the same probably also applies to LeaveAreaLUAPanicEntry and LeaveAreaLUAEntry
[21:42:22] <fizzle> thanks in advance :)
[21:45:45] <-- fizzle has left #gemrb
[22:04:29] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:39:00] <-- brada has left IRC (Quit: brada)
[23:51:43] <-- thomcom has left IRC (Ping timeout: 245 seconds)