#gemrb@irc.freenode.net logs for 27 Mar 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:00:24] <cfchris6> fuzzie: is it possible to get the current cursor "mode" in the guiscript? (i.e. if a spell was selelected and a target has to be selected, can I detect this mode as well as the spell in a guiscript? )
[00:01:22] <cfchris6> on second look it seems as if this was what "GemRB.GameControlGetTargetMode() != TARGET_MODE_NONE" does :/
[00:01:25] <fuzzie> (was that new/delete patch not applied? if not, i would also appreciate a git patch for that to try!)
[00:01:47] <fuzzie> cfchris6: casting spells at on-screen party members should already work..
[00:02:21] <cfchris6> yea, that should be the cited and the following two lines, lets try again
[00:02:46] <fuzzie> beware that if the party member is not visible then ActOnPC() does not work.
[00:03:06] <cfchris6> visible in what context?
[00:03:43] <fuzzie> i think they must be selectable.
[00:04:01] <fuzzie> That function is broken, for that reason.
[00:04:45] <cfchris6> ah it works, but the mouse cursor does not match
[00:05:17] <cfchris6> it changes from spell icon to the hand icon on mouseover
[00:05:19] <fuzzie> i think zefklop deliberately only made it work for bg1, because it is so broken :) but then it never got fixed
[00:06:16] <fuzzie> but there is a PortraitButtonOnMouseEnter in the GUIScript
[00:06:33] <fuzzie> maybe you can change the cursor there
[00:07:05] <cfchris6> hm another funny thing: that char seems to move from map to map now
[00:07:23] <cfchris6> not sure wheather that is because it has full hp again
[00:07:37] <tomprince> banter patch is pushed.
[00:07:49] <cfchris6> i.e. on every map where I am there is the corpse of that char :)
[00:08:25] <tomprince> I'd actually rather not have the new/delete patch applied, since I don't actually think that there is any issue with cross-module allocation.
[00:09:37] <fuzzie> well, if anyone does report a problem, i agree with you that making sure they are not statically linking the runtime library is a better first idea.
[00:10:03] <fuzzie> since as you have pointed out, it makes no sense, and there are cross-module allocations in gemrb anyway.
[00:10:31] <fuzzie> so, ok :)
[00:10:42] <fuzzie> i just don't want to lose any patches.
[00:11:10] <tomprince> I can roll a patch to get rid of the contusions we go to avoid that. But I would rather wait until things settle down somewhat before I do that. Since most of my patches play with a bunch of plugins. :)
[00:11:33] <fuzzie> sure, there is no point unnecessarily rewriting everything.
[00:12:11] <tomprince> I still have all my patches in git. Not all of them are rebased, and I think some are obsolete. But I will review them, and push any I think are still worthwile.
[00:12:43] <tomprince> I will roll that patch, once the backlog is somewhat clearer.
[00:12:49] <fuzzie> cfchris6: The cursor bug also requires changes on the C++ side, unfortunately.
[00:13:47] <fuzzie> cfchris6: Do you have an account on the wiki? Putting the bugs you find on the wiki's todo page or the sourceforge bug tracker would be appreciated, most are easy to fix, I just don't have time right now.
[00:14:17] <cfchris6> I'll create one
[00:15:51] <fuzzie> (I can see: the wrong heal index, the HP gain while dead, the cursor issues, the inability to select dead chars.)
[00:17:13] <cfchris6> I had some others but I think those are alredy known, e.g. wrong mousecursor on mouseover of hostile npcs or dropped items, nps dissapearing (seems to happen when animation not found?)
[00:17:44] <fuzzie> The animation problems are known, although I don't know anything about that.
[00:17:51] <fuzzie> I don't know about the wrong mouse cursor, though.
[00:17:54] <cfchris6> the cursor issues are btw already on the todo list
[00:18:05] <cfchris6> (those concerning portraits)
[00:18:34] <fuzzie> oh :) right, i have been ignoring that because the whole thing needs wrewriting.
[00:19:04] <cfchris6> There are some cases where on mouseover of dead hostile npcs there is still a sword appearing, and there are some cases where mouseover of a hostile living npcs turns the cursor into a "forbidden"-sign instead of a sword
[00:19:48] <fuzzie> interesting
[00:20:10] <cfchris6> however I am not yet sure on how to reproduce this :(
[00:20:48] <fuzzie> that is enough information, i thin.
[00:20:57] <fuzzie> i don't remember how the logic works.
[00:21:10] <fuzzie> but it can go on my list of things to look at :)
[00:21:17] <cfchris6> "Looks like there was an error on sending the password mail. Please contact the admin!"
[00:30:52] <fuzzie> hm
[00:33:58] <fuzzie> i guess lynx is the admin, i don't see what to poke.
[00:34:09] <fuzzie> i will have to remember..
[00:34:12] <fuzzie> ninight
[00:34:44] <cfchris6> for now I put them at http://nowhere.ws/dump/gemrb-bugs.txt will put them in the wiki, later.
[00:34:48] <cfchris6> godd night, fuzzie
[00:34:53] <cfchris6> s/godd/good/
[01:51:24] <Edheldil_> I will have to poke lynx too, looks like I can't remember my wiki password
[01:52:17] <Edheldil_> btw, all other modules except of launcher and installer are moved to git. Win32 renamed to win32, chitem renamed to dltcep
[01:56:04] <tomprince> Two papers on C++ template magic.
[01:56:11] <tomprince> http://wanderinghorse.net/computing/papers/classloading_cpp.html
[01:56:16] <tomprince> http://wanderinghorse.net/computing/papers/generic_cleanup_cpp.html
[02:34:22] --> ratpor has joined #GemRb
[02:39:27] <tomprince> Edheldil: Are you going to post the lua plugin?
[02:43:56] <-- Maighstir_laptop has left #GemRb
[02:46:16] --> Maighstir_laptop has joined #GemRb
[02:46:55] <-- Maighstir_laptop has left #GemRb
[03:21:27] <tomprince> In Actor::SetColor, should it be (value |= gradient) <<=8
[03:22:02] <tomprince> Or value |= (((ieDword)gradient) <<=8)
[03:22:16] <tomprince> Or even value |= (gradient << 8)
[04:31:54] --> Maighstir_laptop has joined #GemRb
[04:50:07] <Genraznx> well its comforting I may have a artist for the game
[05:08:19] <-- ratpor has left IRC (Quit: Get used to disappointment.)
[05:40:32] <Edheldil_> tomprince, http://www.eowyn.cz/gemrb/gemrb_lua.patch
[05:49:26] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[06:28:09] <Gekz> Edheldil: nice patch
[06:42:05] <tomprince> Edheldil: That is missing the actual plugin. :)
[07:04:02] <-- Edheldil_ has left IRC (Read error: Connection reset by peer)
[08:04:19] --> Edheldil_ has joined #GemRb
[08:57:04] <Genraznx> the new portraits in Puzzle Quest would work quite nicely for BG
[09:44:09] <fuzzie> tomprince: that code is just broken atm?
[09:44:26] <tomprince> What code?
[09:44:34] <fuzzie> the SetColor gradient
[09:45:45] <fuzzie> i have only just woken up, but doesn't that always produce zeros? since the shift drops all the bits.
[09:46:07] <tomprince> I don't know. I was running GemRB through clang, and yes, that is the error it gave.
[09:46:18] <tomprince> I don't know what it is supposed to do.
[09:46:42] <fuzzie> The (ieDword) version.
[09:47:16] <tomprince> without the = in <<= ?
[09:47:25] <fuzzie> no.
[09:47:29] <fuzzie> then it makes no sense :)
[09:48:37] <fuzzie> The intention is just to expand 'gradient' to fill the entire word, I guess.
[09:49:19] <fuzzie> I'm pretty sure we only need the first three shifts (well, two), though.
[09:49:34] <fuzzie> But I don't really understand the code; wjp might.
[09:49:51] <tomprince> Well, then shouldn't gradient be ieDword
[09:50:20] <fuzzie> Oh, sorry. Yes, that's what I meant.
[09:51:14] <fuzzie> And so there's not actually any need for the 'value' variable.
[09:51:56] <fuzzie> (Does clang compile the tree?)
[09:52:47] <tomprince> Almost, there are a bunch of sign-compare errors in Sliders.cpp
[09:53:42] <tomprince> http://pastebin.ca/1853763
[09:54:14] <tomprince> Plus a bunch of warnings about extraneous semicolons that I fixed.
[09:55:06] <fuzzie> not awake enough to work out whether those should be signed or not, at a glance :)
[09:55:25] <tomprince> Well, I'll let you wake up first then. :)
[09:55:34] --> kettuz has joined #GemRb
[09:58:35] <tomprince> Then we can depend on clang to generate bindings. :p
[09:59:52] <fuzzie> certainly better suited to that than actually compiling things :)
[10:00:55] <tomprince> Huh? I believe that Clang/LLVM are self hosting now.
[10:01:18] <tomprince> The code I am using is the 2.7 prerelease which should be out in a month or so.
[10:01:54] <tomprince> Plus, it has much nicer errors that gcc.
[10:03:06] <fuzzie> clang has been self-hosting for .. a month or so?
[10:03:36] <tomprince> Something like that.
[10:03:40] <fuzzie> but it is definitely not complete for C++, despite having enough to mange itself :)
[10:04:08] <tomprince> http://pastebin.ca/1853765 is the complete diagnostic for Actor.cpp, very nice.
[10:04:15] <fuzzie> but my experiments with it have it producing really awful code sometimes.
[10:04:36] <tomprince> Most of boost too, now.
[10:04:50] <tomprince> I don't know, I haven't played with that side of it much.
[10:05:20] <tomprince> I have a couple of compiler projects I should be working on, hence my interest.
[10:06:15] <fuzzie> LLVM itself is really *wonderful* for using as a compiler backend, at least :)
[10:08:23] <-- Nomad010 has left IRC (Remote host closed the connection)
[10:08:48] <fuzzie> I think the idea of producing bindings with something for gemrb is a really nice idea, I just don't think there's any way we can depend on that kind of thing for the core games right now. Definitely nothing stopping you from making it work for JavaScript, or Lua, or even conditionally for Python.
[10:09:11] <fuzzie> But if your only aim is to get rid of the manual interface, I guess that's not very helpful.
[10:09:41] <tomprince> I definitely do want to get rid of the manual interface at some point.
[10:11:54] <tomprince> But, at this point I don't know what the right tool to generate the bindings is.
[10:12:26] <tomprince> It seems like there isn't really a good tool out there to generate C++ bindings.
[10:13:21] <tomprince> There are a few tools that use gccxml. And a few others that use their own parser.
[10:13:34] <tomprince> The rest seem to need a santized header to work with.
[10:14:04] <tomprince> Which makes sense, since there hasn't really been a good programable C++ parser available.
[10:20:13] <wjp> fuzzie: yes, I'm fairly sure the intention in Actor::SetColor is to fill value with gradient bytes
[10:20:33] <fuzzie> g'morning.
[10:20:42] <tomprince> morning.
[10:22:08] <fuzzie> Given it doesn't seem to work right now, it's probably a good idea to check the effect against the original again, anyhow.
[10:28:32] <wjp> for the import: do you want the master, plugins and banter branches all uploaded to SF?
[10:30:33] <tomprince> Doesn't matter to me, definitely master.
[10:30:53] <tomprince> Fuzzie was going to integrate the banter patch at some point.
[10:31:03] <tomprince> And the plugins branch is in flux.
[10:31:26] <tomprince> It is up to you.
[10:31:48] <wjp> fuzzie: any preference?
[10:31:58] <fuzzie> It makes more sense to me to just keep the master branch on sf.
[10:32:03] <wjp> ok
[10:32:10] <tomprince> It probably doesn't make sense to put plugins on sf, unless I can update it there.
[10:32:32] <wjp> easy enough to upload the others later if necessary
[10:32:33] <tomprince> Everybody who cares probably knows about the or.ca repo anyway. :)
[10:32:43] <fuzzie> But that is a general thought, nothing specific to tomprince's branches.
[10:33:32] <fuzzie> thanks to git I don't have to worry about losing any of this once cloned..
[10:33:50] <tomprince> I am quite willing to add anybody to the or.cz repo.
[10:34:10] <tomprince> For experimental stuff, or whatever.
[10:34:31] <fuzzie> Can people fork easily on or.cz?
[10:34:57] <tomprince> I think so.
[10:36:34] <tomprince> Yes, click that fork button on the main repo page. :)
[10:36:36] <fuzzie> That model makes more sense to me than sharing development repos.
[10:38:04] <fuzzie> But then forking the gemrb.git repo on or.cz doesn't make a lot of sense if it's not master.
[10:40:54] <fuzzie> Ah well, not very important.
[10:41:41] * wjp drums fingers idly... 40%...
[10:43:00] <Edheldil_> morning, guys
[10:44:52] <wjp> ok, I think that should do it
[10:44:54] <wjp> hi
[10:45:18] <wjp> http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=summary
[10:45:25] <wjp> tomprince: thanks for the conversion work!
[10:45:39] <wjp> (and the explanation; very useful to know :-) )
[10:46:32] <tomprince> No problem. Didn't really take much work, maybe an hour or two, plus waiting for git-svn and git-filter-branch to run.
[10:46:49] <tomprince> Plus, I get the benefit of a sane vcs for gemrb. :)
[10:46:53] <fuzzie> what's the git url?
[10:47:10] <fuzzie> sf gives me one labelled read-only.
[10:47:25] <wjp> ssh://USER@gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[10:48:19] <fuzzie> thanks
[10:48:27] <Edheldil_> ok, should I setup the mailer or did you already do it?
[10:48:40] <wjp> I didn't yet
[10:49:04] <Edheldil_> ok, I will
[10:49:08] <wjp> thanks
[10:49:37] <tomprince> Was there talk of push the first one or two commits from the plugin branch, so that fresh clones wont have stuff that goes away immediately?
[10:49:50] <fuzzie> i'll do that now.
[10:50:11] <Edheldil_> tomprince, ?
[10:50:37] <tomprince> Yes.
[10:50:41] <Edheldil_> fuzzie, wait, you will test the hooks as well
[10:52:25] <tomprince> Edheldil_: That patch you posted didn't include the LuaScript directory.
[10:54:26] <Edheldil_> ok, the hook should be set up
[10:54:56] <Edheldil_> tomprince, I see ... svn diff was not enough :(
[10:57:37] <tomprince> You could probably do git init; git fetch; git read-tree origin/master; git add gemrb/plugins/LuaScript; git diff
[10:58:36] <tomprince> Although, the read-tree should have a -u on it.
[10:59:17] <fuzzie> Sorry, just doing a last paranoid build test on this.
[11:00:33] <tomprince> A few more minutes won't hurt any thing ... it has already been several months. ;)
[11:00:43] <fuzzie> Unfortunately, it fails.
[11:01:29] <fuzzie> The cmake files haven't been updated, I'd thought I'd done that, but apparently not for the Great Rename.
[11:04:52] <fuzzie> And they're also not updated for the makefile update; cmake is still building libXXX.so.
[11:07:37] <tomprince> I'm not sure how to make cmake generate libs without the lib prefix.
[11:07:59] <fuzzie> You can use SET_TARGET_PROPERTIES to modify the PREFIX property (to "").
[11:10:10] <tomprince> Would it make sense to move to just cmake. Or, if OSX/MinGW can be made to work, just autoconf?
[11:10:28] <tomprince> It seems silly to maintain 2 build systems in parallel.
[11:11:07] <fuzzie> Well, I personally dislike cmake, but it does work everywhere.
[11:12:27] <tomprince> Do we have someone who can test OSX and MinGW? I can actually do MinGW/Wine, but not native.
[11:12:31] <fuzzie> And we just don't have anyone maintaining autoconf. And patches adding manual -lpthread, -lz, -lpng statements are not really moving in that dire ction. :)
[11:15:21] <fuzzie> http://fuzzie.org/nfs/gemrb/cmake_names.txt seems to work.
[11:16:17] <tomprince> Looks sane.
[11:18:47] <tomprince> The reason i went with bare -lz, -lpng, is that the test we run checks to see if bare -lz, -lpng brings in the library.
[11:19:48] <tomprince> libz, libpng, libjpeg don't come with pkg-config files or anything.
[11:20:28] <tomprince> We could probably have configure flags to set the CFLAGS and LDFLAGS for each library, but that seems overkill.
[11:20:49] <fuzzie> And this is where cmake has the advantage, unfortunately.
[11:21:03] <fuzzie> Because it works where those assumptions aren't the case. :)
[11:21:39] <fuzzie> I seem to recall that your patch removes the ability to pass a path for the libraries at all, but I haven't looked today, so I might be mistaken.
[11:22:09] <Edheldil_> EXTRA_CFLAGS and EXTRA_LDFLAGS ;-)
[11:22:28] <Edheldil_> ah
[11:23:51] <Edheldil_> ok, the git builds for me w/ autotools
[11:24:01] <fuzzie> libgemrb_core.so ends up in prefix/plugins with cmake, that is a bit silly.
[11:24:01] <tomprince> Even just CFLAGS and LDFLAGS work.
[11:24:25] <fuzzie> Okay, let's see if I break the repository now.
[11:24:42] <CIA-43> GemRB: 03tom.prince * r814470ea6642 10gemrb/ (42 files in 39 dirs):
[11:24:42] <CIA-43> GemRB: Simplify plugin makefiles.
[11:24:42] <CIA-43> GemRB: Note: plugins-prepare.sh needs to be rerun.
[11:25:14] <fuzzie> More to the point, you need to delete the existing lib*.so files/symlinks.
[11:27:11] <tomprince> Now that you mention that, that was probably part of the reason the makefile changes were with the other changes, since the plugin .so name changed at the same point as the symbols that are looked up.
[11:27:25] <tomprince> I forgot all about that.
[11:27:36] <tomprince> Oh well.
[11:27:50] <fuzzie> Yes, I realised yesterday that I should have waited on that change, too. :|
[11:30:09] <fuzzie> Does HAVE_FORBIDDEN_OBJECT_TO_FUNCTION_CAST really only apply to gcc?
[11:30:47] <fuzzie> I don't know if there are any attempts to compile using anything else, I guess.
[11:30:54] <fuzzie> If it's a good patch, it needs removing from cmake too.
[11:32:42] <tomprince> Well, it doesn't apply to windows, since that doesn't use dlsym.
[11:33:30] <fuzzie> I'm not sure this PlayMode/SaveDir patch is good.
[11:33:33] <tomprince> clang accepts it.
[11:34:24] <fuzzie> I thought we'd worked out that the usage of mpsave was independent of the expansion selection.
[11:35:37] <fuzzie> and the comments in iwd/PartyFormation.py are mangled by the patch.
[11:36:03] <tomprince> Well, I have *no* idea about the GUIScript side.
[11:36:35] <tomprince> I think splitting the variables makes sense.
[11:36:42] <fuzzie> Well, lynx OKed it, so if you could fix the comments I'll apply it. I just think it's probably still wrong *behaviour* :)
[11:37:52] <Lightkey> so I guess, now that Subversion has stopped, I have to clone everything again?
[11:38:08] <fuzzie> Tweaking this stuff in the functions of Start2.py doesn't make any sense, though.
[11:38:41] <fuzzie> Either the variables should be set when you make the oldgame/newgame choice, or they should be set in the GUILOAD/CharGen scripts.
[11:39:54] <fuzzie> Lightkey: indeed so
[11:44:43] <tomprince> fuzzie: or.cz/savedir and I agree, I don't know if the variables are being set in the right place, I just tried to make the minimal change consistent with splitting them up.
[11:45:55] <tomprince> Note: for now, I'll keep rebase or.cz/plugins.
[11:46:17] <fuzzie> Well, the The Great Rename patch needs fixing for cmake.
[11:46:17] <tomprince> As things are getting cherry-picked out of it.
[11:46:34] <fuzzie> Would you prefer I modify it, or commit it plus a cmake fix?
[11:46:46] <fuzzie> Sorry, I mean, plus a seperate cmake fix commit.
[11:48:13] <tomprince> Modify it.
[11:48:28] <tomprince> Better to always have a working build.
[11:49:01] <tomprince> I was just lazy, and not as familiar with cmake, and didn't know if the patches would get accepted.
[11:50:16] <tomprince> To a certain extant, the patches were/are there for discussion.
[11:51:00] <tomprince> s/extant/extent/
[11:52:53] <fuzzie> Okay. I'll fix that and commit the obvious patches (SaveDir, semicolons, ResourceMgr centralisation, etc) later, if no-one does so before me.
[11:54:25] <tomprince> Excellent.
[12:03:32] <-- kettuz has left IRC (Quit: Leaving)
[12:35:42] --> lynxlynxlynx has joined #GemRb
[12:35:42] --- ChanServ gives channel operator status to lynxlynxlynx
[12:39:51] <fuzzie> those savedir comments are still mangled (they're all 'second row' after the patch)?
[12:40:37] <lynxlynxlynx> yes
[12:41:06] <lynxlynxlynx> i see the repo is up
[12:41:09] <fuzzie> yes :)
[12:42:14] <lynxlynxlynx> Edheldil: i'd like to have the diffstat output before the diffs, so it is easier to tell if something important is being modified
[12:43:02] <lynxlynxlynx> anyone feel the same?
[12:44:21] <fuzzie> it is is possible.
[12:44:26] <fuzzie> if it is possible.
[12:51:42] <lynxlynxlynx> sure it is
[12:52:12] <lynxlynxlynx> http://lists.ibiblio.org/pipermail/sm-commit/2009-August/025421.html ;)
[12:52:43] <fuzzie> that is nicer :)
[12:52:47] * wjp agrees
[12:53:16] <fuzzie> especially the diffstat applying to the whole set of changes.
[12:56:11] <tomprince> fuzzie: If you just want to fix it and apply it. git commit --amend will keep the authorship.
[12:56:16] <tomprince> Or I can respin it.
[13:02:05] <-- raevol has left IRC (Quit: Leaving.)
[13:02:51] --> raevol has joined #GemRb
[13:04:31] <lynxlynxlynx> eh, no need to be so purist about comments, incremental changes are fine
[13:04:49] <fuzzie> well, the comments get destroyed
[13:05:03] <fuzzie> but i'm not somewhere that i can fix the commit right now.
[13:10:00] <tomprince> How does that look?
[13:12:40] <fuzzie> looks ideal. can you merge it, lynx? i'll bbiaw.
[13:20:01] <-- raevol has left IRC (Quit: Leaving.)
[13:23:39] <lynxlynxlynx> can't do anything until monday
[13:24:04] <lynxlynxlynx> i ran from a meeting to make lunch and now i have to run back
[13:24:46] <lynxlynxlynx> tommorow is another early rise -> touring
[13:25:25] <wjp> the savedir branch?
[13:25:49] --> Maighstir_laptop has joined #GemRb
[13:26:21] <wjp> let's see if I can manage that without blowing up my local repo :-)
[13:26:24] <lynxlynxlynx> i checked the first commit, don't know about any followup
[13:29:54] <tomprince> wjp: Yes. There is only the one commit. The only changes have been to the comments in iwd/PartyFormations.py
[13:32:13] <wjp> I'm guessing the procedure is: rebase master to savedir, commit --amend to set Committer to me, push to SF?
[13:33:04] <tomprince> You could even just fetch it, and then push it.
[13:37:26] <fuzzie> that is what i have been doing.
[13:37:48] <wjp> what is the exact fetch command for that?
[13:39:14] <tomprince> Well, if you already have the repo setup, git fetch repo-name.
[13:39:50] <tomprince> The commit should just show up as refs/remotes/repo-name/savedir
[13:40:24] <tomprince> If not, git remote add or.cz git://repo.or.cz/gemrb.git
[13:40:34] <tomprince> git fetch or.cz
[13:40:44] <wjp> I have the remote already
[13:40:58] <tomprince> git push sf or.cz/savedir:master
[13:41:50] <tomprince> To see what will push, you would do git fetch sf; git log sf/master..or.cz/savedir
[13:44:45] <wjp> but that'll leave Committer set to <cougar@hermes>. Is that what it should be?
[13:45:41] <wjp> I'm not overly familiar with git conventions yet
[13:46:12] <wjp> (I've only used it with git-svn locally or with single-user repositories so far)
[13:46:41] <tomprince> I should probably have something sane there. I mostly use git for single-user repositories as well, and then the commiter tells me what machine I was on.
[13:47:06] <fuzzie> we probably always want the committer to be whoever did the final push, if that's possible to configure.
[13:49:20] <wjp> fuzzie: that sounds good to me
[13:49:38] <tomprince> Well, that is fine for the kind of development that has been going on. But if we start having branches, and merging and things, then we want stable commit-ids, which is broken by changing the commiter.
[13:49:45] <tomprince> But that is probably for the future.
[13:50:08] <fuzzie> Well, the sensible alternative of adding a Signed-off-by presumably also changes that?
[13:50:48] <tomprince> In that case, you can go 'git checkout or.cz/savedir; git commit --am; git push HEAD:master'
[13:50:51] <tomprince> Yes, that does.
[13:51:37] <Edheldil_> I have put the summary to the front
[13:51:54] <Edheldil_> bye for now, I will be back maybe tomorrow evening
[13:56:36] <-- Edheldil_ has left IRC (Quit: Really?)
[13:59:56] <wjp> ok, things successfully build and run
[14:10:21] <-- Maighstir_laptop has left #GemRb
[14:21:41] <CIA-43> GemRB: 03tom.prince * rb198d67b8779 10gemrb/gemrb/ (9 files in 4 dirs): Make SaveGameIterator key save directory off SaveDir instead of PlayMode.
[14:40:47] --> Maighstir_laptop has joined #GemRb
[15:05:52] <CIA-43> GemRB: 03fuzzie * r938b41f37512 10gemrb/gemrb/GUIScripts/bg1/GUISTORE.py: fix bg1 store heal purchases
[16:35:36] --> Nomad010 has joined #GemRb
[17:20:00] --> Avenger_ has joined #GemRb
[17:20:25] --- Avenger_ is now known as Avenger
[17:20:34] --- ChanServ gives channel operator status to Avenger
[17:20:38] <Avenger> hello
[17:21:34] <Avenger> i recompiled gemrb from the git repo. Everything works, but the music sounds jerkier than i remember
[17:22:41] <Avenger> hmm, ok, maybe it was because i ran it in gdb
[17:24:49] <fuzzie> i think nothing profiles differently from 0.6.0, except BIKPlayer, which didn't exist then
[17:32:45] <fuzzie> I am being very slow at including patches because I am trying to test that kind of thing.
[17:33:41] <fuzzie> I need to rope wjp and Ed into doing it :)
[17:38:02] <CIA-43> GemRB: 03fuzzie * rb7052cebff2f 10gemrb/gemrb/plugins/Core/Projectile.cpp: fixes for magic missile projectiles (curved paths and simultaneous creation)
[17:38:55] <fuzzie> i tried it with bg1 and bg2 only
[17:39:10] <fuzzie> but it looks good :)
[17:39:29] <fuzzie> i will work on it more later
[18:12:18] <fuzzie> tomprince: http://fuzzie.org/nfs/gemrb/0001-The-Great-Rename-Part-1.txt is with the tested cmake changes.
[18:26:52] <tomprince> Yes.
[18:27:53] <lynxlynxlynx> Avenger: how do you like the last logo?
[18:32:07] <fuzzie> ok, i'll push the rename patch, it is easy enough to revert it without damage in git.
[18:33:57] <fuzzie> but everyone has to do another plugins-prepare.sh afterwards.
[18:34:54] <fuzzie> maybe we could automatically run that from the makefile?
[18:35:01] <CIA-43> GemRB: 03tom.prince * r74a9b3358a74 10gemrb/ (202 files in 37 dirs):
[18:35:01] <CIA-43> GemRB: The Great Rename (Part 1)
[18:35:01] <CIA-43> GemRB: Rename file to be something sensible. At some point the classes should be renamed as well.
[18:35:01] <CIA-43> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:36:02] <fuzzie> ok, re-running plugins-prepare.sh doesn't even work.
[18:36:42] <lynxlynxlynx> is the change to it included in the patch?
[18:37:06] <fuzzie> yes, but ZLibMgr/ still exists, so old trees still get the wrong thing symlinked.
[18:37:25] <fuzzie> so a "rm -rf gemrb/plugins/ZLibMgr" is needed first.
[18:38:40] <fuzzie> well, i can revert that back if it causes problems.
[18:39:29] <lynxlynxlynx> or you can add it to the script
[18:42:10] <wjp> it still builds and runs ok for me
[18:42:10] <CIA-43> GemRB: 03wjpalenstijn * ra89d6c7f3026 10gemrb/gemrb/plugins/Core/Projectile.cpp: Fix warning
[18:42:38] <fuzzie> but your symlink is probably now pointing at a dead .so.
[18:43:01] <fuzzie> the correct solution would be to move the symlink creation into the makefiles, i guess, but that is annoying w/autoconf.
[18:43:22] <wjp> s/conf/make/
[18:47:15] <wjp> hm, we need a s/ZLibManger/ZlibManager/
[18:47:50] <fuzzie> do that?
[18:48:00] <wjp> doing it right now :-)
[18:49:27] <CIA-43> GemRB: 03wjpalenstijn * r707a893b111e 10gemrb/gemrb/plugins/ZLibManager/Makefile.am: Fix typo
[18:49:43] <wjp> you'll have to clean up some Manger files after building
[18:50:16] <fuzzie> I am just going to do "git clean -f -d" now, for sanity's sake.
[18:59:32] <fuzzie> ok, it builds+works fine for me with a clean git tree.
[19:00:12] <fuzzie> i suggest we apply no more rename/etc changes until we make sure it currently works for everyone?
[19:04:05] <tomprince> or.cz/gitignore
[19:05:13] <fuzzie> "git clean -x -f -d" then, I suppose. Maybe should put that somewhere until we fix the build system.
[19:09:00] <tomprince> What git clean -x -f -d? That should never be scripted.]
[19:09:17] <tomprince> Much like having and rm -rf somewhere
[19:09:21] <fuzzie> It seems the easiest way to fix build issues atm.
[19:09:43] <fuzzie> So I just wanted to leave it in the IRC log.
[19:10:09] <fuzzie> For "fix the build system", I mean that the build systems need to be responsible for he plugin symlinks or similar, I guess.
[19:10:25] <tomprince> rm -f ZLibMgr/.libs/*.so would probably work in plugins-prepare.sh, between the two ifs.
[19:10:47] <fuzzie> yes, but not for cmake.
[19:10:55] <fuzzie> and we'll have to do this every time we split things.
[19:11:00] --> ratpor has joined #GemRb
[19:11:09] <fuzzie> so there must surely be a more elegant solution.
[19:11:41] <fuzzie> i wrote a patch to zap the bad file for both cmake and automake, which is trivial, but i thought it was rather absurd to commit, given we'd need to add to it every time we do that kind of thing again.
[19:22:42] <CIA-43> GemRB: 03tom.prince * r3f701b1bc4e4 10gemrb/gemrb/plugins/ (15 files in 5 dirs):
[19:22:42] <CIA-43> GemRB: GetFactoryResource: Move this function from ResourceMgr to GameData.
[19:22:42] <CIA-43> GemRB: This in in preparation to split ResourceMgr.
[19:22:42] <CIA-43> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:24:08] <CIA-43> GemRB: 03tom.prince * r4ac1eecc4f47 10gemrb/.gitignore:
[19:24:08] <CIA-43> GemRB: gitignore: Add generated files, backups, and patch files.
[19:24:08] <CIA-43> GemRB: Signed-off-by: Tom Prince <cougar@hermes>
[19:25:33] <lynxlynxlynx> why diffs and patches? :(
[19:25:51] <fuzzie> is that bad?
[19:26:21] <fuzzie> i just committed it as better-than-nothing
[19:26:36] <lynxlynxlynx> it is for me, git status is a nice way to check for cruft/todos
[19:26:57] <lynxlynxlynx> finding paths to failed chunks is also easier
[19:27:05] <Avenger> if it isn't on the todo list yet: bink player needs bugfixing
[19:27:47] <fuzzie> Avenger: did the ffmpeg people fix the bugs?
[19:28:06] <Avenger> the ffmpeg player has no graphic artifacts
[19:28:08] <tomprince> lynxlynxlynx: Feel free to change it, i basically coppied my .git/info/exclude.
[19:28:11] <Avenger> only sound
[19:28:50] <lynxlynxlynx> i'd like a third opinion, so it wouldn't look like either is forcing theirs
[19:29:27] <Avenger> a third opinion on what?
[19:29:55] <tomprince> Well, anything that isn't there, I can through back into .git/info/exclude, so a smaller .gitignore is reasonable.
[19:29:58] <fuzzie> oh, right, i hadn't thought about it. yes, i would prefer they show up. i didn't look at the rest.
[19:29:59] <lynxlynxlynx> having patch files and similar marked as ignored (untracked) by git
[19:30:07] <tomprince> I did actually wonder about that.
[19:30:15] <fuzzie> we should have the minimum .gitignore that everyone is happy with.
[19:30:23] <fuzzie> Avenger: tried the missiles?
[19:30:26] <Avenger> uh, btw, i need some quick walkthrough, how do i update my sandbox using git?
[19:30:37] <lynxlynxlynx> git pull
[19:31:18] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[19:31:35] <Avenger> thx
[19:32:05] <fuzzie> make sure to delete the gemrb/plugins/ZLibMgr directory afterwards!
[19:32:24] <tomprince> http://pastebin.ca/1854090 is a makefile fragment that creates the *.so files. Although automake spits out warnings on it. And it depends on GNU Make.
[19:34:55] <fuzzie> where would you put that?
[19:35:43] <tomprince> All the plugin/*/Makefile.am, or something included by that.
[19:36:41] <fuzzie> just wondering if it would be simpler to just put the rule in every file.
[19:37:27] <tomprince> Well, if we made plugins/Makefile.am non-recursive, we could just put it in there.
[19:38:25] <fuzzie> btw: why not use cmake?
[19:38:43] <Avenger> yeah, it works
[19:38:47] <Avenger> nice
[19:39:45] <Avenger> oh, my. the jerky sound was not gdb, but valgrind!
[19:40:06] <Avenger> it has 50fps, otherwise, so i didn't notice i run it in valgrind
[19:40:12] <fuzzie> hehe
[19:40:19] <fuzzie> you know valgrind is an x86 emulator? :)
[19:40:36] <fuzzie> i don't have a fast enough machine to make that mistake!
[19:40:53] <Avenger> well, when i last ran it, it was terribly slow
[19:42:05] <tomprince> Well, I am more familiar with autotools, marginally. Given a choice, I usually default to autotools for building stuff.
[19:43:31] <Avenger> btw, we are good, most of the valgrind problems are in third party libs (but i didn't run gemrb for too long)
[19:45:41] <tomprince> I probably sound like a broken record, but I think that we should pick one build system and get rid of the other. ;)
[19:45:57] <CIA-43> GemRB: 03tom.prince * r325df015188f 10gemrb/gemrb/plugins/ (28 files in 9 dirs):
[19:45:57] <CIA-43> GemRB: ResourceMgr: Centralize all access to ResourceMgr to GameData.
[19:45:57] <CIA-43> GemRB: This way, we can refactor ResourceMgr without affecting anything else.
[19:45:57] <CIA-43> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:46:57] <CIA-43> GemRB: 03fuzzie * r7ea873e03dbb 10gemrb/gemrb/plugins/CMakeLists.txt: cmake build fix
[19:46:58] <fuzzie> Well, someone'd have to fix a lot of things either way.
[19:47:29] <fuzzie> If you pick cmake, you have to fix all the third-party builds. If you pick autotools, you have to fix all the non-gnu platforms.
[19:48:42] <tomprince> Third-party builds?
[19:48:55] <fuzzie> The maemo / gentoo / ubuntu / etc ones.
[19:49:00] <fuzzie> I think they're all using autotools.
[19:49:25] <fuzzie> And I have no idea if cmake works for all of them, although presumably it works fine for the normal Linux distros.
[19:50:05] <Lightkey> what is git fetch good for?
[19:50:10] <tomprince> I'm willing to fix all the non-gnu platforms, I just don't have access to OSX to test.
[19:50:28] <tomprince> It downloads all the changes, so you can look at them.
[19:50:47] <tomprince> git pull == git fetch + git merge, more or less.
[19:50:53] <Lightkey> well, I got that part :-)
[19:51:04] <fuzzie> Well, I have no good solution for the OS X testing.
[19:51:52] <tomprince> If you have local commits, git pull will create a merge. If you would rather rebase, for example, you would just git fetch.
[19:52:08] <cfchris6> or use git pull --rebase
[19:52:59] <tomprince> Or, if you want to look at what I am doing at or.cz, git fetch will let you look at the changes, with merging them.
[19:53:41] <Lightkey> the "let you look" part, how?
[19:54:00] <fuzzie> Or if you just want the objects so as to cherrypick random commits (sorry!), fetch is also helpful. :)
[19:54:14] <tomprince> git log, gitk
[19:54:30] <lynxlynxlynx> re 3rd parties: that's their job
[19:54:55] <fuzzie> lynxlynxlynx: i don't want to break any of the builds completely, though.
[19:55:06] <Avenger> ok, something tells me git push isn't the equivalent of commit
[19:55:15] <lynxlynxlynx> all it takes is a pointer in the release notes
[19:55:29] --> Maighstir_laptop has joined #GemRb
[19:55:36] <fuzzie> Avenger: 'git commit -a' will commit all your changes, then 'git push' to upload them to sourceforge.
[19:55:46] <lynxlynxlynx> Avenger: if it failed, either someone beat you to it and you don't have the latest thing anymore or you're not authed
[19:56:49] <fuzzie> But it's a really good idea to do 'git pull' first.
[19:58:14] <Avenger> any chance git remembers my sf password like svn does?
[19:58:17] <CIA-43> GemRB: 03avenger_teambg * r63964750b3db 10gemrb/gemrb/plugins/CREImporter/CREImporter.cpp: make sure some spell lists are not memory garbage
[19:58:57] <tomprince> Note about commit messgaes: git will handle any kind of commit message, but some git tools optimized for "one line summary, blank line, detailed description"
[19:59:05] <lynxlynxlynx> Avenger: ssh-agent
[19:59:15] <lynxlynxlynx> eval `ssh-agent`; ssh-add
[19:59:23] <fuzzie> if you have a key :)
[19:59:39] <lynxlynxlynx> but the latter one only works for one session
[19:59:39] <fuzzie> It looks like sourceforge only do git commits over ssh, which I guess is sensible.
[20:02:18] <fuzzie> lynxlynxlynx: what did you want removed from .gitignore, just *.patch and *.diff?
[20:02:50] <tomprince> I think *.orig and *.rej as well.
[20:04:29] <fuzzie> But hiding ~* + *.swp is good?
[20:04:34] <fuzzie> erm, *~.
[20:06:41] <Lightkey> omfsm this has a lot of options
[20:06:56] <Avenger> ok, now that the plugin system is reworked, some release functions are not called
[20:07:05] <Avenger> like in CREImporter, ReleaseMemoryCRE
[20:07:17] <fuzzie> Does it break?
[20:07:46] <Avenger> no break, just leak, and actually since they plugins are not dynamically reloaded, this is not even a serious leak
[20:08:00] <fuzzie> well, i would like to fix all leaks :)
[20:08:04] <Avenger> me too
[20:08:35] <Avenger> but is there anything that is called in a plugin on release now?
[20:08:50] <fuzzie> yes
[20:09:02] <fuzzie> grep for "PLUGIN_CLEANUP"
[20:09:30] <Avenger> coolness
[20:09:44] <fuzzie> you can see it in AREImporter.cpp, at the bottom
[20:10:11] <Avenger> yeah
[20:10:29] <tomprince> Not plugin release, but on GemRB quit.
[20:10:47] <fuzzie> i check if we missed anything else..
[20:11:20] <fuzzie> tomprince: we could fix that if we ever did want to dynamically reload plugins.
[20:11:42] <fuzzie> ok, no, CREImporter is the only one we missed
[20:12:21] <fuzzie> i will leave Avenger to fix that, if he is leak-checking?
[20:12:22] <tomprince> Yes. Although, there is a terminalogical confusion as plugin as .so file vs. plugin as object of a derived class of Plugin.
[20:12:53] <Avenger> yes i do
[20:13:50] <Lightkey> woo~ this is phun
[20:13:56] <CIA-43> GemRB: 03avenger_teambg * rae121474f429 10gemrb/gemrb/plugins/CREImporter/CREImporter.cpp: leak fix in CREImporter
[20:14:55] <CIA-43> GemRB: 03fuzzie * r28393dfc6133 10gemrb/.gitignore: don't include non-build cruft in .gitignore
[20:19:23] <fuzzie> the dungeon-escape cutscene is getting better, with the magic missiles
[20:20:10] <CIA-43> GemRB: 03avenger_teambg * r5bd3df376786 10gemrb/gemrb/plugins/Core/SaveGameIterator.cpp: fixed a leak in SaveGameIterator
[20:20:13] <CIA-43> GemRB: 03avenger_teambg * ra0da1844db31 10gemrb/.gitignore: Merge branch 'master' of ssh://avenger_teambg@gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[20:20:51] <fuzzie> just need to add some messaging, fix the music and the particles..
[20:21:05] <Avenger> huh, i'm unsure what's this last 'merge' line from me
[20:22:16] <wjp> you probably did a push without doing a pull first
[20:22:18] <tomprince> Do git fetch, then gitk --all, to see what happened.
[20:22:42] <fuzzie> it means you pushed a change that got automatically merged with something that was already pushed; it is just a "git automatically merged this" warning.
[20:23:11] <lynxlynxlynx> Edheldil: there's an option to skip merges
[20:23:14] <fuzzie> i wonder if we can suppress them from cia.
[20:23:19] <fuzzie> oh, lynx is ahead of me :)
[20:23:41] <lynxlynxlynx> --no-merges to git-log
[20:23:56] <fuzzie> that would make more sense, we don't need them reported
[20:24:02] <lynxlynxlynx> the underlying stuff should have it too
[20:25:33] <fuzzie> Avenger: that leak is also a good catch, i missed it..
[20:25:53] <Avenger> valgrind is the king :)
[20:26:50] <Avenger> we have more leaks, but not all are clear catch
[20:27:31] <lynxlynxlynx> try the other tools, if it makes sense, it can do much more
[20:27:59] <Avenger> lol
[20:28:03] <Avenger> bikplayer leaks some 19M
[20:29:33] <fuzzie> well, it is still an experiment :)
[20:30:00] <Avenger> it is the c_pic buffer, but in EndVideo it is supposed to be released
[20:30:36] <Avenger> oh, it is called repeatedly
[20:31:30] <Avenger> get buffer is called all the time, but the original planes are not freed
[20:31:43] <Avenger> maybe there could be some clever memory management
[20:32:16] <Avenger> i guess, it shouldn't call get_buffer in every frame
[20:32:59] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[20:33:45] <Avenger> i think if someone fixes this, it will fix most of the video artifacts as well
[20:33:53] <tomprince> fuzzie: What do you think of the KEYImporter split?
[20:34:27] <fuzzie> tomprince: wow, you are very dedicated to rebasing.
[20:34:55] <tomprince> At least today.
[20:35:17] <fuzzie> It makes sense to move the non-KEY bits out of KEYImporter.
[20:35:46] <tomprince> If I keep rebasing things, it makes it easier for people to apply them, which means my backlog is smaller, so less need to rebase. :)
[20:35:59] <fuzzie> But I would prefer to avoid making any other resource changes until I have more of a chance to make sure that nothing hasbroken.
[20:36:55] <fuzzie> Which is why I am cherry-picking the trivial patches..
[20:37:10] <-- ratpor has left IRC (Ping timeout: 276 seconds)
[20:37:59] <tomprince> I understand that. Although, the ones you cherry picked were the ground work for the split.
[20:38:17] --> Maighstir_laptop has joined #GemRb
[20:39:04] <tomprince> I was just wondering if you would prefer to apply the split before the dictoranry patch, since you weren't sure of that one.
[20:39:15] <tomprince> It is a non-trivial rebase that.
[20:40:45] <tomprince> Also, it would make sense to do that before the sound support+BMPWriter, so that we never need to introduce GetFile.
[20:41:36] <fuzzie> That was my thought also.
[20:41:43] <fuzzie> But I really need to learn how to use git better.
[20:42:08] <fuzzie> How do I discard changes which are in the working tree but not in the index?
[20:43:04] <tomprince> Well, if that makes sense to you, I can resort the patches.
[20:45:11] <Lightkey> maybe post the switch in the forum, since that seems to be the 'official' news page?
[20:45:39] <tomprince> There must be a better way, but git commit; git reset --hard; git rest --soft HEAD~1 works.
[20:47:42] <tomprince> git checkout-index -a -u, or maybe -a -u -f should also work.
[20:48:42] <fuzzie> ah, wonderful :)
[20:49:40] <lynxlynxlynx> short for git stash
[20:50:07] <fuzzie> git stash seems to try creating a commit, which is not very helpful.
[20:50:55] <lynxlynxlynx> it's behind the scenes, unless it changed since i last used it
[20:51:06] <fuzzie> oh, right, comparing to the 'git commit' suggestion.
[20:51:13] <lynxlynxlynx> which was a while ago (i avoid it ever since)
[20:51:22] <fuzzie> right, that also doesn't work here :-) messing with unmergedtrees.
[20:52:31] <tomprince> Well, git stash creates two commits if index != work-tree. And has options some options for dealing with the index.
[20:53:09] <fuzzie> well, all i know is that it gives me the same errors either way, flailing about how i still have files in the index marked as unmerged.
[20:53:22] <fuzzie> but checkout-index is ideal, and led me to update-index.
[20:56:54] <tomprince> git-add is wrapper around git update-index.
[20:57:12] <tomprince> git-add basically calls git-update-index for each file.
[20:57:18] <fuzzie> i mean, sorry, it is not important. i just noticed that cherry-picking the semicolons commit led to a very messy situation, since files were split under it, and was curious how you'd resolve that.
[20:58:47] <tomprince> Probably manually.
[20:59:42] <fuzzie> Well, I mean, the index ended up fairly confused.
[21:00:02] --> ratpor has joined #GemRb
[21:00:47] <lynxlynxlynx> don't forget git reflog
[21:01:08] <cfchris6> btw: I noticed levelup is not correctly implemented for BG1 mages. There is no chance to select additional spells.
[21:02:01] <cfchris6> (i.e. I am level 5 now but still do only know the magic missiles and identify spell I had chosen at char creation)
[21:02:15] <tomprince> Well, when rebasing, what I usually do is fix up all the files, then run git add -u.
[21:02:26] <tomprince> But that might not work in the case of spilt files.
[21:03:16] <lynxlynxlynx> cfchris6: interesting
[21:03:52] <Avenger> how do i undo a local change and get the original from repo?
[21:04:03] <lynxlynxlynx> git checkout stuff
[21:04:36] <fuzzie> yes, 'git checkout filename' for one file, or 'git reset --hard' to reset *everything*.
[21:06:36] <lynxlynxlynx> cfchris6: oh
[21:06:55] <lynxlynxlynx> bg1 doesn't have sorcerers, you need to learn spells via scrolls
[21:07:33] <cfchris6> lynxlynxlynx: meh. my bad, i mixed that up. :/
[21:10:05] <cfchris6> do you know which attribute decides the probability of success for learning a spell from a scroll?
[21:10:27] <fuzzie> tomprince: Sorry, I didn't reply to you; the dictionary seems reasonable, I just would like to look it over closely, I'd hope to take it first.
[21:11:02] <lynxlynxlynx> intelligence
[21:11:09] <lynxlynxlynx> check your record
[21:11:27] <lynxlynxlynx> good night
[21:11:41] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[21:11:56] <cfchris6> hm, I tried about six times to learn a spell from a scroll and it didn't succeed
[21:14:10] <-- CIA-43 has left IRC (Ping timeout: 248 seconds)
[21:15:43] --> CIA-43 has joined #GemRb
[21:16:39] <Avenger> ok, this was a major leak :)
[21:16:44] <CIA-43> GemRB: 03avenger_teambg * r45ca093d9b2e 10gemrb/gemrb/plugins/BIKPlayer/BIKPlayer.cpp: swap frames and free old one even when skipping one
[21:16:56] <Lightkey> back from the loo? ;p
[21:17:30] <Avenger> hey, i know it is crap, but still
[21:17:38] <-- cfchris6 has left IRC (Ping timeout: 260 seconds)
[21:18:10] <Lightkey> reminds me *goes*
[21:19:22] --> cfchris6 has joined #GemRb
[21:19:36] <CIA-43> GemRB: 03tom.prince * rb4ab522ec121 10gemrb/gemrb/plugins/ (14 files in 4 dirs):
[21:19:36] <CIA-43> GemRB: Get rid of extraneous semicolons.
[21:19:36] <CIA-43> GemRB: Clang complains about extraneous semicolons.
[21:19:36] <CIA-43> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[21:20:30] <Lightkey> btw how do I get the checkout live and everything and not just trunk?
[21:20:41] <Lightkey> +to
[21:22:27] <Lightkey> removing /gemrb from the URL does not quite work
[21:22:34] <tomprince> What do you mean live?
[21:22:42] <tomprince> All the history is in the clone.
[21:22:57] <tomprince> do git tag -l to see all the tags.
[21:23:48] <Lightkey> oh, I meant things like ie_shell
[21:24:19] <Avenger> huh, anyone cared about dltcep?
[21:25:17] <tomprince> They are seperate repositories now. http://gemrb.git.sourceforge.net/git/gitweb-index.cgi
[21:26:14] <Lightkey> and gemrb installer? and.. was there anything else?
[21:27:26] <Lightkey> oh, thanks
[21:29:21] <Avenger> what is gemrb hooks
[21:29:28] <Avenger> it just gives a 404
[21:34:14] <fuzzie> that is just the directory where the CIA/commit mailing list scripts are stored, I think
[21:35:00] <fuzzie> and Edheldil converted it all, including dltcep :) although the svn is still there, of course
[21:42:18] <fuzzie> Lightkey: Updating the forum is a good idea, but someone should update the wiki first.
[21:44:09] <Lightkey> lynxlynxlynx did that already
[21:44:19] <fuzzie> only half of it :)
[21:46:12] <fuzzie> putting 'svn' into the search thing shows all the rest - i could update it, if no-one else does
[21:49:04] * Lightkey is mucksmäuschenstill
[22:11:33] <tomprince> fuzzie: I have shuffle the patches around, so the KEYImporter stuff is at the front.
[22:12:52] <tomprince> The changes look much saner this way.
[22:42:33] <Avenger> bye
[22:42:35] <-- Avenger has left IRC (Quit: bye!)
[23:00:09] <fuzzie> I think the same comment about it being a good idea to be explicit about failing plugins there would be nice.
[23:01:06] <fuzzie> That didn't make much sense. :) But I mean, a clearer error if the RESOURCE_DIRECTORY or RESOURCE_KEY plugins are missing.
[23:01:58] <fuzzie> I really like it otherwise, it's just a bit complex to understand all at once. Did you test it much?
[23:04:25] <tomprince> No. I am doinig that right now.
[23:05:14] <tomprince> Well, the reason I didn't make the distinction is that we rely on all the plugins being available
[23:05:44] <tomprince> There are actually a couple of things wrong with the first two, that I am working on right now.
[23:09:30] <tomprince> Any reason StreamFile/CreateStream doesn't use StackLock for the mutex, or returns with the mutexes held?
[23:11:04] <fuzzie> I don't know what StackLock is.
[23:12:02] <tomprince> It is just an object that grabs the mutex on construction, and frees it on destruction, so that you don't need to worry about releasing the lock before returning.
[23:12:03] <fuzzie> Should definitely be some mutex releasing there, though.
[23:15:14] <fuzzie> Looks like an accident that it isn't released. An on-stack mutex class sounds fine, I hadn't realised there was one there.
[23:16:06] <Lightkey> d'oh
[23:16:22] <Lightkey> one hour less sleep tonight again
[23:16:49] <fuzzie> tomprince: If you're going to fix those issues, do you think it would be possible to bundle them with the other fix you made, into a seperate patch?
[23:17:41] <tomprince> What do you mean?
[23:18:49] <tomprince> I'm not sure what you want bundle vs. seperate.
[23:19:25] <fuzzie> There's a missing alDeleteBuffers in loadSound, which you added in another patch.
[23:20:23] <fuzzie> A fairly unlikely bit to trigger without your changes, but if you are going to be sanitising code there anyway..
[23:21:23] <Lightkey> separate!
[23:21:23] <fuzzie> Then it would be nicer to have a "fix OpenAL error-handling problems" patch rather mixed in with "Resource support for sound".
[23:21:40] <fuzzie> But I have already talked for more time than it would be worth. :)
[23:21:46] <tomprince> Yes.
[23:21:50] <tomprince> I'll do that.
[23:23:53] <tomprince> It is anoying that ieResRef isn't null terminated.
[23:24:59] <tomprince> KEYImporter has historically truncated resname it gets passed at 8 chars for that reason. But I don't want DirectoryImporter to do that, for things like MUSImp::PlayMusic, that pass a path into it.
[23:25:15] <fuzzie> You could fix the sources to null-terminate them?
[23:25:37] <fuzzie> ieResRef is deliberately 9 chars for that reason.
[23:26:01] <fuzzie> I don't know where non-null-terminated versions would be coming from.
[23:26:53] <fuzzie> But I can certainly imagine that trying to make sure they're all null-terminated might lead to a few days of bugfixing..
[23:26:58] <tomprince> Well, I don't know if I actually checked, I think I just assumed it was, because of the strnct in FindIn/SearchIn.
[23:26:59] --> raevol has joined #GemRb
[23:27:17] <tomprince> s/strnct/strncat/
[23:27:38] <tomprince> s/strncat/strncpy/ I should say.
[23:28:42] <tomprince> I'll try change the n to _MAX_PATH and see what breaks. :)
[23:39:45] <tomprince> Nothing seems to break immediately.
[23:41:40] <-- raevol has left IRC (Quit: Leaving.)
[23:41:58] --> raevol has joined #GemRb
[23:50:23] <fuzzie> We cast ieResRefs to char* in various places, so I'd hope any obvious problems would have cropped up already.
[23:51:25] <fuzzie> Popped up?
[23:54:49] <tomprince> or cropped.