[00:10:57] <brada> “protection from cold” should print correctly now :)
[00:43:17] <brada> https://www.dropbox.com/s/cwtukctguqg8xlg/gemrb-current.png?dl=0
[00:43:19] <Pepelka90> Dropbox - gemrb-current.png
[00:43:29] <brada> hats how maseter compares to original
[00:43:39] <brada> https://www.dropbox.com/s/3cg5at9my4nhver/font-rewrite_original.png?dl=0
[00:43:41] <Pepelka90> Dropbox - font-rewrite_original.png
[00:43:47] <brada> and that is how the font-rewrite branch compares
[00:44:02] <brada> we are pretty much pixel perfect with the original now
[00:47:28] <-- brada has left IRC (Quit: brada)
[00:48:38] --> brada has joined #gemrb
[01:42:47] <-- brada has left IRC (Quit: brada)
[01:43:40] --> brada has joined #gemrb
[01:49:15] <-- brada has left IRC (Quit: brada)
[02:08:46] --> Eli2 has joined #gemrb
[02:55:41] --> brada has joined #gemrb
[03:11:57] --> Eli2_ has joined #gemrb
[03:15:12] <-- Eli2 has left IRC (Ping timeout: 260 seconds)
[05:42:31] <-- brada has left IRC (Quit: brada)
[06:37:15] <-- Lightkey has left IRC (Ping timeout: 265 seconds)
[06:49:42] --> Lightkey has joined #gemrb
[07:56:56] <lynxlynxlynx> brad: what about ] and =? Also, in iwd it prints the dash first, then the icon, then the name (but in the dump it's still [% as expected))
[09:27:09] <edheldil> brad: impressive result
[09:32:31] <-- raevol has left IRC (Quit: Leaving)
[10:38:13] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[10:41:28] --> lynxlynxlynx has joined #gemrb
[10:41:28] <-- lynxlynxlynx has left IRC (Changing host)
[10:41:28] --> lynxlynxlynx has joined #gemrb
[10:41:28] --- ChanServ gives channel operator status to lynxlynxlynx
[11:55:57] <-- cable_ has left IRC (Ping timeout: 272 seconds)
[11:58:10] --> |Cable| has joined #gemrb
[12:06:53] <-- |Cable| has left IRC (Ping timeout: 265 seconds)
[12:19:51] --> |Cable| has joined #gemrb
[12:32:40] <-- |Cable| has left IRC (Ping timeout: 272 seconds)
[12:45:36] --> |Cable| has joined #gemrb
[12:56:45] <-- |Cable| has left IRC (Ping timeout: 260 seconds)
[13:10:10] --> |Cable| has joined #gemrb
[14:19:19] --> brada has joined #gemrb
[15:13:57] <brada> lynx: are you saying those dont work? I didnt test them but on their own they look like they should work examining the code.
[15:14:23] <brada> ed: the most impressive bit was getting that result without 100 hacks :p
[15:14:30] <lynxlynxlynx> no, just asking if you thought about them
[15:14:39] <lynxlynxlynx> but [ is definitely still not ok
[15:14:48] <lynxlynxlynx> it's better, but not perfect
[15:14:56] <lynxlynxlynx> your screenshot doesn't appear to have the same effect btw
[15:15:27] <brada> same effect?
[15:18:43] <brada> but yes its obvious that the ‘[‘ needs to be inserted at the beginning of the token.
[15:19:12] <lynxlynxlynx> same opcode
[15:19:36] <lynxlynxlynx> you probably posted just as a pixel-perfection example for the rest of the window
[15:21:56] <-- Eli2_ has left IRC (Remote host closed the connection)
[15:28:40] <brada> not those were from the same save both taken yesterday
[15:29:29] <brada> we print our effects in a different order if thats what you mean
[15:29:37] <lynxlynxlynx> no, that's obvious
[15:29:49] <lynxlynxlynx> i'm just saying that it doesn't look like you had protection from cold there
[15:29:57] <lynxlynxlynx> resist fire/cold is separate
[15:45:08] <brada> oh, yeah that screenshot wasnt for that purpose as you noticed :)
[15:45:42] <brada> are ‘?’ and ‘=‘ even valid states?
[15:45:49] <brada> seem to be printing a - for me
[15:48:45] <brada> not in bg 2 they arent i guess. first valid state is 65
[15:49:26] <brada> but if they were valid it does appear that they are handled fine
[15:51:44] <lynxlynxlynx> ] is valid
[15:51:59] <lynxlynxlynx> it's 2-4 chars ahead of [
[16:00:40] <lynxlynxlynx> hit that textcontainer assert again
[16:01:47] <lynxlynxlynx> but [ is confirmed ok
[16:02:14] <lynxlynxlynx> ... and i can reliably reproduce it
[16:03:54] <lynxlynxlynx> try creating ring39 and viewing its description in the inventory
[16:04:20] <lynxlynxlynx> i load a save where the pc has this ring of gaxx on and upon right click it goes reliably boom
[16:09:17] <brada> ‘]’ already works
[16:09:26] <brada> yes i see you found that out
[16:09:46] <brada> i will look into that assert
[16:10:18] <lynxlynxlynx> and i have a candy for you
[16:11:25] <brada> oh? yummy!
[16:11:46] <brada> you can probaly comment out that assert. the printout is fine without it
[16:11:57] <brada> for testing i mean if it is holding you back
[16:12:42] <brada> should probably just wrap that assert at least in the debug ifdef
[16:12:48] <brada> since it is actually harmless
[16:13:03] <lynxlynxlynx> if it's harmless, then why not just remove it?
[16:13:15] <lynxlynxlynx> or change it to be an actual problem detector
[16:13:32] <brada> because it means that there is a descrepancy between the calculated layout and the actual space required
[16:14:37] <lynxlynxlynx> then yeah, ifdef it and change it to Log(DEBUG, I guess
[16:16:43] <brada> also i noticed just now a weird problem with the drop caps
[16:17:04] <brada> just scroll a long description, you will see it
[16:17:12] <brada> i wonder when and how that broke
[16:17:12] <lynxlynxlynx> i already told you about it
[16:17:16] <brada> oh
[16:17:27] <brada> still wonder when/how it broke :p
[16:18:03] <lynxlynxlynx> at least a week ago
[16:21:33] <lynxlynxlynx> looking into the bik movie crasher
[16:22:01] <brada> mkay, looks like its time to address that long standing fixme for testing rect intersection for printing instead of point inside
[16:27:05] <lynxlynxlynx> eeh, it's from the old ffmpeg mem.cpp removal
[16:27:23] <lynxlynxlynx> i suspect the freep variant in particular
[16:28:10] <brada> does this work for the IWD2 GUI breakage: http://paste.debian.net/127196/
[16:28:11] <Pepelka90> debian Pastezone
[16:37:20] <lynxlynxlynx> i'll check later
[16:37:35] <lynxlynxlynx> one of the problems was thereabouts though
[16:44:12] <brada> actaully should probably be a space since a null will just not print anything
[17:01:53] <lynxlynxlynx> one or the other trigger an assert
[17:02:09] <lynxlynxlynx> TextArea.cpp:360: void GemRB::TextArea::AppendText(const String&): Assertion `pal == __null && state == TEXT' failed.
[17:03:34] <lynxlynxlynx> well, any character, even !
[17:09:07] <brada> for what?
[17:11:14] <brada> i dont see how seting text on a button will trigger an assert in textarea
[17:11:38] <brada> or a label
[17:17:46] <lynxlynxlynx> talk = store = flag = blank = chr(0)
[17:19:00] <lynxlynxlynx> 238 made me see the window
[17:19:05] <lynxlynxlynx> perhaps the crash is right after it
[17:19:20] <lynxlynxlynx> getting the bt
[17:20:15] <lynxlynxlynx> yeah, displaystring
[17:20:46] <lynxlynxlynx> trying to append L"[color=3D3E3D]"
[17:21:20] <lynxlynxlynx> pal is not NULL
[17:23:41] <lynxlynxlynx> hmm, it starts with a full call, so it looks like the text gets chopped
[17:23:48] <lynxlynxlynx> displaymsg->DisplayConstantStringNameString(STR_USING_FEAT, DMC_WHITE, STR_POWERATTACK, target);
[17:24:52] <lynxlynxlynx> ah no, intentionally just the color
[17:30:51] <lynxlynxlynx> something's wrong with a swprintf call
[17:39:29] <lynxlynxlynx> yeah, instead of populating the whole L"[color=%06X]%s - [/color][p][color=%06X]%s: %s[/color][/p]" it chops it off after the first var
[17:40:11] <lynxlynxlynx> ooh
[17:40:18] <lynxlynxlynx> an error occurs, it returns -1
[17:47:09] <lynxlynxlynx> must be a problem with the size argument again, but i can't get it right
[17:47:44] <lynxlynxlynx> gemrb/core/DisplayMessage.cpp:179
[17:47:54] <wjp> what happens if you just add 1000 or so?
[17:50:39] <lynxlynxlynx> i tried with smaller numbers, but even 1000 doesn't make a difference
[17:51:09] <wjp> the +20 is too small in any case, since DisplayFormatNameString is longer than DisplayFormat by more than that
[17:52:30] <wjp> hm
[17:52:40] <wjp> is text2 empty?
[17:52:53] <lynxlynxlynx> no
[17:53:21] <wjp> DisplayFormatName has a %ls, but it's passing a const char* in that case
[17:53:25] <wjp> but I guess that isn't it, then
[17:53:33] <wjp> (although that still looks fishy)
[17:54:43] <lynxlynxlynx> is there no way to make swprintf tell more about the error?
[17:55:22] <lynxlynxlynx> the man page is useless
[18:03:24] <wjp> is this easy to reproduce?
[18:10:44] <-- brada has left IRC (Ping timeout: 260 seconds)
[18:16:25] <lynxlynxlynx> yes, i just load an iwd2 save and boom
[18:16:40] <lynxlynxlynx> but, it happens because a feat is active
[18:17:05] <lynxlynxlynx> anyway, activating one should do the trick, though i don't remember if we grant them properly
[18:17:18] <lynxlynxlynx> so a save from the original is the best bet
[18:17:39] <lynxlynxlynx> in this case it was Power Attack
[18:22:11] --> brada has joined #gemrb
[18:29:08] <wjp> ah yes, if I start a new game with 'hands of fury' gets you a rapid shot that does it
[18:29:17] <wjp> um, but then in a proper sentence :-)
[18:31:21] <wjp> oh, but that's an overflow here
[18:32:35] <wjp> goes away with +1000
[18:33:59] --> turtleman_ has joined #gemrb
[18:34:30] <wjp> oh, guiscript crash when creating a char in iwd2
[18:35:13] <-- turtleman_ has left IRC (Read error: Connection reset by peer)
[18:40:01] <lynxlynxlynx> haven't explored much at all yet
[18:40:08] <lynxlynxlynx> before this, the gui didn't load
[18:46:05] <wjp> but I get no crash other than this overflow when activating Power Attack
[18:46:52] <lynxlynxlynx> you just added 1000 to newlen?
[18:46:58] <lynxlynxlynx> that's what i did
[18:47:19] <lynxlynxlynx> but our systems are different, as my compiler didn't detect the problems you had the other day
[18:49:54] <wjp> yes, changed the +20 to +1000
[20:07:19] <lynxlynxlynx> brada: regardless, the chr fix is ok and i'll go commit it as you
[20:07:30] <brada> ok sounds good
[20:07:45] <brada> no luck figuring out the other thing?
[20:08:44] <lynxlynxlynx> wjp found a bug thereabouts, but his fix doesn't help me in the first issue
[20:09:04] <lynxlynxlynx> newlen of ~1088 still crashed
[20:09:48] <wjp> just to make sure, you did set it before the malloc?
[20:10:22] <wjp> maybe I'll try valgrind here too
[20:12:40] <wjp> one conditional depending on uninitialized value at Font.cpp:338
[20:12:54] <wjp> but the call stack doesn't seem related
[20:13:02] <lynxlynxlynx> right after it was calculated
[20:14:07] <wjp> what is in the output buffer after it returns -1?
[20:20:16] <lynxlynxlynx> it was still L"[color=3D3E3D]"
[20:21:43] <wjp> hm
[20:21:53] <wjp> so that suggests the next parameter is a problem
[20:23:06] <wjp> which would be 'name'?
[20:26:15] <lynxlynxlynx> it's a czech one
[20:26:37] <wjp> ah, interesting
[20:26:52] <lynxlynxlynx> maybe that \216 in it is problematic
[20:27:27] <wjp> that seems plausible
[20:27:38] <wjp> %s does take a multibyte character sequence
[20:28:07] <brada> wjp: how is that font 338 warning possible?
[20:28:26] <brada> like its going beyond the bounds of string?
[20:28:47] <brada> i would expect an exception if that were the case
[20:29:00] <brada> oh
[20:29:01] <brada> i see
[20:29:14] <brada> its a size_t, so i guess its warning about the -1
[20:29:21] <wjp> no
[20:29:28] <wjp> valgrind doesn't work like that
[20:29:30] <brada> then what is the problem?
[20:29:40] <wjp> and I doubt String does bound checking
[20:30:21] <brada> oh, yes it says undefined behavor :/
[20:32:55] <lynxlynxlynx> wjp: yeah, it works if i take that ž out
[20:34:19] <wjp> right
[20:34:24] <wjp> fun with locales
[20:35:14] <wjp> how do we handle such strings/chars elsewhere?
[20:35:39] <wjp> any conversion functions for game data strings to wchar?
[20:37:23] <lynxlynxlynx> it should work in master, but i don't think displaymessage* used wchar before
[20:37:35] <brada> it didnt
[20:37:52] <brada> the locale conversind should be somewhere in the String.cpp file
[20:38:23] <lynxlynxlynx> well it didn't crash, i don't remember if the string was displayed properly
[20:38:33] <lynxlynxlynx> i've used these saves a lot
[20:38:54] <brada> that char is above 127 probably
[20:39:01] <wjp> so I'm guessing this particular string doesn't go through this function to be properly encoded as mb
[20:40:14] <brada> no
[20:40:44] <brada> dont know why i didnt change that to core->GetString
[20:41:38] <brada> that should pipe it though StringFromCString
[20:41:53] <brada> which does the encoding
[20:41:53] <wjp> by the way, there's also a suspicious %ls in DisplayFormatName
[20:42:49] <brada> why is that suspicious? isnt that the specifier for wide strings?
[20:44:03] <wjp> but it doesn't get a wchar_t* argument, right?
[20:44:15] <brada> i dont know im not looking at code right now
[20:44:51] <wjp> it passes char*'s for this %ls as far as I can tell
[20:44:58] <brada> all this looks like it was done before TLKImporter has support for String
[20:46:07] <brada> it looks like at least one use is char*, yes.
[20:46:18] <brada> but i dont see any reason why all those have to be char* now
[20:46:38] <brada> you can get Strings directly now
[21:38:57] <brada> lynx: does this help? http://paste.debian.net/127245/
[21:38:58] <Pepelka90> debian Pastezone
[21:39:24] <brada> in theory that should handle that encoding
[21:41:30] <brada> some of those format specifiers probably need to be changed
[21:42:04] <brada> er and i dont know why that didnt give me a compile warning
[21:42:34] <brada> or can you implicitly convert String like that?
[21:42:37] <brada> i dont think so
[21:46:50] <lynxlynxlynx> yeah, no dice
[21:48:59] <brada> http://paste.debian.net/127246/
[21:49:00] <Pepelka90> debian Pastezone
[21:49:02] <brada> no dice?
[21:50:07] <brada> well even if it doesnt fix it i should probably still commit it if it didnt break something
[21:52:23] <brada> i’ve no ide what those + 18 and such are for...
[21:52:35] <brada> looks like that is superfolous
[21:53:23] <brada> oh, i guess only a little superfluous :)
[21:53:46] <Lightkey> superfoolus
[21:54:18] <wjp> lengths of numbers; sometimes to handle differences in lengths of formats
[21:54:49] <brada> yeah, thats what i mean by a little bit unnecessary.
[21:55:54] <lynxlynxlynx> no dice
[21:56:45] <lynxlynxlynx> and whatever you end up with, please change the asserts to warnings
[21:57:08] <brada> well, those asserts will crash anyway
[21:57:27] <brada> if the string is null string->length() is surely bad to call
[21:57:47] <brada> so what do we actaully want to do if it is null?
[21:58:08] <brada> warn and return?
[21:58:53] <brada> what are your encoding settings btw?
[21:58:59] <lynxlynxlynx> why is name still a char?
[21:59:22] <lynxlynxlynx> encoding is at default
[22:01:59] <brada> it doesnt have to be a char i dont think. will update
[22:04:03] <brada> oh, it seems it doe still need to be char*
[22:04:13] <brada> speaker->GetName
[22:04:36] <brada> that would have to be converted first
[22:05:19] <brada> seems like that should be easy...
[22:11:57] <lynxlynxlynx> well, probably better to just do it here
[22:12:13] <lynxlynxlynx> there are many uses of that elsewhere
[22:12:19] <brada> sure, that works too
[22:12:24] <brada> also raises a question
[22:12:37] <brada> is the use of GetCString in GetSpeakerColor a leak?
[22:13:06] <brada> al the other assignment cases are to constant strings that shouldnt be freed
[22:13:14] <brada> but that one should be freed
[22:14:24] <brada> oh i guess if that problem you were having was with the character name parts of these then my changes wouldnt affect that anyway.
[22:14:42] <brada> so yes best make that into a String as well
[22:18:06] <lynxlynxlynx> well yeah, did you miss part of the convo?
[22:18:16] <lynxlynxlynx> anyway, zzz time here, see you tomorrow
[22:29:22] <-- exultbot has left IRC (signing off...)
[22:30:38] --> exultbot has joined #gemrb
[22:30:38] --- Topic for #gemrb is: GemRB 0.8.1 | http://gemrb.org | Something wrong? State your exact version and CHECK THE GEMRB LOG | Be wary of your thoughts for there are Illithid present: http://log.usecode.org/gemrblog.php
[22:30:38] --- Topic for #gemrb set by lynxlynx!~quassel@sourcemage/warlock/lynxlynxlynx at Sat May 3 14:59:38 2014
[22:34:07] <brada> heh, yeah, i have been busy doing 3 things at ince today
[23:39:20] <-- brada has left IRC (Quit: brada)
[23:56:20] --> brada has joined #gemrb