#gemrb@irc.freenode.net logs for 20 Mar 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:05:29] --> Fuzzlix has joined #gemrb
[00:06:50] <-- Fuzzlix__ has left IRC (Ping timeout: 240 seconds)
[00:06:53] --- Fuzzlix is now known as Fuzzlix__
[00:57:06] --> brada has joined #gemrb
[01:41:07] <gembot> build #534 of cmake clang++ is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/534 blamelist: Brad Allred <bradallred@me.com>
[01:48:12] <gembot> build #534 of cmake g++-4.4 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4/builds/534 blamelist: Brad Allred <bradallred@me.com>
[01:50:37] <gembot> build #533 of cmake g++-4.6 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.6/builds/533 blamelist: Brad Allred <bradallred@me.com>
[01:53:55] <gembot> build #518 of cmake g++-4.5 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.5/builds/518 blamelist: Brad Allred <bradallred@me.com>
[01:56:43] <gembot> build #321 of msvc++6 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/321 blamelist: Brad Allred <bradallred@me.com>
[01:58:38] <gembot> build #535 of cmake clang++ is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/535
[02:01:07] <-- brada has left IRC (Quit: brada)
[02:01:37] --> brada has joined #gemrb
[02:02:12] <gembot> build #315 of nmake-msvc++6 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B6/builds/315 blamelist: Brad Allred <bradallred@me.com>
[02:08:53] <gembot> build #535 of cmake g++-4.4 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4/builds/535
[02:09:20] <gembot> build #379 of nmake-msvc++10 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B10/builds/379 blamelist: Brad Allred <bradallred@me.com>
[02:09:28] <-- brada has left IRC (Quit: brada)
[02:12:43] <gembot> build #534 of cmake g++-4.6 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.6/builds/534
[02:16:49] <-- Fuzzlix__ has left IRC (Ping timeout: 240 seconds)
[02:17:39] <gembot> build #519 of cmake g++-4.5 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.5/builds/519
[03:26:08] --> brada has joined #gemrb
[04:53:51] <-- brada has left IRC (Quit: brada)
[05:17:21] <gembot> build #380 of nmake-msvc++10 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B10/builds/380
[05:33:18] <gembot> build #323 of msvc++6 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/323
[05:44:39] <gembot> build #316 of nmake-msvc++6 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B6/builds/316
[06:26:34] <-- muriani has left IRC (Ping timeout: 260 seconds)
[06:28:46] --> muriani has joined #gemrb
[08:01:32] --> lynxlynxlynx has joined #gemrb
[08:01:32] <-- lynxlynxlynx has left IRC (Changing host)
[08:01:32] --> lynxlynxlynx has joined #gemrb
[08:01:32] --- ChanServ gives channel operator status to lynxlynxlynx
[08:31:59] --> WingedHussar has joined #gemrb
[10:24:22] --> Fuzzlix__ has joined #gemrb
[10:24:30] --- Fuzzlix__ is now known as Fuzzlix
[10:31:37] --> fizzle has joined #gemrb
[11:12:15] <-- WingedHussar has left IRC (Ping timeout: 260 seconds)
[11:13:02] --> WingedHussar has joined #gemrb
[11:19:10] --> traveler has joined #gemrb
[11:19:19] <traveler> eh
[11:19:23] <traveler> strange build errors
[11:19:38] <traveler> worrying i would say
[11:19:46] <traveler> /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 25
[11:20:46] <traveler> + lots of undefined references in AREImporter.cpp
[11:22:18] <traveler> s/build/linking
[11:22:57] <traveler> clang 3.2
[11:23:50] <lynxlynxlynx> if you upgraded any bit of the toolchain, try with make clean first
[11:29:56] <traveler> i don't know what's going on
[11:29:59] <traveler> its broken allover
[11:30:04] <traveler> configure either loops
[11:30:08] <traveler> or core dumps
[11:30:11] <traveler> -- Configuring incomplete, errors occurred! Segmentation fault (core dumped
[11:30:28] <traveler> -- Performing Test PERMITS_OBJECT_TO_FUNCTION_CAST CMake Error at /usr/local/share/cmake/Modules/CMakeCXXInformation.cmake:37 (get_filename_component): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): CMakeLists.txt:3 (PROJECT)
[11:30:42] <traveler> this is now with gcc47
[11:30:48] <-- lynxlynxlynx has left IRC (Ping timeout: 264 seconds)
[11:31:14] <traveler> cmake -DDISABLE_WERROR=enabled -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=/usr/local/bin/gcc47 -DCMAKE_CXX_COMPILER= /usr/local/bin/g++47
[11:31:51] <fuzzie> you have a space where you shouldn't, right?
[11:32:04] <traveler> yup
[11:32:07] <traveler> corrected it now
[11:32:35] <traveler> at least one thing is explained
[11:32:49] <traveler> let's see how build looks with gcc47
[11:33:57] <fuzzie> the 'invalid or unhandled' error above is because your toolchain is too old
[11:35:57] <traveler> i'm pretty sure ld as well as clang is part of base system i've recompiled 14 hr ago
[11:36:07] <traveler> with gcc47 it works btw
[11:36:20] <fuzzie> you don't have a modern ld if you get that error
[11:36:30] <traveler> but gcc47 uses it's own binutils
[11:37:42] <traveler> i get what are you saying
[11:37:50] <traveler> it just shouldn't be possible
[11:39:45] <traveler> $ ls -l /usr/bin/ld -r-xr-xr-x 1 root wheel 1315752 19 mar 20:12 /usr/bin/ld
[11:39:54] <fuzzie> which version, is the obvious question :)
[11:39:56] <traveler> $ ls -l /usr/bin/cc -r-xr-xr-x 7 root wheel 23361584 19 mar 20:12 /usr/bin/cc
[11:41:08] <traveler> which means ld and clang from base are perfectly in sync
[11:41:43] <traveler> gcc47 works but it uses it's own ld from binutils, quite old to be honest (from last year)
[11:43:15] <traveler> btw, i'm using clang and ld to build whole system as well as libreoffice
[11:43:35] <fuzzie> well I don't know what ld they're shipping in base nowadays
[11:43:40] <fuzzie> presumably not the gnu one
[11:43:55] <traveler> so it's quite hard form me to believe i've run into incompatibility not detected by thousands of mb of code on my own machine as well as all others
[11:44:24] <traveler> actually i think it's still gnu one / old one
[11:44:34] <traveler> i don't think llvm/clang has working linker
[11:44:39] <fuzzie> well, the gnu binutils code has been gplv3 for years
[11:44:48] <traveler> but that shouldn't be a problem
[11:44:54] <fuzzie> the gplv2 one is known-broken with modern clang
[11:45:14] <traveler> well, they must have done something to make it work....
[11:45:41] <fuzzie> if it really is an ancient binutils ld then I think you can safely blame that.
[11:47:41] <traveler> it's more or less 2.17.50
[11:47:53] <fuzzie> so, yes, ancient binutils --> broken in many circumstances :)
[11:48:17] <fuzzie> you need 2.22+ if you want to reliably build stuff with modern clang.
[11:48:39] <traveler> it just boggles my mind
[11:48:57] <traveler> it's used to compile literally entire os
[11:49:12] <fuzzie> If you built a whole modern system (including browsers etc) then presumably you're missing flags/patches/etc which are necessary to disable whatever's breaking.
[11:49:14] <traveler> + some big things like boost, libreoffice
[11:49:21] <traveler> and gemrb strikes a corner case?
[11:49:38] <fuzzie> well, did you compile with debug info on?
[11:49:51] <fuzzie> i mean, the rest of the system
[11:50:30] <fuzzie> If not then I expect that's your difference.
[11:51:28] <traveler> humph
[11:51:35] --> lynxlynxlynx has joined #gemrb
[11:51:35] <-- lynxlynxlynx has left IRC (Changing host)
[11:51:35] --> lynxlynxlynx has joined #gemrb
[11:51:35] --- ChanServ gives channel operator status to lynxlynxlynx
[11:51:45] <traveler> i perfectly get your train of thought i think, thanks
[11:52:02] <traveler> but i'm not entirely convinced
[11:52:03] <fuzzie> well, I guess it's easy enough to try if you want
[11:52:11] <fuzzie> but it's seriously known-broken
[11:52:32] <traveler> that really-really strange
[11:52:35] <traveler> https://wiki.freebsd.org/PortsAndClang
[11:52:38] <fuzzie> and you can say 'you're crazy' if you want, but only if you compiled your system with debug info :)
[11:52:42] <traveler> that runs use ld and clang
[11:52:52] <traveler> and 90
[11:53:14] <fuzzie> using clang 3.2?
[11:53:16] <traveler> * 90% of software that compile with gcc47/modern ld compiles there too
[11:54:00] <fuzzie> it seems like the newest of those logs is older than clang 3.2
[11:54:05] <traveler> well there are her some older runs too
[11:54:08] <traveler> yes
[11:54:18] <fuzzie> i have no idea about compatibility with older clang
[11:54:20] <traveler> but it's not like i've slapped there clang 3.2 by myself
[11:54:32] <traveler> it's part of base for sime time now
[11:54:40] <traveler> and nobody complained about major breakeage
[11:56:29] <fuzzie> well it would be useful to work it out
[11:56:56] <traveler> yes, but i don't know if you realise how slim is the chance
[11:57:12] <traveler> that nobody runned into it yet
[11:57:35] <traveler> seeing that head uses old ld too with clang
[11:57:42] <traveler> and they build pretty much everything with it
[11:58:09] <fuzzie> yes, I mean, work out what's going on
[11:58:26] <traveler> ah, sure
[11:58:41] <traveler> thanks for help, appreciated
[11:59:43] <traveler> i would appreciate some further links about known problems with older ld and clang too if you have time
[12:00:07] <traveler> will dig mailinglists if they were solved/approached
[12:00:27] <fuzzie> well of course older ld comes with lots of other problems too
[12:00:52] <fuzzie> but if they ship a modern binutils with modern gcc, that helps
[12:01:56] <traveler> modern binutils as well as gcc47 is a slap on from ports
[12:02:17] <traveler> shipped is old ld and clang, with pale ghost of patched gcc42
[12:12:53] <fuzzie> i'm busy all of a sudden but i don't see any patches/etc applied to the relevant freebsd ports
[12:13:04] <fuzzie> so my theory there is probably wrong
[12:23:45] <traveler> well
[12:23:59] <traveler> your theory is right
[12:24:02] <traveler> somehow
[12:24:13] <traveler> because all of sudden
[12:24:36] <traveler> i cannot link all revisions of gemrb i've tested (tried bisect)
[12:24:54] <traveler> so something is borked since last base system recompile then (last 14hr)
[12:26:03] <fuzzie> you remove cmakecache.txt before running cmake again, right?
[12:26:26] <traveler> not all times
[12:26:30] <traveler> but few times yes
[12:26:47] <traveler> always dwarf errors even with ancient comiits i know were good
[12:27:22] <fuzzie> and you had debug info on then?
[12:27:53] <traveler> yes
[12:28:01] <traveler> my standard build
[12:29:31] <fuzzie> weird :/
[12:29:49] <fuzzie> you're quite right in that we're not 'special', you really should not hit any corner case which is gemrb-only
[12:30:09] <traveler> i know
[12:30:29] <traveler> i just hope my system compiler is not broken beyond repair now :(
[12:30:41] <traveler> what's worse, don;t know why
[12:31:34] <traveler> recompiling base system now, so far looks normal
[12:31:56] <traveler> and there wasn't any relevent llvm commits since my last rebuild i think
[12:33:03] <traveler> well none in last 5 days
[12:33:36] <traveler> make it two weeks
[12:33:58] <traveler> i mean, i'm pretty sure i've rebuilded gemrb just fine since them
[12:34:06] <traveler> so puzzled what's going on
[12:36:46] <fuzzie> libreoffice, as you said above, is good example
[12:37:11] <fuzzie> it has "IGNORE=known as broken" in the debug section of the ports file though
[12:38:33] <traveler> i just built is 2 days ago
[12:38:42] <traveler> it's only broken if mergedlibs are on
[12:38:43] <fuzzie> but with debug info off, presumably?
[12:38:47] <traveler> yes
[12:38:55] <fuzzie> so I still think that sounds your most likely problem
[12:39:10] <fuzzie> i mean, sorry, back to the beginning: you know DWARF is debug info?
[12:39:25] <fuzzie> so, you will only hit these bugs if you have debug info on in a build
[12:39:59] <traveler> i understand
[12:40:11] <traveler> but i've used debug info in gemrb for quite some time
[12:40:23] <traveler> and with libreoffice thos who tried to build with debug
[12:40:34] <traveler> didn't complain about dwarf erros
[12:41:03] <traveler> but those were the ones who usually couldn;t build working lo at all too...
[12:41:14] <traveler> lo is very-very fragile here
[12:41:54] <traveler> i would say building it is somehow more of a wish-granted than deterministic process ;)
[12:46:23] <traveler> ah.i just open lo makefile and there is indeed ignore with debug too, i've only remembered about MERGELIBS
[12:47:11] <traveler> but maybe it's not so good example as really (most of the time ) sometimes nobody knows what's exactly going with it
[12:50:08] <traveler> btw
[12:50:21] <traveler> i assume Release build is without debug
[12:50:31] <traveler> so no dwarf errors here, yes
[12:50:36] <traveler> but cannot build gemrb as well
[12:51:03] <traveler> which is might worrying
[12:51:05] <traveler> *might
[12:51:09] <traveler> *mightY
[12:51:14] <traveler> [ 69%] Building CXX object gemrb/plugins/ACMReader/CMakeFiles/ACMReader.dir/unpacker.cpp.o CMakeFiles/gemrb.dir/GemRB.cpp.o: In function `main': /home/Kuba/GemRBGit/gemrb/gemrb/GemRB.cpp:(.text+0x25): undefined reference to `operator new(unsigned long)'
[12:53:11] <traveler> and flood of similar ones
[12:54:11] <fuzzie> missing library?
[12:54:37] <traveler> i wondered if i accidentally deleted some dependency lately
[12:54:53] <traveler> but i have all that are required for port version of gemrb in place
[12:57:01] <traveler> missing standard library you mean?
[12:57:42] <traveler> currently clang is recompiling itself which im pretty sure is pretty hefty dose of c++ code
[13:00:10] <traveler> http://pastebin.com/5CqX5gph i'm clearly not a coder
[13:00:20] <Seniorita> [ 63%] Building CXX object gemrb/core/CMakeFiles/gemrb_core.dir/System/Logging.c - Pastebin.com
[13:00:23] <traveler> so in case i'm misinterpreting something
[14:00:25] <-- tomprince has left IRC (Ping timeout: 260 seconds)
[14:00:42] <-- gembot has left IRC (Ping timeout: 272 seconds)
[14:01:10] <traveler> brb
[14:05:28] <-- traveler has left IRC (Ping timeout: 245 seconds)
[14:06:26] --> traveler has joined #gemrb
[14:09:48] <traveler> back to drawing board i think
[14:10:15] <traveler> i cannot compile gemrb with clang/ld at all, even ancient revisions
[14:10:38] <traveler> yet i obviously could do so
[14:11:01] <traveler> system et al is just fine with ld/clang
[14:16:13] <traveler> i don't build some parts of clang since some time
[14:16:33] <traveler> but it would be unthinkable that ARCMigrate, Rewriter or StaticAnalyzer
[14:16:53] <traveler> would be somehow needed with clang _just_ when used with gemrb
[14:17:08] <traveler> i mean they are not relevant at all even
[14:20:04] <traveler> will check for sure upon next system rebuilt still, in case something more was accidentally removed too with this macro
[15:07:58] <-- traveler has left IRC (Ping timeout: 245 seconds)
[15:29:18] <fizzle> there's a petrified fighter in ar3500
[15:29:27] <fizzle> if you leave the area she gets deleted
[15:29:52] <fizzle> any ideas how to prevent that?
[15:30:20] --> brada has joined #gemrb
[15:30:21] <fizzle> maybe set MC_KEEP_CORPSE when petrified actor are loaded?
[15:32:40] <fuzzie> fizzle: do you know what happened with the clock?
[15:32:53] <fizzle> not for bg2 :P
[15:34:08] <fizzle> I made some changes for bg1 that supposedly didn't impact bg2 in a bad way
[15:34:18] <fuzzie> well, the clock now appears when it shouldn't
[15:35:05] <fizzle> probably easy to fix if you know when it should appear
[15:36:01] <fuzzie> well, at a guess the real bug is that it was broken before
[15:36:22] <fuzzie> but you now call SetBAM for every update
[15:36:42] <fuzzie> so now you add a bad BAM as well as a bad tooltip
[15:37:45] <fizzle> the controls exist but shouldn't display?
[15:37:51] <fuzzie> the controls are different controls
[15:38:50] <fuzzie> the clock is OptionControl['Time'] under this new system I guess?
[15:39:03] <brada> is that delete actor change relevant to the petrified actor thing?
[15:40:10] <fizzle> brada: no; or well, partly, I guess, because that bug probably prevented this bug from showing itself
[15:40:16] <fuzzie> while UpdateClock is getting hardcoded control ids, so my head explodes
[15:40:32] <fizzle> fuzzie: so the old code set the tolltip on the wrong controls already?
[15:40:42] <fuzzie> yes, but that is intentional I think
[15:40:46] <fuzzie> because the control is the sleep button
[15:42:38] <fuzzie> i mean, let me go back a bit
[15:43:22] <fuzzie> the display or not of the gears is controlled by the Gears param to SetupMenuWindowControls, but you now ignore that and call SetBAM from other code, always.
[15:43:54] <fuzzie> but it confuses me because all the other games also often pass Gears==false anyway, I guess maybe bg1 just doesn't have another control which happens to have the id?
[15:44:17] <fizzle> possibly
[15:44:27] <fuzzie> but in your new OptionControl dictionary, you have 'Rest' set to 9 and also 'Time' set to 9
[15:44:57] <fuzzie> for all bg games
[15:45:23] <fizzle> not exactly my dictionary, but yeah
[15:45:25] <fuzzie> so i don't see how it would work for bg1 either :)
[15:45:31] <fuzzie> oh, well, I thought you did it
[15:45:32] <fuzzie> whoever's dictionary
[15:45:37] <fizzle> I don't think the code's using that
[15:45:52] <fuzzie> some of the code is, though
[15:46:02] <fuzzie> which makes it really difficult to follow here, honestly
[15:46:33] <fuzzie> but that seems to be the problem, there are two controls with the same id, the one for 'Rest' and the one for 'Time', both control id 9.
[15:46:59] <fuzzie> so maybe store the value of 'Gears' in a global?
[15:47:10] <fizzle> and they're both on the same window?
[15:47:29] <fizzle> or do we assign different windows to OptionsWindow?
[15:47:40] <fuzzie> yes, we assign different windows to OptionsWindow
[15:47:48] <fuzzie> depending on which optionswindow is present for the mode
[15:48:56] <fizzle> can't we just use the window id then?
[16:04:38] <fuzzie> well, hardcoding all of this seems a bit silly
[16:04:46] <lynxlynxlynx> branwen used to work or at least work enough
[16:05:21] <fizzle> I think branwen is fine because she's joinable
[16:05:32] <lynxlynxlynx> fuzzie: bg1 doesn't have the rest button on the main screen, i think that's the other control
[16:06:08] <lynxlynxlynx> fizzle: ah, so it's someone else
[16:06:16] <fizzle> yes, tamah
[16:06:26] <fuzzie> not marked as NPC?
[16:06:44] <fizzle> don't think so
[16:08:20] <fuzzie> i don't understand that InStore thing at all
[16:08:25] <fuzzie> it was totally wrong before your commit?
[16:08:37] <fizzle> as far as I can see, yes
[16:08:44] <fuzzie> oops
[16:08:45] <fuzzie> nice catch
[16:09:31] <fuzzie> but I wonder if you broke more stuff nw
[16:10:15] <fizzle> only one way to find out
[16:11:10] <fuzzie> yeah, checking the obvious testcase
[16:12:38] <fuzzie> yeah, so my familiar has vanished :P
[16:14:27] <fuzzie> i wonder what causes that
[16:16:16] <lynxlynxlynx> (removealleffects ignoring permanent effects is a good thing)
[17:11:46] --> tomprince has joined #gemrb
[17:20:21] <-- Fuzzlix has left IRC (Quit: ChatZilla 0.9.90 [Firefox 19.0/20130215130331])
[17:21:23] <fizzle> fuzzie: how about this for the clock: http://paste.debian.net/hidden/6850555d/
[17:21:29] <Seniorita> Debian Pastezone
[17:43:14] --> rocket_hamster has joined #gemrb
[18:00:50] <brada> fuzzie: im trying to understand why we are using strtok for the cd paths
[18:01:23] <brada> shouldnt we just add the paths from the config to the vector
[18:01:35] <brada> then call resolve on that?
[18:12:38] <wjp> the way I read this, it's used to handle multiple paths in a single config entry
[18:15:00] <wjp> semi-colon-separated on Windows, and colon-separated elsewhere, strangely
[18:16:51] <brada> oh
[18:17:00] <brada> that makes sense
[18:17:56] <brada> only i cant think of why/when you would want multiple paths for the same "CD"
[18:22:37] <-- brada has left IRC (Quit: brada)
[18:24:59] <fuzzie> me neither
[18:25:01] <fuzzie> ideas?
[18:26:11] <wjp> no, although I do remember seeing someone in here with that setup
[18:28:01] <wjp> maybe
[18:28:23] <wjp> or I could also have just encountered this bit of code while trying to figure out an invalid path error
[18:28:33] <fuzzie> the truth will out!
[18:28:50] <wjp> it would if some bits of cfg were still available on pastebin :-)
[18:30:07] <wjp> tomprince added it with "First go at supporting mods."
[18:30:28] <wjp> no, wait
[18:30:30] <wjp> I'm blind
[18:30:34] * wjp sighs
[18:32:08] <wjp> it was Avenger, with "implemented multiple cd paths"
[18:34:32] <wjp> for localization, it seems
[18:34:53] <wjp> 19:44 <@Avenger> CD1:=E:\BG2\English\;E:\BG2\CD1\
[18:34:58] <wjp> 19:46 <@Avenger> this is a full install, of localized version
[18:35:16] <wjp> (2010-07-02, if you want to read back more)
[18:36:01] <fuzzie> oh fun
[18:36:07] <fuzzie> also, drat
[18:55:52] --> brada has joined #gemrb
[19:03:56] <fizzle> fuzzie: does the clock change work for you?
[19:04:16] <fuzzie> can't test now :/
[19:04:59] <fizzle> 'k, any ideas about the petrified actor?
[19:07:00] <fuzzie> this is tamah?
[19:07:27] <fizzle> yes
[19:09:37] <fuzzie> no. no flags set?
[19:09:52] <fizzle> what flags? MC_?
[19:09:59] <fuzzie> any weird flags :P
[19:10:24] <fizzle> tell me how to recognize those again? :)
[19:10:43] <fuzzie> open in dltcep :-p
[19:10:58] <fizzle> no windows here
[19:11:07] <fuzzie> as if any of us have windows :)
[19:11:16] <fuzzie> someone else should check that though before I go theorising
[19:11:32] <fuzzie> there's also e.g. ielister etc
[19:12:23] <fizzle> I have NI
[19:12:42] <fuzzie> well, NI is not my friend, but presumably it suffices
[19:13:04] <fizzle> not sure what I'm looking for, though
[19:13:20] <fuzzie> is tamah embedded in the map?
[19:13:47] <fizzle> in the list of actors? yes
[19:13:55] <fuzzie> as opposed to being referenced
[19:14:30] <fizzle> I didn't even know that's possible
[19:14:36] <fizzle> no, there a tamah.cre
[19:15:15] <fuzzie> so the normal way this works is that the map just references the .cre by resref for every creature
[19:15:22] <fuzzie> and then they get embedded at save time
[19:15:41] <fuzzie> but you can also have them embedded right away, so the .cre is actually just useless in the final game
[19:16:35] <fizzle> I suppose you don't know how to tell the difference in NI?
[19:16:39] <fuzzie> no :)
[19:16:47] <fuzzie> and i have no games here, hence lack of test
[19:16:50] <fuzzie> but it can wait
[19:19:52] <fuzzie> and/or someone else might have a direct clue
[19:19:53] <brada> fuzzie: is this satisfactory?
[19:19:53] <brada> http://paste.debian.net/243182/
[19:19:57] <Seniorita> debian Pastezone
[19:20:28] <fuzzie> brada: well, it should fix the bug
[19:20:34] <brada> right
[19:20:42] <fuzzie> as discussed your (char*) cast is still a Really Bad Thing though
[19:20:43] <brada> but there was some concern about the const cahr
[19:20:46] <brada> yeah
[19:20:47] <brada> that
[19:20:56] <brada> but would strtok really alter it?
[19:20:58] <fuzzie> yes
[19:21:01] <fuzzie> that's what strtok does
[19:21:17] <fuzzie> which is why it's char* and not const
[19:21:20] <brada> the only thing i see is adding a null character
[19:21:30] <fuzzie> it *inserts* a null character
[19:21:32] <fuzzie> into the string
[19:21:40] <fuzzie> and continues doing that until it's done tokenising
[19:21:48] <brada> ah
[19:22:27] <fuzzie> but that shouldn't stop you from committing the bugfix, please :)
[19:22:34] <brada> of course
[19:23:58] <brada> so if i understand this correctly it replaces the seperator with null?
[19:24:49] <fuzzie> yes
[19:25:24] <fuzzie> then it returns the current string pointer, so that's the newly-null-terminated next token
[20:54:59] <brada> fuzzie: http://paste.debian.net/243210/
[20:55:03] <Seniorita> debian Pastezone
[20:55:25] <brada> lynx, wjp, anybody else want to comment on that?
[20:58:07] <fuzzie> it's unsafe
[20:58:32] <fuzzie> you started adding code which calls into Interface before Init is called
[20:58:44] <fuzzie> so I don't think it's a good idea to start not initing variables
[20:59:31] <lynxlynxlynx> CustomFontPath could default to /usr/share/fonts/TTF to make me happy
[21:01:35] <fuzzie> other than that, it seems sane enough at a glance
[21:02:11] <brada> fuzzie: i can init them to '\0' then
[21:02:19] <fuzzie> sure, that would be ideal
[21:03:13] <fuzzie> the code confuss me a bit
[21:03:43] <fuzzie> CopyGemDataPath is not the gemrb data path
[21:04:17] <fuzzie> so why is it used in the CachePath default?!
[21:04:24] <fuzzie> that is the cause of the error message which confused me, I guess
[21:04:35] <fuzzie> but that is of course a bug which is already in-tree :P
[21:05:59] <brada> well what should be the default for that?
[21:06:01] <fuzzie> while I'm thinking about existing bugs, InterfaceConfig.cpp is reading _MAX_PATH into a buffer of size 1024, which predates anything of brada
[21:06:05] <fuzzie> brada: GemRBPath.
[21:06:18] <fuzzie> or GamePath.
[21:06:22] <fuzzie> or ./Cache.
[21:06:27] <fuzzie> whatever it was before ideally
[21:07:19] <brada> ./Cache iirc
[21:07:53] <fuzzie> anwyay this is kind of irrelevant
[21:08:15] <fuzzie> it's just that right now, if it can't find the config, it errors out trying to make a non-existant CacheDir
[21:08:19] <fuzzie> or, well, last time I tried
[21:08:26] <fuzzie> since the errors on non-existant config seemed to have vanished
[21:09:29] <fuzzie> and I hadn't worked out why
[21:10:07] <fuzzie> $ build/gemrb/gemrb
[21:10:07] <fuzzie> [Core]: GemRB Core Version v0.7.2-git Loading...
[21:10:07] <fuzzie> [Core]: Initializing the Event Manager...
[21:10:07] <fuzzie> [Core/FATAL]: Unable to create cache directory '/usr/local/share/gemrb/Cache'
[21:10:09] <fuzzie> ^- specifically I get this
[21:10:21] <fuzzie> and that is a completely useless default since it will always be read-only :)
[21:10:27] <brada> ok
[21:10:39] <fuzzie> but it doens't necessarily have to be ./Cache
[21:11:07] <-- rocket_hamster has left IRC (Remote host closed the connection)
[21:11:16] <fuzzie> just would be nice to not force all users to manually set a CachePath in their cfg
[21:13:24] <fuzzie> if that makes any sense at all.
[21:14:20] <brada> yes
[21:27:14] <brada> can somebody not on mac/ios try this
[21:27:15] <brada> http://paste.debian.net/243219/
[21:27:18] <Seniorita> debian Pastezone
[21:27:25] <brada> preferably all of you :p
[22:16:41] <-- brada has left IRC (Quit: brada)
[22:45:28] --> brada has joined #gemrb
[23:37:18] <-- fizzle has left #gemrb
[23:40:00] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[23:59:34] <-- Coriander has left IRC (Ping timeout: 245 seconds)