#gemrb@irc.freenode.net logs for 18 Jan 2012 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:39:29] --> brad_a_ has joined #gemrb
[00:39:29] <-- brad_a_ has left IRC (Client Quit)
[00:42:29] <-- brad_a has left IRC (Ping timeout: 248 seconds)
[01:03:20] --> brad_a has joined #gemrb
[01:09:03] <-- brad_a has left IRC (Quit: brad_a)
[01:48:28] --> joneirik has joined #gemrb
[03:47:14] --> brad_a has joined #gemrb
[04:36:06] <brad_a> ok tossing out that patch from yesterday how about this: http://dl.dropbox.com/u/13866402/pause.patch
[04:37:00] <brad_a> seems to work in my limited testing
[04:37:57] <brad_a> bah misspelled interrupted, but lets ignore that for now :)
[05:00:00] <-- brad_a has left IRC (Quit: brad_a)
[05:01:13] --> brad_a has joined #gemrb
[05:36:52] <-- brad_a has left IRC (Quit: brad_a)
[06:07:27] <tomprince> Looks good, except multiple boolean arguemnts are never good, and having a default value with two callers seems silly.
[06:07:53] <tomprince> I think the best thing would be to add two enums, for the two arguments.
[06:49:59] <-- joneirik has left IRC (Remote host closed the connection)
[12:21:14] --> Baldurer has joined #gemrb
[13:10:24] --> demitar has joined #gemrb
[14:05:32] <-- Baldurer has left IRC (Ping timeout: 255 seconds)
[15:00:36] --> Baldurer has joined #gemrb
[15:03:36] <-- demitar has left IRC (Ping timeout: 240 seconds)
[15:33:34] --> demitar has joined #gemrb
[15:54:23] --> kettuz has joined #gemrb
[16:02:32] <-- Baldurer has left IRC (Ping timeout: 255 seconds)
[16:40:41] --> Baldurer has joined #gemrb
[17:23:03] <CIA-36> GemRB: 03bradallred * r04ecdd4b822c 10gemrb/gemrb/plugins/SDLVideo/SDLVideo.cpp: SDLVideo: print the SDL error when failing to create the display surface.
[17:23:22] --> brad_a has joined #gemrb
[17:56:22] <CIA-36> GemRB: 03avenger_teambg * recdc9a51da8e 10gemrb/gemrb/override/iwd2/ (6 files): IWD2:some combat effects unhardcoded from the .exe
[18:19:32] <-- brad_a has left IRC (Quit: brad_a)
[18:24:43] <gembot> build #23 of autotools g++-4.4 is complete: Failure [failed minimal test] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.4/builds/23 blamelist: avenger_teambg@sourceforge.net
[18:36:36] <gembot> build #42 of osx-xcode-binary is complete: Exception [exception upload_1] Build details are at http://buildbot.gemrb.org/builders/osx-xcode-binary/builds/42 blamelist: avenger_teambg@sourceforge.net
[18:40:03] <fuzzie> buildbot fail not build fail
[18:40:36] <CIA-36> GemRB: 03avenger_teambg * ra7c5a041b101 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: fixed SecondaryType and SpellType confusion (test:Jaheira's shapeshift)
[18:44:21] --> Avenger has joined #gemrb
[18:44:27] <Avenger> hello
[18:44:43] --- ChanServ gives channel operator status to Avenger
[18:48:07] --> brad_a has joined #gemrb
[18:53:43] <Avenger> fuzzie: i get this: AnimationFactory cursors has refcount 2
[18:53:54] <Avenger> just by starting/quitting gemrb
[18:53:58] <fuzzie> we are still arguing over how to fix that
[18:54:14] <Avenger> sorry, i missed the debate :)
[18:54:16] <fuzzie> oh, no, brad applied the fix
[18:54:25] <fuzzie> well I am clearly not paying attention then
[18:54:42] <Avenger> applied? I just downloaded and compiled
[18:54:56] <fuzzie> yeah i guess we missed one then
[18:56:07] <fuzzie> hmph
[18:56:50] <Avenger> it is probably not terribly serious. After loading the game, having different cursors, it is still only 2
[18:57:12] <fuzzie> yes, we were arguing over the drag cursors, which leaked a lot more, but that is fixed while I wasn't looking
[18:57:27] <Avenger> yep, this is normal cursors too
[18:57:46] <fuzzie> it's just leaking the up/down cursors on exit, I guess
[18:57:51] <fuzzie> since nothing calls FreeSprite on them
[18:59:31] <fuzzie> so just doing that in Video::~Video should deal with it
[18:59:39] <Avenger> yeah
[18:59:43] <Avenger> i just concluded that
[18:59:46] <fuzzie> :)
[19:00:03] <Avenger> i guess it would leak 3 cursors if i type Quit() in the console while dragging something
[19:00:11] <fuzzie> yes, probably
[19:00:22] <fuzzie> I have another Friday morning exam, so again not paying much attention
[19:01:12] <Avenger> hehe, no, there is some code to drop items
[19:01:25] <brad_a> fyi that animation factory message has been around for quite sometime
[19:01:26] <fuzzie> well, I was thinking about dragging portraits, for example
[19:01:35] <Avenger> yeah, portraits, good idea
[19:01:37] <fuzzie> brad_a: the cursors one? it really shouldn't be
[19:01:43] <fuzzie> please do mention leaks :-p
[19:01:59] <brad_a> i have gotten that message as long as i can remember (or a similar one about animation refcount)
[19:02:04] <Avenger> brad: it may have been. But i just noticed it now
[19:02:20] <Avenger> animation refcounts ARE leaking, just i didn't see cursors doing it until now
[19:02:32] --> Micru has joined #gemrb
[19:02:34] <fuzzie> i am still getting a segfault on exit because the OpenAL thread isn't being killed
[19:02:47] <-- Baldurer has left IRC ()
[19:02:50] <Micru> hi
[19:02:52] <fuzzie> but otherwise i didn't see any new stuff on exit recently, other than these v.recent cursor leaks
[19:02:54] <Avenger> all leaks shall be fixed or soon we'll be wading waist deep in bits
[19:02:57] <brad_a> oh ok then i am jsut confused :)
[19:03:14] <brad_a> yes i can certainly fix the cursors
[19:03:51] <Micru> i wrote a post on the forum, but after re-reading it, i think i haven't expressed clearly...
[19:04:00] <brad_a> fuzzie: i dont remember us ever thinking of a way to make openal play nice on exit for everybody
[19:04:03] <fuzzie> sort-of-hi Micru
[19:04:22] <fuzzie> brad_a: it isn't hard as far as I remember
[19:04:25] <Avenger> someone wants to do the tile cache? With so many low end devices and complains about performance, it seems to be an important feature
[19:04:55] <Micru> fuzzie: yep, RL-monsters swallowed me
[19:04:55] <fuzzie> i don't think the tile cache is so important
[19:05:00] <Avenger> micru: which one
[19:05:10] <fuzzie> we should just stop loading areas when trying to move creatures to them!
[19:05:10] <brad_a> he is talking about widescreen
[19:05:33] <Micru> avenger: this one http://forums.gibberlings3.net/index.php?showtopic=23870
[19:05:37] <Avenger> fuzzie: that would be also solved with the tile cache, actually
[19:05:47] <fuzzie> Avenger: no, i mean we shouldn't load areas at all
[19:05:50] <Avenger> if you don't display the area, you don't have to load any tiles
[19:05:58] <Avenger> but you need to load the area to embed the creature
[19:06:05] <fuzzie> the original engine doesn't embed the creature
[19:06:09] <Avenger> the bg engine maintains some weird list
[19:06:24] <Avenger> it is totally prone to bugs
[19:06:38] <fuzzie> yes, it just keeps the creature around as a global with a 'move to area' effect attached, which wakes up when the area matches
[19:06:39] <Avenger> what happens if you quit the game before the creature actually transfers
[19:06:51] <fuzzie> that happens all the times
[19:06:58] <fuzzie> they're just globals in the savegame
[19:07:09] <Avenger> hmm, they are stored in the npc list?
[19:07:16] <Avenger> i never seen a savegame with those
[19:07:18] <fuzzie> this is really simple to see, load an original save in gemrb and watch it load about 5 areas :P
[19:07:38] <Avenger> yes, but it would be fast without tiles
[19:07:56] <fuzzie> the .are files aren't in the compressed archives?
[19:08:16] <Avenger> they are only a few k
[19:08:20] <fuzzie> that doesn't matter
[19:08:26] <Avenger> tiles are M's
[19:08:45] <fuzzie> i just mean, do we have to decompress a .bif for them?
[19:08:52] <fuzzie> or are they just in a global .bif?
[19:09:06] <Avenger> the bif is already decompressed, because more than one area is in the bif
[19:09:09] <fuzzie> areas.bif looks like a likely name for the global .bif but i don't have DLTCEP here
[19:09:20] <gembot> build #24 of autotools g++-4.4 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.4/builds/24
[19:10:09] <Avenger> area specific bifs contain: mos/tis/wed
[19:10:12] <fuzzie> as long as we can avoid opening the areaXXXX.bif files then we're fine
[19:10:13] <fuzzie> ok, great
[19:10:14] <Avenger> areas.bif contains all are
[19:10:30] <fuzzie> i guess that is a solution then
[19:10:34] <Avenger> only .are files get saved/needed for my way of storing critters
[19:11:15] --> Yoshimo has joined #gemrb
[19:11:15] <fuzzie> as long as we are very careful not to open the wed
[19:11:42] <fuzzie> so, no trying to initialise doors or anything
[19:11:46] <Avenger> hmm, yes, this will be a big refactoring
[19:12:13] <fuzzie> which is why i thought much simpler to just not open the area files at all :) but i don't mind either way, just avoiding work
[19:12:51] <Avenger> if you are absolutely certain that critters in transit are somehow made global and stored in the game, you can do that too.
[19:12:59] <Avenger> I just never seen them saved
[19:13:01] <fuzzie> you really never saw it in an original save?
[19:13:17] <Avenger> no, and this will need some refactoring too
[19:13:19] <fuzzie> they are everywhere, you can get an example just by making a new bg2 game and saving it after the intro
[19:13:50] <Avenger> yep, the genie must be one
[19:21:11] <brad_a> ah the problem is when i moved code to video i kept the cursor = null junk instead of updating it to setcursor(null)
[19:21:28] <brad_a> ignor me
[19:21:36] <brad_a> but yes i did fix it :D
[19:21:49] <brad_a> fuzzie: remind me of the openal exit problem
[19:23:33] <-- Micru has left IRC (Ping timeout: 258 seconds)
[19:23:41] <fuzzie> brad_a: you no longer kill the thread at exit, and so the thread crashes
[19:23:50] <-- Avenger has left IRC (Quit: bye!)
[19:24:04] <brad_a> oh yes. we used to use sdl_kill thread
[19:24:16] <brad_a> which they say is to be avoided in their docs
[19:24:51] <brad_a> says to use "some other ipc signal"
[19:24:51] <fuzzie> yes, but you just removed the thread killing entirely
[19:25:03] <fuzzie> which is worse :)
[19:25:28] <brad_a> well xcept on systems that terminate the thread on their own or whatever is happening
[19:25:36] <fuzzie> although I'm not sure why it crashes actually..
[19:25:50] <brad_a> i do remember it causing at least apple system to hang indefinately on exit with sdl_killthread
[19:26:18] <brad_a> i switched it to sdl_waitthread
[19:26:29] <brad_a> which says wait for a thread to finish
[19:26:38] <fuzzie> yeah, it clearly isn't working, intrsting
[19:26:42] <brad_a> and on my system it does return successfully....
[19:27:09] <brad_a> and the thread is terminated completely without error
[19:27:17] <fuzzie> although obviously this is really really bad overall
[19:27:36] <brad_a> also obviously im oblivious to how
[19:27:37] <fuzzie> the music thread should be dead before things start messing around with the OpenAL context
[19:27:38] <brad_a> :)
[19:27:51] <fuzzie> but that was already bad in the original code
[19:28:20] <brad_a> oh you mean the make current contet bit?
[19:28:40] <brad_a> shouldnt the music thread do that right before it exits?
[19:28:45] <fuzzie> no
[19:28:49] <brad_a> i guess it doesnt matter
[19:28:52] <brad_a> or no :)
[19:28:53] <fuzzie> should be done after the music thread is gone
[19:28:58] <fuzzie> i mean don't listen to me
[19:29:07] <fuzzie> i spent the whole day on stupid context-free languages
[19:29:13] <fuzzie> my brain is a mush of goo
[19:29:36] <fuzzie> i don't understand why this is broken either
[19:29:46] <fuzzie> let me check the irc logs and see what fuzzie-from-the-past said
[19:29:55] <brad_a> oh good i thought i was jsut missing something obvious again
[19:30:16] <brad_a> ah you "swapped that out" i see
[19:30:30] <fuzzie> ok, she's not very helpful
[19:30:40] <brad_a> i disagree :)
[19:30:51] <brad_a> maybe not at this time :)
[19:30:52] <fuzzie> since she suggests SDL_WaitThread
[19:30:55] <fuzzie> sigh
[19:31:10] <fuzzie> dates back to when we were reviewing the patch before applying it :)
[19:31:35] <fuzzie> but in that case, I don't know why this is crashing for me. how irritating!
[19:32:14] <fuzzie> oh nice, gdb crashes :-)
[19:32:23] <brad_a> o_O
[19:32:54] <fuzzie> perhaps the music thread is a red herring..
[19:33:05] <brad_a> you could try passing status to waitthread
[19:33:23] <fuzzie> we are calling Py_Finalize in the GUIScript destructor
[19:33:27] <brad_a> not as a fix obviously
[19:33:47] <brad_a> i thought you said it was the music thread that was crashing tho
[19:33:52] <fuzzie> and valgrind complains a lot about memory corruption there
[19:34:12] <brad_a> i guess memory corruption can corrupt other thereads
[19:34:18] <fuzzie> it looks pretty innocent though
[19:34:40] <fuzzie> um.
[19:36:10] <brad_a> oh i guess status is jsut the return value of the thread...
[19:36:21] <brad_a> does our function even do a return?
[19:36:31] <fuzzie> yes
[19:36:42] <brad_a> indeed
[19:36:57] <fuzzie> i would not worry about it
[19:37:04] <fuzzie> since it might be corruption
[19:37:05] <brad_a> right
[19:37:18] <brad_a> also as far as i know it only affects you
[19:37:44] <fuzzie> also always hopeful ;p
[19:38:17] <fuzzie> i don't think i have the time now to trace exactly which destructors get run etc
[19:39:01] <brad_a> for the leaking cursors i just put a setcursor(null) for each of the cursor types in ~video
[19:39:05] <brad_a> but
[19:39:13] <brad_a> avenger said it had refcount 2...
[19:39:16] <fuzzie> i don't think you can do that
[19:39:18] <fuzzie> can you?
[19:39:33] <fuzzie> I mean I know I suggested it :-p
[19:39:55] <fuzzie> but the FreeSprite is pure virtual by the time you get to ~Video I think?
[19:40:00] <fuzzie> so it should die horribly if you try it
[19:40:06] <brad_a> lousy c++
[19:40:25] <brad_a> except doesnt setcursor jsut do release?
[19:40:37] <fuzzie> yes, but release just calls FreeSprit
[19:40:37] <fuzzie> e
[19:40:42] <brad_a> oh thats right
[19:41:16] --> thySEus1 has joined #gemrb
[19:41:55] <brad_a> just out of curiosity why do we need to do this: Sprite2D *that = this;
[19:42:04] <fuzzie> I have *no* idea.
[19:42:14] <fuzzie> was also wonering.
[19:42:15] <thySEus1> hey; i am using 0.7.0-git (freshly pulled and compiled). everything works except the inventory and character screen (game freezes). i remember i had this bug and it was an easy solution, but i forgot it. any ideas? ;)
[19:42:16] <fuzzie> wondering.
[19:42:24] <brad_a> msvc++?
[19:42:30] <fuzzie> thySEus1: incorrect resolution?
[19:42:51] <thySEus1> i tried 1024 and 800
[19:43:02] <fuzzie> brad_a: the commit says "Sprite2D: Add an acquire method to increase RefCount." which is a bit unhelpful, but it's from tomprince so you can ask
[19:43:32] <thySEus1> oh, the game is bg2 german
[19:43:41] <brad_a> im sure if its from tomprince then ther is some obscure but valid reason :)
[19:43:53] <brad_a> tho i suppose i am still curious
[19:44:38] <brad_a> thySEus1: look at the log file
[19:44:47] <brad_a> specifically arount the time you open the inventory
[19:45:02] <thySEus1> where can i find the log file?
[19:45:10] <fuzzie> thySEus1: I can't think of anything right now. Nothing in recent IRC logs either.
[19:45:49] <brad_a> log location depends on your system but hopefully you know where the system log is L:)
[19:45:58] <fuzzie> there is one mention of you having UI issues a *long* time ago but you had just been unlucky enough to pick an hour where gemrb git was broken :)
[19:46:10] <fuzzie> but i think brad_a just means the gemrb output
[19:46:17] <thySEus1> i doubt gemrb writes into /var/log/messages ;)
[19:46:28] <fuzzie> we are too used to Android/iOS users in here :)
[19:46:56] <brad_a> oh yeah i forget gemrb is a consol app for most platforms :)
[19:46:57] <brad_a> just like i forget trailing es
[19:47:13] <brad_a> and i use a mac
[19:47:40] <brad_a> and one of my first orders of business for gemrb was to stop compiling as a console app for mac :)
[19:48:20] <brad_a> well if you built before and are upgrading you should delete all the old stuff first
[19:48:33] <brad_a> i know old gui scripts have bitten me once or twice before
[19:51:48] <brad_a> so fuzzie something else needs to call setcursor
[19:51:59] <brad_a> im unsure the best place
[19:52:03] <fuzzie> you could just put it in the SDLVideo destructor for now
[19:52:26] <brad_a> well i could but it seems like it should be someplace that would work if we had more than 1 video driver
[19:53:09] <fuzzie> well, my thought is mostly that it's not worth worrying about it now
[19:53:28] <fuzzie> although yes, it would be nicer to have something less crazy, and certainly worthy of a comment
[19:53:35] <fuzzie> maybe ask someone else's opinion :)
[19:54:01] <brad_a> well im inclined to find a spot on my own perhapps so i can learn more about gemrb
[19:54:30] <thySEus1> hmm, when i set to 640 the whole ui flickers visible&invisible, but its not clickable
[19:54:39] <thySEus1> seems to be a general UI problem. any ideas?
[19:54:42] <thySEus1> python version?
[19:54:43] <brad_a> yes update your guiscripts
[19:54:57] <thySEus1> hmm, how?
[19:55:00] <fuzzie> it does sound like you might have installed over an older version and you have the wrong scripts
[19:55:08] <thySEus1> yes, thats the case !
[19:55:20] <fuzzie> in which case, delete the old scripts, reinstall :)
[19:55:39] <fuzzie> really annoying how cmake is not helpful there
[19:56:12] <thySEus1> ok so rm -rf /usr/local/share/gemrb ; sudo make install should solve it?
[19:56:33] <brad_a> sounds like it should.
[19:57:13] <brad_a> i dont think the guiscripts go in a diffrent place, but i wouldnt know without looking at cmake.txt
[19:57:30] <brad_a> the install locations all differ on mac so im useless
[19:57:43] <thySEus1> works ! could have had this idea for myself ! thanks gemrb community ;)
[20:00:17] <-- thySEus1 has left #gemrb
[20:01:25] <fuzzie> unusually happy user :p
[20:10:45] <brad_a> and for some reason that reminded me of the obnoxious ass hat that came in here a short time ago spouting obcenities at us
[20:18:13] <gembot> build #112 of nmake-msvc++10 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B10/builds/112
[20:38:55] <-- gembot has left IRC (Remote host closed the connection)
[21:05:39] --> lynxlynxlynx has joined #gemrb
[21:05:40] <-- lynxlynxlynx has left IRC (Changing host)
[21:05:40] --> lynxlynxlynx has joined #gemrb
[21:05:40] --- ChanServ gives channel operator status to lynxlynxlynx
[21:06:52] --> SiENcE has joined #gemrb
[21:07:31] <CIA-36> GemRB: 03bradallred * r3effd822a14e 10gemrb/gemrb/core/Interface.cpp: Interface: clear all cursors when destroying interface. Solves cursors having a positive refcount message on exit (ie leaking).
[21:07:31] <CIA-36> GemRB: 03bradallred * rc4208a0acaa3 10gemrb/gemrb/ (7 files in 2 dirs): Merge branch 'master' of ssh://gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[21:08:54] <tomprince> brad_a fuzzie: I think because you cant delete this, which has type 'Sprite2D*const'.
[21:09:20] <brad_a> oh that makes sense
[21:09:50] <brad_a> of course i thought you could jsut cast away const
[21:10:16] <tomprince> I coult probably do 'delete const_cast<Sprite2D*>(this);'
[21:10:52] <brad_a> it doesnt matter. i was just curious for no good reason. :)
[21:10:54] <fuzzie> that would be my first thought, althogh I have no objection to how it is,
[21:10:58] <fuzzie> just also curious
[21:12:39] <tomprince> fuzzie: I am sure I have asked something like this before, but ...
[21:13:17] <tomprince> I know we override some of the original game files (spells/effects?). But do you know if the original data actually refers to them by those names, or could we just invent new names for them.
[21:14:06] <fuzzie> I think you'd have to be more specific.
[21:14:39] <tomprince> Well, I was just considering moving our overrides to after, rather than before the original data.
[21:16:33] <fuzzie> i think various things are referred to by resref
[21:17:01] <fuzzie> spells, certainly
[21:17:09] <fuzzie> but I'm not sure how much we actually override that exists in the original game?
[21:18:25] <fuzzie> I would have thought that overriding broken 2DA files is more common than effects/spells.
[21:18:53] <tomprince> stats.ids, weapprof.2da, spar*.pro, baldur.bcs, but I think those are all for games that don't originally have them. Except the stats.ids.
[21:19:20] <tomprince> At least, according to the override_listings.txt I have sitting in my repository.
[21:26:06] <-- Yoshimo has left IRC (Read error: Connection reset by peer)
[22:06:37] <brad_a> i love ho everybody is freaking out over wikipedia being offline for a day...
[22:06:54] <brad_a> and nobody knows hitting esc will let you in ;-)
[22:06:58] <-- SiENcE has left IRC (Read error: Connection reset by peer)
[22:07:10] <fuzzie> there was a lot of confusion among some of my friends about it this morning
[22:07:20] <fuzzie> because everyone was saying wikipedia was blacked out but .. it was fine
[22:07:27] <fuzzie> of course they're all nerds who have noscript turned on
[22:16:50] --> brad_a_ has joined #gemrb
[22:17:13] <brad_a_> i didnt think they were blocking countries other than us
[22:18:21] <-- brad_a has left IRC (Ping timeout: 252 seconds)
[22:18:22] --- brad_a_ is now known as brad_a
[22:18:58] <brad_a> i have a super flaky internet connection it seems
[22:19:19] <brad_a> must be sopa protets blocking me :O
[22:27:06] --> brad_a_ has joined #gemrb
[22:27:06] <-- brad_a_ has left IRC (Client Quit)
[22:31:20] <-- brad_a has left IRC (Ping timeout: 255 seconds)
[23:07:38] --> brad_a has joined #gemrb
[23:08:19] <-- brad_a has left IRC (Remote host closed the connection)
[23:08:26] --> brad_a has joined #gemrb
[23:10:13] --> brad_a_ has joined #gemrb
[23:13:34] <-- brad_a has left IRC (Ping timeout: 276 seconds)
[23:13:34] --- brad_a_ is now known as brad_a
[23:15:26] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:19:09] <-- brad_a has left IRC (Remote host closed the connection)
[23:19:17] --> brad_a has joined #gemrb
[23:32:49] --> brad_a_ has joined #gemrb
[23:35:38] <-- brad_a has left IRC (Ping timeout: 240 seconds)
[23:35:38] --- brad_a_ is now known as brad_a
[23:41:22] <CIA-36> GemRB: 03bradallred * r646134cb9e21 10gemrb/gemrb/ (core/Video.cpp plugins/SDLVideo/SDLVideo.cpp): Cursors: may as well use named index values for cursors since we have them.
[23:51:10] <-- brad_a has left IRC (Quit: brad_a)