[00:00:49] <pupnik_> so i can't get to the boardroom (flail head)
[00:17:43] <-- SiENcE has left IRC (Quit: cya @all)
[00:36:18] --> SiENcE has joined #GemRb
[02:16:31] <-- SiENcE has left IRC (Quit: cya @all)
[04:10:48] <raevol> hours later, but hello pupnik_
[04:14:39] <pupnik_> huhu raevol
[06:04:31] --> lynxlynxlynx has joined #GemRb
[06:04:31] --- ChanServ gives channel operator status to lynxlynxlynx
[06:18:03] --> Maighstir has joined #GemRb
[06:38:03] <-- raevol has left IRC (Quit: Leaving.)
[07:32:04] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[09:31:49] <edheldil> "Saving game versus death was unsuccessful, because you rolled too much" ;-)
[09:43:23] --> SiENcE has joined #GemRb
[10:35:06] --> pupnik has joined #GemRb
[10:38:17] <-- SiENcE has left IRC (Quit: cya @all)
[10:38:59] <-- pupnik_ has left IRC (Ping timeout: 276 seconds)
[10:59:59] <pupnik> volume settings re-set on each area switch
[11:24:28] --> lubos has joined #GemRb
[11:24:55] <lubos> Hi all
[11:27:27] <fuzzie> hi
[11:27:28] <edheldil> Hi, lubos
[11:29:26] <pupnik> o/
[11:34:01] <lubos> I'm interesting about packaging for Debian.
[11:34:05] <lubos> I found 2 little problems:
[11:34:12] <lubos> Lintian has problem with man page should be "[\-c config-file]"
[11:34:19] <lubos> file gemrb / plugins / BIKPlayer / common.h missing license
[11:35:07] <edheldil> lubos: are you aware that there were/are two attempts on deb packaging? (for Ubuntu, iirc). Dunno about their success
[11:35:40] <edheldil> what is the first problem
[11:35:42] <edheldil> ?
[11:36:01] <lubos> escaped -
[11:36:24] <fuzzie> the ubuntu packaging seems to not be too serious, shipping broken config, and complaining about it not working at arbitary resolutions
[11:38:17] <fuzzie> and i note the maemo package db finally has 0.6.1, a week or so after our 0.6.2 release :(
[11:39:26] <lubos> edheldil: I used one of them at beggining. I switch to debhelper, quilt 3.0 source format and static build...
[11:39:45] <fuzzie> i guess *all* of the gemrb packages i can see are shipping broken config files.
[11:42:08] <edheldil> minimizing config should help with that ;-)
[11:42:19] <CIA-93> GemRB: 03edheldil * raa0a6463703e 10gemrb/gemrb.6: Escaped dash to keep Lintian happy
[11:42:23] <fuzzie> it doesn't really
[11:42:32] <edheldil> how so?
[11:42:34] <fuzzie> because they just ship configs from years ago, overriding all the defaults
[11:42:44] <edheldil> hehe
[11:42:50] <fuzzie> whatever we do to our sample, they keep shipping broken stuff of their own :(
[11:43:06] <fuzzie> even though it defaults to hard-baked paths now, so there's no need for them to fiddle with it!
[11:43:18] <lubos> I dont't install config files in /etc . Better is add it like examples in /usr/share/doc/gemrb/examples/
[11:43:26] <fuzzie> lubos: yes, that is good
[11:43:33] <fuzzie> just ship the generated GemRB.cfg.sample and not something random :)
[11:43:42] <edheldil> we could check for some obsoleted option and crash on it, that would teach them :-)
[11:44:30] <fuzzie> the only problem we have left is the CachePath
[11:44:42] <fuzzie> since there's no sane default for that..
[11:44:52] <fuzzie> it is very annoying
[11:44:52] <edheldil> GamePath has none either
[11:45:09] <fuzzie> well, that is essential anyway :)
[11:45:18] <edheldil> CachePath can have ~/.gemrb/cache/bg2, for example
[11:45:19] <fuzzie> someone had a patch for default GameType,GameName,resolution,etc
[11:45:33] <fuzzie> but CachePath can't be in /tmp, can't be in home and can't be in the game dir
[11:45:45] <fuzzie> so we're left with, well, nothing which works for everyone :(
[11:45:46] <edheldil> I would prefer GameType to be autodetected
[11:46:10] <fuzzie> someone had an *almost* finished patch to look up everything from a table with filenames
[11:46:13] <edheldil> why not in home?? You have browser cache there already
[11:46:24] <fuzzie> not in home because many embedded devices have no space in home
[11:46:44] <fuzzie> just enough for config files
[11:47:23] <edheldil> but embedded devices can screw^H^H^H^H^H be configured by their hopefully cluefull developers
[11:47:33] <fuzzie> you'd think that the iPhone would have set the example here, that having enough internal storage is important
[11:47:57] <fuzzie> well, sure, but 'hopefully clueful packagers' are exactly the problem ;p
[11:48:46] <edheldil> then let's crash on some option and meanwhile add more comments to the sample config?
[11:49:08] <fuzzie> well, i guess we should just have a GemRB.cfg.sample.simple or something
[11:49:09] <wjp> some programs require something like a IHaveReadAndUnderstoodTheConfigDocs=1 option in the config file :-)
[11:49:16] <fuzzie> but *after* we add autodetection
[11:49:44] <fuzzie> maybe i should just hunt down the patch in backscroll and finish it. but not now.
[11:50:04] <edheldil> wjp: sure, but those are packages like Asterisk or ratbox, not game :)
[11:50:43] <edheldil> not sure about asterisk, hehe
[11:53:28] <lubos> Current state: http://debian-packages.cernovice.net/gemrb/
[11:56:05] <lubos> plugins/BIKPlayer/common.h came from ffmpeg?
[11:57:10] <fuzzie> it does look like it
[11:59:16] <edheldil> with some Avenger's modifications, right?
[11:59:55] <edheldil> lubos: nice, did not know DH rules now resemble CDBS so much :)
[12:00:12] <fuzzie> yeah, but you'd have to go back to ffmpeg to see what copyright lines to add
[12:00:28] <fuzzie> BIKPlayer.cpp has a few copyright lines, but i guess common.h will be different
[12:05:45] <wjp> ffmpeg's current avutil/common.h is LGPL 2.1
[12:06:06] <fuzzie> i mean, the copyright names
[12:06:14] <fuzzie> i think we just promote the rest to GPL 2, as allowed
[12:06:32] <wjp> * copyright (c) 2006 Michael Niedermayer <firstname.lastname@example.org>
[12:06:32] <wjp> *
[12:06:32] <wjp> * This file is part of FFmpeg.
[12:09:36] <pupnik> <@edheldil> CachePath can have ~/.gemrb/cache/bg2 << probably the most proper place. people who want it on another device can symlink themselves
[12:10:19] <fuzzie> the trouble is that the cache can get pretty big, and the directory is hidden
[12:11:05] <pupnik> so does my browser cache
[12:11:25] <edheldil> still, /home partition is often the biggest one
[12:11:29] <fuzzie> this is true :-)
[12:11:53] <pupnik> (maemo devices need it on a bigger partition)
[12:12:05] <edheldil> browser cache is limited in size, unlike gemrb one, though
[12:12:08] <pupnik> that 0.6.1 is unfortunate
[12:12:46] <edheldil> well, debian will probably ship 0.6.2 or whatever for years :-P
[12:13:11] <lubos> Good place for cache is ~/.cache/gemrb/bg2 (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html)
[12:13:30] <pupnik> oh
[12:14:52] <edheldil> does look even more obscure than ~/.gemrb, though
[12:15:07] <edheldil> it has a distinctly gnomish look *to me*
[12:18:09] <lubos> Yes, but has benefits. You can remove whole dir. Change location of cache dir with env. variable.
[12:18:29] <lubos> One place for cache, config...
[12:20:59] <pupnik> yes
[12:34:22] <lubos> edheldil: Debian is frozen now (no new packages will not be added to stable branch). Next problem is, that I'm not Debian developer, so I need sponsor to upload new package.
[12:36:22] <lynxlynxlynx> is that a problem?
[12:38:25] <lubos> Yes, it is. :P
[12:40:29] <lynxlynxlynx> why? are they so strick or is your work poor? :P
[12:40:40] <edheldil> it's a policy
[12:44:10] <lynxlynxlynx> and?
[12:44:43] <lubos> Debian is a bit rigid. They have strict rules. Especialy for copyright (file). GemRB belong probably to "contrib/games" section(depend on non-free content).
[12:46:09] <DrMcCoy> ScummVM at least is in the main games section
[12:46:25] <lubos> Min. 2 games are free
[12:46:54] <DrMcCoy> True :P
[12:47:54] <lubos> I'm not sure about contrib section.
[12:56:30] <lynxlynxlynx> that one copyright offender can be fixed
[13:03:49] <edheldil> we should probably update the boilerplates anyway. E.g. pester Avenger to attribute Variables.h to GemRB project, update years ...
[13:04:04] <edheldil> FSF address if it has not been done already ...
[13:05:00] <lynxlynxlynx> the addy was fixed
[13:05:24] <lynxlynxlynx> are you sure the years need to be updated?
[13:09:08] --> SiENcE has joined #GemRb
[13:12:43] <edheldil> no idea what they are good for
[13:15:56] <edheldil> so perhaps not. but the copyright attribution should. E.g. gemrb/core/LRUCache.cpp says just "Copyright (C) 2007"
[13:16:04] <lubos> FSF should provide batch of lawyers for this purposes:)
[13:16:25] <edheldil> for updating projects' boilerplates? :-)))
[13:16:49] <edheldil> btw: admin/check_copyright.pl
[13:43:38] <CIA-93> GemRB: 03lynxlupodian * rcdb9fe69ae6c 10gemrb/gemrb/plugins/GUIScript/CMakeLists.txt:
[13:43:38] <CIA-93> GemRB: cmake: explicitly link GUIScript to dl
[13:43:38] <CIA-93> GemRB: TODO: think about switching to pkg-config as the main way of getting info
[13:43:38] <CIA-93> GemRB: 03lynxlupodian * r758846c960d4 10gemrb/gemrb/core/Scriptable/Actor.cpp: fixed gcc warning
[13:54:01] <edheldil> lynxlynxlynx: pkg-config is not widely enough used, according to fuzzie. I have already proposed that :)
[13:54:23] <lynxlynxlynx> i didn't mean it as a replacement
[13:54:53] <lynxlynxlynx> it would be used when available
[14:01:28] <CIA-93> GemRB: 03lynxlupodian * rf16dbe95331b 10gemrb/NEWS: NEWS bump
[15:14:53] <pupnik> lynxlynxlynx: is there a pack or fix i should be playing bg2 with?
[15:15:07] <pupnik> SOA atm, no ToB
[15:24:50] <lynxlynxlynx> the usual stuff
[15:25:38] <lynxlynxlynx> latest patch at minimum, g3 fixpack for more
[15:33:49] <-- lubos has left IRC (Quit: Leaving.)
[15:34:41] <fuzzie> does the latest fixpack deal with torgal properly?
[15:35:40] <fuzzie> oh, i guess it adds torgal scripts nowadays, so it must do
[15:35:57] <pupnik> ok ty lynxlynxlynx
[15:36:31] <pupnik> guess i'll boot win to install it with the patch just to be sure of what i've got here
[15:43:47] <CIA-93> GemRB: 03lynxlupodian * rd3d7b7bc8332 10gemrb/gemrb/core/Scriptable/Actor.cpp: removed commented-out Actor::MatchesAlignmentMask, a poor version of ID_Alignment
[16:05:37] --> Maighstir has joined #GemRb
[16:46:14] --> spike411 has joined #GemRb
[17:19:48] <lynxlynxlynx> fuzzie: turns out this abazigal death cutscenery is a good proof that bg2 indeed doesn't run area scripts during cutscenes
[17:20:24] <lynxlynxlynx> in this case each starts a cutscene, but unless the area one is delayed, the order is wrong and only one gets played
[17:20:38] <fuzzie> ok. neat. :)
[17:21:46] <lynxlynxlynx> i'll go add the game flag
[17:22:13] <lynxlynxlynx> unfortunately there is still the problem of infinite dragons :)
[17:23:30] <fuzzie> i suggest making bg1 the special case
[17:23:46] <fuzzie> GF_AREASCRIPTS_CUTSCENE or something
[17:24:16] <lynxlynxlynx> i was about to leave it as it was for everything but bg2
[17:24:47] <fuzzie> well, it is very weird behaviour, and devSin implies that bg1 is the broken one and iwd2 does it right
[17:24:58] <fuzzie> but i have no hard facts :)
[17:25:20] <lynxlynxlynx> considering how well iwd1 behaved, the setting seemed fine then
[17:25:41] <lynxlynxlynx> iwd doesn't have much cutscenes though, so it can't matter much
[17:25:55] <fuzzie> but i just mean that flagging the weird behaviour seems best, even if you enable it for everything except bg2
[17:26:03] <fuzzie> but sorry, i don't code it, i shouldn't interfere :)
[17:27:08] <lynxlynxlynx> we have only one case for each side, so we can't really tell which one is the wierd one yet
[17:52:59] <lynxlynxlynx> bah, now i can't reproduce my success
[17:53:38] <lynxlynxlynx> it was a problem in a lot of other places, so i'll commit it anyway
[17:55:04] <CIA-93> GemRB: 03lynxlupodian * r6e92a8ab9a38 10gemrb/gemrb/ (10 files in 10 dirs):
[17:55:04] <CIA-93> GemRB: don't run area scripts during cutscenes in bg2/iwd2 (only bg1/bg2 were tested)
[17:55:04] <CIA-93> GemRB: toggled by CutsceneAreascripts/GF_CUTSCENE_AREASCRIPTS
[18:05:38] --> raevol has joined #GemRb
[19:04:03] <CIA-93> GemRB: 03lynxlupodian * r85b04de39c0e 10gemrb/gemrb/core/Interface.cpp:
[19:04:03] <CIA-93> GemRB: Interface::SummonCreature: bail out also if the xp is 0
[19:04:03] <CIA-93> GemRB: undecuples invisible stalker summoning
[19:20:31] --> Avenger has joined #GemRb
[19:20:31] --- ChanServ gives channel operator status to Avenger
[19:20:42] <Avenger> hello
[19:22:00] <lynxlynxlynx> oj
[19:23:28] <-- SiENcE has left IRC (Ping timeout: 245 seconds)
[19:24:23] --> SiENcE has joined #GemRb
[19:40:45] <Avenger> fuzzie, now i know why there are copies of each 'LastTarget'
[19:41:01] <Avenger> LastShouter/LastAttacker/etc
[19:41:11] <fuzzie> aren't they set globally in many cases?
[19:41:33] <fuzzie> but all i know are people's guesses, do tell!
[19:41:37] <Avenger> it works like this: every ai cycle, it evaluates all the triggers, and deletes the whole queue
[19:41:44] <Avenger> but...
[19:41:51] <fuzzie> sure, but those aren't triggers, they're objects
[19:41:56] <fuzzie> different things
[19:42:00] <Avenger> no, this is the trigger queue
[19:42:16] <Avenger> it always deletes all triggers in every cycle, but...
[19:42:18] <fuzzie> not the object fields set by the trigger queue?
[19:42:22] <Avenger> it recreates some triggers
[19:42:29] <Avenger> based on the copies of the objects!
[19:42:36] <fuzzie> huh
[19:42:37] <fuzzie> interesting
[19:42:57] <Avenger> so, after an ai cycle, only one AttackedBy trigger remains, the last
[19:43:06] <Avenger> but in an ai cycle, you get all
[19:43:11] <fuzzie> but AttackedBy doesn't return true forever
[19:43:12] <Avenger> weird, uh?
[19:43:36] <Avenger> well, i don't see any timer attached to the last attacker object (or its copy)
[19:43:38] <fuzzie> but LastAttacker *is* valid forever
[19:44:15] <fuzzie> so maybe the newly-created trigger has some special 'not real' flag?
[19:45:02] <Avenger> well, it erases the trigger queue every ai cycle, and recreates the still living ones from the scratch, without any time info
[19:45:17] <Avenger> i don't really see how could it discard one after some time
[19:45:21] <fuzzie> it doesn't
[19:45:35] <fuzzie> you get one ai cycle, then the triggers are no longer true
[19:45:43] <fuzzie> but the objects still work fine
[19:46:06] <fuzzie> so this is why i ask, are the recreated triggers special in some way, so they don't actually match for scripting?
[19:46:10] <Avenger> this 0x84 function does really everything :)
[19:47:32] <Avenger> at least i can tell, it evaluates the action queue in its end
[19:48:00] <Avenger> triggers, modal actions, actions based on state are evaluated before that
[19:48:14] <fuzzie> cool
[19:49:00] <Avenger> i think if you understand 0x84 (and everything called by it), you understand almost all scripting :)
[19:49:29] <Avenger> it is at least getting shape, most of the interesting functions were hidden in the call chain
[19:50:20] <Avenger> for example, the trigger evaluation was hidden in a routine doing this: (call evaluate all triggers; delete all triggers)
[19:56:18] <Avenger> there is an awful lot of other code which i don't yet understand
[19:58:08] <fuzzie> isn't there always :)
[20:12:10] <Avenger> the encumbrance stat is not the total weight carried :( it is just 0,1,2 based on how much encumbrance is there (0-normal, 1-slowed, 2-can't move)
[20:12:41] <Avenger> this silly crap recalculates item weight every ai cycle
[20:17:43] <fuzzie> well, our stuff forgets to recalculate it :)
[20:18:03] <fuzzie> i must remember to remove the recalculation in the ctrl-m code, which makes it difficult to spot that
[20:19:12] <Avenger> cool now i see what exactly triggers displaying the 'spturni2' overlay
[20:19:30] <Avenger> this is the glowing disc under feet, for some bounce effects
[20:20:54] <Avenger> well, anyway, i think we should move the total weight from the stat into the inventory
[20:21:04] <Avenger> so the stat would do what it is doing in the original
[20:21:50] <Avenger> the inventory could maintain a 'weight changed' flag, and recalculate the weight if it is marked and weight is requested
[20:22:11] <Avenger> then we need some guiscript interface too
[20:22:30] <Avenger> hopefully we got some existing function which can have a new option
[20:34:07] <Avenger> whoa, finally i found their version of 'updateffects'
[20:34:29] <Avenger> hidden in a long long call chain :)
[20:34:36] <Avenger> i knew it should be here somewhere
[20:37:29] <Avenger> happiest day in my life :) it does almost the same i expected
[20:40:45] <spike411> How are you RE'ing these functions?
[20:41:33] <Avenger> loaded the binary into ida pro, then reading the disassembly. ida pro allows you to mark functions, define structures, etc
[20:42:00] <spike411> Aaah, IDA Pro. I guess that's quite popular… tool. In various areas. :)
[20:42:58] <Avenger> it is a wonderful tool, it crashed on me only once :) sometimes messes up large structures by mistakenly assuming that the structure is its first sub field, otherwise it is a really useful tool
[20:43:24] <Avenger> i wouldn't have gotten this far in understanding the IE without it
[20:43:51] <Avenger> amazingly, a lot of things are exactly the same in it, even some stuff written by balrog
[20:45:56] <Avenger> for a moment, this updateffects stuff scared me, here is a part to execute only the freedom opcode :) that totally gave me the creeps
[20:46:32] <Avenger> but there is also a check before that, so it means: if the actor is removed from the area execute only freedom, otherwise execute all :)
[20:46:37] <Avenger> so i'm all clear
[20:46:53] <fuzzie> we all love IDA Pro
[20:53:36] <Avenger> hmm, some stuff is weird here, in some cases, it just reapplies the whole effect stack
[20:55:17] <Avenger> this could be the 'force update' stuff in effects, based on the return value from any single effect
[20:56:11] <Avenger> i hope we can avoid this
[20:57:55] <Avenger> and now i see where it reapplies the effect stacks (which actually means, recalculating all stats from base + effects)
[21:04:42] <spike411> Anyone tried Cure Light Wounds in IWD2 since the last time I was bugging you? :)
[21:05:47] <spike411> Is there any way to get more output than that? http://paste.jabbim.cz/4851 (I'm running gemrb in gdb too.)
[21:07:20] <fuzzie> i have no idea how this spell protection stuff works
[21:09:00] <fuzzie> but presumably it's being resisted
[21:13:04] <lynxlynxlynx> iwd spells have the first effect with the resistance and if it matches, the rest of the spell effects are dropped
[21:13:56] <lynxlynxlynx> so my money is on that resistspell2 problem and maybe ungracious handling
[21:14:32] <fuzzie> well, the 2da failing doesn't look so good?
[21:14:52] <lynxlynxlynx> spike411: so since you're in gdb, you can start looking there and backwards
[21:15:35] <spike411> lynxlynxlynx: backtrace?
[21:17:12] <lynxlynxlynx> sure
[21:24:57] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[21:26:57] <Avenger> the resistspell should make undead resisting it
[21:27:44] <Avenger> if it isn't working then it is because someone 'fixed' the iwd splprot stuff :)
[21:32:23] <Avenger> admittedly this opcode is buggy :)
[21:33:12] <spike411> Hmm, I put a breakpoint on /Users/spike411/gemrb/gemrb/core/EffectQueue.cpp:177, the execution got paused several times during initialization when I restarted the execution… then when I cast the spell I can see [EffectQueue]: Couldn't assign effect: ResistSpell2 but the execution is not paused?
[21:34:26] <Avenger> change string to Protection:Spell2
[21:34:48] <Avenger> iwdopcodes.cpp line: 2021
[21:35:44] <Avenger> this is just a temporary hack, it should fix the couldn't assign message, but i'm not sure it can fix the spell
[21:36:54] <Avenger> the main problem remains there: check_iwd_targeting thinks this spell should be resisted
[21:37:07] <Avenger> and that is because either lynx or fuzzie fixed it
[21:38:18] <Avenger> changing it to if(!check_iwd_targeting... will fix for this opcode, but i'm not sure it is the right way)
[21:38:41] <Avenger> most likely it needs to be changed in many if not all places
[21:39:01] <fuzzie> is it fixed?
[21:39:23] <fuzzie> is this the one where half the logic returned true and half returned false?
[21:39:28] <Avenger> someone reverted the boolean result of check_iwd_targeting
[21:39:42] <Avenger> now it thinks the target is undead :)
[21:40:04] <fuzzie> i don't think it matters which one it returns, we just changed it to whichever half there were more of, i think
[21:40:56] <Avenger> well, negating the result can help, for this opcode
[21:41:13] <Avenger> it is surely needed to either negate here, or in the core function
[21:42:29] <Avenger> i say, lets negate here, and comment it :)
[21:42:38] <fuzzie> sounds fine
[21:42:46] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716])
[21:43:36] * spike411 is still here and trying hard to understand what's going on, but /me is too slow… >_<
[21:52:51] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[21:53:24] <spike411> Well… Protection:Spell2 really removed the ‘couldn't assign’ message. But negating that check_iwd_targeting did not seem to produce any visible effect.
[21:54:39] <-- SiENcE has left IRC (Quit: cya @all)
[21:56:41] <fuzzie> well, to me, it looks like our iwd2/splprot.2da is basically identical to the iwd one, and this is surely wrong
[22:09:46] <pupnik> sweet cutscenes... :)
[22:21:44] <CIA-93> GemRB: 03avenger_teambg * r8ed4b071721d 10gemrb/gemrb/ (8 files in 8 dirs): possibly fixed cure light wounds in iwd2
[23:01:46] --> nickdaly` has joined #GemRb