#gemrb@irc.freenode.net logs for 19 Nov 2012 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:03:39] <-- kida_laptop has left IRC (Remote host closed the connection)
[00:14:43] <-- Kliff has left IRC (Ping timeout: 246 seconds)
[01:13:39] <-- Canageek has left IRC (Quit: KVIrc 4.0.4 Insomnia The future is here. It's just not widely distributed yet. - William Gibson)
[01:55:57] <-- edheldil has left IRC (Ping timeout: 252 seconds)
[02:19:45] --> edheldil has joined #gemrb
[02:19:46] --- ChanServ gives channel operator status to edheldil
[02:41:42] <-- edheldil has left IRC (Read error: Operation timed out)
[03:16:33] --> Canageek has joined #gemrb
[06:27:34] <-- Canageek has left IRC (Ping timeout: 246 seconds)
[07:35:03] --> Avenger_ has joined #gemrb
[07:36:21] <Avenger_> lynxlynxlynx: when you talk about iwd hack, you meant the fix for the machine of lum? That's in watcher's keep (tob)
[07:37:13] <Avenger_> The funny thing, i found this: http://www.gamebanshee.com/forums/threads/machine-of-lum-bug-broken.119752/
[07:37:44] <Avenger_> so, i think this proves, that the original engine was not working like the scripter expected :D and it was hacked to a fix
[07:38:22] --> edheldil has joined #gemrb
[07:38:23] --- ChanServ gives channel operator status to edheldil
[07:38:38] <-- Avenger_ has left IRC (Client Quit)
[07:53:34] <-- edheldil has left IRC (Ping timeout: 252 seconds)
[08:07:35] <-- duckpunch has left IRC (Remote host closed the connection)
[08:13:04] --> edheldil has joined #gemrb
[08:13:05] --- ChanServ gives channel operator status to edheldil
[08:24:45] --> edheldil_ has joined #gemrb
[08:25:58] --> lynxlynxlynx has joined #gemrb
[08:25:59] <-- lynxlynxlynx has left IRC (Changing host)
[08:25:59] --> lynxlynxlynx has joined #gemrb
[08:25:59] --- ChanServ gives channel operator status to lynxlynxlynx
[10:31:06] <-- edheldil_ has left IRC (Read error: Operation timed out)
[10:45:32] <-- demitar has left IRC (Ping timeout: 252 seconds)
[10:50:25] --> edheldil_ has joined #gemrb
[11:02:40] --> duckpunch has joined #gemrb
[11:06:40] --> demitar has joined #gemrb
[11:15:36] <-- demitar has left IRC (Ping timeout: 252 seconds)
[11:19:58] <-- edheldil_ has left IRC (Ping timeout: 252 seconds)
[11:21:01] --> kida_laptop has joined #gemrb
[11:26:35] <lynxlynxlynx> fuzzie: here?
[11:27:31] <fuzzie> yes
[11:27:50] <lynxlynxlynx> scripts/bg2/udbehol2.baf <-- any idea about the first block?
[11:28:07] <fuzzie> um
[11:28:17] <lynxlynxlynx> See doesn't have an int param, so dead illithid also apply
[11:28:40] <lynxlynxlynx> should we have another ga_no_dead check somewhere?
[11:29:01] <lynxlynxlynx> it keeps forcecasting at corpses (and another one, due to the rest of the script)
[11:29:05] --> demitar has joined #gemrb
[11:29:31] <fuzzie> if it doesn't have an int param, it should be GA_NO_DEAD, right?
[11:30:00] --> WingedHussar has joined #gemrb
[11:31:27] <lynxlynxlynx> right
[11:31:33] <fuzzie> sf's git is quite ridiculously slow
[11:32:35] <lynxlynxlynx> i guess the problem is target reevaluation
[11:33:04] <lynxlynxlynx> ReallyForceSpell([0.0.MIND_FLAYER],BEHOLDER_CHARM_PERSON) <-- does this redo it from scratch or only chooses from the filtered ones?
[11:33:38] <fuzzie> it redoes from scratch
[11:35:33] <lynxlynxlynx> hmm
[11:35:54] <lynxlynxlynx> maybe it was the other way around, since there are live specimens too
[11:36:06] <lynxlynxlynx> and the fault would be in SecondNearest
[11:36:56] <lynxlynxlynx> no flags are passed, but maybe we should have ga_no_dead there by default
[11:38:10] <fuzzie> shouldn't ReallyForceSpell just be passing that?
[11:38:51] <lynxlynxlynx> i think we only abort if we see a dead target
[11:39:05] <lynxlynxlynx> let me check, but i remember that there's a reallyforcespelldead too
[11:39:08] <fuzzie> that is probably a bug
[11:39:13] <fuzzie> yeah, I just looked at it
[11:39:20] <fuzzie> no difference, only AF_ALIVE
[11:40:01] <lynxlynxlynx> relevant to the caster only
[11:40:32] <fuzzie> I would naively think that []-type matching should never catch dead targets.
[11:40:45] <fuzzie> but I don't know. :/
[11:42:11] <fuzzie> the thing to check would be Detect() I guess?
[11:43:23] <fuzzie> 782faaf77c8c6e387da12e0db02d463881552209 looks pretty bad
[11:45:34] <lynxlynxlynx> adding the check to the action worked, but it also uncovered some other problems (existing)
[11:46:30] <lynxlynxlynx> that was moved further down and now doesn't affect the first target lookup
[11:47:27] <fuzzie> yes
[11:47:30] <fuzzie> still pretty bad
[11:48:32] <fuzzie> at least needs to be wrapped in the int param check
[11:49:12] <fuzzie> but presumably you're really just hiding another bug there..
[11:49:17] <fuzzie> any idea what you were trying to fix?
[11:50:14] <fuzzie> am pretty sure that both types of filters should reject dead targets, anyway
[11:50:21] <fuzzie> just not sure where to put that
[11:51:39] <lynxlynxlynx> something was seeing too much
[11:52:07] <fuzzie> well, it seems like right now you sabotage e.g. Detect([PC]) where PC is invis
[11:52:55] <lynxlynxlynx> i don't see any SeeCore users passing any extra params in bg2
[11:53:17] <fuzzie> well, Detect does
[11:53:46] <fuzzie> the GA_DETECT disables the invis check in [] targetting mode
[11:54:29] <fuzzie> if that makes the code make any more sense
[11:54:34] <lynxlynxlynx> it doesn't in my script dump
[11:55:13] <fuzzie> yes, the Detect *action* does :)
[11:55:28] <fuzzie> i.e. Detect == int0Parameter==1
[11:55:53] <lynxlynxlynx> parameters->int0Parameter=1; //seedead/invis yep
[11:56:01] <fuzzie> don't see why it isn't just a normal param
[11:56:45] <fuzzie> I assume that isn't relevant to this script snippet, but I know other scripts break if PC is invis, like this.
[11:56:52] <fuzzie> so, I just see it in passing
[11:57:17] <lynxlynxlynx> why do we have both GA_DETECT and GA_NO_HIDDEN?
[11:57:28] <fuzzie> GA_DETECT only applies to []-style targetting
[11:57:39] <lynxlynxlynx> aha
[11:57:50] <fuzzie> there's basically three types of targets
[11:57:58] <fuzzie> direct targets like 'Player1' always match
[11:58:07] <lynxlynxlynx> no chance to detect that in ValidTarget? It's not using it now directly
[11:58:22] <fuzzie> id targets like '[PC]' get filtered for invis etc during matching
[11:58:42] <fuzzie> and then normal filters like NearestEnemyOf get filtered differently, no invis checks during matching
[11:58:57] <fuzzie> and you can't tell which one is the case inside ValidTarget
[11:59:38] <fuzzie> See() checks for invis itself afterwards, so GA_NO_HIDDEN is fine there, as long as you don't do it for the Detect case
[11:59:55] <fuzzie> but you can't handle GA_DETECT in ValidTarget, because ValidTarget doesn't know which matching type is in use
[12:00:13] <fuzzie> so it's just handled directly in the [] matching code
[12:00:51] <fuzzie> except according to g3, I am wrong and the normal filters *always* get invis checked during matching, even for Detect, so .. take this all with some salt :)
[12:01:08] <fuzzie> but they do agree on the GA_DETECT logic.
[12:01:33] <fuzzie> clearly this is another thing which needs looking at again, anyway
[12:01:34] <lynxlynxlynx> wonderful :)
[12:01:47] <fuzzie> that IF_VISIBLE looks awfully like it should be in the matching code somewhere too, you'd think other actions wouldn't want to get those either
[12:01:58] <lynxlynxlynx> so i'll just ifdef the check in seecore for now to exclude Detect
[12:02:13] <fuzzie> right, that sounds like a good idea
[12:02:18] <fuzzie> unfortunately doesn't magically help your bug :(
[12:02:49] <lynxlynxlynx> not really related
[12:03:14] <fuzzie> well, I was looking because it does seem likely that we should have a GA_NO_DEAD in here somewhere
[12:04:14] <fuzzie> I would guess that GA_NO_DEAD should *always* apply unless we're matching an object directly by name or by a Player1-type match.
[12:04:19] <fuzzie> but, guess.
[12:04:30] <lynxlynxlynx> all the trigger blocks in that script have See too, so I wonder how it managed to run anything
[12:05:21] <fuzzie> we already handle GA_NO_DEAD in places like NearestEnemyOf, I guess?
[12:05:42] <fuzzie> and, well, See *does* specifically pass GA_NO_DEAD, right?
[12:06:10] <fuzzie> so it works out if somehow they all die..
[12:07:29] <lynxlynxlynx> ohh, one was alive, doh
[12:08:02] <lynxlynxlynx> we don't pass GA_NO_DEAD anywhere in matching.cpp
[12:08:27] <fuzzie> the objects are in Objects.cpp
[12:08:40] <fuzzie> but, hm, right, what?
[12:08:48] <fuzzie> wah
[12:09:06] <lynxlynxlynx> DoObjectChecks sounds like a nice place to do it
[12:09:09] <fuzzie> ah, I see, the 'GetNearestEnemyOf' function is not a filter :P
[12:09:23] <fuzzie> DoObjectChecks is []-style matching only
[12:10:16] <fuzzie> you want it in DoObjectFiltering I think.. ?
[12:11:43] <fuzzie> although that still catches stuff like Player1, so maybe you have to do it in two places, I really don't know
[12:13:44] <lynxlynxlynx> i also worry that i'll break resurrection, but let me check how the spell works
[12:13:49] <fuzzie> although maybe not, some scenes would look really silly if that matching worked
[12:14:29] <lynxlynxlynx> ok, simple effect
[12:14:37] <fuzzie> I think the spell is all handled by effects.
[12:14:37] <fuzzie> right.
[12:14:50] <-- kida_laptop has left IRC (Remote host closed the connection)
[12:14:56] <fuzzie> seems worth a try at the start of DoObjectFiltering.
[12:17:06] --> kida_laptop has joined #gemrb
[12:17:42] <lynxlynxlynx> what do you mean? shouldn't we just add ga_no_dead to the flags in there?
[12:20:17] <fuzzie> oh, sure, you can do that too
[12:29:48] <lynxlynxlynx> didn't help though
[12:30:45] <fuzzie> oh, yes
[12:30:47] <fuzzie> right
[12:30:48] --> edheldil_ has joined #gemrb
[12:30:50] <fuzzie> so, no, at the start :P
[12:31:44] <fuzzie> or just add it both in DoObjectFiltering and DoObjectChecks for now I guess
[12:31:52] <fuzzie> if you just want to add it to flags
[12:32:07] <lynxlynxlynx> i'd like to be as correct as possible
[12:32:27] <fuzzie> I have utterly no idea what is correct here.
[12:32:43] <lynxlynxlynx> this is already a bit too inside the engine to be doing it right before the release
[12:32:46] <fuzzie> just thought it would be easy to add to the start of DoObjectFiltering
[12:33:14] <lynxlynxlynx> discard dead members of tgts?
[12:33:26] <fuzzie> but it's not actually easy
[12:33:44] <fuzzie> since in the ids case you don't get *any* iterations of that loop
[12:33:54] <fuzzie> so it's easier to just do it in both places
[12:34:52] <-- edheldil_ has left IRC (Read error: Operation timed out)
[12:35:19] <fuzzie> and I'd kind of hope that nothing relies on dead targets..
[12:35:32] <-- demitar has left IRC (Ping timeout: 252 seconds)
[12:43:06] <lynxlynxlynx> works at the start
[12:56:07] <lynxlynxlynx> http://sprunge.us/JWYW?diff <-- this is what i ended up with
[12:59:01] <fuzzie> do you need the bit in DoObjectChecks if you do that?
[12:59:18] <fuzzie> but it liooks fine
[13:01:53] <lynxlynxlynx> i don't for this case, but i thought you wanted it there too
[13:03:42] <fuzzie> From my quick glance I think DoObjectFiltering always gets called for the relevant cases.
[13:03:45] <fuzzie> So you should be fine without it.
[13:03:54] <fuzzie> Especially if it works for your case, since that's where it'd be needed.
[13:03:57] <fuzzie> Sorry for confusion.
[13:16:46] <lynxlynxlynx> http://paste.debian.net/210686/ <-- any thoughts?
[13:17:29] <lynxlynxlynx> i didn't use RemoveAllNonPermanentEffects since that removes some legitimate effects
[13:21:50] <lynxlynxlynx> and cool, found a way to reproduce the apr madness
[13:28:34] <lynxlynxlynx> hmm, not the best solution, the effects were just instantly applied
[15:17:14] --> _6i has joined #gemrb
[15:17:28] <_6i> hi
[15:18:19] <_6i> i hope, today i have a real gemrb question.. :)
[15:18:42] <_6i> *really a gemrb q...
[15:19:00] <_6i> *gemrb related
[15:19:03] <_6i> damn
[15:24:53] <_6i> so, when i'm in-game, baldur's gate keyboard shortcuts do work (e.g. i for inventory, m for map, r for char. record, etc.), but when the specified page pops up, no keybinding works, only those in the gemrb cheat sheat (if activated in the cfg) -- e.g. if i'm already in one of the mentioed pages, i cannot switch to another using keys but have to click, and esc (or should it be 'g'?) also does not exit the page
[15:26:29] <lynxlynxlynx> yep
[15:26:48] <lynxlynxlynx> currently they only work from the game window
[15:27:30] <_6i> interestingly, when i try to travel to a neighbouring area using the area-edge wheel-iconed click, and the world map pops up, esc do make it exit, while if i get there through 'm' and the area map, it doesn't (iirc)
[15:28:25] <lynxlynxlynx> esc and enter are special, since they are often bound to the default/cancel keys
[15:28:42] <_6i> so you say, no fix so far?... what about the upcoming release you spoke about yesterday?
[15:30:00] <lynxlynxlynx> sometimes this week
[15:30:22] <lynxlynxlynx> cia is dead, so it's hard to track progress via this channel
[15:30:40] <_6i> cia?
[15:30:52] <lynxlynxlynx> i basically need to check just one more thing, but i doubt there'll be any work
[15:31:00] <lynxlynxlynx> commit reporter bot
[15:31:07] <_6i> i see
[15:31:52] <fuzzie> lynxlynxlynx: I think after past conversations with Avenger, we concluded that some effects should just self-destruct if their owner is dead.
[15:31:58] <fuzzie> But honestly I've never looked into it.
[15:33:23] --> Canageek has joined #gemrb
[15:33:39] <lynxlynxlynx> the question is which temporaries should remain otherwise it is just extra work to add the check to individual effects
[15:33:42] <_6i> by effect you mean issues, and by owner the guy who should have fixed it, or you mean in-game effects?..
[15:33:49] <fuzzie> in-game
[15:34:18] <lynxlynxlynx> haha
[15:34:36] <_6i> :) yeah, it's me, again.. :D
[15:35:29] <lynxlynxlynx> bbl
[15:39:32] <_6i> wouldn't be it more correct to let the e.g. spells "play out" --> like when a mage puts a buff on another party member, and the mage dies, shouldn't the spell time out normally regardless of what happens with the caster after the casting? of course this should be not the case for effects which should be continually "maintained" or kept up by the caster (like when doing continuous concentration checks)..
[15:41:39] <_6i> ..or does in baldur's gate (and the other games) the spell need to be "channelled through the caster to affect the current plane, and therefore without the mage the spell is cut?..
[15:42:25] <_6i> ..just theoretically.. :D
[15:50:25] <_6i> fuzzie: just to finish where we left off with lynx^3, do you think that it's reasonable to hope for that keybinding-fix in the upcoming release?
[15:55:23] <_6i> or another issue: settings i make in-game do not seem to persist, there are mostly no alternatives (to my knowledge) in the cfg for them, and the settings i made do change during gameplay (possibly after loading or area change), and even that a bit chaotically (i couldn't see a clear pattern..)
[15:56:15] <_6i> it is a bit annoying e.g. for auto-pause rules
[15:58:06] <_6i> i set not to pause on-hit, then it seems to be changed, but afterwards i do get paused on-hit (the setting is still unchecked in the options menu)
[15:59:27] <_6i> another kind is, when i set e.g. the game difficulty, but when i check it later, the slider is back to the original position (i don't know if the rules actually changed..)
[16:03:25] <_6i> also, for the one option i've found in the cfg (tooptip timeout), the slider does not reflect the in-cfg value which is set (i understand that in the cfg it has millisecond precision and the menu slider has cca. 5 discrete positions, but it would be nice to at least approximately set the slider to a near-corresponding position, or to the max if the value is "overflowing" the slider)
[16:04:31] <_6i> btw, an additional caption next to the slider with the actual value wouldn't hurt either.. :)
[16:06:23] <fuzzie> we don't control the GUI
[16:06:41] <fuzzie> and yes, the cfg thing was something we were hoping to do before the release, I think, but isn't done
[16:06:46] <fuzzie> they shouldn't get changed in-game though
[16:18:34] <lynxlynxlynx> the cfg stuff is done
[16:18:42] <lynxlynxlynx> with saving included
[16:19:54] <lynxlynxlynx> the keybinding stuff is waiting for someone to implement, but nobody volunteered yet
[16:21:51] <-- Canageek has left IRC (Ping timeout: 260 seconds)
[16:42:48] --> brada has joined #gemrb
[16:43:11] <brada> i actually have a patch for the window keys somewhere
[16:47:49] <lynxlynxlynx> so much for my recruitment ploy ;)
[16:48:07] <lynxlynxlynx> i remember, there was something someone didn't like in it
[16:48:21] <lynxlynxlynx> can you look it up?
[16:59:53] <brada> not at the moment
[17:00:05] <brada> but you are right that you were stand ofish
[17:07:24] <-- WingedHussar has left IRC (Quit: WingedHussar)
[17:11:42] <brada> it actually appears that i lost it
[17:13:36] <brada> not even in a git stash :(
[17:16:51] <brada> oh well it didnt take long to write, but id rather remember what was objectionable about it first
[17:17:59] <brada> basically all it did was make the key events return a bool indicating wether they had handled the event or not then if it came back as unhandled to the event manager it trigged a hot key
[17:22:48] <brada> iirc it actually removed more code then it added because the custom code for things like world map could be removed.
[17:24:03] <lynxlynxlynx> fuzzie is the master log searcher
[17:24:19] <lynxlynxlynx> i think i tried to look it up the other day when you mentioned it, but with no success
[17:24:36] <lynxlynxlynx> btw, you can have multiple stashes - see git stash list
[17:27:26] <brada> yes i know
[17:27:29] <brada> i look at all of them
[17:28:14] <brada> most were ancient useless bits or things that were committed long ago or
[17:29:11] <-- brada has left IRC (Quit: brada)
[17:31:53] --> Canageek has joined #gemrb
[17:33:03] <_6i> c'mon brada, you can do it! ;) it would be sweet to have those keys! :D
[17:34:21] <_6i> btw, good to hear about the cfg fix (what exactly? more settings from in-game?..), already can't wait
[17:41:16] --> edheldil_ has joined #gemrb
[17:52:01] <-- Canageek has left IRC (Quit: KVIrc 4.0.4 Insomnia The future is here. It's just not widely distributed yet. - William Gibson)
[19:04:08] <_6i> lynxlynxlynx: hi again, as we confirmed it yesterday, my previous problem(s) originated from errors during the bgt weinstall process, so today i tried to reinstall everything (checked before: mosunpack, tis2bg2 and tisunpack worked -- they printed --help, and also i made everything writable and executable in the pack..)
[19:05:54] <_6i> the 'weinstall bgt' stage just finished, and as i was serching through the setup-bgt.debug logfile, i did not find any {error|Error|ERROR} text, but found some "Warning"s
[19:07:03] <_6i> as i can see, all the warnings are either from the "Cannot handle ..." or the "Cannot delete ..." type
[19:07:31] <_6i> is that normal behavior?
[19:09:32] <_6i> i've got 86 lines containing the word "Warning" in the log
[19:09:52] <lynxlynxlynx> no idea
[19:10:17] --> brada has joined #gemrb
[19:13:48] <-- _6i has left IRC (Ping timeout: 245 seconds)
[19:18:13] --> _6i_ has joined #gemrb
[19:19:04] <_6i_> hi again, it seems my irc server rebooted...or somethin' :)
[19:19:24] --- _6i_ is now known as _6i
[19:20:30] <_6i> oh, i remeber: i was just about to say, that from those 86 warning lines, there was only 8 different:
[19:21:06] <_6i> Warning : Cannot delete source area _HT.bmp file
[19:21:14] <_6i> Warning : Cannot delete source area _LM.bmp file
[19:21:21] <_6i> Warning : Cannot delete source area MOS file
[19:21:26] <_6i> Warning : Cannot delete source area _SR.bmp file
[19:21:33] <_6i> Warning : Cannot handle area _HT.bmp file
[19:21:38] <_6i> Warning : Cannot handle area _LM.bmp file
[19:21:43] <_6i> Warning : Cannot handle area MOS file
[19:21:49] <_6i> Warning : Cannot handle area _SR.bmp file
[19:22:40] <_6i> of course, not in this order (i had them filtered throug 'grep Warning setup-bgt.debug | sort -u')
[19:23:31] <_6i> for example the MOS thingy has the following context:
[19:24:52] <_6i> ...
[19:24:53] <_6i> ----------------------------------------
[19:24:59] <_6i> Local time is: Mon Nov 19 19:13:00 2012
[19:25:11] <_6i>
[19:25:17] <_6i> [Source]: area3100/ar4201.wed, V1.3
[19:25:23] <_6i> area3100/ar4201.tis, V1
[19:25:28] <_6i> [Output]: area3100/ar3101.wed, V1
[19:25:32] <_6i> area3100/ar3101.tis, no header
[19:25:39] <_6i>
[19:25:41] <_6i> Basic tiles number: 88
[19:25:54] <_6i> Doors extra tiles number: 0
[19:26:01] <_6i> Animations extra tiles number: 12
[19:26:06] <_6i> Overlayed doors tiles number: 0
[19:26:13] <_6i>
[19:26:15] <_6i>
[19:26:17] <_6i> Warning : Cannot handle area MOS file
[19:26:24] <_6i> Warning : Cannot delete source area MOS file
[19:26:30] <_6i> Tiles processed: 88 done.
[19:26:35] <_6i> Extra 0 overlay tiles added.
[19:26:42] <_6i> ----------------------------------------
[19:26:44] <_6i> ...
[19:28:17] <_6i> this was the first Warning occurence ( the 1st dashed line i pasted is the 25536th in the .debug logfile)
[19:29:19] <_6i> the 1st warning is on line 25550
[19:42:03] <_6i> i wanted to link a paste of the whole log, but unfortunately i haven't find any site to support big pastes, and mine would be 2.1MB :)
[19:42:30] <_6i> would a contexed grep on "Warning" help?
[19:47:16] <lynxlynxlynx> use a pastebin next time
[19:47:40] <lynxlynxlynx> like i said, i have no idea
[19:48:15] <lynxlynxlynx> one area surely would not load, but that may be of no consequence
[19:48:29] --> demitar has joined #gemrb
[19:57:06] <_6i> ok, so to not to deal with the 2megs of log, i grep-ed it with 25 lines of context around "Warning" matched lines with line numbering (matches are separated with a line containing only "--" without line numbers)
[19:57:09] <_6i> http://paste.debian.net/210801/
[19:58:15] <_6i> lines look like:
[19:58:40] <_6i> linenumber-contextline
[19:58:48] <_6i> linenumber:matchedline
[19:58:55] <_6i> --
[20:02:20] <_6i> anyone took the time to look at it?..
[20:04:55] <lynxlynxlynx> brada: ouch, did you see the latest forum post?
[20:05:42] <_6i> once again: the paste above is grep-ed from weinstall logfile 'setup-bgt.debug'
[20:12:10] <_6i> if anyone is looking at the paste (log), please do tell, so i would not have to wait in vain..
[20:20:18] <_6i> ok, i see nobody cares..
[20:20:32] <_6i> so, another question :)
[20:21:25] <_6i> would it be possible to patch gemrb for android to start on a phone with not a 4 but 3.5 inch display?..
[20:21:38] <_6i> (this is actually gemrb related.. :D)
[20:22:38] <_6i> the phone would be samsung galaxy ace: www.gsmarena.com/samsung_galaxy_ace_s5830-3724.php
[20:22:47] <lynxlynxlynx> that's what she said
[20:24:06] <_6i> care to share? -> "that's what she said"?
[20:26:54] <_6i> ok, i see i'm tiring you, so i'll just leave you to it..
[20:27:07] <brada> lynx: not sure if that is relevant since im not aware of an android build that has actually been built with SDL2
[20:27:17] <lynxlynxlynx> _6i: size doesn't matter ;)
[20:27:41] <lynxlynxlynx> brada: the weekly builds came in two flavours
[20:28:13] <brada> when did that happen?
[20:28:55] <lynxlynxlynx> ages ago
[20:29:01] <lynxlynxlynx> probably before 2 came out
[20:29:04] <lynxlynxlynx> 1.3 times
[20:30:20] <brada> is one bult with sdl2 tho?
[20:30:21] <brada> ]
[20:32:44] <lynxlynxlynx> doubt it, it's been a while
[20:33:04] <brada> mychanges disabled mouse events so i cant imagine he is using SDL 2. and i cant imagine the bug being on our end. it sounds like something (SDL) is sending mouse events with 0,0 coordinates
[20:35:12] <lynxlynxlynx> i initially thought it is just another example why we need a configuration switch
[20:35:21] <_6i> lynxlynxlynx: size might matter if it means resolution.. galaxy ace has only 320x480 pixels, and iirc even the widescreen mod cannot go under 640x480.. (also, i tried to install gemrb from the android market cca. a month ago to try it with the bg2 demo, but it hanged a bit, then crashed on startup)
[20:35:32] <brada> well that much is true. we do need a config option
[20:35:47] <brada> we need an android sdl2 build first for me to care enough to implement one
[20:36:06] <lynxlynxlynx> _6i: while the patches haven't been merged, there is code for splitting the resolution in half
[20:36:16] <fuzzie> yeah, 320x480 just isn't enough
[20:36:43] <lynxlynxlynx> brada: idevices have no chance of mice?
[20:37:09] <brada> well sure jailbroken ones can, but they seem to be rare
[20:37:24] <_6i> fuzzie: according to lynx, wouldn't "cutting in half" mean 320x240?..
[20:37:40] <lynxlynxlynx> interesting
[20:37:48] <brada> btw the sdl 2 driver will scale to the screen
[20:37:50] <fuzzie> _6i: it isn't particularly playable though.
[20:38:02] <fuzzie> I mean, the game still runs at 640x480 minimum.
[20:38:13] <lynxlynxlynx> _6i: it's painful to play on phones as-is, but at such low res ...
[20:38:21] <fuzzie> There's some videos on youtube somewhere I think, of bg2 on the Dingoo using gemrb.
[20:38:26] <lynxlynxlynx> check out the dingux video if you want to have a taste
[20:38:33] <lynxlynxlynx> exactly
[20:38:42] <brada> i have rudimentary pinch to zoom working :p
[20:39:26] <fuzzie> you should just make it work better on my fancy android device, pls
[20:39:35] <brada> :p
[20:39:40] <_6i> pinch-to-zoom could help out.. ;)
[20:39:44] <fuzzie> it has loads of pixels
[20:39:53] <brada> the problem is that it zooms the entire game not just the viewport
[20:40:11] <lynxlynxlynx> you know, someone already implemented this
[20:40:14] <fuzzie> also I'm confused again
[20:40:18] <fuzzie> is there a usable android sdl2 port now?
[20:40:22] <brada> sort of
[20:40:24] <lynxlynxlynx> it was that stranger that did a linux motorola port
[20:40:25] <brada> not in the wild
[20:40:46] <brada> beholder finaly got a working build but he never posted it
[20:41:09] <fuzzie> it didn't seem impossible to build against pelya's sdl2
[20:41:16] <fuzzie> although I never actually got it working
[20:41:30] <brada> i dont know i think he used vanilla sdl2
[20:42:15] <fuzzie> well, I have no interest in building a port which is useless :-p
[20:42:15] <brada> he had to cahnge a variable to get the touch input working is all
[20:42:23] <brada> useless?
[20:42:27] <fuzzie> but it would be cool to be able to play a bit
[20:42:44] <fuzzie> official android sdl2 is terrrrrible, unless someone rewrote it in the last month
[20:42:50] <fuzzie> am sure we've discussed this before
[20:42:54] <brada> much has been done to it
[20:43:06] <brada> yes it has come a long long way since our last discussion :p
[20:43:21] <fuzzie> well our last discussion was quite some time ago I hope :)
[20:43:40] <fuzzie> I could probably do an official sdl2 build pretty easily.
[20:43:46] <brada> that would be nice
[20:43:47] <lynxlynxlynx> http://www.youtube.com/watch?v=Ru-m2BGrnsc&list=PL0AE43FB55973C06A&index=14&feature=plpp_video <-- around 1:30
[20:43:57] <brada> beholder is not around much
[20:44:06] <brada> off to class now
[20:44:08] <-- brada has left IRC (Quit: brada)
[20:52:59] <_6i> lynx: hmm, that redalert...er...i mean iwd look already quite playable :)
[20:54:26] <_6i> i could live with zooming like that ;)
[20:55:07] <_6i> (the dingux video still in the loading phase... :DDD )
[20:55:23] <lynxlynxlynx> woah, i see snow for the first time (that i realise)
[20:58:31] --> avenger_ has joined #gemrb
[20:58:33] <_6i> i would be happy even if gemrb worked for me as in the dingux video (but still, zooming might help ;D )
[20:58:39] <avenger_> hi
[20:58:49] <_6i> hi
[20:59:41] <avenger_> lynx, what iwd dialog hack you and fuzzie talked about?
[21:01:14] --> avenger__ has joined #gemrb
[21:01:45] --- avenger__ is now known as Avenger
[21:01:57] --- ChanServ gives channel operator status to Avenger
[21:02:17] <lynxlynxlynx> that was the djinni one
[21:02:30] <Avenger> ah
[21:02:34] <-- avenger_ has left IRC (Read error: Operation timed out)
[21:02:54] <Avenger> and wha about the lum hack?
[21:03:02] <Avenger> that's clear for release too? ;D
[21:05:01] <Avenger> lol, you found the monk bug?
[21:05:06] <Avenger> that's cool
[21:05:30] <lynxlynxlynx> yeah, good day today
[21:05:50] <Avenger> yeah nice list of dead bugs
[21:06:12] <lynxlynxlynx> i'll check totl again
[21:06:35] <lynxlynxlynx> the last time it wasn't playable forward due to visual or some other range problem
[21:06:41] <lynxlynxlynx> dialog maybe
[21:06:41] <Avenger> i'm pretty sure the djinni is good that way
[21:06:50] <Avenger> that script was definitely using this feature
[21:10:14] <lynxlynxlynx> he's fine
[21:10:26] <lynxlynxlynx> the other problem is in another area
[21:11:03] <lynxlynxlynx> yeah, dialog problem
[21:11:27] <lynxlynxlynx> cutscene starts, someone wants to talk to you before you "explore" him
[21:11:39] <lynxlynxlynx> so the dialog fails and you're stuck
[21:13:48] <lynxlynxlynx> heh, the cutscene itself is playing with the visual range too
[21:16:09] <Avenger> sux
[21:16:13] <Avenger> is this iwd?
[21:16:21] <Avenger> because iwd has weird dialog range
[21:16:24] <lynxlynxlynx> cgptfcen runs, but is irrelevant
[21:16:46] <Avenger> i still didn't find out the difference, but they are different
[21:16:54] <lynxlynxlynx> ar9706 area script doesn't look that bad either
[21:17:43] <lynxlynxlynx> but it likely happens there
[21:17:54] <lynxlynxlynx> nehrpcut is the third one
[21:18:43] <Avenger> ar9706 is also djinni sensitive with that heap of continues
[21:19:26] <Avenger> i wonder what's the goal with if oncreation() then noaction(); continue();
[21:19:31] <lynxlynxlynx> nehrpcut tries to set the dialog range and visual range much higher
[21:19:45] <lynxlynxlynx> i wonder if our max stats array is limiting it
[21:19:54] <lynxlynxlynx> (300)
[21:20:17] <Avenger> i think iwd has no personal dialog/visibility ranges
[21:20:19] <Avenger> only global
[21:20:31] <Avenger> so, that's the difference, and explains why the dialog fails
[21:20:32] <lynxlynxlynx> unrelated, why does Actor have its own copies of Equipped and EquippedHeader?
[21:21:09] <Avenger> i forgot that, but... as a consolation, the original engine has copies too :D
[21:21:41] <Avenger> it is probably possible to remove them, probably ask fuzzie, she just loves refactoring weak code :D
[21:22:04] <Avenger> probably don't try this before release
[21:22:07] <fuzzie> :P
[21:22:42] <Avenger> so back to dialog range
[21:23:09] <Avenger> i think iwd stores dialog range in area (per area dialog range)
[21:23:31] <Avenger> i don't know if it is stored
[21:23:37] <Avenger> but i think it is not
[21:23:50] <Avenger> i mean, it isn't saved
[21:24:06] <lynxlynxlynx> looks like we don't limit the stat
[21:24:41] <Avenger> the problem is, if SetDialogRange runs, it should affect everyone in the area
[21:24:50] <lynxlynxlynx> well even if it was per-actor, from a practical point of view there is little difference
[21:25:09] <lynxlynxlynx> now it runs on the correct actor
[21:25:21] <Avenger> well, i thought there is visibility problem
[21:25:25] <lynxlynxlynx> unless we check the range from the target, not the talker
[21:25:43] <lynxlynxlynx> visualrange is also adjusted
[21:25:47] <Avenger> where is this script?
[21:25:56] <Avenger> nehrpcut?
[21:26:17] <lynxlynxlynx> http://paste.debian.net/210826/
[21:26:35] <Avenger> it is soo lame, why didn't they use the rangeless dialog
[21:27:14] <Avenger> anyway, it is a good test for setvisualrange :)
[21:27:15] <lynxlynxlynx> the area script then resets them
[21:27:33] <_6i> sorry to interrupt the clearly more important conversation, but i would appreciate if anyone could point me to where i can download the latest gemrb android apk (and would tell me which version is the latest..)
[21:27:45] <Avenger> yes, this is an ugly hack just to start a dialog from afar
[21:27:47] <lynxlynxlynx> sourceforge
[21:28:41] <Avenger> http://sourceforge.net/projects/gemrb/files/Other%20Binaries/android/
[21:28:47] <Avenger> not too new :(
[21:29:47] <lynxlynxlynx> hmm, picking a random pc, the range wasn't adjusted
[21:29:56] <lynxlynxlynx> but that's in line, doh
[21:30:36] <Avenger> i don't think we support per area dialog/visibility ranges :)
[21:31:41] <lynxlynxlynx> yeah yeah
[21:33:32] <lynxlynxlynx> it is set properly on the queen
[21:33:44] <_6i> Avenger,lynxlynxlynx: thanx -- it seems i've been at the right place.. so 11bfc23 is the latest?.. (2012-07-11)
[21:33:57] <Avenger> yes
[21:34:15] <Avenger> we don't really have android development
[21:34:17] <_6i> could that have the zooming patch?..
[21:34:39] <lynxlynxlynx> no
[21:34:52] <_6i> (what was in this video: http://www.youtube.com/watch?v=Ru-m2BGrnsc&list=PL0AE43FB55973C06A&index=14&feature=plpp_video )
[21:35:01] <lynxlynxlynx> not android
[21:35:17] <Avenger> though it is likely it could be ported to android
[21:35:24] <Avenger> we just don't have the environment
[21:35:30] <lynxlynxlynx> but we don't the code either
[21:35:42] <Avenger> heh?
[21:35:45] <_6i> shame :( , what about the cut-resolution-in-half patch from the dingux video?
[21:35:58] <lynxlynxlynx> on github
[21:36:48] <_6i> i see :) welcome to the cutting edge, right?.. :D
[21:37:20] <Avenger> well, we don't really cover android, but welcome anyone who can do it
[21:37:23] <_6i> never getting the good stuff without compiling..
[21:38:42] <Avenger> once you set up a build environment, you'll get really cutting edge stuff
[21:39:21] <Avenger> just today lynx alone made >10 commits :)
[21:39:29] <_6i> learning android development is on the todo list...maybe i'll check back later...if the build apk-s will make me angry.. :P
[21:39:36] <Avenger> well not entirely today
[21:39:52] <_6i> *built
[21:40:02] <Avenger> ok
[21:40:10] <Avenger> i'm pretty sure the are outdated
[21:40:26] <lynxlynxlynx> they are
[21:40:37] <Avenger> Here is the commit log :D http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=shortlog
[21:40:39] <_6i> well, that learning part might take longer, too.. :D
[21:40:40] <lynxlynxlynx> we didn't manage to get the build slave uo
[21:40:45] <lynxlynxlynx> up
[21:41:18] <Avenger> brad couldn't make apk's?
[21:42:02] <_6i> damn, if i only had more free time...
[21:42:46] <Avenger> yeah, mine ran out too. see you later
[21:42:49] <-- Avenger has left IRC (Remote host closed the connection)
[21:44:48] <lynxlynxlynx> no, it was the other android guy that volunteered
[21:45:10] <lynxlynxlynx> al3xaps almost got it to work
[21:45:35] <lynxlynxlynx> anyway, stepped right into the problem
[21:45:42] <-- edheldil_ has left IRC (Ping timeout: 264 seconds)
[21:45:53] <lynxlynxlynx> when the dialog checks are being made, visual range is not 50 yet
[21:48:26] <lynxlynxlynx> fuzzie: is it possible that the area script would run in the middle of it all?
[21:49:41] <lynxlynxlynx> and yes, with a range of 50, the check would pass
[22:06:58] <lynxlynxlynx> progress
[22:09:42] <lynxlynxlynx> tada :D
[22:11:47] --> edheldil_ has joined #gemrb
[22:35:38] <lynxlynxlynx> another blocker
[22:35:59] <lynxlynxlynx> but a good one, i suspect deactivate is problematic
[22:36:20] <lynxlynxlynx> but it's on a chest, so easy new insights
[22:52:38] <-- edheldil_ has left IRC (Read error: Operation timed out)
[23:19:44] <-- edheldil has left IRC (Remote host closed the connection)
[23:21:03] <lynxlynxlynx> ok, enough for today :]
[23:35:58] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)