#gemrb@irc.freenode.net logs for 10 Jun 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:00:29] <Empiricist> Good. I ran into an issue earlier where I attempted to add a print statement in one of the scripts and the application would run afterwords. Then again, that was probably just a complication with the setup I was using.
[00:04:35] <brada> well you probably do need to relaunch gemrb between edits
[00:04:48] <brada> since python "compiles" the scripts
[00:05:40] <brada> ive never tried so i dont know for sure
[00:06:16] <brada> and you would likely want to use a log statement not print
[00:07:02] <brada> you can have the log in the ingame message window btw
[00:07:37] <Empiricist> Classes=4 must mean Thief.
[00:08:03] <brada> http://www.gemrb.org/wiki/doku.php?id=guiscript:messagewindowdebug
[00:08:04] <Pepelka> guiscript:messagewindowdebug [GemRB wiki]
[00:10:42] <Empiricist> See GUIDefines.py
[00:19:26] <Empiricist> The demo gives me a black screen now. :)
[00:19:57] <Empiricist> *gemrb demo
[00:25:58] <Empiricist> I was wrong.
[00:26:01] <Empiricist> It works.
[00:26:13] <Empiricist> No CD1 path.
[00:26:25] <Empiricist> That's the key.
[00:26:36] <Empiricist> Can I get it to move?
[00:28:07] <Empiricist> Wonderful! Print works.
[00:30:41] <Empiricist> Start.py -> SetupGame.py -> EnterGame() -> ???
[00:31:44] <Empiricist> Start.py -> SetupGame.py -> EnterGame() -> GUILOAD.py -> ???
[00:34:45] <-- brada has left IRC (Quit: brada)
[00:39:08] --> brada has joined #gemrb
[00:39:15] <brada> Empiricist: you need gametype=demo
[00:39:26] <brada> but no our demo doesnt even let you control the avatar
[00:39:32] <brada> its still vry much a WIP
[00:41:49] <Empiricist> I got it working.
[00:42:15] <Empiricist> Strangely, moving between BGII and the Demo causes the scrambling of the text that I was telling you about.
[00:47:57] <Empiricist> Recompiling fixes the issue.
[00:51:24] <-- brada has left IRC (Quit: brada)
[00:59:07] <-- |Cable| has left IRC (Ping timeout: 245 seconds)
[01:12:21] --> |Cable| has joined #gemrb
[02:18:00] <-- Empiricist has left IRC (Quit: Page closed)
[02:46:08] --- ermo is now known as ermo^
[03:06:31] --> brada has joined #gemrb
[04:38:09] <-- brada has left IRC (Quit: brada)
[04:49:08] --> brada has joined #gemrb
[05:28:26] <-- brada has left IRC (Quit: brada)
[08:15:30] --> edheldil has joined #gemrb
[08:15:30] --- ChanServ gives channel operator status to edheldil
[08:38:17] --> lynxlynxlynx has joined #gemrb
[08:38:17] <-- lynxlynxlynx has left IRC (Changing host)
[08:38:17] --> lynxlynxlynx has joined #gemrb
[08:38:17] --- ChanServ gives channel operator status to lynxlynxlynx
[08:51:09] --> WingedHussar has joined #gemrb
[15:18:51] <-- WingedHussar has left IRC (Quit: WingedHussar)
[15:41:10] --> brada has joined #gemrb
[15:49:57] --- ermo^ is now known as ermo
[15:53:14] --> Coriander has joined #gemrb
[17:26:56] <-- nutron has left IRC (Quit: I must go eat my cheese!)
[17:31:06] <brada> finally apple gets opengl 4
[17:36:37] --> psch has joined #gemrb
[17:36:47] --> duckpunc1 has joined #gemrb
[17:42:24] <-- Coriander has left IRC (*.net *.split)
[17:42:25] <-- psch_ has left IRC (*.net *.split)
[17:42:25] <-- duckpunch has left IRC (*.net *.split)
[17:49:21] --> nutron has joined #gemrb
[17:57:56] --> Occulus has joined #gemrb
[18:03:31] <Occulus> In python scripts: import GemRB, where is this module defined?
[18:04:13] <fuzzie> in the C++ plugin GUIScript
[18:05:47] <Occulus> Thank you.
[18:08:26] <Occulus> Is the source code for the GUIScript plugin defined in gemrb/gemrb/core/GUI, or gemrb/gemrb/core/GameScript, or elsewhere?
[18:08:47] <fuzzie> in gemrb/gemrb/plugins/GUIScript :)
[18:09:18] <Occulus> Very nice. Thanks. :)
[18:14:39] <Occulus> Are these plugins used for the linux and windows binaries in addition to the macosx binary?
[18:15:03] <fuzzie> yes
[18:16:18] <fuzzie> you can link them all into a single binary, but of course the plugins are still all used
[18:16:35] <Occulus> That's good to know. I've never seen this done before. Python calling functions that were defined in c++... this is really cool.
[18:16:52] <fuzzie> we do it at a very low level
[18:17:15] <fuzzie> it's more common to use a higher-level API. or if you're not embedding, something like Cython.
[18:20:27] <Occulus> Is Cython a better way of doing it? Cython came out in 2007, so GemRB is a lot older.
[18:23:51] <fuzzie> cython
[18:23:54] <fuzzie> gr
[18:24:02] <fuzzie> cython's only been usable for this kind of thing since 2011 or so anyway.
[18:24:43] <fuzzie> not sure if it would be better for us or not.
[18:25:14] <brada> guiscripts arent gemrb's biggest problem anyway
[18:25:24] <Occulus> "GemRB.SetVar("Gender",0) #gender".... must correspond with: "static PyObject* GemRB_SetVar(PyObject * /*self*/, PyObject* args)". Right?
[18:25:29] <fuzzie> yep
[18:25:39] <fuzzie> brada: what is gemrb's biggest problem? :)
[18:25:52] <brada> lousy performance on mobile?
[18:26:14] <fuzzie> is it that bad?
[18:26:17] <brada> its subjective :p
[18:26:30] <brada> unplayable on most android devices from what i hear
[18:26:36] <fuzzie> I mean 32bpp is kind of shooting yourself in the foot deliberately.
[18:26:45] <fuzzie> But I thought it was playable on iOS despite that.
[18:26:45] <brada> sure
[18:26:48] <brada> yes
[18:26:49] <brada> on ios
[18:26:53] <brada> even on ipad 1
[18:26:57] <brada> tho not at 30 fps
[18:27:08] <brada> need an ipad 2 or better
[18:27:41] <fuzzie> opengl backend is tempting, just .. time-consuming
[18:28:15] <Occulus> A review from my roommate who tried to play BGII on Ubuntu... "It just seems really unstable." The context: It was crashing from picking up items sometimes...
[18:28:38] <fuzzie> well, that is not supposed to happen :-)
[18:29:24] <Occulus> I should've been watching him while he was playing it. I could've pinpointed exactly what was causing his issues.
[18:29:31] <brada> probably something pretty basic or already fixxed
[18:29:53] <Occulus> I read earlier that there were some issues with gemrb on ubuntu.
[18:30:32] <Occulus> Some to do with OpenAL. But his problems weren't sound related. Well, not all of them, anyways.
[18:33:33] <brada> it would help if we knew what version of gemrb. we have fixed a bunch of sound and other buggs since 0.7.x
[18:33:54] <Occulus> It was version 0.8.0.
[18:34:13] <Occulus> Self compiled on his platform.
[18:34:22] <fuzzie> hm, the fonts are still wonky
[18:34:34] <fuzzie> in bg2's graphics options, the 'software standard blt' is cut off
[18:35:01] <Occulus> What do the fonts do that make them wonky?
[18:35:15] <fuzzie> the 'character's target destroyed' in autopause options is wrapped weirdly too
[18:35:22] <fuzzie> Occulus: if I knew that I'd specify more exactly.. :-)
[18:36:29] <fuzzie> git seems pretty stable for me, anyway, having tried a bunch of tricks just now
[18:36:41] <brada> well im sick to death of fonts right now
[18:36:53] <fuzzie> so reproduction recipes would be welcome
[18:36:58] <brada> working on the sprite class abstraction stuff
[18:37:06] <fuzzie> brada: that sounds not fun :p
[18:37:10] <Occulus> I find it interesting that you mention the fonts because the fonts do strange things if I just run GemRB from the application rather than running it from the executable inside the application.
[18:37:17] <brada> its not but its better than fonts :p
[18:37:21] <Occulus> This is on MacOSX
[18:37:22] <fuzzie> yes, ok, that's true
[18:39:28] <brada> hard to imagine any font problem being specific to mac
[18:39:37] <brada> especially since i have never seen them
[18:39:55] <brada> of course i dont know what "strange things" means
[18:40:59] <brada> i dont know how you got your build either
[18:41:26] <Occulus> For instance: When you open up the character menu, you look at the character statistics/proficiencies/ what-have-you, and they look scrambled, it makes it unreadable.
[18:41:30] <brada> empirical was reporting "odd" font behavior too but he said after i fixed the mac cmake builld and he recompiled the vanished so...
[18:41:48] <brada> Occulus: how to reproduce?
[18:44:08] <Occulus> Run the application: /gemrb.app/. The issue appears and doesn't go away unless you recompile. Run the application from the command line with: /gemrb.app/Contents/MacOS/GemRB and the issue never appears.
[18:44:33] <Lightkey> it's Icculus's evil twin!
[18:45:29] <Occulus> Run the application from /gemrb.app/Contents/MacOS/GemRB and try and run the demo, and it font appears again and doesn't go away unless you recompile.
[18:46:38] <Occulus> Compilation was done using cmake on snow leopard.
[18:47:06] --> Yoshimo has joined #gemrb
[18:47:14] <brada> occulus: you are running an out of date build
[18:47:35] <brada> new build is GemRB.app
[18:47:51] <brada> can you reproduce with a new build?
[18:48:05] <Lightkey> wait-a-mo, he is in SoCal, that *is* near Raleigh, where Icculus is!
[18:48:22] <Occulus> Let's see... sure.
[18:48:43] <brada> be sure to completely clean the build
[18:49:00] --> Coriander has joined #gemrb
[18:49:10] <brada> im also not likely to try and fix bugs that manifest only when you run the binary from CLI, sorry
[18:50:41] <brada> the only repots ive seen for this are from cmake build on 10.6
[18:50:48] <brada> so maybe update your compiler?
[18:51:42] <brada> if you can reproduce it with the sourceforge binary ill try to take a look later
[18:52:28] <brada> gcc 4.3 is known to miscompile gemrb btw… dont know what version you have
[18:53:12] <Occulus> gcc 4.2
[18:53:19] <Occulus> I guess I need to update that.
[18:58:32] <Occulus> Bus error for the binary... caused by clicking on the character stat icon.
[18:58:40] <Lightkey> fuzzie: that's strange to hear, GemRB runs capped at 30 fps ±0.3 fps on my Pandora (with Ångström Linux) ;-)
[18:59:38] <fuzzie> in response to what..? :p
[19:00:34] <Lightkey> being slow on mobile devices
[19:01:05] <brada> its slow on android
[19:01:45] <Lightkey> you said mobile :-(
[19:03:41] <fuzzie> well, it's probably slow on the Pandora, really
[19:04:25] <fuzzie> but without Android being in the way, and with only a 800x480 screen, I can believe you can hit 30fps anyway
[19:04:30] <fuzzie> just .. not good for your battery life
[19:05:15] <Occulus> http://pastebin.com/gKfiBEtz
[19:05:17] <Pepelka> gdb output - Pastebin.com
[19:05:54] <Occulus> This is from starting the program.
[19:05:55] <Lightkey> I will classify it as slow, when I see the first one-fps drop
[19:06:18] <fuzzie> and decent battery life is one reason why reimplementation projects are so great
[19:06:38] <fuzzie> e.g. if you compare dosbox and scummvm, often they're both fine, just scummvm gives you 10 hours of play and dosbox .. doesn't :-)
[19:07:39] <Lightkey> going to to use that quote elsewhere in the future, I'm sure :-)
[19:08:34] <lynxlynxlynx> fuzzie: do you remember any other way to make an actor be completely frozen in the map besides disabling IF_ACTIVE and IF_VISIBLE?
[19:08:47] <Occulus> http://pastebin.com/ZJHnNMTR
[19:08:48] <Pepelka> gdb: causing the bus error - Pastebin.com
[19:08:50] <fuzzie> lynxlynxlynx: um, how do you mean frozen?
[19:08:52] <lynxlynxlynx> with avatarremoval the scripts still run iirc
[19:08:58] <fuzzie> they shouldn't
[19:09:00] <lynxlynxlynx> like it wasn't there
[19:09:58] <brada> occulus: link to python 2.5
[19:10:23] <lynxlynxlynx> hmm, maybe that would work then
[19:11:01] <lynxlynxlynx> the IF_ stuff doesn't work in the importer / gets overriden, that's why i'm asking
[19:11:03] <lynxlynxlynx> http://sprunge.us/SbbI?diff
[19:11:15] <lynxlynxlynx> iwd2 has yet another spawning mechanism
[19:11:42] <fuzzie> hm
[19:11:45] <fuzzie> is avatar removal not used in iwd2?
[19:12:05] <fuzzie> I can't see any *checks* for the avatar removal in the script code.
[19:12:06] <lynxlynxlynx> i think we had MC_HIDDEN at one point too, but now there's no trace
[19:12:33] <lynxlynxlynx> it'd be great if we could resolve this silliness in the importer and not later
[19:12:48] <fuzzie> let me look at this a minute
[19:13:11] <lynxlynxlynx> i haven't tried avatar removal yet btw
[19:13:21] <lynxlynxlynx> just thought it was that way
[19:15:31] <fuzzie> well
[19:15:37] <fuzzie> I don't see a check in GemRB.
[19:16:03] <fuzzie> Inh the original, CGameSprite::ProcessPendingTriggers has 'if (avatarremoval) return;', which should stop all scripts from running.
[19:16:47] <fuzzie> so I think if GemRB is missing a check then that's just a bug, which should make things simpler
[19:19:23] <lynxlynxlynx> i don't see any obvious checks either
[19:20:42] <lynxlynxlynx> and iwd2 has avatarremoval, so that could fix both
[19:39:52] <lynxlynxlynx> yeah, just setting the stat is not enough, they still trigger a dialog
[19:40:36] <-- brada has left IRC (Quit: brada)
[19:48:33] --> fizzle has joined #gemrb
[19:53:25] <fizzle> lynxlynxlynx: I've got some more unscheduled actor fixes in the pipe...
[19:54:15] <lynxlynxlynx> cool, but that's irrelevant for this iwd2 stuff, they're fully scheduled
[19:54:19] <fizzle> although, if it's the removed actor that triggers the dialog I guess that's a different issue
[19:54:25] <fizzle> yeah
[19:54:52] <fizzle> fuzzie: I'd like to get some comments on two issues
[19:56:03] <fizzle> three, actually
[20:05:03] <-- Yoshimo has left IRC (Quit: Yoshimo)
[20:06:52] <Occulus> I think I can start adding my own commands to the console...
[20:08:50] <lynxlynxlynx> ok, vithal still works :)
[20:10:45] <lynxlynxlynx> and yep, fixes the orcs too
[20:21:29] <fuzzie> fizzle: hi
[20:21:35] <fizzle> hey
[20:23:39] <fizzle> got a few minutes
[20:23:43] <fizzle> ?
[20:24:00] <fizzle> been wrestling with a few scripting issues
[20:24:09] <fuzzie> hopefully
[20:24:33] <fizzle> well, the first one's already committed
[20:24:48] <fizzle> but I'm wondering if it's the right thing to do
[20:24:53] <fizzle> 7007465932b77
[20:25:08] <fuzzie> oh. no.
[20:25:17] <fuzzie> that will break other stuff
[20:25:24] <fizzle> :P
[20:25:27] <fuzzie> (I've removed that in the past)
[20:26:00] <fuzzie> in .. 38d2126b1848f86a48cf54607e7528fea5cbf647 I guess
[20:26:28] <fuzzie> what's the problem you were trying to fix? I don't have the source files here
[20:27:11] <fizzle> the script triggered a BeginDialog
[20:27:37] <fizzle> but when the dialog actually started it had altered some variables so the starting state was no longer found
[20:27:39] <fuzzie> but if you do 'BeginDialog, SetGlobal' for example then the SetGlobal will be true when the script starts
[20:27:54] <fizzle> yep
[20:28:00] <fuzzie> i mean, in original
[20:28:04] <fuzzie> the starting state might well be calculated before that though
[20:28:21] <fizzle> that might explain it, too, yes
[20:28:41] <fizzle> I'll investigate along those lines
[20:29:06] <fizzle> I guess that's also exactly what this change breaks otherwise?
[20:29:23] <fuzzie> yes, you break scripts which depend on *later* states having the correct variables
[20:29:57] <fizzle> okay, onto number 2
[20:30:07] <fuzzie> (booting machine with the bg2 install now..)
[20:30:45] <fizzle> in DialogChoose there's a block with ClearAction()
[20:31:33] <fizzle> that breaks hellself.dlg, though
[20:31:53] <fizzle> the demon abducts a party member and casts hold
[20:31:57] <fuzzie> well, someone seems to have nicely hacked that
[20:32:25] <fizzle> in some state it's supposed to dispel that again
[20:32:47] <fizzle> but the spell never finishes because that action's cleared away
[20:32:57] <fuzzie> right
[20:32:59] <fuzzie> that's correct
[20:33:04] <fuzzie> spell action is presumably broken
[20:33:06] <fuzzie> which action is it using?
[20:33:24] <fizzle> let me check
[20:34:02] <fizzle> ForceSpell
[20:35:21] <fuzzie> hmph.
[20:36:46] <fuzzie> ok
[20:37:05] <fuzzie> this is the selfless act one?
[20:37:13] <fizzle> yes
[20:39:00] <fizzle> removing the ClearActions block (or moving it to the (choose==-1) branch fixes this instance
[20:39:16] <fuzzie> removing the ClearActions is really bad
[20:39:28] <fizzle> I noticed :P
[20:39:54] <fuzzie> the queue has to be clear before you do the AddAction calls..
[20:39:59] <fuzzie> um
[20:40:31] <fuzzie> moving it to the choose==-1 branch clearly not correct.. :)
[20:42:20] <fizzle> don't leave me hanging here...
[20:42:28] <fuzzie> is this spin768?
[20:43:14] <fizzle> yes
[20:43:23] <fuzzie> so it has a casting time of 1
[20:44:18] <fuzzie> so it's not instant-cast, either
[20:46:55] <fuzzie> I have no clue. Hm.
[20:48:12] <fizzle> why does the queue have to be empty?
[20:48:24] <fizzle> and why's the -1 branch clearly wrong?
[20:49:55] <fuzzie> the -1 branch is the one that doesn't clear actions
[20:50:08] <fuzzie> so you'd be doing exactly the opposite of what's correct, right?
[20:50:16] <fuzzie> when you move between dialog entries, the queue is cleared
[20:50:32] <fuzzie> otherwise blocking actions from the previous entry will block new actions
[20:50:39] <lynxlynxlynx> The player could avoid the Selfish test immobilization of their party member due to a brief delay between the end of the dialogue and the hold spell cast on the party member.
[20:51:02] <fuzzie> yes, the hold spell works (the dialog exits after casting it)
[20:51:50] <lynxlynxlynx> no other notes in the fixpack
[20:52:15] <fizzle> that means all non-instant actions won't work in dialogs, right?
[20:52:31] <fizzle> ie unless they're run in the final state
[20:53:33] <fuzzie> looking into this
[20:53:48] <fuzzie> think I'mj wrong here
[20:53:52] <fuzzie> which is to say, past`fuzzie says I'm wrong
[20:54:01] <fuzzie> and past`fuzzie usually knows what she's talking about more than I do
[20:54:35] <fuzzie> unfortunately it totally doesn't help because under past`fuzzie's rules, ForceSpell still gets wiped
[20:55:24] <fuzzie> fizzle: so, now I get to look like an idiot, though
[20:56:20] * fizzle ponders whether to cheer...
[20:56:21] <fuzzie> fizzle: the ClearActions should go in the choose==-1 and underneath the 'target should be recalculated' comment
[20:56:31] <fizzle> heh
[20:57:09] <fuzzie> and the existing ClearActions line should be replaced with ReleaseCurrentAction
[20:58:03] <fuzzie> unfortunately that still kills your ForceSpell, I assume..?
[20:58:13] --> brada has joined #gemrb
[20:58:21] <fuzzie> but you should try replacing it with ReleaseCurrentAction first
[20:58:26] <fizzle> I'd guess so
[20:58:36] <-- fireglow has left IRC (*.net *.split)
[20:58:37] <fizzle> what about the ClearPath line?
[20:59:11] --> fireglow has joined #gemrb
[20:59:37] <fuzzie> it shouldn't matter
[20:59:52] <fuzzie> presumably it needs to be in the same place as the ClearActions calls
[21:00:00] <fuzzie> it's kind of complicated, the path should be killed when the movement action is
[21:00:36] <fuzzie> but we don't do that yet :)
[21:02:02] <fuzzie> http://forums.gibberlings3.net/index.php?showtopic=20801 is my notes, if they help
[21:02:03] <Pepelka> dialog action queueing - The Gibberlings Three Forums
[21:02:04] <Pepelka> »These are my current notes on how dialog actions are run in bg2. I would appreciate any comments/clarifications/etc; this is the result of several ho...«
[21:04:41] <-- GoGi has left IRC (Ping timeout: 240 seconds)
[21:04:43] <fizzle> okay, I'll run a test now
[21:04:47] <fuzzie> oh drat, that also means it's actually more complicated, it needs to only go in 'target should be recalculated' if tgt is non-NULL before the "try searching for banter dialogue" bit.
[21:08:27] <fizzle> yes, the spell is stilled killed
[21:08:31] <fizzle> -ed
[21:08:45] <fuzzie> so I don't have any idea what's going on there I'm afraid
[21:09:16] <fuzzie> also not sure how to work out what to do..
[21:10:26] <fuzzie> I think the answer is most likely that the next state is calculated early though.
[21:10:26] --> GoGi has joined #gemrb
[21:11:19] <fizzle> before the actions are run?
[21:11:26] <fuzzie> oh
[21:11:28] <fuzzie> sorry
[21:11:37] <fuzzie> I'm back to the Jaheira one for a moment.
[21:11:49] <fizzle> ah
[21:13:22] <fuzzie> mmh
[21:13:35] <fizzle> what about your comment regarding SetInterrupt(false)?
[21:15:26] <fuzzie> complicated, not relevant here
[21:16:03] <fuzzie> I think..
[21:16:08] <fuzzie> let me check some things
[21:17:57] <fuzzie> yes
[21:18:03] <fuzzie> initial conditions (and the clearactions) are done in the action
[21:18:16] <fuzzie> so that solves jaheira one
[21:26:02] <fuzzie> fizzle: which one is this test from the main bit of hell?
[21:26:25] <fizzle> what do you mean? the dlg file?
[21:26:32] <fuzzie> no, physically
[21:26:33] <fuzzie> down, I think
[21:26:39] <fizzle> yeah middle down
[21:28:02] <fuzzie> was wondering if there was an instant-cast effect
[21:28:04] <fuzzie> but, nope
[21:28:40] <fizzle> does the ReleaseCurrentAction have to happen for each transition?
[21:29:27] <fizzle> or do actions just queue up during the dialog?
[21:30:04] <fuzzie> and it happens for each transition
[21:30:18] <fuzzie> so blocking actions die as you move through the dialog
[21:30:23] <fuzzie> and they don't get executed due to dialog pause
[21:30:39] <fuzzie> i think ForceSpell in a dialog might always be insta-cast
[21:31:37] <fuzzie> oh
[21:32:33] <fuzzie> it would help if I knew more about this code
[21:39:44] <-- brada has left IRC (Quit: brada)
[21:40:29] <fuzzie> ForceSpell definitely obeys the speed; only ReallyForceSpell/ReallyForceSpellDead ignore it.
[21:41:18] <fuzzie> fizzle: can you ask me about this tomorrow?
[21:41:27] <fizzle> nope
[21:41:42] <fizzle> weekend at the earliest
[21:41:43] <fuzzie> drat :)
[21:42:36] --> brada has joined #gemrb
[21:42:54] <fizzle> I'll gladly do it then, though
[21:44:51] <lynxlynxlynx> so what's the third one? :)
[21:45:05] <fizzle> ah, someone's keeping count :)
[21:45:18] <fuzzie> the dialog queueing code (InsertResponse) definitely sets breakaction
[21:46:35] <fizzle> the third's setting view ports in cutscenes after changing areas
[21:46:54] <fizzle> I've fixed it locally by implementing MultiPlayerSync() :D
[21:47:38] <fizzle> but let's do them one at a time
[21:50:20] <fuzzie> so
[21:50:30] <fuzzie> ForceSpell depends on the actiontime being updated
[21:50:38] <fuzzie> that won't happen ever after new dialog stuff is queued
[21:51:53] <fizzle> that sounds like it shouldn't work...
[21:52:25] <-- brada has left IRC (Quit: brada)
[21:52:36] <lynxlynxlynx> heh, nice hack
[21:55:53] <fuzzie> yes, so I don't see why it works in original
[21:57:48] <fuzzie> but I have to sleeep
[21:58:38] <fizzle> thanks so far
[21:58:49] <fizzle> let's continue this later then
[21:59:14] <fizzle> in fact, I think I still have questions regarding the Jaheira issue as well
[22:02:18] <lynxlynxlynx> hey, it's tommorow, ask her about it :)
[22:02:43] <fizzle> :)
[22:03:19] <fizzle> that reminds me, I should head to bed, too
[22:04:11] <fizzle> gn
[22:04:56] <-- fizzle has left #gemrb
[22:06:29] <lynxlynxlynx> i still haven't adapted from the viking timezone (-2 effectively)
[22:06:58] <lynxlynxlynx> not having a fixed schedule job doesn't help
[22:14:00] --> Coriander2 has joined #gemrb
[22:14:40] <-- Coriander has left IRC (Ping timeout: 276 seconds)
[22:31:04] <-- Coriander2 has left IRC (Read error: Connection reset by peer)
[22:32:44] --> Coriander has joined #gemrb
[22:47:00] --- ermo is now known as ermo^
[22:51:20] <Occulus> How does gcc4.8 work with gemrb?
[23:01:49] <lynxlynxlynx> fine
[23:14:18] <-- lynxlynxlynx has left IRC (Remote host closed the connection)