[00:40:57] --> nickdaly` has joined #GemRb
[00:42:32] <-- nickdaly has left IRC (Ping timeout: 240 seconds)
[01:11:18] <-- budlust has left IRC (Ping timeout: 240 seconds)
[01:12:53] --> budlust has joined #GemRb
[01:40:24] --> nickdaly has joined #GemRb
[01:43:15] <-- nickdaly` has left IRC (Ping timeout: 245 seconds)
[02:41:41] --> nickdaly` has joined #GemRb
[02:43:39] <-- nickdaly has left IRC (Ping timeout: 260 seconds)
[03:44:53] <-- nickdaly` has left IRC (Ping timeout: 276 seconds)
[04:09:47] <-- budlust has left IRC (Ping timeout: 264 seconds)
[04:44:16] --> budlust has joined #GemRb
[04:57:01] --> raevol has joined #GemRb
[06:00:15] <-- raevol has left IRC (Quit: Leaving.)
[06:32:53] --> lynxlynxlynx has joined #GemRb
[06:32:54] --- ChanServ gives channel operator status to lynxlynxlynx
[06:48:30] <-- |Cable| has left IRC (Remote host closed the connection)
[07:38:37] <CIA-27> GemRB: 03edheldil * r92762e4d89f6 10ie_shell/infinity/formats/ (__init__.py cre_v90.py): Added CRE v9.0 format
[07:38:39] <CIA-27> GemRB: 03edheldil * refdebf68ddd3 10ie_shell/infinity/ (formats/d2a.py stream.py): Reworked D2A_Format class to allow for duplicate column and row names found in IWD
[07:38:41] <CIA-27> GemRB: 03edheldil * ra9e5b5049896 10ie_shell/infinity/stream.py: Search for CBF file if BIF was not found
[07:38:45] <CIA-27> GemRB: 03edheldil * r6198352a7e02 10ie_shell/infinity/formats/bam.py: Register BAMC format correctly
[07:38:48] <CIA-27> GemRB: 03edheldil * r9d9fc18483cd 10ie_shell/infinity/formats/key.py: iSearch case insensitive in keys.get_resref_by_name()
[07:38:48] <CIA-27> GemRB: 03edheldil * rd9e472dfc9ad 10ie_shell/ (iediff infinity/formats/pro.py): Merge branch 'master' of ssh://gemrb.git.sourceforge.net/gitroot/gemrb/ie_shell
[07:45:09] <Edheldil> hi all
[07:46:49] <lynxlynxlynx> oj
[07:47:29] <Edheldil> Thanks you for contributing, lynx :)
[07:47:52] <lynxlynxlynx> np
[07:48:14] <lynxlynxlynx> that parser is so much faster to use than the gui ones
[08:14:16] <fuzzie> and actually helpful for searching etc
[09:18:40] --> SiENcE has joined #GemRb
[09:54:38] <CIA-27> GemRB: 03lynxlupodian * r8282c9eea018 10gemrb/gemrb/GUIScripts/bg2/GUIWORLD.py:
[09:54:38] <CIA-27> GemRB: bg2: don't allow the protagonist to be reformed out of the party
[09:54:38] <CIA-27> GemRB: even if he is not in the first slot
[09:54:40] <CIA-27> GemRB: 03lynxlupodian * r27d56e6632a4 10gemrb/gemrb/GUIScripts/bg2/GUIWORLD.py: bg2: if nobody can be removed, just close the reform party window
[09:54:46] <CIA-27> GemRB: 03lynxlupodian * r598a06bcff3a 10gemrb/gemrb/GUIScripts/bg1/GUIWORLD.py:
[09:54:46] <CIA-27> GemRB: bg1: same changes as in bg2 reform party, but untested
[09:54:46] <CIA-27> GemRB: the diff applied cleanly, so it probably just works
[09:55:28] <-- budlust has left IRC (Ping timeout: 246 seconds)
[09:57:36] --> budlust has joined #GemRb
[10:20:32] <fuzzie> lynxlynxlynx: that seems to work fine for bg1
[10:21:01] <lynxlynxlynx> :)
[10:28:53] <lynxlynxlynx> hmpf, i still get scrolls with no charges
[10:29:55] <lynxlynxlynx> looks like 83c361b24 wasn't enough, this is a fresh game
[10:31:35] <fuzzie> i'm not sure what 83c361b24 is doing
[10:32:29] <lynxlynxlynx> it appears to copy the charges from the extended header
[10:32:49] <fuzzie> but only on the uncommon path
[10:33:23] <fuzzie> Inventory.cpp:582 should call SetSlotItem, perhaps
[10:36:07] <fuzzie> (btw, if you get it right, bad savegames should auto-correct themselves on load)
[10:36:37] <lynxlynxlynx> that suggestion sounds reasonable
[10:37:32] <fuzzie> it won't work though, because Inventory::AddItem doesn't do it
[10:38:49] <fuzzie> but obviously fixing AddSlotItem will work 'well enough', since it'll auto-correct once anything is in a character's inventory..
[10:39:25] <fuzzie> and i think if AddItem is fixed too, that seems to cover all the paths correctly.
[10:39:51] <lynxlynxlynx> AddSlotItem alone will fix a lot of cases
[10:40:08] <fuzzie> yes, i think that change to AddSlotItem should cover all of the actor cases
[10:40:40] <fuzzie> and then if the charge fixing is also done in AddItem, that will cover all of the other (containers, piles, etc) cases.
[10:41:32] <fuzzie> and then hopefully it is fixed.
[10:42:30] <fuzzie> the trouble is that this will presumably also auto-recharge items if you got them to 0 charges
[10:43:41] <lynxlynxlynx> only if they're not rechargable and are you sure they wouldn't get destroyed first?
[10:43:45] <lynxlynxlynx> this will be easy to test
[10:44:18] <fuzzie> so ResolveRandomItem might still be the place to do this.
[10:46:50] <fuzzie> it looks like destruction is based on type: CHG_BREAK/CHG_NOSOUND means that it's destroyed, anything else means that it's kept (e.g. one charge per day items)
[10:47:38] <lynxlynxlynx> those should have IE_ITEM_RECHARGE set
[10:48:14] <lynxlynxlynx> i'm more worried about use-once items like that rod of the gods used for the unseeing eye
[10:48:46] <lynxlynxlynx> or some better example, i'm not sure anymore that one doesn't get destroyed
[10:48:51] <fuzzie> then i agree that hopefully everything is autodestroyed
[10:49:06] <fuzzie> but that means avenger's fix is no good
[10:49:18] <fuzzie> because items with IE_ITEM_RECHARGE don't get their charges set.
[10:49:44] <fuzzie> and, well, i *thought* i found a bunch of wands etc without charges.
[10:49:55] <fuzzie> which got auto-corrected by the original engine.
[10:50:34] <lynxlynxlynx> the one in the wall traps perhaps? iirc i couldn't use them in gemrb
[10:51:37] <fuzzie> i think those are script-generated, which would be a different bug
[10:52:59] <lynxlynxlynx> yeah
[10:53:10] <lynxlynxlynx> scripts/bg2/pedpoly.baf: GiveItemCreate("WAND13",LastTrigger,1,0,0) // ~Wand of Cloudkill~
[10:53:26] <lynxlynxlynx> should be fine
[10:55:25] <fuzzie> i can't find any examples of wands at all, in the areas i was checking before
[10:56:26] <fuzzie> and the examples in other areas all have the charges set, i think
[10:56:28] <lynxlynxlynx> try the sewers, i think mekrath has one in his alcove
[10:56:35] <lynxlynxlynx> oh
[10:56:54] <fuzzie> what i mean is: i think i must be misremembering
[10:59:42] <fuzzie> yes, i checked some areas at random and rechargable items all have charges set
[11:08:18] <lynxlynxlynx> looking at the containers in dltcep, the scrolls have 0 charges set
[11:10:36] <lynxlynxlynx> potions and ammo are fine as expected
[11:11:04] <lynxlynxlynx> wouldn't fixing just ResolveRandomItem skip these?
[11:11:54] <fuzzie> ResolveRandomItem is called for all items, at ARE load time
[11:12:18] <lynxlynxlynx> but it skips them if they're not in the random treasure table
[11:12:29] <fuzzie> but i think just fixing AddSlotItem (to call SetSlotItem) and AddItem (with a copy of the charges code) will suffice
[11:12:42] <fuzzie> you could do the fix before the skipping, i mean.
[11:13:28] <fuzzie> i'm not sure where the original engine does all of this, though. and if you fix both AddSlotItem and AddItem, i'm pretty sure that covers all the cases and so it doesn't matter.
[11:13:46] <lynxlynxlynx> ok, this one sounds prettier
[11:22:27] <lynxlynxlynx> appears to work great
[11:28:25] <lynxlynxlynx> the pedestal wands work fine too
[11:29:12] <fuzzie> with a single charge?
[11:29:17] <lynxlynxlynx> yep
[11:29:23] <fuzzie> i guess you fixed it :)
[11:29:31] <lynxlynxlynx> didn't it work before?
[11:29:45] <lynxlynxlynx> the 1,0,0 at the end of the call is probably for the charges
[11:30:09] <fuzzie> yes, it is
[11:45:20] <CIA-27> GemRB: 03lynxlupodian * rc9e18c800963 10gemrb/gemrb/core/Inventory.cpp: also hack the charges in AddSlotItem and AddItem fixing scrolls and other loot
[11:45:22] <lynxlynxlynx> thanks for the help
[11:45:38] <lynxlynxlynx> now the only item annoyance left are the flags
[13:12:35] <fuzzie> which ones are a problem?
[13:35:35] <lynxlynxlynx> the flags field was random the last time i checked (testing the portal key removal)
[13:37:08] <lynxlynxlynx> and unrelated, a lot of the container items don't have the identified flag set, which makes me think we should autoidentify those too (on container opening)
[13:47:30] <fuzzie> how would you tell which should be identified?
[13:49:13] <lynxlynxlynx> i would do the same as in the inventory
[13:49:26] <fuzzie> i mean
[13:49:37] <fuzzie> the original engine doesn't autoidentify anything
[13:49:49] <lynxlynxlynx> are you sure?
[13:49:53] <fuzzie> well
[13:49:56] <fuzzie> i don't know what you mean.
[13:50:08] <lynxlynxlynx> opening the first table in the dungeon gives me all unindentified items
[13:50:15] <lynxlynxlynx> the original had them all identified
[13:50:25] <fuzzie> right
[13:50:30] <fuzzie> so, items which need a lore of 0?
[13:50:35] <lynxlynxlynx> yes
[13:50:55] <fuzzie> all i mean is, items with a very low lore value don't get auto-identified until you right-click them
[13:51:07] <lynxlynxlynx> i know
[13:51:13] <fuzzie> i'm sitting here comparing the two engines, there's some real weird stuff
[13:51:30] <fuzzie> like this ring of wizardry is red highlighted in gemrb .. but only when it's in the ring slot?!
[13:52:21] <fuzzie> and as far as i can tell, the sparkle objects in the original don't move, the sparkles just move to the bottom and fade
[13:53:17] <fuzzie> which would be much easier to implement in gemrb than the complicated stuff we do now, i think
[13:54:02] <lynxlynxlynx> the stuff we do now gives horrible results anyway
[14:11:56] <lynxlynxlynx> heh
[14:12:34] <lynxlynxlynx> since we have no gs interface for this, it is another candidate for ResolveRandomItem or ReadItem
[14:14:42] <lynxlynxlynx> ooh, but there's also a more sneaky way
[14:15:37] <lynxlynxlynx> hehe, much better
[14:16:08] <lynxlynxlynx> i'll just make the gui think it is identified, it will get changed once it is transfered
[14:23:38] <CIA-27> GemRB: 03lynxlupodian * rec900583fecd 10gemrb/gemrb/GUIScripts/GUICommon.py: auto-pseudo-identify mundane container items, so we don't get the blue overlay
[16:43:06] <-- SiENcE has left IRC (Quit: @all: cya)
[16:55:29] <Edheldil> lynxlynxlynx: Python has both variable list and distionary args: def a(*args) and def a(**kw)
[17:07:49] <CIA-27> GemRB: 03avenger_teambg * rd1089aba54d3 10gemrb/gemrb/core/ (Map.cpp Scriptable/Actor.cpp Scriptable/ActorBlock.cpp): fixed the familiars (global actors) finally, without breaking something else!!!
[17:07:50] <CIA-27> GemRB: 03avenger_teambg * ra8088483655d 10gemrb/gemrb/ (5 files in 4 dirs): Merge branch 'master' of ssh://email@example.com/gitroot/gemrb/gemrb
[17:55:14] <fuzzie> optimistic :p
[17:58:21] --> Avenger has joined #GemRb
[17:58:26] --- ChanServ gives channel operator status to Avenger
[17:58:29] <Avenger> hi
[18:02:52] <fuzzie> hi
[18:04:30] <Avenger> i tested the familiars for a long time :)
[18:08:25] <lynxlynxlynx> does repacking work too now?
[18:08:38] <Avenger> everything
[18:08:54] <fuzzie> i have been trying to work out what's wrong with our particles
[18:08:55] <lynxlynxlynx> you tried to put it out and back several times in a row?
[18:09:05] <Avenger> yes lynx
[18:09:13] <Avenger> even same session or after save/reload
[18:09:18] <lynxlynxlynx> excellent
[18:09:25] <lynxlynxlynx> i'll remove that from the todo :)
[18:09:34] <Avenger> ok
[18:09:57] <Avenger> it was colliding with San's bg1 crasher bug, btw
[18:10:05] <Avenger> i fixed one, the other popped in :0
[18:34:28] <-- budlust has left IRC (Ping timeout: 265 seconds)
[18:36:22] --> budlust has joined #GemRb
[19:24:34] <CIA-27> GemRB: 03lynxlupodian * r935bf1318987 10gemrb/gemrb/GUIScripts/bg2/CharGen.py: bg2: fixed chargen reentry to not throw a runtime error
[19:25:05] <lynxlynxlynx> not too pretty, but sufficient
[19:26:03] <lynxlynxlynx> i can confirm the familiar works nicely
[19:36:08] --> |Cable| has joined #GemRb
[21:09:17] --> SiENcE has joined #GemRb
[21:46:06] <-- SiENcE has left IRC (Quit: cya @all)
[21:49:31] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[21:51:22] <CIA-27> GemRB: 03avenger_teambg * r249cabd67f41 10gemrb/gemrb/ (5 files in 5 dirs): externalized gender based tokens
[22:00:38] <Avenger> bye
[22:00:40] <-- Avenger has left IRC (Quit: bye!)