#email@example.com logs for 10 Aug 2015 (GMT)Archive Today Yesterday Tomorrow
[01:14:42] --> Eli2 has joined #gemrb
[02:39:34] <-- phao has left IRC (Ping timeout: 245 seconds)
[05:25:25] --> edheldil_ has joined #gemrb
[06:44:11] <-- Lightkey has left IRC (Ping timeout: 246 seconds)
[06:57:00] --> Lightkey has joined #gemrb
[07:21:09] <-- edheldil_ has left IRC (Ping timeout: 250 seconds)
[08:12:55] --> Eli2_ has joined #gemrb
[08:16:07] <-- Eli2 has left IRC (Ping timeout: 264 seconds)
[10:48:36] <Pepelka> [commit] lynxlynxlynx: Map::LoadIniSpawn: pst doesn't use the wed name for lookup https://github.com/gemrb/gemrb/commit/672810b80f14c044a6bfe4b6ee8c7696405d3d74
[10:48:37] <Pepelka> [commit] lynxlynxlynx: pst: added missing file from 3a6f9b289 https://github.com/gemrb/gemrb/commit/ff986d908be0c5013ed1ac3a6bf19988590d09e4
[11:15:42] <-- |Cable| has left IRC (Ping timeout: 240 seconds)
[11:17:54] <lynxlynxlynx> i wonder why we have avatars.2da; except perhaps for ranges, animation.ids looks much saner
[11:20:21] <fuzzie> ..?
[11:20:27] <fuzzie> don't they cover different things?
[11:20:51] <fuzzie> they really do
[11:24:48] <lynxlynxlynx> uhh, animate.ids from pst
[11:25:37] <lynxlynxlynx> http://gibberlings3.net/forums/index.php?showtopic=1818 <-- look at this beauty
[11:25:38] <Pepelka> Resdata Info - IESDP Updates and Info - The Gibberlings Three Forums
[11:25:40] <Pepelka> »Resdata Info - posted in IESDP Updates and Info: ANIMATE.IDS / RESDATA.INIYou'll have to forgive me: I kinda ended up writing this as more of a tutorial becuase it was so complex...sorry.The INI:This INI file may appear to be for refference only, but it is actually the control for Torment's animation structure. Most entries reffer to bam files, while a few reffer to sounds attached to be played during the animation, and when to play it. Confused? This m
[11:25:44] <fuzzie> you mean pst resdata?
[11:25:51] <lynxlynxlynx> yep
[11:26:09] <fuzzie> I wanted to move to that for pst a long time ago, Avenger didn't want I think :)
[11:26:13] <fuzzie> so I approve entirely
[11:26:21] <fuzzie> we already load the file for some of the data anyway
[11:26:49] <lynxlynxlynx> i forgot to ask him if he still manages to use vc6
[11:27:05] <fuzzie> if you do so, or if you don't I guess, I should hack up something to use the extra anims
[11:27:23] <lynxlynxlynx> we lack much of the hardcoded info and avatars.2da will just get crowded or we'll have a bunch of similar extra tables
[11:27:41] <fuzzie> so I think you can actually autogenerate most of the info
[11:27:49] <fuzzie> but I'd rather just use resdata myself
[11:27:53] <lynxlynxlynx> resdata is also more modder / new game friendly
[11:28:06] <fuzzie> so I certainly don't argue :)
[11:28:21] <lynxlynxlynx> generate also resdata? avatars.2da was generated and then patched up as needed
[11:28:48] <lynxlynxlynx> my main gripe is actor speeds that is still missing
[11:28:52] --> |Cable| has joined #gemrb
[11:29:00] <lynxlynxlynx> i'm not sure if we can just use bgee2's table
[11:29:11] <lynxlynxlynx> it would be good for bg2 for sure, but legaly?
[11:29:38] <fuzzie> I think we should not
[11:29:53] <fuzzie> and yes, I guess we could generate something like resdata..
[11:30:05] <fuzzie> opening the bg2 re stuff again is honestly kind of intimidating
[11:30:55] <lynxlynxlynx> i tried hopper, since it works on linux, but it can't read ida stuff
[11:31:21] <lynxlynxlynx> so i was completely lost, mostly a gui for strings
[11:31:34] <fuzzie> it's easy enough to get function names and stuff in
[11:31:50] <fuzzie> but I still didn't buy a copy of Hopper
[11:31:59] <lynxlynxlynx> i haven't done anything like that before, so ... no
[11:32:54] <fuzzie> wow, it's 89eur now? that sure isn't cheap any more
[11:34:02] <lynxlynxlynx> it's free for 30 minutes, but not with all features (debugger?)
[11:34:19] <lynxlynxlynx> 30m sessions
[11:34:33] <fuzzie> but then you might as well use ida :)
[11:35:19] <fuzzie> but the infinity code is pretty horrifyingly complex. not fun to learn with.
[11:36:09] <lynxlynxlynx> i was mostly playing, curious if one of the iwd2 bits was referenced anywhere
[11:36:41] <lynxlynxlynx> oh, ida works on linux too, that's cool
[11:36:58] <lynxlynxlynx> and these nasty constants ...
[11:37:10] <fuzzie> the freeware ida 5.0 runs just fine under wine too
[11:38:01] <fuzzie> well, mostly :)
[11:39:04] <lynxlynxlynx> i may give it a try someday
[11:39:20] <lynxlynxlynx> did you and avenger figure out how to share the dbs effectively?
[11:40:10] <fuzzie> nope, so I just have something random
[11:40:24] <fuzzie> I don't think I even have anything for iwd2
[11:40:42] <fuzzie> "find a way to share ida dbs effectively" is really on my wishlist
[11:40:57] <fuzzie> unfortunately it's aggravated by the fact that you can only upgrade the dbs
[11:41:27] <lynxlynxlynx> upgrade?
[11:41:32] <fuzzie> to newer versions
[11:41:33] <lynxlynxlynx> how big do they grow btw?
[11:41:36] <fuzzie> so my ida 6.8 dbs are not very helpful
[11:41:49] <lynxlynxlynx> oh, no backward compatibility
[11:42:06] <fuzzie> right :/
[11:42:26] <fuzzie> they're not so bad, the bg2 one is <15mb compressed I think
[11:42:35] <lynxlynxlynx> from what i surveyed of the floss disassemblers, most have none or simplistic decompilers
[11:43:00] <fuzzie> yes, well, the hex-rays decompiler is a different story which does not have a demo :)
[11:43:01] <lynxlynxlynx> still sounds reasonable for version control
[11:44:08] <fuzzie> well, it's a compressed blob, so you're basically just making a new version every time, but yes, you could share
[11:45:04] <lynxlynxlynx> mostly for detecting conflicts
[11:45:50] <lynxlynxlynx> anyway, back to animations, resdata does sound cool
[11:46:33] <lynxlynxlynx> kujeger also proved that we don't even use all the orientations (middle ones of the 15 case), so perhaps that's another can of worms waiting
[11:47:01] <lynxlynxlynx> resdata would also solve all the tiny deviations that now require separate animation types
[11:47:10] <lynxlynxlynx> too bad i didn't look at pst earlier :s
[12:12:09] <edheldil> but has resdata.ini all the info we need on pst? Or would we have to have our own?
[12:14:28] <kujeger> I'm not sure I technically proved that the animations aren't used at all, more that the pathfinding will only send characters along stright diagonal lines
[12:50:06] <lynxlynxlynx> yes, that means not all animation paths are exercised
[12:50:28] <lynxlynxlynx> we do take all orientations into account, but again, deviations from the model can't show up if we don't draw them
[12:51:14] <kujeger> yeah, true. It *might* work perfectly once the pathfinder sends them along the new orientations, but we'd never know
[12:51:32] <kujeger> until then
[12:51:35] <lynxlynxlynx> edheldil: it has more than we have now
[12:52:13] <lynxlynxlynx> i think only circle size is missing
[12:54:32] <lynxlynxlynx> what i was saying initially was: why wasn't this system used for dehardcoding other games too?
[12:54:55] <lynxlynxlynx> hit sounds, get hit sounds, walk and run speed, frame-level timing ...
[12:55:01] <edheldil> hehe, because I used to be the only one caring about pst :)
[12:55:40] <lynxlynxlynx> to be honest, i don't know what bit me :)
[12:55:55] <lynxlynxlynx> once i'm done with the blockers, we'll need another chiv-type to test the game again
[12:56:07] <lynxlynxlynx> maybe it's already completable now
[12:56:31] <lynxlynxlynx> so for "story-mode" type of players, we're almost set
[13:18:19] --> phao has joined #gemrb
[13:55:44] <-- phao has left IRC (Ping timeout: 264 seconds)
[15:07:46] --> phao has joined #gemrb
[15:44:57] <-- phao has left IRC (Ping timeout: 240 seconds)
[16:03:51] --> phao has joined #gemrb
[16:15:32] <lynxlynxlynx> fuzzie: do you remember anything about timers as in timeractive / timerexpired?
[16:15:57] <lynxlynxlynx> it seems to be the reason for a lot of grief in iwds and now a great case in pst
[16:16:21] <lynxlynxlynx> seems like they should be ticked off with time like the rest of scripting counters
[16:17:27] <lynxlynxlynx> some scripts use only starttimer and then startactive (which only checks if the timer ever started); expiry is now only handled in the timerexpired trigger, which is not used everywhere
[16:17:47] <lynxlynxlynx> aliasing timeractive to timerexpired creates new issues though
[16:25:24] <lynxlynxlynx> just not sure if we should be counting down all the time or take into account staggering (that globalid ugly from the original)
[16:32:59] <lynxlynxlynx> eh, let's just see what happens
[16:41:54] <-- phao has left IRC (Ping timeout: 260 seconds)
[16:47:10] <lynxlynxlynx> oh yes, this is goood
[16:53:21] --> brada has joined #gemrb
[17:14:05] <-- brada has left IRC (Quit: brada)
[17:15:11] <Pepelka> [commit] lynxlynxlynx: fixed TimerActive by also ticking off timers with time (sound obvious huh?) https://github.com/gemrb/gemrb/commit/296a7f5b90b32fd9ff9e5c11df8a3aefcc73db7d
[17:15:12] <Pepelka> [commit] lynxlynxlynx: converted script_timers to a leaner std::map https://github.com/gemrb/gemrb/commit/1014a3a2bcd43177ba91904e0bd969f8037f4884
[17:15:35] --> brada has joined #gemrb
[17:17:00] <brada> lynx: i have pst with me if you want to walk me though where i can see the labels getting clipped
[17:22:41] <lynxlynxlynx> oh hi
[17:23:16] <lynxlynxlynx> mta("ar0704")
[17:23:22] <lynxlynxlynx> talk to the barkeep
[17:23:24] <lynxlynxlynx> agree, quit
[17:23:30] <lynxlynxlynx> talk again and you can access the store
[17:23:52] <lynxlynxlynx> unlike for buttons, we currently have no mechanism for toggling single/multiline
[17:24:01] <lynxlynxlynx> or any other font flag for that matter
[17:24:38] <brada> well there is IE_FONT_SINGLE_LINE
[17:24:50] <lynxlynxlynx> ups, wrong store
[17:25:08] <lynxlynxlynx> 0504
[17:25:33] <lynxlynxlynx> behind the second counter
[17:28:41] <lynxlynxlynx> got it?
[17:28:42] <brada> how do you teleport?
[17:28:48] <brada> im stuck lol
[17:28:55] <lynxlynxlynx> ctrl-j
[17:29:19] <lynxlynxlynx> unlike the other games (at least bgs), pst has the label text centered
[17:30:30] <brada> ok the store is Anze’s Anvil?
[17:30:51] <brada> yup i see it now
[17:31:30] <lynxlynxlynx> i said we don't do multiline centering, as one of the code comments was to that effect (and that's how it looks)
[17:31:58] <lynxlynxlynx> the original handles it nicely and the end effect is coincidentally just like reverting to top alignment
[17:32:22] <lynxlynxlynx> this can be hacked in at guiscript level, but i consider it an engine bug
[17:32:38] <lynxlynxlynx> the store has no clue where to wrap, so it would have to be a guess anyway
[17:38:24] <brada> lynx: where is that comment?
[17:38:44] <brada> we most certainly do support multiline centering. see the BG2 loading screen
[17:39:06] <brada> the problem here is that there isnt technically enough space for 2 lines
[17:39:08] <lynxlynxlynx> don't remember, but it was probably near single/multi bit
[17:39:23] <brada> the label is 25px high, but the font lineheight is 13 px
[17:39:58] <lynxlynxlynx> eh
[17:39:59] <brada> so we are 1 px short
[17:40:26] <lynxlynxlynx> we can't grow it automatically?
[17:41:40] <brada> not really. it is the height of the control. the call to font::print passes the area the font is allowed to print to
[17:43:22] <lynxlynxlynx> lineheight is calculated from the font size?
[17:44:29] <brada> lineheight is a font property, yes.
[17:44:42] <lynxlynxlynx> we already have a GetRect method exposed in GUIScript, I guess adding a writable one is the only sane choice
[17:45:09] <lynxlynxlynx> for that height += 1
[17:45:19] <brada> im not 100% sure that will fix it, but it was my first observation
[17:45:41] <lynxlynxlynx> try changing it mid session
[17:46:00] <brada> is the comment you are talking about the one that says that vertical alignment isnt handled *here*?
[17:47:26] <brada> it does indeed seem to fix it :)
[17:48:11] <brada> if not then i imagine its an outdated comment from before the rewrite
[17:48:18] <brada> we didnt used to support it
[17:48:33] <brada> I had to add 2 px tho...
[17:48:43] <brada> so maybe there is a bug it a calculation
[17:48:49] <brada> rounding error
[17:49:08] <lynxlynxlynx> interline spacing?
[17:49:21] <brada> oh maybe
[17:49:39] <brada> that would make sense i think
[17:50:35] <lynxlynxlynx> well, still 1px too many
[17:50:36] <lynxlynxlynx> i'll do the guiscript workaround later
[17:51:15] <lynxlynxlynx> one thing that isn't a bug, just a nuisance (not new either) is that we can't attach scrollbars to labels
[17:51:26] <lynxlynxlynx> we can, but since we ignore them for interaction, it is useless
[17:51:49] <lynxlynxlynx> the result is that you can only mouse scroll the left store inventory, since it has the default scrollbar — but not your own
[17:52:11] <brada> oh, well dont worry about that. the branch ive been developing that redid the view hierachy fixes that
[17:52:12] <lynxlynxlynx> do you have any ideas on how to tackle that, except by replacing all those labels with buttons?
[17:52:27] <lynxlynxlynx> interesting
[17:52:41] <lynxlynxlynx> what did you do?
[17:52:59] <brada> now it scrolls the control the mouse is over.
[17:53:30] <brada> of course im not sure how the stores are implemented
[17:53:55] <lynxlynxlynx> labels are ignored for clicks etc., i'm not sure this will work
[17:54:18] <lynxlynxlynx> it would break all those cases where we create extra labels over buttons, since they would steal the event
[17:54:46] <brada> it wont steal the event if it doesnt respond to it :)
[17:55:06] <brada> the event will bubble out until something responds to it
[17:55:30] <brada> so it would hit the label, but label would ignore it so it does to the labels parent view etc until something responds
[17:56:38] <brada> currently, gemrb has no concept of views within views so that doesnt work
[17:56:47] <lynxlynxlynx> but it will respond to this scroll related focus tracking?
[17:57:10] <lynxlynxlynx> i don't think we have cases where controls would compete for that, which is nice
[17:57:43] <lynxlynxlynx> view hierarchy; sounds like something that could fix the fflickering? :)
[17:57:48] <brada> the stores might need special attention, because i imagine they are implemented in a goofy way where its not really scrolling anything
[17:58:06] <lynxlynxlynx> yes, we manually attach scrollbars to controls
[17:58:20] <brada> but it works nicely in game view so you dont have to keep focusing controls to scroll them
[17:58:28] <brada> one of my biggest annoyances with gemrb ha ha
[17:58:51] <brada> i need to find time to work out the remaining kinks in that branch...
[17:59:47] <lynxlynxlynx> well, my todo page has a nice little section for you
[18:00:14] <lynxlynxlynx> didn't update it with today's findings yet, but you can find more info on what's still wrong there wrt text
[18:00:18] --> fizzle has joined #gemrb
[18:00:37] <lynxlynxlynx> hey fuzzie
[18:00:41] <lynxlynxlynx> hey fizzle :)
[18:01:06] <brada> ok ill look at it
[18:01:55] <lynxlynxlynx> contingencies are a bg2 thing btw
[18:02:11] <lynxlynxlynx> best if you start tob with a sorcerer and mind what you choose during char creation
[18:02:13] <brada> maybe an alternative to hacking via guiscript would be to do a calculation in the label constructor to round up to the nearest line?
[18:02:39] <lynxlynxlynx> sounds cleaner
[18:02:40] <brada> or
[18:02:47] <brada> not in the label but in the chuimporter?
[18:02:57] <brada> since it feels (to me) like a data bug
[18:03:18] <lynxlynxlynx> chuimporter has no clue what contents there will be
[18:03:40] <lynxlynxlynx> they're from stoimporter and finally assembled in guiscript
[18:03:54] <fizzle> hey
[18:04:53] <brada> oh, well then
[18:07:05] <lynxlynxlynx> label constructor wouldn't know either, unless a hint was passed
[18:07:25] <lynxlynxlynx> oh, is the multiline font flag set on those labels?
[18:07:37] <lynxlynxlynx> then it could just branch on that
[18:07:48] <lynxlynxlynx> multiline means at least two lines
[18:11:39] <brada> ok, so in the guiscript CreateLabel we check the alignment and if the single line flag is not set, then we force the label to at least 2 lines high?
[18:12:20] <brada> or in the label ctor?
[18:12:37] <lynxlynxlynx> ctor, CreateLabel is only used for manually created labels
[18:12:55] <brada> I thought you said that these were assembled in the guiscript?
[18:13:04] <lynxlynxlynx> just the text contents
[18:13:10] <lynxlynxlynx> since the price depends on a lot of stuff
[18:13:54] <brada> hmmm
[18:15:06] <lynxlynxlynx> you could also do it on flag setting
[18:15:25] <lynxlynxlynx> we'd need those font flags exposed to the rest of the controls sooner or later
[18:19:57] <brada> the other controls seem to determine their font alignments though other flags…
[18:20:18] <brada> so this could probably be simplifies alot
[18:20:57] <brada> jsut have one set of alignment flags
[18:21:27] <brada> instead of a set for font, a set for button, and likely a set for something else
[18:22:44] <brada> and personally id rather have it so that mutually exclusive flags combined mean center
[18:23:01] <brada> so setting top&bottom means middle and left&right mean center
[18:24:06] <brada> anyway, currently, using the ctor wont work because the CHUImporter overwrites the alignment after construction
[18:24:11] <lynxlynxlynx> they're separate, since they're that way in the chu
[18:24:20] <lynxlynxlynx> but this could be handled in the importer
[18:24:38] <brada> and im not sure how big of a fan i am of setting alignment changing the control dims
[18:25:26] <brada> i think thats what i would rather do, since again i view this as a bug in CHU data. with the exception of maybe that 1px for line spacing…
[18:26:02] <brada> but IIRC those screenshot overlays i did in BG2 required it to be pixel perfect...
[18:26:13] <brada> maybe PST is just diffrent in that regard
[18:26:58] <lynxlynxlynx> still would be 1px off
[18:28:16] <brada> ?
[18:28:51] <brada> is pst the only case we know of with this btw?
[18:30:40] <lynxlynxlynx> i'd have to google for store screenshots
[18:30:52] <lynxlynxlynx> bgs definitely use top alignment in stores
[18:31:07] <lynxlynxlynx> pretty sure iwd too, just not about iwd2
[18:31:54] <brada> i meant any other labels being clipped that we know of
[18:35:39] <lynxlynxlynx> tooltip text, but that's different
[18:37:13] <lynxlynxlynx> can't remember anything else
[18:37:34] <lynxlynxlynx> oh, maybe item names in iwd2 description window
[18:52:12] <brada> im hoping that the comparison on Font.cpp line 634 should jsut be >
[18:52:33] <brada> maybe that would fix that assert error i hid
[18:52:46] <brada> but its also why i had to add 2 px instead of 1
[18:55:04] <brada> lynx: did you want to test drive this first, or should i just commit it?
[18:55:47] <lynxlynxlynx> you can just commit it if it doesn't cause any immediate issues for you
[19:04:08] <-- Drakkar has left IRC (Ping timeout: 264 seconds)
[19:04:56] --> Drakkar has joined #gemrb
[19:05:17] <lynxlynxlynx> oh, one other odd thing, sometimes infopoint text shows markup
[19:05:30] <lynxlynxlynx> it's still correctly colored, but you can see the tags
[19:08:32] <Pepelka> [commit] bradallred: Font: StringSize should allow another line as long as it doesnt *exceed* stop->h https://github.com/gemrb/gemrb/commit/f52968d7cd9b7f10ec7037b4c15e42904b301f89
[19:08:34] <Pepelka> [commit] bradallred: Label: try to hack around bad data causing PST store labels to be clipped https://github.com/gemrb/gemrb/commit/7cfb4058c1cf3c0853db96c17b208baf1c52afbf
[19:08:48] <brada> lynx: how could i reproduce that?
[19:09:27] <lynxlynxlynx> lemme check
[19:10:15] <lynxlynxlynx> ar0500
[19:10:39] <lynxlynxlynx> center of the area, a bit to the north are large gates to the foundry
[19:10:41] <lynxlynxlynx> locked
[19:10:45] <lynxlynxlynx> if you click on them ...
[19:12:10] <brada> let me know if that StringSize change broke anything…
[19:13:07] <brada> off to class now
[19:13:10] <-- brada has left IRC (Quit: brada)
[19:23:15] <lynxlynxlynx> i have a feeling the font bam is green
[19:24:09] --> edheldil_ has joined #gemrb
[20:02:50] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[20:08:56] --> edheldil_ has joined #gemrb
[20:20:28] <lynxlynxlynx> ok wtf
[20:21:06] <lynxlynxlynx> a script has a bunch of True() triggered blocks and we run the last one and last one only :s
[20:23:44] <edheldil_> is not there some lut table indexed by condition?
[20:24:16] <lynxlynxlynx> lut?
[20:24:50] <lynxlynxlynx> btw, pst has disabled lua
[20:25:06] <edheldil_> lookup table
[20:25:20] <lynxlynxlynx> lookup table table?
[20:25:40] <edheldil_> pleonasm, I know
[20:25:53] <lynxlynxlynx> btw2, i pushed some more iesh stuff today
[20:26:03] <lynxlynxlynx> i don't think sf's commit mails work anymore
[20:26:06] <edheldil_> Noticed
[20:26:20] <edheldil_> well, I got one
[20:26:35] <lynxlynxlynx> maybe i'm subscribed with the sf address then
[20:27:00] <lynxlynxlynx> anyway, what would a lut have to do with the problem? All the conditions are the same
[20:31:37] <edheldil_> I meant whether gemrb perhaps does not parse the scripts into some table indexed with the condition, so that only the last record is pointed to...
[20:32:50] <fuzzie> lynxlynxlynx: w/Continues? how do you tell?
[20:33:12] <lynxlynxlynx> no continue, but different cutsceneids in all blocks
[20:33:38] <lynxlynxlynx> there's another similar case, but this one has trivial triggers
[20:34:03] <lynxlynxlynx> http://paste.debian.net/291099/
[20:34:04] <Pepelka> debian Pastezone
[20:34:34] <Pepelka> [commit] bradallred: DisplayString: Only TextAreas support markup https://github.com/gemrb/gemrb/commit/81d17ac2a018db932b32932fe6df18dd63b28dcc
[20:35:10] <lynxlynxlynx> class huh :)
[20:36:20] <lynxlynxlynx> hmm, breaking on True doesn't even hit it anywhere near the cutscene start
[20:38:30] <fuzzie> but it does hit it?
[20:38:47] <lynxlynxlynx> on area load, but those are surely other scripts
[20:39:39] <lynxlynxlynx> aha, it doesn't even start
[20:39:44] <lynxlynxlynx> ok, that's good, phew
[20:40:20] <lynxlynxlynx> it's found in the data though, investigating
[20:40:40] <fuzzie> how are you checking?
[20:43:48] <lynxlynxlynx> following the previous cutscene, now i'm looking where it goes wrong
[20:43:59] <lynxlynxlynx> so far the startcutscene(thisone) looks ok
[20:44:15] <lynxlynxlynx> all response blocks are there
[20:45:34] <lynxlynxlynx> ah, can't find the target in ExecuteAllBlocks
[20:45:51] <lynxlynxlynx> they're spawned by the area ini, but apparently not yet
[20:50:27] <-- fizzle has left #gemrb
[20:52:43] <lynxlynxlynx> hmm, only their interval delay looks suspect so far, as the area script can reset their trigger global if they're too slow
[21:06:02] <lynxlynxlynx> i bet this is just the "run area scripts during cutscenes" gameflag
[21:06:08] <lynxlynxlynx> it was set for pst on a guess
[21:08:53] <lynxlynxlynx> hmpf, no effect
[21:10:18] <ebarrett> hey
[21:12:09] * ebarrett clones gemrb master
[21:14:32] <lynxlynxlynx> well, the var is set properly before the cutscene starts, but then the last block resets it to zero
[21:14:44] <lynxlynxlynx> something's amiss, but too late for today
[21:16:09] <ebarrett> lynxlynxlynx: going to bed?
[21:16:16] <Lightkey> <lynxlynxlynx> we already have a GetRect method
[21:16:20] <Lightkey> ☑ awesome!
[21:17:40] * ebarrett wonders why -DDISABLE_WERROR=1 is needed to build gemrb on openbsd...
[21:25:07] <lynxlynxlynx> not yet
[21:25:23] <lynxlynxlynx> that switch is on by default on non-release builds
[21:25:39] <lynxlynxlynx> what compiler are you building with?
[21:26:05] <ebarrett> lynxlynxlynx: i think gcc-4.2
[21:26:28] <ebarrett> admittedly i didnt make a release build
[21:26:29] <lynxlynxlynx> gcc --version
[21:26:50] <ebarrett> gcc (GCC) 4.2.1
[21:27:00] <lynxlynxlynx> ok
[21:27:06] <lynxlynxlynx> what warnings did you get?
[21:27:25] <lynxlynxlynx> and you went to github for the code, right?
[21:28:02] <ebarrett> cc1plus: warning: command line option "-Wmissing-declarations" is valid for C/ObjC but not for C++
[21:28:07] <ebarrett> code from GH, yup
[21:28:35] <lynxlynxlynx> that's the only one?
[21:28:43] <ebarrett> so far (tm)
[21:31:10] <ebarrett> lynxlynxlynx: btw, master seems to work bar that
[21:31:17] <ebarrett> the text is a bit screwed up in the menus
[21:32:55] <lynxlynxlynx> which game?
[21:33:18] <lynxlynxlynx> are you using any special tlks (language packs)?
[21:34:22] <ebarrett> lynxlynxlynx: https://farm1.staticflickr.com/304/20280430710_ed31c120e7_o.png
[21:34:26] <ebarrett> bg1
[21:34:32] <ebarrett> same confiug i used with 0.8.3
[21:34:47] <ebarrett> apart from some paths tweaked to run from /opt instead of from /usr/local
[21:35:21] <lynxlynxlynx> looks fine here on an old build, so perhaps it was today's change
[21:35:45] <ebarrett> i guess this stuff is hard to unit test
[21:36:13] <ebarrett> lynxlynxlynx: i can rewind a day
[21:36:13] <lynxlynxlynx> yep, it's that thing
[21:36:29] <lynxlynxlynx> nah
[21:36:53] <lynxlynxlynx> it's probably that center|middle line in the constructor
[21:37:00] <lynxlynxlynx> guirec shows more problems
[21:37:46] <ebarrett> guirec?
[21:38:02] <ebarrett> i'm happy to report, it builds with bsdmake
[21:38:10] <ebarrett> so many projects dont accept bsdmake
[21:39:49] <lynxlynxlynx> character statistics screen
[21:39:55] <ebarrett> ah
[21:39:58] <lynxlynxlynx> "records window"
[21:40:08] <ebarrett> i rewound to 76ae04d467a2cefb2bbf8a0972f2bce3c170c01e and it's ok
[21:40:37] <lynxlynxlynx> f52968d7cd9b should be enough
[21:41:24] <ebarrett> lynxlynxlynx: i know this question sucks, but any tips on how to win fights in bg1?
[21:41:32] <ebarrett> it's either really hard, or i suck
[21:42:39] <lynxlynxlynx> it can be hard, since you have low hp, especially if you're not a fighter or optimized
[21:42:47] <lynxlynxlynx> ranged weapons come very handy
[21:43:12] <ebarrett> maybe i should get some of those
[21:43:20] --> brada has joined #gemrb
[21:43:22] * ebarrett plays some more
[21:43:28] <ebarrett> lynxlynxlynx: catch you later
[21:43:34] <lynxlynxlynx> zzz
[21:48:26] <Pepelka> [commit] bradallred: DisplayString: print message to both the label and textarea if they both exist https://github.com/gemrb/gemrb/commit/1ef7fdae5d036065888d712a6e20d9370ecb7307
[21:50:30] <lynxlynxlynx> brada: there's a problem with the label hack
[21:50:48] <brada> with the label hack, or the StringSize thing?
[21:51:33] <lynxlynxlynx> i didn't investigate yet, ebarrett just found it
[21:52:02] <lynxlynxlynx> bg1 save window and more guirec labels are now misaligned
[21:52:17] <lynxlynxlynx> there's actually more clipping now due to that
[21:52:30] <brada> hmmm
[21:54:45] <brada> lynx: ok, it is the label hack
[21:54:59] <brada> not sure how to best resolve that
[21:55:25] <brada> maybe also exclude topalingment...
[22:12:43] <brada> committed a hack for the hack :)
[22:12:43] <Pepelka> [commit] bradallred: Label: previous multiline hack broke some things https://github.com/gemrb/gemrb/commit/2b530c051d11631ffbcbf1e97d3d645e1c9f3dca
[22:33:47] <-- edheldil_ has left IRC (Ping timeout: 244 seconds)
[22:53:46] <ebarrett> i also notice that sometimes store windows dont appear, but the game thinks you are in a store, meaning you cant save
[22:53:51] <ebarrett> doesn't happen every time
[22:53:56] <ebarrett> fwiw, i was in nashkar
[22:54:04] <ebarrett> happening in the inn and in the store there
[22:55:34] <brada> its not clear if you mean that you are actually in a store but the window is borked, or that you are not actually in a store
[22:56:59] <ebarrett> you ask the inkeep what he has, then the window for the store doesnt appear
[22:57:21] <ebarrett> you can move around the map, but 'q' doesnt work, nor save via the menu, as "you cant save in a store"
[22:57:34] <ebarrett> that's with git head
[22:57:37] <brada> right, so you are in a store then
[22:57:49] <brada> what console errors do you get?
[22:57:53] <ebarrett> right, just the window didnt show
[22:57:54] <brada> speciffically python
[22:58:04] <ebarrett> ah, let me check scrollback
[22:59:08] <ebarrett> no tracebacks in my scrollback
[22:59:19] <ebarrett> next time it happens, I will look closer
[22:59:31] <brada> can you give me the area number for that store?
[22:59:43] <ebarrett> how can I find it?
[22:59:56] <brada> i think hitting the ‘x’ key while not in any windows
[23:00:16] <brada> should print it to either the message text area, or the console. dont recall which
[23:01:54] <ebarrett> sadly not
[23:03:27] <ebarrett> [ResourceManager]: Searching for 'ar4803'...
[23:03:30] <ebarrett> maybe here
[23:03:39] <ebarrett> this is the store in nashkell perhaps
[23:03:46] <ebarrett> i've seen the issue here
[23:05:55] <brada> ebarrentt: that store works fine for me
[23:06:31] <ebarrett> it doesn't always happen
[23:06:33] <brada> so i would suspect your python scripts maybe arent upto date, or something else python related
[23:06:38] <brada> oh?
[23:06:50] <ebarrett> i've not figured out what causes it
[23:06:50] <brada> do you have a method that can reliably reproduce?
[23:06:54] <ebarrett> nope
[23:06:55] <brada> i see
[23:07:01] <ebarrett> mabe undefined behaviour
[23:07:10] <brada> still would keep an eye on the console when it happens
[23:07:14] <ebarrett> yip
[23:07:16] <ebarrett> will do
[23:07:30] <brada> I also notice you said you were using a really old version of gcc…
[23:07:50] <ebarrett> well, it's openbsd's fork of gcc
[23:08:05] <ebarrett> there's a new gcc in ports, which I could use
[23:09:34] <ebarrett> anyways, i need to zzz
[23:09:37] <ebarrett> catch you later
[23:10:44] <ebarrett> i just realised I have no malloc flags on. next time I play, I will crank them and see if we find any memory errors
[23:14:46] --> phao has joined #gemrb
[23:35:50] <-- phao has left IRC (Ping timeout: 250 seconds)
[23:56:10] --> phao has joined #gemrb