[00:16:51] <tomprince> or.cz/listbox: First go at refactoring GUISAVE/LOAD.
[00:17:07] <tomprince> There should be some more refacotring, and the symlinks should go.
[00:17:22] <tomprince> Also, all the strref/control numbers need to be double-checked.
[00:30:51] <tomprince> Also, the naming need lots more thought.
[01:45:38] --> Maighstir_laptop has joined #GemRb
[01:52:43] <-- Maighstir_laptop has left IRC (Ping timeout: 265 seconds)
[02:09:47] <-- anji has left IRC (*.net *.split)
[02:09:47] <-- fuzzie has left IRC (*.net *.split)
[02:10:56] --> anji has joined #GemRb
[02:10:56] --> fuzzie has joined #GemRb
[05:38:34] --> raevol has joined #GemRb
[05:42:51] <-- raevol has left IRC (Ping timeout: 240 seconds)
[05:48:49] --> raevol has joined #GemRb
[06:28:09] --> budlust has joined #GemRb
[06:38:21] <-- budlust has left IRC (Quit: Konversation terminated!)
[06:38:39] --> budlust has joined #GemRb
[06:56:54] <-- |Cable| has left IRC (Remote host closed the connection)
[07:01:31] --> pupnik_ has joined #GemRb
[07:05:03] <-- pupnik has left IRC (Ping timeout: 260 seconds)
[07:24:16] <-- budlust has left IRC (Ping timeout: 265 seconds)
[07:27:20] --> lynxlynxlynx has joined #GemRb
[07:27:21] --- ChanServ gives channel operator status to lynxlynxlynx
[08:05:11] <fuzzie> tomprince: loading windows in advance is a habit i'd prefer the scripts not get into
[08:05:25] <fuzzie> but i don't see that the save confirm window is going to be a problem resource-wise
[08:05:46] <fuzzie> since it's going to have to be loaded *anyway*
[08:06:15] <fuzzie> no chance to review the code, my ISP's neighbourhood router died last night
[08:06:54] <fuzzie> shall wander to uni and use their connection
[08:15:38] --> Maighstir_laptop has joined #GemRb
[08:31:28] <-- pupnik_ has left IRC (Ping timeout: 276 seconds)
[08:54:32] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[09:14:20] --> pupnik has joined #GemRb
[09:24:54] <-- raevol has left IRC (Quit: Leaving.)
[09:27:40] --> miles_ has joined #GemRb
[10:47:47] <-- miles_ has left IRC (Ping timeout: 265 seconds)
[10:50:37] --> miles_ has joined #GemRb
[11:03:31] <lynxlynxlynx> huh
[11:03:52] <lynxlynxlynx> pst in the original resolution doesn't show the portrait window nor the common windows here
[11:04:02] <lynxlynxlynx> on a custom resolution both show fine though
[11:04:17] <lynxlynxlynx> however the messagewindow is cut
[11:04:38] <lynxlynxlynx> this is after the import cleanup, but i'm not sure how much of this is new
[11:04:52] <lynxlynxlynx> the msgwin definitely worked before on the custom resolution though
[11:22:04] <edheldil> eek :)
[11:25:28] <fuzzie> hm, i have only been testing with the widescreen mod
[11:26:22] <lynxlynxlynx> pst doesn't have an UpdateActionsWindow, but trying different stuff for it hasn't helped
[11:27:45] <fuzzie> although my widescreen mod copy seems just fine
[11:28:15] <fuzzie> i have been keeping an eye on it because it tends to be the unloved one
[11:28:15] <lynxlynxlynx> in my custom res it is obvious the msgwin is moved a bit - it doesn't touch the portrait window
[11:28:33] <fuzzie> now i'm confused
[11:28:46] <fuzzie> you have a gui hack?
[11:28:57] <lynxlynxlynx> on the original res, the loadscreen stuff is left where the common windows should be
[11:29:08] <lynxlynxlynx> i have widescreen
[11:29:47] <lynxlynxlynx> just saying that i have different problems with the modded resolution and the original one, the ones for the latter being graver
[11:30:07] <lynxlynxlynx> and that i haven't tried the original res in long while, so i don't have a baseline
[11:30:30] <lynxlynxlynx> but i haven't been able to fix the problems with the custom one either
[11:30:30] <fuzzie> hm
[11:30:38] <fuzzie> the original one hasn't been touched by weidu?
[11:31:01] <lynxlynxlynx> likely, but let me check
[11:31:02] <fuzzie> or this is one install with the widescreen mod set for gemrb mode? because i'm not sure anyone tested that
[11:32:03] <lynxlynxlynx> there is a guiworld.chu in the override, but everything there has the same timestamp as the custom chu
[11:32:11] <lynxlynxlynx> it was created with the gemrb mode, yes
[11:32:32] <lynxlynxlynx> cgui1070.chu
[11:32:57] <fuzzie> original pst seems to work fine here
[11:33:24] <fuzzie> well, as fine as it ever did, still various stupid bugs
[11:33:50] <lynxlynxlynx> ok, i'll branch it off and retry
[11:34:29] <fuzzie> the gui in all the games has started flickering when i open/close things
[11:34:42] <fuzzie> and the broken RunFunction for enter in dialogs is really super annoying
[11:34:59] <fuzzie> can i just add a module name there?
[11:35:03] <lynxlynxlynx> sure
[11:35:25] <lynxlynxlynx> i explicitly left those alone, since you said you're about to remove them
[11:36:06] <fuzzie> that one in particular is not a keybinding thing, i think
[11:36:51] <lynxlynxlynx> i get the open flicker only when reopening containers
[11:37:28] <fuzzie> i mean, this in a lot of the screens, too
[11:37:35] <fuzzie> i can't work out what would have changed to cause that, though
[11:37:55] <fuzzie> maybe my fault
[11:38:31] <lynxlynxlynx> can't say i noticed it
[11:38:45] <lynxlynxlynx> good news: the custom gui had the same problem before my changes
[11:39:04] <lynxlynxlynx> same with the original one
[11:39:17] <lynxlynxlynx> so i'll just commit
[11:39:26] <fuzzie> oke
[11:40:42] <CIA-23> GemRB: 03lynxlupodian * r6c952652b5f5 10gemrb/gemrb/GUIScripts/pst/ (18 files): pst: clean up imports and switch to using direct python fallbacks
[11:40:43] <CIA-23> GemRB: 03lynxlupodian * re8dc2c6f7871 10gemrb/gemrb/ (GUIScripts/GUICommon.py core/GameControl.cpp):
[11:40:43] <CIA-23> GemRB: call the pst version of OpenFloatMenuWindow from GUICommon, so all can be
[11:40:43] <CIA-23> GemRB: accessed from the same module
[11:41:23] <lynxlynxlynx> btw, do you have a guiworld.chu in override?
[11:41:32] <fuzzie> still fine here
[11:43:38] <fuzzie> and yes, i do
[11:43:50] <lynxlynxlynx> c16be43bba57cc750c4f0e7dc16bb70d ?
[11:44:19] <fuzzie> no
[11:44:25] <fuzzie> d65ec020a5c2ae37658d44ab70b7a656
[11:44:29] <fuzzie> which seems to be identical to the one in the bif
[11:47:05] <lynxlynxlynx> i'll just delete it then
[11:47:07] <fuzzie> those python changes seem fine too
[11:47:17] <fuzzie> although i didn't bother rebuilding for the float window :)
[11:47:46] <lynxlynxlynx> ah yes, that fixed it
[11:47:57] <lynxlynxlynx> minimum res is perfect
[11:48:11] <tomprince> fuzzie: The code doesn't actually preload the confirm window, although I think the code would be clearer if we did.
[11:48:22] <lynxlynxlynx> [GameControl]: More than one bottom window!
[11:48:28] <fuzzie> well, i had a glance at the branch but i don't understand a word
[11:48:40] <fuzzie> lynxlynxlynx: yes, that code is on the 'to rewrite' list because tomprince encountered problems in .. bg2, i think
[11:49:00] <tomprince> We unload windows when we make them invisible, so I we have to reload them each time we shouw them.
[11:49:11] <fuzzie> but the widescreen mod writes some really stupid stuff
[11:50:00] <fuzzie> and gemrb's gamecontrol code is really stupid too
[11:53:03] <fuzzie> tomprince: are there common cases when we make a window invisible which we're going to want to be visible right after?
[11:54:12] <tomprince> Don't know, haven't looked. The one case I ran into, is if some tries to delete multiple savegames, or goes to save a game, and keeps cancelling, once the save confirm window is open.
[11:54:17] <fuzzie> i realise that the absurd SDL and tile loading code right now makes it pale into insignificance
[11:54:41] <fuzzie> and i think honestly in the save/load windows you can do what you want :)
[11:55:14] <-- miles_ has left IRC (Read error: Connection reset by peer)
[11:55:28] <lynxlynxlynx> it would be great to have one release cycle focused on performance some time
[11:55:35] --> miles_ has joined #GemRb
[11:56:33] <fuzzie> well, tomprince has been fixing my requests for performance fixes in the resource stuff
[11:56:56] <fuzzie> it's quite a bit better on disk I/O than it was, especially with the decompression changes
[11:57:19] <lynxlynxlynx> but the sdl hog remains
[11:57:36] <fuzzie> yes, it is amazingly stupid and slow
[11:59:33] <fuzzie> one reason why the opengl thing is on the list
[12:02:14] <tomprince> The idea behind what i did with the save/load, was to move all the logic into LoadSave.py, and just leave the stuff that knows the window/control/strref# in GUILOAD/SAVE.
[12:03:08] <tomprince> And since we can't keep windows loaded, GUISAVE/LOAD passes in function to load the confirm window into the generic code.
[12:03:12] <fuzzie> i figured that, just the commits are a bit too fractured to make sense of, at a glance
[12:03:40] <tomprince> Well, don't look at the commits, just look at the final result.
[12:06:06] <fuzzie> well
[12:06:10] <fuzzie> the final result doesn't make much sense either
[12:06:34] <fuzzie> hacks with __call__, etc
[12:06:42] <fuzzie> but no time right now, it seems, i have to rush off again..
[12:19:43] <tomprince> Yes, the __call__ is a hack -> the object is to be an event handler. Although I guess it would be clearer to create the object beforehand.
[12:35:32] <-- tomprince has left IRC (Ping timeout: 265 seconds)
[13:06:52] --> tomprince has joined #GemRb
[13:07:28] <tomprince> or.cz/listbox: Updated to rename out __call__, and factor out more of GUILOAD
[13:07:32] <tomprince> Still a mess. :)
[13:16:32] <fuzzie> lynxlynxlynx: you saw forum post about python error?
[13:16:54] <lynxlynxlynx> i think that's already fixed
[13:17:11] <lynxlynxlynx> or is there something new since avenger's reply?
[13:17:24] <fuzzie> no, just that :)
[13:17:30] <fuzzie> i assume already fixed, but i thought you'd know better
[13:18:01] <lynxlynxlynx> got most of bg1 ready
[13:18:27] <lynxlynxlynx> time for some grunt work and then it should be done in the evening
[13:46:38] <-- miles_ has left IRC (Quit: Konversation terminated!)
[13:46:55] --> budlust has joined #GemRb
[14:01:05] <-- budlust has left IRC (Ping timeout: 265 seconds)
[14:10:19] --> budlust has joined #GemRb
[14:36:21] <-- budlust has left IRC (Ping timeout: 260 seconds)
[14:36:25] --> budlust has joined #GemRb
[14:49:26] --> |Cable| has joined #GemRb
[15:28:34] <lynxlynxlynx> i was back sooner than anticipated ;)
[15:31:50] <lynxlynxlynx> i'm sure there'll be some problems (as noted), but they are most easily found at runtime
[15:31:56] <tomprince> So what is your opinion on storing controls as part of the window, rather than as global variables?
[15:32:45] <fuzzie> do we store many controls in globals?
[15:33:12] <tomprince> Either in globals, or GetControl(num) every time, as far as I can tell.
[15:33:34] <fuzzie> but i guess it's just a question of whether it's simpler?
[15:33:57] <tomprince> With things like Button = window.GetControl; Button.stuff; Button = window.getControl(other); Button.stuff ....
[15:34:01] <fuzzie> not as if there's any extra infrastructure required
[15:35:58] <lynxlynxlynx> Button Button Button stuff should be changed to be clearer
[15:36:03] <fuzzie> and so not something you have to enforce, just do it if it's easier (which I guess means if it's a control which does more than just get a one-time initialisation)
[15:37:03] <fuzzie> the GUISAVE code does seem to use 'Button' and 'Button2' as variable names, which is icky
[15:37:58] <fuzzie> but i guess fixing that is just going to conflict with tomprince's changes, so i will resist
[15:42:03] <lynxlynxlynx> do you want me to add the containing module to that CloseContinueWindow runfunction call?
[15:43:02] <tomprince> Also, I was wondering about syntax: Window.Control just requires adding a __dict__ slot in the metaclass. Window['Control'] would have the benefit of separating the control namespace from the method namespace, but would require a bit mor hacking.
[15:45:39] <tomprince> This next idea is perhaps too fancy of an abstraction, but: The Create*Window functions in the GUISAVE/LOAD are rather ugly. It wouldn't be too hard to create Window/ControlFactory objects that behave more or less like Window/Controls, but don't actually call into C++, but will replay what was done to them on demand.
[15:45:56] <tomprince> ^--- This is of course with my overly abstract making hat on. :)
[15:46:01] <fuzzie> well
[15:46:10] <fuzzie> the whole thing is with your overly abstract making class on,no?
[15:46:17] <tomprince> Mostly yes.
[15:46:23] <tomprince> That list bit especially so.
[15:46:26] <fuzzie> if you want to put a button in a window object, do 'WindowObject.MyButton = WindowObject.GetButton(5)' :P
[15:47:04] <fuzzie> does that not work for some weird metaclass reason?
[15:47:12] <tomprince> Well, I was wondering if WindowObject['MyButton'] = WindowObject.GetControl(5) might be nicer.
[15:47:24] <fuzzie> it doesn't seem so
[15:47:40] <fuzzie> it does split the namespaces, but not in a very clear way
[15:47:46] <tomprince> It almost works, we need to add __dict__ to the slots.
[15:47:56] <tomprince> Which I did in one of the commits.
[15:48:02] <fuzzie> but maybe lynx has a comment
[15:48:34] <fuzzie> lynxlynxlynx: please
[15:49:36] <fuzzie> i mean, in response to your question, not begging for a comment :)
[15:49:40] <lynxlynxlynx> i don't see it as nicer
[15:49:45] <lynxlynxlynx> yep
[15:50:31] <fuzzie> hm, i am not being very coherent :-)
[15:50:52] <CIA-23> GemRB: 03lynxlupodian * r326946f31e44 10gemrb/gemrb/GUIScripts/iwd/GUIWORLD.py: iwd: PortraitWindow is from gcw
[15:50:53] <CIA-23> GemRB: 03lynxlupodian * r2309bb9cbc54 10gemrb/gemrb/core/GameControl.cpp: GameControl: specify the module CloseContinueWindow is in
[15:50:57] <fuzzie> i can see the argument for splitting the namespaces, but i think the dict complicates things way more than it'd be worth
[15:52:44] <fuzzie> and i don't understand the second idea, the Create*Window functions are entirely created by the patch?
[15:53:18] <fuzzie> not trying to be obtuse there, just not sure what exactly you would gain
[15:53:21] <tomprince> And an example of what I was talking about for factories: http://pastie.org/1017318 to replace the CreateConfirmDeleteWindow in GUILOAD/SAVE
[15:54:05] <fuzzie> but you still have the same code?
[15:54:41] <fuzzie> that AddControl syntax is *far* too magic, but i guess that is not part of your point
[15:56:10] <tomprince> Or, with perhaps less magic: http://pastie.org/1017326
[15:56:24] <fuzzie> well
[15:56:33] <fuzzie> i still don't understand what you'd gain
[15:57:06] <tomprince> I guess what I am brainstorming is a way to separate the logic from the knowledge of the chus.
[15:57:50] <tomprince> And, part of me seems to gravitate to overly complex solutions. :)
[15:58:08] <fuzzie> well, i just want to know what is simplified here :)
[15:58:08] <lynxlynxlynx> where's the separation? you still have to know the ids
[15:59:26] <fuzzie> but the LoadSave refactoring is a bit difficult in that sense anyway
[15:59:32] <tomprince> Well, the SetEvents shouldn't be in there. But once you have created it, you can pass the object to some generic function, that contains all the logic.
[15:59:42] <tomprince> And just know the symbolic names.
[15:59:43] <fuzzie> at the moment, the branch just has all the logic and UI code in a mess in both files
[16:00:29] <fuzzie> not that i have a better solution
[16:01:41] <tomprince> I'll admit that there is still too much logic in the GUI* files. But, I think that the LoadSave just has logic bits in it.
[16:01:58] <fuzzie> well, i think you want it all on one side or the other
[16:03:37] <fuzzie> but it seems that at the moment, if someone wants to mod the save screen, it's not going to work
[16:04:23] <fuzzie> because this LoadSave basically hard-codes all the GUI logic and tries to present a blackbox API
[16:04:27] <tomprince> Yes, I agree, that the rest of logic should be move out of the GUI* files. Part of the reason not all of it has, is that the CloseOtherWindow stuff is quite magic, and I haven't figured out how to move that logic out yet, since it depends on calling OpenSaveWindow to close it.
[16:04:35] * tomprince goes for lunch.
[16:04:53] <fuzzie> so i'm wondering if there's a nicer way to slice it up
[16:05:17] <fuzzie> and, well, the CloseOtherWindow stuff is just broken
[16:05:30] <fuzzie> so it's not a problem to just make stub functions which call into an object
[16:05:36] <fuzzie> and then that can be replaced later
[16:08:25] <-- budlust has left IRC (Ping timeout: 264 seconds)
[16:10:47] --> budlust has joined #GemRb
[16:34:38] <tomprince> I am certainly open to better ideas. That branch is more in the way of something to start discussion.
[16:35:58] <fuzzie> it is at the least a good starting point
[16:36:12] <tomprince> One thing to do in the SaveGameList code is to make all the controls optional.
[16:37:04] <tomprince> Other than that, I am not sure how much one could mod the logic. I guess you could skip confirmation, or add a different way of specifying the save game name.
[16:38:13] <fuzzie> well, generally such mods would change the UI too
[16:38:23] <fuzzie> which is why i argued before that splitting the UI/logic is a lost cause
[16:38:34] <fuzzie> but yes, for example, default save game naming
[16:39:05] <fuzzie> something i've hacked in myself for other games
[16:39:49] <fuzzie> but i haven't thought about it seriously. will try to do so.
[16:40:55] <tomprince> I'm curious what you hacked into other games, and would it be worthwhile to add as an extenstion to GemRB?
[16:42:01] <tomprince> Which would be a good test case for how to add hooks, if that is how we want to do it, and would lead to a cleaner design of whatever interface we come up with.
[16:42:11] <fuzzie> automatic naming of savegames in the form 'xyz - <Area Name>'
[16:42:42] <fuzzie> but just an example pulled out of the hat
[16:43:13] <CIA-23> GemRB: 03avenger_teambg * r7b4e9dd238f9 10gemrb/gemrb/core/Makefile.am: fixed makefile (added DisplayMessage)
[16:44:17] <tomprince> re: dict syntax -> that would just be syntax, and would be handled by the metaclass stuff, and shouldn't complicate the user code at all.
[16:44:25] <fuzzie> no
[16:44:36] <fuzzie> i mean, our point is: the syntax is complicated
[16:44:59] <fuzzie> and you were intending the syntax to be in the user code, no?
[16:45:09] <fuzzie> LoadSave certainly qualifies as user code in the current form, anyway
[16:45:14] <tomprince> Yes.
[16:46:02] <fuzzie> putting stuff into metaclass is just API extensions which no end user is going to touch, so that bit is fine
[16:46:34] <tomprince> Certainly, having a mix of syntax is complicated. I wouldn't have thought that a consistent Window['Control'] is complicated.
[16:46:48] <fuzzie> well, i think it is
[16:46:52] <tomprince> :)
[16:47:21] <tomprince> I, obviously, don't have a good intuition about what people think is complicated syntax. ;)
[16:47:29] <fuzzie> well, a mix of syntax is complicated :)
[16:48:21] <fuzzie> and it doesn't seem that you're intending to namespace *all* members vs variables
[16:48:28] <fuzzie> just the ones in certain classes
[16:48:59] <fuzzie> if this was a custom scripting language then it might make more sense
[16:49:09] <tomprince> Well, I was planning to namespace all controls, as members of windows.
[16:50:32] <fuzzie> but why should they be different from variables?
[16:50:44] <fuzzie> i'm just wondering if there's a simplicity gain which i am not understanding
[16:51:55] <fuzzie> but, yes, my view of 'complicated' in the GUIScripts is rather radically different to my view of complicated in C++
[16:52:17] <fuzzie> because in C++ I want *myself* to have an easy time, so i want compact code, everything in the right place, everything abstracted
[16:53:08] <fuzzie> while in the GUIScript, the primary goal is for it to be easily modified, so the more simple+obvious everything is the better, even if it leads to a lot of rather long-winded code
[16:54:00] <tomprince> I think there is a number of things going through my head.
[16:54:02] <fuzzie> since anything that no-one will want to touch might as well be in the core
[16:54:57] <fuzzie> i spent a while arguing a bit over your C++ patches about how they'd be better off being simpler, i know, especially with things like Holder<>, but i think it makes sense for the core to be compact and for the long-term plan just to be for all the moddable bits to be in python
[16:56:54] <tomprince> 1) you can't derive from GWindow for example, which means that the Confirm window classes are more complicated than they should be. Or really, what I mean is that deriving from them felt like it would be the most natural way to define them, but I couldn't.
[16:57:10] <fuzzie> you can't fix the deriving?
[16:57:56] <tomprince> 2) Right now, our G* objects only have methods, but some of things seem like the could naturally be properites, and if that happens, it won't neccesairly be clear what is a control, and was is a property.
[16:58:21] <fuzzie> well, it seems that you're really trying to fix python :)
[16:58:38] <tomprince> Probably can fix deriving, wasn't sure how best to do it.
[17:00:03] <fuzzie> my concern is mostly that the GUI and the logic for the GUI are by nature fairly intertwined, and i think it is not necessarily a good thing to try and seperate the two at all
[17:00:42] <fuzzie> hence the traditional MVC setup
[17:00:57] <tomprince> Well, really the thing I want to split off is the game dependent chu/strref constants.
[17:01:21] <fuzzie> well, i'm not sure that is worth the gain either
[17:01:42] <fuzzie> if only because i think if you do that, it is too tempting to simply make this single blackbox LoadSave.py
[17:02:14] <fuzzie> but it seems to actually work pretty well for load/save
[17:04:20] <fuzzie> i guess the trouble with applying MVC to gemrb is that things like GUISAVE are almost entirely the View logic, so it doesn't help.
[17:06:32] <fuzzie> having trouble reconciling the desire to just pass a dict of chu/strrefs to LoadSave, and the obvious fact that the whole thing ends up *much* more difficult to follow.
[17:09:34] <tomprince> Well, that desire is where my thought of having a WindowFactory, and my idea from before of having a file format for describing chus came from. So that LoadSave just gets the populated object, like it does now, and GUI* just needs to provide the chu/strrefs, and then API code handles the conversion.
[17:10:00] <fuzzie> yes, but it becomes far too abstract
[17:10:18] <fuzzie> i mean, in my opinion
[17:10:51] <fuzzie> at the moment, to edit the UI, you just go right to the python file you want to change, and you change it
[17:11:27] <fuzzie> and with the goal of being moddable in mind, that is what i don't want to lose
[17:12:32] <fuzzie> and LoadSave is a terrible example for trying to design this, because it's almost identical in each game
[17:12:59] <fuzzie> so you *can* just put it in the one file, which is great, because we can just have it in one file!
[17:13:27] <fuzzie> and i would just de-abstract your branch a little, put a dictionary based on gametype at the top for the chu/strrefs, and commit it
[17:15:32] <tomprince> True. Do you have another screen that has some more variation to play around with?
[17:16:29] <fuzzie> well
[17:16:36] <fuzzie> i would hate for this work to get lost
[17:16:59] <fuzzie> hence my more immediate pondering about how it could actually be applied
[17:17:58] <fuzzie> but the map screens are a relatively simple example
[17:18:12] <fuzzie> the statistics screen a far more complex one
[17:25:25] --> Avenger has joined #GemRb
[17:25:25] <fuzzie> the statistics screen being one that gets tweaked by mods, too
[17:25:27] --- ChanServ gives channel operator status to Avenger
[17:25:31] <Avenger> hello
[17:25:37] <fuzzie> hiya
[17:28:17] <fuzzie> the ps:t floating thingie is weirdly buggy about scrolling
[17:29:14] <Avenger> got a segfault in tob, just seen the initial movies, didn't even enter any game
[17:29:36] <fuzzie> odd
[17:29:47] <fuzzie> any idea what you clicked?
[17:29:57] <Avenger> playmovie's releasestream
[17:30:20] <fuzzie> hm
[17:30:28] <fuzzie> did we lose the -pthread from gemrb's link again?
[17:30:44] <Avenger> oops, actually, this seems to be my doing
[17:30:47] <fuzzie> because it is broken, again.
[17:31:42] <Avenger> called subtitle rendering with 0, but it shouldn't go into any font:print
[17:32:28] <fuzzie> oh, i'm using cmake
[17:32:29] <Avenger> oh
[17:32:59] <fuzzie> sorry, unrelated complaining :p
[17:34:30] <fuzzie> looks like DrawMovieSubtitle doesn't work correctly if you pass it a 0
[17:34:36] <Avenger> well, yes
[17:34:42] <Avenger> i did this myself :D
[17:34:45] <fuzzie> since it'll break on the second call
[17:34:48] <CIA-23> GemRB: 03avenger_teambg * r89366f743ebd 10gemrb/gemrb/plugins/SDLVideo/SDLVideo.cpp: fixed a crasher i added recently
[17:35:02] <Avenger> luckily no one noticed, phew :)
[17:35:15] <fuzzie> i want to know why my cmake binaries are broken, i was sure we fixed that
[17:35:28] <fuzzie> but i guess not, and i just went back to autotools
[17:36:04] <Avenger> yeah, i had to fix compilation even with that
[17:36:20] <fuzzie> well, i think no-one is using autotools now
[17:36:27] <fuzzie> so it gets forgotten sometimes
[17:36:29] <Avenger> except me
[17:36:36] <Avenger> :)
[17:36:59] <fuzzie> well, i think i probably will, because cmake is irritating
[17:37:42] <Avenger> i'm just testing gemrb with valgrind a bit
[17:37:52] <fuzzie> but i am still catching up with the last few weeks of commits, after exams
[17:39:27] <Avenger> exams are fine?
[17:39:30] <fuzzie> yes
[17:39:42] <Avenger> meh, gemrb is broken
[17:39:53] <fuzzie> gemrb is giving me Tiax rules tooltips in the iwd2 inventory screen o.O
[17:40:07] <fuzzie> that is pretty funny, i guess
[17:40:46] <fuzzie> problems under valgrind?
[17:40:50] <CIA-23> GemRB: 03tom.prince * r7556b9a170a3 10gemrb/gemrb/plugins/GUIScript/ (PythonHelpers.cpp PythonHelpers.h):
[17:40:50] <CIA-23> GemRB: GUIScript: Factor out common code for calling into python.
[17:40:50] <CIA-23> GemRB: This handles passing arguments and interpreting return values/errors.
[17:40:50] <CIA-23> GemRB: Signed-off-by: Tom Prince <firstname.lastname@example.org>
[17:40:53] <CIA-23> GemRB: 03tom.prince * re14056d2ba7a 10gemrb/gemrb/ (4 files in 2 dirs):
[17:40:53] <CIA-23> GemRB: GUIScript: Add ability to call callbacks with an int parameter.
[17:40:53] <CIA-23> GemRB: Signed-off-by: Tom Prince <email@example.com>
[17:41:09] <Avenger> no, guiscript
[17:41:18] <Avenger> i found a small leak too, but guiscript is broken
[17:41:22] <fuzzie> howso?
[17:41:30] <fuzzie> i tested it quite a lot today
[17:41:42] <fuzzie> well, with bg2 and iwd2 and pst only
[17:42:06] <Avenger> ImportError: cannot import name GetStatOverview
[17:42:15] <fuzzie> oh
[17:42:29] <Avenger> File "./GUIScripts/bg2/LevelUp.py", line 26, in <module>
[17:42:31] <Avenger> from GUIREC import GetStatOverview, UpdateRecordsWindow, GetActorClassTitle, GSNN
[17:42:32] <fuzzie> i guess first thing to say is: you deleted *.pyc in all the directories?
[17:42:34] <Avenger> why do i get this and you don't?
[17:42:42] <fuzzie> because bg2/LevelUp.py should not exist
[17:42:49] <fuzzie> i really hate python doing that
[17:42:52] <Avenger> doh
[17:42:55] <fuzzie> can we stop python from doing that?
[17:42:57] <Avenger> i thought a make will remove them!
[17:43:07] <fuzzie> that would also be a good idea
[17:43:09] <Avenger> make install should remove all pyc
[17:43:14] <fuzzie> but if we could just not have them in the first place..
[17:44:09] <Avenger> good you has such a sharp mind :D or you just got burned by this recently?
[17:44:18] <Avenger> eep, still buggy...
[17:44:24] <lynxlynxlynx> everybody gets burnt by this sometime
[17:44:47] <lynxlynxlynx> rm gemrb/GUIScripts/*pyc gemrb/GUIScripts/*/*pyc
[17:44:48] <fuzzie> i got burnt by the exact same thing
[17:45:01] <tomprince> there is sys.dont_write_bytecode in 2.6
[17:45:08] <Avenger> ok, it wasn't pyc files, but py files
[17:45:47] <lynxlynxlynx> odd
[17:46:03] <fuzzie> tomprince: gdb doesn't work on my gemrb binaries again, because the main binary isn't getting libpthread i guess
[17:46:18] <fuzzie> tomprince: any pointers?
[17:46:36] <Avenger> ok, it now works
[17:46:41] <tomprince> What I do is LD_PRELOAD=/lib/libpthread.so.0 gdb --args gemrb -c ~/.gemrb/bg2-real.cfg
[17:47:05] <fuzzie> cmake is not so friendly if i have to add hacks everywhere :(
[17:47:10] <Avenger> [GUIScript]: Missing function:EmptyControls
[17:47:16] <Avenger> this is new, i think
[17:47:30] <fuzzie> yes, that is my fault
[17:47:44] <fuzzie> we sabotaged the keybindings in the C++ core, and i didn't finish the python version in ti me
[17:48:34] <fuzzie> although that one in particular should be fixed in the core, i guess
[17:48:45] <Avenger> ok, so now shortcuts won't work?
[17:49:39] <Avenger> they worked so-so before, like 'm' and 'j' brought up map and journal
[17:49:54] <Avenger> ahh, i see, this is guiscript stuff
[17:50:04] <fuzzie> well, they'll get replaced in the next few days, so no-one fixed the core to call the right functions
[17:50:08] <Avenger> i need to use the runfunction with 2 params? as per new syntax?
[17:50:17] <CIA-23> GemRB: 03lynxlupodian * rab8143c02c8f 10gemrb/gemrb/core/GameControl.cpp: enable the shorcut for EmptyControls
[17:50:19] <lynxlynxlynx> there you go
[17:50:28] <fuzzie> the pgup/pgdn ones in the same place are maybe also the same problem
[17:50:37] <fuzzie> there's no bindings in the keymap.ini files for them
[17:50:45] <lynxlynxlynx> oh
[17:51:09] <lynxlynxlynx> won't this be a problem? i hear some keyboards don't have these keys
[17:51:11] <fuzzie> we could ship our own default bindings, but maybe best to fix them in GameControl for now
[17:51:13] <Avenger> oops this Callback is a new file?
[17:51:19] <fuzzie> yes
[17:51:25] <Avenger> then Makefile needs it too
[17:51:27] <fuzzie> but i thought that was in makefile
[17:51:44] <Avenger> oh wait it is in
[17:51:54] <Avenger> then it is not so new :)
[17:52:03] <Avenger> i'm just unfamiliar with some changes
[17:52:16] <fuzzie> the Callback is some generic class
[17:52:23] <fuzzie> so you can pass python functions as event handlers
[17:52:35] <fuzzie> that is the only important thing to know, i think
[17:53:22] <Avenger> i hope this new stuff will not break stuff, or even fix some
[17:53:30] <fuzzie> it just fixed stuff so far
[17:53:38] <Avenger> windows callbacks are now safer?
[17:53:50] <Avenger> like closing a window from one
[17:53:51] <fuzzie> lynx has been merging a lot of duplicate code with it
[17:54:09] <Avenger> you tried to open containers?
[17:54:12] <Avenger> or dialog?
[17:54:16] <lynxlynxlynx> cleaning namespaces
[17:54:17] <fuzzie> hehe
[17:54:19] <Avenger> those were always a bit tricky
[17:54:19] <fuzzie> yes, i played for a while
[17:54:30] <fuzzie> lynx's first attempt broke TextScreen though :)
[17:54:45] <lynxlynxlynx> oh, did i fix that?
[17:54:48] <fuzzie> yes
[17:54:53] <lynxlynxlynx> ok :)
[17:54:55] <Avenger> yeah, that would have been another of my questions, but i already bugged you about the merged textscreen :D
[17:55:02] <fuzzie> although i didn't test, actually, let me test
[17:55:39] <tomprince> And we have been discussing how best to merge all the load/save screens.
[17:55:58] <Avenger> meh, my movie crasher surely made it into 0.6.1?
[17:56:23] <fuzzie> ok, yes, textscreen seems fine
[17:56:30] <Avenger> OpenJournalWindow still not called
[17:56:53] <fuzzie> yes, anything which should come from keymap.ini is broken
[17:57:46] <Avenger> but why? it detects it should call it, it just fails to call with ->RunFunction("OpenJournalWindow");
[17:58:06] <fuzzie> just because no-one bothered to fix it, because it is to be replaced :)
[17:58:15] <lynxlynxlynx> the function is not in the current module
[17:58:17] <tomprince> OpenJournalWindow is no longer in the namespace of the main script file.
[17:58:25] --> cubathy has joined #GemRb
[17:58:44] <Avenger> so, the script is not given because the whole stuff will be changed soon?
[17:58:49] <fuzzie> yes
[17:58:54] <fuzzie> but you can put it in there if you want
[17:58:57] <fuzzie> it is no harm
[17:59:17] <tomprince> The next release seems to be the python cleanup release. :)
[17:59:27] <fuzzie> it would be nice if it were the bugfix release :(
[17:59:45] <fuzzie> everyone here seems to have gone to watch football, i guess the Dutch are playing someone
[17:59:46] <Avenger> i liked it better when the whole stuff was a single namespace
[18:00:00] <Avenger> this makes a lot of hardcodedness in the core
[18:00:18] <fuzzie> well, all of this keybinding stuff will be removed
[18:00:24] <tomprince> There are plan afoot to change that.
[18:00:36] <fuzzie> otherwise, i think we still argue over how to change it
[18:00:43] <tomprince> The hard codedness.
[18:00:47] <fuzzie> a seperate namespace, maybe
[18:01:01] <fuzzie> or tomprince has some crazy plan with decorator magic
[18:01:05] <tomprince> The problem with a single namespace, is that you have issues with what order modules get loaded.
[18:01:39] <fuzzie> but i spend half my day arguing that the python side must be as simple as possible, because i want modding to be easy
[18:01:50] <fuzzie> so that is my mantra!
[18:02:37] <fuzzie> ok, let me look at how i can make keybindings do this latest design
[18:02:47] <Avenger> i can accept that 'some' python files are semi-untouchable
[18:02:56] <Avenger> if the rest is easy to mod
[18:03:01] <fuzzie> yes
[18:03:08] <tomprince> That is the plan.
[18:03:39] <fuzzie> wjp's MetaClasses.py is beyond most people, i am sure, but no modder ever needs to look at it :)
[18:06:29] <tomprince> We are just debating what exactly easy means, and how to balance that against well factored code.
[18:07:18] <fuzzie> so does it make more sense to pass keymap identifiers to python and let it maintain the dict of functions?
[18:07:37] <Avenger> well, i guess, the hotkeys will need some 2da now
[18:07:48] <fuzzie> that is my current plan
[18:08:09] <Avenger> so a row would look like this: MAP / GUIMA / OpenMapWindow
[18:08:10] <tomprince> Well, it is probably 6/half dozen. Does python need to know the keybindings?
[18:08:18] <fuzzie> no
[18:08:26] <fuzzie> well, yes, but not in general, only when editing the keybindings
[18:08:40] <Avenger> guicontrol needs to know them mostly
[18:08:47] <Avenger> though i think fuzzie wants it more generic
[18:09:02] <fuzzie> so i figured we could just have a python function, and call it like HandleKeyBinding("Mage Spells")
[18:09:16] <tomprince> Well, if it needs to know the keybindings, then it is probably best to keep it on the python side.
[18:09:19] <fuzzie> and then that can be wrapped in a python API, which could handle the 2da
[18:09:39] <Avenger> well if you handle them in python then python needs to know them?
[18:10:16] <fuzzie> the core needs to know the key->identifier mappings for tooltips
[18:10:18] <Avenger> hmm, i guess i see, the key -> function map would be done in core
[18:10:51] <tomprince> Or the code that sets the tooltip on the python side can do the lookup.
[18:10:54] <Avenger> ok, then it doesn't really need a 2da, it could be python spaghetti code
[18:10:55] <fuzzie> the difficult part here is the design, it's very simple to code
[18:11:06] <fuzzie> tomprince: but we can't do that yet
[18:11:07] <Avenger> just a lot of dispatching stuff
[18:11:24] <fuzzie> and i'm not sure passing every single keystroke to python is a wonderful idea
[18:11:42] <fuzzie> but there are arguments for every different way, i think
[18:12:15] <Avenger> i agree, passing every keystroke would suck
[18:12:16] <fuzzie> i just try and find a compromise which is simplest while not causing any problems, since allowing python to get the underlying key would be a single api call
[18:12:32] <Avenger> only gui function requests need to leave the core
[18:12:36] <fuzzie> last time i tried this, no-one could agree :)
[18:13:21] <tomprince> If you are concerned about calling into python to much, sure put it C++. :)
[18:13:45] <fuzzie> well, i think we are crazily obsessed about calling into python too much, considering how awful SDL is
[18:13:46] <tomprince> But, we can also always move it if it becomes a bottleneck.
[18:13:59] <tomprince> On the otherhand, there are lots of games written in pure python.
[18:14:02] <fuzzie> i am mostly concerned about simple code
[18:14:14] <fuzzie> are there any *good* games written in pure python? :)
[18:14:49] <tomprince> I don't know.
[18:15:44] <fuzzie> but i do not seriously think it would be a performance problem.
[18:15:51] <tomprince> And, as you say SDL is the bottleneck. And anything that is in python can be migrated to C++ if it becomes a bottleneck, without changing the user exposed interface much or at all.
[18:16:09] <fuzzie> well, i think migrating this from C++ to python should be the same
[18:16:24] <tomprince> True.
[18:16:29] <fuzzie> we'd want to wrap the tooltip stuff anyway
[18:16:33] <fuzzie> i am not convinced either way
[18:16:53] <fuzzie> i just know that i can't do the python thing without a bunch of other annoying changes :)
[18:17:03] <fuzzie> oh hey
[18:17:13] <fuzzie> Avenger: what do you need from sound handles?
[18:17:24] <fuzzie> just looping and position movement for projectiles?
[18:17:36] <fuzzie> we were looking into it the other day, but i wasn't sure what was required
[18:17:48] <fuzzie> i did notice that the post on the forum decoded another looping sound flag for projectiles
[18:18:31] <Avenger> and destroying them
[18:18:45] <CIA-23> GemRB: 03avenger_teambg * r580e2159595e 10gemrb/gemrb/core/GameControl.cpp: re-enabled some hotkeys
[18:18:46] <CIA-23> GemRB: 03avenger_teambg * r4383ca6a4520 10gemrb/gemrb/core/GameControl.cpp: fixed pgup/down too
[18:18:58] <fuzzie> destroying them stops the sound immediately, or only looping sounds?
[18:20:07] <Avenger> well, i guess it is a problem only with looping sounds which don't have a pre determined end
[18:20:23] <tomprince> fuzzie: ping me if you need any python <-> C++ interface stuff for keybindings.
[18:20:55] <Avenger> i don't think any non-looping sounds do end abruptly
[18:21:21] <Avenger> actually, i guess even looping sounds will only stop the looping, and end normally
[18:21:45] <Avenger> so if i can delete the loop flag, it might be fine
[18:22:53] <tomprince> That is a fairly simple set of specs.
[18:23:10] <fuzzie> well, that is why i was hoping we could just make it work :)
[18:23:32] <lynxlynxlynx> Avenger: OnDecreaseSize is from CommonWindow, not GUICommonWindows
[18:23:36] <fuzzie> but having to keep track of actual handles is a bit painful
[18:23:45] <Avenger> yes lynx, the second commit should fix that?
[18:23:59] <fuzzie> so i thought, tomprince probably has a better idea.
[18:24:22] <lynxlynxlynx> oh :)
[18:24:54] <fuzzie> tomprince: poking at my old patch for this, i want to do key->keymap and keymap->key lookups, i don't suppose you know of a better method than just two maps wrapped in a class?
[18:25:08] <-- cubathy has left IRC (Remote host closed the connection)
[18:25:17] <tomprince> So, a SoundSource object, and Audio::CreateSoundSource. with SoundSource:SetPos and SoundSource::Stop?
[18:25:23] <fuzzie> ok, maybe i shouldn't distract you
[18:25:54] <fuzzie> Audio probably needs to keep track of the SoundSource objects so that it can sabotage anything which ended, probably, since SetPos should probably still work even if it's not looping
[18:25:54] <lynxlynxlynx> SoundSource::Stop vs SoundSource::DisableLooping
[18:26:03] <fuzzie> and you can have both! :-)
[18:26:38] <Avenger> i honestly don't know how they implemented looping projectile sounds in the original
[18:27:19] <fuzzie> but that API would be fine as a starting point?
[18:27:24] <Avenger> yes
[18:27:59] <Avenger> setpos should work without looping, yes
[18:28:22] <Avenger> but that's easy, you can always modify the sourcepos in openal
[18:28:42] <Avenger> keeping track of the handle is the problem, i guess
[18:28:56] <fuzzie> well, the tricky bit is that you don't want to keep the openal handles for longer than necessary
[18:29:19] <fuzzie> but you can just keep track of the SoundSource objects in openal, and disable them when the sound is done
[18:29:22] <tomprince> fuzzie: re dicts: I don't see anything obvious.
[18:29:44] <fuzzie> drat :)
[18:29:48] <Avenger> yes, we shouldn't dry out the resources. But, even if the sound is not heard, the handle should be nonzero, in case it gets playable later?
[18:30:41] <Avenger> imagine: there is a big battle with lots of sounds coming and going, but you got a permanent prot from magic globe which hums ominously, after battle that looping sound should be enabled
[18:30:49] <fuzzie> yep
[18:30:56] <fuzzie> so for looping, you always want to create them :)
[18:31:08] <Avenger> hmm
[18:31:11] <fuzzie> i will think about it later if tomprince doesn't
[18:31:32] <Avenger> i would hope if i don't have to create them :)
[18:31:49] <Avenger> i mean, if you got that SoundSource, it could handle that itself
[18:31:51] <fuzzie> yep
[18:31:57] <fuzzie> secret internal magic!
[18:32:30] <Avenger> its a pity openal won't handle this itself
[18:32:43] <Avenger> it shouldn't get choked on lack of resources
[18:33:11] <tomprince> Avenger: If you know how the code projectile side of the code should work, you could create a class that has the interface you want, and use that, and then someone could come and figure out how to make it work with openal.
[18:33:41] <fuzzie> the openal specification leaves too much up to implementations
[18:33:59] <tomprince> I probably won't get a chance to look at it until next week at the earliest.
[18:34:22] <fuzzie> well, i have a lot of time marked "get some sleep"
[18:34:52] <fuzzie> so maybe i'll put a branch up somewhere
[18:34:53] <tomprince> :) And I am going home for the summer on sat, and will no longer have my desktop to work at.
[18:35:26] <Avenger> stuff like core->GetAudioDrv()->Play(SoundRes1, Pos.x, Pos.y, 0); should return a handle, which i could use later with core->GetAudioDrv()->Change(handle, Pos.x, Pos.y, flags) or like that? flags could change the looping, or end the sound.
[18:36:08] <tomprince> No, you would have core->GetAudioDrv()->CreateSoundHandle(....)
[18:36:12] <fuzzie> well, if the handle is an object, we can call on that :)
[18:36:19] <fuzzie> but i think the api requirement is clear
[18:36:33] <tomprince> then handle->SetPos(...), handle->SetFlags(...)
[18:36:37] <Avenger> handle could be an object, no problem with that
[18:37:00] <fuzzie> i'm not sure how to handle the projectile side, but i guess someone can guess
[18:37:06] <fuzzie> do you know if that second looping flag is used anywhere?
[18:37:10] <fuzzie> if so, maybe add it to the .h file
[18:37:11] <Avenger> i just thought it is safer if it is a handle
[18:37:23] <Avenger> because i didn't want to free it myself :)
[18:37:30] <tomprince> Do you want all sounds to have a handle, or most going to be fire and forget?
[18:37:37] <fuzzie> i think most will be fire and forget
[18:37:41] <fuzzie> so a seperate function is fine
[18:37:43] <Avenger> most will be fire and forget
[18:37:48] <tomprince> That is what Holder<> is for.
[18:38:00] <fuzzie> well, there are a *lot* of sounds sometimes
[18:38:12] <lynxlynxlynx> especially on load ;)
[18:38:12] <fuzzie> doing useless memory allocations for each one seems a bit silly
[18:38:28] <fuzzie> i was hoping we could just get away with a non-pointer object, but then we can't keep a reference to it
[18:38:29] <Avenger> especially as a lot of them won't have a chance to be heard
[18:38:32] <fuzzie> annoying
[18:39:54] <tomprince> Won't we need to do some kind of allocation to keep the information for the soudn anyway?
[18:40:15] <Avenger> it is fine if not all of these get actually played, but they all need to be safe to call into (that's why i preferred the handle), and it is a nice to have, if they notice they can be heard when other sounds are gone
[18:40:53] <fuzzie> tomprince: if we know the sound is out-of-range and we're not returning a handle, there's no need to bother with doing anything
[18:41:28] <fuzzie> you could do this with some 'yes, i really want a handle' parameter though, if you think that is cleaner
[18:41:49] <tomprince> Well, that was why I was thinking of a separate function.
[18:41:54] <fuzzie> sure, that sounds great
[18:42:11] <tomprince> And in that case, don't we need to do some kind of allocation anyway?
[18:42:15] <fuzzie> sure!
[18:42:16] <fuzzie> sorry
[18:42:24] <fuzzie> i thought you were arguing for all sounds having a handle, that's all
[18:42:28] <tomprince> No.
[18:42:49] <Avenger> not looping sounds are not really a loss if they don't get a handle
[18:43:04] <fuzzie> obviously a Holder would be ideal here
[18:43:04] <tomprince> I was just commenting on Avengers original suggesting of using ->Play, and wondering if most cases would want a handle.
[18:43:11] <tomprince> Which they don't.
[18:44:19] <Avenger> well, we need a handle for : looping sounds that needs to stop sometime. And ... well, i guess all non looping sounds are stationary too.
[18:44:43] <Avenger> i guess only looping sounds move with the projectile too
[18:44:50] <fuzzie> i think there are some long-playing projectile sounds which move with the projectile
[18:44:53] <Avenger> those that need position change
[18:44:54] <fuzzie> i forget where, maybe in iwd?
[18:45:04] <Avenger> long playing without looping?
[18:45:22] <fuzzie> lasting several seconds
[18:45:32] <Avenger> and they are moving or stationary?
[18:45:36] <fuzzie> moving :)
[18:45:42] <Avenger> hmm, well
[18:45:43] <fuzzie> i'm not sure how i'd work out whichone
[18:45:51] <fuzzie> but it is easy enough to allow it in the API and worry later
[18:45:59] <Avenger> yep
[18:46:08] <Avenger> if some projectile is noticeably different
[18:46:44] <Avenger> other sound sources are not really using this feature
[18:47:05] <Avenger> because they are tied to a spot, or they are replayed next time with a different position
[18:47:10] <fuzzie> there are no actions which allow weird sound stuff?
[18:47:22] --> cubathy has joined #GemRb
[18:47:27] <Avenger> no, they are simple playsounds at a position
[18:47:44] <fuzzie> and player speech never follows players?
[18:47:53] <Avenger> vvcs don't really move either
[18:47:58] <fuzzie> i can't think of any situation where a player can speak and move
[18:48:07] <Avenger> the only mobile sound source is the projectile
[18:48:08] <fuzzie> oh, i guess the first bg1 cutscene has that
[18:48:21] <Avenger> hmm, hmm
[18:48:23] <Avenger> true
[18:48:34] <fuzzie> someone will have to check it, sometime
[18:48:38] <Avenger> i don't know if they are positional sounds
[18:48:50] <Avenger> they could be global sounds without position too
[18:49:02] <tomprince> http://pastie.org/1017624
[18:49:53] <Avenger> yes, that seems to be all we need
[18:50:07] <tomprince> Do we want a SetGlobal as well?
[18:50:19] <Avenger> it will never change
[18:50:31] <Avenger> the setglobal stuff is in the flags, though
[18:50:46] <Avenger> there is also a speech/not speech bit in the flags
[18:51:02] <Avenger> so, maybe you want to handle those flags somehow
[18:51:16] <Avenger> that is the 3rd parameter in Play
[18:51:25] <fuzzie> needs more =0 :p
[18:52:14] <tomprince> Well, the AudioDriver will create the soundsource with the flags passed to it. The interface here only needs those things that might change.
[18:52:57] <Avenger> it would be good if those flags keep the looping flag, at least when passed by Play
[18:53:27] <Avenger> so Play is the only thing one needs when creating them
[18:53:51] <Avenger> ok, maybe a 4th parameter
[18:54:20] <Avenger> i don't know, i guess having a 4th is better than always preparing and parsing the bitfields
[18:55:17] <Avenger> that's what you meant fuzzie, when you said needs more?
[18:56:06] <lynxlynxlynx> fuzzie: do you remember what everything needs to be cured on death? I know poison for sure and thinking also of disease, hold, stun, panic, confusion and sleep
[18:56:36] <fuzzie> it's all commented in avenger's death opcode comments i think, for bg2
[18:56:42] <fuzzie> bit busyright now
[18:56:53] <Avenger> lynx: some of those are handled by the effect when it detects the target is dead
[18:57:00] <tomprince> fuzzie: One issue with creating typedefs for all the holder stuff, is that means that we have more header dependencies. Not a big deal though.
[18:57:10] <lynxlynxlynx> Avenger: can you send me that list or just the whole thing?
[18:57:30] <lynxlynxlynx> i'll check them individually
[18:57:42] <Avenger> hmm, not really, i don't have a prepared list
[18:58:05] <Avenger> i just know, for example, blur and mirror image checks this in their opcode
[18:58:31] <Avenger> but other stuff is removed by the death opcode
[18:58:36] <fuzzie> the visual effects seemed to mostly check in their opcodes
[18:58:41] <Avenger> yes
[18:59:08] <Avenger> ok, i can look into the death opcode, and see what is handled there
[19:00:25] <Avenger> it starts by checking the stance setting the death stance only if the guy is not already horizontal
[19:00:51] <Avenger> that could be 2-3 different stances
[19:01:27] <Avenger> then does the verbal constant for dying
[19:01:40] <tomprince> http://repo.or.cz/w/gemrb.git/commitdiff/61fba10199b70a718b472533770b2fe9c3b61932
[19:01:47] <Avenger> removes the hold effect
[19:02:01] <tomprince> Although the flags should perhaps be something different: enums or something.
[19:02:22] <lynxlynxlynx> no minhp check?
[19:02:26] <Avenger> removes the holdcreature effect
[19:04:04] <fuzzie> the death opcode just kills outright, i think
[19:04:26] <Avenger> yep, it seems so
[19:04:53] <tomprince> fuzzie: How to handle filenaming vs typedefs?
[19:05:26] <Avenger> actually, only the minhp opcode handles the minhp stat directly, so this could be hidden somewhere else
[19:06:06] <fuzzie> tomprince: in this case, it seems like it'd be obscure enough to forget the typedef, if you'd prefer
[19:06:18] <lynxlynxlynx> ok, but back to the effects - anything more?
[19:07:35] <tomprince> If we are going to typedef the Holder<> then we should typedef the Holder<>, i think. And, regardless if we do it here, it is an issue we need to deal with. Unless we do something like *_t for the class, and then * for the typedef or some such thing.
[19:08:25] <fuzzie> that sounds pretty terrible :)
[19:08:32] <fuzzie> but i don't have thoughts in the long-term right now
[19:08:34] <Avenger> yes, HoldCreatureSpell2
[19:08:43] <Avenger> maybe better if i list the opcode numbers
[19:08:53] <lynxlynxlynx> yeah
[19:08:56] <Avenger> 6d, af, b9
[19:09:04] <Avenger> 2d
[19:09:08] <lynxlynxlynx> no need for hold though, since we deal with all of them in the same effect
[19:09:16] <tomprince> Something to ponder.
[19:09:31] <Avenger> 8e / 0d (hold icon)
[19:09:48] <Avenger> 8e is portrait icon, 0d is the hold icon index
[19:10:05] <Avenger> 8e / 37 (stunned icon)
[19:10:26] <Avenger> that's all in bg2
[19:10:34] <Avenger> could be different in other games
[19:10:47] <Avenger> i think it removes these so the guy can actually fall
[19:11:01] <Avenger> otherwise the hold opcodes would disable the stance change
[19:11:33] <Avenger> so, as a rule of thumb, i would remove all opcodes that disable stance change
[19:12:02] <lynxlynxlynx> not so simple -> petrification
[19:12:14] <Avenger> that is not removed yes
[19:12:20] <Avenger> nor freeze
[19:14:06] <Avenger> nor the casterhold effect, but i consider that a bug
[19:15:22] <Avenger> they use that effect for color spray and scorcher where the caster is moveless due to the casting, so when he is dead (or the spell is canceled) he should be able to move
[19:17:36] <lynxlynxlynx> heh
[19:18:01] <lynxlynxlynx> the portrait icon removal should also be done in the cure effects?
[19:18:16] <lynxlynxlynx> it's a bit odd that they do it separately
[19:20:28] <lynxlynxlynx> i guess they removed the effects directly
[19:20:45] <lynxlynxlynx> but that would be different from other parts
[19:21:29] <Avenger> yes, i think it is weird
[19:21:45] <Avenger> i think the cure effects don't do that, but i can check
[19:22:24] <tomprince> Does this look good to go in? http://repo.or.cz/w/gemrb.git/commitdiff/050314f47136327a251d931cd2b6c17d0281c52c
[19:22:53] <tomprince> The flags probably want to be changed, once something is actually implemented.
[19:23:21] <fuzzie> if it really doesn't do anything yet, i would push to a branch
[19:23:42] <Avenger> unstun removes the 2d and the 6d effects
[19:23:43] <tomprince> or.cz/soundsource
[19:26:07] <Avenger> the 0xa2 effect (removehold?) removes some portrait icons
[19:26:39] <Avenger> it removes 6d, af and 8e/0d opcodes
[19:27:40] <lynxlynxlynx> ok, i'll do that and skip the 8e in the dying
[19:27:42] <Avenger> so death is the union of unstun and removehold, but 0x6d is removed by everything. And unstun doesn't remove the stun portrait icon :)
[19:28:17] <Avenger> and bear in mind, this is only bg2
[19:28:32] <Avenger> the relations are different in iwd1/2
[19:30:48] <fuzzie> lynxlynxlynx: you're thinking of trying to hack this into the current gemrb code? wherE?
[19:31:44] <fuzzie> oh, right, we have the CheckOnDeath hack
[19:31:55] <lynxlynxlynx> first i'll add the portrait icon removal to fx_cure_hold_state
[19:32:43] <lynxlynxlynx> not sure iftarget->fxqueue.RemoveAllEffectsWithParam(fx_display_portrait_icon_ref, PI_HELD); is enough, so i added also target->DisablePortraitIcon(PI_HELD);
[19:33:10] <lynxlynxlynx> the rest is in Actor::Die
[19:35:57] <Avenger> the second is not needed
[19:37:23] <lynxlynxlynx> it's always done in the spell with a separate effect?
[19:38:11] <lynxlynxlynx> fx_hold_creature adds the icon manually
[19:38:38] <lynxlynxlynx> but that is taken care by the cure, i guess
[19:43:51] <Avenger> when the portrait icon effect is removed it will not renew the portrait icon anymore. DisablePortraitIcon is needed for immunities
[19:44:08] <Avenger> each ai cycle 'wipes' the portrait icons
[19:44:23] <Avenger> so they need to be actively renewed by the effect
[19:44:57] <lynxlynxlynx> ah ok
[19:46:12] <fuzzie> i think fiddling with effects in Actor::Die leads to crashes
[19:46:35] <fuzzie> i had to remove some stuff at some point due to this, but maybe it's fixed in the meantime
[19:46:52] <fuzzie> although it is technically not necessary
[19:47:13] <Avenger> better don't do that :)
[19:47:35] <Avenger> removing effects directly always leads to crashes, flagging them as to be removed is the way to go
[19:49:35] <fuzzie> oh, right, i was dropping all items there
[19:49:57] <fuzzie> i remember we fixed some inventory stuff since then
[19:52:46] <lynxlynxlynx> i've wiped the main iwd tomb without problems now
[19:54:47] <fuzzie> :)
[19:55:03] <fuzzie> i forget what the main iwd tomb involves
[19:55:08] <lynxlynxlynx> ok commit? it looks pretty boring with the repeating createeffect and applyeffect calls, but it couldn't be in a loop, since 2/5 require special params
[19:55:21] <lynxlynxlynx> plenty of undead :)
[19:57:55] <fuzzie> ok, then i am confused about what you are working on, but don't mind me
[19:58:06] <fuzzie> i got a bit stolen to work on something else
[20:01:32] <-- tomprince has left #GemRb
[20:04:32] <-- budlust has left IRC (Ping timeout: 265 seconds)
[20:04:52] <lynxlynxlynx> http://pastebin.com/JzBWNP1h <-- this
[20:04:59] --> Maighstir_laptop has joined #GemRb
[20:05:36] <lynxlynxlynx> is there some cleaner way?
[20:11:30] <fuzzie> can't you just call RemoveAllEffects?
[20:11:42] <fuzzie> the cure is required?
[20:12:29] --> budlust has joined #GemRb
[20:14:21] <fuzzie> seems that RemoveAllEffects should be sufficient
[20:14:31] <fuzzie> (or the Resource variant for the icon, I guess)
[20:14:42] <fuzzie> but i'm not entirely sure what it's doing so :)
[20:18:13] <lynxlynxlynx> that doesn't make much difference
[20:19:02] <-- budlust has left IRC (Ping timeout: 265 seconds)
[20:19:33] --> budlust has joined #GemRb
[20:20:07] <lynxlynxlynx> oh, you meant it for everything, not just the icon
[20:20:49] <lynxlynxlynx> i'm not sure that would be sufficient
[20:20:56] <fuzzie> well, calling ApplyEffect inside an effect is undefined behaviour, i think
[20:21:12] <fuzzie> although i guess you shouldn't hit anything problematic with this
[20:21:17] <lynxlynxlynx> base state bits are modified
[20:21:59] <lynxlynxlynx> is there a better place for this?
[20:22:12] <fuzzie> CheckOnDeath is where we have been dumping this stuff
[20:22:32] <fuzzie> but the only place it'll work is inside the Death opcode
[20:22:37] <fuzzie> so it might as well be fixed now
[20:22:50] <fuzzie> Avenger: is adding cure effects the only way to make this work in gemrb?
[20:23:03] <lynxlynxlynx> but fx_damage currently calls die, not invoking the death effect
[20:23:41] <fuzzie> that is a bug
[20:24:00] <fuzzie> but fixing it doesn't gain us anything until effects are applied via messaging, i think
[20:25:40] <lynxlynxlynx> bleh
[20:25:45] <lynxlynxlynx> i'll just stash it then
[20:25:48] <fuzzie> no, no
[20:25:49] <lynxlynxlynx> need to go
[20:25:57] <fuzzie> i mean, keep it around
[20:26:08] <lynxlynxlynx> in die?
[20:26:10] <fuzzie> sure
[20:26:49] <CIA-23> GemRB: 03lynxlupodian * re43f62e23c0d 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: fx_cure_hold_state also removes the portrait icon
[20:26:51] <CIA-23> GemRB: 03lynxlupodian * rd8db9ac71220 10gemrb/gemrb/core/Actor.cpp: remove poison, hold, casterhold, stun and its icon on death
[20:27:15] <-- budlust has left IRC (Ping timeout: 265 seconds)
[20:34:32] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[20:34:38] --> budlust has joined #GemRb
[20:36:04] <fuzzie> i still don't understand how the cure stuff works at all, if these effects set base state bits then i don't see how they'd ever clean up after themselves if they just expired
[20:37:40] <fuzzie> oh, Cure:Hold and Cure:Poison do BASE_STATE_CURE while Hold/Poison do STATE_SET. confused!
[20:37:41] <Avenger> base state is rarely set
[20:38:24] <Avenger> it is set only for effects that go away but their result is saved
[20:39:02] <Avenger> cure:Hold fixes the base state, and removes the hold effect
[20:39:18] <Avenger> that is effectively fixing the normal state after the next ai cycle
[20:39:19] <fuzzie> oh, Cure:Stun, not Cure:Hold
[20:39:54] <Avenger> if you fix the base state and remove the stun effect, you fixed it completely
[20:41:21] <fuzzie> so which is best, to do that, or to do what lynx did and do ApplyEffect with the cures?
[20:42:03] <Avenger> i don't see what are the options
[20:42:40] <fuzzie> lynx's latest commit does CreateEffect and ApplyEffect for every cure effect needed, in Die()
[20:42:51] <Avenger> uh
[20:43:31] <fuzzie> i thought, surely we can just call RemoveAllEffects and it will work out fine
[20:43:52] <Avenger> why not simply copy their code
[20:43:55] <Avenger> yes
[20:44:05] <Avenger> that's how the original does this
[20:44:10] <-- budlust has left IRC (Ping timeout: 265 seconds)
[20:44:37] <Avenger> this is a bit slower and could be redundant
[20:44:46] --> budlust has joined #GemRb
[20:58:21] <-- budlust has left IRC (Quit: Konversation terminated!)
[20:58:43] --> budlust has joined #GemRb
[21:03:05] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[21:06:51] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[21:11:45] <-- Avenger has left IRC (Quit: bye!)
[21:18:27] <-- budlust has left IRC (Ping timeout: 265 seconds)
[21:18:27] --> cubathy has joined #GemRb
[21:21:18] --> budlust has joined #GemRb
[21:23:07] <-- pupnik has left IRC (Quit: Lost terminal)
[21:31:03] <-- budlust has left IRC (Ping timeout: 265 seconds)
[21:44:11] --> Maighstir_laptop has joined #GemRb
[22:00:27] --> budlust has joined #GemRb
[22:06:41] <-- budlust has left IRC (Ping timeout: 260 seconds)
[22:21:59] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[22:56:46] --> tomprince_loki has joined #GemRb
[23:05:46] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[23:57:14] --> tomprince_loki has joined #GemRb