#gemrb@irc.freenode.net logs for 16 Jan 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:05:23] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[00:06:18] --- ermo is now known as ermo^
[02:13:51] --> brada has joined #gemrb
[02:22:26] <-- Cuvieronius has left IRC (Quit: ChatZilla 0.9.89 [Firefox 18.0/20130104151925])
[05:04:10] <-- brada has left IRC (Quit: brada)
[05:13:56] --> brada has joined #gemrb
[06:01:03] <-- brada has left IRC (Quit: brada)
[06:04:07] --> brada has joined #gemrb
[06:52:00] <-- brada has left IRC (Quit: brada)
[07:20:17] --> miha has joined #gemrb
[07:50:56] --> edheldil_ has joined #gemrb
[08:08:44] --> lynxlynxlynx has joined #gemrb
[08:08:44] --- ChanServ gives channel operator status to lynxlynxlynx
[08:12:43] <-- edheldil_ has left IRC (Read error: Operation timed out)
[08:28:17] --> WingedHussar has joined #gemrb
[08:51:55] --> edheldil_ has joined #gemrb
[09:50:38] <Seniorita> [wiki] fap http://www.gemrb.org/wiki/doku.php?id=fap&rev=1358329775&do=diff
[10:33:32] <-- WingedHussar has left IRC (Ping timeout: 256 seconds)
[10:34:24] --> WingedHussar has joined #gemrb
[10:54:55] <-- |Cable| has left IRC (Ping timeout: 260 seconds)
[11:07:55] --> |Cable| has joined #gemrb
[12:31:00] --> traveler__ has joined #gemrb
[12:32:58] <-- traveler has left IRC (Ping timeout: 245 seconds)
[13:22:33] <-- chiv has left IRC (Quit: Page closed)
[14:07:15] <-- lynxlynxlynx has left IRC (Ping timeout: 260 seconds)
[14:18:20] --> kida has joined #gemrb
[14:25:58] --> lynxlynxlynx has joined #gemrb
[14:25:58] <-- lynxlynxlynx has left IRC (Changing host)
[14:25:58] --> lynxlynxlynx has joined #gemrb
[14:25:58] --- ChanServ gives channel operator status to lynxlynxlynx
[14:39:52] --> rocket_hamster has joined #gemrb
[14:59:16] <-- miha has left IRC (Quit: Lost terminal)
[15:03:47] --> chiv has joined #gemrb
[15:15:53] <-- traveler__ has left IRC (Ping timeout: 245 seconds)
[15:21:25] --> traveler__ has joined #gemrb
[15:28:56] --> miha has joined #gemrb
[15:38:53] --- ermo^ is now known as ermo
[15:58:59] --> brada has joined #gemrb
[15:59:18] <brada> fuzzie: do you have a min?
[16:00:45] <fuzzie> yes.
[16:00:47] <fuzzie> hi.
[16:01:16] <-- WingedHussar has left IRC (Quit: WingedHussar)
[16:01:47] <brada> so as we discussed i am dynamically loading and caching ttf glyphs
[16:02:00] <brada> i dont know if i am using the best method tho
[16:02:08] <brada> currently using the hash map class
[16:02:13] <fuzzie> right, it sounded like a pretty sensible approach, at least until you discover some issue :)
[16:02:18] <brada> heh
[16:02:39] <brada> its been forever since i was in data structures
[16:02:46] <fuzzie> well, even on 64-bit, an array of 64k glyphs = 256k RAM, so if you have problems then that's not such a crazy idea instead
[16:03:38] <brada> im not sure what the block size parameter is tho
[16:03:45] <brada> is that just the size of sprite*?
[16:03:55] <fuzzie> no
[16:04:14] <brada> so what should i be using to initialize it?
[16:04:35] <chiv> brada: I almost certainly did something wrong, but I could not get that patch to work correctly; for some weird reason, all the text went into one box in the corner, and was garbled after the first glyph...
[16:04:52] <brada> queer
[16:05:10] <fuzzie> brada: new entries are allocated in chunks of blockSize
[16:05:10] <brada> garbled text could be the font tho
[16:05:19] <brada> oh ok
[16:05:33] <brada> so more like size of sprite* * 256 or some such
[16:05:38] <fuzzie> so if you're likely to be adding a lot of entries, you can put it higher to avoid fragmentation
[16:06:03] <brada> i was thinking of 128 or 256
[16:06:04] <fuzzie> no, sorry, I mean, if blockSize is, say, 4, then you get 4 entries allocated when you need new ones
[16:06:16] <brada> oh
[16:06:21] <brada> i see
[16:06:45] <fuzzie> so, 4*sizeof(Entry), where Entry is a couple of pointers and an integer in this case
[16:07:26] <brada> yup i see that now that you explain it
[16:07:31] <fuzzie> but it's probably premature optimisation to worry about it..
[16:07:34] <brada> its usually quicker to ask you :p
[16:07:56] <brada> yeah i just wanted to make sure it wasnt a terrible idea
[16:08:11] <brada> it works fine afict
[16:09:01] <brada> i suppose i need a subclass of hashmap so i can deallocate all the sprites in it?
[16:09:13] <brada> i dont see a way to walk over it
[16:09:51] <chiv> huh? it seems to magically have started working now...
[16:09:56] <brada> ha
[16:10:06] <chiv> at least after the start.py first screen
[16:10:20] <chiv> i dont know why that one breaks
[16:10:27] <brada> o_O
[16:10:35] <brada> doesnt make much sense
[16:11:18] <-- traveler__ has left IRC (Ping timeout: 245 seconds)
[16:11:25] <fuzzie> brada: it seems sort of annoying to subclass
[16:11:48] <brada> yeah, but how else can i free all the cached glyphs?
[16:11:59] <brada> alter the original?
[16:12:36] <fuzzie> can you perhaps store Holder<Sprite2D>?
[16:13:09] <wjp> which hashmap are you using?
[16:13:11] <chiv> its hella strange, for the most part the text boxes are correct, but random specific ones get filled with garbage... maybe I should wait until its in the mainline :)
[16:13:12] <fuzzie> We don't seem to use that anywhere as-is, but I don't see why.
[16:13:16] <fuzzie> wjp: include/HashMap.h
[16:13:18] <brada> wjp: just HashMap
[16:13:33] <wjp> oh, include. I keep forgetting about that directory
[16:13:38] <fuzzie> our very own special one, which looks sort of suspiciously like it wouldn't manage 64-bit ptrs
[16:13:47] <fuzzie> yes, I didn't find it at first glance either
[16:13:47] <brada> chiv: sure maybe. i never saw anything like that
[16:13:54] <brada> are you using the font i suggested?
[16:14:09] <chiv> i found a simhei.ttf on the internet
[16:14:34] <brada> are you using gbk?
[16:14:38] <brada> tlk i mean
[16:14:48] <chiv> yeah
[16:15:11] <fuzzie> which text boxes?
[16:15:33] <fuzzie> I assume we don't try and do e.g. capitalisation right now, so if it's labels and stuff, that might be it.
[16:15:55] <chiv> its: all the ones on the splash screen, the char pregen one, the character stats info box
[16:16:19] <chiv> i can confirm the ones that work make sense though :)
[16:16:33] <brada> yeah i wasnt worried about that
[16:16:56] <brada> just strange that it works on all those screens for me
[16:17:06] <brada> and it shouldnt matter what screen you use
[16:17:19] <brada> since the font is not discriminitory
[16:17:37] <brada> but try turnint the capitalization off in chinese.ini
[16:17:49] <brada> then add Encoding=chinese in cfg
[16:18:10] <chiv> ok this is probably a clue, this time the garbage was actually a bam header
[16:18:23] <brada> oh
[16:18:40] <brada> you need to turn all fonts except numeric and states to ttf
[16:18:41] <fuzzie> character stats info box would include icons I guess?
[16:19:00] <chiv> yeah, are they not working yet?
[16:19:11] <brada> no you just never would want to change them
[16:19:21] <brada> you can change the numeric if you want
[16:19:33] <brada> but change the pt size to something small
[16:20:12] <brada> states are the icons so you are gonna have a bad time if you change those to ttf
[16:20:20] <brada> might be fun to try wingdings tho :D
[16:20:27] <chiv> i just used the 2da as it was in the patch
[16:20:31] <fuzzie> I was thinking Apple's bitmap emoji font. :P
[16:20:35] <brada> heh
[16:20:37] <brada> that too
[16:21:01] <chiv> http://pastefile.com/uploads/Screenshot%20from%202013-01-16%2016:18:31.png
[16:21:03] <brada> i wonder what effect would produce the little pile of poo :&
[16:21:27] <brada> womething is quite wrong there
[16:21:38] <fuzzie> that's interesting
[16:21:40] <brada> BAMv1 is the header for a bam file
[16:21:43] <fuzzie> corruption?
[16:21:47] <brada> somewhere
[16:22:58] <brada> i see you mentioned that :p
[16:23:07] <chiv> it probably best not to worry about it and i will test again later
[16:23:11] <brada> sure
[16:23:45] <brada> fuzzie
[16:23:47] <brada> bah
[16:23:55] <brada> 64bit pointer in hashmap wont work?
[16:24:47] <fuzzie> well, it seems to clearly cast it to 32-bit at a glance, but I don't know if I'm missing something.
[16:24:55] <fuzzie> It wasn't really designed for pointers though.
[16:25:17] <fuzzie> And you're presumably very unlikely to get hash collisions anyway, which is where it'd go wrong.
[16:25:23] <brada> i suppose i can build it for 64 bit real quick then :p
[16:25:59] <fuzzie> You don't usually?
[16:26:06] <brada> usually use ios
[16:26:14] <fuzzie> Ah.
[16:26:19] <brada> its nice having the little interface to pick the game
[16:26:36] <fuzzie> I don't think you'd notice any problems though, it's just thereotically bad.
[16:26:37] <brada> it works on mac 64bit
[16:27:12] <fuzzie> Since even if you truncate to 32 bits for comparisons, you're not likely to end up with the same value, unless fate really doesn't like you that day.
[16:27:45] <brada> so something to worry about later :p
[16:28:34] <brada> now how will holder help me with the deallocation?
[16:29:59] <fuzzie> well, it's a smart pointer, so it will call acquire()/release() itself, and reference counting should take care of the rest
[16:30:17] <fuzzie> but then you do have to provide a specialisation for it (like the one in StringMap.h)
[16:30:30] <brada> i shall have a look
[16:30:57] <fuzzie> Since Sprite2D does have acquire/release I don't see any reason why it shouldn't work in theory, but we don't seem to use it anywhere, so maybe it doesn't.
[16:31:21] <brada> i have used the acquire and release methods for it
[16:31:30] <brada> seems to do what it should
[16:31:35] <fuzzie> We do wrap it in CObject which is pretty equivalent.
[16:32:14] <brada> well seems im nearly done then
[16:33:56] <-- miha has left IRC (Ping timeout: 248 seconds)
[16:43:53] --> traveler has joined #gemrb
[16:44:48] <traveler> huh. cursed scroll of ugliness, i can understand reducing CHR , but INT ?
[16:46:24] <traveler> scrl13
[17:00:51] <Seniorita> [wiki] todo - [Baldur's Gate] http://www.gemrb.org/wiki/doku.php?id=todo&rev=1358355450&do=diff
[17:01:17] <-- brada has left IRC (Quit: brada)
[17:01:34] --> fizzle has joined #gemrb
[17:04:52] <lynxlynxlynx> traveler: are you sure it wasn't just a portrait update issue? the curse was still visible in the records screen?
[17:07:07] <Seniorita> [wiki] todo - [Baldur's Gate] http://www.gemrb.org/wiki/doku.php?id=todo&rev=1358355958&do=diff
[17:07:31] --> traveler__ has joined #gemrb
[17:07:33] <-- traveler has left IRC (Ping timeout: 245 seconds)
[17:08:11] <traveler__> there is no portrait icon with this scroll curses
[17:08:49] <lynxlynxlynx> how do you know it's a curse then?
[17:08:58] <traveler__> but yes, they work
[17:09:04] <traveler__> changed stats
[17:09:12] <traveler__> text in infobox?
[17:09:23] <lynxlynxlynx> so they're just like any other spell probably, not curses
[17:09:40] <traveler__> and that would be why it doesn't work with curse removal?
[17:09:46] <lynxlynxlynx> and i bet if you checked the duration in dltcep, the effect are not permanent
[17:09:46] <traveler__> from temple
[17:10:12] <lynxlynxlynx> that'd be my guess, you'd have better chances with dispel magic
[17:10:16] <traveler__> i thought they are, but maybe they are not indeed
[17:11:14] <traveler__> you are probably right
[17:11:24] <traveler__> as magic resistance interferes with them too
[17:11:55] <traveler__> ok, dispel magic works
[17:12:04] <traveler__> so curses from scrolls are not really curses
[17:13:15] <lynxlynxlynx> only by name :)
[17:13:30] <traveler__> cursed scroll of poisoning is funny... you are targetted (as wth all cursed scrolls) _as well_ as original target
[17:13:37] <traveler__> so it's still offensive
[17:13:40] <traveler__> and very powerful
[17:14:44] <traveler__> and you can kill e.g. temple members with it without turning other to enemies
[17:26:37] --> brada has joined #gemrb
[17:47:36] <-- edheldil_ has left IRC (Read error: Operation timed out)
[18:17:23] <brada> fuzzie: holder seems to have done the trick
[18:18:41] <brada> well sort of
[18:18:49] <brada> the sprites have ref count of 2...
[18:22:20] <fuzzie> did you release the original ref?
[18:22:31] <brada> yeah thats what i just did
[18:22:34] <brada> now it works
[18:22:58] <brada> so thank you
[18:25:45] <fuzzie> nicely done if you made it work :)
[18:26:03] <brada> well with my luck it will explode on another compiler/system :/
[18:26:37] <brada> for example: GetCharSprite member function is const
[18:26:51] <brada> yet i get no warning about adding to the glyph cache member
[18:27:23] <brada> shouldnt taht not even compile?
[18:29:34] <fuzzie> without mutable, it should complain, yes, but too tired to think about it much :)
[18:30:12] <brada> ok then ill just wait till chiv goes to try it out and it fails to compile
[18:30:18] <wjp> where is this code?
[18:30:28] <fuzzie> not yet committed
[18:30:34] <brada> i have github tho
[18:30:46] <brada> i can quickly commit this and push it there
[18:31:02] <fuzzie> makes sense if you want a review :)
[18:31:21] <brada> well i was planing on it, but im doing this in small managable chunks ;)
[18:32:21] <brada> here is what i have commited so far
[18:32:21] <brada> https://github.com/bradallred/gemrb/commits/mbfonts
[18:32:25] <Seniorita> Commit History · bradallred/gemrb · GitHub
[18:32:28] <brada> that lacks the caching stuff tho
[18:32:35] <fuzzie> right, there's no GetCharSprite overridign there
[18:32:36] <brada> so it wont do much good to look yet
[18:32:44] <brada> precicely
[18:53:04] <brada> fuzzie/wjp: i pushed my changes to my github
[19:05:36] <wjp> that's because glyphCache is a pointer
[19:06:54] <-- rocket_hamster has left IRC (Ping timeout: 276 seconds)
[19:09:03] <brada> makes sense
[19:09:19] <brada> so if i were to try to change the value of the pointer it would yell and scream
[19:12:26] <lynxlynxlynx> edheldil: i see i added a small ieparse wrapper to show diffs; do you know if git could use this to display usable diffs for blobs?
[19:13:54] <brada> that would be neat
[19:40:47] --> Yoshimo has joined #gemrb
[19:43:08] --> edheldil_ has joined #gemrb
[19:43:22] <-- edheldil_ has left IRC (Client Quit)
[19:43:29] --> edheldil_ has joined #gemrb
[19:47:04] <chiv> i am back, it am going to build off that repo now
[19:48:03] <brada> chiv: that still doesnt have mb support in it. you would have to merge some bits from that other patch
[19:49:15] --> chiv_ has joined #gemrb
[19:50:31] <chiv_> hmmm, that might be tricky...
[19:50:48] <brada> youve done trickier
[19:51:18] <-- chiv has left IRC (Ping timeout: 245 seconds)
[19:51:22] <brada> jsut keep the ttf stuff from that branch and the merge the font class changes from both
[19:54:58] <chiv_> heh, I think its a bit above my head, just looked
[19:55:49] <brada> im quite certain you could do it
[19:56:21] <chiv_> there is so much difference between the trees I have no idea what to merge
[19:56:33] <brada> just add my github as a remote then checkout my branch
[19:56:49] <chiv_> doh! i forgot to checkout, thats why
[19:56:53] <brada> then get the old patch and remove the ttf changes in it
[19:56:55] <chiv_> i thought that was strange
[19:57:01] <brada> then apply it
[20:02:08] <chiv_> building...
[20:03:19] <chiv_> hm, compiler warning
[20:03:37] <brada> well thats not terribly suprising
[20:03:43] <brada> what is the warning?
[20:04:23] <chiv_> http://pastebin.ca/2303532
[20:04:25] <Seniorita> pastebin - Stuff - post number 2303532
[20:05:23] <brada> i forget about the strict order of initilizers
[20:05:28] <chiv_> the patch seemed to go ok
[20:06:13] <brada> so no more problems?
[20:06:16] <brada> or?
[20:07:56] <chiv_> have to admit, I dont know how to make the compiler shutup
[20:08:41] <fizzle> traveler__: that NBOY animation is yet another different animation type
[20:08:42] <brada> change the order
[20:08:46] <fizzle> *sigh*
[20:08:55] <brada> so that the initializers are called in the order they are declared
[20:10:11] <brada> (or just build with warnings)
[20:11:18] <lynxlynxlynx> edheldil: cool, it is possible; --textconv and gitattributes
[20:11:34] <lynxlynxlynx> didn't try with ieparse, since it doesn't run here now, but ielister works aswell
[20:12:17] <lynxlynxlynx> http://paste.debian.net/225430/
[20:12:19] <Seniorita> debian Pastezone
[20:16:09] <edheldil_> lynx: nice :)
[20:16:21] <edheldil_> sorry to reply omly now
[20:16:36] <lynxlynxlynx> np
[20:16:48] <lynxlynxlynx> i got sidetracked from trying to make iesh work with py3
[20:17:23] <lynxlynxlynx> some import problem after the 2to3 autoport
[20:17:50] <lynxlynxlynx> too bad this diff stuff can't be automated
[20:19:01] <edheldil_> I will look into it, there's probably a ron of string x bytes issues
[20:19:05] <edheldil_> ton
[20:20:07] <edheldil_> how did you configured it in git?
[20:21:14] <brada> yes post some instructions :)
[20:27:39] <lynxlynxlynx> incoming
[20:27:56] <lynxlynxlynx> bbl
[20:28:21] <edheldil_> ahh, found it
[20:28:26] <Seniorita> [commit] Jaka Kranjc: admin/enable-ie-git-diff: added script/instructions for enabling diffs for ie blobs http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=8fc2d45170522978af812d05ae5cb8844517327b
[20:30:30] <chiv_> heh, now i cant build ttffont.cpp... something tells me I am doing it wrong
[20:30:59] <brada> chiv: it could be my cmake changes being bad
[20:33:19] <chiv_> i assumed you meant to prune the changes from ttffontmanager.cpp, should i not have done that?
[20:33:56] <brada> no :p
[20:34:44] <brada> there was a single line in that old patch you were supposed to remove
[20:34:46] <brada> that was it
[20:36:31] <chiv_> well, I have no idea which one, I don't even look at this area - its too scary...
[20:38:37] <brada> well ill have something for you that needs no patch later tonight
[20:39:36] <chiv_> sorry, unfortunately you are dealing with a moron in the case of me :)
[20:40:02] <brada> gdoubtful
[20:49:03] <Seniorita> [commit] Jens Granseuer: allow the player to select party members even when hidden/invisible http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=01b149c397827792e4cc712672481bf95f9df5a7
[20:49:05] <Seniorita> [commit] Jens Granseuer: add support for yet another slightly different animation layout http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=c9dfe55397c0717d164d6f73f0a6a92e6a155618
[20:49:06] <Seniorita> [commit] Jens Granseuer: use IE_ANI_FOUR_FILES_3 for lots of civilians http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=561a3f2f8489f5464e15891f26f8e342b70559fe
[21:06:36] --> chiv has joined #gemrb
[21:06:42] <-- chiv_ has left IRC (Quit: Page closed)
[21:10:52] <-- Yoshimo has left IRC (Quit: Yoshimo)
[21:13:58] <Seniorita> [commit] Avenger: fence flag is 0x1000, my bad http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=0c4c3608e20397fb14a658370b3dede58538ab6f
[21:13:59] <Seniorita> [commit] Avenger: Merge branch 'master' of ssh://gemrb.git.sourceforge.net/gitroot/gemrb/gemrb http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=b8c4f2b0ff629ed81396ecc53ab35d843d3c352f
[21:24:02] <-- edheldil has left IRC (Remote host closed the connection)
[21:24:31] <traveler__> fizzle: if you fix something, please comment/delete bit from wiki too; i'm not always that fast... today i got caught up in chocolate-doom port which for unknown reasons is very stubborn to not install files where _i_ want
[21:24:40] <traveler__> *appropriate bit
[21:27:48] <traveler__> i mean, if you just want to focus on developing cool, but i not always can follow irc, so i can miss something requiring retesting or removing already
[21:37:43] --> traveler___ has joined #gemrb
[21:37:43] <brada> you are such a studious wiki master tho
[21:40:28] <-- traveler__ has left IRC (Ping timeout: 245 seconds)
[21:58:29] <traveler___> brada: very funny
[21:59:01] <brada> wasnt joking. its nice having you maintain the wiki :
[21:59:02] <traveler___> ...and chivs wiki edits are a lot prettier
[21:59:04] <brada> :p
[21:59:09] <brada> meh
[22:00:03] <traveler___> autotools is ver definition of madness.
[22:00:26] <traveler___> automake fails becouse it is 1.12 and configure in is from 1.11
[22:00:28] <brada> with gemrb you mean?
[22:00:30] <traveler___> *very definition
[22:00:32] <traveler___> no
[22:00:37] <traveler___> totally unrelated
[22:00:48] <brada> cuz our automake stuff is in bit rot
[22:01:23] <traveler___> i know
[22:01:31] <traveler___> i don't use it
[22:01:36] <brada> its probably rotten to the point that we should remove it
[22:01:52] <traveler___> i heard this too i think ;)
[22:01:55] <brada> so many files addes/moved/removed since it was updated
[22:16:18] <chiv> heh, I actually wrote the torment page with the idea that many quests would be broken and need lots of investigation and info, turns out the opposite was true and its only the same 4 or 5 bugs breaking everything
[22:17:17] <fizzle> ugh
[22:17:32] <fizzle> Segmentation fault.
[22:17:34] <fizzle> 0x00007ffff7d5adc4 in GemRB::Actor::GetRacialEnemyBonus (this=0xfc4250, target=0x0)
[22:17:36] <fizzle> at /home/fizz/dev/gemrb/gemrb/core/Scriptable/Actor.cpp:8916
[22:17:38] <fizzle> 8916 if (Modified[IE_HATEDRACE] == target->Modified[IE_RACE]) {
[22:18:10] <fizzle> unfortunately I was in fullscreen so lost the backtrace
[22:18:49] <fizzle> traveler___: anims should be fine now, hopefully
[22:19:19] <fizzle> the boy one anyway
[22:21:58] <fizzle> oh, well, that was easy to reproduce :P
[22:22:05] <traveler___> yeah, that's what i was alluding to, but i cannot check this now ;)
[22:29:22] <brada> target being NULL for that seems odd
[22:29:33] <fizzle> nah, not odd
[22:29:40] <fizzle> just not handled :P
[22:29:53] <Seniorita> [commit] Jens Granseuer: fix crash when GetRacialBonus is called without a target http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=0c5e4da11442def3a6b09197a2b778807d179a04
[22:35:47] <brada> it seems odd that GetRacialEnemyBonus would ever be called with null
[22:35:54] <brada> (i havent actually examined code)
[22:36:06] <fizzle> it's quite normal from the character screen
[22:36:34] <brada> i shall take you at your word sir
[22:37:37] <brada> chiv: ready to test things?
[22:39:58] <chiv> yeah ready
[22:40:22] <chiv> shall i just git pull your repo again?
[22:46:51] <brada> no
[22:46:58] <brada> i m not quite ready
[22:47:30] <traveler___> brada: if you are interested, there should be few new warnings in font.cpp (clang 3.2)
[22:47:39] <brada> new?
[22:47:43] <brada> i doubt they are new
[22:47:51] <traveler___> well new
[22:48:06] <brada> i saw what you posted yesterday
[22:48:08] <brada> they arent new
[22:48:10] <traveler___> in the meaning they appeared for me after switch to 3.2
[22:48:13] <brada> ah
[22:48:18] <traveler___> change in default flags?
[22:48:22] <traveler___> or smt
[22:48:34] <brada> i have no idea
[22:48:47] <brada> xcode is annoyingly silent by default
[22:49:10] <traveler___> miss -Weverything ;) ?
[22:49:37] <brada> heh
[22:49:53] <brada> i jsut dont know why -Wall er whatever it was didnt work
[22:50:23] <traveler___> -Wall good, -Weverything bad iirc
[22:50:36] <traveler___> not speaking of gemrb, just in general sense
[22:50:37] <brada> right but wall did not have any effect is what i am saying
[22:50:41] <brada> maybe it does now
[22:50:46] <brada> that was a while ago
[22:51:11] <traveler___> ah
[22:51:18] <traveler___> that's strange
[22:51:33] <brada> yeah well several clang and xcode updates have come since
[22:51:38] <brada> so time to try again
[22:56:58] <traveler___> probably seen this already http://programmers.stackexchange.com/questions/122608/clang-warning-flags-for-objective-c-development
[22:57:04] <Seniorita> Clang warning flags for Objective-C development - Programmers
[22:57:28] <traveler___> from what i see, freshest xcode still have clang 3.1 so that could explain some differences still (3.2 here)
[22:59:34] <brada> it was still clang 2.x when i last tried
[22:59:55] <brada> so i will add it back in now
[23:03:45] <brada> chiv: we will have to do this tomorrow i got caught up in more important matters
[23:04:02] <chiv> no worries
[23:05:16] <lynxlynxlynx> ok, back
[23:06:32] <lynxlynxlynx> chiv: there was a change to store flags, but i doubt that affects your magic item bug
[23:07:18] <chiv> in torment? nothing else seems weird there, its specifically just magic weapons that i couldnt sell to anyone
[23:08:39] <brada> it may have affected it
[23:08:46] <brada> isnt the changed flag for stolen goods?
[23:09:26] <chiv> it was all found loot, maybe torment has different flag usage?
[23:11:08] <lynxlynxlynx> quite possible, but from what little i saw of that diff, it's more likely to do if the store buys stolen items or not
[23:11:10] <brada> well what i mean was thee error avenger fixed today
[23:12:10] <chiv> oh, i havent checked since then
[23:12:31] <edheldil_> phew... I have made iesh start under py3k, but quickly ran into bytes/string problems
[23:13:21] <-- fizzle has left #gemrb
[23:14:13] <-- traveler___ has left IRC (Ping timeout: 245 seconds)
[23:18:32] <brada> chiv: that didnt take as long as i though
[23:18:40] <brada> if you want to test just pull my branch down
[23:18:47] <lynxlynxlynx> edheldil_: how did you fix that bam import error?
[23:18:49] <brada> and apply a patch im making
[23:19:05] <lynxlynxlynx> i didn't see a circular dep when i checked
[23:19:06] <chiv> ok
[23:22:15] <brada> http://paste.debian.net/225488/
[23:22:17] <Seniorita> debian Pastezone
[23:22:20] <brada> chiv: thats the patch
[23:23:37] <brada> wait
[23:23:42] <brada> wrong file :(
[23:23:47] <chiv> doh
[23:24:02] <brada> http://paste.debian.net/225489/
[23:24:04] <brada> there
[23:24:06] <Seniorita> debian Pastezone
[23:24:26] <brada> probably negligable diffrences tbh
[23:24:30] <brada> probably both would work
[23:25:09] <chiv> ok, building
[23:29:21] <brada> i didnt rebase to fix that warning btw
[23:31:03] <edheldil_> lynxlynxlynx: the PIL one? Just ignored the exception
[23:33:56] <lynxlynxlynx> formats/init could import bam here, no mention of pil specifically
[23:36:06] <edheldil_> so what bam import error do you mean?
[23:39:35] <chiv> hmm.. do i need the old patch too? ttfimporter didnt build
[23:39:42] <brada> no
[23:39:46] <brada> so whats the problem?
[23:40:19] <chiv> various vars not in right scope
[23:40:41] <brada> maybe i should try with cmake
[23:42:07] <chiv> im not convinced that new patch applied correct, it seems to have broken ffont:getcharsprite
[23:44:55] <brada> font::getcharsprite should be gone completely
[23:45:14] <brada> and this builds fine in camake for me
[23:45:16] <brada> cmake
[23:45:29] <chiv> wierd, should I be on mbfonts branch?
[23:45:32] <brada> yes
[23:45:34] <brada> did you pull
[23:45:39] <chiv> yup
[23:46:05] <chiv> gnarg, not recently enough by the look of it#
[23:46:43] <chiv> i probably should have waited a minute or two after you said...
[23:47:13] <brada> the only problems building i have are that warning which i will fix in a rebase before merging
[23:47:20] <brada> and the missing iconv
[23:47:41] <brada> speaking of how are you patching the cmake to add that?
[23:47:49] <brada> because i will need to do the same
[23:48:46] <brada> chiv: did you remember to do a git reset to my branch?
[23:48:54] <chiv> yep
[23:49:04] <brada> so your working tree is clean?
[23:49:15] <chiv> iconv is just in /usr/include for me, so i guess thats fine?
[23:49:27] <brada> well cmake needs to be told to link it
[23:49:34] <brada> so what did you do to cmake.txt?
[23:50:06] <chiv> nothing at all
[23:50:38] <brada> i would expect it to fail with missing symbols...
[23:50:40] <chiv> i didn't realise i needed to :)
[23:50:47] <brada> maybe you dont
[23:50:58] <brada> maybe something else you are linking with is bringing it in for you
[23:52:37] <brada> but anyway if you do a git reset to my branch and either discard or stash your working tree then apply that patch file you should build just fine sans warnings
[23:54:08] <brada> bbl
[23:54:10] <-- brada has left IRC (Quit: brada)