#gemrb@irc.freenode.net logs for 10 Jun 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:00:49] --> budlust has joined #GemRb
[00:32:23] <CIA-23> GemRB: 03tom.prince * r4ab608d0a034 10gemrb/gemrb/ (core/VFS.h includes/globals.h):
[00:32:23] <CIA-23> GemRB: VFS: Move PathDelimter here and change to a const.
[00:32:23] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[00:32:23] <CIA-23> GemRB: 03tom.prince * r238308f3bb8b 10gemrb/gemrb/ (271 files in 42 dirs):
[00:32:23] <CIA-23> GemRB: Sort include order.
[00:32:23] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[00:41:54] <CIA-23> GemRB: 03tom.prince * rd39d93411136 10gemrb/gemrb/docs/en/CodingStyle.txt:
[00:41:54] <CIA-23> GemRB: CodingStyle: Document header include order.
[00:41:54] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[00:58:23] <tomprince> Comments on changing char[_MAX_PATH] to std::string?
[02:04:08] --> _pickle has joined #GemRb
[02:15:31] <CIA-23> GemRB: 03tom.prince * rb2102e580ddd 10gemrb/gemrb/ (13 files in 7 dirs):
[02:15:31] <CIA-23> GemRB: Remove unneeded includes of config.h.
[02:15:31] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[02:15:34] <CIA-23> GemRB: 03tom.prince * rc2b37d84b0b4 10gemrb/gemrb/ (25 files in 9 dirs):
[02:15:34] <CIA-23> GemRB: Get rid of most system headers.
[02:15:34] <CIA-23> GemRB: Tested on linux, mingw, and msvc++6. If it breaks elsewhere, we
[02:15:34] <CIA-23> GemRB: should fix it by abstraction.
[03:21:59] --> Gekz_ has joined #GemRb
[03:32:09] <-- Gekz has left IRC (Read error: Connection reset by peer)
[03:32:22] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[03:32:36] --> Gekz_ has joined #GemRb
[03:32:57] <-- _pickle has left IRC (Remote host closed the connection)
[03:38:59] --> Gekz has joined #GemRb
[04:02:04] <tomprince> or.cz/vfs: Lightly tested.
[04:07:44] <tomprince> A good follow up to this would be to refactor DirectoryIterator, so that we have different versions for unix/win32, rather than wrapping opendir et al just for it.
[04:09:50] <tomprince> Also, should CachedFileStream delegate to FileStream for actually open/reading the file?
[04:12:15] <tomprince> After that, we could do the same split for FileStream. i.e. not wrapping the stdio stuff for just FileStream.
[04:12:36] <tomprince> Or, is there any reason we can't just use stdio directly, in FileStream?
[04:42:47] <tomprince> stdio at least compiles on win32.
[04:45:03] <-- budlust has left IRC (Remote host closed the connection)
[04:45:21] --> budlust has joined #GemRb
[04:45:39] <-- budlust has left #GemRb
[05:32:34] --> raevol has joined #GemRb
[06:21:26] <-- raevol has left IRC (Quit: Leaving.)
[06:55:47] --> lynxlynxlynx has joined #GemRb
[06:55:47] --- ChanServ gives channel operator status to lynxlynxlynx
[07:01:45] <-- Gekz has left IRC (Read error: Connection reset by peer)
[07:02:04] --> Gekz has joined #GemRb
[07:02:12] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[07:02:25] --> Gekz_ has joined #GemRb
[07:43:35] <-- Gekz has left IRC (Read error: Connection reset by peer)
[07:44:22] <-- Gekz_ has left IRC (Ping timeout: 245 seconds)
[07:49:30] --> Gekz_ has joined #GemRb
[08:13:59] --> Gekz has joined #GemRb
[08:15:39] <fuzzie> tomprince: i seem to recall that the buffering causes problems?
[08:15:52] <fuzzie> but maybe edheldil would be better to ask
[08:16:09] <edheldil> hm?
[08:17:51] <-- Gekz_ has left IRC (Ping timeout: 260 seconds)
[08:18:47] <edheldil> specific versions of directory iterator for posix/win - why not, the code would probably be more clear and it would be a fairly static code
[08:22:33] --> Gekz_ has joined #GemRb
[08:24:21] <fuzzie> yes, that makes sense
[08:29:30] <fuzzie> it is really not a good sign when it's two hours or so before an exam and i'm still trying to work out when i'm taking it
[08:32:49] <lynxlynxlynx> do you at least know where it will be? :)
[08:36:09] <tomprince> Does the chitin.key for HOW need to be merged with the base one for iwd? I seem to get missing bams with just the HOW chitin
[08:36:23] <fuzzie> tomprince: you have gametype 'how'?
[08:37:34] <tomprince> That would do it.
[08:37:49] <fuzzie> another vote for automated detection, perhaps
[08:38:41] <fuzzie> (beware, gemrb's HOW support is broken for the expansion areas)
[08:39:05] <edheldil> yes, although that will not work with data from scratch ....
[08:39:26] <-- Gekz has left IRC (Read error: Connection reset by peer)
[08:39:39] <tomprince> Well, for data from scratch, we should need the GemRB override...
[08:39:52] <tomprince> s/should/shouldn't/
[08:40:11] <edheldil> ??? sure we need them
[08:40:22] --> Gekz has joined #GemRb
[08:41:09] <tomprince> Well, if the data is targeted at GemRB, then all the files we need that aren't supported by IE can just go in with the rest of the data.
[08:41:28] <tomprince> What I mean is, the distinction between original data, and gemrb specific data disapears.
[08:41:53] <fuzzie> well, that doesn't actually work yet :)
[08:42:11] <edheldil> ah. But that would create ugly issues with GemRB upgrades
[08:42:44] <edheldil> or just 'issues'
[08:43:01] <fuzzie> especially for guiscripts. but the future.:)
[08:43:27] <edheldil> guiscripts != override ;-)
[08:43:52] <fuzzie> well, if you get rid of gametype, guiscripts have to go somewhere too :P
[08:44:08] <fuzzie> so i think it is a multi-step thing, and just auto-detecting gametype is a cleverer plan for now
[08:45:11] <fuzzie> and i know the *building* for this exam, so i shall go and look lost.
[08:45:40] <tomprince> or.cz/config cleans up the config parsing, and adds multiple override support.
[08:46:29] <-- |Cable| has left IRC (Remote host closed the connection)
[08:48:14] <fuzzie> that is.. ugly :-)
[08:48:40] <fuzzie> also, you seem to be breaking ResolveFilePath again?
[08:49:17] <fuzzie> maybe that needs a comment about leaving them outside the loop :)
[08:50:42] <tomprince> I don't think that breaks things?
[08:51:39] <fuzzie> oh, isee
[08:51:52] <fuzzie> well, i guess i don't quite see what's going on, but there are two different patches here?
[08:52:29] <tomprince> Well, the second patch just add suport for a new config option ModPath.
[08:52:41] <fuzzie> no
[08:52:47] <fuzzie> i mean, the first patch should be two patches
[08:53:16] <fuzzie> it seems to be un-doing your ResolveFilePath moves and fixing that problem a different way, and also macro-ifying the config parsing?
[08:53:52] <fuzzie> but it seems like it doesn't fix the problem
[08:54:27] <fuzzie> i mean, you made that change because you should be able to put 'CaseSensitive = 0' or 'CaseSensitive = 1' at the bottom of your config file.
[08:54:43] <fuzzie> so you can't call ResolveFilePath until you're finished parsing the entries.
[08:54:57] <fuzzie> and you're undoing that change a few days later, but it seems like it's still broken.
[08:55:46] <fuzzie> i'm pretty sure it was your change, anyway..
[08:56:11] <tomprince> Yes, I forgot about that. :) A comment would be a good thing there, obviously.
[08:56:59] <fuzzie> ok. so my vote: comment :)
[08:57:09] <fuzzie> the macros are ugly though
[08:57:47] <fuzzie> i mean, it's a perfectly fine change, +1 other than the path thing
[08:58:26] <tomprince> Well, I started off having an array that described all the config options. But the problem was, for the int/bools, that we did all sort fo things to them, and it would have been uglier to describe that.
[08:59:13] <fuzzie> well, i thought an array and a switch statement for type or something :)
[08:59:17] <CIA-23> GemRB: 03lynxlupodian * rd58cb92ae0b2 10gemrb/gemrb/GUIScripts/LUCommon.py: LUCommon.py: import only the needed stuff from GUICommon
[08:59:18] <CIA-23> GemRB: 03lynxlupodian * r53abdb8706a8 10gemrb/gemrb/GUIScripts/ (GUICommon.py LUProfsSelection.py TextScreen.py): added GameIsIWD1, a shortcut to check if we're playing either iwd or how
[08:59:21] <CIA-23> GemRB: 03lynxlupodian * rf81a4ef87e22 10gemrb/gemrb/GUIScripts/ (5 files in 3 dirs):
[08:59:21] <CIA-23> GemRB: use direct gametype checks instead of hardcoded LUPROFS_TYPE* constants;
[08:59:22] <CIA-23> GemRB: the iwd and bg1 levelup code are now identical
[08:59:24] <CIA-23> GemRB: 03lynxlupodian * r96a2cede7e14 10gemrb/gemrb/GUIScripts/ (bg1/LevelUp.py bg2/LevelUp.py iwd/LevelUp.py): merged the bg1/iwd and bg2 version of LevelUp.py
[08:59:25] <CIA-23> GemRB: 03lynxlupodian * r3f722096065b 10gemrb/gemrb/GUIScripts/ (LevelUp.py bg1/LevelUp.py bg2/LevelUp.py iwd/LevelUp.py): moved LevelUp.py up to be shared and removed the copies
[08:59:31] <fuzzie> but i probably should go and integrate vector fields over oriented surfaces or somesuch undergrad horror, rather than peer at gemrb code :(
[08:59:31] <CIA-23> GemRB: 03lynxlupodian * rff3364af0e5c 10gemrb/gemrb/GUIScripts/LevelUp.py: iwd: fixed druid spell learning on level up
[08:59:32] <CIA-23> GemRB: 03lynxlupodian * r5ea20fe7d721 10gemrb/gemrb/GUIScripts/ (LUSkillsSelection.py LevelUp.py): replaced LUSKILLS_TYPE_LEVELUP_BG1 with direct gametype checks
[08:59:48] <fuzzie> lynxlynxlynx: our hero!
[09:00:58] <fuzzie> now all we have to do is scatter TNO checks all over it
[09:01:23] <lynxlynxlynx> and later iwd2 >>
[09:01:29] <lynxlynxlynx> 10 files changed, 90 insertions(+), 1034 deletions(-) <-- :)
[09:04:52] <tomprince> Awesome.
[09:11:40] <edheldil> :)
[09:12:55] <edheldil> the question is, how to check for a specific engine version, keeping in mind there might be nonstandard ones
[09:13:23] <edheldil> e.g. is check for beasts.ini good enough?
[09:14:31] <tomprince> I don't know, how does weidu do it?
[09:23:33] <edheldil> or we could forget about the nonstandard for a while, they would have to be specified directly
[09:24:00] <tomprince> Probably.
[09:25:45] <CIA-23> GemRB: 03tom.prince * r2b5e6e52fb8b 10gemrb/gemrb/core/Interface.cpp:
[09:25:45] <CIA-23> GemRB: Interface: Add warning about moving ResolveFilePath into loop.
[09:25:45] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:25:47] <CIA-23> GemRB: 03tom.prince * r41a32265380c 10gemrb/gemrb/core/Interface.cpp:
[09:25:47] <CIA-23> GemRB: Interface: Simply config file parsing.
[09:25:47] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:25:50] <CIA-23> GemRB: 03tom.prince * r51eda9b3d896 10gemrb/gemrb/core/ (Interface.cpp Interface.h VFS.cpp VFS.h):
[09:25:50] <CIA-23> GemRB: First go at supporting mods.
[09:25:50] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:51:13] <CIA-23> GemRB: 03tom.prince * rdd96baa4f897 10gemrb/gemrb/core/Interface.cpp:
[09:51:13] <CIA-23> GemRB: Interface: Fix broken tob -> bg2 alias.
[09:51:13] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:56:27] --> pupnik has joined #GemRb
[09:59:58] <-- pupnik_ has left IRC (Ping timeout: 265 seconds)
[10:01:03] <CIA-23> GemRB: 03tom.prince * r6f177edbef20 10gemrb/gemrb/core/SaveGameIterator.cpp:
[10:01:03] <CIA-23> GemRB: SaveGameIterator: change ->release() to .release to avoid double free.
[10:01:03] <CIA-23> GemRB: There should be a way to diagnose this automatically.
[10:01:03] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[10:05:38] <fuzzie> that's Holder vs non-Holder release()?
[10:06:22] <tomprince> Yes.
[10:07:09] <tomprince> Holder release sets Holder to NULL, so doesn't free on destruction.
[10:12:57] <CIA-23> GemRB: 03tom.prince * r62c326d48047 10gemrb/gemrb/ (core/Holder.h includes/operatorbool.h):
[10:12:57] <CIA-23> GemRB: operator bool: Move operator bool handling to its own include file.
[10:12:57] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[10:21:10] --> barra_library has joined #GemRb
[10:25:34] --> Maighstir_laptop has joined #GemRb
[10:28:16] <CIA-23> GemRB: 03tom.prince * r0c0d4211299d 10gemrb/gemrb/core/ (5 files):
[10:28:16] <CIA-23> GemRB: VFS: Add DirectoryIterator abstraction.
[10:28:16] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[10:41:58] <-- barra_library has left IRC (Ping timeout: 258 seconds)
[11:04:07] <Maighstir_laptop> minw32-make breaks at OpenAL (99%): http://pastebin.com/re9EHZUD
[11:23:35] <lynxlynxlynx> interesting
[11:24:46] <Maighstir_laptop> how so?
[11:25:02] <lynxlynxlynx> it has a guard
[11:32:45] <lynxlynxlynx> including SDL_config in win32def.h would probably fix it, but i don't think it is the right place
[14:04:50] <Maighstir_laptop> #include "SDL_config.h" just makes it break the first thing it does: "fatal error: SDL_config.h: no such file or directory", though it IS in my path at C:\MinGW\include\SDL\SDL_config.h
[14:19:11] <tomprince> Maighstir_laptop: Does changing the define in win32def.h to #define HAVE_SNPRINTF 1 fixes things?
[14:28:41] <CIA-23> GemRB: 03tom.prince * r3344c671d20a 10gemrb/gemrb/includes/win32def.h:
[14:28:41] <CIA-23> GemRB: Mingw: Fix conflicting definitions of HAVE_SNPRINTF.
[14:28:41] <CIA-23> GemRB: Mingw compiled SDL has SDL_config.h defined HAVE_SNPRINTF as 1,
[14:28:41] <CIA-23> GemRB: which conflicted with our empty definition.
[14:28:41] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[14:28:42] <tomprince> On the basis that changing the define in config.h to be blank cause the same error on linux.
[14:29:45] <tomprince> The prebuild SDL is apperently build with msvc.
[14:29:53] <tomprince> Or something.
[14:35:07] <fuzzie> given the state of gcc on Windows, i think pretty much all standard dlls are built with msvc
[14:37:40] <tomprince> That was the impression I got.
[14:43:05] <tomprince> Some I am curious what people think of changing char[_MAX_PATH] to std::string.
[14:43:26] <fuzzie> where in particular?
[14:44:00] <fuzzie> it would make sense in Interface etc, certainly
[14:44:20] <tomprince> Well, I am just looking to decrease the dependencies on VFS.h.
[14:45:05] <fuzzie> but i would want to avoid huge numbers of heap allocation/reallocations
[14:45:11] <fuzzie> i don't know if that would happen anywhere :)
[14:45:38] <tomprince> Yes.
[14:46:36] <tomprince> The first pass would be just to change things in strucutres.
[14:47:01] <Maighstir_laptop> tomprince: that makes it build
[14:47:57] <tomprince> Good.
[14:48:31] <fuzzie> it would be nice if we didn't depend on STL, really
[14:49:24] <fuzzie> but i suspect it would be more horror than it was worth
[14:50:11] <tomprince> Well, I can understand that in terms of building everywhere, it might be easier.
[14:50:30] <fuzzie> but, i mean, you'd simply do s/std::string/SomeStringClass/ here
[14:50:52] <fuzzie> so i don't mean it as a "no, don't make sensible changes to code!" thing, i am just going off on a tangent
[14:51:07] <tomprince> Well, yes, we could reimplements stl, if we wanted.
[14:52:58] <fuzzie> well, bare-bones string/vector/list/map wouldn't quite be reimplementing STL :) but i will see how much of a pain it is to try building STLport or similar first
[14:54:24] <fuzzie> but not yet, i have foolishly given myself only 6 days to try and remember a semester's worth of group theory
[14:59:36] <Maighstir_laptop> Either GemRB has a problem with 8-bit png's again, or GemRB doesn't like having both 8-bit and 24-bit png's loaded with GemRB.LoadWindowFrame() (one of my images was 8-bit, probably from some png optimiser, and GemRB halted when loading it, saving it in 24-bit mode fixed the problem)
[15:00:55] <fuzzie> do you get some kind of error?
[15:01:45] <fuzzie> oh, trying to store the palette in a null pointer is perhaps unlikely to work
[15:03:38] <edheldil> tomprince: why do you want to get rid of dependencies on VFS.h?
[15:03:55] <tomprince> Changing PNGImporter.cpp:180 to Color pal[256] should fix it.
[15:04:05] <fuzzie> edheldil: the less header files the faster compiles!
[15:05:55] <tomprince> Well, in this particular instance, I think the dependency is just on _MAX_PATH, which I could just move out of there. But we use _MAX_PATH just as a default size for strings, which just seems silly, especially considering it is 4096 on linux x86_64.
[15:06:13] <edheldil> sure, but will using std::string instead of static char arrays lead to faster compiles
[15:06:15] <edheldil> ?
[15:07:19] <lynxlynxlynx> more likely slower
[15:07:26] <fuzzie> well, if your std::string allocates on the heap, it's not going to be a memory gain
[15:07:53] <tomprince> No?
[15:08:32] <fuzzie> fragmentation is going to wipe out any gains you'd get, i'm pretty sure
[15:08:44] <fuzzie> i mean, given numbers like 4096
[15:08:52] <fuzzie> i could imagine that it'd be higher on other platforms
[15:09:31] <fuzzie> and, well, about faster compiles: i imagine it'd make almost no difference up to the point where you change something in VFS.h :)
[15:09:41] <fuzzie> but i don't mind either way, and now i shall go cook
[15:10:18] <edheldil> ^^ I concur, but no cooking
[15:14:20] <Maighstir_laptop> I guess it no longer matters, but here's a log of what I get trying to start GemRB, using said 8-bit png: http://pastebin.com/GUDWRW3S
[15:21:05] <tomprince> Changing PNGImporter.cpp:180 to Color pal[256] should fix it.
[15:21:08] <tomprince> ?
[15:22:07] <Maighstir_laptop> recompiling now
[15:24:56] --> budlust has joined #GemRb
[15:26:04] <Maighstir_laptop> hmm, either I made some error, or there's no difference
[15:30:52] <Maighstir_laptop> cleaning out the build dir and removing PNGimporter.dll from the install dir, then recompiling made no difference
[15:34:33] <tomprince> I get it here too.
[15:48:38] <tomprince> Maighstir_laptop: That should fix it. Or at least let it get further.
[15:49:58] <CIA-23> GemRB: 03tom.prince * r1da3dfb21996 10gemrb/gemrb/plugins/PNGImporter/PNGImporter.cpp:
[15:49:58] <CIA-23> GemRB: PNGImporter: Some fix to paletted PNG handling.
[15:49:58] <CIA-23> GemRB: - Don't deallocate read struct until after we are done with it.
[15:49:58] <CIA-23> GemRB: - Don't dereference NULL.
[15:49:58] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[15:59:46] <tomprince> Looking at the log, I don't see how it could ever have worked.
[16:07:36] <Maighstir_laptop> I'm not sure it ever did. I know there was problems with 8-bit pngs a long time ago, which I "complained" about in a roundabout way (I thought my images were 24-bit, but someone else said they weren't when they looked at my dataset).
[16:08:31] <tomprince> Work now?
[16:08:35] <Maighstir_laptop> it does
[16:08:37] <Maighstir_laptop> thanks
[16:10:16] <Maighstir_laptop> now I'll just have to look through my guiscripts for stuff that needs changing
[16:11:58] <tomprince> I think the main thing that needs changing is anything that could, but didn't go through the GUIClasses stuff.
[16:12:06] <tomprince> And the save game stuff.
[16:12:33] <tomprince> Which is now an object.
[16:12:47] <lynxlynxlynx> i suggest you remove all the *pyc too, there were a few renames/moves recently
[16:14:50] <Maighstir_laptop> yeah, I'll figure out what doesn't work, and I'll probably ask if I can't figure out how to get it to work (by looking at the other games' scripts)
[16:17:04] <edheldil> Maighstir_laptop: have you seen my list of files for new dataset? Might help you ..
[16:18:06] <Maighstir_laptop> that the one in the source? at tests/minimal?
[16:18:43] <lynxlynxlynx> no
[16:19:03] <tomprince> No. That is mine, which is just *barely* enough to allow me to call GemRB.Quit() in Start.py:OnLoad.
[16:20:14] <Maighstir_laptop> [14:08:27] <edheldil> at http://www.eowyn.cz/gemrb/testgame.lst is a list of files (sans the gemrb-specific ones, which were mostly copied from ps:t) <- that one, then?
[16:21:04] <edheldil> yes
[16:22:57] <Maighstir_laptop> at least I can load the start window, I use a bunch of files copied from the games but I'm in the process of crating my own versions of those
[16:24:25] <Maighstir_laptop> figuring out what few files are needed isn't too hard though trial-and-error
[16:24:27] <lynxlynxlynx> btw, i've made a project page on https://openhatch.org/+projects/GemRB ; maybe we should adopt a similar clean approach on our wiki and hide the how-to-contribute into its own page
[16:24:50] <lynxlynxlynx> the main page is definitely too long
[16:29:50] <tomprince> We should also get rid of the mention of techinical difficulties on the root gemrb.sf.net
[16:31:03] <lynxlynxlynx> slow redirection huh
[16:31:55] <-- Dark-Star|away has left IRC ()
[16:38:48] <Maighstir_laptop> another thing... I don't know if this is just me, but GemRB doesn't seem to like quitting through the "close window" (X) button on Windows. It says: "This Application has requested the Runtime to terminate in an unusual way."
[16:39:23] <lynxlynxlynx> tomprince: fixed
[16:39:25] <Maighstir_laptop> Taking a wild guess, I'd say this is the Visual C 9 runtime that python is compiled with
[16:41:53] <tomprince> Does it do it if you call GemRB.Quit() ?
[16:43:39] <Maighstir_laptop> it doesn't fail, but takes a long time to quit
[16:45:46] <Maighstir_laptop> no wait, hat was just me bugging out... the failure was because a script error, first trying to load a chu file that doesn't exist, then closing with the window's close button (because the in-game buttons calls functions from the previous script that's no longer loaded)
[16:46:19] <Maighstir_laptop> sorry, nothing to see here
[16:50:27] <tomprince> Well, we should probably still handle it gracefully ...
[16:51:37] <tomprince> If you can track do where it is falling down, either with GDB, or judicious use of printfs ...
[16:59:22] <-- pupnik has left IRC (Ping timeout: 276 seconds)
[17:07:51] <Maighstir_laptop> ... that may take a while. I figured out the main fault was mine, and I have other projects (among others: the dataset, and trying to figure out how an XCode project for GemRB should be set up)
[17:11:27] <fuzzie> you tried just using cmake to generate an XCode project?
[17:12:27] <Maighstir_laptop> two questions: it can do that? where can I find it?
[17:13:17] <fuzzie> you just run 'cmake -G Xcode' i think, after making sure you have cmake 2.8.1
[17:13:40] <Maighstir_laptop> yeah, cmake doesn't exist on my system... I'll google
[17:13:58] <fuzzie> but there are various ways to install it
[17:14:18] <fuzzie> i think they have a binary package if you're intending to do everything the native OS X way
[17:14:35] <Maighstir_laptop> that's what I prefer, yes
[17:16:18] --> |Cable| has joined #GemRb
[17:16:48] <tomprince> I can understand having too many projects. :)
[17:17:58] <fuzzie> i wonder what we depend on, on OS X .. just SDL.framework on top of the system libraries?
[17:20:49] --> pupnik has joined #GemRb
[17:32:52] <Maighstir_laptop> Heh, it finds SDL (SDL Found), but then it complains that the variable SDL_MAIN_LIBRARY_PATH is NOTFOUND
[17:35:54] <Maighstir_laptop> and the only place google finds that string is at gemrb.git.sourceforge.net
[17:40:02] <tomprince> You could just try getting rid of it. I am not really sure that I understand the use for it. It has something to do with needing an objc entry point for a cocoa app. The thing to search for is probably sdlmain.m
[17:41:31] <Maighstir_laptop> changing it to SDL_LIBRARY_PATH works, but I have no idea if that's "correct"... i was just guessing
[17:42:25] <lynxlynxlynx> let me check what we have in wormux
[17:43:50] <lynxlynxlynx> a precompiled libSDLmain_UB.a directly in the tree
[17:47:06] <lynxlynxlynx> and no mention of SDL_MAIN anywhere
[17:47:32] <lynxlynxlynx> it's one big mess
[17:48:27] <tomprince> Well, SDL_MAIN_LIBRARY_PATH is just the cmake variable that points at *SDLmain*
[17:48:42] <tomprince> But, yes, the SDLmain does seem to be a mess.
[18:08:17] <-- Gekz has left IRC (Quit: Leaving)
[18:26:59] --> tomprince_loki has joined #GemRb
[18:31:01] --> Dark-Star|away has joined #GemRb
[18:31:01] --- ChanServ gives channel operator status to Dark-Star|away
[18:41:56] <fuzzie> you need Cocoa setup for a Cocoa app.
[18:42:39] <fuzzie> modern SDL does the sensible thing and just does the Cocoa init at SDL init time.
[18:43:26] <fuzzie> unfortunately, they can't change that in SDL 1.2 because it changes a bunch of subtle behaviour and obviously breaks the ABI.
[18:44:22] <fuzzie> and you have to sabotage something or other in SDLVideo to make it build against a newer SDL. does work fine on OS X after that though.
[18:46:20] <fuzzie> but it works fine with 1.2 if you copy the SDLmain.m out of the framework and build against that instead of whatever weird thing cmake fails to find.
[18:48:34] <fuzzie> i'm surprised they didn't fix cmake, i assumed i was just using an old version.
[18:52:38] <fuzzie> but they have indeed not. sigh.
[18:55:05] <fuzzie> although poking through cmake's bugs, i'm surprised it manages to build anything much on OS X at all.
[18:59:42] --> cubathy has joined #GemRb
[20:01:29] --> raevol has joined #GemRb
[20:18:33] <lynxlynxlynx> the portal key non-removal is partly due to the containainer item init problems
[20:19:28] <lynxlynxlynx> so it's in the same basket as potions and scrolls, at least in the beginning
[20:23:23] <fuzzie> but the action got fixed now?
[20:23:27] <fuzzie> i forget the situation
[20:25:06] <lynxlynxlynx> that's what i wanted to do, but i see i have no way to test it
[20:26:29] <lynxlynxlynx> http://pastebin.com/zWami8Hx <-- this was the first plan
[20:28:57] <lynxlynxlynx> basically the same as the FindItem fix (forgot for what it was needed), but untested and unthought out
[21:17:39] <-- raevol has left IRC (Quit: Leaving.)
[21:21:25] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[21:44:59] <lynxlynxlynx> it's interesting that the undroppability always works in the inventory
[21:44:59] <-- budlust has left IRC (Ping timeout: 272 seconds)
[21:45:24] --> budlust has joined #GemRb
[22:28:01] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[23:07:19] <-- CIA-23 has left IRC ()
[23:37:43] --> Gekz has joined #GemRb
[23:49:10] --> CIA-23 has joined #GemRb
[23:50:44] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[23:51:32] <-- budlust has left #GemRb