#gemrb@irc.freenode.net logs for 29 Jun 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:10:23] <-- Maighstir has left #gemrb
[00:21:43] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[00:43:12] --> edheldil_ has joined #gemrb
[00:55:00] --> raevol has joined #gemrb
[01:10:15] <-- edheldil_ has left IRC (Ping timeout: 255 seconds)
[03:02:01] <-- barra_away has left IRC (Quit: Verlassend)
[04:26:29] <-- Cable_ has left IRC (Read error: Operation timed out)
[04:32:50] --> Cable_ has joined #gemrb
[06:27:25] --> edheldil_ has joined #gemrb
[06:54:43] <-- edheldil_ has left IRC (Ping timeout: 244 seconds)
[07:03:20] --> lubos has joined #gemrb
[07:58:57] --> adominguez has joined #gemrb
[08:04:38] <-- adominguez has left IRC (Remote host closed the connection)
[08:06:14] --> adominguez has joined #gemrb
[08:12:57] <fuzzie> also Avenger is quite right about msvc6, vc2010's debugger still sucks
[08:13:06] <fuzzie> gah, i say.
[08:16:12] <fuzzie> "how to get the missing frames to appear in the call stack window" appears to boil down to "set a breakpoint in one of the missing frames and continue execution to that point"
[08:16:14] <fuzzie> i have no words
[08:19:17] <edheldil> what are missing frames?
[08:19:43] <fuzzie> missing entries in the call stack
[08:22:06] <edheldil> do you mean parent/grandparent etc frames?
[08:22:34] <edheldil> r.e. what you get to in gdb with "frame 3" etc?
[08:22:44] <fuzzie> yes
[08:23:32] <edheldil> eh, that sounds funny
[08:23:51] <fuzzie> apparently it's because the debugger tries to be 'smart' when there's managed (.NET) code running in any thread
[08:24:11] <fuzzie> and promptly forgets that half the native frames exist
[08:24:34] <edheldil> how are you fuzzie? Still not feeling like hacking on GemRB?
[08:25:19] <fuzzie> i should have time for it again now
[08:25:54] <edheldil> good
[08:26:19] <edheldil> I feared you had burnt out :)
[08:42:27] <fuzzie> i am just fighting with vs right now, as you can no doubt tell
[08:42:33] <fuzzie> i am *also* helping someone else remotely fight with vs
[08:43:14] <edheldil> vs==visual studio?
[08:43:39] <fuzzie> yes
[08:44:08] --> edheldil_ has joined #gemrb
[09:08:23] <-- raevol has left IRC (Ping timeout: 250 seconds)
[09:08:37] <-- Cable_ has left IRC (Remote host closed the connection)
[09:19:19] --> raevol has joined #gemrb
[09:32:21] <-- raevol has left IRC (Quit: Leaving.)
[10:45:33] --> PixelScum has joined #gemrb
[10:48:53] <-- BaldimerBrandybo has left IRC (Ping timeout: 252 seconds)
[10:55:34] --> SiENcE has joined #gemrb
[12:15:12] <-- wjp has left IRC (Ping timeout: 240 seconds)
[12:15:31] --> wjp has joined #gemrb
[12:15:53] --- ChanServ gives channel operator status to wjp
[13:52:19] --> lynxlynxlynx has joined #gemrb
[13:52:19] --- ChanServ gives channel operator status to lynxlynxlynx
[14:54:36] --> brad_a has joined #gemrb
[15:01:15] <brad_a> i get an Unhandled Music state error when trying to pause/play the openal audio driver. I probably dont care enough to do more than mention it here ;)
[15:02:47] <fuzzie> there was a bug in there, deactivate() got called on the AmbientManagerAL way too early (should be first thing)
[15:02:53] <fuzzie> erm, way too late
[15:04:38] <brad_a> ah
[15:04:43] <brad_a> is that fixed in git?
[15:06:59] <fuzzie> i dooon't know
[15:07:08] <brad_a> it doesnt appear to be
[15:07:42] <brad_a> bah. that dint fix it anyway. oh well
[15:07:57] <brad_a> ill just live with the music playing while gemrb is in the background
[15:09:25] <fuzzie> that's odd
[15:10:05] <brad_a> yeah well ive been told apples openal implementation is just taht ;-)
[15:10:25] <fuzzie> ah right, we don't handle AL_PAUSED or something in MusicManager
[15:10:42] <fuzzie> and you're not pausing the app, so the music gets force-restarted by the game code
[15:11:27] <brad_a> are you saying this would work if i paused gameplay?
[15:11:36] <brad_a> cuz i do want to pause gameplay as well
[15:13:48] <fuzzie> it doesn't really look like it should ever get there
[15:14:53] <brad_a> like i said its not a big deal
[15:15:16] <edheldil> write some pauseApp() method probably in interface, so it can be reused
[15:15:56] <brad_a> oh i will if i do it
[15:16:16] <fuzzie> ah, yes, the game loop does indeed restart music
[15:16:36] <edheldil> or suspendApp(), whatever. And document it :-B
[15:16:40] <brad_a> not my priority ATM but it probably needs to be done for androidso you can take calls and such while playing
[15:16:44] <fuzzie> it only does it when the game is *running* though
[15:17:01] <fuzzie> so only if you didn't even do DF_FREEZE_SCRIPTS
[15:17:45] <fuzzie> so i hope that it would get fixed by you pausing gameplay
[15:18:32] <edheldil> btw, is it a proper iPhone/iPad suspend? I have heard iOS suspend is basically save screenshot & die
[15:19:02] <fuzzie> this is a jailbroken app, so it doesn't have to obey the App Store restrictions
[15:19:05] <brad_a> yes iOS suspends just fine automatically
[15:19:23] <fuzzie> i'm not sure why the process can't just get frozen :)
[15:19:30] <brad_a> it doesnt have to but it does suspend. to not suspend you have to do soe kluging
[15:19:48] <fuzzie> i mean, if it got suspended then you'd get no music, right?
[15:19:52] <edheldil> fuzzie: to free memory
[15:19:52] <brad_a> it can i just dont know how to do that programatically
[15:20:01] <brad_a> right
[15:20:10] <fuzzie> edheldil: i mean, for gemrb in particular here
[15:20:49] <edheldil> fuzzie: because you would have to wake it up externally :)
[15:20:55] <fuzzie> i know from android that suspending seems a terrible idea, because it means app authors don't bother saving state and you get horrible unpredictable behaviour
[15:21:45] <brad_a> i did have a problem where video wouldnt update after returning to gemrb because the window surface was getting invalidated and the prescribed method for getting a new one wasnt working well so i just exposed a private member of SDLs window struct and set it back to valid and it works fine now
[15:22:25] <edheldil> can't you force redraw by normal means?
[15:23:50] <brad_a> explain. im new to SDL and everything else :-)
[15:24:12] <brad_a> the documentation told me to call SDL_GetWindowSurface
[15:24:39] <brad_a> but doing that resulted in a black screen on return then leaving and coming back it would be fine and it would keep alternating in that manner
[15:25:09] <brad_a> it was really bizarre
[15:28:16] <brad_a> i do know that it was getting invalidated because of a resize event, but it wasnt even created with the resizable flag in the first place. i think its a bug in sdl but i dont know for sure
[15:30:27] <-- lubos has left IRC (Quit: Leaving.)
[15:36:37] <edheldil> Could be due to double-buffering?
[15:37:35] <brad_a> i tried calling swap buffers
[15:37:59] <brad_a> im ignorant of such things tho
[15:47:02] --> Maighstir has joined #gemrb
[16:27:43] <-- SiENcE has left IRC (Quit: @all: cya)
[16:42:06] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[16:45:59] --> Maighstir has joined #gemrb
[17:07:09] <-- adominguez has left IRC (Quit: Saliendo)
[17:11:36] <-- edheldil_ has left IRC (Ping timeout: 260 seconds)
[17:33:16] --> |Cable| has joined #gemrb
[17:33:25] <lynxlynxlynx> hmpf, another reproducable segfault
[17:34:17] <lynxlynxlynx> in a cutscene area move no less
[17:34:32] <lynxlynxlynx> Projectile::SetTarget crashes since area is nulled
[17:56:13] <lynxlynxlynx> ActionOverride("Yoshimo",ReallyForceSpell("Yoshimo",NOHOLD_PARTY)) from cut41g starts it
[17:56:29] <lynxlynxlynx> but there doesn't appear to be any yoshimo present in the current area
[18:00:02] <lynxlynxlynx> there is one if i just check by global id, but that's in another area
[18:07:17] <fuzzie> yes
[18:07:36] <fuzzie> i think that is correct
[18:14:54] <lynxlynxlynx> http://pastebin.com/9cubm7EP <-- this is the full trace
[18:16:29] <lynxlynxlynx> core is already in the target area
[18:17:31] <lynxlynxlynx> switching to frame 4, area is already null :s
[18:19:10] <lynxlynxlynx> means something after it changed the area or why didn't it crash right there?
[19:03:29] <fuzzie> it doesn't crash there because it didn't try using this yet
[19:03:45] <fuzzie> i don't really understand what it's up to
[19:05:04] <fuzzie> i mean, the code is just randomly making a projectile without checking if it can
[19:06:56] <fuzzie> oh i do know what's going on, scripting issues :-/
[19:18:59] <lynxlynxlynx> how is it not used there, the line is area->AddProjectile(pro, origin, tgt, fake);
[19:21:25] <lynxlynxlynx> hmm, what if the two-step casting is in the way
[19:21:49] <lynxlynxlynx> preparatory step in the first area, while second being tried already in the new one
[19:36:12] <lynxlynxlynx> not in this action
[19:55:59] --> barra_home has joined #gemrb
[20:07:16] --> Beh0lder has joined #gemrb
[20:07:30] <Beh0lder> hi all
[20:09:59] <brad_a> hey
[20:10:11] <-- Beh0lder has left #gemrb
[20:10:34] --> Beh0lder has joined #gemrb
[20:11:40] <lynxlynxlynx> oj
[20:11:49] <Beh0lder> please apply my Android diffs (touch areas and volume control changes)
[20:12:04] <lynxlynxlynx> where are they?
[20:12:17] <lynxlynxlynx> last time you showed them they needed some minor rework
[20:14:31] <Beh0lder> I posted they in pastebin two weeks ago and post link here...
[20:14:40] <Beh0lder> what rework?
[20:15:48] <Beh0lder> http://pastebin.com/HBNVWYfx
[20:18:38] <lynxlynxlynx> i don't remember, but to make me happy you should at minimum also include that option in the example configs
[20:19:16] <brad_a> i posted one of those config changes but apparently there was another config file that needed the patch
[20:19:47] <brad_a> http://dl.dropbox.com/u/13866402/touchscreenconfigpatch.txt
[20:20:24] <lynxlynxlynx> there are two in the same dir
[20:20:36] <lynxlynxlynx> that patch also adds a nonexisting option anyway
[20:21:02] <brad_a> yeah that non existing option is something that i still need to submit
[20:21:39] <brad_a> this weekend i will have time to patch out all my diffs
[20:21:55] <lynxlynxlynx> and it should be below video settings, which are changed much more frequently
[20:22:29] <lynxlynxlynx> all options should also be in the man page, but i can take care of that, the syntax is yucky
[20:22:34] <Beh0lder> TouchScrollAreas now implemented in my patch
[20:23:01] <Beh0lder> and successfully used in latest android version
[20:24:53] <brad_a> video settings because they are implemented in sdlvideo? even though they are both input settings?
[20:25:10] <lynxlynxlynx> below as in further in the file
[20:26:03] <lynxlynxlynx> people change the paths most often (sadly), then resolution, while all the rest are rarely touched
[20:26:33] <brad_a> ah gottcha
[20:33:19] <Beh0lder> People asked what part of the PST is complete? 50%, 80% or more? What features are not implemented in this time?
[20:35:09] --> edheldil_ has joined #gemrb
[20:44:23] <-- Beh0lder has left #gemrb
[20:44:48] --> Beh0lder has joined #gemrb
[20:53:23] <lynxlynxlynx> i can't estimate the percentage, but
[20:53:42] <lynxlynxlynx> - tno is a broken multiclass character
[20:53:54] <lynxlynxlynx> - i think we're missing something about the animation format
[20:54:17] <lynxlynxlynx> - some spells and effects are surely broken
[20:54:35] <lynxlynxlynx> - no overhead text means no combat feedback
[20:55:09] <lynxlynxlynx> - i'm sure there are plenty of other surprises left due to the engine difference
[20:55:20] <fuzzie> and we don't support a whole bunch of obscure-but-important stuff
[20:55:38] <fuzzie> the game breaks somewhere because we don't handle some kind of flag which sets everyone hostile, for example
[20:57:09] <Beh0lder> (
[20:57:24] <Beh0lder> not playable
[20:59:55] <lynxlynxlynx> yep
[21:00:21] <lynxlynxlynx> the gui part is also not so clean due to all the changes that prevent efficient code share
[21:07:17] <Beh0lder> any plans to improve PST support in near future?
[21:08:57] <fuzzie> well it's often being improved..
[21:25:34] <lynxlynxlynx> and most of the engine fixes benefit it aswell
[21:26:41] <lynxlynxlynx> fuzzie: so what's that crashing scripting issue about? severity?
[21:26:56] <fuzzie> i think the action should never run
[21:27:09] <fuzzie> that's a long-standing instants issue which i keep meaning to fix
[21:27:13] <fuzzie> i'm not sure i'm right though
[21:29:16] <-- Beh0lder has left #gemrb
[21:32:59] <lynxlynxlynx> something for the release then :)
[21:33:33] <fuzzie> are you planning one?
[21:33:45] <lynxlynxlynx> not before more bugs are gone
[21:33:53] <lynxlynxlynx> maybe in two weeks
[21:41:12] <lynxlynxlynx> not that much left to do
[21:42:00] <lynxlynxlynx> some patches left to resolve and apply, adding feedback for why saving fails, misc fixes (like traps)
[21:58:31] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[22:09:22] <lynxlynxlynx> bah, why are always the longest cutscenes problematic
[22:12:48] <lynxlynxlynx> this one could be due to the mods though
[22:13:20] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:21:09] <-- barra_home has left IRC (Quit: Verlassend)
[22:33:15] <-- edheldil_ has left IRC (Ping timeout: 252 seconds)
[22:46:10] --> BaldimerBrandybo has joined #gemrb
[22:49:19] <-- PixelScum has left IRC (Ping timeout: 258 seconds)
[23:58:42] <-- brad_a has left IRC (Ping timeout: 240 seconds)