#gemrb@irc.freenode.net logs for 26 Aug 2009 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:02:03] <-- Enverex has left IRC (Remote closed the connection)
[01:40:14] <-- tombhadAC has left IRC ("Verlassend")
[05:56:32] --> Avenger has joined #gemrb
[05:56:39] --- ChanServ gives channel operator status to Avenger
[06:02:47] --> Gekz has joined #GemRB
[06:36:04] --> Gekz_ has joined #GemRB
[06:37:08] --> Gekz` has joined #GemRB
[06:40:15] <-- Gekz_ has left IRC (Nick collision from services.)
[06:40:17] <-- Gekz has left IRC (Nick collision from services.)
[06:40:56] --- Gekz` is now known as Gekz
[06:52:38] --> Gekz_ has joined #GemRB
[06:52:42] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[07:06:41] <-- Avenger has left IRC ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]")
[07:12:08] <-- Gekz_ has left IRC (Connection timed out)
[07:20:16] --> Gekz has joined #GemRB
[07:44:22] <-- |Cable| has left IRC (Remote closed the connection)
[08:09:46] --> lynxlynxlynx has joined #gemrb
[08:09:46] --- ChanServ gives channel operator status to lynxlynxlynx
[08:13:31] <lynxlynxlynx> moo
[08:18:00] <fuzzie> hey
[08:19:40] <lynxlynxlynx> i haven't started playing yet, but i realised yesterday that the clab thing is perhaps not a regression
[08:20:01] <lynxlynxlynx> in the first run i had 100% mr, so i always resisted magic
[08:49:22] <CIA-22> gemrb: 03lynxlupodian * r7053 10/gemrb/trunk/gemrb/plugins/Core/Actions.cpp: added feedback for getting one's map updated
[09:22:28] <lynxlynxlynx> 6852 is bad for both, the polymorph crashes and the dispel already works
[09:28:06] <pupnik_> you created a 100% magic resistant character? for bg2? how?
[09:31:20] <lynxlynxlynx> same for 6550
[09:31:33] <lynxlynxlynx> pupnik_: i cheated
[09:32:00] <lynxlynxlynx> highlevel monk = level*3 mr; then a cloak with +25% and a ring +10%
[09:32:06] <-- Gekz has left IRC (Connection timed out)
[09:32:54] <pupnik_> ohhh
[09:44:17] --> Gekz has joined #GemRB
[09:57:18] <lynxlynxlynx> the clab dispel issue is not a regression (or not a recent one), it happens in 6052 too
[10:08:46] <lynxlynxlynx> finally found a good revision for the weapons
[10:24:09] <lynxlynxlynx> Bisecting: 5 revisions left to test after this (roughly 3 steps)
[10:35:14] --> barraAway has joined #gemrb
[10:36:07] --- barraAway is now known as barra_library
[10:46:25] <lynxlynxlynx> bleh, not a clean revert
[11:07:15] --> barraAway has joined #gemrb
[11:12:45] <-- barra_library has left IRC (Read error: 60 (Operation timed out))
[11:18:42] --> barra_away has joined #gemrb
[11:25:47] --> barra__out has joined #gemrb
[11:30:03] <-- barra_away has left IRC (Read error: 60 (Operation timed out))
[11:34:51] --> barra_away has joined #gemrb
[11:36:50] <-- barraAway has left IRC (Read error: 110 (Connection timed out))
[11:37:11] <lynxlynxlynx> i must've botched up the revert, but a manual check confirms that 6938 is the cause of the regression
[11:39:22] --> barraAway has joined #gemrb
[11:42:00] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[11:42:07] --> Gekz has joined #GemRB
[11:43:18] <fuzzie> that commit really screws with the formatting in EffectQueue, weird
[11:43:37] <lynxlynxlynx> that too
[11:43:48] <lynxlynxlynx> use -w and some of it will go away
[11:44:16] <lynxlynxlynx> "some"
[11:44:23] <lynxlynxlynx> navaden@lynxlynx git-gemrb 0 $ git show -w 4dc25eb8077d09d1623f7f53d701f9fd529b888c | wc -l
[11:44:25] <lynxlynxlynx> 237
[11:44:26] <lynxlynxlynx> navaden@lynxlynx git-gemrb 0 $ git show 4dc25eb8077d09d1623f7f53d701f9fd529b888c | wc -l
[11:44:27] <lynxlynxlynx> 1492
[11:44:51] <-- barra_away has left IRC (Read error: 60 (Operation timed out))
[11:49:10] --> barra_away has joined #gemrb
[11:54:08] <-- barra__out has left IRC (Success)
[11:54:45] --> barra__out has joined #gemrb
[11:55:11] <lynxlynxlynx> it is broken since the script now doesn't remove the slayer item you get equipped in the magic slot
[12:02:23] <-- raevol has left IRC (Read error: 104 (Connection reset by peer))
[12:03:20] <-- barra__out has left IRC (Read error: 60 (Operation timed out))
[12:04:15] --> barra__out has joined #gemrb
[12:06:34] <-- barraAway has left IRC (Connection timed out)
[12:06:59] <Gekz> my eeepc was stolen today
[12:07:05] <Gekz> this gives me massive amounts of sad face
[12:07:50] <-- barra_away has left IRC (Read error: 110 (Connection timed out))
[12:10:04] --> barraAway has joined #gemrb
[12:12:19] --> barra_away has joined #gemrb
[12:13:52] --> raevol has joined #GemRB
[12:17:06] <pupnik_> eant mine gekz?
[12:17:09] <pupnik_> want
[12:17:16] <pupnik_> is broken tho
[12:17:24] <Gekz> how broken
[12:17:35] <pupnik_> maybe components you can use acer aspire one
[12:17:47] <pupnik_> dont turn on
[12:18:36] <Gekz> sounds rather useless to me
[12:18:37] <Gekz> no thanks lol
[12:25:01] <lynxlynxlynx> i don't see where b1-20m4 is removed (the weapon created by the change)
[12:25:10] <lynxlynxlynx> dltcep doesn't find it anywhere else
[12:25:43] <lynxlynxlynx> maybe they destroy the magic slot explicitly (iirc we do that too somewhere)
[12:25:45] <-- barra_away has left IRC (Read error: 60 (Operation timed out))
[12:26:26] --> barra_away has joined #gemrb
[12:30:03] <-- barraAway has left IRC (Connection timed out)
[12:32:35] <-- barra__out has left IRC (Connection timed out)
[12:33:12] --> barraAway has joined #gemrb
[12:34:26] <lynxlynxlynx> in fx_polymorph, no less :)
[12:39:00] <-- barra_away has left IRC (Read error: 60 (Operation timed out))
[12:41:36] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[12:42:07] --> Gekz has joined #GemRB
[12:43:09] <-- barraAway has left IRC (Read error: 60 (Operation timed out))
[12:43:28] <lynxlynxlynx> yep, it happens on polymorph expiry
[12:43:44] --> barraAway has joined #gemrb
[12:43:55] <lynxlynxlynx> commenting out the new "if( fx->TimingMode == FX_DURATION_INSTANT_LIMITED) fx->TimingMode = FX_DURATION_ABSOLUTE;" fixes it
[12:50:10] --> barra_away has joined #gemrb
[12:57:51] --> barra__out has joined #gemrb
[13:01:48] <-- barra_away has left IRC (Connection timed out)
[13:02:22] --> barra_away has joined #gemrb
[13:03:23] <-- barraAway has left IRC (Read error: 110 (Connection timed out))
[13:03:53] --> barraAway has joined #gemrb
[13:05:45] <-- barra__out has left IRC (Read error: 60 (Operation timed out))
[13:06:35] --> barra__out has joined #gemrb
[13:23:22] <-- barra_away has left IRC (Read error: 110 (Connection timed out))
[13:23:54] --> barra_away has joined #gemrb
[13:24:40] <-- barra__out has left IRC (Read error: 110 (Connection timed out))
[13:24:43] <fuzzie> hm
[13:25:53] --> barra__out has joined #gemrb
[13:27:03] <-- barraAway has left IRC (Read error: 110 (Connection timed out))
[13:28:43] --> barraAway has joined #gemrb
[13:37:24] <-- barraAway has left IRC (Read error: 145 (Connection timed out))
[13:42:52] <-- barra_away has left IRC (Read error: 110 (Connection timed out))
[13:42:54] --> barra_library has joined #gemrb
[13:45:17] <-- barra__out has left IRC (Read error: 110 (Connection timed out))
[13:51:20] --> barra_away has joined #gemrb
[13:54:21] --> Avenger has joined #gemrb
[13:54:24] --- ChanServ gives channel operator status to Avenger
[13:56:16] <lynxlynxlynx> ojla
[13:57:27] <lynxlynxlynx> the backlog is for you
[13:57:39] --> barra__out has joined #gemrb
[13:58:09] <Avenger> which part?
[13:59:04] <Avenger> if you meant the timing mode, then i don't quite see how it could affect the master object
[14:01:19] <lynxlynxlynx> in the end it does
[14:01:55] <lynxlynxlynx> could be that commenting that out just disables some other code that is at fault
[14:02:23] <lynxlynxlynx> part of that commit definitely caused a regression
[14:03:33] <lynxlynxlynx> whatever happens, the destroy item part in fx_polymorph isn't reached or isn't reached in a reasonable time
[14:03:41] <lynxlynxlynx> resting doesn't help
[14:04:27] <fuzzie> it doesn't look as if you should ever be reaching that fx_polymorph RemoveItem bit, isn't it only used on failure?
[14:06:29] <Avenger> i cannot look at it now
[14:07:11] <lynxlynxlynx> i think that's the only place that we remove the magic weapon
[14:07:11] <lynxlynxlynx> i'll go break it
[14:07:18] <Avenger> only a screenful of nonliving actions to go :)
[14:07:22] <Avenger> cracked the message system too
[14:07:42] <Avenger> now i can see what's going deep inside
[14:07:44] <fuzzie> so did you work out what clearactions does? :)
[14:07:55] <-- barra_library has left IRC (Read error: 110 (Connection timed out))
[14:07:56] <Avenger> i didn't try
[14:08:04] <Avenger> i looked into how doors work ;)
[14:08:13] <fuzzie> less interesting :)
[14:08:13] <Avenger> with all the creaking, trap reset, etc
[14:08:33] <Avenger> well, it is good to find attributes
[14:08:35] <fuzzie> i guess you can spend years working out exactly how everything works in the original
[14:08:46] <fuzzie> but it would be nice to have the data structures documented
[14:09:34] <-- barra__out has left IRC (Read error: 60 (Operation timed out))
[14:09:35] <Avenger> so far i didn't find too much new about the structures, but i just took a glance. understanding the message system is important
[14:09:55] <fuzzie> yes
[14:10:13] <Avenger> its purpose is mostly for multiplaying
[14:10:38] <fuzzie> well, i don't think we need a message system yet
[14:10:39] <Avenger> most of the time, it sets an attribute, then sends a message with the purpose of setting that attribute too
[14:10:52] <Avenger> so, i think it is just to synchronise the machines
[14:11:09] <fuzzie> but i thought there were some actions which only sent a message :)
[14:11:15] <Avenger> yes
[14:11:22] <Avenger> something happens only through messages
[14:11:29] <fuzzie> so i would love to hear about that
[14:12:10] <Avenger> i found some message that didn't make much sense, it seemed to send a callback to itself :) but deep inside there was a flag to break out :)
[14:12:14] <fuzzie> but i am also interested in clearactions because i think it gives clues to the last action bits
[14:12:25] <fuzzie> but anyway i have to be gone all day
[14:12:28] <Avenger> looks like they got infinite loops, hehe
[14:12:53] <Avenger> well, i can take a peek again
[14:13:02] <Avenger> now that i won't stop at the send message call :)
[14:13:37] <Avenger> though i prefer 'simpler' things, like copygroundpiles :)
[14:14:26] <lynxlynxlynx> ah, another effect removes the item
[14:15:07] <-- barra_away has left IRC (Read error: 110 (Connection timed out))
[14:15:48] <lynxlynxlynx> fx_create_magic_item schedules a fx_remove_item
[14:15:56] <lynxlynxlynx> but only if (fx->TimingMode==FX_DURATION_INSTANT_LIMITED)
[14:16:27] <lynxlynxlynx> so i was right
[14:16:59] <Avenger> it should be fx->TimingMode&0xff
[14:17:05] <Avenger> or also the absolute mode
[14:17:13] <lynxlynxlynx> ok, let me try that
[14:17:45] <Avenger> but when calculating the duration, it should handle the two modes differntly
[14:18:29] <fuzzie> it doesn't calculate the duration there
[14:18:34] <fuzzie> it just modifies itself
[14:18:42] <fuzzie> so i think it's fine, since that's after any PrepareDuration call
[14:20:00] <Avenger> well, then it could be chanced to duration_absolute outside
[14:20:06] <Avenger> changed
[14:20:27] <Avenger> hopefully, the timing mode is changed to delayed?
[14:20:34] <lynxlynxlynx> FX_DURATION_DELAY_PERMANENT
[14:21:33] <lynxlynxlynx> worked :D
[14:21:38] --> pupnik has joined #gemrb
[14:21:58] <Avenger> i can imagine this stuff bleeding all over
[14:22:10] <Avenger> the absolute timing mode was only recently added
[14:22:23] <lynxlynxlynx> it was the only thing i noticed during the runthrough
[14:22:37] <Avenger> i didn't know it exist, because it was hidden by the editor and no one documented it
[14:23:18] <CIA-22> gemrb: 03lynxlupodian * r7054 10/gemrb/trunk/gemrb/plugins/FXOpcodes/FXOpc.cpp: fixed a timing check in fx_create_magic_item, thanks Avenger
[14:23:34] <Avenger> heh, thanks me :) i didn't do much
[14:23:51] <lynxlynxlynx> true, you /just/ provided the fix
[14:24:16] <Avenger> ok fuzzie, i'm in the outskirts of clearactions. There is a message call when the object is nonzero
[14:25:22] <Avenger> this one is very nasty, first i didn't even realize it builds a message struct :)
[14:25:53] <lynxlynxlynx> dispel magic ignores mr by design, no wonder it is problematic
[14:27:43] <lynxlynxlynx> there are 4 more hits for checks of plain TimingMode against FX_DURATION_INSTANT_LIMITED
[14:29:27] <Avenger> I don't know how balrog found out this 'scriptable' type. The IE has a very similar setup. A flag marks objects which are scriptable. So, their GetActorFromObject can return animations or spawnpoints too. Those don't have the scriptable flag, though.
[14:30:07] <Avenger> clearactions works only scriptables, of course :)
[14:31:15] <lynxlynxlynx> is it just me or is the duration check in fx_create_item_in_slot inverted?
[14:31:40] <lynxlynxlynx> the other hits are the same as the one i already fixed, all are item creators
[14:36:44] <Avenger> meh i hate dynamic call addresses
[14:37:05] <Avenger> this clearactions message just vanishes in a hole :)
[14:37:50] <-- pupnik_ has left IRC (Read error: 110 (Connection timed out))
[14:39:48] <Avenger> fuzzie: initiating a dialog calles clearactions, does that make sense?
[14:40:09] <Avenger> i just put a breakpoint into that message :)
[14:40:28] <fuzzie> well, i don't know what clearactions does.
[14:40:52] <fuzzie> so it is difficult to say :)
[14:40:58] <Avenger> wipes the queue, i guess
[14:41:11] <fuzzie> the message bit does that?
[14:41:17] <Avenger> yes
[14:41:25] <fuzzie> it would make sense if it's delayed-action
[14:41:48] <Avenger> clearactions sends a message, and the message calls into a virtual function in their 'scriptable' object
[14:42:00] <fuzzie> it definitely doesn't do that right away, though
[14:42:03] <Avenger> dialog calls into the same function
[14:42:05] <fuzzie> so there's got to be something delaying it
[14:42:22] <Avenger> well,i don't know how these messages are processed
[14:42:26] <fuzzie> same for dialog, the queue is still processed after the dialog action
[14:42:38] <fuzzie> so i am not really convinced that clearactions wipes the queue.
[14:42:40] <Avenger> it could be that on a single player game there is no asynchronicity
[14:42:56] <Avenger> well, i follow into it :)
[14:43:11] <fuzzie> if you do 'displaymessage', 'clearactions' and then 'displaymessage' on a non-living, both messages are shown.
[14:43:28] <fuzzie> and living scripts often do 'clearactions' at the start, so i doubt it is just a queue wipe.
[14:44:37] <Avenger> oh cool i can even tell who is 'clearactioned' :)
[14:44:38] <CIA-22> gemrb: 03lynxlupodian * r7055 10/gemrb/trunk/gemrb/plugins/FXOpcodes/FXOpc.cpp: fixed some other effect timings
[14:44:52] <Avenger> it is the one with the faldorn portrait, hehe, that's aargh ;)
[14:45:16] <Avenger> so, this clearaction event could be simply issued by clicking on the gui
[14:45:27] <Avenger> not necessarily by the dialog action
[14:45:37] <Avenger> lemme see if i click around without dialog
[14:45:49] <fuzzie> well, they've got to send a message when the gui does ClearActions
[14:45:54] <fuzzie> otherwise the multiplayer sync won't work
[14:46:31] <fuzzie> but the dialog action definitely doesn't ClearActions immediately, it's got to be delayed in some way if it happens at all
[14:46:31] <Avenger> simple moving around didn't send the message
[14:46:57] <Avenger> 'attacking' a trapdoor did
[14:47:02] <fuzzie> but i think the message is more likely something like "stop doing modal actions"
[14:47:16] <fuzzie> because it surely doesn't wipe the queue, from what i tested
[14:47:31] <fuzzie> but if it works on non-living then there must be more to it :)
[14:47:34] <Avenger> hmm, so you say clearactions just stops the modal state?
[14:47:44] <fuzzie> i say: i ask Avenger what it does
[14:47:57] <Avenger> well it would help if i already disassembled the modal state action and such
[14:48:21] <Avenger> i think i ran too ahead here
[14:48:26] <fuzzie> ok :)
[14:49:02] <Avenger> anyway, this virtual method (of an actor) is small
[14:57:45] <lynxlynxlynx> ok, fixed the dispel issue
[14:58:11] <lynxlynxlynx> of the 103 effects now only PauseTarget got wiped, instead of some 70
[14:58:39] <fuzzie> :)
[14:58:45] <lynxlynxlynx> http://pastebin.com/d272a438c <-- any objections?
[15:06:14] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[15:12:27] <Avenger> what are you doing there?
[15:13:06] <lynxlynxlynx> don't remove permanent or equipped effects on dispel
[15:13:11] <lynxlynxlynx> if( ((*f)->TimingMode&0xff) == FX_DURATION_INSTANT_PERMANENT ||
[15:13:16] <lynxlynxlynx> and the other permanents
[15:13:29] <lynxlynxlynx> in EffectQueue::RemoveLevelEffects
[15:14:16] <Avenger> permanents should be removable
[15:14:41] <Avenger> no this is wrong
[15:15:02] <Avenger> completely :)
[15:15:29] <lynxlynxlynx> at least the equipped ones shouldn't be?
[15:15:41] <lynxlynxlynx> and if this is wrong, how to fix it properly?
[15:16:32] <Avenger> if an effect is dispellable, it is removed
[15:16:52] <Avenger> regardless if its an equipped effect
[15:17:19] <Avenger> the problem is more like this: if( !(*f)->Resistance&FX_CAN_DISPEL) {
[15:17:31] <Avenger> that seems awful :)
[15:17:47] <Avenger> operator precedence is one, i think :)
[15:17:59] <Avenger> shouldn't it be !(...) ?
[15:18:19] <Avenger> but even then, i think fx_can_dispel shouldn't be a bit comparation
[15:18:35] <Avenger> it could be that of the 4 possible values, only one is dispellable
[15:18:41] <Avenger> not sure, though
[15:19:01] <Avenger> anyway, i would use more parentheses in that line
[15:19:04] <lynxlynxlynx> FX_CAN_DISPEL is defined so we don't have to compare all of them it seems
[15:19:39] <Avenger> ! is stronger than &, and that would cause big trouble, no?
[15:19:46] <lynxlynxlynx> yep
[15:20:03] <Avenger> it would never do continue, that means it would never skip an effect
[15:20:39] <lynxlynxlynx> works :)
[15:20:46] <lynxlynxlynx> even that pause is preserved
[15:21:03] <Avenger> so with parentheses it is better?
[15:21:12] <lynxlynxlynx> yes
[15:21:24] <Avenger> ok, good, i didn't like your patch at all :)
[15:21:26] <lynxlynxlynx> must try some dispellable effect now
[15:21:42] <Avenger> mirror image is surely dispellable
[15:21:54] <lynxlynxlynx> it's a monk
[15:21:57] <lynxlynxlynx> potion time
[15:22:14] <Avenger> make sure the dispel level is high enough
[15:22:23] <Avenger> though i'm sure we suck at that too
[15:22:40] <lynxlynxlynx> it's a temple, it probably has some absurdly high value
[15:22:49] <Avenger> ok, i'm back to my actions :)
[15:25:45] <lynxlynxlynx> yep, works
[15:27:03] <CIA-22> gemrb: 03lynxlupodian * r7056 10/gemrb/trunk/gemrb/plugins/Core/EffectQueue.cpp: fear dispel no more!
[15:27:03] --> pupnik_ has joined #gemrb
[15:37:30] <-- pupnik has left IRC (Read error: 110 (Connection timed out))
[15:51:59] --> barra_away has joined #gemrb
[15:54:29] <Avenger> hehe the layhands action positively doesn't work ;)
[15:54:47] <Avenger> it parses the target, then simply returns success :)
[15:55:20] <Avenger> i see a big TODO here :)
[15:56:10] <lynxlynxlynx> is it used at all?
[15:56:14] <lynxlynxlynx> the effect works
[15:56:24] <lynxlynxlynx> well, there is no effect, it just cures
[15:56:29] <Avenger> this is an action
[15:56:45] <Avenger> but anyone scripting layhands sucks :)
[15:57:11] <lynxlynxlynx> from fuzzie's script dump, only one match
[15:57:13] <lynxlynxlynx> scripts/iwd2/63phaenc.baf: LayHands(Myself)
[15:57:15] <Avenger> the spell probably works, but the gui doesn't use this action for sure
[15:57:25] <Avenger> well that's iwd2
[15:57:31] <Avenger> they might have implemented it
[15:57:43] <lynxlynxlynx> checked bg1, bg2, pst
[15:57:58] <Avenger> that script dump is useful :)
[15:58:07] <lynxlynxlynx> also bg1 and bg2 dialogs don't have it
[16:00:16] --> barra__out has joined #gemrb
[16:10:12] <-- barra__out has left IRC (Read error: 60 (Operation timed out))
[16:17:53] <-- barra_away has left IRC (Success)
[16:21:05] <CIA-22> gemrb: 03lynxlupodian * r7057 10/gemrb/trunk/gemrb/GUIScripts/bg2/GUISTORE.py: bg2: don't allow selling to temples
[16:33:10] --> barra_library has joined #gemrb
[16:38:16] --> barra_away has joined #gemrb
[16:41:57] --> D_T_G has joined #gemrb
[16:42:12] <lynxlynxlynx> oj
[16:42:18] <D_T_G> hi
[16:42:42] <lynxlynxlynx> D_T_G: if you're past the kit stuff already, i have a more practical task for you, if you want
[16:43:15] <D_T_G> not yet
[16:43:33] <D_T_G> preselecting and remarking on scroll need to be done
[16:43:51] <D_T_G> but what would it be?
[16:43:52] <D_T_G> the task
[16:46:44] <lynxlynxlynx> charisma price modifier
[16:47:16] <D_T_G> oh
[16:47:18] <lynxlynxlynx> more important than those cosmetics ;)
[16:47:34] <D_T_G> would be more visible ingame indeed
[16:47:56] <lynxlynxlynx> we already parse the table and it is accessible from the core, so you don't even need to load it
[16:48:14] <lynxlynxlynx> shops don't care about charisma. GemRB.GetAbilityBonus reads the table already, but isn't used. <-- this is what i put on the todo
[16:48:39] <lynxlynxlynx> http://iesdp.gibberlings3.net/files/2da/2da_tob/chrmodst.htm <-- the table
[16:48:52] <lynxlynxlynx> GUISTORE.py is the file
[16:49:36] <D_T_G> pretty big script
[16:50:38] <D_T_G> the numbers in 2da define percentage?
[16:51:18] <lynxlynxlynx> yes
[16:51:45] <lynxlynxlynx> the script is for all kinds of stores
[16:52:11] <lynxlynxlynx> code folding helps, but it is easy to get out the buy/sell bits
[16:52:12] <Avenger> stores, shops, bags, temples, what else ?
[16:52:21] <lynxlynxlynx> you could also grep for Price
[16:52:51] <lynxlynxlynx> apparently there are two other types for containers
[16:53:21] <lynxlynxlynx> and tavern and inn are separate (i guess one is just for rumors and sleep)
[16:54:00] <D_T_G> hm, maybe but not today, my holidays are reaching end too sadly
[16:54:02] <Avenger> actually there are overlaps
[16:54:14] <-- barra_library has left IRC (Read error: 110 (Connection timed out))
[16:54:23] <lynxlynxlynx> there's no hurry
[16:56:19] <lynxlynxlynx> we'll probably have a new release tommorow :)
[16:56:52] <-- barra_away has left IRC (Read error: 110 (Connection timed out))
[16:57:05] <D_T_G> will there be windows/mac builds?
[16:57:14] <lynxlynxlynx> not from me
[16:57:32] <lynxlynxlynx> zefklop will probably do the win one
[16:57:47] <D_T_G> i think if there will be in the day of release more people would try
[16:58:36] <lynxlynxlynx> if they are following releases via sf, they'll get notified separately for each file
[17:00:54] <D_T_G> the zenit of interest is the day of official release, if there is no build most people tend to forget about it and do not wait for build, it's my observation on polish forum
[17:02:29] <lynxlynxlynx> too bad
[17:06:55] <D_T_G> the main feature is "SoA finishable", right :)
[17:07:20] <lynxlynxlynx> yep
[17:07:48] <lynxlynxlynx> didn't try a normal party play yet though
[17:08:13] <lynxlynxlynx> and it definitely isn't near bugfree yet
[17:08:18] <D_T_G> today i got a crash in gemrb
[17:08:29] <lynxlynxlynx> reproducible?
[17:08:33] <D_T_G> yes
[17:08:37] <D_T_G> with familar
[17:08:54] <D_T_G> a minute
[17:12:35] <D_T_G> http://img98.imageshack.us/i/gemrb1h.jpg/
[17:12:47] <D_T_G> here, when trying to join the team with familar
[17:13:10] <D_T_G> SIGSEGV
[17:13:52] <lynxlynxlynx> original save huh
[17:14:09] <D_T_G> yes, original save
[17:14:13] <lynxlynxlynx> without a backtrace or a save it doesn't help much
[17:14:15] <D_T_G> know issue?
[17:14:43] <D_T_G> the console output is not verbose on that
[17:14:49] <lynxlynxlynx> i doubt anyone took familiars for long walks
[17:16:41] <D_T_G> i must go, bye
[17:16:45] <-- D_T_G has left IRC ()
[17:48:50] --> barra_library has joined #gemrb
[17:52:19] <-- barra_library has left IRC (Client Quit)
[18:42:36] --> barra_library has joined #gemrb
[19:11:46] --> |Cable| has joined #gemrb
[19:19:10] --- barra_library is now known as barra_home
[19:28:18] --> tombhadAC has joined #gemrb
[19:51:40] --- barra_home is now known as superfluid
[19:52:13] --- superfluid is now known as barra_home
[20:18:30] --> Edheldil has joined #gemrb
[20:18:30] --- ChanServ gives channel operator status to Edheldil
[20:19:17] <Edheldil> oi!
[20:19:31] <lynxlynxlynx> oj
[20:27:58] <Avenger> lo
[20:42:25] <lynxlynxlynx> Avenger: do you know where in the spell is the info that it is a hostile spell or not?
[20:42:41] <Avenger> yes
[20:42:59] <Avenger> there is a bitfield
[20:43:14] <Avenger> the same which has the simplified duration in it
[20:43:29] <Avenger> it should already be defined
[20:43:54] <Avenger> there are other ways for a spell to be hostile
[20:44:01] <Avenger> the damage opcode is always hostile
[20:44:44] <Avenger> actually, now i'm able to see how it happens
[20:44:59] <Avenger> i'm pretty sure it is a message, with a send trigger 'AttackedBy' :)
[20:46:16] <lynxlynxlynx> i'm thinking this is the way bg2 magic resistance works
[20:46:45] <lynxlynxlynx> you can't resist your own potions, healing spells or bufs
[20:46:52] <Avenger> hmm, the damage opcode sends a 'TookDamage' trigger to the target, but that's not hostile
[20:47:21] <Avenger> yes, there is some check if the damage is own damage or coming from outside
[20:47:40] <Avenger> so it is surely checked in other effects as well
[20:47:43] <Avenger> globally too
[20:47:50] <Avenger> but this is engine specific
[20:48:04] <lynxlynxlynx> iwd2 is probably doing it similar
[20:48:10] <Avenger> in iwd1 magic resistance disables healing :)
[20:48:18] <lynxlynxlynx> maybe not in how
[20:48:19] <Avenger> at least, it did once
[20:48:26] <Avenger> maybe that was a bug, actually
[20:48:30] <lynxlynxlynx> we'll definitely need a gameflag, but that is the trivial part
[20:50:22] <Avenger> ok i found a curious message, it is sent by: damage opcode, death opcode, attack action :)
[20:50:42] <Avenger> sounds like this is what makes something hostile
[20:51:45] <lynxlynxlynx> indeed
[20:52:58] <lynxlynxlynx> ah, we have a define for the spell flags: SF_HOSTILE
[20:57:03] <Avenger> i told you
[20:57:26] <lynxlynxlynx> yes, but i didn't find it in a blink
[20:57:40] <Avenger> eventually i will be able to see how it is done, exactly
[20:58:07] <Avenger> i learned a lot in the past few days :)
[21:01:18] <lynxlynxlynx> :)
[21:02:01] <lynxlynxlynx> looks like we only need to populate the SourceFlags and the mr check will be easy
[21:12:31] <Avenger> i got bad news for fuzzie, hehe.
[21:13:07] <Avenger> the message sent by clearactions is something also sent by: death, petrification, replaceself :)
[21:13:16] <Avenger> sounds like it is a queue wipe, whatever she says
[21:13:36] <Avenger> modal actions on the other hand, don't do it
[21:14:23] <Avenger> ahh clearallactions does it too
[21:14:28] <lynxlynxlynx> your scripts keep running while you're imprisoned?
[21:23:19] <Avenger> i don't know
[21:23:39] <Avenger> if the protagonist gets imprisoned, it is game over in the original game
[21:24:07] <Avenger> it removes the actor from team, and puts it in the area, hidden
[21:24:07] <lynxlynxlynx> mhm
[21:24:22] <Avenger> i don't know more about it
[21:27:23] <Avenger> hah, nice, i just read the script loop
[21:27:40] <Avenger> it is where it decides if your scripts are run or not :)
[21:27:41] <lynxlynxlynx> pretty similar to getting killed
[21:27:49] <fuzzie> Avenger: i just say, the clearactions action does not clear the queue immediately
[21:27:53] <fuzzie> i would like to know how that works
[21:27:57] <Avenger> so far: held stat, caster pause, and stoned/frozen death
[21:28:07] <fuzzie> whether we just have to delay it, or some other cleverness
[21:28:23] <fuzzie> also, please tell me whether fadetocolor is blocking
[21:28:30] <fuzzie> people keep on telling me that it is, i don't believe them :)
[21:29:21] <lynxlynxlynx> when it was, the ch2 cutscenes were broken
[21:29:30] <lynxlynxlynx> so i support your claim fuzzie :)
[21:30:53] <lynxlynxlynx> and clearactions is somewhere in between too, something didn't work until we changed it to be instant instead of what it was before
[21:31:08] <fuzzie> well, i don't think it should be instant
[21:31:18] <fuzzie> but it also definitely doesn't clear the queue
[21:31:24] <Avenger> fadetocolor not pausing will break IWD
[21:31:27] <fuzzie> gemrb doesn't even check for an object parameter
[21:31:30] <Avenger> got iwd, fuzzie?
[21:31:32] <fuzzie> Avenger: yes
[21:31:40] <Avenger> the part where the avalanche starts
[21:31:45] <fuzzie> i already broke fadetocolor in gemrb a long time ago
[21:31:56] <fuzzie> because pst, bg1, bg2 all depend on it not blocking
[21:31:56] <Avenger> you talk to hrothgar, and start on the journey
[21:32:15] <Avenger> i remember that was the reason i changed it
[21:32:16] <fuzzie> but i would like you to confirm in bg2 exe please :)
[21:32:26] <Avenger> meh, in bg2 it is not pausing
[21:32:32] <Avenger> i see that already
[21:32:43] <fuzzie> did you check the iwd exe?
[21:32:51] <Avenger> O_O
[21:32:52] <fuzzie> because a lot of times where people say "this is surely blocking", they miss something else
[21:32:54] <Avenger> no :)
[21:33:00] <fuzzie> i'll check it, tomorrow
[21:33:06] <fuzzie> also, does playsound block in bg2?
[21:33:11] <Avenger> no
[21:33:44] <Avenger> but some of the displaystringheads wait, i think
[21:33:47] <fuzzie> ok, i'm going to go through and replace all this stuff after the release then
[21:33:55] <fuzzie> yes, i think there's specifically a wait version of those?
[21:34:11] <Avenger> hmm, yeah, maybe that's it
[21:34:20] <lynxlynxlynx> so what version should we release? :)
[21:34:22] <Avenger> i didn't reach those yet :)
[21:34:25] <Avenger> 0.5.5
[21:34:26] <fuzzie> yes, DisplayStringWait
[21:34:42] <Avenger> your speed walkthrough is not really convincing :)
[21:34:55] <fuzzie> i am happy with 0.5.1, if lynx finds it better
[21:35:09] <Avenger> well, thats fine to me as well
[21:35:23] <lynxlynxlynx> ok, .1 it is
[21:36:07] <Avenger> the pocket plane now works back and forth, right?
[21:36:08] <fuzzie> i think the monk thing is a great idea, though
[21:36:12] <fuzzie> we should check more paths
[21:36:20] <fuzzie> i don't think anyone checked ToB recently :)
[21:36:26] <Avenger> i did when i added it
[21:36:28] <lynxlynxlynx> i arrived succesfully
[21:36:32] <lynxlynxlynx> yesterday
[21:36:36] <Avenger> but i like independent checks
[21:36:40] <Avenger> not the first arrival
[21:36:43] <Avenger> that doesn't count
[21:36:52] <Avenger> the first arrival to pp, and then to saradush is scripted
[21:37:06] <lynxlynxlynx> the movetoexpansion hack needs to change the worldmap or the saves will be bad, but going to the pp went just fine
[21:37:08] <Avenger> go to saradush, then to pocketplane, and back to saradush
[21:37:16] <fuzzie> Avenger: if you could make a list of actions which are blocking or not blocking in bg2, it would be very nice to have
[21:37:33] <Avenger> it is not yet finished fuzzie
[21:37:38] <Avenger> but i worked on it
[21:37:44] <fuzzie> sure, i don't expect results for weeks
[21:37:45] <lynxlynxlynx> i haven't tried the move2pp innate in a while, but it worked before
[21:37:45] <Avenger> i made a list of possible return values
[21:37:47] <fuzzie> or more :)
[21:38:09] <Avenger> return 1: stays on queue, return 0: not interruptable, return -1: end, return -2: error end
[21:38:35] <fuzzie> non-interruptable stays on queue also?
[21:38:42] <Avenger> yes
[21:39:09] <fuzzie> i was thinking of doing that with 'Action->SetCanInterrupt(false)'
[21:39:15] <Avenger> and some return all 4 :)
[21:39:27] <Avenger> though this is probably because of the merged functions
[21:39:28] <fuzzie> and an action has to do that every frame while blocking
[21:39:36] <Avenger> so, we might be fine with our action flags
[21:39:52] <fuzzie> our action flags are fine
[21:40:13] <fuzzie> if we have version differences, then we simply make it always AF_BLOCKING and then it can release when it's not blocking :)
[21:40:46] <fuzzie> but it's really great to know that it has a seperate not-interruptable bit!
[21:40:52] <fuzzie> that is really good to know
[21:41:01] <Avenger> the bg version of fadecolor simply sends a message and returns -1
[21:41:09] <fuzzie> ok.
[21:41:17] <fuzzie> the fading runs during dialogs/pause, also
[21:42:25] <fuzzie> so i have to check iwd :)
[21:42:40] <Avenger> hmm the dialog pause stat is actually checked
[21:42:49] <fuzzie> aha
[21:42:50] <Avenger> i never made it work
[21:42:52] <fuzzie> it has a seperate one for dialogs?
[21:42:58] <fuzzie> interesting
[21:43:07] <Avenger> there is an actor stat
[21:43:52] <Avenger> opcode 0xc2 handles it
[21:44:41] <fuzzie> well, i admit i only checked dialog fading in pst :)
[21:44:48] <fuzzie> and i only checked pause fading in bg2
[21:44:52] <fuzzie> so perhaps there are more engine differences
[21:45:07] <fuzzie> but i think we can check them by testing
[21:46:23] <fuzzie> also would be nice to hear about how it schedules scripts, but i know that differs wildly between engine versions so difficult to implement
[21:47:26] <Avenger> something i recently read on g3 tells me, they are not so different :)
[21:47:51] <fuzzie> well, someone confirmed that the iwd2 scripting notes are not all true
[21:47:54] <fuzzie> and that is nice to hear
[21:47:58] <Avenger> yes
[21:48:17] <Avenger> that hole in the script level order was very painful
[21:48:20] <fuzzie> but you can simply look at the iwd2 scripting behaviour to see that some things are very different
[21:52:51] <Avenger> woo, i see the immune to timestop check:)
[21:52:54] <fuzzie> :)
[21:54:15] <Avenger> yeah, we implemented exactly the same way :) cool
[21:54:24] <Avenger> there is a 'timestop owner' in cgameobject
[21:56:05] <lynxlynxlynx> is our timestop supposed to work already?
[21:56:17] <fuzzie> yes
[21:56:28] <Avenger> not sure
[21:56:50] <lynxlynxlynx> i think it didn't the last time i tried, but i'll go test it again
[21:56:51] <Avenger> there is a timestop ticks remaining field in the IE, i don't know how we implemented duration
[21:59:07] <Avenger> hmm what is the summon disable stat... it seems to be a script blocker too
[21:59:24] <lynxlynxlynx> maybe it holds the count of summons?
[21:59:38] <Avenger> no
[21:59:52] <Avenger> it is an active effect, blocks the scripts of the affected one
[22:00:09] <Avenger> also gives the casterhold stat, so it is double proof stopping scripts
[22:01:12] <Avenger> ahh, hmm, there is some naming difference
[22:02:17] <lynxlynxlynx> casting time stop had no visible effect
[22:02:42] <Avenger> maybe in 0.5.2 :)
[22:04:19] <lynxlynxlynx> perhaps
[22:04:59] <lynxlynxlynx> this effect change for the bg2 style mr will be a pain
[22:05:28] <lynxlynxlynx> it looks like all the callers of CreateEffect will have to be adjusted for another param
[22:06:02] <lynxlynxlynx> and there are many
[22:06:21] <Avenger> can't it be done in createffect?
[22:06:59] <lynxlynxlynx> CreateEffect(ieDword opcode, ieDword param1, ieDword param2, ieWord timing) <-- i don't see a way to figure out the source from these
[22:07:28] <lynxlynxlynx> the one that takes a ref is no different
[22:16:07] <-- lynxlynxlynx has left IRC (Remote closed the connection)
[22:40:44] <fuzzie> night
[22:54:43] <Avenger> bye
[22:54:47] <-- Avenger has left IRC ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]")
[23:17:14] <-- barra_home has left IRC ("Verlassend")
[23:21:15] --> Gekz has joined #GemRB