#gemrb@irc.freenode.net logs for 22 Sep 2009 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:34:10] <-- pupnik_ has left IRC ("leaving")
[00:34:41] --> pupnik has joined #gemrb
[00:45:09] <-- tombhadAC has left IRC (orwell.freenode.net irc.freenode.net)
[00:45:09] <-- |Cable| has left IRC (orwell.freenode.net irc.freenode.net)
[00:55:29] --> tombhadAC has joined #GemRb
[00:55:29] --> |Cable| has joined #GemRb
[00:56:12] <-- |Cable| has left IRC (Read error: 110 (Connection timed out))
[00:56:43] --> |Cable| has joined #gemrb
[00:56:59] --> pupnik64 has joined #gemrb
[00:58:17] <-- pupnik64 has left IRC (Client Quit)
[05:13:38] <-- tombhadAC has left IRC (Remote closed the connection)
[06:11:44] --> Gekz has joined #GemRB
[06:38:51] * pupnik Away, but within earshot of privmsg beep - mostly
[07:24:32] --> Gekz_ has joined #GemRB
[07:24:49] <-- Gekz has left IRC (Read error: 60 (Operation timed out))
[07:44:59] --> lynxlynxlynx has joined #gemrb
[07:44:59] --- ChanServ gives channel operator status to lynxlynxlynx
[08:47:20] <-- |Cable| has left IRC (Remote closed the connection)
[10:59:13] --> Gekz has joined #GemRB
[11:01:50] <-- Gekz_ has left IRC (Read error: 104 (Connection reset by peer))
[11:06:11] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[11:14:47] --> Gekz has joined #GemRB
[11:39:21] <CIA-22> gemrb: 03lynxlupodian * r7244 10/gemrb/trunk/gemrb/ (6 files in 6 dirs):
[11:39:21] <CIA-22> gemrb: added another game flag to discern whether a game has two stealth stats;
[11:39:21] <CIA-22> gemrb: also hide in shadows or just move silently (stealth)
[11:39:53] <fuzzie> morning
[11:39:59] <fuzzie> oh, that's coincidence :)
[11:40:14] <lynxlynxlynx> oj
[11:40:22] <lynxlynxlynx> what coincidence?
[11:40:48] <fuzzie> i started typing 'morning' before CIA spoke :)
[11:41:05] <lynxlynxlynx> you're up pretty late
[11:41:31] <fuzzie> those dratted morning lectures got in the way
[11:42:01] <lynxlynxlynx> but it is almost 1400
[11:42:21] <lynxlynxlynx> here lectures start with october :)
[11:42:32] <fuzzie> here lectures started on 31st august :(
[11:43:50] <Gekz> I dont go to uni and feel out of the loop.
[11:44:45] <fuzzie> it is not quite as exciting as rumoured
[11:45:09] <lynxlynxlynx> it's very exciting in an Oghmatic way :P
[11:45:57] <lynxlynxlynx> i can't imagine what a sorry lot i'd be hadn't i gone to uni
[11:46:06] <Gekz> well
[11:46:14] <Gekz> it's likely that I'll fuck up my final exams in 4 weeks
[11:46:19] <Gekz> and not be able to enter uni
[11:46:23] <Gekz> which would make me a sad boy.
[11:48:30] <lynxlynxlynx> 4 weeks is quite some time
[11:48:30] <lynxlynxlynx> do i need to kick you out of here? ;)
[11:52:55] <lynxlynxlynx> i've got most of the hiding action written down
[11:53:26] <lynxlynxlynx> but this only helps scripts, since our modal actions just cast spells from the table
[11:54:10] <fuzzie> it's no problem to change our modal actions if required
[11:54:31] <lynxlynxlynx> sure
[11:56:13] <lynxlynxlynx> i wonder why they weren't tied to actions in the first place, it seems all have counterparts there
[11:56:43] <fuzzie> well, we wrote it to make Find Traps work
[11:57:27] <fuzzie> so it didn't get a lot of thought
[11:57:32] <fuzzie> i wonder how it works in the original game
[11:58:06] <fuzzie> it can't be a 'real' action (on the queue) because then it would be reset by things like walking
[11:58:18] <fuzzie> when /are/ modal actions disabled?
[11:59:10] <lynxlynxlynx> combat
[11:59:30] <fuzzie> but not by interacting with things like containers, doors, etc? i guess not
[11:59:33] <lynxlynxlynx> maybe the same as with with invisibility
[12:06:35] <lynxlynxlynx> we already do the reset
[12:07:10] <lynxlynxlynx> except for combat
[12:07:39] <fuzzie> i think our reset code is flawed and should be more general, but i forget why
[12:32:10] <Gekz> haha
[12:36:33] <CIA-22> gemrb: 03lynxlupodian * r7245 10/gemrb/trunk/gemrb/plugins/Core/ (Actor.cpp Actor.h): added Actor::ResetState to cure the invisibility, sanctuary and modal states
[12:37:05] <Gekz> is that a member function?
[12:37:18] <Gekz> ie, a function of the Actor class
[12:38:25] <raevol> hello
[12:38:28] <lynxlynxlynx> yes, that's why it has the Actor::
[12:38:38] <lynxlynxlynx> ojla
[12:46:09] --> pupnik_ has joined #gemrb
[12:46:39] <Gekz> lynxlynxlynx: then my learning of C++ is progressing :D
[12:57:44] <lynxlynxlynx> :)
[13:01:59] <-- pupnik has left IRC (Read error: 110 (Connection timed out))
[13:27:40] <CIA-22> gemrb: 03lynxlupodian * r7246 10/gemrb/trunk/gemrb/plugins/Core/ (Actions.cpp Game.cpp Game.h): implemented most of the Hide action
[16:44:49] --> kingron has joined #gemrb
[17:16:50] <lynxlynxlynx> oh crap
[17:25:02] --> |Cable| has joined #gemrb
[17:25:12] <-- |Cable| has left IRC (Read error: 104 (Connection reset by peer))
[17:25:16] --> |Cable| has joined #gemrb
[17:25:28] <-- |Cable| has left IRC (Read error: 104 (Connection reset by peer))
[17:25:41] --> |Cable| has joined #gemrb
[17:54:37] <lynxlynxlynx> fuzzie: here?
[17:55:00] <fuzzie> hi
[18:04:01] <lynxlynxlynx> sorry, got interrupted
[18:04:51] <lynxlynxlynx> http://pastebin.com/d152811e5 <-- the effects crash; the first new check doesn't help, as expected, but the second one does. So something empties effects when the loop body starts
[18:05:36] <lynxlynxlynx> memory corruption from somewhere else?
[18:05:40] <fuzzie> oh?
[18:06:00] <fuzzie> the only possibilities i found was ApplyEffect modifying the list
[18:06:32] <lynxlynxlynx> i'll check how many times it gets called
[18:08:18] <fuzzie> printing effect_refs[(*f)->Opcode].Name before calling ApplyEffect ought to make it obvious where it goes wrong, i hope in an inventory effect..
[18:08:51] <fuzzie> (although if it does exit on the first iteration then that must be corruption, yes)
[18:09:10] <lynxlynxlynx> it is the third effect
[18:09:11] <fuzzie> oh, right, it might die on the first iteration because it's actually recursively calling itself
[18:11:02] <lynxlynxlynx> PlaySound
[18:11:49] <fuzzie> ok, that is weird :p
[18:12:11] <lynxlynxlynx> that's the last thing printed before the segfault, but that means *f is ok
[18:13:01] <fuzzie> well, if my assumption is correct, it crashes on the 'f++'
[18:13:07] <fuzzie> maybe your print statements show otherwise?
[18:13:44] <lynxlynxlynx> oh, something interesting
[18:14:06] <lynxlynxlynx> Item:Remove gets applied twice and the loop count is the same :s
[18:14:11] <fuzzie> yes
[18:14:18] <fuzzie> Item:Remove -> inventory modification -> known corruption
[18:14:36] <lynxlynxlynx> RRRRRRRRRRRRR+1+Item:Remove+
[18:14:37] <lynxlynxlynx> RRRRRRRRRRRRR+1+Item:Remove+
[18:14:39] <lynxlynxlynx> RRRRRRRRRRRRR+2+PlaySound+
[18:14:48] <lynxlynxlynx> 1 is a simple int counter
[18:15:11] <fuzzie> the trouble is, Item:Remove recursively calls into the effect code
[18:15:16] <fuzzie> to make sure effects from the removed objects are removed
[18:15:50] <lynxlynxlynx> but the loop checks are evaluated each time
[18:16:05] <fuzzie> it's the 'f' which gets corrupted
[18:16:23] <fuzzie> the effects list itself is fine
[18:17:31] <fuzzie> anyway: if Item:Remove is really recursively calling into the effect code, trying to stop the crash there is just going to make the big silent..
[18:17:42] <lynxlynxlynx> would something like if (!(f+1)) break; at the end of the loop help?
[18:17:51] <fuzzie> erm, the bug
[18:17:52] <lynxlynxlynx> true
[18:19:21] <lynxlynxlynx> at the point of the crash, the acolyte only has the fist item left in the inventory
[18:20:03] <fuzzie> Inventory::RemoveSlotEffects is the thing to break on
[18:21:27] <fuzzie> the item will be removed by that point, though (via KillSlot), i guess
[18:25:36] <lynxlynxlynx> it's the flame blade with several equipping effects
[18:26:07] <fuzzie> hum
[18:26:30] <fuzzie> well, the fix is to delay the RemoveSlotEffects call until after the effects get applied
[18:27:12] <fuzzie> but that's a huge pain for a few reasons, which is why Avenger was suggesting someone just implement a generic queue system for that (with which you can fix ClearActions, Kill, etc too)
[18:27:22] <fuzzie> but i guess that doesn't help rtight now :(
[18:27:52] <lynxlynxlynx> i have a workaround and i don't hit this problem often, so it is manageable
[18:31:45] --> Avenger has joined #gemrb
[18:32:04] --- ChanServ gives channel operator status to Avenger
[18:32:20] <-- kingron has left IRC ("Leaving")
[18:33:41] <Avenger> hi
[18:34:11] <lynxlynxlynx> hi
[18:34:28] <lynxlynxlynx> i get an odd action problem now
[18:34:46] <lynxlynxlynx> how/caratrg3.baf was ran and i got the journal entry, but the global is still 0
[18:35:37] <lynxlynxlynx> nope, disregard that
[18:35:49] <lynxlynxlynx> i keep using the wrong function to lookup the value
[18:36:10] <Avenger> hehe
[18:36:18] <Avenger> ok, because i was puzzled by that
[18:37:27] <lynxlynxlynx> the dialog problem is caused by an unset var
[18:37:42] <lynxlynxlynx> my first guess is that the engine autogenerates them
[18:37:49] <lynxlynxlynx> AR3600_Visited is 0, but i was there
[18:38:06] <Avenger> i think refresheffects shouldn't be called by removesloteffects
[18:38:15] <lynxlynxlynx> and it doesn't match in any script, only in a dialog, but that's readonly
[18:38:22] <fuzzie> Avenger: it can't remove effects either
[18:38:27] <fuzzie> so it needs delaying in any case
[18:38:40] <Avenger> the remove call is ok
[18:38:47] <Avenger> that would just set their timing
[18:38:51] <Avenger> that's fine
[18:38:53] <fuzzie> oh, ok
[18:39:13] <Avenger> the problem is that 'refresheffects' would cause their immediate removal
[18:39:17] <Avenger> THAT is bad
[18:39:43] <Avenger> refresheffects should be called from 1. gui, 2. the refresh loop
[18:39:45] <fuzzie> doesn't the current gemrb code call that every frame anyway?
[18:39:46] <Avenger> nothing else
[18:39:58] <Avenger> yes, but it would be bad for gui
[18:40:11] <Avenger> if you remove an armor, the stats wouldn't update immediately
[18:40:16] <Avenger> that's why it is there
[18:40:28] <Avenger> but it would still work if it is in the guiscript function
[18:40:38] <Avenger> so, i think it is an easy workaround
[18:40:40] <fuzzie> huh, interesting
[18:40:55] <fuzzie> how does the code avoid repeating effects while paused?
[18:41:31] <Avenger> the loop doesn't work while paused, and i think it doesn't avoid recurring damage...
[18:42:01] <Avenger> actually, if you are regenerating, you could probably equip/remove/equip/remove for cheap healing while paused
[18:42:12] <Avenger> i think that would work
[18:42:18] <fuzzie> can you really do that in the original?
[18:42:21] <Avenger> no
[18:42:28] <Avenger> i don't think so :)
[18:42:32] <fuzzie> i just think .. if the gui calls that, then we don't really fix the bug
[18:42:43] <Avenger> we fix the crasher part
[18:42:52] <Avenger> and make one step closer to the original version
[18:42:55] <fuzzie> well, sure, i just wonder if there's a less silly way to fix it in general
[18:43:19] <Avenger> i don't know, the effect refreshing 'side effect' is there in the current version as well
[18:43:29] <Avenger> and the original engine does some effect reapply too
[18:43:41] <Avenger> it just does the recurring stuff somehow differently
[18:44:08] <Avenger> i think it adds a recurring effect, and then the effect goes 'dormant'
[18:44:19] <Avenger> if it is reapplied, it won't work, only on reload
[18:44:49] <Avenger> there is a 'recurring effect' list, it gets added there
[18:45:15] <fuzzie> ok, so that is different code to implement
[18:45:38] <Avenger> yes, but this change is independent from that one
[18:45:45] <Avenger> this change is needed anyway
[18:46:28] <Avenger> btw, not all engines implement all recurring damage correctly :)
[18:46:45] <Avenger> for example iwd crashes on burning blood effect if it is on an item :)
[18:47:07] <Avenger> it tries to apply the effect while the actor is not in any area
[18:47:26] <Avenger> and i think it applies it when you equip/remove items too
[18:48:05] <Avenger> i didn't do the recurring damage like in the original because it is a separate queue, and i thought i could avoid it
[18:48:41] <Avenger> i still think it might be avoidable, we probably just need a flag
[18:49:06] <Avenger> and probably the first apply field could be hacked into a bitfield :)
[18:50:34] <Avenger> back to lynx, you think <areaname>_visited is set by the engine?
[18:50:46] <lynxlynxlynx> it appears so
[18:51:07] <lynxlynxlynx> first time i hit the problem i thought it was due to my hacking around, but now it repeated
[18:51:16] <lynxlynxlynx> and grepping only shows variable reads
[18:51:19] <Avenger> well, ithought it isn't true, but there is a _Visited string in the engine
[18:51:24] <Avenger> so, you should be right
[18:51:39] <lynxlynxlynx> :)
[18:51:53] <Avenger> all areas get this?
[18:51:57] <Avenger> or there is a flag in areas
[18:52:25] <lynxlynxlynx> no idea, but iwd is the first place i noticed the importance
[18:52:49] <Avenger> if there is no flag that is unused in ToB/Bg1 etc, then we need a new gameflag
[18:52:58] <Avenger> tob has no such string
[18:53:21] <Avenger> iwd2 has _visited, and _revealed too
[18:54:16] <Avenger> pst sets the _visited variables by script
[18:54:30] <Avenger> so this is an iwd/iwd2 feature
[18:55:24] <Avenger> got iwd2 in searchable format? can you check if _revealed is used?
[18:56:18] <lynxlynxlynx> set by scripts
[18:56:39] <Avenger> hmm, interesting
[18:57:08] <lynxlynxlynx> only for a few areas though
[18:57:59] <Avenger> i look into a saved game to see if it is set for all areas
[19:01:04] <Avenger> it looks like all areas
[19:01:44] <Avenger> well, i think it needs a gameflag, then whenever an area is loaded, the areaname+_visited variable could be set
[19:03:15] <lynxlynxlynx> pst seems to do it all manually
[19:03:32] <fuzzie> well, pst has some pre-set
[19:03:35] <fuzzie> but that is already coded
[19:03:54] <Avenger> btw, in the hide action, the original engine checks for night/day (if it is a night/day area, it does something to the light), if it is an extended night area, it checks the proper lightmap (i guess we already update it, so you just need to adjust it for night/day areas)
[19:04:16] <Avenger> and i think it is better to have a map->GetLightLevel(Point ) method
[19:04:42] <lynxlynxlynx> there's other stuff to add
[19:04:50] <Avenger> to hide?
[19:05:21] <lynxlynxlynx> besides the TODOs, i was wondering why modal state setting doesn't call actions yet
[19:05:53] <Avenger> you mean, if the modal state is set, it should call an action recurringly?
[19:05:54] <lynxlynxlynx> we just read modal.2da and apply the spell, so the action improvement doesn't show for players yet
[19:06:28] <Avenger> i don't understand that, what is an action improvement
[19:06:48] <lynxlynxlynx> an example is the extension of Hide
[19:07:18] <lynxlynxlynx> if you click the hide in shadows button, it doesn't call the action, but just applies the spell
[19:07:28] <lynxlynxlynx> (with quite a delay at that)
[19:07:42] <lynxlynxlynx> so there is no skill check, it always works
[19:08:29] <Avenger> i see, actually, i don't know how exactly this works in the original
[19:08:43] <Avenger> pressing the hide button isn't the same as calling the hide action
[19:08:52] <fuzzie> the hide action code isn't called?
[19:09:02] <fuzzie> some shared function on their Actor?
[19:09:04] <Avenger> i'm pretty sure it is called indirectly
[19:09:46] <Avenger> actually, i don't really see why the hide action turns the modal state to 0 before checks, (then turns it to hide), but if it is called from the modal, it makes sense.
[19:10:27] <Avenger> this stuff needs a little more research :)
[19:10:44] <Avenger> unless you want to implement it somehow
[19:11:04] <Avenger> that works too, but it might change later
[19:11:17] <lynxlynxlynx> it's a bit much for me, but it would be nice to have a proper stealth for players
[19:11:35] <lynxlynxlynx> i can commit the spell, but that always works
[19:14:00] <Avenger> well, my current understanding is this: the button pressing would set the modal state, which in turn executes the proper action (periodically), the action would apply the spells, in case of hide, it would be a simple invisibility spell.
[19:14:34] <Avenger> but i cannot say this is how the IE works, yet
[19:15:01] <lynxlynxlynx> that's how i imagined it too
[19:15:48] <Avenger> sadly this means, our modal.2da needs a new column
[19:15:58] <Avenger> the action should be there too
[19:16:25] <lynxlynxlynx> trivial to change
[19:17:01] <Avenger> ok
[19:17:19] <Avenger> if that works for you, that's great :)
[19:17:37] <Avenger> eventually i will see the code for it in the IE then we can refine
[19:20:57] <Avenger> i commented out the effect updates from AddSlotEffects and RemoveSlotEffects
[19:21:10] <lynxlynxlynx> :)
[19:21:21] <Avenger> checking if doing this will wreck the gui or not
[19:23:27] <Avenger> huh this is worse than i expected
[19:23:48] <Avenger> it caused no effects updated, even outside of the inventory screen
[19:28:40] <CIA-22> gemrb: 03lynxlupodian * r7247 10/gemrb/trunk/gemrb/plugins/Core/ (Actions.cpp Map.cpp Map.h): added Map::GetLightLevel
[19:34:24] <lynxlynxlynx> fuzzie: about that party centering thing, do you think it would work as another queued action the end of Map::MoveToNewArea ?
[19:35:21] <fuzzie> those actions are executed at once, so i assume not, but i forget what the problem was
[19:35:29] <fuzzie> you could always try :)
[19:36:29] <lynxlynxlynx> the problem: you enter an area and the viewport is not on your party but somewhere else
[19:36:57] <fuzzie> i think i added prints and the viewport does get moved but then it gets moved back by something?
[19:37:04] <fuzzie> i just mean that i forget if that was it
[19:37:46] <lynxlynxlynx> good that i ask then :)
[19:38:59] <lynxlynxlynx> i will check the prints then
[19:39:11] <-- Avenger has left IRC ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]")
[19:40:12] <fuzzie> maybe the viewport move was being cancelled? i forget, the viewport code never seems to do moves instantly (i changed that in a bunch of places, it was annoying me)
[19:46:18] <CIA-22> gemrb: 03lynxlupodian * r7248 10/gemrb/trunk/gemrb/ (5 files in 5 dirs): added the AreaVisitedVar game flag for use in iwd2*
[19:53:52] --> Avenger has joined #gemrb
[19:54:32] --- ChanServ gives channel operator status to Avenger
[20:39:25] <lynxlynxlynx> i've got the area var almost working, but i have to go now
[20:40:42] <-- lynxlynxlynx has left IRC (Remote closed the connection)
[20:50:14] --> tombhadAC has joined #gemrb
[20:56:47] <Avenger> bye
[20:56:48] <-- Avenger has left IRC ("bye!")
[21:58:36] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[22:55:07] <-- tombhadAC has left IRC (Remote closed the connection)