#gemrb@irc.freenode.net logs for 27 Sep 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:52:52] --> Mataniko_ has joined #GemRb
[00:54:18] <-- Mataniko has left IRC (Ping timeout: 245 seconds)
[00:54:30] --- Mataniko_ is now known as Mataniko
[02:23:32] --> raevol has joined #GemRb
[03:31:36] <-- Mataniko has left IRC (Remote host closed the connection)
[06:06:24] <-- raevol has left IRC (Quit: Leaving.)
[07:25:09] --> lynxlynxlynx has joined #GemRb
[07:25:09] --- ChanServ gives channel operator status to lynxlynxlynx
[07:36:41] <-- |Cable| has left IRC (Remote host closed the connection)
[07:46:35] <lynxlynxlynx> found out the problem
[07:47:07] <lynxlynxlynx> the inventory items have foobared flags even before the entry to the store
[07:50:04] <lynxlynxlynx> this is an old bg2 save, so the chars are still bg1-like, but on a quick glance i don't see any difference in inventory structure/reading
[07:51:24] <lynxlynxlynx> some items are from not-fresh loot, so maybe it's just an old save thing - i'll go fetch them anew
[07:56:16] --> lubos has joined #GemRb
[08:17:32] --> spike411 has joined #GemRb
[08:31:52] <lynxlynxlynx> ugh, it's a problem in new games too
[08:33:40] <fuzzie> howso foobared?
[08:33:54] <lynxlynxlynx> IE_INV_ITEM_SELECTED is part of the flags
[08:34:31] <fuzzie> actually, or just in guiscript?
[08:34:52] <lynxlynxlynx> we set that in 3 places, 1 of which is unused, the other two in stores and there were no stores, so it is either read bad, handled badly or bad data
[08:35:05] <lynxlynxlynx> actually, i'm checking the debug dump
[08:35:34] <lynxlynxlynx> one thing that may be related is that this is a gemrb extension - maybe the original does use this bit and for something else
[08:36:05] <fuzzie> um
[08:36:12] <lynxlynxlynx> oh, it shares the value with IE_INV_ITEM_EQUIPPED
[08:36:14] <fuzzie> ok, so flags set on STOItem?
[08:36:32] <fuzzie> i never remember how this works
[08:37:05] <lynxlynxlynx> no, this is still CREItem
[08:37:56] <lynxlynxlynx> i killed a goblin and he dropped arrows
[08:38:04] <lynxlynxlynx> i picked them up and they have 2ce1 for flags
[08:38:33] <lynxlynxlynx> so i guess we should disable the equipped bit when dropping stuff
[08:39:11] <lynxlynxlynx> yeah, equipping and deequipping fixed it
[08:43:17] <fuzzie> good find :)
[08:43:39] <fuzzie> i am off to university to see if i can get further extensions on homework if i ask in person, will bbl
[08:43:47] <lynxlynxlynx> good luck
[08:48:33] --> SiENcE has joined #GemRb
[10:19:42] <lynxlynxlynx> pfew, it's done! :)
[10:20:26] <CIA-93> GemRB: 03lynxlupodian * rfa1d5de43a7f 10gemrb/gemrb/core/Inventory.cpp:
[10:20:26] <CIA-93> GemRB: DropItemAtLocation: disable the equipped bit, since it is shared with the
[10:20:26] <CIA-93> GemRB: store-selected bit and was causing item preselection in stores
[10:20:30] <CIA-93> GemRB: 03lynxlupodian * rb512a728d490 10gemrb/gemrb/ (GUIScripts/GUISTORE.py plugins/GUIScript/GUIScript.cpp): GUISTORE: allow identifying more than one item at a time
[11:29:02] <-- SiENcE has left IRC (Ping timeout: 265 seconds)
[11:38:45] <CIA-93> GemRB: 03lynxlupodian * r034fe897b152 10gemrb/gemrb/GUIScripts/GUISTORE.py: GUISTORE: prevent overscrolling due to different inventory sizes
[12:45:09] <-- spike411 has left IRC (Quit: spike411)
[12:55:39] --> SiENcE has joined #GemRb
[13:14:52] <CIA-93> GemRB: 03lynxlupodian * r2b241a2cb26a 10gemrb/gemrb/GUIScripts/GUISTORE.py: cosmetics in guistore
[13:14:55] <CIA-93> GemRB: 03lynxlupodian * r0fec994f9b5b 10gemrb/gemrb/ (GUIScripts/GUISTORE.py plugins/GUIScript/GUIScript.cpp):
[13:14:55] <CIA-93> GemRB: GUISTORE: disallow raising dead on live actors and anything but raising on
[13:14:55] <CIA-93> GemRB: dead actors
[13:16:21] <lynxlynxlynx> running out of things to fix/add :)
[13:16:48] <lynxlynxlynx> you can't raise the dead, because they are unselectable
[13:18:00] <lynxlynxlynx> we don't allow bulk buying nor display the quantity
[13:18:54] <fuzzie> which ones are merged?
[13:19:32] <lynxlynxlynx> merged? if you mean bulks, you can't buy three potions of the same kind in one go
[13:22:17] <fuzzie> i mean, the games
[13:23:04] <lynxlynxlynx> all but pst
[13:23:34] <lynxlynxlynx> it has most of the control ids at different values
[13:23:39] <lynxlynxlynx> plus the strrefs
[13:26:59] <fuzzie> ah
[13:27:22] <fuzzie> i forget if pst id much different UI-wise
[13:27:26] <fuzzie> is much different
[13:27:51] <lynxlynxlynx> not that much, but for some reason the ids are off
[13:32:39] <fuzzie> hadn't realised it worked at all in gemrb
[13:35:31] <lynxlynxlynx> i fixed it during summer
[13:35:57] <lynxlynxlynx> for a loose definition of fixed
[14:42:51] <lynxlynxlynx> wtf
[14:43:13] <lynxlynxlynx> getting odd results from gamegetselectedsingle
[14:43:35] <fuzzie> oh?
[14:44:13] <lynxlynxlynx> if i print it in the console, i get 2 for all of the pcs
[14:44:20] <lynxlynxlynx> (selected individually)
[14:44:29] <fuzzie> and you're on a screen?
[14:44:49] <lynxlynxlynx> gamescreen, but the original problem is from within a store
[14:45:04] <fuzzie> the gamegetselectedsingle is only valid after you set it
[14:45:32] <fuzzie> done in SetSelectionChangeHandler of each game, i think
[14:46:06] <lynxlynxlynx> it's not consistent, that's what is odd
[14:46:16] <fuzzie> but i don't see the window handling code in GUISTORE
[14:47:10] <lynxlynxlynx> the selection change handlers are set
[14:47:20] <fuzzie> but the other window function?
[14:47:50] <lynxlynxlynx> ooh, i got an idea
[14:48:26] <lynxlynxlynx> yeah, i see the problem
[14:48:45] <lynxlynxlynx> it's the multiple portraitwindows thing again
[14:49:30] <fuzzie> well, i'm glad you know what that is :)
[14:50:21] <lynxlynxlynx> i'll add something to reset the selection on store close, that should fix it
[14:51:08] <lynxlynxlynx> the problem went like this: start store with 1, change to 3 in the store and close; restart store with 1, which is treated like 3 for one important thing
[14:51:22] <lynxlynxlynx> instead of 1, of course
[14:56:19] <lynxlynxlynx> heh, strike 1
[14:57:31] <fuzzie> my assumption would be that, since the window opening/closing is circumventing CloseOtherWindow, that the selection change handler isn't going to set the selection right on store startup
[14:59:17] <fuzzie> but i know nothing about the portrait window stuff
[15:17:58] <lynxlynxlynx> yeah, must've been that or close
[15:19:39] <CIA-93> GemRB: 03lynxlupodian * r43df04e7c278 10gemrb/gemrb/GUIScripts/GUISTORE.py: GUISTORE: always use the talking pc for price calculation
[15:39:24] <CIA-93> GemRB: 03avenger_teambg * r9e487533394a 10gemrb/gemrb/override/shared/bardsong.spl: implemented default bardsong (immunity to fear)
[15:51:40] <-- lubos has left IRC (Quit: Leaving.)
[15:58:31] <CIA-93> GemRB: 03avenger_teambg * r63c43ce2ba50 10gemrb/gemrb/ (3 files in 2 dirs): implemented bardsong opcode
[16:01:11] <-- SiENcE has left IRC (Quit: @all: cya)
[16:26:22] --> Maighstir has joined #GemRb
[17:16:46] --> spike411 has joined #GemRb
[17:51:34] <CIA-93> GemRB: 03lynxlupodian * r8117a54cdf67 10gemrb/gemrb/core/Scriptable/ActorBlock.cpp: *::TryBashLock: besides the skill, also luck and 1d10 decides the success
[18:56:57] <lynxlynxlynx> why do we do trap detection inside TriggerTrap?
[18:59:13] <fuzzie> that's not right?
[19:00:29] <lynxlynxlynx> it's another save
[19:01:05] <lynxlynxlynx> always if you try to force a trap to trigger, since skill==0
[19:01:33] <lynxlynxlynx> is this something REd or just a guess?
[19:01:38] <fuzzie> it doesn't seem very likely, honestly
[19:01:55] <fuzzie> the 'return false;', at least
[19:02:57] <fuzzie> i seem to have fiddled with this quite a bit
[19:05:12] <lynxlynxlynx> only TryDisarm uses it with an actual skill
[19:05:47] <fuzzie> but i don't really understand what you mean
[19:06:03] <fuzzie> if skill is zero then it should never save, right?
[19:06:33] <lynxlynxlynx> i don't think it should save even for nonzero skill
[19:06:46] <fuzzie> sure, i'm just wondering what you mean
[19:07:06] <fuzzie> the code is from 2004, i doubt if it was REed
[19:07:26] <fuzzie> forcing the skill to 100 doesn't seem right either?
[19:07:48] <fuzzie> e0c7f4e8 if you didn't find it already
[19:08:42] <lynxlynxlynx> the whole block looks bad to me
[19:08:47] <fuzzie> sure
[19:08:54] <fuzzie> i'm just looking at the commit :)
[19:08:56] <lynxlynxlynx> you get extra saves when the effects fire
[19:09:22] <fuzzie> well, if there is a save against the trap triggering, it has to be here
[19:10:37] <fuzzie> but it does seem unlikely.
[19:11:36] * lynxlynxlynx summons avenger
[19:11:59] <fuzzie> it should be easy for him to answer, the offsets for this stuff seem known..
[19:12:57] <lynxlynxlynx> unrelated: a load hint reminded me of one missing feature
[19:13:08] <lynxlynxlynx> shift+clicking sets waypoints
[19:16:12] <lynxlynxlynx> i'm doing something else wrong too
[19:16:35] <lynxlynxlynx> triggertrap isn't enough to actually trigger a trap
[19:18:13] <fuzzie> no
[19:20:03] <fuzzie> should be enough?
[19:20:16] <fuzzie> i mean, assuming you have an actor
[19:20:53] <lynxlynxlynx> i do, but nothing happens
[19:22:13] <fuzzie> as long as the trap is trapped+active and has a script, it should be fine
[19:22:29] <lynxlynxlynx> active as in Trapped == 1?
[19:22:45] <fuzzie> and without a deactivated flag
[19:23:06] <lynxlynxlynx> i didn't see any check for that
[19:23:12] <fuzzie> what kind of trap?
[19:23:18] <lynxlynxlynx> door
[19:23:36] <fuzzie> so yes, no deactivated flag
[19:23:46] <lynxlynxlynx> http://pastebin.ca/1949824
[19:24:33] <fuzzie> looks fine
[19:24:35] <lynxlynxlynx> i see what you meant now
[19:25:02] --> |Cable| has joined #GemRb
[19:25:03] <fuzzie> it's not being triggered from inside a cutscene or something?
[19:25:17] <lynxlynxlynx> no, i'm trying to bash it
[19:26:08] <lynxlynxlynx> http://pastebin.ca/1949828 <-- with this
[19:27:22] <fuzzie> well, the Trapped check isn't needed, i guess
[19:28:05] <lynxlynxlynx> true, but that's not a problem
[19:28:57] <fuzzie> how strange, though
[19:29:33] <fuzzie> oh, no
[19:29:50] --> edheldil_ has joined #GemRb
[19:29:53] <fuzzie> not strange
[19:29:57] <fuzzie> trigger bug :(
[19:30:28] <fuzzie> no, wait, the triggers are set on the *trap*.
[19:30:31] <fuzzie> never mind me
[19:32:22] <fuzzie> so, the script checks Entered() and Opened()
[19:32:54] <lynxlynxlynx> eh
[19:32:54] <fuzzie> it isn't open, and gemrb's Entered() returns false if it isn't trapped
[19:34:20] <fuzzie> since Entered() is a normal trigger, i doubt a Trapped check there is correct
[19:34:28] <fuzzie> but i don't really have any clue beyond that
[19:34:55] <lynxlynxlynx> since the trap isn't repeating, Trapped gets disabled before Entered gets called?
[19:34:58] <fuzzie> (in the original engine, normal triggers (without 0x4 at the start) are always just plain matches against the trigger list, as far as i know)
[19:35:14] <lynxlynxlynx> we don't run scripts in another thread, do we?
[19:35:20] <fuzzie> nope
[19:35:25] <fuzzie> so yes, Trapped is disabled right there
[19:35:56] <fuzzie> i don't understand how traps would ever work, maybe i'm missing the obvious?
[19:36:52] <fuzzie> oh right, Entered() doesn't even check that, for doors
[19:38:26] <fuzzie> i'm sure it is easier to just ask Avenger
[19:40:25] <fuzzie> the only thing my copy of his notes has is the case where the bash works.
[19:40:36] <fuzzie> and then only the Unlocked() bit.
[19:42:05] <fuzzie> assuming this actually does anything in the original :)
[20:17:30] --> pupnik has joined #GemRb
[21:07:22] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[21:28:25] <CIA-93> GemRB: 03avenger_teambg * r0d77b2dbae1b 10gemrb/gemrb/ (19 files in 11 dirs): added autodetecting secret doors
[21:29:33] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[21:37:25] <CIA-93> GemRB: 03avenger_teambg * r7837bc4274f6 10gemrb/gemrb/GUIScripts/ (bg2/LoadScreen.py iwd2/LoadScreen.py): fixed loadscreens in bg2/iwd2