#gemrb@irc.freenode.net logs for 16 Jul 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:01:53] --> cryptopsy has joined #gemrb
[00:02:06] <cryptopsy> anyone want to play iwd2 multiplayer with me tonight? i've never played it before
[00:02:33] <cryptopsy> i'd also like to download the soundtrack, if someone could upload it for me that would be great!
[00:06:05] <cryptopsy> cool jeremy soule was the composer for these tracks
[00:06:18] <cryptopsy> he did the score for total annihilation one of the best only maybe to the mercenaries series
[00:34:12] <-- duckpunch has left IRC (Read error: Connection reset by peer)
[00:34:59] --> duckpunch has joined #gemrb
[00:35:21] <cryptopsy> i found a bunch of game soudtracks in mediafire links you guys want?
[00:35:25] <cryptopsy> the list has about 1000+ games
[01:33:26] <-- cryptopsy has left IRC (Quit: Lost terminal)
[03:33:44] <-- duckpunch has left IRC (Read error: Connection reset by peer)
[03:34:23] --> duckpunch has joined #gemrb
[05:03:12] <wirehead> does anyone here have an HTC HD2/
[05:03:29] <wirehead> or a Desire Z?
[06:33:16] <-- duckpunch has left IRC (Read error: Connection reset by peer)
[06:33:52] --> duckpunch has joined #gemrb
[07:17:40] --> lynxlynxlynx has joined #gemrb
[07:17:41] <-- lynxlynxlynx has left IRC (Changing host)
[07:17:41] --> lynxlynxlynx has joined #gemrb
[07:17:41] --- ChanServ gives channel operator status to lynxlynxlynx
[08:05:46] --> Avenger has joined #gemrb
[08:05:51] <Avenger> hello
[08:06:00] --- ChanServ gives channel operator status to Avenger
[08:08:54] <wirehead> or some other snapdragon qwerty phone
[08:17:06] <CIA-40> GemRB: 03avenger_teambg * r93192b913dcc 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: display contingency failure message
[08:18:17] <fuzzie> supposedly it runs ok on a desire z, but i haven't tried it on the one here
[08:18:38] <fuzzie> and i imagine memory usage is probably an issue
[08:22:30] <lynxlynxlynx> oh, we already had the message wired :)
[08:30:09] <Avenger> yep
[08:30:44] <Avenger> i'm not sure about the other message and the self check, though
[08:36:05] <lynxlynxlynx> cosmetics
[08:39:30] <lynxlynxlynx> i added a frame check, but it doesn't help much
[08:40:03] <lynxlynxlynx> it breaks the infinite loop, but that's it
[08:41:45] <fuzzie> well, the original contingency trigger handler keeps *one* contingency time, and then refuses to do more than one contingency in that GameTime, all others are ignored
[08:42:08] <fuzzie> so you'd think you'd duplicate that behaviour
[08:42:52] <fuzzie> unless there are multiple contingency effects involved here?
[08:43:28] <fuzzie> although actually, *real* contingencies just self-destruct without setting the time
[08:55:41] <lynxlynxlynx> actually there is no infinite loop anymore, even without that
[08:56:19] <lynxlynxlynx> if (fx->Parameter4 == core->GetGame()->GameTime) return FX_APPLIED;
[08:56:19] <lynxlynxlynx> fx->Parameter4 = core->GetGame()->GameTime;
[08:56:38] <lynxlynxlynx> that's what i had, but it never returned there
[09:01:59] <fuzzie> worrying? :P
[09:03:24] <Avenger> what infinite loop
[09:03:46] <fuzzie> Avenger: spell casting means effect queue gets applied which means the effects all get re-run
[09:04:10] <Avenger> we need to remove effects, yes
[09:04:30] <Avenger> that's when the extra message is printed too :)
[09:04:33] <fuzzie> so without a GameTime check, you can get infinite fx_cast_spell_on_condition triggering between two actors
[09:04:54] <Avenger> there is an 'is_contingency' flag
[09:05:07] <fuzzie> *real* contingencies get removed, so they don't matter
[09:05:23] <Avenger> hmm, my fireshield didn't cause any problem either
[09:05:27] <fuzzie> but other uses of the contingency list don't, they have a GameTime check instead (in original, too)
[09:05:39] <Avenger> fireshield was fine
[09:05:45] <Avenger> triggered only once
[09:05:53] <fuzzie> with fireshield on two actors, hitting each other?
[09:05:57] <Avenger> yes
[09:06:01] <fuzzie> i mean, i only know what lynx reported :P
[09:06:08] <fuzzie> but i don't see anything which would've fixed it, since then
[09:06:12] <Avenger> i put fireshield on aerie, then hit her with minsc :)
[09:06:34] <Avenger> also tried ranged weapons
[09:06:52] <Avenger> i just tested the spell failed message
[09:07:09] <Avenger> maybe i was just lucky i don't know
[09:07:23] <fuzzie> well, if it's fixed then it's fine, i just don't see how it would happen before and not now
[09:08:24] <Avenger> ahh there is this per_round hack by lynx
[09:08:38] <fuzzie> that isn't a hack :P
[09:08:43] <Avenger> i'm pretty sure it isn't how the original works, but it works
[09:08:47] <fuzzie> the original hardcodes 100
[09:08:55] <Avenger> 100 what?
[09:09:01] <fuzzie> owner ticks
[09:09:17] <fuzzie> ToBEx will let you change it via an effect parameter
[09:09:30] <Avenger> hehe
[09:09:38] <fuzzie> so, i guess they have it fully decoded?
[09:09:39] <Avenger> we can support that
[09:09:59] <Avenger> when the first mod uses it :)
[09:10:39] <fuzzie> my notes say "original maintaines a ContingencyTimer in each scriptable, subtract 1 every tick, run contingencies and set timer to 100 when timer is <=0"
[09:11:15] <Avenger> and it fires the contingency only when the timer is?
[09:11:23] <Avenger> 0?
[09:11:26] <Avenger> or what
[09:11:29] <fuzzie> when it is <=0
[09:11:43] <fuzzie> (i guess because contingencies don't run in cutscenes, so the timer can get lower than 0)
[09:11:55] <Avenger> i see
[09:12:37] <Avenger> well, i didn't see this filter stuff. but when i said i'm pretty sure it isn't the original works, i just meant it has no such distinction between the trigger conditions
[09:12:38] <fuzzie> but this is only relevant for 0x4xxx triggers, as I note in the comment
[09:12:44] <Avenger> oh
[09:12:55] <Avenger> ok, now i understand
[09:13:10] <Avenger> then i'm not sure anymore about the distinction :)
[09:13:15] <fuzzie> hehe
[09:13:22] <fuzzie> well, you know there are two different functions for checking contingencies?
[09:13:25] <Avenger> i didn't even realize what you meant with the 0x4... :)
[09:13:31] <Avenger> yes
[09:13:54] <Avenger> i don't mean i know them, i didn't really realize WHY there are two of them
[09:13:58] <fuzzie> ah
[09:14:08] <fuzzie> well, it makes sense? :)
[09:14:15] <Avenger> now it makes more sense, yes
[09:14:43] <Avenger> though, i still think their implementation is overly complicated :)
[09:15:07] <Avenger> i don't quite understand why they build a separate trigger list
[09:15:11] <fuzzie> well, their implementation of lists maintained from effects is clearly *broken* :)
[09:15:20] <fuzzie> like the recurring damage effects, it just doesn't work properly
[09:15:50] <Avenger> yep, i'm pretty sure we can go without building those
[09:15:53] <fuzzie> so i wouldn't try making too much sense of it
[09:16:06] <fuzzie> but i wrote a big comment at the top of fx_cast_spell_on_condition
[09:16:35] <Avenger> it was tldr, i admit :D
[09:17:39] <Avenger> the original also has a flag 'is_contingency' in their maintained contingency list
[09:17:53] <fuzzie> but we can just use Parameter3 directly, right?
[09:18:00] <Avenger> yes
[09:18:33] <fuzzie> we don't seem to do the spell removal here?
[09:18:36] <fuzzie> there
[09:18:42] <Avenger> do you now have access to the ida db?
[09:18:46] <fuzzie> maybe you know how that works :P
[09:18:58] <Avenger> i didn't figure out that part yet
[09:19:13] <Avenger> you meant the effect removal ?
[09:19:29] <fuzzie> i dunno, my notes say 'remove two spells'
[09:19:43] <fuzzie> i have access to db, but cooking lunch
[09:19:43] <Avenger> spells are removed when they go into the contingency (if they are built by contingency creation)
[09:20:17] <lynxlynxlynx> re excessive application: minsc should have a fireshield active too for you to experience it
[09:20:21] <Avenger> but i agree, i saw a special effect block removal code just in the end of the contingency processing
[09:20:41] <Avenger> two fireshields resonating?
[09:20:46] <Avenger> lol
[09:20:59] <Avenger> i never had it in the original either
[09:20:59] <lynxlynxlynx> yep
[09:21:28] <Avenger> it is clearly a bug if a fireshield triggers another
[09:21:40] <Avenger> the whole crap should be applied only for melee attacks
[09:21:56] <lynxlynxlynx> wouldn't solve anything
[09:22:19] <Avenger> why not, the fireshield wouldn't trigger the other
[09:22:42] <fuzzie> what does the fireshield trigger on, AttackedBy?
[09:22:46] <lynxlynxlynx> i don't know if the spell's description is correct, but it also says casting inside the range would trigger it
[09:23:00] <lynxlynxlynx> so mm hits should activate it too probably
[09:23:02] <Avenger> i noticed in the original that a ranged attack (like a sling slot) triggers it
[09:23:07] <Avenger> i always thought it is crap
[09:23:26] <lynxlynxlynx> fuzzie: hitby, atleast in gemrb
[09:23:38] <Avenger> yes, we use the same, but i didn't like it
[09:23:54] <Avenger> they just documented their failure there, lynx :)
[09:24:07] <lynxlynxlynx> could be
[09:24:18] <Avenger> they went the easy way, and use already existing triggers
[09:24:20] <fuzzie> HitBy should definitely only be set by *hits* in the Attack actions
[09:24:33] <Avenger> and their trigger cannot say 'hit by melee'
[09:25:14] <Avenger> let me see what fireshield has
[09:25:16] <fuzzie> i'm not quite sure where AttackedBy is set, apparently i found it in a function which Avenger marked as isHostile?
[09:26:25] <Avenger> 0 is on hit
[09:26:30] <Avenger> so it should be HitBy
[09:26:50] <fuzzie> oh hm
[09:26:58] <fuzzie> if you happen to hit each other at the same time, it will break without the GameTime check
[09:27:25] <Avenger> but there is this per_round flag now
[09:27:35] <fuzzie> but that is only set for 0x4xxx, right?
[09:27:39] <Avenger> ahh it is disabled for hitby
[09:28:00] <fuzzie> once per round is definitely not right for hitby :)
[09:28:06] <Avenger> yes
[09:28:20] <Avenger> but how would this go wrong
[09:28:42] <Avenger> even if both of us got a fireshield, the fireshield damage shouldn't register as a hitby (melee)
[09:28:49] <Avenger> it is a hit by spell
[09:29:09] <lynxlynxlynx> we set hitby in actor::damage, where everyone ends up
[09:29:15] <Avenger> yep
[09:29:19] <fuzzie> ah, well, that is jsut wrong
[09:29:23] <Avenger> maybe we should make a distinction
[09:29:44] <Avenger> can't we just set the type in hitby? :)
[09:29:57] <fuzzie> no, because it breaks all existing scripts
[09:30:32] <fuzzie> there's a discussion about this on ToBEx forum again
[09:30:45] <Avenger> well there are more than one ints in the trigger?
[09:31:20] <Avenger> the first int is for the flunked damage type anyway :)
[09:31:23] <fuzzie> oh, well, i guess you could do something there :P
[09:31:25] <Avenger> i didn't meant to change that
[09:31:46] <Avenger> the second int could be the melee/ranged distinction
[09:32:11] <Avenger> and... if some modder wants, they can use it for HitBy(..., whatever, RANGED)
[09:32:16] <fuzzie> but the usual cause of loops is because Actor::RefreshEffects re-runs *all* effects, and that is called from AddSlotEffects/RemoveSlotEffects, which are called in all kinds of places
[09:32:48] <Avenger> hmm
[09:32:49] <-- duckpunch has left IRC (Read error: Connection reset by peer)
[09:33:05] <Avenger> maybe that needs to be regulated, yep
[09:33:34] <Avenger> either restrict the calls, or build some delay mechanism
[09:34:00] --> duckpunch has joined #gemrb
[09:34:03] <fuzzie> the trouble is, you want the inventory to update when the game is paused
[09:34:28] <Avenger> yes, even the portrait icons :(
[09:34:34] <fuzzie> maybe we could have an effect flag which says "only run when it's a main loop call"?
[09:34:43] <fuzzie> then we could set that flag on contingency, damage, etc
[09:34:55] <Avenger> meh
[09:35:04] <Avenger> maybe
[09:35:22] <fuzzie> i mean, it only matters where the original engine maintains lists, i guess? so just recurrent damage, contingency, etc
[09:35:31] <Avenger> yes
[09:36:03] <Avenger> the problem with it is mostly that they erase/rebuild those lists every ai cycle
[09:36:30] <fuzzie> well, let's not do that please :P
[09:36:31] <Avenger> and the double administration of the same information is also lame
[09:36:44] <fuzzie> but, a flag seems like a fairly nice solution
[09:37:12] <Avenger> it still increases complexity, but if that's what we have to do, so be it :)
[09:40:46] <Avenger> lunchtime here
[09:45:36] <lynxlynxlynx> early birds
[09:59:33] <Avenger> yes, it was a bit early
[10:14:52] --> test32894789234u has joined #gemrb
[10:16:40] <-- test32894789234u has left IRC (Read error: Connection reset by peer)
[10:17:21] --> test32894789234u has joined #gemrb
[11:03:30] <CIA-40> GemRB: 03lynxlupodian * rb4426eb27faa 10gemrb/gemrb/core/SaveGameIterator.cpp: CanSave: display the relevant error message when saving isn't allowed
[11:03:42] <CIA-40> GemRB: 03lynxlupodian * r80982ab204ef 10gemrb/gemrb/ (7 files in 7 dirs): added strref for erroring out on saving while in stores
[11:58:10] <-- Avenger has left IRC (Quit: bye!)
[12:18:00] <-- lynxlynxlynx has left IRC (*.net *.split)
[12:18:00] <-- Drakkar has left IRC (*.net *.split)
[12:19:12] --> lynxlynxlynx has joined #gemrb
[12:19:12] --> Drakkar has joined #gemrb
[12:46:47] <lynxlynxlynx> doh
[12:47:00] <lynxlynxlynx> the fatespirit not working has nothing to do with range
[12:47:14] <lynxlynxlynx> we just don't set the walkedto trigger anywhere
[12:51:00] <fuzzie> because we don't implement the walktotrigger action
[12:51:32] <fuzzie> TriggerWalkTo, even
[12:52:00] <fuzzie> which is also meant to deal with all the other fiddly stuff when you click triggers
[12:52:14] <lynxlynxlynx> currently it's set to movetoobject
[12:55:31] <fuzzie> the idea is that it's meant to try and get as close as possible to the relevant point, then set the walkedto trigger
[12:55:55] <lynxlynxlynx> how about making movetoobject core return a bool (when reached/close) and then use that to set the trigger
[12:55:58] <fuzzie> while movetoobject is meant to actually move to the object
[13:02:32] <fuzzie> so i don't know, you'd ahve to pass a flag anyway
[13:10:34] <lynxlynxlynx> it would be doable without that, if it still has to come close enough (closer than max operating distance)
[13:11:31] <fuzzie> but it has to approach a different point
[13:12:31] <lynxlynxlynx> how come? from the looks of it, we do the right thing now
[13:12:57] <fuzzie> you have to walk to UsePoint if TRAP_USEPOINT is set
[13:13:03] <fuzzie> MoveToObject just walks to Pos
[13:13:51] <-- duckpunch has left IRC (Quit: leaving)
[13:13:51] <fuzzie> right now, GameControl.cpp:1799 just hacks the target which ends up passed to MoveToPoint
[13:14:36] --> duckpunch has joined #gemrb
[13:35:42] <lynxlynxlynx> so we should be using triggerwalkto instead of movetopoint in GameControl::CreateMovement for regions?
[13:36:52] <fuzzie> i think that GameControl.cpp:1800 should be making a triggerwalkto action and returning true (true == handled, stop now)
[13:37:00] <fuzzie> but not sure
[13:38:04] <lynxlynxlynx> ok, i'll try that
[13:40:25] --> Avenger has joined #gemrb
[13:40:25] --- ChanServ gives channel operator status to Avenger
[13:41:48] <Avenger> haha, i played Daggerdale for about 10 minutes, and immediately thought: BioWare is still doing the best rpg's though they work hard to loose that feat. The best copyprotection for a game is to make it awfully terribly sucking.
[13:42:23] <Avenger> bioware still has 2-3 years till they reach this level of suckage
[13:51:16] <-- duckpunch has left IRC (Quit: leaving)
[13:51:57] --> duckpunch has joined #gemrb
[13:57:59] <-- Avenger has left IRC (Quit: ChatZilla 0.9.87 [Firefox 5.0/20110615151330])
[15:08:58] --> brad_a has joined #gemrb
[15:31:53] <-- duckpunch has left IRC (Read error: Connection reset by peer)
[15:37:53] --> duckpunch has joined #gemrb
[15:47:46] <-- dhewg has left IRC (Remote host closed the connection)
[16:04:48] --> dhewg has joined #gemrb
[16:13:00] <-- dhewg has left IRC (Remote host closed the connection)
[17:00:43] <lynxlynxlynx> it works
[17:01:05] <lynxlynxlynx> it triggers as soon as the actor comes within range
[17:01:33] <lynxlynxlynx> should probably try to get there first
[17:13:06] <lynxlynxlynx> http://pastebin.com/B0rUMbLN <-- this
[18:33:04] <lynxlynxlynx> any feedback fuzzie?
[18:33:44] <fuzzie> oh, sorry!
[18:34:00] <fuzzie> it looks sane to me
[18:34:06] <fuzzie> thought i'd already said, but clearly not
[18:38:07] <lynxlynxlynx> cool
[18:41:48] <lynxlynxlynx> what i'm not sure about is whether this trigger should be set only for TRAP_USEPOINT regions
[18:42:07] <fuzzie> um
[18:42:21] <lynxlynxlynx> HandleActiveRegion still checks it
[18:42:56] <fuzzie> TriggerWalkTo is run when flag 0x400 is set
[18:43:29] <lynxlynxlynx> ok
[18:43:47] <fuzzie> so i guess only for TRAP_USEPOINT
[18:45:31] <fuzzie> the relevant code for traps does: trig_clicked, if (no target mode) { if (strref) showText; if (TRAP_USEPOINT) { GroupSetMoveToPoint(altX, altY); add action TriggerWalkTo } }
[18:45:50] <CIA-40> GemRB: 03lynxlupodian * r52b8930daf03 10gemrb/gemrb/core/ (5 files in 2 dirs):
[18:45:50] <CIA-40> GemRB: implemented the TriggerWalkTo action
[18:45:50] <CIA-40> GemRB: fixes tob's fate spirit inaccessibility
[18:46:11] <fuzzie> (the group walk thing sets the target indicators, which we handle differently)
[18:55:57] <-- test32894789234u has left #gemrb
[19:14:10] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[19:34:28] <-- Kiranos has left IRC (Ping timeout: 252 seconds)
[19:34:33] --> Kiranos has joined #gemrb
[19:38:32] <-- harijan2 has left IRC (Ping timeout: 246 seconds)
[19:38:52] --> harijan2 has joined #gemrb
[21:01:44] --> mozvip has joined #gemrb
[21:01:58] <mozvip> hello
[21:30:59] <-- duckpunch has left IRC (Read error: Connection reset by peer)
[21:32:10] --> duckpunch has joined #gemrb
[21:32:25] <-- mozvip has left IRC (Quit: Page closed)
[22:48:07] --> PixelScum has joined #gemrb
[22:50:36] <-- Drakkar has left IRC (Ping timeout: 252 seconds)
[23:50:44] <-- brad_a has left IRC (Quit: brad_a)