[04:01:07] <-- exultbot has left IRC (Ping timeout: 270 seconds)
[04:01:07] <-- exultbot has left IRC (signing off...)
[04:02:27] --> exultbot has joined #GemRb
[04:02:27] --- Topic for #GemRb is: GemRB 0.6.1 | http://gemrb.sf.net | Be wary of your words for there are Modron sensors in this channel: http://log.usecode.org/gemrblog.php | Hey <CHARNAME>, we need some awesome screenshots!
[04:02:27] --- Topic for #GemRb set by lynxlynxlynx!~navaden@sourcemage/warlock/lynxlynxlynx at Wed Jun 16 16:31:07 2010
[04:04:03] <-- |Cable| has left IRC (*.net *.split)
[04:04:04] <-- Gekz has left IRC (*.net *.split)
[04:04:05] <-- CIA-27 has left IRC (*.net *.split)
[04:05:55] --> |Cable| has joined #GemRb
[04:05:55] --> CIA-27 has joined #GemRb
[04:05:55] --> Gekz has joined #GemRb
[04:06:15] <-- |Cable| has left IRC (*.net *.split)
[04:06:16] <-- Gekz has left IRC (*.net *.split)
[04:06:17] <-- CIA-27 has left IRC (*.net *.split)
[04:08:30] --> |Cable| has joined #GemRb
[04:08:30] --> CIA-27 has joined #GemRb
[04:08:30] --> Gekz has joined #GemRb
[04:09:37] <-- |Cable| has left IRC (*.net *.split)
[04:09:38] <-- Gekz has left IRC (*.net *.split)
[04:09:39] <-- CIA-27 has left IRC (*.net *.split)
[04:14:35] --> Gekz has joined #GemRb
[04:14:35] --> |Cable| has joined #GemRb
[04:14:35] --> CIA-27 has joined #GemRb
[04:15:32] <-- Edheldil has left IRC (*.net *.split)
[04:15:32] <-- Gekz has left IRC (*.net *.split)
[04:15:34] <-- |Cable| has left IRC (*.net *.split)
[04:15:38] <-- CIA-27 has left IRC (*.net *.split)
[04:15:39] <-- Lightkey has left IRC (*.net *.split)
[04:18:04] --> |Cable| has joined #GemRb
[04:18:46] --> CIA-27 has joined #GemRb
[04:18:46] --> Gekz has joined #GemRb
[04:18:46] --> Lightkey has joined #GemRb
[04:18:46] --> Edheldil has joined #GemRb
[05:17:54] --> raevol has joined #GemRb
[06:56:34] --> lynxlynxlynx has joined #GemRb
[06:56:34] --- ChanServ gives channel operator status to lynxlynxlynx
[07:02:24] <-- raevol has left IRC (Quit: Leaving.)
[07:22:55] <-- |Cable| has left IRC (Remote host closed the connection)
[08:23:39] <lynxlynxlynx> the last commit is broken
[08:24:04] <lynxlynxlynx> fixing the build just gives me a segfault on start though
[08:26:19] <lynxlynxlynx> entry->type = atoi(tm->QueryField(i,0)); // both entry and tm are not null, so i guess other memory is getting written to?
[08:49:43] <Edheldil> or tm->QueryField(i,0) returns something bogus
[08:51:08] <lynxlynxlynx> it's hard to tell, i don't know how to debug an autotable
[08:56:07] <fuzzie> your gdb refusing to use the -> operator?
[08:57:37] <lynxlynxlynx> i guess, it can't find the method
[08:58:05] <fuzzie> -> is an overloaded operator, so it's a bit complicated to resolve
[08:58:37] <fuzzie> but tm.table.ptr->QueryField(i,0) or something should work
[08:59:13] <lynxlynxlynx> Cannot access memory at address 0x14
[09:00:01] <fuzzie> it doesn't even build for me
[09:00:24] <lynxlynxlynx> add the type name
[09:00:32] <lynxlynxlynx> or i can push the commit
[09:00:40] <lynxlynxlynx> -};
[09:00:41] <fuzzie> well, i just removed the 'typedef'
[09:00:42] <lynxlynxlynx> +} gt_type;
[09:00:50] <lynxlynxlynx> in c++ it shouldn't matter
[09:00:54] <fuzzie> which seemed a bit more sensible :)
[09:01:46] <fuzzie> which game do you get a crash with?
[09:02:08] <lynxlynxlynx> bg2
[09:02:23] <lynxlynxlynx> right after loading the table, i can access that first cell
[09:03:12] <fuzzie> and it crashes right at the start?
[09:03:55] <lynxlynxlynx> the strnuprcpy breaks it
[09:04:11] <fuzzie> tm->GetRowName(i) is invalid?
[09:04:56] <fuzzie> oh, i guess it's probably meant to be sizeof(Variable)-1
[09:05:53] <fuzzie> i went through and fixed a bunch of these already, it's annoying because valgrind doesn't pick them up (on stack) and they only crash for some configs/compilers
[09:06:50] <fuzzie> ==1168== Source and destination overlap in strcpy(0xbed192d8, 0xbed192d8)
[09:06:51] <fuzzie> ==1168== at 0xFFBB390: strcpy (mc_replace_strmem.c:303)
[09:06:51] <fuzzie> ==1168== by 0xFF3F153: PathJoin(char*, char const*, ...) (in /home/fuzzie/gemrb/build/gemrb/core/libgemrb_core.so)
[09:06:54] <fuzzie> ==1168== by 0xFEA6F53: CreateSavePath(char*, int, char const*) (in /home/fuzzie/gemrb/build/gemrb/core/libgemrb_core.so)
[09:06:57] <fuzzie> ^- i should remember to look at that one
[09:07:05] <lynxlynxlynx> yeah, the -1 helped
[09:07:27] <fuzzie> otherwise valgrind is clean, and i get no crash so i guess it's all up to you :-)
[09:11:00] <lynxlynxlynx> i'm invisible and even summoned worgs can see me
[09:11:12] <lynxlynxlynx> i'll go check this other one
[09:11:20] <fuzzie> object matching does no checks whatsoever right now, afaik
[09:11:54] <fuzzie> the original engine does a lot of checks there; distance, walls/etc, invisibility, some resistance(?) checks for invisibility, etc
[09:14:23] <fuzzie> i wish i'd found the time to do this earlier, because i've forgotten how it works now
[09:14:59] <fuzzie> but i think basically, object matching like [PC] does that (it *doesn't* do it for matching actors, so that code needs seperating, tomprince had a patch which helped tidy that up but it didn't work as-is)
[09:16:16] <lynxlynxlynx> yeah, there's an invisibility resistance (non-detection) and the see-through for higher beings like dragons
[09:16:28] <fuzzie> and object matching like Player1 doesn't, and anything in between i don't know, it seems a bit unlikely that NearestEnemyOf(Myself) would return players from the other end of the map
[09:16:58] <fuzzie> but then i just ran a grep and it's all See(NearestEnemyOf(Myself)) and Detect(NearestEnemyOf(Myself)), so maybe it does
[09:22:46] <fuzzie> (and [PC]-style matching doesn't return self, another reason to split it out, it breaks the tutorial right now)
[09:31:02] <lynxlynxlynx> that valgrind warning is harmless btw
[09:31:17] <fuzzie> well, it isn't
[09:31:34] <lynxlynxlynx> how come?
[09:31:37] <fuzzie> i mean, it works with the standard linux libc
[09:32:24] <lynxlynxlynx> other implementations of strcpy break if they have to copy something on itself?
[09:32:26] <fuzzie> yes
[09:32:48] <fuzzie> maybe not if it's exactly the same string..
[09:32:57] <lynxlynxlynx> then a target != base check should suffice
[09:33:38] <lynxlynxlynx> oh, what if the sizes are different
[09:37:26] <fuzzie> i think strcpy onto itself will be fine in all circumstances
[09:38:09] <fuzzie> the trouble is that the order of copying is not necessarily left-to-right, but it doesn't matter here
[09:38:12] <fuzzie> i will leave alone
[09:38:57] <fuzzie> i still haven't finished my bg2 run, yesterday evening I managed to finish everything before the SoA forest, i think..
[09:40:24] <lynxlynxlynx> if the order changes in some compiler/libc, wouldn't everything break?
[09:45:26] <fuzzie> no
[09:45:36] <fuzzie> because it's different between different implementations anyway
[09:46:22] <fuzzie> so broken uses of strcpy get fixed; there are other functions to copy between overlapping regions, such as memmove()
[09:47:46] <fuzzie> although to be honest i have no idea how common it is on desktop/server machines..
[09:49:05] <wjp> we should really just respect the strcpy specs, regardless of how common undefined behaviour is :-)
[09:51:42] <fuzzie> well, i am just rambling in general
[09:53:13] <fuzzie> i am fixing electronics and studying probability, so can't go poke at gemrb
[09:55:15] <fuzzie> next year, must be sure to arrange things so i don't have all these exams in August :(
[09:57:43] <CIA-27> GemRB: 03lynxlupodian * rab9317729164 10gemrb/gemrb/plugins/TLKImporter/TLKImporter.cpp: fixed a compilation and crashing problem from the last commit
[09:57:45] <CIA-27> GemRB: 03lynxlupodian * r9ae1254b3b87 10gemrb/gemrb/core/SaveGameIterator.cpp: removed a doubled snprintf call in CreateSavePath
[10:04:32] <fuzzie> :)
[10:14:38] <fuzzie> so i guess the problem with red highlights is that some items make themselves unusable when equipped
[10:14:59] <fuzzie> to avoid items with the same abilities being used, i guess?
[10:15:03] <fuzzie> but i don't see an easy way to deal with that
[10:16:52] <lynxlynxlynx> i've never seen this in the original
[10:17:35] <lynxlynxlynx> the magic protection items are handled via a the itemexcl flag (preventing magic armor + stuff of protection)
[10:18:03] <lynxlynxlynx> which items are you talking about?
[10:19:26] <lynxlynxlynx> oh, maybe it's one of those npc items
[10:19:46] <lynxlynxlynx> iirc they used effects with stat limits to make "personal" items
[10:20:19] <lynxlynxlynx> the fixpackers had a lot of work with those, as a carefully crafted character could use them
[10:20:33] <fuzzie> i don't have the save here, but i don't see why an item would ever be red only when equipped
[10:20:44] <fuzzie> well, i do, i guess, if it messed with stats
[10:21:39] <lynxlynxlynx> equipping effects ;)
[10:22:09] <fuzzie> but these were standard items
[10:23:21] <lynxlynxlynx> i'll go try tob
[10:23:59] <fuzzie> well, maybe it's not very useful without my saves
[10:24:09] <fuzzie> i was comparing original engine to gemrb side-by-side
[10:24:20] <fuzzie> was indeed fixpacked though
[10:24:30] <lynxlynxlynx> keldorn's armor is properly shaded and unusable
[10:25:07] <lynxlynxlynx> same for his redeemer
[10:25:18] <lynxlynxlynx> and this is vanilla tob
[10:25:36] <lynxlynxlynx> but these hacks could be inconsistent, so maybe it is a problem only with some items
[10:27:12] <fuzzie> well, or maybe it is a problem somewhere else here
[10:35:42] <fuzzie> argh, gemrb's travel region code is so stupid
[10:36:56] <fuzzie> ok, so my original guess was right
[10:38:24] <fuzzie> this applies a CantUseItem effect, and Actor::Disabled promptly sees it and claims the item is unusable, and the guiscript uses that to colour it red
[10:39:15] <fuzzie> (testing with the Ring of Wizardry, as a random example i spawned into an untouched ToB)
[10:40:26] <fuzzie> i would guess the original engine handles this by not colouring things in red in that case if they're already equipped? but will have to look another time
[10:40:57] <lynxlynxlynx> well, should you be able to equip it or not?
[10:44:15] <fuzzie> yes
[10:45:21] <fuzzie> but the item itself has a "you can't equip this item" effect, which i can only guess is to stop double-equips of these items
[10:45:43] <fuzzie> i'll have to look at the other items later, but atm i can't use that machine
[10:45:59] <fuzzie> so just looking at the one case which i could reproduce :)
[10:46:33] <lynxlynxlynx> there were only 2 such rings in game and not easy to get either
[10:47:09] <lynxlynxlynx> so i can't say i tried double equipping them
[10:47:26] <lynxlynxlynx> i did in iwd2 with the rings of +5wis, but iwd2 is dnd3 and just uses the highest bonus
[10:48:37] <fuzzie> i went through bg2 and obsessively did everything i could
[10:48:42] <fuzzie> (in the original engine)
[10:49:00] <lynxlynxlynx> maybe they prohibit the double use due to the bonus spell effect being non-cummulative (just a guess)
[10:49:10] <fuzzie> because i keep trying to fix things in gemrb where i don't know how they're meant to work, so i wanted to try as much as possible
[10:49:34] <lynxlynxlynx> yeah, good strategy
[10:50:15] <fuzzie> @53012 = ~You may not use two rings of wizardry at the same time.~
[10:50:34] <fuzzie> no other matches for 'You may not use'
[10:53:47] <fuzzie> not any other likely-looking strings. things like ~You cannot have more than one chaos shield cast at one time.~ only.
[11:00:22] <lynxlynxlynx> hah
[11:00:56] <lynxlynxlynx> out of all the hundred of items, you found the only one with this problem
[11:01:13] <lynxlynxlynx> tousand/hundreds
[11:02:24] <lynxlynxlynx> doesn't seem to be hardcoded in the exe
[11:04:15] <fuzzie> just my luck :)
[11:08:43] <lynxlynxlynx> oh, the string is in the effect
[11:57:51] <Edheldil> e.g. in IWD there are 1774 ITM objects
[11:59:38] <fuzzie> checked them for the CantUseItem effect? :)
[13:58:43] <fuzzie> gemrb certainly is ridiculously faster than the original engine, sometimes
[14:12:57] <fuzzie> so, how do i add party experience in gemrb?
[14:13:31] <lynxlynxlynx> from where?
[14:13:33] <fuzzie> at the moment, things like trap disarming call AddExperience on the actor directly
[14:13:38] <fuzzie> which means it's not shared across the party
[14:13:44] <fuzzie> unless i am missing some bug here
[14:14:00] <lynxlynxlynx> for traps i'm not sure if that was shared
[14:14:07] <fuzzie> it is
[14:14:24] <fuzzie> (i just checked, everyone gains XP when i disarm a trap, at least according to the character record screen)
[14:14:31] <lynxlynxlynx> core->GetGame()->ShareXP
[14:14:44] <fuzzie> but i have to provide a fixed xp value for tha
[14:14:44] <fuzzie> t
[14:14:57] <lynxlynxlynx> what do you mean?
[14:15:24] <fuzzie> disarming/unlocking/etc xp is based on level somehow
[14:15:29] <fuzzie> i thought you might know better than me, really
[14:15:43] <lynxlynxlynx> this is already done
[14:15:55] <lynxlynxlynx> the values are based on difficulty and in one of the original tables
[14:16:02] <fuzzie> but not if i call ShareXP.
[14:16:25] <lynxlynxlynx> call it with that value
[14:16:38] <fuzzie> sorry, let me clarify
[14:16:51] <fuzzie> i'm wondering if i should just fix Actor::AddExperience to always share XP, or make a copy of the code in there
[14:17:21] <lynxlynxlynx> i don't see why that'd be needed
[14:17:26] <fuzzie> well
[14:17:31] <fuzzie> i mean, i have no XP value
[14:17:41] <fuzzie> so i can't call ShareXP because i don't know the number
[14:17:56] <fuzzie> at the moment, Actor:AddExperience (the second one) does some kind of table lookups for it
[14:17:56] <lynxlynxlynx> look it up first
[14:18:11] <fuzzie> so i should just copy that code into a new function?
[14:18:19] <lynxlynxlynx> i see now
[14:19:58] <fuzzie> Jan's XP for spell learning, unlocking and disarming is all shared, in my original ToB setup
[14:20:40] <fuzzie> and that seems to cover all of the XP_ defines in ActorBlock.h right now
[14:20:57] <fuzzie> but i don't know if that applies to anything except bg2
[14:22:32] <lynxlynxlynx> i doubt it's different elsewhere, except maybe in our two aliens
[14:25:23] <lynxlynxlynx> i'd rename AddExperience and make it just lookup the xp, then use ShareXP in the actions
[14:39:53] <fuzzie> http://fuzzie.org/nfs/gemrb/bla.txt is my tree (with other changes from earlier) which i guess is what you meant, but have to run now
[14:43:27] <lynxlynxlynx> yep
[15:05:44] <Edheldil> fuzzie: where can I find the opcode number for it?
[15:09:35] <lynxlynxlynx> iesdp?
[15:09:52] <lynxlynxlynx> #181 (0x0B5) Item: Can't Use Itemtype 
[15:10:08] <lynxlynxlynx> and more to the point: #180 (0x0B4) Item: Can't Use Item 
[15:10:52] --> Avenger has joined #GemRb
[15:10:53] --- ChanServ gives channel operator status to Avenger
[15:10:59] <Avenger> hi
[15:11:28] <Avenger> fuzzie: did you find out why the ring of wizardry goes red now? :)
[15:11:49] <lynxlynxlynx> yes
[15:12:12] <Avenger> if you have two, one equipped, another in the inventory. Is it red or not?
[15:12:18] <Avenger> i mean, in the original
[15:14:37] <lynxlynxlynx> don't know
[15:14:53] <lynxlynxlynx> but since she brought it up, i think it isn't
[15:15:43] <lynxlynxlynx> i mean there must be some difference in how gemrb and the original does it now or it wouldn't have been mentioned
[15:36:34] <Edheldil> as far as I can see, in IWD/how, not taking overrides into account, there's no item having 180 or 181 opcode
[15:53:38] <Avenger> yep, that opcode is probably used only in ring of wizardry of bg2
[15:56:07] <Edheldil> if anyone's interested in what resrefs use which opcode in iwd, I can send them the python object ;-)
[15:59:25] <Avenger> i use dltcep for that
[16:02:09] <Edheldil> do you hack&recompile it to print whatever you just need?
[16:23:48] <lynxlynxlynx> Registered: 2000-08-21
[16:24:06] <lynxlynxlynx> we have the next release date set :)
[16:27:25] <Avenger> 10 years?
[16:27:28] <Avenger> hehe
[16:27:43] <Edheldil> :)
[16:28:01] <lynxlynxlynx> was it long before the project got on sf?
[16:28:39] <Avenger> ed: dltcep can look for opcodes (check the search menu), but i usually hack&recompile it if i look for something special
[16:29:26] <Avenger> search item can look for : opcodes, item types, projectiles and used resrefs of any kind
[16:29:31] <Avenger> all else needs hack
[16:29:42] <Edheldil> ah, ok
[16:34:36] <lynxlynxlynx> are you working on anything Avenger?
[16:34:43] <Avenger> not right now
[16:34:54] <Avenger> i will fix the pst Note: stuff soon
[16:39:43] <Edheldil> hehe, it really looks like fuzzie hit the only 180/181 opcode using item in several thousands :)
[16:40:01] <Avenger> it was surely not a coincidence
[16:40:13] <Avenger> she looked for stuff containing it
[16:40:29] <Edheldil> ah
[16:40:56] <Edheldil> btw, have you found any with #181?
[16:47:08] <Avenger> no
[16:47:23] <Avenger> that opcode doesn't even work in the original engine
[16:47:36] <Avenger> it does something, but it is unfinished
[16:48:01] <Avenger> it might be that ToBEX will reactivate it, iirc, Taimon did it
[16:50:32] <Edheldil> what is ToBEX? Is it a binary patch to the original ToB engine?
[16:50:58] <lynxlynxlynx> yes
[16:57:25] <CIA-27> GemRB: 03lynxlupodian * rf02f8596b0a8 10gemrb/gemrb/core/Scriptable/Actor.cpp:
[16:57:25] <CIA-27> GemRB: close the container window if a party member is getting hurt
[16:57:25] <CIA-27> GemRB: (hack to not discard the incoming messages)
[17:11:39] <lynxlynxlynx> is there some special reason we always center on the first actor in Interface::HandleFlags() ?
[17:12:16] <lynxlynxlynx> i'm pretty sure all the originals left you on the same viewport as you saved on load
[17:20:07] <Avenger> i'm confused by looking at an empty area, better to see where are my chars
[17:20:24] <Avenger> i think i'm lazy on the viewport
[17:21:15] <lynxlynxlynx> but now we always recenter on the first actor, no matter who you saved over
[17:31:58] <Avenger> yes
[17:32:09] <Avenger> if you want, feel free to fix it :0
[17:32:25] <Avenger> it might be possible
[17:32:35] <Avenger> but, there is a bigger problem with the viewport
[17:32:40] <Avenger> it cannot change in pause
[17:32:42] <lynxlynxlynx> what i have now just centers on the first selected char
[17:33:02] <lynxlynxlynx> it's already an improvement, so i'll commit it
[17:33:11] <Avenger> that's fine now that we actually preserve the selected status :)
[17:33:46] <lynxlynxlynx> and because there is a fallback on GetPC - it is still possible to unselect everyone (and save)
[17:34:07] <Avenger> i don't really like that feature
[17:34:15] <Avenger> is it in the original engine?
[17:34:27] <Avenger> it seem i always unselect everyone by accident
[17:34:51] <lynxlynxlynx> no, i don't remember it
[17:35:07] <Avenger> actually, i think the original game selects the protagonist if you save as everyone unselected
[17:37:38] <CIA-27> GemRB: 03lynxlupodian * re977431a9d26 10gemrb/gemrb/core/Interface.cpp: center the viewport on the first selected pc on load instead of the protagonist
[17:46:42] <lynxlynxlynx> trying tob, you can't unselect everyone at all
[17:46:54] <lynxlynxlynx> if you draw an empty selection rect, nothing changes
[17:46:57] <Avenger> yeah
[17:47:10] <Avenger> ah yes, that's how i usually get everyone unselected
[17:47:12] <Avenger> quite annoying
[17:48:56] <lynxlynxlynx> i don't know of any other way ;)
[18:00:39] <fuzzie> i didn't check two rings of wizardry
[18:00:40] <fuzzie> i checked one
[18:01:54] <fuzzie> so it is a pretty simple problem
[18:02:10] <fuzzie> i just didn't see the CantUseItem opcode, since i was distracted by other usability problems
[18:02:23] <CIA-27> GemRB: 03lynxlupodian * r11a0d82fa5c7 10gemrb/gemrb/core/Interface.cpp: shortened the previous fix
[18:03:45] <CIA-27> GemRB: 03avenger_teambg * r67b5c3c41c37 10gemrb/gemrb/ (4 files in 3 dirs): externalized the 'NOTE:' string that is used in highlights in PST TextArea
[18:03:46] <CIA-27> GemRB: 03avenger_teambg * rbbe0c442c3f4 10gemrb/gemrb/core/Interface.cpp: Merge branch 'master' of ssh://firstname.lastname@example.org/gitroot/gemrb/gemrb
[18:04:43] <fuzzie> i got a bit distracted by buying food and cooking for people, bit busy for a while longer, so one of you is free to apply that ShareXP patch :p otherwise will do it later
[18:10:57] <fuzzie> oh, one thing i noticed that was still annoying: you can still cast magic missiles at a point, and it will still fire at the caster
[18:11:23] <fuzzie> i don't know whether the bug there is that it lets you cast at a non-actor, or whether it fires at the caster, but it is kinda painful if you misclick
[18:13:19] <lynxlynxlynx> sadly, a lot of spells don't work
[18:13:54] <lynxlynxlynx> the spellcasting should be cancelled if you don't target a valid target
[18:14:18] <fuzzie> this is not difficult to fix, i'm just not sure exactly what the rules are.
[18:14:48] <lynxlynxlynx> you can't mm thin air
[18:15:42] <fuzzie> so there's both the bit where the spellcasting cursor should go gray when you're not pointing an actor-requiring spell at an actor - we don't implement that at all?
[18:16:18] <fuzzie> and there's the bit where the action cancels itself when started if your target is invisible/sancturied/et
[18:17:04] <fuzzie> and i guess the "casting at dead actors" bit is just the result of gemrb removing corpses when it shouldn't.
[18:18:18] <fuzzie> no hidden trickery here?
[18:19:19] <lynxlynxlynx> i've never cast anything on corpses in any of the games
[18:19:32] <lynxlynxlynx> raise dead and the like all have no targetting
[18:20:02] <fuzzie> i mean, actors can die while you're casting
[18:20:43] <fuzzie> and even if they de-summon or explode or whatever, a projectile is still launched when the cast is done, aimed at their location
[18:21:06] <fuzzie> i'm not sure how that should work though :/
[18:21:24] <fuzzie> i mean, surely we don't keep un-summoned actors around in the map..
[18:21:35] <lynxlynxlynx> maybe a sanity check in DoStep?
[18:22:16] <fuzzie> i mean, the projectile is created after the actor dies
[18:22:41] <fuzzie> try a spell with a reasonable casting time (i was playing with the low-level flame thing in bg2) and then insta-kill enemies while it's being cast
[18:23:14] <lynxlynxlynx> do you immediately stop casting in the original?
[18:23:18] <fuzzie> no
[18:23:27] <fuzzie> you finish the cast, and the projectile fires at where the actor died.
[18:24:14] <fuzzie> it happened an awful lot during my last bg2 run, which is why i'm noticing this is all so flaky in gemrb
[18:25:00] <fuzzie> but i wonder if spell flags and things are involved?
[18:25:55] <lynxlynxlynx> i wouldn't worry about that just yet
[18:26:40] <fuzzie> well, all the spells i tried seem to work pretty well otherwise.
[18:26:49] <fuzzie> maybe i just pick the ones which work :)
[18:30:07] <lynxlynxlynx> a lot of the breakage is likely due to buggy projectiles
[18:30:25] <lynxlynxlynx> and some due to effects
[18:30:53] <lynxlynxlynx> in iwd even some simple damaging spells don't work
[18:31:19] <fuzzie> i also only check bg2
[18:31:27] <lynxlynxlynx> not to mention complex stuff like timestop
[18:31:52] <fuzzie> also when i drink a health potion, i get an attack anim and not the pretty heal effect :)
[18:32:08] <lynxlynxlynx> i get both iirc
[18:32:41] <fuzzie> [ResourceManager]: Searching for chmf4a5.bam...[chitin.key]
[18:32:42] <fuzzie> [ResourceManager]: Searching for wqLS2a5.bam...[ERROR]
[18:32:42] <fuzzie> [ResourceManager]: Searching for wqLH1a5.bam...[chitin.key]
[18:32:56] <fuzzie> ^- maybe i'm just missing the anim, then
[18:35:07] <-- budlust has left IRC (Ping timeout: 240 seconds)
[18:35:43] <fuzzie> and, yes, i guess if i try time stop then absolutely nothing happens :)
[18:36:30] --> budlust has joined #GemRb
[18:37:25] <lynxlynxlynx> yeah, nothing in bg2 with extra healing
[18:37:43] <lynxlynxlynx> while in iwd i get both for all the potions i tried
[18:40:33] <lynxlynxlynx> we already shade the cursor grey on invalid targets btw
[18:40:58] <fuzzie> well, i guess 'no target' just needs to be an invalid target also for some spells? but i don't know how to tell which ones, i have no idea
[18:41:58] <lynxlynxlynx> just look at the spell target type
[18:43:45] <fuzzie> the experience/kills summary is interestingly broken, also
[18:45:13] <lynxlynxlynx> works here, except for the favourites
[18:45:37] <fuzzie> it works fine here for some characters, and is completely broken (impossible figures) for others
[18:48:37] <fuzzie> looks like the label ids are wrong?
[18:50:35] <fuzzie> no dltcep here, but let me just call SetText on them all
[18:54:59] <fuzzie> http://ccdevnet.org/~fuzzie/exp_labels.png <- GUIREC uses 0f/10/15/16 for total, and 13/14/11/12 for chapter :)
[18:57:06] <fuzzie> oh, you broke it, in d8566640, by fixing the code so it did what it *claimed* to do :)
[18:57:32] <fuzzie> i guess the labels just need swapping, then
[19:01:13] <fuzzie> it looks like the label ids should also be broken in bg1/iwd, but i don't have either here
[19:03:16] <lynxlynxlynx> i'll look at it in a day or two, need to go to sleep
[19:03:29] <lynxlynxlynx> tommorow starts at 0430 :o
[19:03:38] <fuzzie> sorry, i am just kinda going down my list of stuff i noticed..
[19:04:02] <fuzzie> not meaning to imply i expect a response. sleep well!
[19:08:54] <Avenger> fuzzie: there is no wqls2a5
[19:09:05] <Avenger> only a2/4/6
[19:09:22] <fuzzie> Avenger: so, where is my heal animation? :) i guess it would be a vvc or something anyway
[19:09:50] <Avenger> that is surely a spell hit anim
[19:10:02] <Avenger> a stationary projectile
[19:10:33] <Avenger> what potion you use?
[19:11:31] <fuzzie> um, one of the ones which is lying around everywhere in bg2
[19:11:46] <fuzzie> let me run gemrb again
[19:12:58] <Avenger> btw, i realized what bow/xbow/sling do in extended headers (in dltcep, i represent them by checkboxes)
[19:13:10] <fuzzie> it is potn52
[19:13:13] <Avenger> they are actually animation percentages similar to the melee animations
[19:13:48] <fuzzie> oh, interesting
[19:13:57] <fuzzie> so you can have mixes?
[19:14:11] <Avenger> yes, but you have to have the bams or crash occurs
[19:14:29] <Avenger> basically, you can have 6 weapon attack anims
[19:15:31] <Avenger> does this potion play some anim in bg2?
[19:15:45] <fuzzie> yes
[19:15:50] <Avenger> oh it has a play animation
[19:15:56] <Avenger> sphealin
[19:16:06] <Avenger> do you see it looked up in the console?
[19:16:16] <fuzzie> nope
[19:16:21] <Avenger> huh
[19:16:30] <fuzzie> but it is just some bug?
[19:16:42] <Avenger> possibly, it has a very short duration
[19:16:43] <Avenger> 3
[19:17:11] <Avenger> maybe gemrb honours the duration, but the original engine always plays a cycle fully
[19:17:22] <lynxlynxlynx> they work in iwd, but those are richer, so easier to notice
[19:17:24] <lynxlynxlynx> good night
[19:17:38] <Avenger> in iwd it is probably not so short
[19:17:46] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[19:17:56] <Avenger> hmm wait, it should still show up on the console
[19:18:17] <fuzzie> the AttackStance code in ChargeItem seems to always play the attack anim when anything is used..
[19:18:45] <fuzzie> so that is the attack anim bit
[19:20:56] <Avenger> lol
[19:21:08] <Avenger> fuzzie, look in fxopcodes
[19:21:18] <Avenger> 0xd7 PlayVisualEffect
[19:21:29] <Avenger> line 4679
[19:21:49] <fuzzie> one ! too many? :)
[19:21:54] <Avenger> bingo
[19:21:58] <fuzzie> oops
[19:22:31] <Avenger> i wonder why, it is so trivial :)
[19:22:46] <Avenger> i must have been very sleepy
[19:23:07] <Avenger> this must solve lots of missing graphics
[19:23:28] <fuzzie> well, hooray!
[19:24:04] <Avenger> btw, it shouldn't return as fx_not_applied
[19:24:10] <Avenger> it should return as fx_applied
[19:24:23] <Avenger> because if it goes away from the other source, it should still be played
[19:24:36] <Avenger> this way, the effect is killed if there is another already
[19:24:43] <Avenger> it is not good
[19:33:52] <fuzzie> oh
[19:33:57] <fuzzie> i didn't say: it works, of course :)
[19:34:18] <fuzzie> i am busy admiring the effects
[19:35:06] <Avenger> cool
[19:35:13] <Avenger> so little missed :)
[19:35:33] <CIA-27> GemRB: 03avenger_teambg * r006dfc6d4271 10gemrb/gemrb/plugins/IWDOpcodes/IWDOpcodes.cpp: remove opcode 1a1 from dead targets (as original iwd2 does)
[19:37:47] <fuzzie> hehe, the fire shield vvc (spfiresa) is not mirrored
[19:38:46] <fuzzie> it works fine when 'starting', but then the animation which plays all the time is in two parts: one at the top, under my actor, but then another one on top of that, on top of my actor, which i guess is meant to be the bottom half of the circle..
[19:38:53] <fuzzie> some missing projectile flag?
[19:39:15] <Avenger> hmm
[19:39:19] <Avenger> mirrored?
[19:39:35] <fuzzie> one moment
[19:40:09] <Avenger> there is no mirror flag set in the vvc
[19:40:27] <fuzzie> http://ccdevnet.org/~fuzzie/fireshield_anim.png
[19:42:49] <Avenger> wait you have both fireshield?
[19:42:59] <fuzzie> i cast them both to see if both were broken, that's all
[19:43:06] <Avenger> ah ok
[19:43:32] <Avenger> the cycles are not honoured
[19:44:08] <CIA-27> GemRB: 03fuzzie * rc941c22a65fb 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: fix fx_play_visual_effect
[19:44:14] <Avenger> in dltcep it is 1.seq/2.seq
[19:44:50] <Avenger> in ScriptedAnimation.cpp: ieDword seq1, seq2
[19:45:50] <Avenger> hmm you said the flare up is working?
[19:45:53] <fuzzie> yes
[19:46:00] <Avenger> that is seq1
[19:46:08] <Avenger> i do: if (seq1) seq1--
[19:46:17] <Avenger> probably it should be done with seq2 too
[19:46:20] <Avenger> try that?
[19:46:59] <Avenger> most likely that will fix it
[19:47:10] <fuzzie> will do
[19:47:23] <Avenger> and seq3 too
[19:47:27] <Avenger> almost sure :)
[19:47:39] <Avenger> looks like 0 means not existent
[19:48:47] <Avenger> hmm wait a moment
[19:48:53] <Avenger> bool phases = (seq2 || seq3);
[19:49:03] <Avenger> this needs them unchanged
[19:49:12] <Avenger> so, you can do the -- after that
[19:49:36] <Avenger> but it is in a loop
[19:49:41] <Avenger> so, it should be moved outside
[19:49:42] <fuzzie> can do it after the loop
[19:49:48] <fuzzie> but you're right
[19:50:40] <Avenger> this is a very hacked up code that tries to do a lot of things
[19:52:50] <fuzzie> ok, works beautifully
[19:56:25] <CIA-27> GemRB: 03fuzzie * ra206099afa2c 10gemrb/gemrb/core/ScriptedAnimation.cpp: add some more hacks to ScriptedAnimation, fixes fire shield animation
[19:56:25] <CIA-27> GemRB: 03fuzzie * r9aa42906127f 10gemrb/gemrb/core/Scriptable/ (Actor.cpp Actor.h ActorBlock.cpp): lockpick/disarm/spell-learn XP is shared between party
[19:56:38] <Avenger> cool
[19:57:25] <Avenger> heh, spell learn is shared?
[19:57:48] <fuzzie> well, i only tested bg2 :P so maybe it needs a GF_
[19:57:58] <Avenger> that's awfully weird, but well, if it is shared, then we should do the same
[19:58:56] <fuzzie> but i guess that if your fighters have to share all the XP for when they kill enemies - the only thing they do, really - thieves/mages should surely share XP for everything they do
[19:59:38] <Avenger> you know what i did for free when i needed only a little?
[19:59:46] <fuzzie> the ring of wizardry thing is simple: if you equip an item with a CantUseItem effect for itself, then the item shows up in red when equipped, because it is not usable
[19:59:54] <Avenger> bought a bunch of scrolls/learned them then forgot them :0
[20:00:18] <fuzzie> and i guess the original game just ignores CantUseItem effects when checking for the red highlight.
[20:00:29] <Avenger> hmm
[20:00:32] <fuzzie> since there is only this one item, i hope that can't cause any problems :P
[20:00:38] <Avenger> so it needs a flag
[20:00:58] <fuzzie> that is my thought
[20:01:06] <Avenger> i liked that it is red, even if it isn't in the original (except for itself when already worn)
[20:01:31] <fuzzie> well, i only tested with the single ring, i didn't know if you can get two :)
[20:01:45] <Avenger> well, otherwise you wouldn't need the effect, LOL
[20:01:58] <fuzzie> as if Bioware haven't done silly things :P
[20:02:15] <Avenger> btw, gemrb has a feature that makes this effect obsolete
[20:02:20] <fuzzie> but i thought the guiscript can simply only set this flag if checking something already equipped
[20:02:27] <Avenger> itemexcl in gemrb is a bitfield
[20:02:31] <Avenger> not a simple boolean
[20:02:41] <Avenger> so you can have 32 sets of items that exclude each other
[20:03:17] <Avenger> i wish i was there when bioware designed this game ;)
[20:04:15] <Avenger> i think the original makes unusable items red, even if they are already equipped
[20:04:23] <fuzzie> yes
[20:04:29] <fuzzie> so this CantUseItem thing is just special-cased
[20:04:45] <Avenger> yeah, most likely it is not highlighted
[20:04:48] <fuzzie> oh, sure
[20:05:01] <fuzzie> i only noticed because i was comparing to the original
[20:05:16] <fuzzie> i just ran both side-by-side and checked differences, yesterday
[20:05:33] <Avenger> i don't have any idea how to make it perfect
[20:06:23] <fuzzie> our summons are too fast, also
[20:06:40] <Avenger> hmm, CanUseItem.... needs a flag (already equipped)
[20:07:24] <Avenger> and the part about Actor->Disabled shouldn't be called when it is set
[20:07:24] <fuzzie> the original has the summons appearing at the end of the summon animation, but our summons are instant
[20:07:52] <Avenger> we don't even play all summons, it seems
[20:07:57] <Avenger> i mean animations
[20:08:13] <fuzzie> hmm, the animations seemed to play for everything i tried just now
[20:08:14] <Avenger> i noticed it when i tested the familiar
[20:08:25] <fuzzie> oh, the familiar code is different
[20:08:42] <fuzzie> it has CreateUnsummonEffect in fx_find_familiar too
[20:08:48] <fuzzie> so i don't understand it, and i don't touch it :)
[20:08:56] <Avenger> btw, back to the usability, it already has a boolean, just convert it to a bitfield
[20:09:44] <Avenger> or hmm, the feedback bit is probably useful
[20:10:06] <Avenger> hmm, no, on second though, it isn't :0
[20:10:21] <fuzzie> it should never get called with feedback, i'd hope
[20:10:38] <Avenger> ?
[20:10:51] <fuzzie> i mean, with feedback and this 'already equipped' flag set
[20:11:15] <Avenger> ah well, that's true, but there are 3 possible combinations
[20:11:39] <Avenger> no feedback, not equipped; no feedback equipped; feedback, not equipped
[20:13:04] <fuzzie> well, i do this the lazy way for now
[20:17:10] <-- Edheldil has left IRC (Ping timeout: 248 seconds)
[20:18:18] --> Edheldil has joined #GemRb
[20:18:18] --- ChanServ gives channel operator status to Edheldil
[20:23:44] <-- Edheldil has left IRC (*.net *.split)
[20:23:45] <-- Gekz has left IRC (*.net *.split)
[20:23:49] <-- CIA-27 has left IRC (*.net *.split)
[20:23:50] <-- Lightkey has left IRC (*.net *.split)
[20:26:19] --> Edheldil has joined #GemRb
[20:26:19] --> Lightkey has joined #GemRb
[20:26:19] --> Gekz has joined #GemRb
[20:26:19] --> CIA-27 has joined #GemRb
[20:27:27] <-- Edheldil has left IRC (*.net *.split)
[20:27:28] <-- Lightkey has left IRC (*.net *.split)
[20:27:30] <-- Gekz has left IRC (*.net *.split)
[20:27:37] <-- CIA-27 has left IRC (*.net *.split)
[20:28:03] <Avenger> oh i know why fighter mages don't get any spell
[20:28:15] <Avenger> Level = GemRB.GetPlayerStat (Slot, IE_LEVEL2+i-1)
[20:28:32] --> Edheldil has joined #GemRb
[20:28:32] --> CIA-27 has joined #GemRb
[20:28:32] --> Gekz has joined #GemRb
[20:28:32] --> Lightkey has joined #GemRb
[20:29:19] <Avenger> i bet the mage level is in IE_LEVEL1 for them
[20:29:31] <-- fuzzie has left IRC (*.net *.split)
[20:29:31] <-- Edheldil has left IRC (*.net *.split)
[20:29:32] <-- Gekz has left IRC (*.net *.split)
[20:29:37] <-- CIA-27 has left IRC (*.net *.split)
[20:29:38] <-- Lightkey has left IRC (*.net *.split)
[20:30:47] --> fuzzie has joined #GemRb
[20:30:47] --> Edheldil has joined #GemRb
[20:30:47] --> Lightkey has joined #GemRb
[20:30:47] --> Gekz has joined #GemRb
[20:30:47] --> CIA-27 has joined #GemRb
[20:32:14] <fuzzie> heh
[20:32:15] <fuzzie> a netsplit for the exact moment CIA reported those commits :)
[20:32:17] <fuzzie> Avenger: 'fighter/mage' has fighter in 1 and mage in 2, no?
[20:32:17] <-- Edheldil has left IRC (Ping timeout: 248 seconds)
[20:32:18] --> Edheldil has joined #GemRb
[20:32:18] --- ChanServ gives channel operator status to Edheldil
[20:32:36] <Avenger> dunno fuzzie
[20:32:48] <Avenger> there is a complicated code to determine level
[20:32:48] <fuzzie> you can literally just split the identifiers by the _: FIGHTER_MAGE has FIGHTER in 1 and MAGE in 2
[20:32:58] <Avenger> and i see the levelup gets level=0
[20:33:01] <Avenger> so, it fails
[20:33:16] <Avenger> guicg7
[20:33:17] --> |Cable| has joined #GemRb
[20:33:21] <Avenger> line 56
[20:33:50] <fuzzie> and it fails there?
[20:35:28] <Avenger> line 56 and below calculates level as 0
[20:35:40] <Avenger> levelup expects 1
[20:35:50] <Avenger> because level 0 has no spells to select
[20:36:02] <fuzzie> hm
[20:36:10] <fuzzie> it is not that range(2,2) returns nothing?
[20:36:38] <Avenger> mage thief works
[20:36:45] <fuzzie> and range(2,3) means i is only ever 2, and IE_LEVEL2+2-1 = IE_LEVEL3
[20:36:47] <Avenger> hmm, because it has mage in level1
[20:36:50] <fuzzie> yes, because it's MAGE_THIEF :p
[20:36:56] <Avenger> yep
[20:37:10] <fuzzie> i would change the range to be range(1, ...)
[20:37:32] <Avenger> yes, probably
[20:38:12] <Avenger> so i remove the -1 from the Level = GemRB.GetPlayerStat (Slot, IE_LEVEL2+i-1)
[20:38:29] <Avenger> and change the 2 to 1 in range(2
[20:38:55] <Avenger> hmm on second thought
[20:39:01] <Avenger> i won't remove that -1
[20:39:08] <fuzzie> changing the 2 to a 1 works
[20:39:27] <fuzzie> i think the second parameter to range should be without the +1, too
[20:40:22] <Avenger> well, i will print IsMulti
[20:40:29] <fuzzie> yep, that works
[20:40:42] <fuzzie> IsMulti is 2, so range(1,2) is  which is correct here
[20:41:04] <fuzzie> i'm sure it needs testing with the other multiclassed mages though
[20:41:25] <Avenger> fighter mage: 2,2,1,0
[20:41:29] <fuzzie> i am off to find a power adapter
[20:41:47] <Avenger> yes, i test it with everything now
[20:45:35] <-- Edheldil has left IRC (Ping timeout: 248 seconds)
[20:45:48] --> Edheldil has joined #GemRb
[20:45:48] --- ChanServ gives channel operator status to Edheldil
[20:48:31] <CIA-27> GemRB: 03avenger_teambg * r3e6e2fc04c68 10gemrb/gemrb/GUIScripts/ (bg1/GUICG7.py bg2/GUICG7.py): fixed cg spell selection for some multiclasses
[20:48:33] <CIA-27> GemRB: 03avenger_teambg * re6c56fb18fee 10gemrb/gemrb/ (7 files in 5 dirs): Merge branch 'master' of ssh://email@example.com/gitroot/gemrb/gemrb
[21:09:46] <CIA-27> GemRB: 03avenger_teambg * re39df6eebf4e 10gemrb/gemrb/ (GUIScripts/pst/GUICommonWindows.py core/GUI/GameControl.cpp):
[21:09:47] <CIA-27> GemRB: fixed half party selection
[21:09:47] <CIA-27> GemRB: added ActOnPC in pst
[21:19:51] <CIA-27> GemRB: 03fuzzie * rb315d13efb50 10gemrb/gemrb/GUIScripts/bg2/GUIREC.py: fix label ids for bg2 GUIREC info window (probably needs applying to bg1/iwd too)
[21:24:03] <CIA-27> GemRB: 03fuzzie * r885e266b0465 10gemrb/gemrb/GUIScripts/bg1/GUIINV.py: fix encumbrance label size in bg1 inventory
[21:29:01] <Avenger> fuzzie, i'm doing the infravision stuff
[21:29:24] <fuzzie> cool
[21:32:18] <fuzzie> i am just poking through my pile of unfinished things
[21:32:35] <CIA-27> GemRB: 03fuzzie * r5bdd595baed1 10gemrb/gemrb/GUIScripts/bg2/GUIINV.py: apply encumbrance inventory change to bg2 too, although they're probably not the right numbers
[21:33:28] <fuzzie> i forget why we concluded the sizes were bad - someone had a modded bg2 with the wrong font? - but at least it's readable in bg2 now
[21:48:13] <Avenger> it is different for each resolution
[21:48:22] <Avenger> it should be relative to a control, i guess
[21:48:30] <fuzzie> i only change the sizes here
[21:49:22] <fuzzie> and container window has the same problem, i guess
[22:04:49] <Avenger> hmm elves/dwarves/etc infravision is hardcoded?
[22:05:47] <fuzzie> don't know
[22:08:11] <CIA-27> GemRB: 03avenger_teambg * r7c80460f7f6d 10gemrb/gemrb/core/ (5 files in 2 dirs): infravision
[22:08:12] <CIA-27> GemRB: 03avenger_teambg * ra77aacb93ea9 10gemrb/gemrb/GUIScripts/bg2/GUIINV.py: Merge branch 'master' of ssh://firstname.lastname@example.org/gitroot/gemrb/gemrb
[22:08:37] <fuzzie> the atweaks "Restore innate infravision to Half-Orc characters" mod just scripts a spell cast..
[22:09:28] <Avenger> yes, there is an infravision effect
[22:09:32] <fuzzie> and the remove infravision effect doesn't remove native infravision for elves/etc, i guess?
[22:09:36] <Avenger> but elves are not affected by it
[22:09:40] <fuzzie> so i would guess that it is hardcoded.
[22:09:45] <Avenger> sucks
[22:11:05] <Avenger> the tint is not correct, it seems it makes everything even darker
[22:11:26] <Avenger> i guess this will require wjp :)
[22:12:01] <Avenger> and, the code that determines if a lightmap point is dark or not, is not exactly like the original, yet
[22:12:10] <Avenger> i think they do some weighting of r/g/b
[22:12:26] <fuzzie> hmm, we don't? i thought lynx added that
[22:12:40] <Avenger> for hide in shadows?
[22:12:59] <Avenger> this is supposed to use the same code
[22:13:09] <Avenger> i didn't remember we already had it
[22:13:11] <fuzzie> see Map::GetLightLevel
[22:13:17] <Avenger> hmm
[22:13:18] <Avenger> ok
[22:13:25] <fuzzie> this is not what you mean?
[22:13:40] <Avenger> yes, it should use that
[22:14:02] <Avenger> i don't know what light level it should used, though
[22:14:06] <Avenger> probably mid way
[22:14:27] <Avenger> see you tomorrow
[22:14:35] <-- Avenger has left IRC (Quit: bye!)
[22:32:52] --> Maighstir_laptop has joined #GemRb
[23:43:02] <-- Maighstir_laptop has left IRC (Ping timeout: 260 seconds)