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

Archive Today Yesterday Tomorrow
GemRB homepage

[00:04:00] <-- PixelScum has left IRC (*.net *.split)
[00:04:40] --> Drakkar has joined #gemrb
[00:18:00] --> irfaanator has joined #gemrb
[00:19:07] <-- irfaanator has left IRC (Client Quit)
[00:22:43] <-- |Cable| has left IRC (Ping timeout: 260 seconds)
[00:36:16] --> |Cable| has joined #gemrb
[01:48:36] --- ermo is now known as ermo^
[03:17:00] --> fireglow- has joined #gemrb
[03:18:47] <-- fireglow has left IRC (Ping timeout: 240 seconds)
[03:18:47] --- fireglow- is now known as fireglow
[05:20:33] --> PixelScum has joined #gemrb
[05:21:48] <-- Drakkar has left IRC (Ping timeout: 264 seconds)
[05:50:16] --> wjp_ has joined #gemrb
[05:52:35] <-- wjp has left IRC (Ping timeout: 255 seconds)
[05:52:36] <-- PixelScum has left IRC (*.net *.split)
[05:56:49] --> PixelScum has joined #gemrb
[06:03:21] --> Gekz` has joined #gemrb
[06:04:37] <-- Gekz has left IRC (Write error: Broken pipe)
[06:53:01] --> edheldil_ has joined #gemrb
[06:53:37] --> edheldil has joined #gemrb
[06:53:37] --- ChanServ gives channel operator status to edheldil
[07:04:04] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[07:04:08] <-- edheldil has left IRC (Ping timeout: 255 seconds)
[07:20:56] <-- Gekz` has left IRC (Quit: No Ping reply in 180 seconds.)
[07:21:04] --> Gekz has joined #gemrb
[07:21:04] <-- Gekz has left IRC (Changing host)
[07:21:04] --> Gekz has joined #gemrb
[07:36:55] --> edheldil has joined #gemrb
[07:36:55] --- ChanServ gives channel operator status to edheldil
[07:36:55] --> edheldil_ has joined #gemrb
[08:57:18] --> fizzle has joined #gemrb
[09:13:09] <-- edheldil has left IRC (Read error: Operation timed out)
[09:15:47] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[09:20:26] --> lynxlynxlynx has joined #gemrb
[09:20:26] <-- lynxlynxlynx has left IRC (Changing host)
[09:20:26] --> lynxlynxlynx has joined #gemrb
[09:20:26] --- ChanServ gives channel operator status to lynxlynxlynx
[09:35:56] --> rocket_hamster has joined #gemrb
[09:44:09] <-- rocket_hamster has left IRC (Remote host closed the connection)
[09:46:47] <lynxlynxlynx> buhh
[09:47:08] <lynxlynxlynx> such an influx of people that can't be bothered to read the faq/fap
[09:47:26] --- wjp_ is now known as wjp
[09:47:34] --- ChanServ gives channel operator status to wjp
[11:19:10] --> edheldil_ has joined #gemrb
[11:19:49] --> edheldil has joined #gemrb
[11:19:52] --- ChanServ gives channel operator status to edheldil
[11:29:10] <-- edheldil has left IRC (Ping timeout: 260 seconds)
[11:29:36] <-- edheldil_ has left IRC (Ping timeout: 264 seconds)
[11:32:07] <fizzle> should GetActorFromObject with a NULL parameter always return Sender?
[11:32:28] <fizzle> right now it doesn't and that breaks stuff
[11:32:42] <lynxlynxlynx> i doubt it
[11:32:56] <lynxlynxlynx> falling back to the Sender is something the action should decide about
[11:33:07] <fizzle> NumTimesTalkedTo doesn't work right now
[11:33:37] <lynxlynxlynx> that's odd
[11:34:17] <lynxlynxlynx> but how would the Sender as the object help? doesn't it take just a count?
[11:34:52] <lynxlynxlynx> ah
[11:34:54] <fizzle> no, the trigger doesn't check the correct actor
[11:35:15] <lynxlynxlynx> the sender should always be checked, since that's where the talkcount is stored
[11:35:30] <lynxlynxlynx> it doesn't need to call GetActorFromObject at all
[11:36:12] <lynxlynxlynx> i guess it was added as an extension
[11:36:12] <fizzle> well, yes, but the comment says the trigger was extended on purpose
[11:36:43] <lynxlynxlynx> so the extension is misimplemented
[11:37:27] <fizzle> yeah, but the question is, should I add an extra 0-check in the trigger or change GetActorFromObject
[11:37:41] <lynxlynxlynx> the first
[11:37:56] <fizzle> and if the first, what other triggers are affected
[11:38:34] <fizzle> NumTimesTalkedToGT and LT for sure
[11:38:37] <lynxlynxlynx> in which script/dialogue do you see a probelm?
[11:39:01] <lynxlynxlynx> these three work most of the time or we'd have noticed by now
[11:39:18] <fizzle> drizzt.dlg
[11:41:26] <lynxlynxlynx> standard :s
[11:42:11] <fizzle> his TalkCount is now up to 10 but since we keep checking some Gnoll he initiates dialog again and again
[11:44:13] <fizzle> I really wonder how the trigger can work most of the time
[11:44:32] <fizzle> it always simply checks the first actor on the map
[11:51:21] <lynxlynxlynx> works fine with rieg in iwd2 and judging from his globalid, he wouldn't be the first actor
[11:51:28] <lynxlynxlynx> i admit that the code looks that way though
[11:52:08] <fizzle> I didn't have the problem when I met Drizzt on my last playthrough
[11:59:12] <lynxlynxlynx> i've stepped through it now and he does come out as the one returned
[12:01:05] <lynxlynxlynx> :(
[12:01:16] <lynxlynxlynx> this could affect a lot of stuff either way
[12:01:39] <fizzle> do you have objectParameter==NULL?
[12:01:45] <lynxlynxlynx> fuzzie: we need your help
[12:01:54] <lynxlynxlynx> of course
[12:03:56] --> edheldil has joined #gemrb
[12:03:56] --- ChanServ gives channel operator status to edheldil
[12:03:56] --> edheldil_ has joined #gemrb
[12:06:12] <fizzle> ah, AddTarget sorts by distance
[12:06:29] <fizzle> so Myself should normally come first
[12:06:53] <fizzle> unless you've got a dead Gnoll underfoot, I suppose
[12:09:18] <lynxlynxlynx> it check GA_ flags, but this action doesn't pass any
[12:13:33] <fizzle> since the code relies on GetActorFromObject returning Sender in this case I guess we should ensure that Sender is really first in that list
[12:14:00] <fizzle> that is, not only relies on it in this trigger
[12:16:31] <lynxlynxlynx> it would be safest, yes, since i'm not sure all dialogs are pausing in the original
[12:16:49] <lynxlynxlynx> i hope it doesn't break something else
[12:40:28] <fizzle> http://paste.debian.net/hidden/8ad073ab/
[12:40:31] <Seniorita> Debian Pastezone
[12:40:38] <fizzle> I propose this as a fix
[12:40:57] <fizzle> maybe fuzzie can comment on whether she's got a better idea
[12:48:53] <fuzzie> sorry, not home
[12:51:41] <fizzle> no rush
[13:08:50] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[13:08:54] <-- edheldil has left IRC (Ping timeout: 260 seconds)
[13:37:23] <-- fizzle has left #gemrb
[14:02:29] --> Yoshimo has joined #gemrb
[14:10:25] <-- Yoshimo has left IRC (Quit: Yoshimo)
[15:07:40] <psch> okay, i have unhardcoded, GUIScripts and override packaged into the apk, extracting them on run
[15:07:51] <psch> that adds about 3 or 4 minutes to the start up time of the application
[15:08:49] <psch> to be fully consistent with how android wants to manage application life cycles, i should probably delete them in onPause() and onResume(), since the user can upgrade gemrb with gemrb still running
[15:09:05] <psch> which would probably add a few seconds to onPause() and 3 to 4 minutes to onResume()
[15:09:17] <psch> im not sure how i feel about that
[15:24:29] <lynxlynxlynx> let's just say we don't support live upgrades
[15:25:14] <lynxlynxlynx> why is the extraction taking so long?
[15:25:46] <psch> i don't really know
[15:26:07] <psch> intuitively i'd assume random writes of many small files, but that doesn't apply to ssds, does it
[15:27:32] <lynxlynxlynx> unhardcoded and override could be biff-ed, but not the scripts
[15:28:31] <lynxlynxlynx> would require weidu as part of the package generation then
[15:28:48] <lynxlynxlynx> or some iesh scripting
[15:29:03] <lynxlynxlynx> but it would remove most of the fragmentation
[15:29:50] <lynxlynxlynx> 1805 files in unhardcoded, 34 override, 215 scripts
[15:35:05] <psch> im gonna keep looking if im maybe doing something dumb and there's a faster way
[16:39:42] <psch> i did find something that allegedly should be faster, but i guess creating ~1500 FileChannels instead of FileStreams doesn't really help performance
[16:40:05] <psch> i can go about 5-10 seconds faster if i don't compress the apk, guess that's something
[17:05:19] --> brada has joined #gemrb
[17:05:30] <brada> psch: thats really sad
[17:05:32] <brada> :(
[17:06:12] <brada> the ios version can unarchive an entire 2gb game in less time than that
[17:07:47] <psch> yeah im not happy about it either
[17:07:58] <psch> i still can't shake the feeling im doing something wrong though, but...
[17:08:10] <brada> brw the touch api for sdl just got updated
[17:09:24] <brada> so stay away from updating your sdl until we are compatible
[17:09:47] <psch> okay
[17:09:56] <brada> on the plus side touch events no longer create mouse events
[17:09:59] <brada> happy day
[17:10:12] <psch> yeah i saw a patch for a hint that does that somewhere
[17:10:16] <psch> guess that went mainline
[17:10:54] <brada> ok i lied the do, but you can tell if they are created by a touch now
[17:11:17] <psch> mean
[17:11:25] <brada> no thats perfect
[17:11:42] <psch> no i mean it's mean of you to lie heh
[17:12:28] <psch> but never mind that
[17:12:29] <brada> ah
[17:12:45] <brada> well seems like they have even more touch api changes in the pipeline
[17:14:16] <brada> This means that you no longer have to query the touch object to find out the resolution of the touch area
[17:14:18] <brada> woot
[17:14:54] <brada> looks like i will have some work to do next week
[17:15:06] <brada> if i have time :/
[17:15:29] <psch> that should solve the fixed aspect ratio thing, shouldnt it
[17:16:16] <brada> i doubt it
[17:16:31] <brada> it changes the correction formula im sure
[17:16:39] <psch> right
[17:16:46] <brada> you will still get 0…1 for the entire screen ill bet
[17:17:05] <brada> ill just have to wait and see
[17:17:14] <brada> no time for at least 2 days
[17:28:52] <brada> anyway it will make things simpler
[17:28:55] <brada> so im happy
[17:29:21] <brada> and glad i didnt make an attempt to correct the mismatched ratio input :D
[17:52:56] <psch> i think im blaming java for the slow copying, i think the object recreation is the bottleneck, but i can't reuse them
[17:53:17] <psch> afaict, i dont have any choice except copying slowly
[17:53:35] <psch> there's a bunch of benchmarks for copying a single file with multiple methods, but nothing for many files
[17:55:16] <brada> does android not have libarchive?
[17:56:14] <psch> it probably does and you reminded me of fuzzie saying something about unzipping from the apk
[17:56:18] <psch> guess that's what im doing wrong
[17:56:33] <psch> im reading the files from the apk and writing them to disc, extracting parts of the archive should definitely be faster
[18:02:20] <brada> psch: http://stackoverflow.com/questions/2651816/reading-resource-files-from-my-own-apk-in-android-native-environment
[18:02:29] <Seniorita> Reading Resource Files from my own APK in Android Native Environment - Stack Overflow
[18:02:52] <brada> how bout just not compressing the files?
[18:03:22] <psch> im not compressing the apk
[18:03:28] <psch> im also trying to avoid to change native code
[18:03:43] <psch> if i throw the latter out i could read files from the apk directly
[18:03:52] <psch> which is probably the sanest way to do this
[18:04:23] <psch> this reminds me of something i tried to do yesterday, to get around the need to change anything for accessing the config file
[18:04:44] <psch> i tried to modify the map returned by System.getenv() in memory so we can have $HOME inside gemrb
[18:04:59] <psch> but the map isn't stored in memory, it gets recreated on every call to getenv()
[18:05:30] <psch> in conclusion: dear me, stop being scared of c/c++ and actually do sensible stuff inside gemrb instead of insane stuff in the java activity
[18:16:55] <brada> you said "extracting parts of the archive"
[18:17:01] <brada> how is that not compressing?
[18:17:48] <brada> i mean i wish i were more help
[18:17:55] <brada> i know nothing useful here
[18:18:52] <psch> with "archive" i mean the apk in that context
[18:19:14] <psch> which doesn't have to be compressed, but is still packaged
[18:19:23] <psch> probably not the clearest wording possible on my end
[18:24:38] --> Maighstir has joined #gemrb
[18:31:38] <-- brada has left IRC (Quit: brada)
[19:20:06] --> Yoshimo has joined #gemrb
[19:28:49] --> fizzle has joined #gemrb
[19:29:28] --> brada has joined #gemrb
[19:39:18] <fizzle> another scripting problem
[19:39:34] <fizzle> bragecut.bcs does
[19:39:36] <fizzle> LeaveAreaLUAPanic("AR4802","TRBRACAP",[325.469],12)
[19:39:38] <fizzle> ActionOverride("Brage",DestroySelf())
[19:40:11] <fizzle> and the override fails because we've already left the map and Brage's no longer there...
[19:42:23] <lynxlynxlynx> maybe LeaveAreaLUAPanic should be blocking
[20:06:09] <fizzle> is there an easy way to change that?
[20:09:44] <fizzle> and what exactly does blocking mean in the scripting context?
[20:09:53] <fizzle> IÄm not quite getting the comments in there
[20:14:45] <fuzzie> blocking wouldn't help, right?
[20:15:55] <fizzle> not if it means what I think it means
[20:15:56] <fuzzie> probably the leavearea should be delayed a tick, but then you have to make sure brage still runs the action, so not much fun
[20:23:01] <fizzle> hm, no, doesn't sound like fun
[20:27:17] <fizzle> what's the difference between LeaveAreaLUA and LeaveAreaLUAPanic?
[20:28:02] <fizzle> it looks like the Panic version is always followed by the non-Panic one in bg1 scripts
[20:28:14] <fizzle> and if the map only changed in the latter one...
[20:32:58] <fizzle> I just made Panic a noop; seems to work fine
[20:48:19] <lynxlynxlynx> there are many of them, so i don't know, but one difference is that some will move the actor even if he doesn't reach an exit
[20:55:02] --> thomcom has joined #gemrb
[20:56:51] <fizzle> leavearea doesn't check exits
[20:57:11] <fizzle> it removes the area from one map and adds it to another
[20:57:31] <fizzle> s/area/actor/
[20:58:44] <fizzle> and the combination LeaveAreaLUAPanic, then DestroySelf() and other stuff, then LeaveAreaLUA occurs several times
[20:59:09] <fizzle> so it's not just the brage cutscene that's broken
[21:14:01] --> rocket_hamster has joined #gemrb
[21:14:13] <psch> thomcom: did you get anywhere?
[21:15:36] <thomcom> nope, i spent what little time I had yesterday playing BG:EE The Black Pits
[21:15:54] <thomcom> thanks for asking :D
[21:16:25] <-- Yoshimo has left IRC (Quit: Yoshimo)
[21:17:09] <psch> i gotta say, i don't really have any ideas what it could be, except the files not being in the right path
[21:17:30] <psch> this is of course complicated by the fact that i don't have a 4.1 device for testing here, and i dont really want to downgrade my tablet
[21:17:41] <thomcom> i think it is a fragmentation problem
[21:18:47] <thomcom> SDL_AndroidGetExternalStoragePath might return something bad in 4.1.2, or something bad on Samsung, etc
[21:19:23] <thomcom> The SDL source for it looks fine and clearly reyurns a valid path
[21:19:37] <psch> i guess you could add some Log.d() calls to SDLActivity or the GemRB activity, check for the path, trying to create a file, that kinda stuff
[21:19:49] <psch> or i could write the activity if that's more to your liking
[21:20:40] <psch> but that's as far as my ideas for debugging go
[21:22:28] <thomcom> its a c++ function that is failing afaik
[21:23:18] <thomcom> LoadConfig(const char* filename)
[21:23:33] <psch> yeah, that one just tries to find the file in the path it gets in LoadConfig()
[21:23:43] <psch> i.e. if it fails it means a) the path is wrong or b) the file isn't there
[21:24:16] <thomcom> yup
[21:24:33] <thomcom> path seems wrong - permissions?
[21:24:50] <thomcom> well, path seems right, but the function fails
[21:24:53] <psch> considering SDL_AndroidGetExternalStoragePath returns an app-specific path it's unlikely
[21:25:01] <thomcom> i can shell to that dir
[21:25:17] <psch> unless you set permissions yourself on gemrb.cfg that don't fit the app, but im not sure that's possible
[21:25:32] <thomcom> obviously you cant do much since it is my phone
[21:27:06] <psch> can you give me a recent log?
[21:35:04] <thomcom> same as the pastie from two days ago
[21:35:34] <thomcom> darn three days ago haha
[21:35:37] <thomcom> work's been a drag
[21:35:38] <thomcom> http://pastie.org/6355795
[21:35:39] <Seniorita> #6355795 - Pastie
[21:35:45] <psch> oh right
[21:35:48] <thomcom> i should be working this weekend on work work
[21:35:53] <thomcom> plenty to do, important demo, etc etc sigh
[21:36:34] <psch> and adb shell ls /storage/sdcard0/Android/data/net.sourceforge.gemrb/files/GemRB.cfg shows the file?
[21:37:06] <psch> because if so we can definitely stop right now and you can get back to work cause i really don't have a clue hah :/
[21:38:09] <thomcom> haha
[21:39:44] <thomcom> http://pastie.org/6374588
[21:39:46] <Seniorita> #6374588 - Pastie
[21:39:46] <thomcom> as you can see
[21:40:38] <psch> yup, i see
[21:40:42] <psch> i don't understand, but i see
[21:43:00] <thomcom> i'll hard code the path to go to my iwd file directory later and check it
[21:43:02] <thomcom> whenever this demo push is over
[21:51:18] <psch> you could also add a check for Environment.getExternalStorageState() == MEDIA_MOUNTED in the activity and log the result
[21:51:43] <psch> that's the only thing i can think of, that your device unmounts the fuse mount for the application because it's connected to the computer and the external storage is mounted for the computer
[21:51:57] <psch> i don't know if it should also be unavailable for adb shell, though
[21:55:39] <-- rocket_hamster has left IRC (Remote host closed the connection)
[21:55:59] <wjp> permission problem?
[21:59:22] <psch> for reference, this is my ls -l output for GemRB.cfg: -rw-rw-r-- root sdcard_rw 12704 2013-02-26 12:39 GemRB.cfg
[21:59:42] <psch> i seem to remember thomcom has the same owner and group at least, but i dont know about the permissions
[22:00:16] <psch> i'd assume adb push and whatever the gui tool is have the same umask
[22:04:11] <fuzzie> shouldn't that be completely irrelevant on the sdcard on 4.1 anyway?
[22:05:07] <psch> i think so, yeah
[22:12:40] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:14:33] <thomcom> psch: same error whether or not phone is plugged in at the time
[22:14:48] <thomcom> same preferences and ownership as yours psch
[22:15:38] --> Maighstir_ has joined #gemrb
[22:15:41] <psch> this is really confusing to me
[22:17:10] --> Maighstir___ has joined #gemrb
[22:18:24] <thomcom> maybe my GemRB.cfg file is bad
[22:18:31] <thomcom> but that wouldn't produce that particular error
[22:18:42] <thomcom> if the cfg was bad then i'd get to some later error regarding a particular key/value pair eh
[22:18:46] <-- Maighstir has left IRC (Ping timeout: 240 seconds)
[22:20:34] <-- Maighstir_ has left IRC (Ping timeout: 246 seconds)
[22:20:43] <psch> and empty gemrb.cfg gives me the same error, fwiw
[22:21:00] <psch> oh no, nvm that, wrong lin
[22:21:01] <psch> e
[22:21:08] <thomcom> oh well that's worth something, could be a bad gemrb.cfg then?
[22:21:22] <psch> no, i misread the log, it opens the empty file fine
[22:21:22] <thomcom> oh so it does open the empty gemrb and error later?
[22:21:41] <psch> yeah, it bails on chitin.key
[22:21:46] <psch> warnings about invalid paths before that
[22:22:28] <thomcom> how to launch the project with ndb debug?
[22:22:46] <psch> you should be able to run ndk-gdb --start from the dir you built it in
[22:22:50] <psch> with the phone connected
[22:22:54] <psch> it should start the app
[22:23:06] <psch> assuming you build with ndk-build NDK_DEBUG=1
[22:25:17] <thomcom> looks like the process needs to be running in order to use that line? We're going to the pool
[22:25:21] <thomcom> i can look it up later
[22:26:52] <psch> nah, if you built with ndk-build NDK_DEBUG=1 you can start the application on your phone with ndk-gdb --start from your computer
[22:28:54] <thomcom> yeah but the application launches and then terminates instantly because of no GemRB.cfg you see :D
[22:29:03] <thomcom> need to be able to launch the application via ndb-debug :D
[22:29:26] <thomcom> maybe I can launch the application with an adb debug breakpoint, then launch ndb-debug while it is broken at that line :D
[22:29:37] <|Blaze|_> sometimes you need to throw an SDL_Sleep() in your main
[22:30:08] <psch> ndk-gdb is a script in android-ndk
[22:30:25] <psch> it doesn't trip a bp instantly, but in my tests it interrupted fast enough i think
[22:30:31] <psch> but yeah, what |Blaze|_ said
[22:31:46] <psch> considering trying to read the config is one of the first things the app does, it makes sense to have to delay that to see what it's doing
[22:32:29] <brada> worth a try, but i would love to think there are better ways then sleeping
[22:32:33] <brada> is 2013...
[22:32:52] <|Blaze|_> it is android ;) There's a timing between the app launch and the gdb attach
[22:32:56] <brada> i doubt that will solve it anyway
[22:33:09] <brada> i dont know about the gbd thing
[22:33:37] <brada> you are all making me very happy im not an android developer tho
[22:33:57] <-- fizzle has left #gemrb
[22:34:31] <psch> another thing people apparently do is something like "bool loopit = true; while (loopit) {}" and set loopit to false inside the debugger
[22:34:35] <psch> im not sure that's better
[22:35:09] <brada> its not anymore event driven then sleeping so no
[22:35:12] <thomcom> lol
[22:35:34] <thomcom> pool time
[22:35:36] <psch> have fun
[22:35:47] <brada> im very disappointed that android development seems so cobbled together.
[22:35:50] <thomcom> one day I'll report on my results when clients are not chomping for deliverables
[22:35:59] <thomcom> has anybody played the Black Pits all the way through yet?
[22:36:10] <thomcom> android development is a nightmare, mess, mess
[22:36:44] <|Blaze|_> straight up java development on android is nicer then ndk. I'm just glad ndk is an option
[22:37:36] <psch> i remember having the same problem with not being able to read the config file
[22:37:50] <psch> but i think in my case the problem was path related, i.e. my files were not in the right spot
[22:37:50] <thomcom> javadocs for 99% of android api functions are like this "public void <functionName> : does the <functionName> to the data when you call it"
[22:38:02] <psch> unfortunately i didnt document any of that
[22:39:15] <brada> here is an idea
[22:39:40] <brada> have gemrb create a file at the path you are trying to read gemrb.cfg from
[22:40:02] <brada> then read that file back
[22:40:22] <psch> well the subject is off to the pool
[23:17:33] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[23:21:09] --> rocket_hamster has joined #gemrb
[23:25:31] <-- Maighstir___ has left IRC (Quit: .)
[23:48:53] <-- rocket_hamster has left IRC (Remote host closed the connection)