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

Archive Today Yesterday Tomorrow
GemRB homepage


[00:13:27] <-- Gekz_ has left IRC (Changing host)
[00:13:27] --> Gekz_ has joined #GemRb
[00:33:49] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[00:51:52] --> tomprince_loki has joined #GemRb
[01:22:04] --> Gekz_ has joined #GemRb
[01:44:04] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[01:56:59] --> Gekz_ has joined #GemRb
[04:01:32] <-- Gekz has left IRC (Read error: Connection reset by peer)
[04:01:45] --> Gekz has joined #GemRb
[04:52:24] <-- Gekz_ has left IRC (Changing host)
[04:52:24] --> Gekz_ has joined #GemRb
[05:06:34] <-- raevol has left IRC (Ping timeout: 276 seconds)
[05:17:19] --> cubathy has joined #GemRb
[05:18:29] --> raevol has joined #GemRb
[05:19:43] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[06:17:40] <-- cubathy has left IRC (Read error: Connection reset by peer)
[06:37:40] <-- Gekz has left IRC (Read error: Connection reset by peer)
[06:38:32] --> Gekz has joined #GemRb
[06:59:55] <-- |Cable| has left IRC (Remote host closed the connection)
[07:06:18] <-- Gekz has left IRC (Read error: Connection reset by peer)
[07:06:54] --> Gekz has joined #GemRb
[07:17:28] --> budlust has joined #GemRb
[07:17:43] --> lynxlynxlynx has joined #GemRb
[07:17:44] --- ChanServ gives channel operator status to lynxlynxlynx
[07:40:13] <fuzzie> morning
[07:40:35] <-- budlust has left IRC (Ping timeout: 265 seconds)
[07:41:47] <-- raevol has left IRC (Quit: Leaving.)
[08:01:31] <fuzzie> i guess the 'blue screen of death' on the forum is probably someone missing CD 2 with the area data on it
[08:01:53] <fuzzie> and i thought tomprince fixed the starting area stuff a long time ago :(
[08:35:51] <lynxlynxlynx> could be they're trying .0
[08:52:00] <fuzzie> i guess so
[09:13:59] <-- CIA-25 has left IRC (Ping timeout: 272 seconds)
[09:42:39] --> CIA-23 has joined #GemRb
[10:17:52] <lynxlynxlynx> i'll do the displaystring split next for some diversity and learning
[10:18:14] <lynxlynxlynx> how does DisplayMessage sound for the class name?
[10:21:22] <lynxlynxlynx> also not sure if DisplayStringCore from GSUtils should be moved out/in too
[11:17:09] <fuzzie> do we have a good plan for how that should work?
[11:20:08] <fuzzie> or you just split it and it'll get rewritten later?
[11:37:07] <lynxlynxlynx> which part?
[11:37:18] <lynxlynxlynx> i'm starting just with the interface one
[11:37:57] <fuzzie> i seem to remember we had to fix the interface stuff so that messages could be suppressed?
[11:38:15] <fuzzie> and then some thought needs to go into PS:T
[11:40:07] <lynxlynxlynx> no, i'm not implementing a message queue and filtering
[11:41:17] <fuzzie> well, i realise that :) i just wondered if you took it into account
[11:41:46] <lynxlynxlynx> the headtext stuff is currently in the actor class
[11:42:26] <lynxlynxlynx> i imagine those two would only require caller changes on the outside
[11:42:31] <fuzzie> well, the actual place where the headtext itself is implemented is not so interesting
[11:42:44] <fuzzie> it doesn't even pretend to work at the moment
[11:42:49] <lynxlynxlynx> and additional DS_ flag to mark the few inventory-worthy messages
[11:43:02] <fuzzie> but everything is going to have to go through a central point anyway
[11:43:06] <fuzzie> for the filtering etc
[11:44:13] <fuzzie> so if DisplayMessage is intended solely for MessageWindow duties, then DisplayStringCore should stay very seperate
[11:46:40] <lynxlynxlynx> mhm
[11:47:33] <fuzzie> this is just thoughts, i can't even remember what was discussed previously
[12:10:52] --> Gekz_ has joined #GemRb
[12:11:34] <-- Gekz_ has left IRC (Changing host)
[12:11:34] --> Gekz_ has joined #GemRb
[12:30:31] <lynxlynxlynx> gemrb doesn't link anymore - it doesn't find one new exported symbol
[12:32:01] <lynxlynxlynx> ooh
[12:33:46] <lynxlynxlynx> fixed :)
[13:17:12] <lynxlynxlynx> http://pastebin.ca/1888441 <-- this
[13:17:28] <lynxlynxlynx> feedback wanted
[13:20:34] <Gekz_> why
[13:20:41] --> budlust has joined #GemRb
[13:30:10] <lynxlynxlynx> because i suck
[13:30:41] <Gekz_> oh
[13:42:36] <-- budlust has left IRC (Ping timeout: 265 seconds)
[13:44:42] <fuzzie> well
[13:44:49] <fuzzie> is DisplayMessage intended solely for MessageWindow stuff?
[13:45:00] <fuzzie> if so, the strref_table should be in GameData, i guess
[13:45:51] --> budlust has joined #GemRb
[13:57:35] <-- budlust has left IRC (Ping timeout: 265 seconds)
[13:59:56] --> budlust has joined #GemRb
[14:24:37] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[14:25:07] --> Gekz_ has joined #GemRb
[14:26:35] <tomprince> lynxlynxlynx: If we are going to have a global, no reason also for a member variable in Interface.
[14:28:01] <lynxlynxlynx> i think the queue could be in there too
[14:28:01] <fuzzie> weren't you doing crazy things to *reduce* header deps, just a few days ago? :)
[14:28:20] <fuzzie> oh, i misread
[14:28:27] <fuzzie> there's two in the patch? i must've misread it too
[14:28:39] <lynxlynxlynx> tomprince: it would look ugly directly in the an if test
[14:28:55] <lynxlynxlynx> two what?
[14:30:09] <lynxlynxlynx> i checked if any Interface.h include could be removed due to this, but there aren't any such cases
[14:30:40] <fuzzie> well, what is the member variable in Interface?
[14:30:47] <tomprince> Which test?
[14:30:47] <fuzzie> i don't see
[14:30:57] <lynxlynxlynx> displaymsg
[14:31:48] <fuzzie> but that's a global, no?
[14:31:51] <tomprince> No, I just wasn't looking properly.
[14:31:55] <fuzzie> i thought you were just avoiding overly-complicated singleton code
[14:32:11] <lynxlynxlynx> it is, yes
[14:32:12] --> |Cable| has joined #GemRb
[14:32:17] <tomprince> I thought I saw a meber variable, but I was mistaken/
[14:32:37] <fuzzie> i mean, that is not a statement about it being overly-complicated, just, ok. :)
[14:33:13] <lynxlynxlynx> it is present in the ctor and dtor, which i'm not sure if it is necessary
[14:35:00] <fuzzie> well, the patch looks fine, i am not so sure about the design
[14:35:08] <fuzzie> but that is not something you're really changing here, so that is fine
[14:36:11] <lynxlynxlynx> what's wrong with it?
[14:36:42] <fuzzie> well, there's a whole bunch of different functions doing fairly similar work
[14:37:27] <fuzzie> if there's to be queue handling etc, then i imagine it should be different: a single function taking a type parameter, for example
[14:38:14] <lynxlynxlynx> it's true there is nplication, but that can be lessened
[14:38:17] <fuzzie> and the colours hard-coded into the code are crazy too
[14:38:50] <fuzzie> surely there must be a better way to handle that
[14:38:56] <lynxlynxlynx> unfortunately they are not constant through the games, so we'll have to create another table for the colors
[14:39:28] <fuzzie> seems like the best way to handle it anyway
[14:39:40] <lynxlynxlynx> yeah, modder-friendly
[14:40:22] <fuzzie> but what i meant by "not something you're really changing here" is that your patch doesn't change the design, so it can always be fixed up later for all these problems
[14:40:51] <fuzzie> and to think about it, i'd have to go and look up what exactly the queue needs to do
[14:41:17] <fuzzie> unless you know that off the top of your head
[14:41:46] <lynxlynxlynx> there's the inventory filtering and then there's the actual queueing when the message window is not available
[14:43:03] <fuzzie> but i know fx_protection_from_display_string seems to just be ignored outside effect application right now
[14:44:45] <fuzzie> oh, right, the original engine does this all via effects. surely can be avoided.
[15:00:12] <-- tomprince has left IRC (Ping timeout: 240 seconds)
[15:01:46] --> tomprince has joined #GemRb
[15:16:22] <lynxlynxlynx> http://pastebin.ca/1888519 :)
[15:30:04] <CIA-23> GemRB: 03lynxlupodian * re8997078b2f9 10gemrb/gemrb/GUIScripts/ (bg1/GUIINV.py bg2/GUIINV.py iwd/GUIINV.py pst/GUIINV.py): replace the nonexistant OpenGroundItemAmountWindow with a TODO note
[15:30:07] <CIA-23> GemRB: 03lynxlupodian * r802ad8a2dd5b 10gemrb/gemrb/ (19 files in 5 dirs): split the DisplayMessage functions out of Interface
[15:30:08] <CIA-23> GemRB: 03lynxlupodian * r97b5a50b2445 10gemrb/CMakeLists.txt: cmake: also print the build type when configuring
[15:37:15] <CIA-23> GemRB: 03lynxlupodian * rba2cbfa54e6d 10gemrb/gemrb/core/DisplayMessage.cpp: DisplayMessage: reduce code duplication between all the Display*StringNames
[15:37:17] <CIA-23> GemRB: 03lynxlupodian * rc34d374d72ac 10gemrb/gemrb/core/ (DisplayMessage.cpp DisplayMessage.h): DisplayMessage: added another DisplayString to reduce code duplication
[15:38:07] <-- budlust has left IRC (Ping timeout: 265 seconds)
[15:51:52] --> budlust has joined #GemRb
[15:54:28] <-- |Cable| has left IRC (Quit: Leaving)
[16:08:11] <-- budlust has left IRC (Ping timeout: 240 seconds)
[16:10:44] --> Maighstir_laptop has joined #GemRb
[16:11:30] <lynxlynxlynx> ups, you can't exit stores anymore
[16:14:22] <lynxlynxlynx> GemRB.RunEventHandler doesn't take objects and the passed string isn't good enough either
[16:16:01] <lynxlynxlynx> odd function
[16:16:09] --> budlust has joined #GemRb
[16:17:50] <tomprince> Any reason to not just call the function directly?
[16:18:17] <lynxlynxlynx> not in bg2
[16:18:42] <lynxlynxlynx> i guess it was used by name before, since the function is from another module
[16:19:52] <CIA-23> GemRB: 03lynxlupodian * r4b6a4d3c8c1a 10gemrb/gemrb/GUIScripts/bg2/GUISTORE.py: bg2: fixed bag closing
[16:19:57] <lynxlynxlynx> it's used like 5 times, so i'm sure we can kill it once everything gets cleaned up
[16:21:08] <-- budlust has left IRC (Ping timeout: 265 seconds)
[16:23:48] <fuzzie> doesn't seem like there's any reason for RunEventHandler to exist
[16:27:15] --> |Cable| has joined #GemRb
[16:27:47] <lynxlynxlynx> the tob intro stuff still works beautifully
[16:28:18] <fuzzie> :)
[16:28:31] <fuzzie> the waves and all?
[16:28:56] <lynxlynxlynx> just before that, but i'm going to try that too, need to get to civilians
[16:32:24] --> muni has joined #GemRb
[16:32:32] --> budlust has joined #GemRb
[16:34:48] <lynxlynxlynx> yep, just fine
[16:34:58] <fuzzie> hoorah
[16:36:14] <-- Gekz_ has left IRC (Changing host)
[16:36:14] --> Gekz_ has joined #GemRb
[16:38:38] <lynxlynxlynx> ouch, segfault
[16:41:25] <-- budlust has left IRC (Quit: Konversation terminated!)
[16:41:46] --> budlust has joined #GemRb
[16:45:35] <lynxlynxlynx> ranger and paladins can't fall unless it is done via actions, but then we don't consider this anywhere else
[16:46:33] <fuzzie> do we need to?
[16:47:12] <lynxlynxlynx> the ability removal could be done in the actions, but we just set the bit currently
[16:47:37] <lynxlynxlynx> it's a complicated matter
[16:47:55] <fuzzie> what would you want to do, delayed python script run?
[16:48:02] <fuzzie> or something in-core?
[16:48:53] <lynxlynxlynx> i haven't though about it, but probably in the core
[16:49:11] <lynxlynxlynx> never had a fallen x in the original, so i don't know the full extent of the change
[16:49:24] <fuzzie> i wonder if we need to hard-code the rep check too
[16:49:30] <fuzzie> or is that just scripted?
[16:49:47] <lynxlynxlynx> spellcasting, innates, turn undead get disabled, maybe more
[16:51:02] <lynxlynxlynx> only one script does it manually and it is an area one
[16:51:10] <fuzzie> drat
[16:51:30] <lynxlynxlynx> one of the hell challenges
[16:52:09] <lynxlynxlynx> nothing in the other games
[17:10:17] <fuzzie> the original action might just force you to a fighter, i don't know
[17:11:21] <lynxlynxlynx> i doubt it due to all the fighter nonwarior hacks
[17:12:06] <fuzzie> avenger's commentary is only that it sets the relevant 'was paladin/ranger' creature flag and displays 'Lost Class: xxx'
[17:13:22] <lynxlynxlynx> then it is spread all over the place
[17:13:36] <fuzzie> there's a lot of function calls but i have no ideas
[17:14:26] <lynxlynxlynx> something for the future, it's a pretty obscure feature
[17:14:29] <fuzzie> but it definitely modifies the kit
[17:14:44] <fuzzie> what on earth is addsuperkit, anyway?
[17:15:05] <fuzzie> ah, adds on top
[17:15:12] <lynxlynxlynx> super hehe
[17:33:21] <lynxlynxlynx> writting an automation to do the rest of the cleanups
[17:34:49] --> cubathy has joined #GemRb
[17:35:29] <fuzzie> the imports?
[17:35:38] <lynxlynxlynx> yes
[17:36:09] <lynxlynxlynx> it drags the seteventbyname changes with it
[17:36:14] <fuzzie> mhm
[17:36:21] <fuzzie> you'll test it?
[17:36:44] <lynxlynxlynx> it can't do everything, so i'll have to manually do a few bits anyway
[17:38:08] <fuzzie> i think everything except the chargens should be trivial though
[17:39:13] <lynxlynxlynx> the step-by-step bg2 change definitely helps, i know exactly where things should be and how to make them like it
[17:39:35] <lynxlynxlynx> i won't touch bg1, since i can't test it
[17:39:50] <fuzzie> i think bg1 and iwd2 are the odd chargens
[17:40:49] <fuzzie> don't have bg1 handy here, but tomorrow afternoon
[17:41:19] <-- budlust has left IRC (Ping timeout: 260 seconds)
[17:42:57] <fuzzie> File "/home/fuzzie/src/gemrb/gemrb/GUIScripts/iwd2/GUICommonWindows.py", line 593, in CheckLevelUp
[17:43:00] <fuzzie> GemRB.SetVar (CheckLevelUp+str(pc), CanLevelUp (pc))
[17:43:03] <fuzzie> TypeError: unsupported operand type(s) for +: 'function' and 'str'
[17:43:31] <lynxlynxlynx> aha
[17:43:36] <fuzzie> copy-and-pasted?
[17:43:46] <lynxlynxlynx> i fixed this in bg2
[17:44:04] <lynxlynxlynx> hopefuly the function can be moved to a shared place, since it is the same everywhere
[17:44:08] <fuzzie> the commit has the same thing in bg1/bg2/iwd/iwd2
[17:44:21] <fuzzie> oh, and pst. so the whole set.
[17:44:55] <lynxlynxlynx> GemRB.SetVar ("CheckLevelUp"+str(pc), LUCommon.CanLevelUp (pc)) <-- this is how it will look when i'm done with it
[17:45:05] <lynxlynxlynx> but first iwd1
[17:45:29] <fuzzie> and a cheat in GearsClicked, heh :)
[17:46:00] <lynxlynxlynx> that wasn't intentional, but it is very handy
[17:48:35] <fuzzie> i should make a note to think about all that code
[17:48:49] <fuzzie> calling into python there will become a disaster once someone has the clever idea to interfere with actors from the python
[17:49:03] <lynxlynxlynx> it's a hack
[17:49:39] <fuzzie> but other parts of pcf_ need work anyway
[17:49:58] <fuzzie> i think Die() is still called from there, which is why death is so broken
[18:01:02] <tomprince> Should CheckLevelUp just return a bool, rather than using a variable?
[18:02:29] <lynxlynxlynx> ideally it shouldn't be needed
[18:03:45] <tomprince> Should that logic move to C++ then?
[18:04:59] <lynxlynxlynx> the goal was to avoid that
[18:08:11] <Maighstir_laptop> how's right-click+drag to rotate formation going?
[18:08:30] <Maighstir_laptop> :-D
[18:08:46] <fuzzie> the rest of the CheckLevelUp logic should move to python, presumably
[18:09:06] <lynxlynxlynx> hah
[18:09:47] <lynxlynxlynx> Maighstir_laptop: i mention that to fuzzie whenever she is looking for something non iescript related, but apparently it is not so simple
[18:09:49] <fuzzie> just add a NotifyLevelUp c++ function which sets GotLUFeedback and does the string display, for now
[18:10:14] <fuzzie> well, when i implemented the formation stuff, i didn't even realise the rotation mode existed, until lynx mentioned the lack :)
[18:11:10] <fuzzie> i'm not sure if there's a smarter way to handle this stuff than that
[18:13:45] <fuzzie> i wonder if allowing python functions to return values would be useful anywhere else?
[18:14:06] <fuzzie> not really, i guess.
[18:14:43] <tomprince> Easy enough to handle, if it ever comes up.
[18:14:47] <fuzzie> mhm
[18:17:03] <fuzzie> well, i'm sure it might be useful if we move more game rules into python
[18:18:22] <fuzzie> but enough to do atm without that..
[18:19:26] <fuzzie> i keep forgetting about all these serious bug reports lurking on the forums, too
[18:19:32] <fuzzie> no-one looked into those, i guess?
[18:20:16] <fuzzie> i hope the potions one is just charges
[18:21:44] <lynxlynxlynx> the bg stuff? i added a link to the buglist summary to the wiki immediately ;)
[18:22:18] <lynxlynxlynx> nothing new on that list though
[18:22:25] <fuzzie> oh hey, maybe sound handles is something to suggest to tomprince
[18:22:35] <fuzzie> i don't remember why we needed them, but i know we did
[18:23:08] <lynxlynxlynx> we didn't have the ability to stop sound at some point, but iirc zefklop fixed that
[18:23:23] <fuzzie> oh?
[18:23:42] <lynxlynxlynx> None as the parameter instead of something real
[18:23:48] <fuzzie> oh, right
[18:24:19] <fuzzie> this is for projectiles, it seems: handles to allow temporary sounds to be set looping, stopped and moved around (to follow the projectile location)
[18:25:03] <fuzzie> wishlist item came from Avenger, i guess
[18:25:21] <lynxlynxlynx> mhm
[18:26:07] <fuzzie> it would be nice to know whether the openal music thread opening music files is a problem, too, and since tomprince rewrote pretty much all the resource code, i guess he'd know
[18:26:46] <fuzzie> my simple solution of moving responsibility to the main thread means that music stopped working on the load screens :(
[18:33:39] <tomprince> The file opening shouldn't be an issue, since DirectoryImporter is stateless.
[18:34:40] <fuzzie> okay, that is reassuring :)
[18:35:03] <tomprince> There might be a race in MUSImporter.
[18:35:49] <fuzzie> i don't really remember how any of it works
[18:36:03] <fuzzie> i know that i broke some of this logic a while ago
[18:37:17] <fuzzie> the "// perhaps a StartMusic action stopped the area music?" logic in Game.cpp is terrible, i'm pretty sure we should just keep track of that
[18:37:40] <fuzzie> and above that our CombatCounter code, sigh
[18:38:30] <fuzzie> that needs a serious review
[18:39:00] <fuzzie> it's meant to be set to a high value (250 or so?) on every combat event, and count down to 0
[18:39:19] <fuzzie> with the combat music enabled and saving disabled while the counter is non-zero, and some other effects
[18:39:36] <fuzzie> but it's abused all over Game.cpp and i'm not sure enough of how it works to fix it
[18:53:16] <lynxlynxlynx> stop worrying about everything at the same time ;)
[18:53:47] <fuzzie> well, all of this is on todo already :)
[18:54:07] <tomprince_loki> I am curious what the sound handles bit is, or do we need to wait for avenger to reappear?
[18:54:09] <fuzzie> but i am just rambling in between memorising boring formulas
[18:54:29] <fuzzie> tomprince_loki: just simply a way to control the position/status of playing audio
[18:54:49] <fuzzie> primarily so that projectiles can set audio looping and then update it as they move
[18:58:26] <fuzzie> i think everything relevant is already decoded: looping is controlled by SFlags&PSF_LOOPING
[18:58:45] <fuzzie> it's just very much a 'design an API' task, so i thought of you :)
[19:01:12] <tomprince_loki> I'll have a look into it then.
[19:02:29] <tomprince_loki> It seems like the ambients could also use this?
[19:03:01] <fuzzie> honestly, i know nothing about it
[19:06:19] <tomprince_loki> So, my understanding is that we need a sound source that moves around, and can play various files at various points in time, controled by some outside source?
[19:06:43] <fuzzie> i think the various files is not strictly necessary
[19:07:16] <fuzzie> just a "i want to play this file, with it in a loop" and then some outside source controlling position and being able to stop it
[19:08:08] <fuzzie> but if you're looking at the ambients, you probably know more than I do
[19:08:52] <tomprince_loki> Well, I was just thinking, if the projectiles only ever need to play one sound, but different sounds over time, they coulde get away with a single source.
[19:09:32] <fuzzie> well, from the openal/SDL/other API point of view, you don't want to keep the internal stream/etc open unless it's actually in use
[19:09:46] <fuzzie> but obviously you could easily map that away
[19:10:02] <fuzzie> but projectiles do need to play different sounds at different points, and they might well overlap..
[19:10:33] <fuzzie> the existing ambient code, on the other hand, seems to be keeping "ownership" of dedicated channel, if i read it right, which i might not be
[19:10:43] <tomprince_loki> If they overlap, then it is perhaps not worth it.
[19:11:22] <fuzzie> i think you probably have impact+explosion sounds overlapping, but i don't know anything about it.
[19:11:50] <fuzzie> wjp probably knows about the ambient code, come to think of it, since he refactored it
[19:12:06] * fuzzie waves cake in the direction of wjp
[19:21:08] <wjp> hm?
[19:21:32] <wjp> what did I break?
[19:22:15] <fuzzie> a healthy automatic response there :p
[19:27:22] <wjp> it does seem like ambients hold on to their streams
[19:32:32] <fuzzie> any idea why?
[19:32:36] <wjp> in theory only if there's a fair chance they'll be playing again "soon", but I'm not sure how solid that logic is
[19:32:42] <fuzzie> *nod*
[19:33:04] <tomprince_loki> Soon being half a second. it looks like.
[19:33:25] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[19:41:03] --> Maighstir_laptop has joined #GemRb
[19:41:46] <-- cubathy has left IRC (Ping timeout: 264 seconds)
[19:42:39] <fuzzie> but even if it's too complicated to do, thoughts on a design would be appreciated
[19:47:16] <lynxlynxlynx> meh, silly iwd with nonunique function names
[19:49:48] <tomprince_loki> One thing I was considering, for the python side, is changing all the Open*Window to just Open, and, in fact, splitting it up into Open, and Close.
[19:50:20] <tomprince_loki> ... now that we don't need to worry about global naming conflicts.
[19:50:52] <tomprince_loki> i.e. have GUIMAP.Open(), rather than GUIMAP.OpenMapWindow()
[19:51:35] <lynxlynxlynx> where's the gain?
[19:51:49] <lynxlynxlynx> some have plenty of other windows inside
[19:52:16] <lynxlynxlynx> a .Close() that would terminate everything wherever you are in that module would be handier
[19:52:16] <fuzzie> makes things a bit more ambigious at a glance, too
[19:52:34] <fuzzie> the really tricky bit is trying to close some windows while keeping others open
[19:52:54] <lynxlynxlynx> yeah, limited use case
[19:53:08] <fuzzie> well, they are the cases where i've given up on trying to make it work, with the current desing
[19:53:11] <fuzzie> design
[19:53:26] <fuzzie> so i am motivated to keep people thinking about that :)
[19:53:48] --> cubathy has joined #GemRb
[19:53:51] <tomprince_loki> When do you only want to clse some windows?
[19:53:57] <fuzzie> when you're opening sub-windows
[19:54:01] <fuzzie> and then closing them again
[19:54:23] <fuzzie> options windows in some of the games i think, and the inventory is an obvious candidate, and various bits in iwd2
[19:54:41] <lynxlynxlynx> and to make it fun, there are at least two levels of subwindows
[19:56:00] <tomprince_loki> Is it ever more that one way? in IWD2? I never did play the original of that.
[19:56:26] <fuzzie> well, i also haven't played the original of iwd2
[19:56:35] <lynxlynxlynx> one way?
[19:56:41] <fuzzie> but yes, all of this is two-way.
[19:57:14] <tomprince_loki> A window opens subwindows, and switches between them, but only while the main one is open.
[19:57:37] <tomprince_loki> Is there ever a case where you want a subwindow open, but not the main window?
[19:58:22] <lynxlynxlynx> you don't care about the first subwindow usually
[19:58:42] <lynxlynxlynx> the main one is always the biggest, so unless the subwindow is also fullscreen, it needs to remain drawn
[19:59:31] <fuzzie> well, there are various examples of multiple windows inside a single CHU file, obviously
[19:59:37] <lynxlynxlynx> the subwindows come in different sizes though and are sometimes aligned well, but if you have two of them open, the default button settings (and probably more) will be screwed up
[19:59:44] <fuzzie> but afaik there's nothing stopping us from splitting those into multiple python modules
[19:59:53] <fuzzie> the world map is an obvious example
[20:00:15] <tomprince_loki> I guess what I am asking, is the set of displayed windows like a tree, that any node, and it parents will be drawn... but not nodes on two differnt paths from the root.
[20:01:04] <lynxlynxlynx> the options and portrait windows are on different paths
[20:01:11] <fuzzie> but on the other hand, it should really be as flexible as possible
[20:01:31] <fuzzie> so i'm not sure why it matters so much
[20:02:06] <fuzzie> oh, i guess the sensible way to implement window closing would be to have a stack design
[20:02:59] <fuzzie> for the screens -- which i guess is what's being discussed -- i think that would always work, although it's useless for windows in general obviously
[20:04:30] <fuzzie> although it doesn't actually seem like a stack helps at all, because windows always know what their parents/siblings are anyway..
[20:17:39] <lynxlynxlynx> ok, autorun done, now to mend the wounds
[20:19:32] <fuzzie> if you want testing, am looking for distractions while staring at pages of formulas, so..
[20:20:41] <lynxlynxlynx> nah, i need to review it first
[20:21:06] <lynxlynxlynx> there's a bunch of false positivies due to common function names like DonePress
[20:21:30] <lynxlynxlynx> i'll make the bg1 switch in a branch so others can test it later
[20:22:05] <fuzzie> but you can test iwd2?
[20:22:12] <lynxlynxlynx> yep
[20:22:15] <fuzzie> ok, neat
[20:23:30] --> budlust has joined #GemRb
[20:24:28] --- Dark-Star|away is now known as Dark-Star
[21:08:40] --> raevol has joined #GemRb
[21:14:01] <-- budlust has left IRC (Ping timeout: 265 seconds)
[21:16:37] <fuzzie> oh, there's some more information about looping projectile sounds in that pro format forum post
[21:18:39] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[21:19:23] --> budlust has joined #GemRb
[21:30:31] <-- budlust has left IRC (Ping timeout: 240 seconds)
[21:36:21] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[21:39:25] --> tomprince_loki has joined #GemRb
[21:46:55] --> budlust has joined #GemRb
[21:51:14] <-- tomprince_loki has left IRC (Read error: Connection reset by peer)
[21:55:29] --> Maighstir_laptop has joined #GemRb
[21:57:02] <-- budlust has left IRC (Remote host closed the connection)
[22:02:10] --> tomprince_loki has joined #GemRb
[22:04:45] <lynxlynxlynx> nice, in iwd you can actually change the brightness live
[22:06:42] <lynxlynxlynx> and unlike in bg2 it doesn't matter if the window has focus or not, it is of equal brightness
[22:09:12] <CIA-23> GemRB: 03lynxlupodian * r5731cc08aa42 10gemrb/gemrb/GUIScripts/iwd/GUISTORE.py: iwd: don't use RunEventHandler
[22:09:14] <CIA-23> GemRB: 03lynxlupodian * rede1f927f189 10gemrb/gemrb/GUIScripts/iwd/CharGen.py: iwd: renamed a few cg functions to be unique
[22:09:19] <CIA-23> GemRB: 03lynxlupodian * rff3f5e8a56dc 10gemrb/gemrb/GUIScripts/iwd/ (18 files): iwd: clean up imports and switch to using direct python fallbacks
[22:09:36] <CIA-23> GemRB: 03lynxlupodian * rbf2aee208d9e 10gemrb/gemrb/GUIScripts/bg2/GUIREC.py: bg2::GUIREC: GetActorPaperDoll is from GUICommon
[22:10:09] --> budlust has joined #GemRb
[22:11:55] <lynxlynxlynx> fixed it in the original ini
[22:25:34] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:33:17] <-- budlust has left IRC (Ping timeout: 265 seconds)
[22:43:28] <-- tomprince_loki has left IRC (Ping timeout: 258 seconds)
[22:46:21] --- Dark-Star is now known as Dark-Star|away
[22:47:48] <-- cubathy has left IRC (Ping timeout: 260 seconds)
[23:38:48] <-- muni has left IRC (Quit: Leaving)
[23:56:10] --> tomprince_loki has joined #GemRb