#gemrb@irc.freenode.net logs for 2 Oct 2009 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[02:11:52] --> Darki has joined #gemrb
[02:22:48] <-- Dark-Star has left IRC (Read error: 110 (Connection timed out))
[03:07:41] <-- wjp has left IRC (orwell.freenode.net irc.freenode.net)
[03:10:12] --> wjp has joined #GemRb
[07:11:11] --> lynxlynxlynx has joined #gemrb
[07:11:11] --- ChanServ gives channel operator status to lynxlynxlynx
[07:50:14] <fuzzie> morning
[07:52:30] <lynxlynxlynx> oj
[07:59:02] <CIA-22> gemrb: 03lynxlupodian * r7317 10/gemrb/trunk/gemrb/ (9 files in 8 dirs): limited backstab to weapon thieves can use and added more feedback
[08:01:51] <lynxlynxlynx> now for the deathvar test
[08:03:39] <fuzzie> i am just going to steal a machine and install pst and iwd2 so that i can test all circumstances
[08:04:13] <fuzzie> but that doesn't test the patch :)
[08:04:39] <fuzzie> i fixed the jail bug, too
[08:05:05] <lynxlynxlynx> i saw :)
[08:06:05] <fuzzie> very grateful to zefklop's test suite, which sits in the tracker
[08:06:17] <fuzzie> i just tweaked his scripts for every new test, re-ran weidu, magic :)
[08:21:18] <lynxlynxlynx> it works, you can commit it
[08:45:00] <fuzzie> well, i think it doesn't work much :)
[08:45:12] <fuzzie> you just tested the _DEAD, or all the vars?
[08:45:19] <fuzzie> i have to rewrite some other bits too, checking iwd2/pst first
[08:46:44] <lynxlynxlynx> i just tested _dead, yes
[08:47:49] <fuzzie> the problem is that i don't set this DeathVarFormat as expected, so the scripts will break
[08:48:01] <fuzzie> but i don't want to add iwd-specific hacks if pst and iwd2 are the same, so let's see
[08:52:02] <-- |Cable| has left IRC (Remote closed the connection)
[08:52:37] --- ChanServ gives channel operator status to Darki
[08:55:30] --- Darki is now known as Dark-Star
[09:09:15] <CIA-22> gemrb: 03lynxlupodian * r7318 10/gemrb/trunk/gemrb/plugins/IWDOpcodes/IWDOpc.cpp:
[09:09:15] <CIA-22> gemrb: fixed fx_summon_creature2 to handle parameter2==3 properly;
[09:09:15] <CIA-22> gemrb: belhifet's true form is now spawned hostile
[09:11:06] <fuzzie> i don't suppose you have any idea about this palette naming stuff, lynx?
[09:11:41] <lynxlynxlynx> nope
[09:12:25] <fuzzie> 21:19 <wjp> ugh, that named/unnamed palette stuff should be refactored out
[09:12:25] <fuzzie> ^- doesn't sound so nice :p
[09:12:47] <wjp> hm?
[09:13:03] <fuzzie> there's another crash in there, but i don't want to refactor it
[09:13:08] <fuzzie> it sounds like, well, work
[09:14:02] <fuzzie> i guess back to gdb
[09:20:54] <fuzzie> the crash is in the AreaAnimation destructor, name 'flame2m', bam 'flame2m', PaletteRef clearly corrupt (starts with \001)
[09:21:14] <fuzzie> i wonder where it's constructed from
[09:22:04] --> barra_library has joined #gemrb
[09:22:44] <fuzzie> oh, i guess it comes directly out of the ARE file
[09:26:05] <CIA-22> gemrb: 03fuzzie * r7319 10/gemrb/trunk/gemrb/plugins/Core/Map.cpp: AreaAnimation: be sure to clear PaletteRef when making a new palette
[09:27:25] <wjp> hm, surprising that bug lasted that long
[09:28:06] <fuzzie> yes
[09:38:57] --> barra_away has joined #gemrb
[09:41:18] <-- barra_library has left IRC (Nick collision from services.)
[09:41:22] --- barra_away is now known as barra_library
[09:56:41] <fuzzie> interesting things from pst save .. no death vars set as expected, CURRENT_AREA is 202 when in ar0202, EVIL_ZM985_1 is set (i guess i killed it?), GOOD is 1 along with one GOOD death var, PREVIOUS_AREA is 202 also
[09:56:58] <fuzzie> KILL_ZOMBIE is set to the number of zombies i killed - race again? - along with the _DEAD variables, in the kaputz vars
[09:58:24] <fuzzie> yes, looks like KILL_%s is the race from iwd
[10:00:42] <fuzzie> and gemrb doesn't set EVIL_%s etc in globals for pst, maaaybe it should
[10:01:26] <fuzzie> am disappointed that pst has no cool alt-f4 message
[10:05:25] <lynxlynxlynx> hell will miss you?
[10:11:45] <fuzzie> so, i killed a bunch of goblins in iwd2
[10:12:08] <fuzzie> and i get _DEAD1000_GOBLIN_01 and 02, 03, 06, 07, _DEAD1000_GOBLIN_ARCHER_01
[10:12:22] <fuzzie> and 1000_GOBLIN_01_DEAD with also 02, 03, 06, 07
[10:12:30] <fuzzie> and 10GOBD set to 6, total number of kills
[10:12:47] <fuzzie> as well as both _REVEALED and _VISITED for ar1000 without having gone anywhere
[10:12:57] <fuzzie> so i guess this is yet again completely different
[10:13:02] <lynxlynxlynx> you're not in ar1000 then?
[10:13:31] <fuzzie> i am in ar1000
[10:13:35] <fuzzie> just interesting that _REVEALED is set immediately
[10:13:54] <fuzzie> these goblins are named 1000_goblin_01 etc, so that makes sense
[10:14:35] <fuzzie> _DEAD%s and %s_DEAD is kind of odd for a death var, considering the archer is missing from the %s_DEAD variety
[10:15:27] <fuzzie> i guess 10GOBD is the 'tertiary scripting name' which gemrb lists under "Icewind Dale II specific"
[10:15:46] <fuzzie> ah, the archers don't have 'set death var' set
[10:16:04] <fuzzie> and none of these have 'killvar count' set
[10:16:28] <fuzzie> let me set 'killvar count' on the goblins and restart
[10:16:35] <lynxlynxlynx> uh
[10:16:44] <lynxlynxlynx> i wonder why they needed so many counters
[10:17:04] <fuzzie> well, that's my question for iwd: why four counters?!
[10:19:04] <fuzzie> okay, so 'killvar count' sets this KILL_%s_CNT for race
[10:20:05] <fuzzie> _DEAD%s is always set, 'set death var' sets %s_DEAD, and <tertiary script name> is incremented by one at death
[10:20:09] <fuzzie> so this is basically the same as iwd
[10:20:19] <fuzzie> and gemrb's DeathVarFormat makes no sense whatsoever
[10:21:07] <lynxlynxlynx> :)
[10:39:37] <fuzzie> IESDP's Dead documentation just talks about 'death variable's, meh
[10:40:25] <fuzzie> oh, right, iwd is the one full of hilarious Dead("yself)") entries
[10:40:37] <fuzzie> and Dead("ENEMY]") and Dead("astSeenBy(Myself)") and etc
[10:45:04] <fuzzie> i guess iesdp's iwd2 cre page documents those 'set death var' and 'killvar count' flags
[10:45:10] <fuzzie> even if it gets KILL_%s_CNT wrong
[10:49:26] <fuzzie> oh, great, our CRE loader just ignores these
[10:49:54] <fuzzie> okay, i guess i'll just rewrite this and commit
[10:57:11] <fuzzie> gemrb has been silently corrupting saves, in any case
[10:57:20] <fuzzie> so you have to restart iwd games for this to work
[10:57:55] <fuzzie> "various scripting flags currently down the drain", as the comments say
[11:06:07] <CIA-22> gemrb: 03fuzzie * r7320 10/gemrb/trunk/gemrb/plugins/ (CREImporter/CREImp.cpp Core/Actor.h): don't drop important CRE flags down the drain
[11:11:24] <CIA-22> gemrb: 03fuzzie * r7321 10/gemrb/trunk/gemrb/plugins/Core/Interface.cpp: disable incorrect iwd deathvar override
[11:14:03] <fuzzie> lynxlynxlynx: around?
[11:14:11] <lynxlynxlynx> yeah
[11:14:22] <lynxlynxlynx> fighting with the resistance thing
[11:18:58] <fuzzie> i really wish DLTCEP showed me all the data
[11:19:11] <fuzzie> i'll have to bug Avenger when he returns
[11:27:27] <CIA-22> gemrb: 03fuzzie * r7322 10/gemrb/trunk/gemrb/plugins/Core/Actor.cpp: try to fix iwd-style death variables
[11:33:02] * fuzzie prods at svn
[11:33:30] <fuzzie> it made it half way through and is now sulking
[11:34:06] * fuzzie pokes CIA-22
[11:35:14] <lynxlynxlynx> yeah, it is randomly dodgy lately
[11:35:47] <fuzzie> it ended up throwing an internal server error, hum
[11:36:30] <CIA-22> gemrb: 03fuzzie * r7323 10/gemrb/trunk/gemrb/ (5 files in 5 dirs): GF_IWD_DEATHVARFORMAT -> GF_IWD2_DEATHVARFORMAT, used only in iwd2, which is _DEAD%s
[11:36:42] <fuzzie> okay, i think i'm all done with death variables for the moment
[11:37:15] <fuzzie> would appreciate some confirmation that i did fix your problem
[11:37:17] <fuzzie> because i changed the logic completely
[11:37:33] <fuzzie> oh, heh, it's not going to work actually, your savegame will be corrupt :(
[11:37:53] <fuzzie> it'll only work if the creature in question gets reloaded, so might need to back up a bit
[11:38:33] <lynxlynxlynx> only the dead one is really important
[11:38:45] <fuzzie> that one gets set depending on a flag in the CRE
[11:38:53] <lynxlynxlynx> i didn't have to hackset any of the others to get over problems
[11:39:08] <fuzzie> and before r7320, gemrb just dropped those flags down the drain
[11:39:12] <lynxlynxlynx> but the count ones may be important for the false pomab fight
[11:41:38] <fuzzie> and, well, i might have broken your walkthrough by fixing the main deathvar, because Dead() triggers will fail, but i guess you'll find out
[11:42:12] <fuzzie> i need to go through and fix all the other places where gemrb just discards important data from files, but not now
[11:43:39] <lynxlynxlynx> may walkthrough is complete, save for the final fight
[11:43:56] <lynxlynxlynx> don't know if it uses that trigger yet
[11:44:01] <fuzzie> well, and maybe this _DEAD problem :)
[11:44:30] <fuzzie> and that dratted Forge_On thing, i hope to work on that later
[11:44:51] <fuzzie> i guess i'm waiting on raevol to see if there are more showstoppers in bg1
[11:45:50] <lynxlynxlynx> this damage thing is pretty wierd
[11:46:17] <lynxlynxlynx> i see PerformAttack goes well and it ends up constructing a good projectile with a good damage effect
[11:46:19] <fuzzie> i have long since lost track of how it's meant to work
[11:46:31] <lynxlynxlynx> it doesn't get applied though
[11:46:58] <lynxlynxlynx> maybe i should attack it with bisect instead
[11:47:24] <fuzzie> printfs all over the apply code don't help?
[11:48:22] <lynxlynxlynx> there's only one place where it gets applied
[11:49:58] <fuzzie> i mean, you got all the way to where, 'attackProjectile = pro'?
[11:50:13] <lynxlynxlynx> yes, now i'm checking Actor::Draw
[11:50:18] <fuzzie> and it gets to the AddProjectile(attackProjectile, ...) call?
[11:50:23] <fuzzie> ok
[11:51:05] <fuzzie> it looks like that Draw code assumes that all attackProjectiles are ranged weapons?
[11:51:38] <lynxlynxlynx> melee combat seems to also produce projectiles to do the damaging
[11:51:40] <fuzzie> i assume that's not the bug, but still, eek
[11:51:59] <fuzzie> well, that code to check for the 8th frame was added to fix the bow animations
[11:52:30] <lynxlynxlynx> i'll have to check when, but i don't think it was recent
[11:52:34] <fuzzie> i guess, as the comment implies, that code shouldn't be in Draw anyway
[11:52:43] <fuzzie> yes, i don't think it's your bug, it's just *a* bug
[11:54:20] <fuzzie> especially since it just uses LastTarget without considering that LastTarget might have changed, etc. meh.
[11:55:11] <lynxlynxlynx> ctrl-m works since it has another way of getting lastActor if it's null
[11:58:34] <lynxlynxlynx> the frame is varying, but 39 most of the time
[11:58:50] <fuzzie> does it work if you just comment out the frame check?
[11:59:15] <lynxlynxlynx> finally an 8
[11:59:25] <lynxlynxlynx> but i am immune to normal weapons :)
[11:59:34] <lynxlynxlynx> i'll wrap it in a ranged weapon check
[12:00:05] <fuzzie> the thing is, you might have changed weapons by the time this code gets run
[12:00:11] <lynxlynxlynx> true
[12:00:18] <fuzzie> difficult problem
[12:01:34] <fuzzie> i guess there's no harm in adding more hacks, it needs more thought anyway
[12:01:47] <lynxlynxlynx> last change was at the start of august, but that just moved the code; it originated in june
[12:02:02] <lynxlynxlynx> so i wonder what changed that this doesn't work anymore
[12:02:37] <fuzzie> there are a whole bunch of bugs there; my first thought would be that something zaps LastTarget?
[12:04:06] <fuzzie> i can't find anything which would do that, though
[12:06:35] <lynxlynxlynx> commenting the frame check out didn't have an effect
[12:06:47] <lynxlynxlynx> kinda good
[12:06:54] <fuzzie> yes :)
[12:11:09] <fuzzie> meh, silly forums
[12:16:33] <fuzzie> hm, i don't think my race conclusion is correct
[12:16:50] <lynxlynxlynx> invalid stance ids
[12:16:55] <lynxlynxlynx> some look like overflows
[12:17:26] <lynxlynxlynx> lastTarget seems fine btw
[12:19:37] <fuzzie> ok, no, KILL_%s_CNT is definitely race
[12:19:48] <fuzzie> if i switch race of the goblins to ogre, then it's KILL_OGRE_CNT all of a sudden
[12:19:56] <fuzzie> i just had the test area already in my save, oops
[13:12:23] <-- barra_library has left IRC ("Verlassend")
[14:00:50] <fuzzie> ugh, our text rendering really needs some work
[14:01:47] <fuzzie> that Scar dialog snaps back and forth because the renderer seems to be trying to be clever and ignore previous lines, i think
[14:04:33] <fuzzie> and the Scar bug is just the standard bug where ActionOverride should set the no-interrupt flag
[14:54:58] --> barra_library has joined #gemrb
[15:05:12] <raevol> fuzzie: with the latest build that crash leaving the area is fixed
[15:05:20] <raevol> i just got called in to work, so i'll have to play more later
[15:16:26] <fuzzie> good to hear :)
[15:20:09] <fuzzie> hm, forums back
[15:20:21] <fuzzie> i wonder how long that will last
[15:21:03] <lynxlynxlynx> great
[15:23:16] <fuzzie> the posts on the summon effects are not as helpful as i'd thought
[15:23:41] <fuzzie> Avenger's comment is limited to just being doubtful about the IESDP interpretation
[15:24:44] <fuzzie> to me it looks like it could simply be bit-based
[15:26:42] <fuzzie> and Avenger already documented some of this iwd death variables stuff, so i don't see why he didn't implement it
[15:28:33] <fuzzie> anyway, the forum has less information in total across 8 threads than i already discovered myself, so i am happy
[15:28:55] <lynxlynxlynx> :)
[15:29:26] <fuzzie> did you get anywhere on working out where the projectile goes?
[15:30:47] <lynxlynxlynx> i started bisecting
[15:30:54] <lynxlynxlynx> i got sidetracked
[15:41:28] <lynxlynxlynx> time for some more, laws are boring
[15:50:55] <lynxlynxlynx> looks like the change to use a damage effect will be the reason for ctrl-y not working on the rakshasa anymore
[15:51:01] <lynxlynxlynx> just a few more commits to test
[15:58:20] <lynxlynxlynx> yep, that was it, r7253
[15:58:57] <lynxlynxlynx> kind of consistent with the combat thing too
[16:00:30] <lynxlynxlynx> so I'll look from ApplyEffect forward now
[16:00:51] <lynxlynxlynx> maybe the resistance changes really are the cause
[16:04:34] <lynxlynxlynx> yeah
[16:08:48] <lynxlynxlynx> actor->fxqueue.HasEffectWithParamPair(fx_level_immunity_ref, fx->Power, 0) returns an effect, so the actor is considered immune
[16:09:04] <lynxlynxlynx> which is true in a sense
[16:09:27] <lynxlynxlynx> the rakshasa have effects that grant immunity up to level 7 spells if i read that correctly
[16:10:10] <lynxlynxlynx> maybe we need to set another effect property like Power
[16:12:51] <fuzzie> shouldn't fx->Power be 0, and there be no level immunity effect for that?
[16:13:07] <lynxlynxlynx> it is 0
[16:13:58] <fuzzie> meh
[16:14:15] <lynxlynxlynx> Protection:SpellLevel (1-7, 0)
[16:14:18] <fuzzie> HasOpcodeWithParamPair doesn't check param1 if it's 0
[16:14:48] <fuzzie> maybe just don't call the HasEffectWithParamPair at all if fx->Power is 0?
[16:14:54] <fuzzie> i don't have any clue about how this works, i just babble
[16:15:21] <fuzzie> but it seems like level immunity should really only be checked if you actually have a level
[16:15:29] <lynxlynxlynx> indeed
[16:15:41] <fuzzie> so just a 'fx->Power &&' would be my first attempt
[16:18:16] <fuzzie> i wonder if i should mirror the g3 forums before they fall over again
[16:18:25] <lynxlynxlynx> that brough zapping back
[16:18:46] <lynxlynxlynx> now just need to break through the stone skins YAY
[16:18:56] <lynxlynxlynx> both are fixed
[16:19:01] <fuzzie> :)
[16:19:05] <lynxlynxlynx> time to check the baatezu
[16:26:00] <lynxlynxlynx> current HP:80 and he's marked as almost dead heh
[16:30:23] <lynxlynxlynx> eebelhi1.baf is stuck
[16:30:59] <lynxlynxlynx> maybe that ClearAllActions?
[16:31:16] <fuzzie> how?
[16:31:26] <lynxlynxlynx> ah no, eebeldth was searched for too
[16:31:47] <lynxlynxlynx> stuck in cutscene mode
[16:32:15] <lynxlynxlynx> eebeldth was the last that was run
[16:32:29] <fuzzie> the gui isn't visible?
[16:32:41] <lynxlynxlynx> no as in yes
[16:32:52] <fuzzie> if the gui disappeared and reappeared, you completed IWD
[16:33:14] <fuzzie> the game terminates there
[16:33:15] <lynxlynxlynx> i'll recheck
[16:33:28] <lynxlynxlynx> real easy now
[16:34:10] <lynxlynxlynx> just the death animation plays, then nothing else happens
[16:34:17] <fuzzie> it should try to play the 'credits' video, though
[16:34:29] <fuzzie> oh, heh
[16:34:40] <fuzzie> right, eebelkil has a CutSceneId(Myself)
[16:34:40] <lynxlynxlynx> doesn't get to eebelkil
[16:34:49] <fuzzie> that's Player1, but gemrb doesn't handle that
[16:34:55] <lynxlynxlynx> ok
[16:35:32] <fuzzie> that should be implemented very differently
[16:36:25] <fuzzie> for now you can just hack CutSceneID to check for a null GetActorFromObject and use something else instead, i think Sender would be fine
[16:36:32] <fuzzie> just to see if it works
[16:36:36] <CIA-22> gemrb: 03lynxlupodian * r7324 10/gemrb/trunk/gemrb/plugins/Core/EffectQueue.cpp:
[16:36:36] <CIA-22> gemrb: only check for level immunity if the effect has a level assigned;
[16:36:36] <CIA-22> gemrb: fixes rakshasa and belhifet (and globe of invulnerability)
[16:36:48] <fuzzie> (Actions.cpp:751)
[16:37:45] <fuzzie> oh, hm
[16:38:29] <fuzzie> okay, probably actually Actions.cpp:743 and change Sender to core->GetGame()->GetPC(0, false)
[16:38:29] <lynxlynxlynx> ok
[16:39:15] <fuzzie> not actually sure why it wouldn't work anyway though
[16:40:08] <fuzzie> and i guess you have to call ClearCutsceneID on the GetPC result too. hmph.
[16:40:14] <lynxlynxlynx> yeah, the first one didn't help
[16:41:16] <fuzzie> so i guess 'Scriptable *player1 = core->GetGame()->GetPC(0, false);' and then use that instead of Sender everywhere there
[16:41:28] <lynxlynxlynx> got it
[16:42:11] <fuzzie> the problem is that we're meant to peer into the script, steal the object from the first line (doesn't matter if it's CutSceneID), and then just dump the rest onto that object's script
[16:43:08] <fuzzie> but i don't see why eebelkil wouldn't work anyway with our current code
[16:43:41] <fuzzie> that Myself seems to return gs->MySelf, so it'll just get run in the context of belhifet?
[16:43:43] <lynxlynxlynx> it didn't get that far
[16:44:44] <fuzzie> if the .bcs gets loaded from disk at all, it looks like it should get far enough
[16:45:24] <lynxlynxlynx> like i said, eebeldth is the last one searched for
[16:45:36] <fuzzie> oh, huh
[16:46:03] <fuzzie> okay, let me go back to beginning
[16:46:19] <fuzzie> where does eebeldth get triggered from?
[16:46:40] <fuzzie> ar1105, i guess.
[16:47:03] <lynxlynxlynx> yes
[16:47:24] <fuzzie> EEBELHI1 is still alive?
[16:47:33] <lynxlynxlynx> yes
[16:49:23] <fuzzie> and no console errors about being unable to set cutsceneid?
[16:49:36] <fuzzie> oh, drat, that's a debug-only error
[16:49:49] <fuzzie> comment the lines around Actions.cpp:752 for a bit, i guess
[16:50:05] <lynxlynxlynx> no errors
[16:51:12] <lynxlynxlynx> you mean the original Actions.cpp:752, right?
[16:51:28] <fuzzie> yes. sorry, the 'InDebug&ID_CUTSCENE' line in CutSceneID
[16:53:10] <lynxlynxlynx> still doesn't print
[16:53:57] <fuzzie> my thoughts are: ClearAllActions() should zap anything running on EEBELHI1, it must get to StartCutScene("EEBELDTH") if it opens the script
[16:54:49] <fuzzie> and if CutSceneId doesn't fail, then everything in eebeldth gets added to EEBELHI1's script queue, and there's very very little there before EEBELKIL gets run
[16:55:02] <fuzzie> the MoveViewObject and Wait are harmless, at least
[16:56:33] <fuzzie> the ReallyForceSpell can't block, so PlaySequence is the obvious culprit, but it also doesn't block, so i'm left confused
[16:57:36] <fuzzie> i can only suggest adding printfs or turning on script debugging
[16:58:04] <lynxlynxlynx> some other time, need to go
[16:58:10] <fuzzie> bye!
[17:09:33] --> barra_away has joined #gemrb
[17:26:07] <-- barra_library has left IRC (Read error: 110 (Connection timed out))
[17:45:58] --> barra__out has joined #gemrb
[18:02:51] <-- barra_away has left IRC (Read error: 110 (Connection timed out))
[19:15:21] <-- lynxlynxlynx has left IRC (orwell.freenode.net irc.freenode.net)
[19:15:21] <-- wjp has left IRC (orwell.freenode.net irc.freenode.net)
[19:15:21] <-- barra__out has left IRC (orwell.freenode.net irc.freenode.net)
[19:16:56] --> lynxlynxlynx has joined #GemRb
[19:16:56] --> barra__out has joined #GemRb
[19:16:56] --> wjp has joined #GemRb
[20:11:26] --> Edheldil has joined #gemrb
[20:11:26] --- ChanServ gives channel operator status to Edheldil
[20:11:26] <fuzzie> hi, Edheldil
[20:12:55] <Edheldil> Hi, fuzzie
[20:13:11] <Edheldil> and others, of course
[20:25:10] --> Avenger has joined #gemrb
[20:25:17] --- ChanServ gives channel operator status to Avenger
[20:25:22] <Avenger> hello
[20:25:26] <fuzzie> hi, Avenger :)
[20:25:48] <Avenger> i'm a bit ill. probably got a flu. only slight fewer and scratching throat now
[20:25:56] <Avenger> fever i mean :)
[20:26:10] <fuzzie> sorry to hear that :( hope you feel better
[20:26:36] <Edheldil> me too, Avenger. Take rest and the usual stuff
[20:26:48] <Avenger> yep
[20:35:37] <-- tombhadAC has left IRC (Network is unreachable)
[20:40:53] --> tombhadAC has joined #gemrb
[20:51:54] <fuzzie> Avenger: does DLTCEP display iwd/iwd2 ARE-overrided scriptnames anywhere? or the flag?
[20:51:55] --> Maighstir has joined #gemrb
[20:52:11] <Avenger> what flag?
[20:52:31] <Avenger> i think only iwd2 has extra script, i display that one
[20:52:44] <fuzzie> the AF_NAME_OVERRIDE one
[20:53:16] <Avenger> ahh, i see
[20:53:16] <Avenger> the creature label is the field
[20:53:34] <Avenger> and i think i tell you about the flag in a tooltip.
[20:53:42] <Avenger> let me see
[20:54:25] <fuzzie> i look at iwd1's ar1000 goblins, for example
[20:54:37] <Avenger> the flags are in the 'fields' field :)
[20:54:58] <Avenger> i named it 'fields' because it enables the usage of certain fields ;)
[20:55:11] <fuzzie> huh, i see no 'fields'. maybe this DLTCEP is too old, i will go look
[20:55:21] <Avenger> it is in every actor
[20:55:29] <Avenger> check out an actor header
[20:55:35] <fuzzie> i look for the ARE one, though
[20:55:39] <Avenger> yes
[20:55:41] <Avenger> an area actor
[20:55:49] <Avenger> on the actors tab
[20:56:03] <fuzzie> oh! i see :)
[20:56:22] <Avenger> the scriptname is the actor's label itself
[20:57:06] <fuzzie> huh, that doesn't match either iwd or gemrb, but iwd doesn't have the AF_NAME_OVERRIDE flag set anyway
[20:57:17] <Avenger> what? the 8?
[20:57:39] <fuzzie> gemrb checks ((Flags&AF_NAME_OVERRIDE) || (core->HasFeature(GF_IWD2_SCRIPTNAME)) )
[20:58:01] <Avenger> yes, iwd always 'overrides' the name, i think
[20:58:04] <fuzzie> so that makes sense, i just still don't see where the name comes from :)
[20:58:58] <Avenger> the name?
[20:59:30] <Avenger> that is the label
[20:59:34] <fuzzie> it is "Goblin Axe 1" in the label
[20:59:36] <Avenger> hmm
[20:59:40] <fuzzie> oh
[20:59:46] <fuzzie> ok, no, that is fine!
[20:59:54] <fuzzie> it is GOBLINAXE1 in game, all is well, thankyou :-)
[21:00:07] <fuzzie> i just forgot the spaces
[21:00:07] <Avenger> oh cool, so it is the same
[21:00:10] <Avenger> :)
[21:00:17] <Avenger> yes, i trim spaces
[21:00:31] <fuzzie> that is correct :)
[21:00:55] <Avenger> ok, at least something is completely correct ;)
[21:01:09] <Avenger> if you make the action merging, we could fix the forge
[21:01:23] <fuzzie> yes, i just work on bg1 for a bit
[21:01:29] <fuzzie> i fixed iwd death variables, which helped a lot
[21:04:28] <CIA-22> gemrb: 03fuzzie * r7325 10/gemrb/trunk/gemrb/plugins/Core/ (ActorBlock.cpp ActorBlock.h GameScript.cpp): try to make sure that ActionOverride actions don't get interrupted too soon
[21:04:41] <fuzzie> ok, that fixes Scar, who was annoying me
[21:04:55] <fuzzie> also Spellhold, it seems
[21:05:41] <fuzzie> now i look at action merging
[21:22:50] <-- lynxlynxlynx has left IRC (orwell.freenode.net irc.freenode.net)
[21:22:50] <-- tombhadAC has left IRC (orwell.freenode.net irc.freenode.net)
[21:22:50] <-- Avenger has left IRC (orwell.freenode.net irc.freenode.net)
[21:22:50] <-- wjp has left IRC (orwell.freenode.net irc.freenode.net)
[21:22:50] <-- barra__out has left IRC (orwell.freenode.net irc.freenode.net)
[21:24:39] --> Avenger has joined #GemRb
[21:24:39] --> tombhadAC has joined #GemRb
[21:24:39] --> barra__out has joined #GemRb
[21:24:39] --> lynxlynxlynx has joined #GemRb
[21:24:39] --> wjp has joined #GemRb
[21:24:54] <CIA-22> gemrb: 03fuzzie * r7326 10/gemrb/trunk/gemrb/plugins/Core/GameScript.cpp: support gemact.ids file to add/replace actions
[21:25:06] <fuzzie> Avenger: not sure if that's what you wanted?
[21:25:28] <fuzzie> but you can now have a .bcs file which uses an action id which is only in gemact.ids, so i hope it's enough
[21:25:29] <Avenger> yes
[21:25:31] <Avenger> that's what we need
[21:34:13] <CIA-22> gemrb: 03avenger_teambg * r7327 10/gemrb/trunk/gemrb/override/shared/gemact.ids: gemrb specific actions (shared, so compatibility is assured)
[21:34:29] <Avenger> we'll need triggers too, but it is not important yet. First lets see how the concept works
[21:41:39] <lynxlynxlynx> fuzzie: which spellhold bug did 7325 fix?
[21:41:55] <fuzzie> lynxlynxlynx: the little girl
[21:42:02] <fuzzie> maybe coincidence, i didn't re-run it yet
[21:42:16] <lynxlynxlynx> the disappearing part?
[21:43:04] <Avenger> i will fix this tomorrow, i think. if i'm not too ill :)
[21:43:09] <Avenger> see you later
[21:43:12] <-- Avenger has left IRC ("bye!")
[21:44:26] <fuzzie> lynxlynxlynx: yes, and the problems with the coordinator, and Dili talks to you automatically, and so forth
[21:44:53] <fuzzie> i tried it again, still works, v.happy :)
[21:45:02] <lynxlynxlynx> great
[21:45:12] <lynxlynxlynx> i'll remove those from the list then
[21:45:40] <lynxlynxlynx> her polymorph is probably still buggy, but that is a general problem
[21:47:10] <lynxlynxlynx> also removed the two bg1 issues you fixed :)
[21:54:35] <fuzzie> r7325 could have broken huge amount of other stuff, but i don't think so
[22:06:13] <-- lynxlynxlynx has left IRC (Remote closed the connection)