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

Archive Today Yesterday Tomorrow
GemRB homepage

[00:03:12] --> budlust has joined #GemRb
[01:00:58] <-- budlust has left IRC (Ping timeout: 260 seconds)
[01:03:32] --> budlust has joined #GemRb
[02:28:26] --> tomprince has joined #GemRb
[03:37:45] <-- budlust has left IRC (Quit: Konversation terminated!)
[03:38:02] --> budlust has joined #GemRb
[04:32:10] --> tomprince_loki has joined #GemRb
[04:47:33] <-- budlust has left IRC (Quit: Konversation terminated!)
[04:47:50] --> budlust has joined #GemRb
[05:02:53] <-- tomprince_loki has left IRC (Ping timeout: 240 seconds)
[05:49:09] --> Gekz has joined #GemRb
[05:54:32] <-- Gekz has left IRC (Changing host)
[05:54:32] --> Gekz has joined #GemRb
[05:57:24] <-- pupnik has left IRC (Quit: Lost terminal)
[06:02:33] <CIA-23> GemRB: 03tom.prince * r2b6ccc359f32 10gemrb/gemrb/docs/en/CMakeLists.txt:
[06:02:33] <CIA-23> GemRB: doc: Don't install doxygen stuff.
[06:02:33] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[06:20:17] <CIA-23> GemRB: 03tom.prince * r9a370eca0995 10gemrb/gemrb/GUIScripts/bg2/GUISONGS.py:
[06:20:17] <CIA-23> GemRB: GUIScript: Fix done button in bg2/GUISONGS
[06:20:17] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[06:20:37] <-- budlust has left IRC (Quit: Konversation terminated!)
[06:20:57] --> budlust has joined #GemRb
[06:37:08] <tomprince> Shoud the bg2 main menu screen option menu return to Start, or Start2?
[06:37:13] <-- Gekz has left IRC (Ping timeout: 252 seconds)
[06:39:44] <tomprince> or.cz/events: cleaned up callback code. I plan to push all but the last one.
[07:30:34] <CIA-23> GemRB: 03avenger_teambg * r25de1bb1eaf0 10gemrb/gemrb/plugins/SDLVideo/SDLVideo.cpp: fixed the previous fix about subtitle text
[07:30:35] <CIA-23> GemRB: 03avenger_teambg * r387e07b2a8d9 10gemrb/gemrb/ (GUIScripts/bg2/GUISONGS.py docs/en/CMakeLists.txt): Merge branch 'master' of ssh://avenger_teambg@gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[07:31:22] --> Avenger_ has joined #GemRb
[07:32:02] --- Avenger_ is now known as Avenger
[07:32:10] --- ChanServ gives channel operator status to Avenger
[07:32:52] <Avenger> hi
[07:40:47] <-- Avenger has left IRC (Quit: bye!)
[07:46:13] <-- budlust has left IRC (Ping timeout: 264 seconds)
[07:57:03] --> budlust has joined #GemRb
[08:02:47] --> raevol has joined #GemRb
[08:33:22] --> lynxlynxlynx has joined #GemRb
[08:33:22] --- ChanServ gives channel operator status to lynxlynxlynx
[08:45:47] <-- raevol has left IRC (Quit: Leaving.)
[09:28:28] <CIA-23> GemRB: 03lynxlupodian * raa320afd7434 10gemrb/gemrb/GUIScripts/ (5 files in 5 dirs): GUICommon{,Windows}: removed a few unneeded imports and slimmed down a few others
[10:02:20] --> Maighstir_laptop has joined #GemRb
[10:44:14] --> Edheldil has joined #GemRb
[11:04:53] <-- Edheldil has left IRC (Remote host closed the connection)
[11:34:55] <lynxlynxlynx> buh
[11:35:23] <lynxlynxlynx> i always get into dependency trouble
[11:35:41] <fuzzie> between modules?
[11:35:47] <lynxlynxlynx> no, that's the wierd part
[11:36:06] <lynxlynxlynx> gemrb/GUIScripts/bg2/LUHLASelection.py defines HLASelectPress and calls it from another function in the same module
[11:36:43] <lynxlynxlynx> that function is run (called from outside) and but [GUIScript]: Missing function:HLASelectPress
[11:37:11] <lynxlynxlynx> (i'm changing things to import modules "by ref")
[11:37:26] <fuzzie> the callback has to live in the 'current' script module
[11:37:40] <fuzzie> which is not LUHLASelection
[11:37:49] <lynxlynxlynx> oh
[11:38:07] <fuzzie> this is why tomprince's callback stuff is important
[11:38:23] <-- AntiPudd1ng has left IRC (Quit: leaving)
[11:38:36] <fuzzie> because then you can just pass the function
[11:39:09] <lynxlynxlynx> i guess i can't fix this easily then, importing a copy would probably break, since the function modifies globals
[11:39:33] <fuzzie> well, importing doesn't import a copy of the function, just a copy of the variable referring to the function
[11:39:51] <fuzzie> so the function still has the same parent module, etc
[11:40:15] <lynxlynxlynx> maybe it'll work then
[11:41:02] <fuzzie> but, yes, the callback-by-name stuff is a lot more horrible than it appears :(
[11:41:21] <-- budlust has left IRC (Ping timeout: 265 seconds)
[11:49:56] <wjp> hm, it seems I still have an un-pushed patch here that adds an unused PixelType argument to BlitTile_internal to work around a MSVC6 template bug
[11:50:49] <wjp> I guess that's still relevant?
[11:51:20] <fuzzie> strange, i thought msvc6 would default to the second one
[11:51:46] <fuzzie> i wonder if tomprince is actually running any of the builds
[11:51:55] <fuzzie> or Avenger
[11:52:28] <Maighstir_laptop> wasn't that why he made the minimal dataset? to see if it runs
[11:52:43] <wjp> wouldn't this only show up at runtime with the 'wrong' PixelType?
[11:53:39] <fuzzie> well, this is tile-rendering code, so you'd have to actually load an area
[11:53:50] <fuzzie> wjp: i thought it would default to the 'wrong' PixelType, is all
[11:58:07] <wjp> ah, I don't know which one Avenger is using
[12:01:32] <fuzzie> so it seems still relevant, but no idea if it's necessary
[12:05:46] --> Avenger has joined #GemRb
[12:05:49] --- ChanServ gives channel operator status to Avenger
[12:06:09] <lynxlynxlynx> ojla
[12:06:22] <CIA-23> GemRB: 03lynxlupodian * r4fc07441b8ba 10gemrb/gemrb/GUIScripts/bg2/LUHLASelection.py: LUHLASelection: import whole modules, call functions directly
[12:06:24] <CIA-23> GemRB: 03lynxlupodian * r5c67010683f2 10gemrb/gemrb/GUIScripts/Actor.py: Actor.py: import the correct and whole module and adjust users appropriately
[12:06:27] <CIA-23> GemRB: 03lynxlupodian * re7a6b4610c9a 10gemrb/gemrb/GUIScripts/LevelUp.py: LevelUp: import modules directly
[12:06:40] <Avenger> tile rendering works on msvc6 currently
[12:06:45] <fuzzie> with 16bpp or 32bpp?
[12:07:01] <Avenger> i think i always use it 32bpp
[12:07:55] <fuzzie> there is a bug in msvc6's optimiser which i thought would make it combine the 16 and 32bpp functions into a single function without wjp's patch, but i thought it always picked the second one, which would be 16bpp
[12:08:45] <fuzzie> but i still have no time until wednesday
[12:08:59] <Avenger> at one point there was some bug in the tile rendering, wjp told me to do somehting, i think he made me to hardcode the selection
[12:09:29] <Avenger> but since then i updated my sources and copied the one from git
[12:10:04] <fuzzie> interesting
[12:10:28] <Avenger> i'm on linux now, but i can check it on win if you want
[12:10:31] <fuzzie> well, seems silly to mess with it if there's no problem
[12:11:07] <Avenger> does that optimization work if you compile with debug info?
[12:11:11] --> budlust has joined #GemRb
[12:11:25] <Avenger> i usually compile with debug info, so, maybe thats why i don't see any problem now
[12:11:45] <fuzzie> well, if you ever have any time to check it out, but i think there's no hurry
[12:13:57] <Avenger> ok
[12:14:00] <-- Avenger has left IRC (Quit: bye!)
[12:34:30] --> pupnik has joined #GemRb
[12:37:40] <-- budlust has left IRC (Read error: Operation timed out)
[12:38:35] <tomprince> morning.
[12:38:51] <lynxlynxlynx> oj
[12:39:30] <CIA-23> GemRB: 03lynxlupodian * rc306d625ebff 10gemrb/gemrb/GUIScripts/LUSpellSelection.py: LUSpellSelection: import GUICommon directly
[12:39:33] <CIA-23> GemRB: 03lynxlupodian * rc480350a10c9 10gemrb/gemrb/GUIScripts/LUSkillsSelection.py: LUSkillsSelection: import GUICommon directly
[12:39:34] <CIA-23> GemRB: 03lynxlupodian * rae8a6e6fcbd7 10gemrb/gemrb/GUIScripts/LUProfsSelection.py: LUProfsSelection: import GUICommon directly
[12:39:38] <CIA-23> GemRB: 03lynxlupodian * r2ed77c62253a 10gemrb/gemrb/GUIScripts/LUCommon.py: LUCommon: import GUICommon directly
[12:39:39] <CIA-23> GemRB: 03lynxlupodian * r080e9b3f88d8 10gemrb/gemrb/GUIScripts/TextScreen.py: TextScreen: import GUICommon directly
[12:40:26] <lynxlynxlynx> all toplevel pythons are done now :)
[12:40:56] <tomprince> fuzzie: lynxlynxlynx: how does the current branch look?
[12:41:01] --> budlust has joined #GemRb
[12:41:31] <lynxlynxlynx> guicallback?
[12:41:41] <tomprince> events
[12:42:55] <fuzzie> it seems good up until the last commit
[12:43:13] <fuzzie> which is not really reviewable by looking at it
[12:43:20] <tomprince> I wasn't going to push the last one right away.
[12:43:56] <fuzzie> although a wholesale s/private:/public:/ is a bit scary
[12:44:25] <fuzzie> that can't be done either nicer or with a friend clause?
[12:45:26] <fuzzie> i like handler->call
[12:45:44] <tomprince> A little bit, yes. Or a friend would work.
[12:46:22] <fuzzie> the TODO for the name doesn't seem too important since it'll produce a backtrace
[12:46:30] <tomprince> It is local to the plugin.
[12:47:21] <tomprince> (the private->public)
[12:47:37] <tomprince> That is why it is only a todo.
[12:47:58] <fuzzie> an obvious thing i see here is that 0 is being passed to SetEvent
[12:48:29] <fuzzie> not anything to do with your patch series, but replacing those with IE_GUI_BUTTON_ON_PRESS should maybe go on a todo list, if that's what it's doing
[12:49:18] <fuzzie> but it all looks great at a glance.
[12:50:38] <fuzzie> if you push everything except the last commit now, i guess that immediately helps lynx
[12:50:49] <tomprince> I think the proper solution to the public vs private, may be to split up GUIScript into two classes, one that derives from ScriptEngine and is public facing, and one that is plugin facing.
[12:51:13] --> Gekz has joined #GemRb
[12:51:16] <tomprince> Or maybe it isn't an issue. I don't know if encapsulation gains us anything here?
[12:51:18] <fuzzie> i don't object to the last commit, i just can't review it atm
[12:51:39] <lynxlynxlynx> it needs to be refreshed
[12:51:47] <tomprince> I was planning on pushing it yet anyway.
[12:51:56] <lynxlynxlynx> otherwise it looks pretty automated
[12:51:57] <fuzzie> well, you can argue that encapsulation gains you nothing anywhere :)
[12:53:26] <fuzzie> seems like the right design there shouldn't have the callback classes reaching into class internals, but *shrug*
[12:54:06] <fuzzie> as you say it's all pretty internal anyway, so if you just want it to treat everything like a global for the whole plugin..
[12:54:46] <tomprince> At least for everything in PythonHelpers, I think.
[12:55:21] <tomprince> lynxlynxlynx: Want me to merge?
[12:55:49] <fuzzie> thanks for doing all this messy callback work, anyhow
[12:55:53] <lynxlynxlynx> sure
[12:56:28] <lynxlynxlynx> i can't do any effective cleanup of the individual game types without it
[12:56:40] <fuzzie> i had envisaged something a bit more blackbox-ish, event handlers being a void*, the meaning of which were entirely internal to the scriptengine
[12:56:50] <fuzzie> is rather neater the way you did it
[12:56:53] <CIA-23> GemRB: 03tom.prince * rb29d10c896cf 10gemrb/gemrb/ (164 files in 8 dirs):
[12:56:53] <CIA-23> GemRB: GUIScript: Rename Control.SetEvent to Control.SetEventByName.
[12:56:53] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[12:56:56] <CIA-23> GemRB: 03tom.prince * r57ad07a8e0c9 10gemrb/gemrb/plugins/GUIScript/ (GUIScript.cpp GUIScript.h PythonHelpers.h):
[12:56:56] <CIA-23> GemRB: GUIScript: Prepare for having other C++ files in GUIScript.
[12:56:56] <CIA-23> GemRB: - Change gs variable from static to extern.
[12:56:56] <CIA-23> GemRB: - Make PythonHelpers.h not depend on GUIScript.h being included first.
[12:56:57] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[12:56:57] <CIA-23> GemRB: 03tom.prince * ref9bc9eb0dc1 10gemrb/gemrb/ (8 files in 2 dirs):
[12:56:58] <CIA-23> GemRB: Callback: Add callback interfaces for python.
[12:56:58] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[12:57:01] <CIA-23> GemRB: 03tom.prince * r0517b0e91731 10gemrb/gemrb/ (25 files in 2 dirs):
[12:57:01] <CIA-23> GemRB: Control: Change controls to use new callback infrastrucure.
[12:57:01] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[12:57:03] <CIA-23> GemRB: 03tom.prince * r4dc2aceea7fc 10gemrb/gemrb/ (GUIScripts/GUIClasses.py plugins/GUIScript/GUIScript.cpp):
[12:57:03] <CIA-23> GemRB: GUIScript: Add method to set python callables as callbacks.
[12:57:03] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[12:57:05] <CIA-23> GemRB: 03tom.prince * r672e9e42ecd5 10gemrb/gemrb/GUIScripts/ (23 files in 5 dirs):
[12:57:05] <CIA-23> GemRB: GUIScript: Use None instead if "", for null event handler.
[12:57:05] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[12:57:06] <CIA-23> GemRB: 03tom.prince * r2bf2012b5616 10gemrb/gemrb/ (196 files in 9 dirs):
[12:57:06] <CIA-23> GemRB: Merge branch 'events'.
[12:57:07] <CIA-23> GemRB: Conflicts:
[12:57:07] <CIA-23> GemRB: gemrb/GUIScripts/LUSpellSelection.py
[12:58:38] <tomprince> Anyway, am going for breakfast. Will be back shortly to fix any fallout, and see about a win32 build, and mess with the command stuff.
[13:00:26] <fuzzie> :-)
[13:00:31] <fuzzie> busy bee
[13:05:00] <fuzzie> a minute or so of ps:t seems to work ok
[13:10:22] <Lightkey> Conflicts?
[13:10:36] <Lightkey> anyway, 196 files? o_O
[13:10:40] <fuzzie> the files which had to be edited in some way during the merge
[13:10:40] <lynxlynxlynx> merge conflicts
[13:10:43] <Maighstir_laptop> IwD works well enough
[13:11:22] <Lightkey> yes, just not sure whether he added it or it was an automated warning
[13:11:29] <lynxlynxlynx> automated
[13:22:12] --> tomprince_loki has joined #GemRb
[14:38:51] <-- CIA-23 has left IRC (Ping timeout: 272 seconds)
[14:56:07] --> CIA-25 has joined #GemRb
[14:59:26] <-- budlust has left IRC (Ping timeout: 240 seconds)
[15:02:43] <-- pupnik has left IRC (Ping timeout: 276 seconds)
[15:03:01] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[15:03:17] --> tomprince_loki has joined #GemRb
[15:03:59] <tomprince_loki> How bad did I break things. :)
[15:04:20] <lynxlynxlynx> nothing appears broken to me
[15:04:57] <tomprince_loki> Excellent.
[15:09:02] --> budlust has joined #GemRb
[15:09:02] <CIA-25> GemRB: 03lynxlupodian * r16a1ea50e1e2 10gemrb/gemrb/GUIScripts/bg2/ (26 files):
[15:09:02] <CIA-25> GemRB: bg2: made GUICommonWindows import whole modules and hopefully fixed all the
[15:09:02] <CIA-25> GemRB: exposed holes
[15:13:55] <-- budlust has left IRC (Ping timeout: 248 seconds)
[15:57:48] --> cubathy has joined #GemRb
[16:26:41] --> Dark-Star has joined #GemRb
[16:26:41] --- ChanServ gives channel operator status to Dark-Star
[16:59:50] <lynxlynxlynx> i have found a problem
[17:00:02] <Lightkey> call houston
[17:00:19] <lynxlynxlynx> overriding functions doesn't refresh the callback
[17:00:42] <lynxlynxlynx> or more plainly, the callback is static
[17:07:01] <tomprince_loki> Well, that has to do with python semantics. If you redefine a function, it changes the binding of the name, but the old object is still around. SetEvent binds to the function object passed to it.
[17:07:25] <tomprince_loki> I am curious what you are trying to do, that you are overriding a callback dynamically?
[17:12:48] <lynxlynxlynx> i am going through bg2, cleaning up the imports
[17:13:00] <lynxlynxlynx> this particular problem is at the end of chargen
[17:13:29] <lynxlynxlynx> NextPress is overriden for the last step just to avoid a loop
[17:13:50] <lynxlynxlynx> and like you point out, the old function gets called
[17:15:57] <tomprince_loki> Yes, that is why I didn't change NextPress. :/ I think there has to be a better, more modular design for that, but I am not sure what it is.
[17:16:15] <tomprince_loki> I would say, leave it for the first pass, add add a FIXME.
[17:17:26] <lynxlynxlynx> no, i'll redesign a bit of the script, otherwise i can't continue the work
[17:20:49] <tomprince_loki> That works too.
[17:24:29] <CIA-25> GemRB: 03lynxlupodian * r48630e68ddf6 10gemrb/gemrb/GUIScripts/ (22 files in 2 dirs):
[17:24:29] <CIA-25> GemRB: bg2: more import cleanup;
[17:24:29] <CIA-25> GemRB: moved FinishCharGen to its own file
[17:24:36] <CIA-25> GemRB: 03lynxlupodian * re09a1bb48972 10gemrb/gemrb/GUIScripts/ (14 files in 3 dirs): removed a few needless imports
[17:30:02] <fuzzie> with all the chargen code replaced, i imagine we could remove SetEventByName, given that SetNextScript isn't used significantly outside that?
[17:30:14] <fuzzie> if it works out, that is
[17:31:42] <lynxlynxlynx> there are still plenty of callers
[17:32:29] <fuzzie> well, it only matters if SetNextScript is used where the functions are going to get overridden by name
[17:35:45] <tomprince_loki> SetNextScript?
[17:36:18] <fuzzie> not that?
[17:36:22] <fuzzie> whatever changes the module
[17:36:36] <fuzzie> sorry, no code here, just thinking out loud while i'm sat down at a computer for a moment :)
[17:36:41] <tomprince_loki> Yes, that changes the module.
[17:37:02] <tomprince_loki> Oh, I think I see what you mean.
[17:38:17] <tomprince_loki> It just occured to me that SetNextScript can perhaps go away, once SetEventByName does, and the RunFunctions on the C++ side get changed. Since those are the only two things that care about wich script is active.
[17:39:34] <fuzzie> not sure it would be a good thing.
[17:39:48] <fuzzie> i'd have to see some idea of how it would work, i guess.
[17:40:41] <tomprince_loki> The same way we swich screens while GUIWORLD is active right now, probably.
[17:41:13] <fuzzie> well, that is a horrible overcomplicated thing which only works because the core knows what to show/hide
[17:41:33] <fuzzie> so i worry that it would be more of a mess
[17:43:34] <fuzzie> well, i guess it would be unnecessary if you had a queue of python functions to call on the next frame
[17:43:48] <fuzzie> then you could just queue somemodule.OnLoad to get the same behaviour
[17:44:53] <tomprince_loki> Does it actually need to be the next frame?
[17:45:09] <fuzzie> well, it makes the code far less error-prone
[17:45:21] <fuzzie> and a lot simpler
[17:46:07] <tomprince_loki> Well, maybe I'll experiment with it, after SetEventByName goes away mostly.
[17:46:14] <fuzzie> but we've had this discussion before; thereotically you could make it work however, but imo at the cost of making it accessible to random hacking
[17:48:42] <tomprince_loki> I am curious what kind of errors might result. Clearly, if things are being called by name in the current frame, things could break right now, but if there is not calling by name, I am not sure what issues there could be. Admittedly, it just occured to me, and I haven't thought about it at all.
[17:48:49] <fuzzie> i mean
[17:48:56] <fuzzie> my starting point is: SetEventByName is gone completely.
[17:49:12] <fuzzie> so there is no longer a dictionary etc, no need to poke at symbols of the current module.
[17:49:55] <tomprince> Exactly. I am just curious what errors you would be prone to.
[17:50:33] <fuzzie> so I click a button, and I want to replace the GUI with a whole different screen, and either you can handle that with a simple "call this completely new function, sometime when it's safe", or you can write a whole bunch of really complicated re-entrant stuff and wrap everything in reference counting and confuse me to death.
[17:52:35] <fuzzie> and in the end, what you're going to want to do as a GUI script author is still going to "move to the next screen now".
[17:52:43] <tomprince_loki> I suspect that *now* is safe, is my thought.
[17:52:52] <tomprince_loki> But if that isn't the case, I see your point.
[17:53:00] <fuzzie> it isn't
[17:53:10] <fuzzie> but in any case, i am more concerned about simplicity.
[17:53:31] <fuzzie> if you want to write more code, it is not something for me to worry about :)
[17:53:53] <fuzzie> but SetNextScript is a very simple API with a very simple idea, and I think nothing else would be
[17:56:03] <fuzzie> but the windowing stuff is pretty fragile, i still haven't found the bug w/combat where some script messes with the GUI from underneath itself and something ends up corrupted
[17:56:22] <tomprince_loki> Well, my though was 'import GUIWORLD; GUIWORLD.Open()'
[17:56:31] <tomprince_loki> I wouldn't want anything more complicated.
[17:57:25] <fuzzie> but that is misleading
[17:57:28] <tomprince_loki> If that doesn't work, then it isn't worth changing.
[17:57:38] <fuzzie> because it'll always happen from inside an event handler
[17:58:20] <fuzzie> but, well, if you have the time to try it..
[18:02:16] <fuzzie> i am pondering about whether a generic script queue thing would be useful elsewhere
[18:03:05] <fuzzie> for example, GemRB_EnterStore sets the EF_OPENSTORE thing purely for sync issues, to make sure the OpenStoreWindow function is called from the next frame
[18:04:38] <fuzzie> most of the rest of those are called for sync reasons from actions/events, but it wouldn't really gain anything to have the queue, it would just get rid of some of the boilerplate EF_ code
[18:07:09] <tomprince_loki> Well, I am only interested in doing it if it actually simplifies the code, and does have weird corner cases.
[18:07:39] <lynxlynxlynx> +not
[18:07:52] <fuzzie> well, i mean, considering this seperately from the previous discussion
[18:07:59] <CIA-25> GemRB: 03lynxlupodian * rce46e6626340 10gemrb/gemrb/GUIScripts/ (LUCommon.py LevelUp.py): bg2: moved ReactivateBaseClass back to its only caller, fixing the function
[18:08:00] <CIA-25> GemRB: 03lynxlupodian * r7b081f5a6b1c 10gemrb/gemrb/GUIScripts/bg2/DualClass.py: DualClass: cleaned up the imports, inadvertently fixing another bug
[18:08:02] <CIA-25> GemRB: 03lynxlupodian * rd96eda24898d 10gemrb/gemrb/GUIScripts/bg2/DualClass.py: DualClass: fixed iwd druid spell lookup
[18:08:15] <fuzzie> take a look at Interface::HandleEvents (but ignore the comment, there are far more sync issues involved than just windowing)
[18:11:02] <fuzzie> it is tricky because it does things like delaying updates while windows aren't visible, but still
[18:12:05] <fuzzie> it would be simple to change half of that into a queue, if it would be better
[18:18:24] <fuzzie> but i don't really want to fiddle if you have plans :)
[18:18:42] <fuzzie> lynxlynxlynx: see forum
[18:19:35] <fuzzie> i'm not sure what the plans are for build system etc, so can't comment myself
[18:21:49] <lynxlynxlynx> done
[18:22:37] <fuzzie> thanks :)
[18:22:56] <tomprince> I don't.
[18:23:23] <fuzzie> we should get rid of INSTALL if automake isn't encouraged
[18:23:49] <tomprince> Or at least not have it be the autotools INSTALL.
[18:24:09] <tomprince> Have it it be Building-cmake.txt
[18:24:20] <fuzzie> why not just BUILDING?
[18:24:46] <fuzzie> if people already know to look for cmake docs, they probably don't need any notes
[18:24:52] <tomprince> I meant what is currently Building-cmake.txt should become INSTALL.
[18:25:06] <fuzzie> oh. we have a Building-cmake.txt?
[18:25:15] <tomprince> gemrb/docs/en
[18:25:16] <fuzzie> aha
[18:26:04] <fuzzie> i didn't realise those even were there
[18:26:24] <fuzzie> so, yes, +1
[18:28:39] --> pupnik_ has joined #GemRb
[18:30:47] <lynxlynxlynx> ok
[18:31:10] <lynxlynxlynx> any chance of also getting SetTimedEvent to accept python objects?
[18:31:59] <fuzzie> there's no need for that to take names at all, right?
[18:32:22] <lynxlynxlynx> no idea, just stumbled upon it now
[18:32:48] <fuzzie> it seems that it would be trivial
[18:33:36] <fuzzie> don't know if tomprince has time, otherwise i could do it
[18:33:48] <Maighstir_laptop> http://ops-area.net/annat/GemRB/Subtitles.PNG ... Subtitles in Icewind Dale do not disappear, but new ones are simply layered on top of the old ones.
[18:34:01] <lynxlynxlynx> that happens everywhere
[18:34:13] <fuzzie> that is during cutscenes?
[18:34:22] <Maighstir_laptop> intro movie
[18:34:30] <fuzzie> i mean, sorry, movies
[18:35:15] <fuzzie> hmm
[18:35:23] <fuzzie> it seems that the subtitles are fetched every frame
[18:36:11] <fuzzie> so it's just that it isn't clearing the space
[18:36:51] <fuzzie> you could copy lines 2417-2420 (SDL_LockSurface, a memset and SDL_UnlockSurface) of SDLVideo.cpp into the top of the showFrame function (right below it)
[18:37:29] <fuzzie> if that works then it could easily be restricted to just do it for subtitleregion
[18:40:45] <tomprince_loki> or.cz/events: SetTimedEvent. Just the C++ changes, and compiling now.
[18:41:16] <fuzzie> you don't reset event_handler
[18:41:27] <fuzzie> i guess that doesn't actually matter
[18:41:40] <fuzzie> but would be nice anyway, if possible
[18:43:13] <tomprince> done.
[18:43:53] <fuzzie> looks good, then
[18:44:54] <Maighstir_laptop> That works, yes
[18:47:16] <tomprince> Maighstir_laptop: http://hermes.hocat.ca:4010/test-gemrb-v0.6.1-mingw.zip
[18:47:29] <tomprince> Install into 'C:/Program Files/gemrb'
[18:47:46] <-- pupnik_ has left IRC (Ping timeout: 240 seconds)
[18:54:36] <fuzzie> hardcoded paths?
[18:54:58] <fuzzie> or just to avoid fiddling with the config?
[18:56:01] <tomprince> To avoid fiddling with the config. At least I think that is the only reason.
[18:56:21] <fuzzie> yes, sorry, the first was a stupid question
[18:56:26] <fuzzie> i didn't think :)
[19:00:49] <Maighstir_laptop> On the virtual machine (VMWare) GemRB complained that it couldn't open the OpenAL device, and subsquently quit (Winows' own warning sounds are fine), trying on the old laptop in a moment... both are Win2000 pro
[19:01:57] <Maighstir_laptop> Oh, yeah, i fiddled with the config, almost without thinking
[19:05:59] <fuzzie> is there a bundled openal32.dll?
[19:06:14] <tomprince> Yes.
[19:06:22] <fuzzie> and it's OpenAL Soft?
[19:06:46] <fuzzie> strange if so, i thought it would fall back to winmm
[19:09:07] <Maighstir_laptop> More specific message: [Core]: Starting up the Sound Driver...[OpenAL]: Failed to open device 40961 [ERROR]
[19:09:17] <tomprince> I don't know if it is openal soft.
[19:13:10] <fuzzie> no, it is the creative openal router
[19:13:14] <fuzzie> so i would not expect it to work.
[19:13:17] <Maighstir_laptop> installing openal solves it
[19:13:37] <fuzzie> because there's no actual openal implementation in it :)
[19:14:04] <fuzzie> (it just looks in the registry for installed openal implementations and relays calls)
[19:18:23] <Maighstir_laptop> except for that (and few changes in GUIScript since then), my tiny dataset runs as expected
[19:19:09] <fuzzie> is there anything which would help with your dataset?
[19:22:19] <Maighstir_laptop> Not sure, as of now I just have a few buttons and SetNextScript calls... the constant changes in the guiscript doesn't really help me in getting further along when I have to figure out what's changed :-P
[19:22:50] <lynxlynxlynx> "constant"
[19:23:12] <Maighstir_laptop> I mostly use it because it's easier to copy a few MB than a couple GB between computers and VMs
[19:24:03] <fuzzie> ok. you are welcome to ask how to fix snippets of guiscript, if it's easier :)
[19:24:29] <lynxlynxlynx> tomprince: you need to fix the variable name
[19:24:41] <Maighstir_laptop> When I manage to load an area of my own making, I'll consider it for distribution with GemRB
[19:24:49] <lynxlynxlynx> can't say if it works properly though, since i got into a big loop now
[19:26:21] <lynxlynxlynx> Maighstir_laptop: there are some nice backgrounds on shs, but i'm not sure if they're completely authored anew
[19:28:22] <fuzzie> you might ask K'aeloree, who in another incarnation organised some Free backgrounds for another project of mine
[19:33:15] <Maighstir_laptop> And about that "it takes 30 seconds to close the console window" on Windows that i mentioned recently: Looking at memory usage, it uses about 18 MB when just loaded (my tiny dataset), then when i call GemRB.Quit() it rises to almost 2GB in a matter of seconds and stays there until it closes. My old laptop and virtual machines gets to complain about virtual memory being too low (understandably), since they hav
[19:33:16] <Maighstir_laptop> (2GB) and desktop (8GB).
[19:34:09] <Maighstir_laptop> The Linux VM's are not affected.
[19:34:13] <fuzzie> that still happens with tomprince's build?
[19:34:56] <Maighstir_laptop> his seems to be 0.6.1 release, isn't it?
[19:35:05] <fuzzie> oh, this is new since then?
[19:35:14] <Maighstir_laptop> but yes
[19:36:03] <Maighstir_laptop> I normally run the latest possible, it happened before... having loads of memory i didn't think about it much, and I only though about checking memory usage now
[19:36:36] <fuzzie> tomprince: don't you run PluginMgr::RunCleanup too early (i.e. before things still use video/etc?)
[19:36:42] <CIA-25> GemRB: 03lynxlupodian * rc87d42cd0e74 10gemrb/gemrb/GUIScripts/LevelUp.py: LevelUp: fixed oops from one of the previous commits
[19:36:45] <CIA-25> GemRB: 03lynxlupodian * r388d04bba2b3 10gemrb/gemrb/GUIScripts/bg2/ (GUILOAD.py GUIMOVIE.py GUISAVE.py GUISONGS.py): bg2: a few more imports done
[19:37:29] <fuzzie> not sure if that's anything to do with your changes
[19:38:40] <fuzzie> but seems a recipe for potential future disaster
[19:40:04] <fuzzie> i have no idea what might be causing memory usage, i guess printf()s inconvenient places might be a start, but all the magical Holder stuff makes it difficult to follow
[19:41:27] <tomprince> Well, I think we need a more intelligent cleanup handling. But the RunCleanup is where the functions it is replacing were. It doesn't cleanup all plugins, it just runs those functions that registred with it.
[19:44:17] <fuzzie> *nod*
[19:44:26] <fuzzie> found that now, poking through history
[20:06:53] <tomprince> Maighstir_laptop: http://hermes.hocat.ca:4010/test-GemRB-v0.6.1.zip
[20:07:01] <tomprince> This should work w/o openal installed.
[20:08:37] --> budlust has joined #GemRb
[20:17:01] <Maighstir_laptop> it seems to work as far as I can see
[20:27:41] <Maighstir_laptop> excepting the memory problem, that is
[20:29:48] <tomprince> lynxlynxlynx: Here is the clean build http://hermes.hocat.ca:4010/GemRB-v0.6.1.zip
[20:30:24] <lynxlynxlynx> great, i'll upload it
[20:39:47] <lynxlynxlynx> done & announced
[20:40:04] <lynxlynxlynx> thanks
[20:45:34] <-- cubathy has left IRC (Ping timeout: 265 seconds)
[20:48:56] <CIA-25> GemRB: 03lynxlupodian * r4da8f9f7a65e 10gemrb/ (INSTALL gemrb/docs/en/Building-cmake.txt): moved Building-cmake.txt to INSTALL (default GNU) and clarified a bit
[20:49:43] <Lightkey> 0.6.0 2.2 MB, 0.6.1 1.7 MB? O_o
[20:50:25] <Lightkey> what happen?
[20:51:21] <lynxlynxlynx> the source tarball is smaller too
[20:51:56] <Lightkey> that's what I meant?
[20:52:07] <lynxlynxlynx> but i'm not really sure, because it is mostly text, which compresses well
[20:52:53] <lynxlynxlynx> but surely all the now not-included autotools crutf is part of the gain
[20:53:04] <Lightkey> none of the previous tarballs are that small, the earliest 0.2.8 being the smallest with 1.9 MB
[20:55:07] <lynxlynxlynx> download the tarball, extract, run du -sh .; ./autogen.sh; du -sh .
[20:56:12] <-- budlust has left IRC (Ping timeout: 265 seconds)
[20:57:15] <tomprince> For the binaries, we have less exported symbols, which might be significant.
[20:59:02] --> budlust has joined #GemRb
[20:59:41] <Lightkey> on the contrary, the Windows binary is the biggest yet, with over 5 MB
[21:00:09] <Lightkey> 0.6.0 was only 4.6 MB
[21:01:55] <lynxlynxlynx> i see why the source one is also smaller - when i added the make dist target to cmake, i made it use --best (-9) compression
[21:02:05] <CIA-25> GemRB: 03tom.prince * r31ee3ec2a01d 10gemrb/gemrb/plugins/PNGImporter/CMakeLists.txt:
[21:02:05] <CIA-25> GemRB: cmake: Link PNGImporter against all required libraries.
[21:02:05] <CIA-25> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[21:02:50] <lynxlynxlynx> the windows build was done by different people, so we don't know if the same compression was used
[21:14:02] <Lightkey> that took some time.. for 0.6.1, it was 17.6 MB and after autogen 22.2 MB, 0.6.0 is 19.1 MB
[21:14:23] <Lightkey> is 0.6.0 already autogened? because there is no autogen.sh
[21:25:35] <lynxlynxlynx> yep
[21:28:36] <Lightkey> so if you substract that amount from 0.6.0, it means 0.6.1 actually gained 3 MB?!
[21:29:47] <CIA-25> GemRB: 03tom.prince * rfc772185bb59 10gemrb/gemrb/ (core/Makefile.am plugins/CMakeLists.txt plugins/Makefile.am):
[21:29:47] <CIA-25> GemRB: Sort makefiles.
[21:29:47] <CIA-25> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[21:29:53] <Lightkey> anyway, it seems the cause was mostly the higher compression
[21:31:18] <lynxlynxlynx> no, it's not so simple
[21:32:27] <Lightkey> btw, I thought tar uses -9 by default
[21:33:18] <lynxlynxlynx> nope, it's -6
[21:35:39] <Lightkey> mixed it up with bzip2
[21:37:33] <lynxlynxlynx> btw, if you have a multicore machine i suggest you install pbzip2
[21:38:21] <CIA-25> GemRB: 03lynxlupodian * r0b33f13ede12 10gemrb/CMakeLists.txt: cmake: display all the configured paths at the end
[21:42:51] <Lightkey> where did that suggestion come from? ;-P
[21:43:35] <Lightkey> and no, all I have are single-cores
[21:48:00] <lynxlynxlynx> same here
[21:48:17] <lynxlynxlynx> but parallelization helps a lot
[21:49:56] <Lightkey> I understand that, just not why you are suggesting that to *me* :p
[21:51:17] <Lightkey> wait, you still have no multicores?!
[21:52:29] <Lightkey> I mean, I am just too lazy to buy a new one but you are obviously not :p
[21:52:56] <lynxlynxlynx> i am immune to new shiny stuff
[21:53:22] <lynxlynxlynx> while this old machine works, i have no good reason to replace everything
[21:53:53] <lynxlynxlynx> sure it can be slow sometimes, but so what?
[21:54:50] <Lightkey> you definitely need a new machine, they break down faster, so you will always have more up-to-date machines
[21:55:33] <lynxlynxlynx> ;P
[22:05:11] --> _pickle has joined #GemRb
[22:11:54] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:22:43] <-- budlust has left IRC (Ping timeout: 265 seconds)
[22:42:59] <tomprince> lynxlynxlynx: Would it make sense to post a new tarball, that has an updated INSTALL?
[23:12:38] <CIA-25> GemRB: 03tom.prince * r0e5d096d8f0c 10gemrb/gemrb/ (9 files in 5 dirs):
[23:12:38] <CIA-25> GemRB: GUIScript: Rename SetTimedEvent to SetTimedEventByName.
[23:12:38] <CIA-25> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[23:12:46] <CIA-25> GemRB: 03tom.prince * r1091bc05f433 10gemrb/gemrb/ (core/Game.cpp core/Game.h plugins/GUIScript/GUIScript.cpp):
[23:12:46] <CIA-25> GemRB: GUIScript: Convert timed events to use Callbacks.
[23:12:46] <CIA-25> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[23:12:46] <CIA-25> GemRB: 03tom.prince * re3cd6459289b 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:
[23:12:46] <CIA-25> GemRB: GUIScript: Add SetTimedEvent function that takes a python callabale.
[23:12:46] <CIA-25> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[23:20:52] <CIA-25> GemRB: 03tom.prince * rbd4212c1fe90 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: GUIScript: Keep StringCallback strings stay in python.
[23:27:26] --> budlust has joined #GemRb
[23:50:10] --> miles_ has joined #GemRb
[23:51:10] <-- budlust has left IRC (Ping timeout: 265 seconds)
[23:59:55] --- miles_ is now known as budlust