[00:17:31] <-- joneirik has left IRC (Ping timeout: 245 seconds)
[00:26:39] --> joneirik has joined #gemrb
[00:31:53] --> joneirikb has joined #gemrb
[00:31:53] <-- joneirik has left IRC (Read error: Connection reset by peer)
[00:34:23] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[00:38:35] <-- rocket_hamster has left IRC (Ping timeout: 255 seconds)
[00:38:35] <-- joneirikb has left IRC (Read error: Connection reset by peer)
[00:38:59] --> joneirik has joined #gemrb
[00:54:11] <-- joneirik has left IRC (Remote host closed the connection)
[01:13:41] <-- edheldil_ has left IRC (Read error: Operation timed out)
[01:14:43] --> rocket_hamster has joined #gemrb
[01:39:13] <-- traveler has left IRC (Ping timeout: 245 seconds)
[03:15:48] <-- |Cable| has left IRC (Ping timeout: 264 seconds)
[03:26:09] <-- rocket_hamster has left IRC (Quit: BuhBye!)
[03:28:36] --> |Cable| has joined #gemrb
[04:12:47] --- ermo is now known as ermo^
[06:12:38] <-- WingedHussar has left IRC (Ping timeout: 245 seconds)
[06:13:45] --> WingedHussar has joined #gemrb
[07:41:08] --> Avenger has joined #gemrb
[07:43:48] <Avenger> lynxlynxlynx: GameScript::GlobalTimerExpired always returns 0 ? I know that an unset timer is not expired normally. This is why people use !GlobalTimerNotExpired - hope this helps.
[07:44:44] <Avenger> if in iwd GlobalTimerExpired = !GlobalTimerNotExpired, then we might need a new gameflag
[07:45:53] <-- Avenger has left IRC (Client Quit)
[08:03:51] --> edheldil has joined #gemrb
[08:03:52] --- ChanServ gives channel operator status to edheldil
[10:03:52] --> traveler has joined #gemrb
[10:11:21] --> lynxlynxlynx has joined #gemrb
[10:11:22] <-- lynxlynxlynx has left IRC (Changing host)
[10:11:22] --> lynxlynxlynx has joined #gemrb
[10:11:22] --- ChanServ gives channel operator status to lynxlynxlynx
[10:19:26] --> rocket_hamster has joined #gemrb
[11:35:47] <-- rocket_hamster has left IRC (Quit: BuhBye!)
[12:51:39] --> kida has joined #gemrb
[12:57:07] <-- traveler has left IRC (Ping timeout: 245 seconds)
[14:00:51] --> traveler_ has joined #gemrb
[14:09:13] <-- traveler_ has left IRC (Ping timeout: 245 seconds)
[14:22:02] --> traveler_ has joined #gemrb
[15:03:28] <Seniorita> [commit] Jaka Kranjc: implemented the unhide action http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=437f117d4ae1eee112672df9537614e2abde9d77
[15:28:48] <-- traveler_ has left IRC (Ping timeout: 245 seconds)
[16:21:42] --> brada has joined #gemrb
[16:34:07] <-- brada has left IRC (Quit: brada)
[16:40:02] --> brada has joined #gemrb
[17:19:48] --> traveler_ has joined #gemrb
[17:32:33] <-- traveler_ has left IRC (Ping timeout: 245 seconds)
[17:39:10] <Seniorita> [bug] 3603301 - BG2: gesen bow damage extremely high (usually 193) http://sourceforge.net/tracker/?func=detail&atid=110122&aid=3603301&group_id=10122
[17:51:56] --> mikol79 has joined #gemrb
[17:52:50] <-- mikol79 has left #gemrb
[17:55:04] --> mikol79 has joined #gemrb
[17:55:31] <mikol79> I also seem to be getting too many critical hits in BG2
[17:59:37] <mikol79> With Minsc (gauntlets of weapon skill) and Harbinger +3 (or any two handed sword) I seem to get a critical every other time
[18:00:59] <mikol79> The same with Keldorn too, who has Carsomyr +5 (an awesome sword to be sure), and gets a critical nearly every time
[18:02:23] <mikol79> But this only seems to happen when two handed swords are equipped- perhaps that's where the problem lies?
[18:07:58] <mikol79> I'm using the most recent git of course (as I always note on my reports), and overall gemrb is in great shape- thanks everyone.
[18:08:24] <-- mikol79 has left #gemrb
[18:24:11] <-- brada has left IRC (Ping timeout: 245 seconds)
[19:23:14] --> brada has joined #gemrb
[19:26:40] --> Yoshimo has joined #gemrb
[19:30:16] <brada> ^ probably all related to the luck bug?
[19:30:51] <-- Yoshimo has left IRC (Client Quit)
[19:31:59] <lynxlynxlynx> gesen maybe not
[19:32:14] <lynxlynxlynx> i think someone already mentioned it was problematic
[19:32:28] <lynxlynxlynx> but it's a very special bow, since it has its own ammo
[19:35:19] --> mikol79 has joined #gemrb
[19:35:51] <lynxlynxlynx> oj
[19:36:08] <lynxlynxlynx> try resting, then see if you still get so many criticals
[19:36:14] --- ermo^ is now known as ermo
[19:36:42] <mikol79> It seems to happen particularly with two handed swords
[19:37:35] <ermo> I'm following the development of BG:EE and in particular, the ShadowKeeper compatibility thread. Someone is currently hacking on SK to bring it up to date (unicode, move to something more modern than MFC). And then it struck me:
[19:37:49] <ermo> Why not have a python tool instead?
[19:38:04] <lynxlynxlynx> pyqt :)
[19:38:10] <ermo> The code is non compiled and it would make sense to distribute it with GemRB
[19:38:34] <lynxlynxlynx> ie_shell is in our project and can do some nice stuff
[19:39:11] <ermo> ie_shell, you say?
[19:39:12] <brada> unfortunately lack of gui will prevent its use by most
[19:39:41] <ermo> yeah, I'm thinking that a SK-ish GUI would be a nice thing
[19:39:49] <lynxlynxlynx> i've never used sk, so i don't know what all it is capable off (except for changing saves)
[19:40:25] <lynxlynxlynx> or just port dltcep, seems a waste to duplicate effort
[19:40:27] <ermo> but I'm encouraged by the fact that something like ie_shell exists, since it implies that a library for reading and writing ie data exists?
[19:40:55] <brada> sure libgemrb_core ;)
[19:41:12] <lynxlynxlynx> they're binary formats, so there's no magic, it's just about knowing the offsets
[19:41:22] <lynxlynxlynx> (and sizes)
[19:42:35] <ermo> I see.
[19:42:46] <brada> i guess all the data importers are plugins so ignore what i said
[19:42:54] <ermo> Even better.
[19:42:58] <brada> but the source is there so....
[19:43:47] <lynxlynxlynx> i remember a french editor
[19:44:02] <lynxlynxlynx> it was done purely with iescript ingame
[19:44:19] <brada> heh
[19:45:47] <lynxlynxlynx> let's see this gesen masterpiece
[19:47:26] <lynxlynxlynx> ahaha
[19:48:28] <brada> sounds like a fix is imminent :D
[19:49:34] <lynxlynxlynx> not really, i found i actually have a save with it from when testing weapon abilities
[19:49:44] <lynxlynxlynx> but now the pc pretty much dies on load :)
[19:50:28] <lynxlynxlynx> probably due to my local hacks
[19:50:59] <lynxlynxlynx> fx_death is applied and that's likely from the main game script - the bhaal timer
[19:51:23] <lynxlynxlynx> let's see
[19:51:47] * tomprince just realised he can see when commits happen to gemrb by watching the load average spike
[19:52:00] <lynxlynxlynx> yep, that was it
[19:52:20] <lynxlynxlynx> definitely looks like another game flag is in order, since it did fix that silly mouth door
[19:54:34] <lynxlynxlynx> gesen seems to work fine here
[19:55:02] <lynxlynxlynx> i get a bit more piercing damage than the description says, but could easily be a data bugie
[19:55:46] <lynxlynxlynx> the funnier thing is that it looks like throwing javelins
[19:56:19] <mikol79> How much damage did it do?
[19:56:39] <ermo> ooh, ie_shell looks like just the ticket
[19:56:46] <lynxlynxlynx> 1d4 piercing and 1d8 electrical
[19:58:04] <mikol79> Did you try it with my savegame (provided with the bugreport)?
[19:58:46] <ermo> by the way, I recently assembled a conservative/minimal-ish BGT BwP install. When playing, I noticed that my on screen animated character kept switching his weapon between his right and left hand. Is this a known issue/feature for IE games?
[19:59:02] <ermo> (no mega-mods installed -- just BGT and a few tweaks)
[19:59:16] --> fizzle has joined #gemrb
[20:00:02] <ermo> Is this because the animation files are mirrored?
[20:00:33] <ermo> (and yes, I accept that this is not a BGT/BwP/1pp support forum)
[20:01:49] <lynxlynxlynx> very likely, yes
[20:01:51] <lynxlynxlynx> mikol79: no
[20:01:56] <lynxlynxlynx> do try sleeping
[20:02:13] <mikol79> I'll experiment and report back
[20:03:48] <lynxlynxlynx> with a fresh master fighter also no problems with 2handlers
[20:04:18] <lynxlynxlynx> with harbringer even
[20:04:36] <lynxlynxlynx> also got lucky so i proved that both the ogre petrification and fireballing works
[20:11:53] <mikol79> after sleeping, then attacking with the party, the number of criticals are still too high (for Minsc and Keldorn) and the gesen bow also does too much damage. It's very strange.
[20:14:33] <lynxlynxlynx> what kind of install is this?
[20:16:07] <mikol79> installed from cd (via wine), official patches applied, gibberlings fixpack and unfinished business applied
[20:21:06] <lynxlynxlynx> nothing spectacular
[20:23:45] <mikol79> There's nothing unusual in the install-no mods apart from unfinished business-everything checks out
[20:27:53] --> cj_schnell has joined #gemrb
[20:30:55] --> AndChat|339824 has joined #gemrb
[20:30:55] <-- cj_schnell has left IRC (Read error: Connection reset by peer)
[20:41:53] <-- tomprince has left IRC (Ping timeout: 255 seconds)
[20:41:56] <-- gembot has left IRC (Ping timeout: 248 seconds)
[20:50:26] <-- AndChat|339824 has left IRC (Read error: Connection reset by peer)
[20:50:40] --> cj_schnell has joined #gemrb
[20:51:47] <-- mikol79 has left #gemrb
[21:03:04] --> AndChat|339824 has joined #gemrb
[21:03:04] <-- cj_schnell has left IRC (Read error: Connection reset by peer)
[21:12:50] <Seniorita> [commit] Jaka Kranjc: added a minimal fix for totl's ar9717 talking door http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=178c8450783773980cd37e07462101b9ad499f92
[21:24:09] <Seniorita> [commit] Jens Granseuer: Button: when calculating transparency consider the offset used for drawing http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=cf882acb953d60f04775dbbf1138811dacd1156a
[21:24:10] <Seniorita> [commit] Jens Granseuer: bg1: fix some issues with the spell action buttons http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=94c935f36caf90de773a28c8bb30037331117180
[21:27:36] <lynxlynxlynx> what does this transparency fix fix?
[21:31:36] <fizzle> in the spell action bar
[21:31:45] <fizzle> if you have more than 12 spells
[21:31:54] <fizzle> you get those left and right buttons
[21:32:09] <fizzle> but they are only half the normal button width
[21:32:29] <fizzle> so clicking where you expect them to activate didn't work
[21:33:47] <lynxlynxlynx> good catch, never noticed it
[21:52:01] <Seniorita> [commit] Jens Granseuer: bg1: fix bogus tooltips for left/right buttons http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=9f46e34bffb5480f6895df6c2885b8683cd13d42
[21:52:12] <fizzle> I'd like to tackle random encounters next
[21:52:40] <fizzle> any info on how they differ from other games in bg1 would help me not step on anyone's toes
[21:54:37] --> rocket_hamster has joined #gemrb
[22:23:15] <fuzzie> what do you mean by random encounters?
[22:23:29] <fuzzie> i mean, what do you want to fix in particular?
[22:28:50] <lynxlynxlynx> there's a save in the todo section for bg1
[22:29:13] <lynxlynxlynx> traveler said it can be used to reproduce the repeated random encounters (from travelling)
[22:29:40] <lynxlynxlynx> if you meant spawn point stuff, that's different, so nmi
[22:30:36] <fuzzie> yes, that's why I ask
[22:30:50] <fuzzie> bg1 random encounters are *meant* to repeat, right?
[22:31:21] <fuzzie> so fixing them is somewhat tricky
[22:31:26] <lynxlynxlynx> no idea
[22:31:31] <fuzzie> but it's not bg1-specific afaik
[22:31:41] <fuzzie> while the spawn points are bg1-specific and not at all fun :)
[22:32:01] <lynxlynxlynx> in both bg1 and bg2 we sometime put people in the same r-e area
[22:32:19] <lynxlynxlynx> just that in bg2 that shouldn't happen, while in bg1 the baddies should probably indeed respawn
[22:32:39] <lynxlynxlynx> or maybe they are the same and there just many r-e areas with the same layout
[22:33:32] <lynxlynxlynx> unrelated, i was revisiting the rakshasa bug talk of yesterday
[22:33:57] <fuzzie> in both cases, the area shouldn't be saved
[22:34:09] <fuzzie> so there's no need to respawn baddies etc
[22:34:41] <lynxlynxlynx> one idea you mentioned was that corpses could call endcutscenemode. Would that be an invasive change?
[22:35:00] <lynxlynxlynx> i was also thinking of just changing the script and putting it in our override
[22:36:05] <fuzzie> i have no idea :/ but it seems utterly harmless to allow corpses to call endcutscenemode, if that works
[22:37:07] <fizzle> well, currently the encounter areas *are* saved
[22:37:29] <fizzle> so when you've fought in one area once, you'll only meet corpses there for the rest of the game
[22:37:52] <fizzle> so they don't repeat
[22:37:56] <fizzle> that's the problem
[22:38:10] <fizzle> and the encounter areas don't show up on the world map properly
[22:38:34] <lynxlynxlynx> fuzzie: but how to detect them? doesn't IF_CLEANUP mean their scripts stop running?
[22:39:03] <lynxlynxlynx> fizzle: i think it just computed an average between the coordinate pairs
[22:39:14] <fuzzie> yes, but we don't save enough information right now
[22:42:07] <fuzzie> 20:49 <fuzzie> if it's an ambush area, presumably we just need to store the original source/target areas for the worl
[22:42:11] <fuzzie> dmap
[22:42:11] <fuzzie> ^- 2.5 years ago :/
[22:43:21] <fizzle> the code seems to have two different kinds of random encounters
[22:43:30] <fizzle> is that bg1 vs. bg2?
[22:43:49] <fuzzie> not as far as I remember
[22:43:52] <fuzzie> what's the second kind?
[22:44:40] <fuzzie> oh, unless you mean bounty encounter vs normal encounters, but they're basically equivalent
[22:44:52] <fizzle> er, maybe?
[22:45:04] <fizzle> there's Game::RandomEncounter
[22:45:12] <fizzle> and "regular" encounter
[22:45:13] <fuzzie> yes, so that's the reputation-based check which is bg1-specific
[22:45:17] <fuzzie> but they're the same encounters
[22:45:41] <lynxlynxlynx> bg2 also has reputation based random encounters btw
[22:45:50] <fuzzie> oh well maybe bg2 also :-p
[22:45:50] <fizzle> and the regular ones happen in all games?
[22:46:00] <lynxlynxlynx> not completely sure if they're always in a special area though
[22:46:12] <fuzzie> but the only difference is the choice of area.
[22:46:17] <lynxlynxlynx> but you get jumped by cowled wizards and/or paladins if you don't behave
[22:46:31] <fuzzie> if RandomEncounter succeeds then you get the rep-based area resref, otherwise it picks from the standarde list.
[22:46:34] <lynxlynxlynx> fizzle: iwds and pst have none
[22:47:01] <fizzle> okay, but the areas should never be saved for either game
[22:47:31] <fizzle> and I presume there's no flag or ssomething in the area data to denote an ambush area?
[22:48:11] <brada> i think there is
[22:48:22] <brada> bit 3: (0) Sequential ambient selection / (1) Random ambient selection
[22:48:34] <lynxlynxlynx> ambient == music?
[22:48:45] <fizzle> that's what I thought...
[22:48:47] <brada> heh stayed up too late doing homework
[22:48:53] <brada> cant read
[22:49:22] <lynxlynxlynx> if nothing else, there's a heuristic available
[22:49:28] <lynxlynxlynx> you can't save or rest in these areas
[22:49:37] <lynxlynxlynx> there are flags for both
[22:49:42] <fuzzie> yes, that was avenger's original suggestion
[22:49:52] <lynxlynxlynx> cool :)
[22:49:55] <fuzzie> but isn't the no-save flag also set in other areas? :P
[22:50:02] <fizzle> we can just set a flag from the outside though
[22:50:03] <brada> we dont know how the original worked?
[22:50:13] <lynxlynxlynx> sure, but in any with no-rest?
[22:50:14] <fizzle> the code does know when it's an ambush
[22:50:22] <brada> there are "unknown" fields still right?
[22:50:26] <fizzle> because that's a heuristic
[22:50:32] <fizzle> and likely to fail sooner or later
[22:51:01] <fuzzie> i'm pretty sure you just save the source+target area resrefs when you got ambushed
[22:51:20] <fuzzie> which gives you worldmap info and also tells you you're in an ambush
[22:51:21] <brada> i like how there is a bit for tutorial area
[22:51:41] <fuzzie> (i think original maybe just preserves the current area resref until you actually succeeded in travel, but i forget)
[22:55:03] <brada> you get a message when an ambush happens right?
[22:55:19] <fizzle> yes
[22:57:54] <fuzzie> hardcoded :)
[22:58:00] <brada> naturally
[22:58:05] <fuzzie> i assume you *did* find the code (in GUIScript
[22:58:05] <fuzzie> )
[22:58:09] <brada> what about the unknown at 0x0052
[22:58:11] <fuzzie> i have to sleep though :/
[22:58:41] <fuzzie> but since you can't save in ambush areas it seems easy to solve.
[22:58:52] <fizzle> I'm probably not going to get to do anything before the weekend anyway
[22:58:59] <brada> except i thought there were some other areas where that was true
[22:59:11] <brada> but maybe it doesnt matter if those are treated as ambush areas too
[23:00:10] <lynxlynxlynx> i don't remember any in any of the games
[23:01:03] <lynxlynxlynx> but that's a few dltcep searches away if anyone wants to verify
[23:01:25] <fizzle> a flag would have been easiest but separating the real ambush areas from normal areas is really not an issue
[23:01:51] <fizzle> since the ambush is decided in code anyway
[23:02:07] <brada> sure
[23:02:17] <lynxlynxlynx> maybe the no-save bit is the ambush bit and we just misunderstoof it ;)
[23:02:30] <brada> ha
[23:02:32] <fizzle> heh
[23:02:52] <lynxlynxlynx> if they fully overlap it is plausible
[23:02:57] <fuzzie> possible. might be worth checking which areas have it set with ie_shell or similar
[23:03:00] <fuzzie> but sleeep.
[23:05:07] <fizzle> yeah, me too
[23:05:11] <fizzle> gn
[23:05:25] <-- fizzle has left #gemrb
[23:18:39] --> traveler__ has joined #gemrb
[23:19:16] <-- brada has left IRC (Quit: brada)
[23:25:13] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:25:41] <-- kida has left IRC (Remote host closed the connection)
[23:31:21] <traveler__> this saves are related more to
[23:31:24] --> edheldil_ has joined #gemrb
[23:31:34] <traveler__> a) exploding enemies upon ambush
[23:31:47] <traveler__> b) appearing in wrong place (durlag tower)
[23:32:43] <traveler__> repeated not cleaned up ambush encounters is just regular thing you get all the time e.g. especially often when travelling to gnoll stronghold
[23:33:11] <traveler__> exploding enemies is more of a curiosity
[23:33:26] <traveler__> you cannot replicate it with fresh game, but once it started, it started
[23:33:53] <traveler__> and low level ambush baddies die *instantly* when entering area
[23:34:22] <traveler__> mind, i don't say *already dead* as in not cleaned up corpses, this is usual thing
[23:34:33] <traveler__> i mean they are dying the moment you enter the area
[23:34:59] <traveler__> *ambush area
[23:36:51] <traveler__> i say exploding, because i'm pretty sure they all got criticals, but we don;t have instachunks to display it...
[23:37:42] <traveler__> i'm also pretty sure i saw something similar in original
[23:47:18] <-- rocket_hamster has left IRC (Quit: BuhBye!)