#gemrb@irc.freenode.net logs for 20 Jun 2009 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:07:43] <-- Gekz has left IRC (Read error: 54 (Connection reset by peer))
[00:08:01] --> Gekz has joined #GemRB
[00:20:08] <-- Gekz has left IRC (Remote closed the connection)
[00:21:05] --> Gekz has joined #GemRB
[00:22:48] <fuzzie> okay, I posted a huge blob of questions in the Modding Q&A forum. ninight!
[00:26:13] <-- Gekz has left IRC (Remote closed the connection)
[00:56:29] --> Gekz has joined #GemRB
[05:38:50] <pupnik> morning :)
[07:09:27] --> lynxlynxlynx has joined #gemrb
[07:09:27] --- ChanServ gives channel operator status to lynxlynxlynx
[08:06:21] --- barra_away is now known as barra_library
[08:41:17] --> |Cable| has joined #gemrb
[08:43:16] --> Avenger has joined #gemrb
[08:43:19] --- ChanServ gives channel operator status to Avenger
[08:43:51] <Avenger> hi
[08:44:06] <lynxlynxlynx> oj
[08:45:22] <Avenger> that dimension door was a very annoying piece
[08:46:00] <Avenger> i had to assemble it from 3 pieces, in 2 files, playing the first backwards for the third piece
[08:46:51] <lynxlynxlynx> i've started on the portrait icon refresh thing
[08:47:01] <lynxlynxlynx> http://pastebin.ca/1467376
[08:47:39] <lynxlynxlynx> i'm wondering if it is safe to remove the update calls from the pcf functions (are they ever called from outside of effects?)
[08:48:20] <Avenger> i don't know, maybe from actions
[08:48:30] <Avenger> yeah, actions call them
[08:48:57] <Avenger> if you modify a base stat from an action, the pcf for that stat is triggered
[08:49:11] <Avenger> even from guiscript
[08:49:50] <lynxlynxlynx> with the move, there is now some flickering when you fiddle with the inventory and i think it is due to both the pcf_stat and RefreshEffects calling the refresh
[08:50:09] <lynxlynxlynx> Avenger: ok, but should they affect the portrait icons?
[08:50:31] <lynxlynxlynx> sooner or later RefreshEffects will be called anyway
[08:51:08] <Avenger> they never affects the portrait icons, portrait icons are affected only by effects that call the addportraiticon method in actor
[08:51:51] <lynxlynxlynx> ok, but they could affect the hp, which we display in there
[08:51:58] <Avenger> you can safely remove refresh marks from pcf_ functions
[08:52:07] <lynxlynxlynx> ok
[08:52:10] <Avenger> hmm yes, that's why it is there
[08:52:17] <lynxlynxlynx> the approach looks good otherwise?
[08:52:18] <Avenger> not for the portrait icons :)
[08:52:31] <Avenger> you could put the refresh to damage
[08:52:51] <lynxlynxlynx> damage is an effect
[08:53:03] <lynxlynxlynx> or the Actor::Damage?
[08:53:12] <Avenger> yes, it is like i would have written it, at least Refresheffects, and yes, in Actor::Damage
[08:53:39] <Avenger> Btw, we could probably write an individual actor portrait update
[08:54:16] <Avenger> or tie the button control more closely to the actor, and do the update in core
[08:55:02] <Avenger> we could have a button flag which marks the button 'know' the actor. And it could get the stats directly from there. And update itself when it is drawn
[08:56:22] <lynxlynxlynx> a bit over my head
[08:57:27] <Avenger> one small problem, remove that negation from memcmp :)
[08:57:46] <Avenger> memcmp returns nonzero if the compared memories differ
[08:57:57] <Avenger> it returns 0 if they are the same
[08:58:04] <lynxlynxlynx> yes, reverse
[08:58:54] <fuzzie> ah, lots of useful info from devSin, hooray.
[09:00:57] <Avenger> yes, even if we have to test some of that info individually
[09:01:04] <Avenger> he answered me too
[09:01:56] <fuzzie> Quite a bit of that I already know, or is already in gemrb but not working :)
[09:04:50] <fuzzie> I tried Dialogue() in BG1, IWD, PS:T and BG2 and it follows you around in all cases, so the coordinates must be being updated.
[09:05:01] <Avenger> so movetoobject isn't that complex as you said :)
[09:05:05] <fuzzie> I think devSin is right about some of this differing wildly between IE versions.
[09:05:32] <fuzzie> But it still doesn't help me about MoveToObject. :/
[09:05:50] <Avenger> the path is recalculated as soon as they reach the operating distance
[09:06:06] <fuzzie> the path is recalculated for Dialogue() even if they're half way across the map
[09:06:18] <Avenger> hmm
[09:06:37] <Avenger> then ask him about it :D
[09:06:41] <fuzzie> there are lots of characters which try to automatically initiate dialog with you in all the games, it's easy to test :)
[09:07:16] <fuzzie> yes, i'll experiment some more in the original engine first
[09:08:21] <fuzzie> combat should be trivial to test also
[09:08:34] <fuzzie> but time for breakfast and things first.
[09:09:39] <fuzzie> re the portraits: shouldn't RefreshEffects and the pcf_stat be called in the same frame anyway?
[09:10:12] <CIA-18> gemrb: 03lynxlupodian * r6534 10/gemrb/trunk/gemrb/plugins/ (Core/Actor.cpp FXOpcodes/FXOpc.cpp): try to always update the portrait window when necessary
[09:10:25] <lynxlynxlynx> one thing that is a bit annoying is that the ordering isn't preserved
[09:10:40] <fuzzie> we call gui scripts first, then update actors, then handle EF_PORTRAIT
[09:10:41] <lynxlynxlynx> if you remove icon #2 and readd it, it will go into the last place
[09:12:33] <fuzzie> Oh, I see, you're being much cleverer.
[09:14:34] <lynxlynxlynx> except it isn't working
[09:15:23] <lynxlynxlynx> or it's playing tricks on me
[09:17:35] <fuzzie> in the memcmp, MAX_PORTRAIT_ICONS should be either sizeof(ieWord)*MAX_PORTRAIT_ICONS or plain sizeof(PreviousPortraitIcons)
[09:17:46] <Avenger> damn i didn't notice that :D
[09:18:09] <lynxlynxlynx> ah, so i'm comparing too little and it seems the same
[09:18:16] <fuzzie> yes, you're only comparing the first 6 atm
[09:18:29] <fuzzie> maybe that's not your bug, but it seems fine otherwise
[09:19:55] <lynxlynxlynx> thanks
[09:20:10] <lynxlynxlynx> bad c/p, i see the source used a constant
[09:20:26] <-- Edheldil has left IRC ("Really?")
[09:58:12] <lynxlynxlynx> wierd stuff, we do update but very late
[10:00:46] <fuzzie> How late?
[10:00:59] <fuzzie> It might end up a frame or two late, but that should be all.
[10:01:47] <lynxlynxlynx> like a turn late :/
[10:01:55] <lynxlynxlynx> casting haste nicely shows it
[10:02:15] <fuzzie> Maybe PortraitIcons doesn't get updated?
[10:02:16] <lynxlynxlynx> if you cast something shortlived like protection from magical weapons, it won't be updated in time
[10:02:45] <lynxlynxlynx> if you switch to inventory immediately, the copy there is properly updated
[10:03:02] <lynxlynxlynx> so i'm puzzled why the main one isn't
[10:03:23] <fuzzie> Hm, 'PortraitIcons' should be kept updated.
[10:03:46] <fuzzie> Just not the string, necessarily.
[10:03:47] <lynxlynxlynx> it is reconstructed
[10:04:05] <fuzzie> The string being updated when the python gets around to asking.
[10:04:20] <fuzzie> Did you try adding a printf() and seeing if EF_PORTRAIT gets set there in your RefreshEffects?
[10:05:01] <lynxlynxlynx> i'm in a gdb session, but RefreshEffects is called so often i can't do much
[10:05:04] <lynxlynxlynx> i'll try that
[10:05:24] <lynxlynxlynx> forgot about the possibilities of guiscript bugs
[10:08:22] <lynxlynxlynx> it gets triggered, but not immediately
[10:08:59] <fuzzie> RefreshEffects only gets called once the next AI update happens, but if the game is unpaused that should be within 1/15th of a second.
[10:08:59] <lynxlynxlynx> and the icon list must be bad at that point, since there is no visual update
[10:09:32] <fuzzie> And then the python is only called the *next* time around the main loop, and the python is responsible for the visual update.
[10:09:46] <fuzzie> But still, it should be faster than 1/10th of a second or so.
[10:11:49] <fuzzie> You tried putting some print statements in UpdatePortraitWindow in guiscripts too?
[10:12:09] <lynxlynxlynx> i'm looking at them now
[10:37:25] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[10:40:45] --> Gekz has joined #GemRB
[10:50:25] <fuzzie> ok
[10:50:33] <fuzzie> if you MoveToObject, you follow the object.
[10:50:55] <fuzzie> it re-pathfinds constantly.
[10:51:45] <fuzzie> it only stops once it's actually caught up (touching, not operating distance).
[10:53:11] <fuzzie> oh, hm, maybe operating distance just differs per-game
[10:53:15] <fuzzie> because Dialogue works identically
[10:55:39] <fuzzie> MoveToObjectFollow works the same, but at a larger distance, and it keeps following once it caught up.
[11:00:09] --- barra_library is now known as barraAway
[11:04:17] <fuzzie> okay, i posted more to the thread. summary: MoveToObject will re-pathfind constantly to find a new path to the target, even if started via a one-time ActionOverride call.
[11:07:51] --> zefklop has joined #gemrb
[11:08:00] <zefklop> hi everybody
[11:11:49] <fuzzie> hi
[11:49:23] <CIA-18> gemrb: 03zefklop * r6535 10/gemrb/trunk/gemrb/ (2 files in 2 dirs): Partially fix GuiScripts for summoned and charmed creatures.
[11:52:27] <fuzzie> that's a nice simple temporary fix :)
[11:52:39] <fuzzie> I am trying to work out how movement actions work..
[12:01:15] <-- Gekz has left IRC (Read error: 60 (Operation timed out))
[12:03:08] --> Gekz has joined #GemRB
[12:09:12] <zefklop> yeah i saw your post on modding q&a
[12:10:12] <Avenger> meh, call lightning chain doesn't want to work, in original game. I always see only one strike
[12:10:38] <zefklop> doesanybody have a savegame with a deva summoner?
[12:10:46] <lynxlynxlynx> call or chain lightning?
[12:10:51] <Avenger> call lightning
[12:10:55] <zefklop> well, a high level clerk :)
[12:11:09] <Avenger> you can always get one
[12:11:13] <Avenger> addcurrentxp :)
[12:11:20] <Avenger> wanna me create one?
[12:11:21] <zefklop> meh, shadow keeper ...
[12:11:23] <lynxlynxlynx> GemRB.SetPlayerStat(1,44,4000000)
[12:11:30] <zefklop> thanks
[12:11:44] <lynxlynxlynx> Avenger: it is one per turn
[12:11:51] <Avenger> oh, per turn
[12:11:53] <Avenger> hmm
[12:12:27] <Avenger> i'm sure i waited more
[12:12:28] <lynxlynxlynx> i have an iwd2 save where that is still in effect hehe
[12:12:38] <lynxlynxlynx> check the description
[12:12:43] <Avenger> well, i talk about bg2
[12:13:00] <lynxlynxlynx> me too :)
[12:13:05] <Avenger> i saw call lightning work in iwd2
[12:13:33] <lynxlynxlynx> The caster can call down one bolt per turn.
[12:14:01] <lynxlynxlynx> The spell has a duration of one turn for every four levels of the caster.
[12:14:24] <Avenger> yes, so?
[12:14:30] <lynxlynxlynx> btw, iirc it works indoors too now
[12:14:38] <Avenger> i use the projectile with the 4 lightnings
[12:14:41] <lynxlynxlynx> those were just description quotes
[12:14:52] <Avenger> i don't need the spell, most likely
[12:14:56] <Avenger> just the projectile
[12:15:01] <lynxlynxlynx> 81?
[12:15:06] <Avenger> 84
[12:15:15] <lynxlynxlynx> my sppr302 uses 81
[12:15:22] <Avenger> in its first header
[12:15:27] <Avenger> but it varies with level
[12:15:36] <Avenger> look for higher levels
[12:15:41] <lynxlynxlynx> yeah
[12:15:52] <Avenger> there are projectiles up to 11 chains
[12:15:58] <Avenger> even though the spell uses 4 at max
[12:16:07] <Avenger> i tried 1,4,10,11 so far
[12:16:16] <Avenger> all gives only 1
[12:16:37] <lynxlynxlynx> you mean you don't get another projectile the next round?
[12:16:44] <Avenger> i guess i will have to fall back to the spell
[12:16:50] <Avenger> yes i get only one
[12:17:34] <Avenger> i see the call lightning spell is flagged as indoors
[12:17:46] <lynxlynxlynx> yep
[12:17:49] <Avenger> THAT is easy to implement, if it wasn't yet
[12:18:10] <Avenger> i doubt the projectile bothers with that
[12:19:03] <Avenger> i thought its code is similar to the magic missiles, but i see no iteration here
[12:19:22] <Avenger> even in the code, that's why i tried to experiment with it at all
[12:19:50] <lynxlynxlynx> my jaheira is druid level 13 and the damage output says she fired two strong bolts at the same time
[12:20:02] <Avenger> all i see it creates a basic call lightning projectile (23)
[12:20:14] <Avenger> hmm but only one visual?
[12:20:33] <Avenger> maybe it just applies the same effect n times?
[12:20:48] <Avenger> heh, i could check that
[12:20:50] <lynxlynxlynx> 34, 30 hp; none visually
[12:21:09] <Avenger> you should see the lightning bolt :)
[12:21:10] <lynxlynxlynx> no, it has two damage effects, one for the base and one for the level based
[12:21:29] <lynxlynxlynx> but i'd expect 3 for a 13th level caster
[12:22:22] <lynxlynxlynx> hmm, no, it's not the base + level
[12:22:35] <Avenger> i'm getting too obsessed with the IE, i just typed in the display string opcode number without thinking :)
[12:23:39] <Avenger> k, i see only one display string too
[12:23:53] <Avenger> so this must check something from the spell
[12:23:57] <Avenger> maybe cleric caster level
[12:24:05] <Avenger> that could be
[12:24:13] <lynxlynxlynx> on string of what?
[12:24:38] <lynxlynxlynx> i get two of the "damage taken"
[12:25:15] <Avenger> i don't use damage opcode
[12:25:22] <Avenger> it makes targets hostile, etc :)
[12:25:31] <lynxlynxlynx> not if you target pcs ;)
[12:25:33] <Avenger> usually just single pulse color glow
[12:25:40] <Avenger> or display string
[12:25:55] <Avenger> single pulse color is good for area affecting spells ;)
[12:27:04] <Avenger> ok, gave the item with the projectile (84) to jaheira, still only a single lightning strike
[12:53:57] <fuzzie> Avenger: Should I add another GameScript flag - AF_REEVALUATE, maybe - to cope with AttackReevaluate?
[12:54:19] <Avenger> why do you need it
[12:55:00] <fuzzie> Oh, hm, maybe it can work ok with AttackCore anyway.
[12:57:44] <Avenger> btw, we have lots of actions that exclude any sender except actor, there is a flag for that AF_ALIVE
[12:58:13] <fuzzie> Isn't that all working already?
[12:58:28] <Avenger> af_alive works, but not used everywhere
[12:58:38] <Avenger> AddSpecialAbility is one
[12:58:50] <Avenger> it could be marked, and the extra lines removed then
[12:59:52] <Avenger> hmm, wait, it doesn't check the actor type, it checks if the actor is still alive ;)
[13:04:01] <fuzzie> AF_BLOCKING is strange
[13:05:52] <fuzzie> I'll just try rewriting this how I think it should work, and see if it's better.
[13:29:44] <CIA-18> gemrb: 03fuzzie * r6536 10/gemrb/trunk/gemrb/plugins/Core/GameScript.cpp: clear path when executing a new script block
[13:35:10] <fuzzie> I think our implementation of IsOverMe() is bad, because IsOverMe("Jaheira") fails unless she happens to be the one who caused LastEntered (it is more often another party member).
[13:35:49] <fuzzie> But I didn't test it yet and it could be a trap bug instead.
[13:39:50] <fuzzie> We should display "Detecting traps" and "Stopped detecting traps", also. For that matter, we should make the button work to stop detecting them. :/
[13:43:15] <fuzzie> also, Imoen's initial lore is a lot more useful (identifies more things instantly) than in gemrb
[13:43:49] <fuzzie> And the original ctrl-y definitely works by causing damage, so we should fix that too.
[13:44:39] <lynxlynxlynx> yes, like i said - it deals a bit over 1k of damage
[13:45:22] <fuzzie> Sorry, I must have missed you saying that.
[13:45:40] <fuzzie> I'm just using ctrl-y trying to debug some script issues and noticed it :)
[13:50:40] <fuzzie> Okay, our trap implementation is wrong: It should only fire when it is *entered* by an actor, not by an actor already in it. I'll fix later.
[13:51:01] <fuzzie> Traps also shouldn't become visible when they're set off.
[13:56:13] <fuzzie> The Ulvaryl cutscene works fine in gemrb now, anyway..
[13:56:32] <lynxlynxlynx> mist included?
[13:57:40] <fuzzie> Well, she disappears :) I didn't see mist in original game or gemrb, but she was a bit hidden by the wall in both.
[13:58:04] <lynxlynxlynx> iirc she does mistify in the original, you can't really kill her
[13:58:34] <fuzzie> The script has her turning into a bat if <10hp, or turning into mist (in death script) if she dies.
[13:59:27] <fuzzie> Looks like the bat (SPIN963) is what fired for me.
[14:01:19] <fuzzie> It didn't actually seem to work, though. No VAMPBAT resource loaded.
[14:02:06] <fuzzie> The SPDISPMA effect in the spell worked, though..
[14:02:44] <fuzzie> Ah, the fx_replace_creature has a delayed timing and she probably died before it got activated.
[14:04:12] <fuzzie> Probably the same bug with mist; turning into GASFORM4 is also delayed.
[14:04:32] <fuzzie> Avenger: Any idea how this is meant to work?
[14:05:07] <Avenger> which spell? spin963?
[14:05:17] <fuzzie> SPIN964 is clearer.
[14:05:36] <fuzzie> It is cast on death on self, after Die() returned true.
[14:05:38] <Avenger> well, it has a tick delay
[14:06:27] <Avenger> maybe death doesn't clear the fxqueue?
[14:07:03] <fuzzie> Maybe death does clear the fxqueue, but only at the moment of death?
[14:07:21] <Avenger> no, at all
[14:07:42] <fuzzie> I found some bugs with other effects not stopping on death.
[14:07:53] <Avenger> well, some effects stop
[14:08:02] <Avenger> i saw code in mirror image, for example
[14:08:13] <fuzzie> for example, SPWI311's Overlay:ShieldGlobe is meant to disappear on death; it doesn't right now, in gemrb
[14:08:14] <Avenger> it specifically removes itself on death
[14:08:21] <Avenger> hmm
[14:08:30] <Avenger> but then replaceself should work :)
[14:09:20] <fuzzie> CheckOnDeath() maybe returns true (and so the actor is deleted) too soon.
[14:09:42] <fuzzie> There are lots of bugs with that, actors being deleted before they get a chance to do their death stuff..
[14:10:27] <fuzzie> Hm, Ulvaryl doesn't have any class flags set, though.
[14:12:27] <fuzzie> I don't know. I was just wondering if it was an obvious problem :)
[14:35:36] <lynxlynxlynx> hmpf
[14:36:01] <lynxlynxlynx> when meddling with the inventory, this portrait stuff works as expected
[14:36:37] <lynxlynxlynx> but when getting an icon through spell effects, the original icon list already has the addition before we nullify it
[14:37:12] <lynxlynxlynx> so the two list are the same and there is no update triggered
[14:39:07] <fuzzie> You could make the PreviousPortraitIcons a member of PCStats; then initialise it in the 'if (first)' block and at the end of RefreshEffects.
[14:39:23] <fuzzie> You'd have to move the memset() for PortraitIcons down below the if(first) block, but that doesn't seem harmful.
[14:39:49] <lynxlynxlynx> you think that would help?
[14:39:53] <fuzzie> It is kind of a horrible hack just to account for the fact that we're re-applying effects far too often, though. :/
[14:40:41] <fuzzie> lynxlynxlynx: Well, it'd mean that it would be sure to detect any changes which happened. If the icon list really isn't changing at all then it won't help.
[14:41:22] <-- zefklop has left IRC ("ChatZilla [SeaMonkey 1.1.16/2009040306]")
[14:41:23] <lynxlynxlynx> i does change and i have some GRRR1+38+65535+65535+ to prove it :)
[14:41:32] <lynxlynxlynx> i'll try your approach, thanks
[14:43:29] <-- Avenger has left IRC ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]")
[14:44:11] <lynxlynxlynx> oh, but wouldn't that make it update the portrait window all the time if you had some permanent on-equip effects?
[14:45:44] <lynxlynxlynx> nevermind
[14:47:11] <fuzzie> I should clarify; the first initialization would fill it with -1, and at the end of RefreshEffects you'd put the memcpy() which you'd put at the start previously.
[14:47:36] <fuzzie> I guess you probably figured it out yourself, whether that way or another, though :)
[14:47:57] <lynxlynxlynx> yeah
[14:48:31] <lynxlynxlynx> the first one isn't needed, since the array is already cleared in the constructor of PCStats
[14:49:03] <fuzzie> Ah, even more convenient :)
[14:55:28] <lynxlynxlynx> cool, this works
[14:55:54] <lynxlynxlynx> five update calls - one per actor (6 members, but one has free action)
[14:56:02] <fuzzie> yay :)
[15:03:07] <CIA-18> gemrb: 03avenger_teambg * r6537 10/gemrb/trunk/gemrb/override/bg2/ (comet.pro gemprjtl.ids spgenhla.pro): 2 new unhardcoded projectiles
[15:03:52] <CIA-18> gemrb: 03lynxlupodian * r6538 10/gemrb/trunk/gemrb/plugins/Core/ (Actor.cpp PCStatStruct.cpp PCStatStruct.h): fixed portrait icon refreshing
[15:03:54] <lynxlynxlynx> cool, maybe now saradush catapults work
[15:04:33] <CIA-18> gemrb: 03avenger_teambg * r6539 10/gemrb/trunk/gemrb/plugins/Core/ (Projectile.cpp Projectile.h): implemented PAF_DELAY and PAF_AFFECT_ONE flags existing in original game
[15:06:33] <CIA-18> gemrb: 03avenger_teambg * r6540 10/chitem/trunk/ (Chitem.h ProjGemRB.cpp ProjGemRB.h chitem.clw chitem.rc): dltcep update (some more gemrb specific projectile flags)
[15:09:43] <lynxlynxlynx> the comet falls nicely
[15:10:34] <CIA-18> gemrb: 03avenger_teambg * r6541 10/gemrb/trunk/gemrb/docs/en/Engine/Projectile.txt: more projectile extension flags documented
[15:10:58] <lynxlynxlynx> dragon breath is funny
[15:11:34] <fuzzie> hm, projectile 191 doesn't seem to work from me, from a trap, but maybe the bug is elsewhere
[15:14:41] <lynxlynxlynx> which one is that?
[15:15:06] <lynxlynxlynx> i can't trigger the saradush comets either, if it is that one
[15:15:16] --> Avenger has joined #gemrb
[15:15:30] <lynxlynxlynx> casting the spell works though, but we don't display the splash
[15:16:09] --- ChanServ gives channel operator status to Avenger
[15:16:52] <Avenger> the saradush comet animation should work now, i just made its projectile
[15:17:10] <fuzzie> no, 191 is from the wizard Frost spell
[15:17:15] <lynxlynxlynx> i can't trigger it
[15:17:32] <fuzzie> it seems to be in gemprjtl.ids but it isn't firing from a tra
[15:17:33] <fuzzie> p
[15:17:41] <lynxlynxlynx> iirc there are two area traps that consistently summon it
[15:17:55] <lynxlynxlynx> someone also shouts Incoming
[15:18:12] <fuzzie> do you get the Incoming shout? if not, presumably it's a script bug
[15:18:21] <lynxlynxlynx> i don't
[15:18:32] <lynxlynxlynx> i'll try a fresh entry, this was an old save
[15:18:45] <lynxlynxlynx> all my chars had IE_EA==255
[15:19:44] <fuzzie> I forgot to buy dinner, so I need to go off with people and eat. The trap code is pretty badly broken so it could just be a trap bug, I wouldn't spend too much time looking..
[15:20:19] <fuzzie> If you could take a look at why you can't disable FINDTRAPS with the action bar (the button doesn't even go disabled) I'd be grateful. Not important though. Bye!
[15:20:53] <lynxlynxlynx> bye
[15:22:03] <Avenger> it is the jwsiege spell
[15:22:13] <Avenger> from ptsiege1 trap
[15:24:00] <Avenger> it needs the Global("SiegeLocation","AR5000",0) condition
[15:24:19] <Avenger> so you can probably set that variable back to 0
[15:24:20] <lynxlynxlynx> nice, the column effect of the bhaal transform works
[15:24:38] <lynxlynxlynx> i have to get there first ;)
[15:30:51] <lynxlynxlynx> oh, does it work for you (the comet)?
[15:32:50] <Avenger> i tested it only with item
[15:33:04] <Avenger> with an item, it works
[15:33:31] <Avenger> not exactly the same, the incoming part is there, and there is a kind of explosion on ground, but not the same as in the original
[15:34:09] <Avenger> the ground explosion will probably need some more unhardcoding :)
[15:34:14] <lynxlynxlynx> the shadow door works nicely too
[15:34:38] <Avenger> you meant the pop in/out dimension door?
[15:34:47] <lynxlynxlynx> yes
[15:35:08] <Avenger> i worked a lot to place it behind the target :)
[15:36:20] <Avenger> it is simple, but i mixed up the numbers
[15:36:45] <lynxlynxlynx> i don't get the "incoming" warning or the comet
[15:36:57] <lynxlynxlynx> comet the spell works ok
[15:38:25] <lynxlynxlynx> that var is 0
[15:38:57] --> Edheldil has joined #gemrb
[15:38:57] --- ChanServ gives channel operator status to Edheldil
[15:43:48] --> zefklop has joined #gemrb
[15:48:29] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[15:48:36] --> Gekz has joined #GemRB
[15:55:29] <zefklop> meh, deva summoning does not work
[15:56:49] <-- zefklop has left IRC ("ChatZilla [SeaMonkey 1.1.16/2009040306]")
[16:06:05] <-- Gekz has left IRC ("leaving")
[16:20:27] <Avenger> hmm, i tried to use an innate (not the first in the row), and it used the first
[16:20:49] <Avenger> this seem to be a guiscript bug
[16:21:09] <lynxlynxlynx> happened to me once too
[16:21:53] <lynxlynxlynx> and still does
[16:22:49] <Avenger> oh i know why
[16:23:01] <Avenger> if there are multiple uses of a spell
[16:23:16] <Avenger> there are fewer buttons
[16:23:25] <Avenger> not all instances of the spell get a button
[16:24:20] <Avenger> setupspellicons should set it correctlyt
[16:25:44] <Avenger> i'll fix this
[16:31:20] <Avenger> omg, multiple bugs
[16:48:16] <-- Avenger has left IRC ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]")
[16:50:08] --> Avenger has joined #gemrb
[17:04:49] <fuzzie> > ReallyForceSpell(Myself, 0)
[17:05:05] <fuzzie> ^- that is the spell call from my copy of ptsiege1, from weidu
[17:05:39] <fuzzie> patched ToB has a ReallyForceSpellRES there?
[17:16:19] <Avenger> yes
[17:16:37] <Avenger> there is a resource field filled
[17:18:26] <CIA-18> gemrb: 03avenger_teambg * r6542 10/gemrb/trunk/gemrb/plugins/Core/Interface.cpp: fixed summoning of single creatures
[17:20:26] <fuzzie> strange
[17:23:19] <CIA-18> gemrb: 03avenger_teambg * r6543 10/gemrb/trunk/gemrb/plugins/ (Core/Spellbook.cpp GUIScript/GUIScript.cpp): fixed selection of the right spellinfo struct (used in spellcasting gui)
[17:23:23] <Avenger> ok, i had to fix 3 bugs to make zefklop's deva summoning work. It is still a bit different, but it works now
[17:23:36] <fuzzie> that is great :)
[17:23:46] <Avenger> was there a bugreport for this?
[17:23:54] <fuzzie> no, i think he just found it
[17:24:31] <Avenger> the summoned creature can't be selected bug by him seems to be fixed, by him?
[17:24:34] <Avenger> i close that
[17:24:42] <fuzzie> yes, fixed
[17:24:43] <Avenger> i could move my deva
[17:25:43] <fuzzie> are the helm of balduran / ring of regeneration problems still there?
[17:27:03] <Avenger> well, i think yes
[17:27:11] <Avenger> it is not as heavy as before
[17:27:25] <Avenger> there were multiple bugs affecting that
[17:27:42] <Avenger> when i 'fixed' it completely, it caused other problems with the pcf stuff
[17:27:49] <Avenger> so part of it was reverted
[17:30:08] <Avenger> this wasn't fixed yet ? https://sourceforge.net/tracker/?func=detail&aid=1895628&group_id=10122&atid=110122
[17:30:35] <fuzzie> i think the animation sequence is still a bit broken
[17:31:53] <fuzzie> i guess you have no idea about #1623839 (our oldest bug)? i put some comments in
[17:32:14] <Avenger> small teeth ?
[17:32:19] <fuzzie> yes
[17:32:25] <Avenger> that is very simple bug
[17:32:27] <fuzzie> the TIS has lots of different shades of green
[17:32:41] <fuzzie> a few times, multiple shades in the same tile
[17:33:20] <fuzzie> the pool itself is just one shade of green (4/248/4 or something), but that is not the only mis-rendered thing on that area
[17:33:45] <Avenger> there is another tile which shows what to do, i think
[17:34:17] <Avenger> do you remember the area resref?
[17:34:46] <Avenger> i remember i knew what to do with this bug, it was just too much fuss for so little gain
[17:35:22] <fuzzie> ar1700 maybe?
[17:36:05] <Avenger> yes
[17:36:06] <fuzzie> DLTCEP mentions a 'threshold' for the transparency, but i don't know if that's just a DLTCEP thing
[17:36:28] <Avenger> that is a function to clean up these kind of things
[17:37:04] <Avenger> if something is inside the transparency treshold, it can change it to the canonical value
[17:37:50] <fuzzie> i tried adding a threshold and editing the palette as it was loaded, but i couldn't find a threshold which worked for AR1700 but didn't match 'normal' tiles in other areas
[17:38:41] <Avenger> if you look at the area in dltcep
[17:39:30] <Avenger> 1769 is one of those bad tiles
[17:39:49] <Avenger> you can see the stencil tiles by default
[17:40:17] <Avenger> if you use the stencil tiles only for cutting out the overlay, and the whole tiles for drawing
[17:40:30] <Avenger> you can fix this problem
[17:40:49] <Avenger> the problem is that we use the stencil tiles for drawing
[17:41:03] <Avenger> alternative solution: repair all stencil tiles on the fly
[17:41:33] <Avenger> that means: when they have a transparent pixel keep it, when they have a non-transparent pixel, replace it with the original whole tile.
[17:41:42] <Avenger> i wanted this second version
[17:42:04] <fuzzie> but what is 'transparent pixel'?
[17:42:23] <Avenger> 0,255,0
[17:42:27] <Avenger> full green
[17:42:36] <fuzzie> but there are overlay tiles which aren't that, right?
[17:42:47] <fuzzie> or are the stencil tiles all fine?
[17:43:02] <Avenger> no, the overlay (stencil) files are not fine, but all original tiles are fine
[17:44:04] <Avenger> for simplicity we draw the overlay tiles on top of overlays, but the overlay tiles themselves are just copies of the original tiles
[17:44:09] <Avenger> well, most of the time
[17:44:35] <Avenger> i call them stencil because the overlay tiles are the water tiles
[17:45:00] <Avenger> dltcep calls it alternate tile
[17:45:21] <fuzzie> 16:33 is the real problem in AR1700
[17:45:29] <Avenger> 1633?
[17:45:32] <fuzzie> that is 1831/2932
[17:46:12] <fuzzie> would that be solved with both of your suggestions?
[17:46:16] <Avenger> that's the same as 1769
[17:46:19] <Avenger> yes
[17:46:45] <Avenger> do you look at it in dltcep?
[17:46:48] <fuzzie> yes
[17:46:56] <fuzzie> 1769 looks like it *shouldn't* be water where the green is
[17:46:57] <Avenger> click on draw open
[17:47:14] <Avenger> that will draw the original tiles
[17:47:18] <Avenger> as you see, they are intact
[17:47:35] <Avenger> the stencil tiles should be used only where they are transparent
[17:47:55] <fuzzie> the original game doesn't draw moving water for the pool?
[17:48:01] <fuzzie> i thought i checked, but maybe not
[17:48:05] <fuzzie> but, okay, i can make that work
[17:48:49] <Avenger> the original game draws the water overlay only where the stencil tile is transparent
[17:49:13] <Avenger> in other places we draw the stencil tile, but hte original game draws the original tile
[17:49:50] <Avenger> so the alt tiles are used only for their transparency info
[17:50:03] <Avenger> they could be all white, or whatever
[17:50:10] <Avenger> except 0,255,0
[17:50:19] <fuzzie> you are right, the water is still.
[17:53:34] <fuzzie> Huh, I spent ages trying to work out how transparency worked for other pixels. :/
[17:53:35] <Avenger> btw, if you mess with the drawing order, be aware of bg1 :)
[17:53:56] <Avenger> i wouldn't mess with the drawing order, just fix the stencil tiles
[17:54:08] <fuzzie> I usually test everything in bg1 and bg2.
[17:54:17] <fuzzie> Not iwd2 because I can't make new games in it :)
[17:55:01] <Avenger> so i really prefer this solution: when there is an alternate tile, overwrite it everywhere with the appropriate original tile, except where the alternate tile is transparent green
[17:55:31] <fuzzie> Does that not break door open/closed tiles?
[17:55:49] <Avenger> hmm
[17:56:02] <fuzzie> I forgot how it works, so maybe not.
[17:56:12] <Avenger> i think doors are different
[17:56:22] <Avenger> they got 2 separate sets of tiles
[17:56:36] <Avenger> but let me findsome
[17:56:46] <fuzzie> the pocket plane is a good example
[17:57:52] <lynxlynxlynx> btw, helm of balduran seems to function correctly now (except for the general double effects gui bug)
[18:00:08] <Avenger> fuzzie: do you know any place where a door tileset intersects an overlay?
[18:00:22] <fuzzie> i don't think so
[18:00:26] <Avenger> because you have to do my fixing hack only when there is an overlay :)
[18:00:38] <fuzzie> i was just wondering about the consequences :)
[18:01:59] <fuzzie> so i guess the fix for Saradush is to actually implement some of the missing actions
[18:02:09] <Avenger> which action is missing
[18:02:14] <fuzzie> ReallyForceSpellRES
[18:02:24] <Avenger> that is the same as reallyforcespell
[18:02:36] <fuzzie> i can just add it to the list in GameScript?
[18:02:46] <Avenger> it should autodetect it
[18:03:02] <Avenger> it should say 'reallyforcespellres' is a synonym for 'reallyforcespell'
[18:03:08] <fuzzie> Warning: Couldn't assign action: 181 reallyforcespellres
[18:03:12] <Avenger> woo
[18:03:20] <fuzzie> same for all the RES stuff
[18:03:29] <Avenger> because reallyforcespell isn't there either
[18:03:32] <Avenger> meeh
[18:03:53] <Avenger> hmm it is there
[18:03:56] <fuzzie> oh? reallyforcespell is seems to be there
[18:04:46] <Avenger> 181 ReallyForceSpellRES(S:RES*,O:Target) is the same as 181 ReallyForceSpell(O:Target,I:Spell*Spell)
[18:05:12] <Avenger> wait, it isn't a problem if it couldn't assign 181 first :)
[18:05:16] <Avenger> it will do that later
[18:05:20] <Avenger> at least it should
[18:05:53] <Avenger> the only thing requirement is that it finds reallyforcespell and ties our implementation to action opcode 181
[18:05:56] <fuzzie> it should probably make more sense on the console :/
[18:06:06] <fuzzie> but it doesn't complain about not being able to find reallyforcespell
[18:06:24] <Avenger> it should complain about reallyforcespellres later
[18:06:29] <Avenger> if it couldn't resolve it
[18:06:39] <Avenger> see what it says about multiplayersync
[18:06:57] <fuzzie> it doesn't like that one either
[18:07:10] <fuzzie> but i guess it /really/ doesn't assign that
[18:07:15] <Avenger> but not at load time
[18:07:17] <fuzzie> since i get errors about it being missing
[18:07:30] <Avenger> yes, when it uses it first, you get a second message
[18:07:39] <Avenger> that second message is the real one :)
[18:07:43] <lynxlynxlynx> i've noticed only multiplayersync messages
[18:07:54] <fuzzie> ok
[18:08:03] <fuzzie> i guess i will put printf()s in ReallyForceSpell everywhere then :)
[18:08:06] <Avenger> because you ignored the ones at load time when it parses the script tables
[18:08:15] <lynxlynxlynx> btw, that synonim finding doesn't link the two funny tob actions that have the same id
[18:08:30] <fuzzie> lynxlynxlynx: that output is apparently unreliable
[18:08:35] <fuzzie> it is lying :/
[18:08:51] <Avenger> maybe it doesn't list synonyms when one of them isn't in the list
[18:09:02] <Avenger> it says synonym only when it finds the same opcode twice
[18:09:06] <fuzzie> i think it doesn't list synonyms when it encounters the synonym first
[18:09:09] <lynxlynxlynx> i guess it doesn't list them since none of the two is implemented yet ;)
[18:09:12] <fuzzie> then it just errors out
[18:09:26] <lynxlynxlynx> Warning: Couldn't assign trigger: 0x40db inwatcherskeep
[18:09:26] <Avenger> hehe lynx which tob funny action is that
[18:09:27] <lynxlynxlynx> Warning: Couldn't assign trigger: 0x40db amiinwatcherskeeppleaseignorethelackofapostophe
[18:09:34] <Avenger> ook, i didn't implement that
[18:09:46] <lynxlynxlynx> pleaseignorethelackofr
[18:09:52] <fuzzie> we should maybe just get the basic games working first :)
[18:10:01] <Avenger> it should be easy, just have a 2da which lists them, i guess
[18:10:08] <lynxlynxlynx> yeah, this one should be really easy
[18:10:20] <lynxlynxlynx> Avenger: i think there already is such a 2da
[18:10:26] <lynxlynxlynx> xl3000 maybe?
[18:10:34] <Avenger> it isn't easy because i want to implement it like the original, sans the hardcode
[18:10:36] <Avenger> hmm
[18:10:40] <Avenger> really?
[18:10:42] <lynxlynxlynx> no
[18:10:43] <Avenger> that would be good
[18:11:13] <lynxlynxlynx> xnewarea
[18:11:29] <fuzzie> ok, reallyforcespell is called, it just doesn't actually open the damn spell :/
[18:11:30] <lynxlynxlynx> that is if AR3000 is WK
[18:12:22] <lynxlynxlynx> yep
[18:12:23] <Avenger> fuzzie: it calls resolvespellname
[18:12:38] <fuzzie> Avenger: but then it doesn't cast the spell
[18:13:03] <fuzzie> CastSpellEnd doesn't work without a CastSpell first, i will fix
[18:13:04] <Avenger> resolvespellname resolves it to the jwsiege resref? (i think that's the name)
[18:13:10] <Avenger> aaah
[18:14:00] <Avenger> do the same fix in reallyforcespellpoint too!
[18:14:13] <fuzzie> and in ReallyForceSpellDead
[18:14:16] <Avenger> yep
[18:14:24] <lynxlynxlynx> there are so many casting actions
[18:15:29] <Avenger> cool, some more actions will work now
[18:17:38] <fuzzie> it works fine with that
[18:17:40] <fuzzie> poor orphan kid
[18:18:42] <fuzzie> hehe, we can talk to actors who are playing dead :)
[18:20:26] <fuzzie> the traps still don't work though
[18:20:29] <CIA-18> gemrb: 03fuzzie * r6544 10/gemrb/trunk/gemrb/plugins/Core/Actions.cpp: fix ReallyForceSpell actions
[18:23:40] <fuzzie> Hopefully that fixes 978 bg2 actions. :P
[18:23:57] <Avenger> 978?
[18:24:11] <fuzzie> the number of ReallyForceSpell* calls
[18:24:29] <Avenger> haha
[18:24:36] <Avenger> you actually counted them?
[18:25:19] <fuzzie> I got weidu to decompile all the scripts for me, so I can just grep them :)
[18:25:24] <Avenger> when will you switch over to curved path magic missiles?
[18:25:37] <fuzzie> It is very useful when making a change, I can just grep for all usages of the action and make sure I don't break any of them.
[18:25:49] <pupnik> nice fuzzie
[18:28:05] <fuzzie> Avenger: That shouldn't be hard to do, just want to fix these trap bugs first and keep getting distracted.
[18:29:24] <lynxlynxlynx> structured procrastination
[18:30:41] <Avenger> heh, these guys created lots of projectiles for the same theme
[18:30:43] <CIA-18> gemrb: 03avenger_teambg * r6545 10/gemrb/trunk/gemrb/override/bg2/ (gemprjtl.ids lightbnb.pro spholymt.pro): 2 more unhardcoded projectiles (lightning bolt needs more care)
[18:31:05] <fuzzie> i was thinking that we should maybe have a shared override directory
[18:31:06] <Avenger> spholymt is another light pillar type
[18:31:13] <fuzzie> for the .pro files which are present in all the games
[18:31:26] <Avenger> optimally they could be biffed
[18:31:48] <fuzzie> well, we could .bif them as an optional part of the build
[18:32:01] <Avenger> yeah
[18:32:21] <Avenger> but we need lots of special code for that, a chitin.key override
[18:32:31] <Avenger> not a big deal, just read 2 .keys
[18:32:38] <fuzzie> but already, some of these projectiles would be nice to have in bg1
[18:32:43] <fuzzie> and iwd1
[18:32:46] <Avenger> yep
[18:33:03] <Avenger> they didn't overwrite the legacy projectiles, most of the time
[18:33:14] <Avenger> so even iwd2 got these, i think
[18:33:26] <fuzzie> so would it be useful to add support for an override/shared folder (or a better name?)?
[18:33:53] <Avenger> probably yes
[18:34:11] <Avenger> but there are surely exceptions
[18:34:28] <Avenger> so it is a tough stuff
[18:34:43] <fuzzie> we could make it lowest-priority :)
[18:34:44] <Avenger> to avoid overcrowding of the override dir, they need to be biffed
[18:35:00] <Avenger> to avoid duplication of the same files, we need them shared
[18:35:07] <fuzzie> well, for svn it is not very nice to .bif them
[18:35:17] <Avenger> yeah, only for install
[18:35:30] <Avenger> and mostly only for release install
[18:35:54] <fuzzie> we'd have to be careful that the .bif would be lowest-priority, i guess
[18:36:35] <Avenger> i say lets finish the projectiles first. then we can find the duplicates and work on the shared sutff
[18:36:36] <Avenger> stuff
[18:37:05] <CIA-18> gemrb: 03fuzzie * r6546 10/gemrb/trunk/gemrb/plugins/Core/ActorBlock.cpp: traps shouldn't usually be detected on trigger
[18:38:40] <lynxlynxlynx> i see why you can equip unindentified items
[18:38:42] <Avenger> are traps detected on trigger at all?
[18:38:53] <lynxlynxlynx> we disallow it only for quickslots
[18:38:55] <Avenger> lynx: you can usually equip them
[18:39:00] <lynxlynxlynx> like potions
[18:39:18] <lynxlynxlynx> they should grant effects though
[18:39:26] <Avenger> they do
[18:39:39] <lynxlynxlynx> err, shouldn't?
[18:39:41] <fuzzie> i tried in original bg1 with a ring of protection +1, and it gave me the AC bonus
[18:39:44] <Avenger> you can equip unidentified armor and they do
[18:39:55] <Avenger> that works in all games
[18:39:56] <lynxlynxlynx> that makes sense wrt realism
[18:39:57] <fuzzie> i thought it didn't work, so i am confused :(
[18:40:13] <Avenger> they just don't let you use abilities marked with 'need id'
[18:40:14] <lynxlynxlynx> don't see why SLOT_ITEM is an exception though
[18:40:23] <Avenger> because the original game does that too :D
[18:40:45] <lynxlynxlynx> wierd
[18:41:03] <Avenger> but i think only when their first ability is 'need id'
[18:41:10] <Avenger> i think i already implemented that
[18:41:40] <Avenger> you can make items whose ability could be used without identifying it :)
[18:42:38] <Avenger> i think i made a potion for dltc where the first ability was an explosion, and the second was some beneficial effect
[18:42:58] <lynxlynxlynx> hehehe
[18:43:12] <Avenger> it was some explosion potion, the second ability was to throw it at someone
[18:43:30] <Avenger> so, without identify one could still drink it :D
[18:43:47] <Avenger> i'm sure it was possible to put it in the quick item slot
[18:47:59] <Avenger> we already made more commits than last month
[18:48:11] <Avenger> and we got 10 more days :)
[18:48:56] <-- pupnik has left IRC ("Leaving")
[18:49:11] --> pupnik has joined #gemrb
[18:49:24] <-- Avenger has left IRC ("bye!")
[18:56:09] <fuzzie> lynxlynxlynx: portraits are not updated on heals
[18:57:27] <fuzzie> the EF_PORTRAIT in the pcf_hitpoint and friends (maxhitpoint, minhitpoint) seem to have gone AWOL
[18:57:42] <fuzzie> i guess that was intentional, but then some more effects need them?
[18:59:56] <CIA-18> gemrb: 03fuzzie * r6547 10/gemrb/trunk/gemrb/plugins/Core/ActorBlock.cpp: don't trigger ST_PROXIMITY traps based on operating distance, it leads to disaster
[19:00:07] <fuzzie> that fixes the dreugar/assassin scene nicely, after i spent ages trying to work out what was going wrong
[19:00:49] <fuzzie> perhaps the fix is that ClearTrap should be checking distance, but i didn't find any traps which are operated by distance..
[19:04:04] <fuzzie> There are no longer any disasterous script failures in the dungeon, anyway.
[19:04:56] --> barra_away has joined #gemrb
[19:06:12] <lynxlynxlynx> cool
[19:06:18] <lynxlynxlynx> i'll look at that hp thing
[19:07:25] <lynxlynxlynx> Avenger: you know what would make spellcasting instantly prettier? Not starting the animation at the actors center, but between the hands
[19:10:34] <fuzzie> did someone fix that for arrows yet?
[19:10:56] <lynxlynxlynx> i still get every ~3 attack from behind the actor
[19:11:12] <lynxlynxlynx> without any shooting animation
[19:16:35] <fuzzie> so, Tutu handles weapon breaking using an effect
[19:16:52] <fuzzie> due to lack of bg2 engine support
[19:16:56] <CIA-18> gemrb: 03lynxlupodian * r6548 10/gemrb/trunk/gemrb/plugins/Core/Actor.cpp: reinstated two EF_PORTRAIT's
[19:17:08] <lynxlynxlynx> did bg1 support it?
[19:17:46] <lynxlynxlynx> i think they coded the thing but disabled/removed it in the end for playability reasons
[19:17:54] <fuzzie> yes, bg1 breaks weapons normally, about 1% chance per hit
[19:19:01] <fuzzie> it's very annoying for the first half or so of the game
[19:19:13] <lynxlynxlynx> another game flag?
[19:20:28] <fuzzie> i am thinking GF_BREAKWEAPONS :)
[19:20:54] <fuzzie> i'm also quite convinced mattinm is right and it's nothing to do with critical misses
[19:21:47] <-- barraAway has left IRC (Read error: 110 (Connection timed out))
[19:23:03] <fuzzie> and 1 in 100 doesn't sound unreasonable
[19:23:44] <fuzzie> i think this critical misses thing comes from someone reading ad&d rules
[19:26:11] <fuzzie> darn difficult to find any info, though, everyone is playing tutu with its fixed 1% chance
[19:31:14] --> Avenger has joined #gemrb
[19:31:17] --- ChanServ gives channel operator status to Avenger
[19:32:44] <Avenger> yes, i think break weapons is a bg1 specific thing. it is part of the bg1 story, the weapons are made from some corrupted iron
[19:33:35] <fuzzie> you can end up with broken weapons even before leaving Candlekeep sometimes, it is pretty annoying :)
[19:34:01] <CIA-18> gemrb: 03wjpalenstijn * r6549 10/gemrb/trunk/gemrb/GUIScripts/iwd2/MessageWindow.py: Attempt at fixing unresponsive IWD2 controls when starting a new game
[19:34:09] <Avenger> don't you get a magic weapon inside?
[19:34:17] <Avenger> some dagger?
[19:34:20] <fuzzie> but i think it also applies to shields/armour
[19:34:52] <wjp> re. that IWD2 patch: I'm not 100% sure it's the correct fix, but it at least indicates where the problem is/was :-)
[19:34:54] <fuzzie> no, but you can get one about 5 areas away if you know where to look, i think
[19:35:49] <fuzzie> wjp: it works now?
[19:36:03] <wjp> yes
[19:36:40] <fuzzie> so it does :) nice
[19:36:58] <wjp> switching into dialogue mode broke the event handlers for the buttons
[19:37:45] <wjp> (or rather, switching back didn't restore them)
[19:43:40] <fuzzie> Hm, I got stuck in an infinite loop there..
[19:44:03] <fuzzie> Something was continually doing MoveToPoint() and failing to find a path.
[19:46:36] <fuzzie> was probably UseContainer() calling GoNearAndRetry
[19:46:49] <fuzzie> but the GoNearAndRetry code actually has magic for avoiding deadlocks
[19:47:46] <fuzzie> Oh. UseContainer() on a pile requires a distance of 0 so the deadlock avoidance fails
[19:48:33] <Avenger> sucks
[19:48:34] <fuzzie> Avenger: is it okay if I just add 1 to distance when I set it on the MoveToPoint action, and subtracting one in the action itself?
[19:49:11] <Avenger> i don't see how will that help
[19:49:20] <fuzzie> becuase then int0Parameter will be 1
[19:49:28] <Avenger> just try it, i guess
[19:49:38] <fuzzie> and the MoveToPoint code will know it has to do deadlock avoiding :)
[19:50:49] <Avenger> i have already forgot how it was done, sorry
[19:51:07] <Avenger> too much code, and even more tricks to keep in mind :)
[19:51:35] <fuzzie> Sometimes I even forgot that I wrote code, and I didn't really write so much..
[19:56:09] <CIA-18> gemrb: 03fuzzie * r6550 10/gemrb/trunk/gemrb/plugins/Core/ (Actions.cpp GSUtils.cpp): add a hack to MoveToPoint deadlock detection to cope with distance==0 (eg, piles)
[19:56:55] <Avenger> why only piles
[19:57:10] <fuzzie> Avenger: Is there a reason why InfoPoint::Entered() on infopoints triggers if the actor is within operating distance of Pos? i had to disable it for proximity infopoints because it broke things
[19:57:15] <Avenger> wouldn't it be easier to hack piles to resemble normal containers?
[19:57:19] <fuzzie> because you must be on top of piles to open them :)
[19:57:36] <fuzzie> otherwise it works when you're a searchmap block away, and this is not correct
[19:58:20] <Avenger> no idea about the infopoint
[19:58:23] <fuzzie> but i didn't think very hard about it, i just wanted to fix the bug
[19:58:37] <Avenger> make sure you don't break pst either :)
[19:58:39] <fuzzie> okay, it was code from 2005 or something, and i commented that change also :)
[19:58:47] <Avenger> ok
[19:59:15] <Avenger> it is good to note what did you fix, so if it needs to be reverted, it could be checked against that
[20:00:18] <Avenger> i'm pretty sure that there are engine quirks that cannot be fixed without breaking another engine variant
[20:00:33] <fuzzie> well, then we have to start using GF_ flags in more places
[20:00:43] <Avenger> yep
[20:00:44] <fuzzie> do you think we should add one for weapon breaking?
[20:00:48] <Avenger> yes
[20:00:51] <Avenger> that seems clear
[20:01:04] <Avenger> though i don't see what it breaks
[20:01:09] <fuzzie> i think a flag would be nice, because mods might want it
[20:01:12] <Avenger> most weapons are not marked breakable in bg2
[20:01:27] <fuzzie> yes, but a lot of the basic bg2 weapons are marked breakable
[20:01:28] <lynxlynxlynx> most is not good enough
[20:01:37] <lynxlynxlynx> even some magic ones
[20:01:55] <Avenger> i see
[20:01:57] <fuzzie> presumably they just copied those from bg1 and didn't unset the flags
[20:02:02] <fuzzie> because nothing ever breaks in bg2
[20:02:02] <lynxlynxlynx> mazzy's holy sword for example (i think one of the fixpacks changes this)
[20:02:09] <Avenger> wait
[20:02:14] <Avenger> why would the fixpack change it
[20:02:22] <Avenger> if it doesn't break in bg2???
[20:02:23] <fuzzie> the fixpackers change all kinds of pointless flags
[20:02:28] <fuzzie> because "things should be correct!"
[20:02:28] <lynxlynxlynx> it does break
[20:02:36] <fuzzie> oh, it does?
[20:02:38] <Avenger> mazzy's sword breaks in bg2?
[20:02:52] <fuzzie> huh, then we have a problem, because i couldn't make anything break in bg2 with thousands and thousands of hits
[20:02:53] <Avenger> then bg2 has the break feature :D
[20:02:59] <lynxlynxlynx> wait
[20:03:11] <fuzzie> and the tutu/etc people say that it is not in the engine
[20:03:28] <Avenger> in bg1 it is in the engine
[20:03:30] <lynxlynxlynx> i was trying to say that it is bad to rely on the unbreakable bit set
[20:03:47] <lynxlynxlynx> since i did break mazzy's sword in a pp fight
[20:03:49] <Avenger> ok, so mazzy's sword doesn't break in original bg2
[20:04:00] <lynxlynxlynx> not sure
[20:04:14] <lynxlynxlynx> maybe what i think i remember is also just a cosmetic fix
[20:04:48] <Avenger> npsw01 is mazzy's sword
[20:04:50] <Avenger> i have fixpack
[20:04:58] <Avenger> and this sword still has the breakable flag
[20:05:24] <Avenger> meh, i think we need that GF_ flag
[20:05:40] <Avenger> i'm almost sure i didn't see weapons break outside of bg1
[20:07:08] <lynxlynxlynx> i'm sure i didn't see it in bg2
[20:07:22] <lynxlynxlynx> almost as sure for iwd2
[20:11:45] <pupnik> so you will default to UNbreakable, but provide a breakable flag?
[20:11:55] <fuzzie> yes
[20:12:08] <fuzzie> for use in bg1, and mods which wish it
[20:29:42] <Avenger> we need this flag because of lazy game developers
[20:30:07] <fuzzie> If it weren't for lazy game developers I think we could lose half of the flags.
[20:30:22] <Avenger> in an open source world, there would have been a small tool which converted bg1 items to bg2
[20:30:59] <fuzzie> Hm, maybe not. We could've done without a few, anyway.
[20:31:21] <Avenger> a lot of hacks are needed because of a few crappy exceptions
[20:31:47] <fuzzie> I think the real trouble is that we probably need a lot of flags for things we didn't find yet.
[20:31:55] <Avenger> yep
[20:31:57] <fuzzie> devSin talks about a lot of nasty differences between IE versions.
[20:32:13] <Avenger> some differences could be done without flags
[20:32:25] <Avenger> but not this breakable thing
[20:35:15] <lynxlynxlynx> [CharAnimations]: Couldn't create animationfactory: mgo2 yay
[20:35:37] <fuzzie> whoever decided that animations should be hard-coded in the original exe was a very bad person
[20:40:42] <Avenger> yes
[20:41:29] <Avenger> it is really amazing pst didn't hardcode them
[20:42:33] <Avenger> hmm the unknown spark flag 0x20, has something to do with sparks
[20:42:42] <fuzzie> i think they were short on programmer time, so they probably wanted to let the designers do as much work as possible
[20:42:56] <Avenger> this may sound weird, but the whole spark flags bitfield has 2 bits about sparks ;)
[20:43:12] <fuzzie> maybe not quite the right name? :)
[20:43:31] <Avenger> well, the original iesdp description knew only about the lowest bit
[20:43:34] <Avenger> so the name stuck
[20:44:01] <Avenger> at least it is clear which bitfield we talk about
[20:49:05] <Avenger> heh i love when i spend 10 minutes to determine the usage of a field, go to the struct definition, and see it was already determined :)
[20:49:27] <Avenger> it is still better than finding some conflicting definition there
[20:57:17] <fuzzie> Ugh.
[20:57:38] <fuzzie> devSin pointed out something annoying
[20:57:49] <fuzzie> MoveToObject([PC]) moves to the nearest PC
[20:58:07] <fuzzie> that is not "it picks the nearest PC and then moves to it"
[20:58:45] <fuzzie> it is "it moves to the nearest PC, and if that changes as it moves, it changes to the new nearest PC"
[20:59:35] <lynxlynxlynx> could be useful for initiating dialog
[20:59:53] <fuzzie> so blocking actions truly need to re-execute every frame
[21:00:12] <Avenger> are you sure it does that?
[21:00:23] <fuzzie> Avenger: i just spent half an hour with it in SoA
[21:01:05] <Avenger> this will cause a lot more computing
[21:01:07] <fuzzie> ActionOverride(Player1, MoveToObject([PC])), then jump the nearer PC away with ctrl-j, and player1 will switch to the next nearest PC while walking
[21:01:56] <fuzzie> maybe there is a flaw in my test method? but i think it is ok
[21:05:55] <fuzzie> i don't see how on earth that would work with things like LastSeen
[21:06:00] <fuzzie> i will post on the forum again
[21:10:34] <lynxlynxlynx> what about if you just move him away? maybe there is a distance threshold
[21:11:12] <lynxlynxlynx> or does it really switch on any movement?
[21:11:18] <fuzzie> haven't tested yet
[21:11:20] <fuzzie> will do now
[21:11:51] <fuzzie> switches on any movement
[21:12:20] <Avenger> what if you move someone closer
[21:12:26] <Avenger> will it switch to that one?
[21:12:35] <fuzzie> Avenger: that is very difficult to tell
[21:12:46] <fuzzie> i'll check in a minute
[21:12:58] <fuzzie> i just found out that a lot of our AddTrigger calls are bad
[21:12:59] <Avenger> just make a long walk, and then ctrl-j someone near it
[21:13:20] <Avenger> because triggers are cleared between rounds?
[21:13:42] <fuzzie> yes
[21:13:48] <fuzzie> and LastSeen should not be, for instance
[21:14:22] <Avenger> hehe, it would make a simpler system
[21:14:24] <fuzzie> devSin says most of the Last stuff persists forever (but it is not saved, you discuss this in the same threead)
[21:14:35] <fuzzie> i don't know if all of it does, we'll have to see
[21:15:01] <Avenger> so, you say some Last... are cleared, and some are not?
[21:15:16] <fuzzie> maybe none of them are cleared
[21:15:44] <Avenger> hehe, sounds like you are just as confused as i am
[21:16:04] <fuzzie> > Persistent objects are marked by certain triggers and actions; these are usually the "Last" objects. When these objects are assigned, they remain valid for the session
[21:16:19] <fuzzie> that is the last post in the thread i linked from my last forum post, if you're interested
[21:18:50] <fuzzie> ok, yes, if you move someone else closer without moving the original person, it still goes to the nearer
[21:18:58] <fuzzie> so i am afraid someone gets to rewrite the blocking code
[21:21:19] <fuzzie> the original BG1 script manual seems to imply that the only optimisation they did was that the engine does *not* repathfind unless the target moved, so i guess it simply checks Destination coords before re-pathing
[21:27:04] <fuzzie> and that is not so bad computation-wise, it is relatively rare for anything to have a blocking action *and* be moving, it is just that a lot of scripts depend on it
[21:27:39] <fuzzie> it would mean that we could move the attack code into the Attack() actions and friends, which would maybe solve a lot of problems..
[21:28:07] <fuzzie> but that is for a later time
[21:28:15] <Avenger> hmm
[21:28:29] <Avenger> well, it sounds interesting
[21:29:34] <fuzzie> We could also get rid of all these hacks where we AddActionInFront() ourselves repeatedly
[21:30:56] <Avenger> hmm it seems the original IE had 3 lists just for sparkles :)
[21:31:26] <Avenger> and this flag selects between spark list 0 and spark list 1
[21:31:49] <Avenger> most likely this is something like draw over actors and draw under actors, etc
[21:33:09] <fuzzie> Avenger: did you ever RE any of the actions?
[21:33:27] <Avenger> triggers surely, i think actions too
[21:33:43] <Avenger> i sent you the list for their entry points
[21:33:44] <fuzzie> i'm wondering if we can just replace Wait() and etc with blocking actions, i think all of this code could be much tidier
[21:33:55] <fuzzie> but maybe you know that the original engine did no such thing
[21:34:42] <Avenger> I'm almost sure the engine simply kept them on the top of the queue
[21:35:10] <fuzzie> that sounds the correct thing to do, just keep them at the top of the queue and re-execute them every frame
[21:35:55] <Avenger> i'm fine with that, just don't break anything
[21:36:26] <fuzzie> I think I might break a lot, so I'll probably do this as a patch for a while.
[21:36:42] <fuzzie> I think lynx wants to do a release on Thursday.
[21:37:22] <fuzzie> And maybe I can work on other things in the meantime.
[21:38:39] <lynxlynxlynx> Avenger: i said something to you before, but didn't notice you weren't here
[21:38:43] <lynxlynxlynx> Avenger: you know what would make spellcasting instantly prettier? Not starting the animation at the actors center, but between the hands <--
[21:39:19] <lynxlynxlynx> manipulating the energy with your hand and all
[21:39:27] <Avenger> you could work on that yourself :D
[21:39:34] <Avenger> just make new projectiles
[21:39:36] <Avenger> hehe
[21:39:52] <Avenger> all those casting anims are in fact projectiles with the 'flying' spark flag set
[21:39:53] <pupnik> evil :)
[21:39:55] <lynxlynxlynx> oh, i thought it was just a bad origin
[21:40:02] <Avenger> it is
[21:40:17] <Avenger> but the flying spark flag is about that: raising the projectile
[21:40:25] <Avenger> and they should be a projectile anyway
[21:40:31] <Avenger> so, it is a win-win :D
[21:40:52] <fuzzie> except none of us except you have the slightest clue where to start on making all these projectiles, i think :)
[21:40:55] <Avenger> i will probably make one
[21:41:04] <Avenger> then it is just a cut&paste
[21:41:17] <Avenger> just lemme find wtf is this spark flag
[21:41:30] <Avenger> i think i'm on the trail
[21:41:49] <Avenger> yeah
[21:41:54] <lynxlynxlynx> woah
[21:42:08] <lynxlynxlynx> i think your innate fix was bad
[21:42:12] <Avenger> the new flag makes the spark covered by actors, it is more like a slimy snail trail :D
[21:42:21] <lynxlynxlynx> now casting normal spells gives me wierd choices
[21:42:31] <Avenger> really?
[21:42:38] <lynxlynxlynx> yep
[21:43:02] <lynxlynxlynx> btw, take knock for example - we already draw everything and more (the ugly sparkles)
[21:43:24] <lynxlynxlynx> what would need changing for that to start forming in the hands?
[21:43:50] <lynxlynxlynx> or melf
[21:43:55] <pupnik> code?
[21:44:16] <Avenger> very small code
[21:44:54] <lynxlynxlynx> are there any spell anims that don't start at the hands?
[21:45:04] <Avenger> no
[21:45:19] <Avenger> all CG graphics is raised
[21:45:52] <Avenger> but the vvc doesn't have that flag, you could simply adjust its coordinates, though
[21:46:08] <lynxlynxlynx> so can't we just add special code for our custom ones somewhere high, not in each individual?
[21:47:15] <lynxlynxlynx> hard to test this now
[21:47:57] <pupnik> maybe need a new data structure effect_offset(int x, int y)
[21:48:41] <Avenger> see fx_casting_glow in fxopc.cpp
[21:48:58] <Avenger> int heightmod = target->GetAnims()->GetCircleSize()*12;
[21:49:01] <lynxlynxlynx> the innates are picked in reverse order
[21:49:07] <Avenger> that needs to be fixed
[21:49:30] <pupnik> u da man
[21:50:27] <Avenger> anyway, this will be removed later when i convert them to projectiles :)
[21:50:53] <Avenger> most likely the constant 50 in projectiles is bad too
[21:51:01] <lynxlynxlynx> the height may even be ok, but one or both of the x/y is bad
[21:52:08] <lynxlynxlynx> nah, all are bad
[21:52:10] <Avenger> feel free to adjust those
[21:52:50] <Avenger> they will be ported to projectiles when i convert the cg to projectile, so don't be afraid you won't work in vain
[21:53:46] <Avenger> i just need the conversion because the cg are also available as projectile, and we need maximum compatibility
[21:56:34] <Avenger> hmm, probably height is not correct, i guess a gnome's hands are not the same height as an human's
[21:56:53] <lynxlynxlynx> yeah
[21:57:18] <lynxlynxlynx> don't we have the actor height somewhere?
[21:57:19] <Avenger> guess it should use the avatar.2da height info
[21:57:29] <Avenger> yes we have it
[21:57:39] --> pupnik_ has joined #gemrb
[21:58:05] <lynxlynxlynx> are pc races also in there?
[21:58:22] <Avenger> pc races?
[21:58:50] <Avenger> the humans in the game usually use a human pc avatar, yes
[21:58:52] <lynxlynxlynx> if i want to get the elven height
[21:59:09] <fuzzie> OK, it would be nice if no-one touches the action code for a few days.
[21:59:10] <Avenger> mage/cleric/fighter etc
[21:59:14] <fuzzie> I have to rewrite a lot of this.
[21:59:19] <Avenger> hehe
[21:59:31] <Avenger> brace yourselves
[21:59:56] <lynxlynxlynx> doh
[22:00:04] <lynxlynxlynx> too late to think clear
[22:00:26] <Avenger> yep,
[22:00:30] <Avenger> gotta sleep
[22:00:34] <-- Avenger has left IRC ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]")
[22:07:07] <-- lynxlynxlynx has left IRC (Remote closed the connection)
[22:15:20] <-- pupnik has left IRC (Read error: 101 (Network is unreachable))
[22:41:11] <CIA-18> gemrb: 03avenger_teambg * r6551 10/gemrb/trunk/gemrb/plugins/Core/EffectQueue.cpp: added timing mode 8 to some lists (equipped effect, live effect)
[22:47:04] <CIA-18> gemrb: 03avenger_teambg * r6552 10/gemrb/trunk/gemrb/plugins/Core/EffectQueue.cpp: probably fixed the removable effect timing modes (delayed effects are removable, equipping effects are not)
[22:51:23] <fuzzie> A lot of this code looks like it's already meant to do what I'm doing, and then someone broke it..
[23:01:38] <Edheldil> :)
[23:03:10] <CIA-18> gemrb: 03fuzzie * r6553 10/gemrb/trunk/gemrb/plugins/Core/Region.cpp: implement missing Point::operator!=
[23:07:17] <fuzzie> There are ReleaseCurrentAction() calls everywhere in blocking actions.
[23:07:28] <fuzzie> It makes my job a lot easier, I just have to add the missing ones, remove the broken ones, etc.
[23:25:22] <fuzzie> ok, the trap at the start of bg2 kills people in moments now
[23:25:44] <fuzzie> i thought it might be my changes, but it isn't
[23:27:49] <pupnik_> :/
[23:28:38] <pupnik_> did the work on rounds/initiative affect a time factor?
[23:32:54] <fuzzie> no-one updated poison/disease for new gametime
[23:33:08] <fuzzie> i don't understand why it seemed ok before, though
[23:33:12] <fuzzie> i think someone must've fixed poisoning
[23:34:25] <fuzzie> hm, this doesn't help :(
[23:35:55] <CIA-18> gemrb: 03fuzzie * r6554 10/gemrb/trunk/gemrb/plugins/FXOpcodes/FXOpc.cpp: try to fix poison/disease timings (untested)
[23:49:08] <pupnik_> hmm