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

Archive Today Yesterday Tomorrow
GemRB homepage

[02:52:21] <-- tomprince_loki has left IRC (Ping timeout: 265 seconds)
[03:44:45] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[06:45:08] <-- |Cable| has left IRC (Remote host closed the connection)
[07:03:16] --> pupnik has joined #GemRb
[07:11:07] --> budlust has joined #GemRb
[07:38:08] --> Maighstir_laptop has joined #GemRb
[07:55:54] <edheldil> Hi all
[08:02:44] <budlust> hi!
[08:04:35] --> lynxlynxlynx has joined #GemRb
[08:04:36] --- ChanServ gives channel operator status to lynxlynxlynx
[08:14:14] <Maighstir_laptop> morning
[08:27:53] <lynxlynxlynx> oj
[09:07:58] <CIA-23> GemRB: 03lynxlupodian * rc1e481644c05 10gemrb/gemrb/GUIScripts/bg2/ (7 files): bg2: removed a few unneeded imports
[09:08:02] <CIA-23> GemRB: 03lynxlupodian * r8a9254dce46c 10gemrb/gemrb/GUIScripts/iwd/ (CharGen.py GUICommonWindows.py PartyFormation.py): iwd: fixed a few missed table lookups and one missing function
[09:10:55] <edheldil> lynxlynxlynx: you know that in modern python (2.5 and later, I think) you can do "import a.b.c as c", right? :)
[09:11:39] <lynxlynxlynx> i don't think it would help here
[09:16:54] <fuzzie> we're still claiming to support 2.2 or something
[09:18:52] <fuzzie> also g'morning
[09:23:21] <lynxlynxlynx> 2.3
[09:29:49] <edheldil> pah
[09:42:08] <-- Maighstir_laptop has left IRC (Ping timeout: 276 seconds)
[09:57:01] <fuzzie> well, the README in my tree says 2.2 :)
[10:04:52] --> muni_ has joined #GemRb
[10:52:40] <edheldil> what platforms don't have at least python 2.5? Windows? some ARM phone?
[10:53:25] <edheldil> or Mac?
[11:00:03] <-- budlust has left IRC (Read error: Operation timed out)
[11:26:09] --> budlust has joined #GemRb
[12:00:26] <pupnik> edheldil: nokia n800, n900 have python 2.5 - dunno the rest
[12:11:36] <-- raevol has left IRC (Quit: Leaving.)
[12:22:40] <-- lynxlynxlynx has left IRC (Ping timeout: 265 seconds)
[12:29:56] --> lynxlynxlynx has joined #GemRb
[12:29:56] --- ChanServ gives channel operator status to lynxlynxlynx
[12:33:23] <lynxlynxlynx> geez
[12:33:39] <lynxlynxlynx> gemrb got OOM killed
[12:34:05] <lynxlynxlynx> [CREImporter]: Unknown creature signature.
[12:34:07] <lynxlynxlynx> [Streams]: Invalid seek
[12:34:31] <lynxlynxlynx> and then just a normal message from the audio thread, but the mem leak was already in effect
[12:36:02] <lynxlynxlynx> i'm guessing it was the 2.1 format
[12:36:17] <lynxlynxlynx> shouldn't the importer just abort there instead?
[12:40:18] --> Maighstir_laptop has joined #GemRb
[12:42:39] <lynxlynxlynx> looks like EffectsOffset was unitited
[12:43:04] <Maighstir_laptop> Python 2.5 supports at least Windows 98, don't know about 95 or NT4, 2.6 works on 2000, XP and up
[12:44:30] <lynxlynxlynx> let's see if this works
[12:44:52] <lynxlynxlynx> cool, a segfault instead :)
[12:46:44] <lynxlynxlynx> 255 as the cre signature :s
[12:54:55] <lynxlynxlynx> ugh, returning null there requires plenty of other checks in other functions
[13:11:23] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[13:18:34] --> kettuz has joined #GemRb
[14:06:30] <-- budlust has left IRC (Ping timeout: 265 seconds)
[14:15:40] <CIA-23> GemRB: 03lynxlupodian * r5049728bdf29 10gemrb/gemrb/GUIScripts/iwd2/ (50 files): iwd2: clean up imports and switch to using direct python fallbacks
[14:18:56] <CIA-23> GemRB: 03lynxlupodian * rc29307863d79 10gemrb/gemrb/GUIScripts/GUICommon.py: shortcircuit IsDualClassed and IsMultiClassed for iwd2
[14:18:58] <CIA-23> GemRB: 03lynxlupodian * rd033d2e6130e 10gemrb/gemrb/GUIScripts/iwd/GUICommonWindows.py: iwd: SelectFormationPreset is from the same file
[14:19:43] --> budlust has joined #GemRb
[14:22:10] --> |Cable| has joined #GemRb
[14:24:30] <fuzzie> lynxlynxlynx: is it a good idea to return NULL there?
[14:24:57] <-- budlust has left IRC (Ping timeout: 265 seconds)
[14:25:42] <lynxlynxlynx> it depends
[14:26:02] <lynxlynxlynx> it creates a crash instead of a big resource hog
[14:26:33] <fuzzie> well, i mean, why an invalid cre?
[14:26:43] <lynxlynxlynx> spreading more null checks around got me ingame, but no area was loaded, so things started crashing elsewhere
[14:26:46] <fuzzie> seems like abort() would be a more sensible tactic
[14:30:48] <lynxlynxlynx> yes
[14:30:48] <fuzzie> i am finally done with difficult exams for a while
[14:32:05] <lynxlynxlynx> cool
[14:33:38] --> budlust has joined #GemRb
[14:33:54] <fuzzie> and i'm sure there's no problem with python 2.5
[14:34:10] <fuzzie> just saying someone should update the README :)
[14:34:35] <CIA-23> GemRB: 03lynxlupodian * rf995a0ee942f 10gemrb/gemrb/plugins/CREImporter/CREImporter.cpp:
[14:34:35] <CIA-23> GemRB: CREImporter::GetActor: abort on invalid CREVersion, avoiding a massive
[14:34:35] <CIA-23> GemRB: memory leak
[14:39:00] <-- budlust has left IRC (Read error: Operation timed out)
[14:55:09] --> budlust has joined #GemRb
[15:09:19] --> Maighstir_laptop has joined #GemRb
[15:15:42] <-- budlust has left IRC (Ping timeout: 265 seconds)
[15:25:19] --> budlust has joined #GemRb
[15:44:47] <-- muni_ has left IRC (Quit: Leaving)
[16:36:55] --> kjkjh has joined #GemRb
[16:38:21] <-- budlust has left IRC (Ping timeout: 265 seconds)
[16:43:34] --> budlust has joined #GemRb
[16:43:59] <-- kjkjh has left IRC (Ping timeout: 276 seconds)
[16:59:56] <tomprince> lynxlynxlynx: Shoud the 4 remaining SetEventByName in iwd2/Enemy.py really be SetEvent?
[17:01:59] <fuzzie> is Enemy.py used?
[17:03:27] <tomprince> Doesn't look like it.
[17:03:32] <fuzzie> atm it doesn't look like it, meaning someone'd have to fix that before testing it
[17:07:13] <fuzzie> can't work out where that got broken
[17:07:16] <-- budlust has left IRC (Quit: Konversation terminated!)
[17:07:34] --> budlust has joined #GemRb
[17:07:41] <fuzzie> oh, right, lynx didn't quite complete the commit
[17:08:23] <fuzzie> it's thus missing starting in 57233eb1, after the old code was refactored
[17:09:44] <fuzzie> so patch #1984907, which i guess was broken?
[17:10:10] <fuzzie> and notes that these silly CharGenX.py files are useless
[17:10:30] <fuzzie> so someone should probably fix that first, will add it to the todo list
[17:10:56] <-- kettuz has left IRC (Quit: Leaving)
[17:13:05] <tomprince> Well, I think the SetEventByName simply got missed in the automatic conversion.
[17:13:23] <fuzzie> lynx is only changing what he can test, afaik
[17:13:53] <fuzzie> with the intention of the rest going into a branch
[17:14:20] <tomprince> Well, he touched those lines, dropping ". I would just change it myself, but I didn't want to step on his toes.
[17:14:52] <tomprince> And if it is never called, whoever starts it being called again will have to test it. Be easier if there is calls to a function that was dropped in the mean time.
[17:14:55] <fuzzie> oh, i see
[17:15:05] <fuzzie> well
[17:15:41] <fuzzie> i don't think it's a good idea to start refactoring/dropping things without testing the callers just because they happened to get broken
[17:16:07] <fuzzie> i know this already happened with pst stores, and it makes things rather more painful
[17:16:54] <fuzzie> because whoever fixes the code has to worry about fixing the problem *and* whatever got changed from underneath it without testing
[17:17:17] <fuzzie> but as you say, lynx does seem to have made a mistake there, pretty sure you might as well go ahead and commit a fix
[17:17:39] <fuzzie> it obviously doesn't make much sense this way..
[17:18:27] <fuzzie> so either it needs the change or it needs reverted entirely, and you making an intermediate commit seems like it's not going to do harm
[17:19:15] <CIA-23> GemRB: 03tom.prince * r941487de7be7 10gemrb/gemrb/GUIScripts/iwd2/Enemy.py:
[17:19:15] <CIA-23> GemRB: GUIScript/iwd2: Change missed SetEventByName -> SetEvent.
[17:19:15] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[17:29:17] <fuzzie> i'm not quite sure how to test the filter changes
[17:30:00] <fuzzie> i'll play some of the more complex scenes, i guess
[17:33:10] <fuzzie> the stupid CloseContinueWindow hack in the core is no longer working, it needs a module?
[17:34:39] <fuzzie> ok, something certainly broke
[17:34:51] <fuzzie> some dialog trigger
[17:40:35] <fuzzie> ok, so those patches are no good as-is
[17:42:08] <fuzzie> but i'm not convinced the old code was correct
[17:42:51] <fuzzie> well, pretty sure it wasn't, actually. hum.
[17:43:41] <fuzzie> tomprince: why not assert(func) in the "Move reporting of unknown object field selector to load" one?
[17:44:47] <fuzzie> if you removed the printf then i guess you covered all the input paths, so idtargets[j] should always be valid there?
[17:46:20] <fuzzie> just wondering if i missed a case; otherwise it seems like a harmless patch, good to apply
[17:50:13] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[17:50:17] <fuzzie> i'll have to work out what the correct behaviour is for the second one, but not right now
[18:03:47] <fuzzie> damn, it really is that last patch breaking everything
[18:04:06] <fuzzie> and tweaking the single behaviour-changed check i see isn't helping
[18:04:27] <fuzzie> good to know it's nothing in the dialog trigger changes, i guess
[18:19:22] <-- budlust has left IRC (Ping timeout: 265 seconds)
[18:22:19] <tomprince> It could also come from IniSpawn::SpawnCreature, and a couple of other places.
[18:26:08] <fuzzie> ah. that is annoying.
[18:27:51] <fuzzie> is there anything else i should be reviewing?
[18:35:33] <tomprince> Looking at the branches I have lying around: the gettile branch ... how should we handle multiple primary animations, when there is a secondary animation.
[18:38:34] --> budlust has joined #GemRb
[18:39:01] <tomprince> The only other things are listbox and command stuff. Both of which are wip, but could do with comments.
[18:46:38] <fuzzie> well, the listbox design you have seems both simple and to work well
[18:47:04] <fuzzie> although i have not tried seeing if it actually works, or why you noted it has problems at init
[18:55:25] <tomprince> I just defaults to the top, rather than the bottom, if I rember correctly.
[19:28:08] --> Maighstir_laptop has joined #GemRb
[19:49:14] <-- budlust has left IRC (Ping timeout: 276 seconds)
[20:03:19] --> budlust has joined #GemRb
[20:43:04] <-- Gekz has left IRC (Quit: Leaving)
[20:50:03] --> raevol has joined #GemRb
[20:50:17] <lynxlynxlynx> yeah, i forgot to include the file in the file list
[20:51:20] <fuzzie> i'll have to set original iwd2 up on a Windows install and have a poke around and see how it's all meant to work
[20:51:29] <lynxlynxlynx> meaning only some operations got applied to it
[20:51:32] <fuzzie> don't suppose you have any thoughts about merging the code for stores? :)
[20:51:57] <lynxlynxlynx> i don't know how much they differ
[20:52:14] <fuzzie> well, iwd2/pst stores just aren't implemented
[20:52:29] <fuzzie> there was some work, but it's all completely broken/reverted/regressed since, useless
[20:53:21] <fuzzie> so i am wondering whether i can avoid writing all the code for them both
[20:54:01] <tomprince> I am working on merging Save/Load.
[20:54:31] <fuzzie> would be interested to see that
[20:54:38] <fuzzie> although it is a lot easier, not much of the logic is different i hope?
[20:54:49] <tomprince> About all the same.
[20:55:11] <tomprince> Is there any reason the confirmdelete in bg2 hides the save window?
[20:55:16] <fuzzie> but i guess the portrait numbers will be candidates for modding
[20:57:21] <fuzzie> i have no idea; i take it the original engine doesn't do that?
[20:57:38] <fuzzie> the bg2 save GUI had some nasty windowing bugs in it, i remember
[20:57:57] <fuzzie> i still don't think i worked them out, i just fiddled with it enough until it stopped obviously breaking
[20:58:02] <tomprince> Don't know, but it makes the loading screen appear behind, with the box offset. form the loading circle.
[20:58:11] <fuzzie> but looks like the invisible code is from a long time ago
[20:58:59] <tomprince> Related question: can I load the confirm window, and set labels and things in GUISAVE.OnLoad, nad then just show it when I need it?
[21:01:06] <-- budlust has left IRC (Ping timeout: 260 seconds)
[21:03:52] <lynxlynxlynx> as long as it works
[21:04:33] <lynxlynxlynx> like it was already said, the code is ancient and that behaviour probably unintentiona
[21:38:20] <tomprince> I was wondering why my refactored deletion code wasn't working ... and it turns out the directories I was trying to delete were write protected. :)
[21:56:18] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:30:35] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[23:22:18] <-- raevol has left IRC (Quit: Leaving.)