#gemrb@irc.freenode.net logs for 17 Oct 2014 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:17:43] <Lightkey> Enhanced Edition Baldur's Gates are on GOG.com now
[00:45:28] <brada> oh nice, even the mac version
[00:45:35] <brada> on sale too
[00:48:07] <-- brada has left IRC (Quit: brada)
[01:08:45] --> brada has joined #gemrb
[01:20:18] <-- brada has left IRC (Quit: brada)
[02:12:50] --> Eli2 has joined #gemrb
[02:45:12] --> raevol has joined #gemrb
[03:15:20] <-- Eli2 has left IRC (Ping timeout: 260 seconds)
[03:15:27] --> Eli2_ has joined #gemrb
[06:36:57] <-- Lightkey has left IRC (Ping timeout: 272 seconds)
[06:49:12] --> Lightkey has joined #gemrb
[08:51:44] <-- raevol has left IRC (Quit: Leaving)
[14:24:49] --> brada has joined #gemrb
[14:26:04] <brada> lynx: did that last commit fix the charname issue?
[14:34:03] <edheldil> Hi, brada
[14:40:38] <lynxlynxlynx> yes
[14:42:06] <brada> nice
[14:42:09] <brada> hey ed
[14:50:26] --> NoseGoth has joined #gemrb
[14:52:34] <-- Drakkar has left IRC (Ping timeout: 258 seconds)
[15:26:35] --> maighstir has joined #gemrb
[15:53:06] <-- Eli2_ has left IRC (Remote host closed the connection)
[17:09:07] <brada> :/ lousy OS X update moved libpng again
[17:21:22] <lynxlynxlynx> is it just me or is github pretty random about sending commit emails?
[17:51:52] <brada> i dont think it sends emails for commits to secondary branches does it?
[17:52:21] <brada> i seem to always get them for commits to master, but never for other branches. on any of my projects, not just gemrb
[18:19:39] <lynxlynxlynx> but your last commit was not to master, was it?
[18:20:08] <lynxlynxlynx> i received about every other and i haven't touched master
[19:15:58] <brada> lynx: on your wiki there is an item: “what happens if choices don't fit into the window (eg. pst)?”
[19:16:09] <brada> is there an actuall issue behind that? or just something to check?
[19:16:16] <brada> afik that should work fine
[19:16:21] <lynxlynxlynx> just check
[19:16:31] <lynxlynxlynx> i wonder where it is anchored for example
[19:18:52] <brada> it shoudl be anchored so the top of the last dialog “node” is at the top of the TA and you would have to scroll down to see options that dont fit in the remaining space
[19:19:14] <brada> i tested that part at the time (tho who knows if it has broken since)
[19:20:45] <brada> I tested by adding a bunch of duplicate options, but i didnt test with some huge dialog node that would take up the entire height by itself, so that might be worth looking into
[19:21:42] <lynxlynxlynx> none exist
[19:22:04] <brada> didnt test at all with PST either tho. and if that does dialog a bit diffrentlyly then im not sure what to expect
[19:22:42] <lynxlynxlynx> it's just the only one i remembered that for sure had more options than fit into a screen
[19:23:21] <lynxlynxlynx> oh, wrt that charsPrinted assert: it's also trivially triggerable through iwd2
[19:23:36] <lynxlynxlynx> there guirec is enough for me
[19:24:02] <brada> interesting
[19:24:11] <brada> probably something simple
[19:24:13] <lynxlynxlynx> if the item description one is caused by too big item illustrations, i think those just got clipped
[19:24:41] <brada> no that wouldnt cause a problem
[19:25:11] <brada> more likely some special series of characters or a single special character that isnt handled correctly
[19:25:17] <brada> \t perhapps
[19:25:35] <brada> or possibly contiguous whitespace chars
[19:26:36] <brada> in the GUIREC i suppose it is possible that a single word is overrunning the available width
[19:26:49] <brada> that would cause something to break for sure
[19:26:53] <brada> there is a fixme about that
[19:27:11] <lynxlynxlynx> it has contiguous spaces for sure; many items use them for formatting
[19:27:34] <lynxlynxlynx> iwd2 guirec is much wider, so that would be odd
[19:37:40] <wjp> oh, one of the newlens is too short
[19:38:31] <brada> :/
[19:38:35] <brada> fix it?
[19:38:41] <wjp> just about to commit
[19:38:45] <brada> and is it truely too short?
[19:39:01] <wjp> there's no +constant to compensate for the expanded numbers
[19:39:27] <brada> sure, but technically speaking doesnt the extra space from the format specifiers compensate for that?
[19:39:39] <brada> but yes jsut add a know to be long enough constant
[19:39:49] <wjp> oh, the %ls's?
[19:40:09] <wjp> hm. I suppose you're right
[19:40:12] <brada> yeah :)
[19:40:28] <wjp> right, there are enough of those in there it seems
[19:40:55] <brada> right, but there is nothing wrong with adding a constant since technically we may change the format string at anytime blah blah
[19:42:16] <brada> at the very least, relying on that should have come with a comment
[19:55:01] <lynxlynxlynx> pst journal also triggers the same assert
[20:02:49] <brada> pretty clear it must be just some char/sequence then
[20:04:37] <brada> it doesnt look like Font::RenderLine handles contiguous whitespace so thats at least part of it
[20:05:10] <brada> Font::SizeString does appear to deal with contiguous whitespace so indeed that would explain a descrepancy
[20:06:14] <brada> i may be wrong about RenderText not dealing wiht it, but its easy to test
[20:07:43] <brada> neither appear to make a special case for \t so that might be a better place to start poking
[20:10:30] <lynxlynxlynx> grepping over a hexdump of iwd's dialog.tlk gives me almost 2k lines with tabs in them
[20:12:27] <lynxlynxlynx> mostly noise though
[20:14:33] <brada> does the BAM even have a tab?
[20:23:49] <brada> if not i will need to fabricate one
[20:35:41] <lynxlynxlynx> no idea
[20:35:49] <lynxlynxlynx> make sure tabs are a problem first
[20:35:58] <lynxlynxlynx> i didn't find anything concrete that would use them
[20:55:37] --> Eli2 has joined #gemrb
[21:18:30] --> nutron has joined #gemrb
[22:18:58] --> raevol has joined #gemrb
[23:32:42] <-- brada has left IRC (Quit: brada)