#gemrb@irc.freenode.net logs for 3 Jun 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[02:26:54] <-- |Cable| has left IRC (*.net *.split)
[02:26:54] <-- Maighstir|work has left IRC (*.net *.split)
[02:26:54] <-- puphome has left IRC (*.net *.split)
[02:26:55] <-- wjp has left IRC (*.net *.split)
[02:26:56] <-- edheldil has left IRC (*.net *.split)
[02:26:57] <-- anji has left IRC (*.net *.split)
[02:26:58] <-- xrogaan has left IRC (*.net *.split)
[02:26:59] <-- fuzzie has left IRC (*.net *.split)
[02:27:01] <-- Lightkey has left IRC (*.net *.split)
[02:27:02] <-- tomprince has left IRC (*.net *.split)
[02:27:02] <-- cubathy has left IRC (*.net *.split)
[02:28:30] --> tomprince has joined #GemRb
[02:28:30] --> cubathy has joined #GemRb
[02:28:30] --> |Cable| has joined #GemRb
[02:28:30] --> puphome has joined #GemRb
[02:28:30] --> Maighstir|work has joined #GemRb
[02:28:30] --> fuzzie has joined #GemRb
[02:28:30] --> Lightkey has joined #GemRb
[02:28:30] --> wjp has joined #GemRb
[02:28:30] --> anji has joined #GemRb
[02:28:30] --> edheldil has joined #GemRb
[02:28:30] --> xrogaan has joined #GemRb
[02:37:15] --> budlust has joined #GemRb
[02:55:54] <-- budlust has left IRC (Quit: budlust)
[02:55:58] --> budlust has joined #GemRb
[03:32:36] --> tomprince_loki has joined #GemRb
[03:39:28] --> Gekz has joined #GemRb
[03:55:23] <-- Gekz has left IRC (Ping timeout: 248 seconds)
[04:02:57] --> Gekz has joined #GemRb
[04:43:36] <-- Lightkey has left IRC (Read error: Operation timed out)
[04:51:49] --> Lightkey has joined #GemRb
[04:56:43] <-- cubathy has left IRC (Ping timeout: 260 seconds)
[05:09:34] --> cubathy has joined #GemRb
[05:15:29] --> raevol has joined #GemRb
[06:22:22] --> puphome_ has joined #GemRb
[06:23:21] <-- puphome has left IRC (Read error: Operation timed out)
[06:40:55] --> Gekz_ has joined #GemRb
[06:42:58] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[06:55:15] <-- raevol has left IRC (Quit: Leaving.)
[06:56:22] --> cubathy has joined #GemRb
[07:11:29] --> lynxlynxlynx has joined #GemRb
[07:11:29] --- ChanServ gives channel operator status to lynxlynxlynx
[07:16:42] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[07:22:55] --> raevol has joined #GemRb
[07:23:01] <-- raevol has left IRC (Client Quit)
[07:29:23] <-- Gekz has left IRC (Read error: Connection reset by peer)
[07:30:05] --> cubathy has joined #GemRb
[07:30:19] --> Gekz has joined #GemRb
[07:30:21] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[07:31:04] --> Gekz_ has joined #GemRb
[08:43:50] <-- |Cable| has left IRC (Remote host closed the connection)
[09:11:26] <-- Maighstir|work has left IRC (Quit: Page closed)
[10:24:59] --> Maighstir has joined #GemRb
[11:17:10] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[11:17:22] <-- Gekz has left IRC (Read error: Connection reset by peer)
[11:17:46] --> Gekz has joined #GemRb
[11:18:01] --> Gekz_ has joined #GemRb
[12:27:31] <-- budlust has left IRC (Ping timeout: 260 seconds)
[12:30:22] --> budlust has joined #GemRb
[12:36:01] <-- Maighstir has left #GemRb
[12:38:02] <-- tomprince has left IRC (Ping timeout: 245 seconds)
[12:38:45] <-- tomprince_loki has left IRC (Ping timeout: 265 seconds)
[12:38:49] --> tomprince has joined #GemRb
[12:48:48] <-- Gekz has left IRC (Read error: Connection reset by peer)
[12:49:01] --> Gekz has joined #GemRb
[13:14:41] <-- Gekz has left IRC (Read error: Connection reset by peer)
[13:14:49] --> Gekz has joined #GemRb
[13:14:54] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[13:15:50] --> Gekz_ has joined #GemRb
[13:28:01] <-- Gekz has left IRC (Read error: Connection reset by peer)
[13:28:47] --> Gekz has joined #GemRb
[13:43:31] <-- cubathy has left IRC (Ping timeout: 265 seconds)
[13:55:51] --> cubathy has joined #GemRb
[14:14:44] --> kingron has joined #GemRb
[14:17:09] <lynxlynxlynx> https://bugs.launchpad.net/ubuntu/+bug/148427 <-- driver & pulse foo?
[14:19:22] <fuzzie> yes
[14:19:41] <lynxlynxlynx> hehe
[14:20:01] <fuzzie> as far as i could tell it's pulse's fault, but we do *very* broken things in the audio driver atm
[14:20:50] <fuzzie> (e.g. loading music files from the music streaming thread(!) )
[14:24:39] <lynxlynxlynx> btw, i couldn't make the container thing refresh properly
[14:25:08] <lynxlynxlynx> it works correctly when exiting, but the initial draw is all messed up no matter where i put the updates
[14:26:52] <fuzzie> the problem is that the message window should be higher?
[14:26:57] <fuzzie> i don't have a good view of what is breaking
[14:26:58] <Gekz> fuzzie: isn't it proper to simply interrupt the thread, kill it, and start it again with the new stream
[14:27:04] <lynxlynxlynx> http://pastebin.com/gkQ6eDs0 <-- this was it if you're wondering
[14:27:19] <fuzzie> Gekz: the thread is the only thing which notices the music stopped, i think is the problem
[14:27:22] <lynxlynxlynx> the restoration on closing works perfectly
[14:27:40] <Gekz> fuzzie: yeah, meaning you need a 'control' thread, no?
[14:27:44] <Gekz> a thread that interrupts the other thread
[14:28:04] <lynxlynxlynx> when you open the container and the message window is scaled down, the old height is also still displayed in the background and that and the minimised message window obscure the container window
[14:29:14] <fuzzie> and the window is actually there, or you can fix it by interacting with the container window and making it redraw?
[14:32:32] <lynxlynxlynx> the minimised window is there and i can interact with it; i can do the same with the part of the container window that replaced the action bar, but it doesn't change the drawing order or the situation one bit
[14:34:06] <fuzzie> i'm just not sure quite what is going on
[14:34:10] --> tomprince_loki has joined #GemRb
[14:34:46] <lynxlynxlynx> i'll make a screenie
[14:36:26] <lynxlynxlynx> http://lynxlynx.info/bugs/containerVSmsgwindow.jpg
[14:37:14] <lynxlynxlynx> i can temporarily get the whole container window to draw, i was mistaken
[14:38:29] <lynxlynxlynx> interestingly, the upper anomaly is of the same size if i start with the large message window instead of the medium one (it isn't present with the small one)
[14:39:29] <lynxlynxlynx> i see why, it is just replaced with the starting gamecontrol content and moving around proves that
[14:40:20] <fuzzie> yes, this is presumably a "gamecontrol is the wrong size, because ShowGUI got called too early" bug
[14:41:57] <fuzzie> i think the thing is, "runs UpdateControlStatus()" is not true
[14:42:58] <fuzzie> does it help if you call it manually there?
[14:45:51] <lynxlynxlynx> yes
[14:46:11] <lynxlynxlynx> i thought that maybe it is ran too late, some kind of race
[14:46:33] <fuzzie> the core only 'queues' the python functions to be run, so yes, run too late
[14:46:38] <lynxlynxlynx> closing is just fine btw, no amount of manual UpdateControlStatus helped on opening though
[14:48:22] <-- cubathy has left IRC (Ping timeout: 264 seconds)
[14:48:22] <fuzzie> the SetVisible there is also not going to do helpful things, i think
[14:48:49] <lynxlynxlynx> i tried that too
[14:48:50] <fuzzie> but GameSetScreenFlags followed by UpdateControlStatus really ought to do the right thing
[14:49:09] <lynxlynxlynx> both before the unhiding and after, once even at the very start of the functin
[14:49:23] <fuzzie> in the sense that you shouldn't get an anomaly
[14:52:52] <lynxlynxlynx> sometimes i can click through to the slots on the top container row
[14:53:08] <lynxlynxlynx> moving the mouse resets the drawn slots pretty quickly
[14:53:14] <lynxlynxlynx> do we impose some order?
[14:54:13] <lynxlynxlynx> i can move the mouse inside the actionbar part of the container window without the resetting effect
[14:55:03] <fuzzie> yes, we force MessageWindow on top
[14:55:32] <fuzzie> swap GameControl.cpp:2184/2185 to change order
[14:55:57] <fuzzie> but i don't see which MessageWindow we're meant to be using
[14:58:18] <fuzzie> window #18?
[14:58:35] <lynxlynxlynx> for what?
[15:00:28] --> cubathy has joined #GemRb
[15:00:32] <lynxlynxlynx> i don't know what you mean anyway, i see the choice of 4/7/12
[15:01:19] <fuzzie> oh, dammit
[15:02:08] <fuzzie> i had thought there was meant to be a message window there. if not, you ought to simply be able to set the MessageWindow to -1, call UnhideGUI, then set the MessageWindow back.
[15:02:16] <fuzzie> this is what i mean by not being quite sure what is going on.
[15:02:36] <lynxlynxlynx> changing the order did help a bit - the whole container is drawn, but then the side panels are partly wrong
[15:03:16] <fuzzie> and that can be permanently fixed by implementing the lists discussed w/tomprince the other week.
[15:03:25] <lynxlynxlynx> well, the point of keeping the message window valid is that we don't skip on messages
[15:03:46] <lynxlynxlynx> if it is set to -1 DisplayString will bail out
[15:03:47] <fuzzie> but there are gui resources which have a message window at an appropriate position to be displayed along with the container, and i was looking at those.
[15:03:55] <fuzzie> yes, i mean:
[15:04:00] <fuzzie> set MessageWindow to -1
[15:04:02] <fuzzie> UnhideGUI()
[15:04:06] <fuzzie> set MessageWindow back
[15:04:49] <fuzzie> you have to do the same before calling HideGUI again, so it is not really a wonderful idea, but it should work if you just want the window *gone*
[15:19:07] <-- budlust has left IRC (Ping timeout: 248 seconds)
[15:21:45] <edheldil> we could also store messages internally and let the message window be just viewer/controller, not model as well
[15:22:22] <fuzzie> yes, we're already copying messages between textareas
[15:26:32] <lynxlynxlynx> we need that for filtering the inventory messages too
[15:31:45] <tomprince> So would it make sense to pass each message to python, and let python keep track of it?
[15:32:33] <lynxlynxlynx> i don't know why that would be needed
[15:33:14] <lynxlynxlynx> as far as the inventory goes, a 2da with all the allowed strrefs is probably enough
[15:33:17] <tomprince> That seemed to be what edheldil was suggesting, or at least, that was what it called to mind.
[15:35:09] <fuzzie> well, i think python has absolutely no need for access to the contents, so it would be simpler on the C++ side
[15:37:30] <tomprince> I was simply wondering if there was a way to avoid having the C++ side need to know about the message window.
[15:37:32] <fuzzie> since otherwise you'd have to actually copy things around
[15:37:53] <fuzzie> well, that is a more interesting question :)
[15:38:16] <fuzzie> i mean, if you did as edheldil suggested and had a message store instead
[15:38:51] <fuzzie> then i figure edheldil's suggestion would mean you'd just have the python side set a 'viewing message buffer' flag on the TextArea
[15:39:14] <edheldil> complicated a little by dialogs, but hopefully just a little
[15:39:50] <tomprince> And I was thinking just have the python side tell the TextArea what to display.
[15:39:51] <fuzzie> well, ok, a "i am currently the message window" flag
[15:40:05] <fuzzie> tomprince: sure, but you'd be copying huge buffers around then.
[15:40:17] <fuzzie> and you'd have a nightmare trying to do the dialog stuff.
[15:40:53] <tomprince> Yes, I wasn't sure how you would handle dialog stuff. :)
[15:41:23] <fuzzie> for all i think the python side is not a performance issue, i would not want to be copying huge amounts of strings back+forth.
[15:41:47] <fuzzie> i was just proposing a solution that someone could implement in half an hour :-)
[15:41:49] <edheldil> well, but there's not really a need to
[15:42:07] <edheldil> just let the message buffer in C++
[15:43:59] <edheldil> it was just meant as decoupling store from the textarea view/control
[15:44:57] <tomprince> That does make sense.
[15:45:10] --> budlust has joined #GemRb
[15:46:38] <tomprince> If it just took a pointer to a buffer object, we could even set things up so that the buffer could be implemented either from C++ or python, depending on what we want to show.
[15:47:00] <fuzzie> well, again, you make it complicated that way
[15:47:16] <fuzzie> you could implement the buffer thing in 10 minutes, or you could try reimplementing the entire message window design.. :p
[15:47:45] <tomprince> Well, I wouldn't do it that way, unless I had a use for both python and C++ buffers.
[15:50:50] <tomprince> Part of it is just my desire to make Python a first class citizen. And to make the GUI code look more like traditional gui code (not that I have ever written any, to know what it looks like).
[15:53:20] <tomprince> And I probably do have a tendency to design things more complicated than they need to be.
[15:53:24] <tomprince> Or should be.
[15:53:39] <edheldil> I am even worse in this regard
[15:54:28] <tomprince> Althogu fuzzie seems fairly good at reigning in the worst of my excesses.
[15:55:08] <lynxlynxlynx> There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. [C.A.R. Hoare]
[15:56:16] <fuzzie> I tend to lean a bit too far in the "just get it working" followed by the "argh, don't change anything, you'll break it" direction.
[15:56:31] <fuzzie> So a nice balance, maybe :)
[15:57:45] <Gekz> I tend to lean towards take too long but do it perfectly the first time
[15:58:46] <edheldil> can a message arrive while a dialog is open? I guess so, especially w/ network play
[15:58:47] <tomprince> I think it is a nice balance. :)
[15:58:48] <lynxlynxlynx> and i prefer evolutionary design for big stuff
[15:59:12] <edheldil> I am diagnosed with frameworkitis
[15:59:24] <lynxlynxlynx> i'm not sure all dialogs even pause the game
[16:00:15] <Gekz> edheldil: do explain
[16:00:56] <edheldil> I tend to make overcomplicated frameworks for solving a problem
[16:01:19] <edheldil> sometimes they even work and SOMETIMES they are even usable :)
[16:03:05] <tomprince> It probably helps for gemrb that there is moslty working code, that does most of what is needed.
[16:05:13] <edheldil> anyway, interruptible dialogs mean that the message buffer would have to be somehow splitted after the current dialog, so that message can arrive after it. Or queue them until the dialog is updated\
[16:07:15] <lynxlynxlynx> you can't just queue everything like that, things happen in the middle that are run by the dialog too
[16:09:15] <fuzzie> what lynx said :)
[16:11:48] <edheldil> well, ok, but their eventual messages will arrive after user selects a response and before the new dialog state is displayed, so they can fall between them
[16:12:46] <lynxlynxlynx> other things could sneak into the queue and it might not be empty at the start either
[16:14:08] <edheldil> what I meant was something like while you decide whether to tell Deionarra to go to hell on fall crying to her *cough* legs, Morte starts light banter with Annah. (pst is perhaps bad example, but that's the gist of that)
[16:14:31] <edheldil> s/on/or/
[16:15:17] <edheldil> or a nerby coffin vendor starts his pitch
[16:15:23] <edheldil> nearby
[16:15:48] <lynxlynxlynx> double dialog? oO
[16:16:25] <edheldil> hmm, vendor pitches probably do not go to messages
[16:16:33] <-- kingron has left IRC (Remote host closed the connection)
[16:18:12] <edheldil> sooo, to untangle the mess: can a dialog be interruped by a message while it waits for user input?
[16:19:31] <lynxlynxlynx> not interrupted, but the messages will be displayed
[16:19:59] <lynxlynxlynx> think of answering something that ends a quest in bg2 - you get the xp granting messages
[16:20:37] <lynxlynxlynx> i'm not sure if this ever happens at a branching point though
[16:20:46] <fuzzie> (and yes, pst is bad example :p)
[16:21:08] <lynxlynxlynx> (and no, no luck with the -1 approach)
[16:21:15] <edheldil> well, but not while it waits for input, no? (except "close")
[16:21:29] <lynxlynxlynx> i'm not sure
[16:21:50] <edheldil> and then there's multiplayer ....
[16:22:43] <lynxlynxlynx> quick, bring a medic, his condition is severe!
[16:26:57] <edheldil> "talk with him, while I pick his pockets"
[16:47:48] <-- Gekz has left IRC (Quit: Leaving)
[16:50:20] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[16:53:03] <-- budlust has left IRC (Ping timeout: 260 seconds)
[17:47:23] --> |Cable| has joined #GemRb
[17:50:00] <-- tomprince_loki has left IRC (Ping timeout: 265 seconds)
[18:17:11] <-- Lightkey has left IRC (*.net *.split)
[18:18:24] --> Lightkey has joined #GemRb
[18:56:47] <-- tomprince has left IRC (Ping timeout: 245 seconds)
[18:57:06] --> tomprince has joined #GemRb
[19:10:44] --> tomprince_loki has joined #GemRb
[19:58:40] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[19:58:55] --> tomprince_loki has joined #GemRb
[20:37:05] --> kingron has joined #GemRb
[20:47:23] <-- tomprince_loki has left IRC (Ping timeout: 265 seconds)
[22:00:53] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:17:28] <-- kingron has left IRC (Quit: Leaving)
[23:29:06] <tomprince> Any opposition to me adding const whereever I can?
[23:53:17] <tomprince> Speaking of which Inventory::CalculateWeight is rather misnamed.