[01:14:44] <-- tombhadAC has left IRC (Read error: 145 (Connection timed out))
[01:24:16] --> tombhadAC has joined #gemrb
[06:05:14] --> Gekz_ has joined #GemRB
[06:07:07] --> Gekz` has joined #GemRB
[06:21:14] <-- Gekz` has left IRC (Read error: 104 (Connection reset by peer))
[06:22:09] <-- Gekz has left IRC (Read error: 110 (Connection timed out))
[06:22:10] --> Gekz` has joined #GemRB
[06:27:07] <-- Gekz_ has left IRC (Connection timed out)
[06:28:17] --> Gekz_ has joined #GemRB
[06:31:20] --> lynxlynxlynx has joined #gemrb
[06:31:20] --- ChanServ gives channel operator status to lynxlynxlynx
[06:45:20] <-- |Cable| has left IRC ("Leaving")
[06:55:50] <-- Gekz_ has left IRC (Connection timed out)
[06:56:16] --> Gekz_ has joined #GemRB
[06:58:49] <-- Gekz` has left IRC (Connection timed out)
[07:23:03] --> pupnik_ has joined #gemrb
[07:39:07] <-- pupnik has left IRC (Read error: 110 (Connection timed out))
[08:19:40] <lynxlynxlynx> The big news this month is that GDB v7.0 is about to be released.
[08:20:20] <fuzzie> i wonder if the C++ support will be any less awful
[08:20:34] <lynxlynxlynx> http://nickclifton.livejournal.com/3883.html
[08:20:46] <lynxlynxlynx> esrever
[08:21:33] <fuzzie> the 'inlined functions' bit sounds hopeful
[08:22:25] <lynxlynxlynx> the python thing is very powerful, a lot of the internals are exposed
[09:39:40] <wjp> reverse debugging also sounds very cool
[11:28:14] <lynxlynxlynx> hmpf
[11:28:42] <lynxlynxlynx> i can't unlock a chest, but i have the correct key
[11:30:13] <lynxlynxlynx> maybe it got screwed up, since i picked it open a long time ago
[11:30:37] <fuzzie> Oh.
[11:30:41] <fuzzie> Containers can be locked?
[11:31:59] <lynxlynxlynx> of course?
[11:32:26] <fuzzie> I don't think I implemented keys for those. :/
[11:32:46] <fuzzie> indeed, UseContainer seems to just give up if the container is locked
[11:32:57] <lynxlynxlynx> ah
[11:33:31] <lynxlynxlynx> should be a quick copy/paste job, no?
[11:34:17] <fuzzie> it would be nicer to refactor my TryUnlockDoor into something higher-level
[11:35:00] <fuzzie> Highlightable::TryUnlock(Actor *actor, bool removekey) maybe
[11:35:51] <fuzzie> and then Door::TryUnlockDoor can call that, and Container::TryUnlockContainer would then just be a copy of that with removekey always false?
[11:36:00] <fuzzie> i could do it, but if you have a test case, maybe easier for you..
[11:37:35] <lynxlynxlynx> i'm working on something else now
[11:37:49] <lynxlynxlynx> while i should be working on something else
[11:37:53] <fuzzie> heh
[11:37:55] <lynxlynxlynx> i can test the changes
[11:37:58] <fuzzie> ok
[11:45:32] <CIA-22> gemrb: 03lynxlupodian * r7281 10/gemrb/trunk/gemrb/GUIScripts/ (bg1/GUISTORE.py iwd/GUISTORE.py): don't allow selling to temples in iwd and bg1 either
[11:49:10] <CIA-22> gemrb: 03fuzzie * r7282 10/gemrb/trunk/gemrb/plugins/Core/ (Actions.cpp ActorBlock.cpp ActorBlock.h): move TryUnlock code into Highlightable, call it from UseContainer too
[11:49:43] <fuzzie> i can't test that from here, but it built!
[11:50:48] <pupnik_> :)
[11:52:36] <lynxlynxlynx> let's see
[11:53:48] <lynxlynxlynx> works
[11:54:39] <lynxlynxlynx> crash
[11:55:53] <lynxlynxlynx> shouldn't be moving things to actors in other areas
[11:56:44] <fuzzie> non-related crash?
[11:57:05] <lynxlynxlynx> yes
[12:37:30] --- pupnik_ is now known as pupnik
[13:30:16] <-- tombhadAC has left IRC ("Verlassend")
[13:30:55] --> tombhadAC has joined #gemrb
[13:58:04] --> Maighstir has joined #gemrb
[13:59:25] <Maighstir> I'd like to report on a false bug in the bg1 playthrough section on the wiki: With Montaron dead, removing Xzar from the party does not remove Montaron's portrait. I'm not sure what the expected behavior is here.
[13:59:47] <Maighstir> That's the behaviour in vanilla BG1 (and TosC)
[14:00:06] <Maighstir> any pair can be split in that way
[14:00:28] <Maighstir> "pair" being: Montaron+Xzar, Minsc+Dynaheir, Jaheira+Khalid, Skie+Eldoth, and maybe some others
[14:19:02] <lynxlynxlynx> ok
[14:20:00] <lynxlynxlynx> i added a note
[14:20:09] <lynxlynxlynx> are you trying bg1 out too?
[14:21:34] <Maighstir> Not really, I just noticed that on the wiki and thought that was the original behaviour... tried it out to confirm in non-gemrb bg1, and found out i was right
[14:22:19] <Maighstir> and I like helping out where I can
[14:22:25] <lynxlynxlynx> sure, thanks
[14:22:38] <lynxlynxlynx> you can make an account on the wiki and add notes yourself
[14:23:49] <Maighstir> I can?... ooh, I can!
[14:54:35] <fuzzie> and we'd be grateful for it :)
[15:13:33] <Maighstir> one question though, since my wiki-searching-fu fails me: what's the status of png support? portraits in override can be png, but what else?
[15:14:08] <Maighstir> could the mos files be switched for png as well? (since they are not animations, but sinply static graphics) would make it a little bit easier making a new game (something me and a couple of friends are trying to do).
[15:15:34] <fuzzie> looks like we don't handle that right now, but i think it would be trivial to add
[15:18:37] <Maighstir> though what definitely does elude me is the bam files... how would I make new such files? either I don't understand the tool I've found (bam workshop), or it doesn't work that well
[15:19:15] <Maighstir> of course, this isn't significant for supporting the existing games, but it is for making new datasets
[15:19:17] <fuzzie> hm, i guess BAM Workshop is from the teambg days
[15:19:27] <Maighstir> yeah
[15:19:28] <fuzzie> i personally use DLTCEP, but there is likely something better
[15:19:35] <Maighstir> so what's the tool to use nowadays?
[15:19:40] <Maighstir> ah, ok
[15:20:45] <fuzzie> DLTCEP is kind of the 'official' gemrb modding/editing tool because it's in our svn repository and it's kept up-to-date with support for new gemrb features, as long as you're happy with a Windows tool
[15:20:59] <Maighstir> yeah, I'm on windows
[15:21:35] <lynxlynxlynx> bam is just a glorified bmp
[15:21:54] <Maighstir> I haven't gotten that deep into the tool though... will be digging more, thanks
[15:22:04] <fuzzie> but you might find something like http://www.shsforums.net/index.php?showtopic=42359 more useful if you're doing a lot of editing
[15:23:08] <Maighstir> bam has the frames and animation sets (or whatever they're called) though, so it's more than just bmp
[15:24:39] <lynxlynxlynx> yeah
[15:26:52] <CIA-22> gemrb: 03lynxlupodian * r7283 10/gemrb/trunk/gemrb/GUIScripts/ (GUICommon.py bg2/GUIINV.py iwd/GUIINV.py): synced iwd and bg2 guiinv (UpdateInventorySlot goodness) and shared another function
[15:39:41] <CIA-22> gemrb: 03lynxlupodian * r7284 10/gemrb/trunk/gemrb/GUIScripts/ (8 files in 5 dirs): made pdolls global
[16:01:45] <lynxlynxlynx> slow svn is slow
[16:25:08] <lynxlynxlynx> meh
[16:27:35] --> zefklop has joined #gemrb
[16:30:40] <fuzzie> hi zefklop
[16:30:58] <zefklop> hi fuzzie
[16:32:06] <CIA-22> gemrb: 03lynxlupodian * r7285 10/gemrb/trunk/gemrb/GUIScripts/iwd/GUIWORLD.py: iwd: more UpdateInventorySlot goodness
[17:06:12] --> Avenger has joined #gemrb
[17:06:18] --- ChanServ gives channel operator status to Avenger
[17:06:22] <Avenger> hey
[17:06:59] <Avenger> lynx, now i see the how avatar animation code, i found some new slots
[17:07:57] <Avenger> one is definitely absent from any lists: 0xeb52 is used with the MFIR animation, but there is no MFIR*.BAM resource so, it is never used
[17:09:12] <Avenger> i also see how MANI/MAN2/MAN3 are used, they are actually in the right order: 0xeb0*-mani, 0xeb1*-man2, 0xeb2*-man3
[17:09:53] <lynxlynxlynx> cool
[17:12:01] <Avenger> i don't quite see why they made efforts to split the 0xeb5* animations
[17:12:16] <Avenger> usually the last digit is masked out
[17:12:43] <Avenger> we don't do that, we can have only exact matches
[17:14:25] <Avenger> ops, another unused animation: 0xeb8* MMAN
[17:14:43] <Avenger> manticore ?
[17:17:06] <lynxlynxlynx> don't remember one
[17:17:18] <lynxlynxlynx> but it has been a while since i played iwd
[17:18:57] <lynxlynxlynx> or should i say, i haven't seen one so far
[17:19:06] <Avenger> there is no MMAN animation in the game
[17:19:15] <Avenger> it is just supported by the engine
[17:19:21] <Avenger> a kind of hole :)
[17:19:34] <Avenger> i didn't know there are free slots in iwd
[17:20:36] <Avenger> probably this is discovered by someone else, so we gotta support it, it is cheap
[17:31:07] <lynxlynxlynx> hmm, do we hardcode the distance the chars need to be from a portal to use it?
[17:31:29] <lynxlynxlynx> i can't go through one as nobody can get close enough
[17:36:45] <fuzzie> well, i guess it's an infopoint? i think we do
[17:37:06] <lynxlynxlynx> it is
[17:37:15] <Avenger> i think they use range scripted, no?
[17:37:15] <pupnik> i think this is a bit more complicated than xu4
[17:37:50] <lynxlynxlynx> it has no script assigned
[17:38:01] <Avenger> is it a pst portal?
[17:38:05] <lynxlynxlynx> iwd
[17:38:11] <fuzzie> how is it going to work if there's no script assigned?
[17:38:14] <lynxlynxlynx> Travel Region to6003
[17:38:15] <fuzzie> it's a travel trigger?
[17:38:17] <fuzzie> ah
[17:38:29] * Avenger says ah too...
[17:38:47] <Avenger> well, travel triggers got some max_travel_distance
[17:39:30] <fuzzie> i thought gemrb had no codepath for using travel triggers unless you stood on them
[17:40:04] <fuzzie> ah
[17:40:08] <fuzzie> i may have sabotaged this code
[17:40:45] <fuzzie> hm, no, i deliberately left it working for ST_TRAVEL
[17:41:01] <fuzzie> it checks MAX_OPERATING_DISTANCE, anyway
[17:41:19] <fuzzie> ActorBlock.cpp:1977 i would guess?
[17:41:38] <lynxlynxlynx> i'll try with increasing the constant
[17:41:58] <fuzzie> increasing the constant is maybe a disaster, given how much it's used
[17:42:10] <lynxlynxlynx> i'll bisect to the minimum that works
[17:46:14] <lynxlynxlynx> huh, double didn't help
[17:46:23] <lynxlynxlynx> the infopoint is active btw
[17:48:04] <fuzzie> add a debug print in that Entered check, maybe
[17:48:14] <lynxlynxlynx> i'm right in it
[17:48:20] <lynxlynxlynx> the PersonalDistance check passed
[17:48:59] <lynxlynxlynx> TRAP_USEPOINT is not in Flags, so it ends up just returning false
[17:49:08] <fuzzie> if you get that far then you probably got to Map::UseExit?
[17:49:27] <lynxlynxlynx> Map::UpdateScripts
[17:49:31] <Avenger> then how travel triggers would work elsewhere :)
[17:49:59] <fuzzie> i mean, if Entered is called, then it should get as far as calling UseExit, so you should peer there
[17:50:23] <fuzzie> TRAP_USEPOINT shouldn't get checked
[17:50:50] <lynxlynxlynx> it gets checked since this is a ST_TRAVEL Type
[17:50:58] <fuzzie> i mean, if the PersonalDistance check on 1977 passes..
[17:51:12] <lynxlynxlynx> but the Type doesn't
[17:51:22] <fuzzie> it's 'Type != ST_PROXIMITY', which is true for ST_TRAVEL
[17:51:32] <lynxlynxlynx> ups :)
[17:51:58] <lynxlynxlynx> i don't know what i was thinking
[17:52:08] <lynxlynxlynx> personal distance is 136 for this one
[17:52:47] <fuzzie> the problem is maybe: it checks distance to Pos, not to the trigger
[17:53:09] <fuzzie> and i think Pos is calculated by the ARE loader to be the centre of the bounding box, which is not very useful if it's large?
[17:53:30] <lynxlynxlynx> it's not that large
[17:54:20] <fuzzie> well, or if it's inaccessible..
[17:55:09] <lynxlynxlynx> trying to find the point
[17:56:06] <lynxlynxlynx> it's a human height away from the standpoint
[17:56:37] <lynxlynxlynx> don't know how that translates to hundredsomething
[17:57:20] <fuzzie> what's the area name? where's the portal?
[17:58:03] <lynxlynxlynx> ar6002
[17:58:10] <lynxlynxlynx> monitor north
[17:58:21] <lynxlynxlynx> ctrl-shift-y
[17:59:31] <fuzzie> i wonder if we're meant to obey the 'launch point', which is at the front
[18:00:04] <fuzzie> for now i would add a check for ST_TRAVEL which checks the distance to 'TrapLaunch'
[18:00:26] <fuzzie> and at least see if that works
[18:07:06] <lynxlynxlynx> trying
[18:25:30] <lynxlynxlynx> yeah, worked
[18:32:32] <fuzzie> that is maybe a better replacement for that hack wrapped in Type != ST_PROXIMITY
[18:32:59] <fuzzie> maybe add a comment noting i said that, add a comment that the test case is north-east in ar6002, and commit?
[18:39:13] <-- Avenger has left IRC ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]")
[18:43:41] <lynxlynxlynx> ok
[18:47:29] <CIA-22> gemrb: 03lynxlupodian * r7286 10/gemrb/trunk/gemrb/plugins/Core/ActorBlock.cpp: changed a check in InfoPoint::Entered to fix an iwd exit
[18:50:14] <fuzzie> now we'll hope it doesn't cause disasters, i guess :) much further through iwd?
[18:51:51] <lynxlynxlynx> a bit
[19:03:45] <-- Gekz_ has left IRC (Read error: 54 (Connection reset by peer))
[19:07:57] --> Gekz has joined #GemRB
[19:11:57] <CIA-22> gemrb: 03avenger_teambg * r7287 10/gemrb/trunk/gemrb/override/ (how/avatars.2da iwd/avatars.2da): added some avatar anims supported by the original game (only MSEE is actually existing)
[19:35:05] <Edheldil> good night
[19:35:09] <-- Edheldil has left IRC ("Really?")
[19:46:45] <lynxlynxlynx> crash on lich
[19:51:02] <lynxlynxlynx> heh, missing avatar
[19:53:44] --> |Cable| has joined #gemrb
[20:03:08] <fuzzie> can you make that a nice error?
[20:03:43] <lynxlynxlynx> i thought it was, but maybe it doesn't get reached
[20:04:43] <lynxlynxlynx> this lich fight is pretty tough
[20:06:25] <lynxlynxlynx> they keep casting hopelessness and only one party member is immune
[20:16:42] <lynxlynxlynx> and they never run out heh
[20:18:36] <CIA-22> gemrb: 03lynxlupodian * r7288 10/gemrb/trunk/gemrb/override/ (how/avatars.2da iwd/avatars.2da): added a missing iwd avatar: greater mummy
[20:32:41] <CIA-22> gemrb: 03lynxlupodian * r7289 10/gemrb/trunk/gemrb/plugins/Core/Actor.cpp: use the long name for combat feedback
[21:06:24] <lynxlynxlynx> hmpf, another blocker
[21:07:01] <lynxlynxlynx> one area is supposed to change when you finish a quest to reveal a container with a critical item (besides the graphics)
[21:08:22] <lynxlynxlynx> i only see a var getting set though
[21:09:15] <lynxlynxlynx> ugh
[21:09:30] <lynxlynxlynx> another var is Forge_On and it matches in the exe
[21:10:37] <lynxlynxlynx> FORGE_ONar6004
[21:10:50] <lynxlynxlynx> that's the area it is in
[21:36:24] --- Maighstir is now known as Maighstir_
[21:36:42] --- Maighstir_ is now known as Maighstir
[21:37:11] <lynxlynxlynx> maybe its an internal (proto) version of LeaveAreaLUA
[21:39:47] <lynxlynxlynx> but how has that, at least if action.ids is to be believed
[21:40:14] <lynxlynxlynx> i didn't find a replacement area though
[21:40:36] <lynxlynxlynx> this is how the tree of life fountain stairs in bg2 work
[21:53:44] <fuzzie> is the container in the area?
[21:54:04] <lynxlynxlynx> nope
[21:54:44] <lynxlynxlynx> there's an infopoint there, but i guess it gets demolished
[21:55:39] <-- zefklop has left IRC ("Page closed")
[21:56:14] <fuzzie> the forge info one?
[21:56:20] <lynxlynxlynx> yes
[21:56:37] <fuzzie> hum.
[21:56:42] <lynxlynxlynx> http://www.gamebanshee.com/icewinddale/walkthrough/thegreatforge.php <-- here's the after image
[21:59:04] <fuzzie> well, that page is labelled AR0613, which seems to have the container
[21:59:38] <lynxlynxlynx> i have no such area
[21:59:47] <lynxlynxlynx> they start at 1000 here
[21:59:56] <fuzzie> erm, 6013, sorry
[22:00:48] <lynxlynxlynx> nice
[22:00:58] <lynxlynxlynx> i only looked at the 600x
[22:01:33] <lynxlynxlynx> heh
[22:01:45] <lynxlynxlynx> FORGE_ONar6004 -> AR6013FORGE_ONar6004
[22:01:52] <fuzzie> :)
[22:02:22] <fuzzie> (ack, why hardcode such things in the .exe? :()
[22:03:10] <fuzzie> i wonder what it does, just switching some exit destinations?
[22:04:07] <lynxlynxlynx> no, the exits stay the same, at least the forward (top) ones
[22:04:09] <fuzzie> ar6011 seems to have an exit both to ar6004 and to ar6013, in the same place (well, three pixels away)
[22:04:16] <lynxlynxlynx> you get a key in that receptivle
[22:04:28] <fuzzie> same for the other connected area, ar6005
[22:04:38] <fuzzie> it has every exit duplicated, one for 6004 and one for 6013
[22:05:42] <fuzzie> so my guess would be: the engine is hardcoded to ignore exits based on whether the var is set?
[22:07:31] <lynxlynxlynx> sounds like a reasonable guess
[22:09:33] <fuzzie> hm, i should really read more forums
[22:09:50] <fuzzie> a bunch of iwd stuff is already documented on the G3 iwd-to-bg2 forum
[22:10:09] <fuzzie> since they ran across all these issues already, i guess, like the auto-setting of the _Visited vars
[22:11:09] <lynxlynxlynx> the forum is still down
[22:11:32] <lynxlynxlynx> ack, it's tommorow already
[22:11:36] <fuzzie> yes, i use the google cache :)
[22:11:37] <lynxlynxlynx> good night
[22:11:38] <fuzzie> night
[22:11:55] <-- lynxlynxlynx has left IRC (Remote closed the connection)
[23:18:54] <-- tombhadAC has left IRC ("Verlassend")