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

Archive Today Yesterday Tomorrow
GemRB homepage

[00:03:49] <-- raevol has left IRC (Quit: Leaving.)
[00:38:32] <Maighstir_laptop> Git says "error: cannot open .git/FETCH_HEAD: Permission denied" when trying to pull gemrb. Did something happen?
[00:39:23] <-- Maighstir_laptop has left #GemRb
[02:37:47] --> Gekz has joined #GemRb
[03:21:14] --> raevol has joined #GemRb
[03:46:04] <-- raevol has left IRC (Quit: Leaving.)
[05:57:41] <-- Gekz has left IRC (Changing host)
[05:57:41] --> Gekz has joined #GemRb
[06:06:59] --> budlust has joined #GemRb
[06:15:43] <-- Gekz has left IRC (Read error: Connection reset by peer)
[06:31:11] <CIA-25> GemRB: 03tom.prince * rceec628af078 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:
[06:31:11] <CIA-25> GemRB: GUIScript: Fix typo in attribute error.
[06:31:11] <CIA-25> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[06:31:22] <CIA-25> GemRB: 03tom.prince * ra1ed6e7bb72c 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:
[06:31:22] <CIA-25> GemRB: GUIScript: Add missing NULL check.
[06:31:22] <CIA-25> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[06:33:21] <tomprince> or.cz/listbox: This has a working prototype.
[06:33:42] --> lynxlynxlynx has joined #GemRb
[06:33:42] --- ChanServ gives channel operator status to lynxlynxlynx
[06:34:08] <tomprince> Morning.
[06:34:14] <tomprince> Or should I say night. :)
[06:41:15] --> Gekz has joined #GemRb
[06:41:27] <tomprince> Feel free to bikeshed it, or any other comments.
[06:41:44] <tomprince> There is something not quite right about it, but I can't put my finger on it.
[06:56:20] <-- |Cable| has left IRC (Remote host closed the connection)
[06:59:12] <-- budlust has left IRC (Ping timeout: 265 seconds)
[07:00:06] --> budlust has joined #GemRb
[07:01:48] <-- budlust has left IRC (Client Quit)
[07:02:09] --> budlust has joined #GemRb
[07:02:52] <-- Gekz has left IRC (Read error: Connection reset by peer)
[07:10:09] --> Gekz has joined #GemRb
[07:34:01] <-- Gekz has left IRC (Changing host)
[07:34:01] --> Gekz has joined #GemRb
[07:58:25] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[08:08:51] --> miles_ has joined #GemRb
[08:09:17] <-- budlust has left IRC (Ping timeout: 265 seconds)
[08:15:58] <fuzzie> do we really need all those 'global' statements, is my first thought
[08:17:24] <fuzzie> otherwise my previous comments still apply: 'for j in row['Portraits']' would be tidier, for example, and i still ponder about users just subclassing ListBox, you need the processing function anyway..
[08:17:51] <fuzzie> oh, right, you need the SaveGame.GetPortrait. drat.
[08:29:28] --> Gekz has joined #GemRb
[08:45:08] --> edheldil has joined #GemRb
[09:07:34] --> miles__ has joined #GemRb
[09:07:46] <-- miles_ has left IRC (Ping timeout: 265 seconds)
[09:11:58] --> raevol has joined #GemRb
[09:20:08] <-- raevol has left IRC (Quit: Leaving.)
[09:31:55] <-- miles__ has left IRC (Read error: Operation timed out)
[12:32:08] <tomprince> Your probably right about the globals.
[12:35:09] --> barra_library has joined #GemRb
[12:38:32] <lynxlynxlynx> fuzzie: you'll be doing the keybindings soon? If so, I'd just leave the GameControl callbacks alone to avoid conflicts, since they'll be gone with your changes
[12:50:18] <tomprince> fuzzie: Posted a patch that turns it into a subclass.
[12:51:41] <tomprince> Feel free any of you to play around with syntax/structure.
[12:51:58] <tomprince> I have *zero* experience with gui programming.
[13:00:37] <wjp> Avenger asked to keep GUIScripts very simply to modify, by the way, since the modding community may not have much high-level programming experience
[13:01:49] <wjp> I haven't really looked at your branch yet, but just something to keep in mind :-)
[13:02:12] <tomprince> I certainly agree with that.
[13:02:52] <tomprince> At least so long as the doesn't cover *all* python.
[13:03:05] <wjp> well, you've seen my metaclass stuff ;-)
[13:03:09] <tomprince> :)
[13:03:13] <tomprince> Yes.
[13:04:45] <tomprince> I certainly think that making modding is easy is a good thing.
[13:05:55] <tomprince> Although... I might disagree on what constitutes easy.
[13:07:14] <fuzzie> well, easy meaning 'you don't have to be a programmer'
[13:08:28] <fuzzie> which means it being clear precisely what everything is doing if there's any chance it might be modified by end-users
[13:08:38] <fuzzie> but the metaclass stuff is obviously more part of the API
[13:16:36] <tomprince> Well, I was thinking more about the proceduralness of all the GUI code. Which may in fact be a reasonable design. But I seem to recall that keeping it easy for modders was also given as a reason.
[13:31:08] <fuzzie> well, it's a reason not to make it more difficult to work with.
[13:31:46] <edheldil> I always found OO intuitive (but not its rendering to some language like C++ ;-))
[13:32:36] <fuzzie> but 'easy' for modders is going to be biased towards *modifying* the code, too, which makes a difference
[13:32:50] <wjp> OO: yes, I think having 'window', 'control', ... objects makes sense and simplifies the guiscripts
[13:33:04] <fuzzie> yes, and the ListBox thing makes sense too imo
[13:33:35] <wjp> haven't looked at it yet, but I can imagine there's some common functionality there which can be moved "into the API"
[13:34:05] <fuzzie> it's just another trivial wrapper, yes
[13:36:09] <wjp> (looking at it now): does this subclassed SaveGameList have "user servicable parts" ?
[13:37:46] <tomprince> I would say that eveything in display would be. Also have a look at the previous commit. That was my original design. I don't know which is better.
[13:37:58] <fuzzie> the subclass prototyping was just a request from me
[13:38:23] <tomprince> I don't know about *just*. :)
[13:38:39] <fuzzie> well, i mean, you may claim innocence :-)
[13:43:49] <fuzzie> might be worth trying replacing one of the spell/HLA selection UIs, if you have a mod with enough content
[14:02:54] <-- barra_library has left IRC (Quit: Verlassend)
[14:23:44] <tomprince> fuzzie: done. very, very, *very* hackish.
[14:24:26] <tomprince> I think that LUSpellSelection needs a bunch of refactoring to make this worthwhile. But I think we have the infrastructure to do that now.
[14:26:41] <fuzzie> that patch just doesn't try getting the scrolling right?
[14:26:47] <tomprince> And note: It just scrolls one at a time now, but that is easy to change. :)
[14:27:31] <fuzzie> well, that is to some extent what i was curious about
[14:27:32] <tomprince> And, now that I think of it, the SetMaxes should move into ListBox.
[14:28:11] <fuzzie> since it's a bit tricky with the sorceror stuff
[14:29:18] <fuzzie> i think all the scrolling code in LUSpellSelection was contributed by a non-programmer, if that helps give an insight into the way it is
[14:38:08] <tomprince> Done. Not tested for levelup.
[14:38:51] <fuzzie> well, yes, because it doesn't handle the difficult case :)
[14:39:06] <tomprince> What is the difficult case?
[14:39:26] <fuzzie> default levelup window
[14:39:36] <fuzzie> 4 rows of 5 + 1 row of 4
[14:40:18] <tomprince> How is that supposed to scroll?
[14:40:25] <fuzzie> or does it handle that?
[14:41:41] <fuzzie> i think the idea is that the row of 4 is a row of 5 with the last one missing, so you have to be able to scroll one line further if you have 5 in that row
[14:42:08] <fuzzie> it's a pretty obscure case, but i think it's the trickiest one and so worth thought
[14:42:18] <fuzzie> since it did get thought+testing in the existing code
[14:43:05] <fuzzie> i just can't work out if it works with your code, at a glance
[14:43:30] <fuzzie> moving the SetMax into the ListBox is much nicer, though
[14:44:24] <tomprince> Well, it looks scrollbar + original window isn't possible. Since GUIEnhancements turns on both scrollbar and extra button.
[14:45:49] <fuzzie> the code is there to comment out the extra button, though?
[14:46:11] <fuzzie> huh
[14:46:56] <fuzzie> i guess we gave up?
[14:47:07] <fuzzie> it used to be a seperate Sorc25thSpellButton variable
[14:49:19] <fuzzie> but looks like that got dropped in 3de4ce5c, which added the GUIEnhancements switch
[14:49:42] <fuzzie> will have to poke through the UI mods
[14:52:35] <fuzzie> well, i guess never mind
[14:52:37] * fuzzie flails
[15:00:28] <tomprince> Anyway, the code works just fine if the last row isn't complete -> try changing line 253 to 21, or something, and going into chargen.
[15:04:15] <fuzzie> well, in that case, it seems like it's worthwhile even without any refactoring
[15:05:04] <fuzzie> but i think my conclusion is that i'd need to sit and look at it some more.
[15:14:37] <tomprince> Yes.
[15:15:36] <tomprince> At the very least, my changes need to be refactored. I was going for minimal, proof of concept change, rather than sensible change.
[15:36:29] --> budlust has joined #GemRb
[15:54:01] <lynxlynxlynx> i need help again
[15:54:25] <fuzzie> oh?
[15:55:14] <lynxlynxlynx> SetActionIcon GemRB_Window_SetupEquipmentIcons GemRB_Window_SetupSpellIcons
[15:55:48] <lynxlynxlynx> they construct the event name and are still on the by-name code, so i can't pass a module
[15:56:35] <fuzzie> hmm
[15:56:53] <fuzzie> my long-term plan was to just move all of those into python
[15:58:38] <fuzzie> in the short term i guess i would ask tomprince to hack a module name option into StringCallback..
[15:59:05] <lynxlynxlynx> looking at the functions, they don't seem to be so complicated
[16:00:07] <fuzzie> well, GemRB_Window_SetupControls is the most problematic?
[16:01:15] <lynxlynxlynx> mhm
[16:01:17] <fuzzie> if you think there are any issues with moving them to python, i'd like to hear
[16:03:21] <lynxlynxlynx> i don't know any
[16:04:16] <lynxlynxlynx> looks like a few more bindings would be needed, but that's all i can say
[16:06:51] <fuzzie> mhm
[16:07:36] <fuzzie> i think iwd2 is pretty much the worst-case, so hopefully not too hard to test
[16:08:01] <lynxlynxlynx> we should just port the iwd2 case everywhere
[16:08:12] <lynxlynxlynx> worst case / best case :)
[16:08:43] <fuzzie> :)
[16:09:10] <fuzzie> i think that's basically what the current code tries to do
[16:20:04] <CIA-25> GemRB: 03lynxlupodian * r5b482539e903 10gemrb/gemrb/GUIScripts/ (5 files in 5 dirs):
[16:20:05] <CIA-25> GemRB: Revert "moved all the ActionQItem*Pressed() duplicates into GUICommon"
[16:20:05] <CIA-25> GemRB: All need to be in the same module and most are in GUICommonWindows
[16:20:05] <CIA-25> GemRB: This reverts commit d862ff785c12a1e52668da00d12a803625f1e5b3.
[16:20:10] <CIA-25> GemRB: 03lynxlupodian * rcf032d6c896b 10gemrb/gemrb/GUIScripts/ (6 files in 6 dirs):
[16:20:10] <CIA-25> GemRB: moved a few Action*Pressed callbacks back into GUICommonWindows, so they
[16:20:10] <CIA-25> GemRB: are all accessible from the same module
[16:20:10] <CIA-25> GemRB: (maybe all the GUICommonWindows can be merged later)
[16:20:13] <CIA-25> GemRB: 03lynxlupodian * rf274e74c8190 10gemrb/gemrb/core/ (Actions.cpp Actor.cpp Game.cpp Interface.cpp): core: specify the module in most RunFunction calls
[16:33:53] --- Dark-Star|away is now known as Dark-Star
[16:52:49] --> Maighstir_laptop has joined #GemRb
[16:59:38] <-- budlust has left IRC (Remote host closed the connection)
[17:08:37] --> budlust has joined #GemRb
[17:15:26] <-- budlust has left IRC (Ping timeout: 265 seconds)
[17:17:08] --> budlust has joined #GemRb
[17:21:43] <-- budlust has left IRC (Ping timeout: 265 seconds)
[17:26:27] --> budlust has joined #GemRb
[17:41:28] <-- budlust has left IRC (Ping timeout: 245 seconds)
[17:42:08] <-- Maighstir_laptop has left IRC (Read error: Connection reset by peer)
[17:42:28] --> Maighstir_laptop has joined #GemRb
[17:52:33] --> budlust has joined #GemRb
[18:01:26] <tomprince> lynxlynxlynx: I could make StringCallback take a module. Or I could make Setup* take a module object, and get the functions from there.
[18:02:09] <tomprince> Also, it just occured to me, it might make sense for SetEventByName to resolve the name immedietly, rather than waiting for the call.
[18:02:26] <tomprince> It shouldn't make much difference, but with those two changes, StringCallback becomes unused.
[18:03:56] <lynxlynxlynx> either is fine for me
[18:04:15] <lynxlynxlynx> all of this setup happens in GUICommonWindows btw
[18:04:28] <tomprince> I think I'll do the latter then.
[18:04:35] <lynxlynxlynx> thanks
[18:04:40] <fuzzie> um
[18:04:47] <fuzzie> don't do that without making sure it works.
[18:05:10] <fuzzie> at a glance it looked like the bg1 chargen stuff depended on delayed resolution, i thought.
[18:05:12] <tomprince> About moving stuff back out of GUICommon ... you could do 'from GUICommon import balh'
[18:05:25] <fuzzie> and i stopped there so didn't review any of the rest.
[18:05:48] <tomprince> I'll look then. The Setup* should depend on that though.
[18:05:54] <fuzzie> no
[18:05:59] <fuzzie> just talking about SetEventByName
[18:06:26] <lynxlynxlynx> it would complicate the matter on the plugin side
[18:06:30] <fuzzie> i am fine with either of your first suggestions, since i would like to get rid of that code anyway
[18:06:55] <lynxlynxlynx> i diffed three gcws and it didn't look like much effort to merge them
[18:07:12] <tomprince> Of course, that would be even better. :)
[18:07:29] <fuzzie> i will do that when i have time if no-one else does. after keybindings, w/same disclaimer. :P
[18:08:55] <-- Maighstir_laptop has left IRC (Ping timeout: 252 seconds)
[18:12:43] <-- budlust has left IRC (Ping timeout: 245 seconds)
[18:20:32] <-- Gekz has left IRC (Read error: No route to host)
[18:20:59] --> Gekz has joined #GemRb
[18:37:58] --> budlust has joined #GemRb
[18:39:21] --> |Cable| has joined #GemRb
[18:46:50] <CIA-25> GemRB: 03tom.prince * r9792a560c88f 10gemrb/gemrb/plugins/GUIScript/PythonHelpers.cpp:
[18:46:50] <CIA-25> GemRB: GUIScript: More PyObject* NULL checks.
[18:46:50] <CIA-25> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:49:25] <tomprince> lynxlynxlnyx: or.cz/events
[18:50:31] <lynxlynxlynx> has only this last commit
[18:50:47] <tomprince> Forgot to commit. :)
[18:51:36] <tomprince> Should be there now.
[18:53:43] <lynxlynxlynx> can't you get the global dict from the the environment?
[18:53:59] <tomprince> What do you mean?
[18:54:12] <lynxlynxlynx> dict is always globals()
[18:55:02] <lynxlynxlynx> so why not get that in the c++ part
[18:55:14] <lynxlynxlynx> not possible?
[18:55:33] <tomprince> Well, I'd worry about it being too magic, but I'll have a look.
[18:55:51] <tomprince> Also, I hadn't considered it.
[18:55:51] <fuzzie> hm, the confusingness of that commit is certainly motivation to get rid of it all
[18:58:17] <fuzzie> seems silly to put so much work into it
[19:09:25] <tomprince> Supposedly, you can get globals() from c++ (or.cz/events2), but that code doesn't work.
[19:12:35] <fuzzie> the execution context is going to be the MetaClasses module if you do that, no?
[19:13:11] <fuzzie> if that
[19:13:40] <tomprince> Yes. That would do it.
[19:14:31] <fuzzie> i forget how to get the current PyFrameObject
[19:17:55] <fuzzie> oh, i just missed the function. seems like excessive work to fish the relevant frame out and then the dict though..
[19:18:22] <fuzzie> in python it's just inspect.currentframe().f_back.f_globals or something like that
[19:21:37] <tomprince> There is PyEval_GetFrame, but then you need to do PyObject_GetAttr(frame, "f_back") ... GetAttr(..., "f_globals")
[19:22:36] <fuzzie> i would consider that excessive work for something which should just be a temporary hack
[19:22:43] <tomprince> Yes.
[19:22:45] <fuzzie> but then, i'd just have hardcoded the module name in, because i am lazy :)
[19:24:58] <tomprince> :)
[19:25:27] <tomprince> lynxlynxlynx: ?
[19:26:09] <lynxlynxlynx> the shorter the diff, the better
[19:26:51] <lynxlynxlynx> the first version should be fine if it works
[19:28:09] <-- budlust has left IRC (Remote host closed the connection)
[19:29:03] --> budlust has joined #GemRb
[19:29:08] <tomprince> It does.
[19:29:56] <-- budlust has left IRC (Read error: Connection reset by peer)
[19:34:30] <CIA-25> GemRB: 03tom.prince * r77bd57b2549e 10gemrb/gemrb/ (5 files in 5 dirs):
[19:34:30] <CIA-25> GemRB: GUIScript: Make Setup*Icons functions take a dict to get the callbacks from.
[19:34:30] <CIA-25> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:39:21] <tomprince> or.cz/events gets rid of StringCallback.
[19:40:39] <tomprince> bg1 chargen seems to work. Although LUSpellSelection is missing CloseOtherWindow there.
[19:41:04] <fuzzie> that breaks, or just a code bug?
[19:41:08] <fuzzie> it was working fine a few months ago
[19:41:24] <tomprince> Although, that commit is probably useless when lynxlynxlynx gets done with removing SetEventByName.
[19:41:34] <tomprince> import bug, I'm sure.
[19:42:08] <lynxlynxlynx> yep
[19:43:30] <fuzzie> yeah, i figured we could just wait and get rid of SetEventByName entirely
[19:44:50] <lynxlynxlynx> i have it almost done for bg2
[19:45:02] <tomprince> One nice thing about getting rid of 'from ... import' is that reload should work at least slightly better from the console.
[19:45:25] <tomprince> Although there is perhaps more we could do if we wanted to support that.
[19:45:45] <fuzzie> well, not on my wishlist yet :)
[19:46:15] <fuzzie> did you have any fixed ideas about rearchitecting the GUI side?
[19:46:22] <tomprince> Me, no.
[19:47:52] <tomprince> I'd like someone who has experience with gui coding to weigh in.
[19:48:24] <tomprince> And I'd like to move all the GetControl(number) to config files, rather than in code.
[19:48:51] <tomprince> So we can say things like SaveWindow.SaveButton, or SaveWindow['SaveButton'].
[19:49:29] <lynxlynxlynx> i'm not sure it makes that much sense
[19:49:44] <lynxlynxlynx> sure there's some overlap, but there's enough of differences to make it annoying
[19:50:12] <fuzzie> well, it also makes it a lot more difficult to mess with
[19:50:23] <lynxlynxlynx> having dicts with the ids would be simpler
[19:50:28] <fuzzie> but 'experience with gui coding' encompasses rather a lot :)
[19:50:48] <fuzzie> i tried fiddling with some code which just took basically a big python dict and tried auto-constructing things
[19:50:52] <lynxlynxlynx> could be needed for more agressive merging
[19:50:57] <fuzzie> but it ended up more complicated than the procedural code
[19:51:02] <fuzzie> i wasn't thinking of merging, though
[19:51:14] <lynxlynxlynx> i wasn't thinking of autoconstructing :)
[19:51:53] <fuzzie> well, just having a lookup table for the game-specific ids is a very low-impact small-change thing which makes obvioussense :)
[19:53:17] <lynxlynxlynx> yep
[19:53:19] <tomprince> One vague thought I had, was that instead of loading a chu file, we had some other type of file, that has meaningful names for all the window and control ids, and populates dicts or something with the controls and windows.
[19:53:39] <fuzzie> but then you doubled the complexity
[19:53:50] <fuzzie> because now you have two sets of files to keep in sync
[19:53:57] <fuzzie> and i'm not sure that's worth the gain
[19:54:48] <fuzzie> while if you just put that directly into python-land, at least it's in the one place and you can just ignore the whole thing if it becomes a pain
[19:55:11] <tomprince> Well, we could design the format so that it could replace the chu files for new stuff.
[19:56:22] <tomprince> And the basic idea is really just your lookup table for game-specific ids.
[19:56:52] <lynxlynxlynx> you think too far ahead
[19:57:16] <fuzzie> well
[19:57:34] <fuzzie> the trouble is, if you want to do that, gemrb kinda has to be almost as good as the original engine first :)
[19:59:18] <tomprince> Well, I do always try and keep new games in mind when designing things.
[19:59:59] <fuzzie> well, i mean, a chu-replacing format would be fine for new games
[20:00:12] <fuzzie> all i mean is: it would be more work for old games.
[20:04:51] <tomprince> Work to get from here to there. But I think after that, I think it would be easier to work with.
[20:05:31] <fuzzie> n o
[20:05:36] <fuzzie> i mean, i think it would be more work overall.
[20:05:57] <fuzzie> the use case being "i have a chu file from some mod, and i want to make the python code cope with it".
[20:06:08] <fuzzie> as it is, it's just a bit of fiddling with python.
[20:08:39] <tomprince> Well, it would be another file to edit, but I think it would be clearer what is going on, rather than having all these magic constants.
[20:10:36] <fuzzie> but there's a middle ground between 'magic constants' and 'seperate new file format' :)
[20:11:15] <lynxlynxlynx> the separate would gain only for truly new content
[20:11:29] <lynxlynxlynx> but you'd have to have good tools for that and even more time
[20:11:49] <tomprince> Well, I think seperate file is important.
[20:12:09] <fuzzie> well, i think seperate file is a huge negative :)
[20:12:17] <tomprince> And even if that file is in python, you don't want it littered with GetWindow/GetControl calls.
[20:12:21] <fuzzie> i mean, that is the big difference here
[20:12:33] <tomprince> How do you support multiple games with different ids then?
[20:12:39] <fuzzie> i think you're kinda pushing a strawman argument here
[20:12:58] <fuzzie> where it's either seperate files or procedural calls for every single thing you want to do :)
[20:13:21] <lynxlynxlynx> if the games had identical guis, then it would make more sense
[20:13:31] <lynxlynxlynx> guis and strings
[20:16:53] <fuzzie> but the truth is that you're going to need customisation of the code all over the place anyway
[20:24:52] <CIA-25> GemRB: 03lynxlupodian * r7fd9c304c907 10gemrb/gemrb/GUIScripts/ (6 files in 6 dirs): added a few missing imports
[20:24:55] <CIA-25> GemRB: 03lynxlupodian * rc3ba9ff5777e 10gemrb/gemrb/plugins/TLKImporter/TlkOverride.cpp: fixed two noncolored TLKImporter error messages
[20:31:32] <lynxlynxlynx> i'm getting sloppy
[20:54:51] <lynxlynxlynx> almost done with the main bg2 stuff
[20:55:07] <lynxlynxlynx> ReturnToGame remains a problem though
[20:55:31] <lynxlynxlynx> if i leave it called by name, then the button doesn't work
[20:56:48] <lynxlynxlynx> eh, nevermind
[21:06:10] <CIA-25> GemRB: 03lynxlupodian * rfe5cfd234070 10gemrb/gemrb/GUIScripts/ (30 files in 2 dirs):
[21:06:10] <CIA-25> GemRB: bg2: complete the from-import removal;
[21:06:10] <CIA-25> GemRB: as a side effect, everything but cg was rid of SetEventByName
[21:06:15] <CIA-25> GemRB: 03lynxlupodian * r8addba2f4a0e 10gemrb/gemrb/GUIScripts/bg2/ (16 files): bg2: complete SetEventByName removal
[21:06:38] <lynxlynxlynx> finally
[21:19:41] <fuzzie> doesn't work
[21:20:19] <fuzzie> oh, hm
[21:20:47] <lynxlynxlynx> hm?
[21:20:50] <fuzzie> well
[21:21:06] <fuzzie> some of it is apparently my fault
[21:21:26] <fuzzie> and some of the rest is because the core is now calling functions in GUICommonWindows while we don't have a game running, and it doesn't expect that
[21:21:37] <lynxlynxlynx> keybinds don't work, that's the only thing i know about
[21:22:26] <lynxlynxlynx> yeah, those are harmless
[21:23:36] <fuzzie> the keybindings can stay broken while they're in C++
[21:24:00] <lynxlynxlynx> ah, found one
[21:24:06] <fuzzie> but MessageWindow has lost all the imports
[21:24:15] <lynxlynxlynx> yep :)
[21:24:17] <fuzzie> and obviously that breaks things
[21:24:29] <lynxlynxlynx> where?
[21:26:33] <fuzzie> you can no longer identify using items i think?
[21:27:02] <fuzzie> huh, is that just broken?
[21:27:11] <fuzzie> it is difficult to tell what is just plain broken
[21:28:18] <lynxlynxlynx> i didn't test identifying, but drinking works
[21:28:22] <fuzzie> let me try without my changes
[21:30:29] <fuzzie> some of this has been broken for a while
[21:31:26] <lynxlynxlynx> you tried the glasses of indentification?
[21:31:28] <fuzzie> yes, reverting quite a while has things still broken. meh.
[21:31:30] <CIA-25> GemRB: 03lynxlupodian * r24738c08df72 10gemrb/gemrb/GUIScripts/bg2/GUICommonWindows.py: bg2: shortcircuit SelectionChanged if there is no portrait window
[21:31:32] <CIA-25> GemRB: 03lynxlupodian * rc0db97bce0e4 10gemrb/gemrb/GUIScripts/bg2/GUIOPT9.py: bg2/GUIOPT9: added function stubs
[21:34:31] --> budlust has joined #GemRb
[21:34:38] <fuzzie> File "/home/fuzzie/src/gemrb/gemrb/GUIScripts/bg2/GUICommonWindows.py", line 227, in GroupControls
[21:34:41] <fuzzie> Button.SetEvent (IE_GUI_BUTTON_ON_PRESS, SelectFormation)
[21:34:44] <fuzzie> NameError: global name 'SelectFormation' is not defined
[21:35:50] <lynxlynxlynx> on it
[21:37:19] <CIA-25> GemRB: 03lynxlupodian * r69ccf0480288 10gemrb/gemrb/GUIScripts/bg2/GUICommonWindows.py: bg2: SelectFormation is in GUICommon
[21:41:24] <fuzzie> thanks
[21:41:51] <fuzzie> [GUIScript]: Missing callback function:FeedScroll
[21:41:57] <fuzzie> so textscreens don't work
[21:42:22] <fuzzie> ReplayTextScreen and EndTextScreen too, so you can't leave
[21:43:46] <fuzzie> oh, right, you made TextScreen shared
[21:44:30] --> raevol has joined #GemRb
[21:44:40] <fuzzie> well, that is a bit of a showstopper :)
[21:44:51] <fuzzie> but i keep finding other bugs anyway
[21:48:02] <fuzzie> has the travel screen always been this broken?
[21:48:05] <fuzzie> i can barely go anywhere
[21:48:17] <fuzzie> but no-one touched it recently
[21:50:03] <lynxlynxlynx> i'll look into the textscreen, haven't tested either recently
[21:51:28] <fuzzie> it seems a well-done change in general
[21:51:35] <fuzzie> always going to have overlooked bugs
[21:52:33] <fuzzie> and now sleep for me
[22:07:13] <-- budlust has left IRC (Ping timeout: 264 seconds)
[22:12:25] <CIA-25> GemRB: 03lynxlupodian * rf027086ccb3b 10gemrb/gemrb/GUIScripts/TextScreen.py: TextScreen: don't use SetEventByName
[22:13:22] <lynxlynxlynx> i don't see any change in the travel screen
[22:19:30] <fuzzie> sorry, like i said, no-one touched it recently
[22:19:34] <fuzzie> not since last year
[22:19:48] <fuzzie> i'm just wondering why some of my savegames don't let me go anywhere
[22:22:20] <lynxlynxlynx> they're probably too old
[22:22:28] <fuzzie> i mean, original savegames
[22:22:37] <lynxlynxlynx> oh
[22:22:54] <lynxlynxlynx> and why are you not asleep? :P
[22:33:04] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:57:12] --- Dark-Star is now known as Dark-Star|away
[23:55:29] --> Gekz_ has joined #GemRb