#gemrb@irc.freenode.net logs for 6 Apr 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:23:36] <-- Brendan__ has left IRC (Read error: Connection reset by peer)
[00:23:40] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[00:23:42] --> Gekz has joined #GemRb
[00:30:55] --> Brendan__ has joined #GemRb
[00:43:40] --> raevol has joined #GemRb
[00:51:46] <-- Brendan__ has left IRC (Quit: This computer has gone to sleep)
[01:52:20] <-- _pickle has left IRC (Remote host closed the connection)
[02:04:04] --> Gekz_ has joined #GemRb
[02:04:34] <-- Gekz has left IRC (Read error: Connection reset by peer)
[02:06:45] --> Gekz has joined #GemRb
[02:07:03] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[03:26:36] <-- barraAway has left IRC (Quit: Verlassend)
[05:18:35] --> Nomad010 has joined #GemRb
[05:26:00] <-- Nomad010 has left IRC (Ping timeout: 258 seconds)
[05:54:01] --> Nomad010 has joined #GemRb
[06:03:34] <-- Nomad010 has left IRC (Ping timeout: 258 seconds)
[07:34:20] --> edheldil has joined #GemRb
[07:46:44] <-- edheldil has left IRC (Ping timeout: 240 seconds)
[08:08:45] --> lynxlynxlynx has joined #GemRb
[08:08:45] --- ChanServ gives channel operator status to lynxlynxlynx
[08:34:26] <-- |Cable| has left IRC (Remote host closed the connection)
[09:07:35] --> edheldil has joined #GemRb
[09:32:06] --> Gekz_ has joined #GemRb
[09:33:44] --> Brendan__ has joined #GemRb
[09:34:06] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[09:34:10] <-- Gekz has left IRC (Ping timeout: 276 seconds)
[09:38:31] --> Gekz has joined #GemRb
[09:38:49] <-- Brendan__ has left IRC (Read error: Connection reset by peer)
[09:55:17] <edheldil> I am pushing gemrb with lua support to github
[09:55:31] <fuzzie> cool
[09:55:49] <fuzzie> add it to the main wiki page?
[09:56:17] <edheldil> don't hold your breath, it can only list PCs' names at the moment :)
[09:56:20] <edheldil> I will
[10:12:00] <edheldil> added
[10:17:33] <-- edheldil has left IRC (Ping timeout: 276 seconds)
[10:44:59] <-- raevol has left IRC (Quit: Leaving.)
[13:18:22] --> Edheldil has joined #GemRb
[13:18:23] --- ChanServ gives channel operator status to Edheldil
[13:18:34] <Edheldil> hi
[13:19:59] <tomprince> Hello.
[13:25:33] <Edheldil> tomprince, I have pushed the lua plugin to github, but it's not complete yet
[13:25:45] <tomprince_loki> Thanks. :)
[13:45:09] <fuzzie> afternoon, all
[14:00:56] <tomprince_loki> morning. :)
[14:01:12] <tomprince_loki> Feeling better?
[14:49:30] <-- tomprince_loki has left IRC (Ping timeout: 258 seconds)
[15:11:29] --> tomprince_loki has joined #GemRb
[15:40:57] --> Gekz_ has joined #GemRb
[15:41:57] <-- Gekz has left IRC (*.net *.split)
[15:41:58] <-- CIA-43 has left IRC (*.net *.split)
[15:42:52] --> CIA-43 has joined #GemRb
[15:45:40] --> Nomad010 has joined #GemRb
[15:55:50] <fuzzie> tomprince_loki: not really, but getting there.
[15:56:10] <fuzzie> tomprince_loki: why did you initialise the values of CD[] to 'CD1', 'CD2', etc?
[16:14:42] <fuzzie> (just curious if there's a reason for specifically that)
[16:19:04] --> Maighstir_laptop has joined #GemRb
[16:26:43] <tomprince_loki> CD[0] = $path_to_game/cd1 ...
[16:27:30] <tomprince_loki> The CDs are 1 indexed, but array is 0 index.
[16:27:32] <fuzzie> that's not what it's doing, though.
[16:27:45] <fuzzie> CD[0] is 'CD1'.
[16:28:05] <fuzzie> until you override it with the config.
[16:28:33] <fuzzie> i'm wondering why.
[16:28:48] <tomprince_loki> Exactly, the first cd CD[0] is CD1. Unless something is wrong.
[16:29:04] <tomprince_loki> Which may be.
[16:29:35] <fuzzie> i mean, maybe i'm not being clear :)
[16:29:50] <fuzzie> i am not asking about the indexing, i am asking why they are initialised with contents at all.
[16:31:22] <fuzzie> it means the core is doing a bunch of unnecessary searches at startup for a 1-CD game, that's all.
[16:34:34] <tomprince_loki> Well, it looks like is broken right now. The idea was that you wouldn't need to specify the cds in the config at all.
[16:34:58] <fuzzie> Ah :)
[16:35:18] <fuzzie> Okay, that's fine.
[16:35:35] <tomprince_loki> It doesn't actually work, because we expect it to be an absolute path, and it is only relative right now. At least, it doesn't look like it should work.
[16:35:57] <fuzzie> Yes, gemrb ends up looking for "CD1/blah.bif".
[16:52:13] <CIA-43> GemRB: 03fuzzie * rbe66a42104c4 10gemrb/gemrb/plugins/DirectoryImporter/DirectoryImporter.cpp: speed up DirectoryImporter's searches by avoiding unnecessary work
[16:52:17] <CIA-43> GemRB: 03fuzzie * r6f18dab1529c 10gemrb/gemrb/plugins/OpenALAudio/ (OpenALAudio.cpp OpenALAudio.h): fix leak in OpenALAudio's caching
[16:58:17] <fuzzie> wjp: that is all your code, i guess, so a glance to make sure it makes sense would be nice :)
[17:12:55] <tomprince_loki> fuzzie: Should I move the CaseSentitive check inside FindInDir, or will you?
[17:14:14] <fuzzie> i didn't do it because it was a bit involved
[17:14:52] <fuzzie> (got to avoid the malloc too, and hence fix the other callers)
[17:15:44] <tomprince_loki> The other than ResolveFilePath, the only other callers are in Actor.
[17:15:52] <fuzzie> yes, but they're there :)
[17:16:04] <tomprince_loki> I was just wondering if you were planning on doing it, or if I should go ahead.
[17:16:08] <fuzzie> sure, go ahead
[17:16:59] <tomprince_loki> I'll probably do it tonight.
[17:18:08] <wjp> fuzzie: looks ok
[17:23:41] <fuzzie> wjp: thanks
[17:24:33] <CIA-43> GemRB: 03fuzzie * rf38882a27189 10gemrb/gemrb/plugins/Core/GSUtils.cpp: fix leak in DisplayStringCore
[17:24:36] <CIA-43> GemRB: 03fuzzie * r2bb10ee6545e 10gemrb/gemrb/plugins/Core/GameControl.cpp: fix DisplayText leak in GameControl
[17:26:38] <fuzzie> valgrind down to just unavoidable complaints now, I think.
[17:27:39] <tomprince_loki> What unavoidable complaints?
[17:27:54] <fuzzie> Internal ALSA/python/libc/X11/etc bugs.
[17:28:26] <tomprince_loki> At least for python there is a suppression file, that hides the "expected" complaints.
[17:28:34] <tomprince_loki> Probably for the others.
[17:31:19] <fuzzie> Last time I looked, it was pretty madly broad. I guess it doesn't matter for us, though.
[17:32:11] <fuzzie> But anyway, I just mean: a run of valgrind without any suppressions is down to only complaints which should be suppressed :)
[17:35:46] <tomprince_loki> :)
[18:01:53] <CIA-43> GemRB: 03fuzzie * r15b3460a7480 10gemrb/gemrb/GUIScripts/bg2/GUICommonWindows.py: fix bg2's UpdateActionsWindow to actually invalidate the PortraitWindow
[18:03:35] <CIA-43> GemRB: 03fuzzie * r1f433ae97fa5 10gemrb/gemrb/plugins/Core/ (Control.cpp Window.cpp Window.h): add (trivial, incomplete) dirty regions to Window, use them when redrawing animations
[18:03:36] <fuzzie> Take *that*, irritating flickering AI buttons!
[18:07:24] <lynxlynxlynx> flickerfree now? :)
[18:07:35] <fuzzie> in theory :)
[18:15:01] <lynxlynxlynx> haven't tried it yet or just unsure if everything is covered?
[18:15:09] <fuzzie> just unsure if everything is covered.
[18:47:20] <fuzzie> It is *eerie* playing gemrb without the flickering AI buttons and the flickering dialog 'continue' button.
[18:49:08] <lynxlynxlynx> i tried to fix that once, but gave up
[18:50:54] <fuzzie> I wrote something to delay the UI changes from the button callback until after the dialog system has caught up. Not quite done yet, though.
[18:57:27] <fuzzie> http://fuzzie.org/nfs/gemrb/fix_continue_flickering.txt if anyone else wants to ponder over it.
[19:03:56] <fuzzie> (which is to say, it works for my limited testing, but i haven't checked much, and i haven't updated non-bg2 scripts.)
[19:10:26] <fuzzie> it looks like the encumbrance text being cut off was a deliberate change by Avenger in 96fc9753..
[19:13:35] <fuzzie> that *is* broken for people who aren't me, right?
[19:16:36] <lynxlynxlynx> you mean being cut off?
[19:16:45] <fuzzie> yes
[19:17:03] <lynxlynxlynx> i know something is wrong, but maybe it is the position
[19:17:06] <lynxlynxlynx> let me check
[19:18:02] <lynxlynxlynx> containers or inventory?
[19:18:17] <fuzzie> both
[19:18:28] <lynxlynxlynx> inventory is cut off here, both on the bottom side
[19:18:56] <lynxlynxlynx> the container is even worse, the labels are almost in a line
[19:20:43] <fuzzie> Well, there's nothing much wrong there, the GUIScripts are just passing bad positions/sizes to CreateLabel..
[19:21:20] <fuzzie> Changing all the heights back to 20 stops the text from being cut off, at least.
[19:21:53] <-- tomprince_loki has left IRC (Ping timeout: 276 seconds)
[19:23:48] <fuzzie> same in bg1.
[19:26:02] --> tomprince_loki has joined #GemRb
[19:26:12] <lynxlynxlynx> i wonder why he changed it then
[19:26:54] <lynxlynxlynx> again one of those everything-in-the tree commits
[19:33:05] <fuzzie> Well, for modding, ideally we wouldn't have hard-coded coordinates anyway.
[19:35:16] <fuzzie> Another mystery solved, anyway. Am going through the TODO list, seeing which bugs can be easily fixed with the benefit of another 6 months of thought.
[19:37:22] --> |Cable| has joined #GemRb
[19:39:41] <-- tomprince_loki has left IRC (Ping timeout: 258 seconds)
[19:40:42] <Edheldil> does it perhaps mean we should change our commit message customs to better indicate what was the reason for a patch?
[19:41:59] <fuzzie> probably :) for confusing things usually Avenger requests we add a comment too.
[20:00:24] --> tomprince_loki has joined #GemRb
[20:16:25] <fuzzie> tomprince_loki: http://fuzzie.org/nfs/gemrb/type_looping_to_core.txt works, but isn't done due to at least one regression (I figured I could vastly simplify things by only having ResourceMgr know about SClass_ID).
[20:20:45] <fuzzie> Your design seems to have no single resource identifier to use; ResourceDesc is only for plugins, TypeID is only for generic types and you seem to have intended to avoid using SClass_ID?
[20:21:30] <tomprince_loki> Well, I wanted to avoid SClass_ID, since that is an artifact of BIF files.
[20:21:43] <tomprince_loki> Ideally, everything would have moved over to ResourceDescs.
[20:22:22] <fuzzie> Unfortunately, ResourceDesc doesn't seem creatable on-the-fly, since it requires all kinds of plugin internals.
[20:22:22] <tomprince_loki> If anything, I think we should be syntethesizing ResourceDescs on the fly to pass to the ResourceMgr, rather than using SClass_ID.
[20:22:38] <tomprince_loki> Oh, yes.
[20:23:03] <tomprince_loki> I think the thing to do is to live with split for now, until things are moved over to ResourceDescs.
[20:23:16] <fuzzie> I don't see how you *can*.
[20:23:41] <tomprince_loki> Well, just convert everything that comes out of GameData be a Resource.
[20:24:08] <fuzzie> And move everything to be using TypeID?
[20:24:13] <tomprince_loki> Yes.
[20:24:19] <fuzzie> That seems kind of silly, you end up with two different "type ID" types.
[20:24:29] <tomprince_loki> Two?
[20:24:36] <fuzzie> SClass_ID, and TypeID.
[20:25:17] <tomprince_loki> Also, extension.
[20:26:05] <tomprince_loki> Ideally, I would get rid of SClass_ID for everything. For plugins that we get by ID we would have a PluginID, such as SDL, OpenAL, GUIScript.
[20:26:11] <tomprince_loki> And TypeID for everything else.
[20:26:25] <tomprince_loki> Because those two things are really disjoint.
[20:26:27] <fuzzie> Sure, but then you've just duplicated SClass_ID in the form of TypeID, no?
[20:27:09] <fuzzie> Almost every SClass_ID is going to need an equivalent TypeID, and every useful TypeID is going to need an equivalent SClass_ID.
[20:27:17] <tomprince_loki> Well, I think right now SClass_ID is overloaded.
[20:27:28] <fuzzie> I mean, PluginID is a *great* idea, obviously.
[20:27:32] <tomprince_loki> No, PNG, OGG, JPEG won't need SClass_ID.
[20:27:49] <fuzzie> Sure, but we can drop png/ogg/jpg from the codebase and no-one'd notice :)
[20:27:53] <tomprince_loki> :)
[20:28:24] <fuzzie> And I think if anyone ends up using them, they'd probably want to be able to pack them in BIF anyway, but I don't know, BIF doesn't seem particularly convenient to me.
[20:29:05] <fuzzie> (I mean, I am not serious about no-one noticing - I use the ogg support every day - just pondering.)
[20:30:07] <tomprince_loki> I'd like for SClass_ID to be mentioned calls to PLUGIN_IE_RESOURCE.
[20:30:36] <tomprince_loki> s/calls/only in calls/
[20:30:42] <fuzzie> I'm just wondering why.
[20:31:43] <tomprince_loki> It is an implementation detail of BIF files, and has nothing to do with our abstractions.
[20:31:45] <fuzzie> Well, no, I can see the reasoning too, it just seems very overcomplicated.
[20:32:10] <fuzzie> Because you're still going to want a TypeID for every BIF file type.
[20:32:31] <fuzzie> And it seems like some kind of ResourceDesc-type object would make a lot more sense.
[20:32:46] <tomprince_loki> Almost. Not MOS/BMP, I don't think.
[20:32:59] <tomprince_loki> And you only want one TypeID for MOS/BMP/PNG/JPEG.
[20:33:02] <fuzzie> I'm still not convinced they don't conflict.
[20:33:15] <tomprince_loki> Also, the same thing for OGG/WAV/ACM/FLAC.
[20:33:32] <fuzzie> So my thoughts are with the addition "we'll probably need to be able to uniquely identify MOS and BMP for the purposes of preferred file types".
[20:34:20] <tomprince_loki> Well, so that is a specific hack for compatability, but ideally, I think that we want TypeID <-> abstract Resource baseclass.
[20:34:49] <tomprince_loki> The same thing for BIK/MVE.
[20:35:42] <tomprince_loki> Part of the reason for the TypeID and ResourceDesc, is to avoid the thing of, when you want a sound, you need to check first for a wav, and then for an ogg. And the same thing for bmp/png.
[20:35:55] <tomprince_loki> And, if I ever get around to finishing it up TIS/TIZ.
[20:36:17] <tomprince_loki> And, if we do need hacks for compatability, fine, but mark them as such.
[20:36:29] <tomprince_loki> And don't design the interface around that.
[20:36:45] <tomprince_loki> And I'll shut up for a bit, so you can get a word in. :)
[20:36:47] <lynxlynxlynx> why would that be a hack?
[20:37:19] <lynxlynxlynx> from a modder's point of view, keeping filenames in check to be unique is just another burden
[20:37:49] <lynxlynxlynx> and it is he who would say that our design is bad
[20:37:56] <fuzzie> but on the other hand, having to mess about with weird formats like MOS and BMP is also a burden, when you could just distribute slim PNG/JPG files.
[20:38:33] <lynxlynxlynx> iron shirts and all
[20:38:45] <tomprince_loki> I haven't checked, but I wouldn't be suprised if some of the conflicts are there just because the IE engine makes a arbitrary distinction between MOS and BMP.
[20:39:01] <fuzzie> well, it would be good if you would take a peek sometime :)
[20:42:59] <fuzzie> tomprince_loki: http://fuzzie.org/nfs/gemrb/type_looping_to_core.txt updated.
[20:43:59] <fuzzie> It's very noisy, not sure if I forgot a silent check somewhere.
[20:47:43] <tomprince_loki> I just realized that 5d71b83883d407ce797be151b4a8d16b2a427132 and a7ad48e6ec7dd0a55364dee035143f6a0914418a depend on DirectoryImporter looping. :(
[20:47:48] <tomprince_loki> I forgot aobut that.
[20:48:31] <tomprince_loki> What made me realize that was that you changed it to return a DataStream* rather than a Resource* when passed a ResourceDesc.
[20:48:45] <tomprince_loki> I don't know what the solution to that is though.
[20:49:35] <fuzzie> Hm.
[20:49:48] <fuzzie> I also don't know.
[20:50:35] <tomprince_loki> I think break out the logic that got moved to GameData into its own class, and have GameData, and MUSImporter and SaveGame hold one of those objects.
[20:50:48] <tomprince_loki> That way we get the all the reporting logic in one place.
[20:51:43] <fuzzie> That makes sense.
[20:52:29] <tomprince_loki> So, apply your patch, but with s/DataSteam/Resource/. Then extract those functions. And then I update the plugins branch to use the new class. ?
[20:53:09] <fuzzie> Do you think the s/DataStream/Resource/ is needed?
[20:53:24] <fuzzie> I mean, I was considering the ResourceMgr API to be private, really.
[20:54:12] <fuzzie> So you could have minimal amounts of code in ResourceMgr implementators, and then some wrapper class around a ResourceMgr* array which does what GameData is doing right now.
[20:57:47] <tomprince_loki> That actually makes sense.
[20:59:05] <tomprince_loki> Two nitpicks. We should move the strcmp out of GetResource, and KEYImporter::GetResource(...ResourceDesc) should just call GetStream.
[20:59:33] <fuzzie> Should we be passing a 'const ResourceDesc &' around, or a 'const ResourceDesc'?
[21:00:33] <tomprince_loki> Probably const ResourceDesc&
[21:00:46] <fuzzie> ok. good, because i already did that :)
[21:01:33] <tomprince_loki> Probably doesn't make much difference.
[21:02:10] <fuzzie> Patch updated with those nitpicks.
[21:02:33] <fuzzie> Not sure if you wanted the strcmp moved where I put it (the top of the GameData functions).
[21:03:02] <tomprince_loki> That is probably the most sensible place for it.
[21:03:15] <tomprince_loki> Saves us running the loop if we don't have to.
[21:03:22] <fuzzie> Still confused as to why I'm getting a lot more output now.
[21:04:32] <fuzzie> Oh, because 'Exists' is now always printing results.
[21:04:58] <fuzzie> Perhaps I'd better revert that, then.
[21:05:50] <tomprince_loki> Should probaly change the comment about KEYImp.
[21:06:16] <fuzzie> to '// TODO: check various caches', perhaps?
[21:06:20] <tomprince_loki> Yes.
[21:08:27] <fuzzie> It's also a bit silly how I'm only printing the filename after trying types[j].Create(), in the TypeID form of GetResource.
[21:08:37] <fuzzie> But that is a thought for another time, I guess.
[21:08:49] <fuzzie> a new patch, again.
[21:09:14] <fuzzie> It needn't be applied now, if you'd prefer to think about it some more.
[21:15:37] <tomprince_loki> Does this http://pastebin.ca/1857355 (untested) fix the extra output?
[21:18:56] <fuzzie> doesn't that just re-add it?
[21:19:54] --> cfchris6_ has joined #GemRb
[21:20:39] <tomprince_loki> Yes. I just wasn't paying attention, we never should output on success on Exists before.
[21:20:43] <tomprince_loki> Silly me.
[21:20:55] <tomprince_loki> Should get rid of the commented out code though, probably.
[21:21:06] <fuzzie> Yes, I guess it's trivial to re-add.
[21:23:21] <-- cfchris6 has left IRC (Ping timeout: 248 seconds)
[21:24:08] <tomprince_loki> I think that if you change the GetResource to GetStream in KEYImporter, that it is ready to commit. I want to deliberately avoid the masking, since GetKeyType is already an ieWord not ieDword.
[21:24:29] <fuzzie> Oh, I didn't make that change?
[21:24:52] <tomprince_loki> I didn't see it.
[21:25:35] <fuzzie> The latest copy is up there.
[21:25:56] <fuzzie> I hope all the changes are obvious; I added that GetDescription() to ResourceMgr, which seemed reasonable.
[21:28:46] <tomprince_loki> Yes, that seems reasonable. You could probably change the protected to private now.
[21:29:17] <tomprince_loki> Then apply it. And through your and my signed-off-by's on it?
[21:33:09] <fuzzie> ok, commit is up at that url.
[21:34:19] <fuzzie> It doesn't build, heh.
[21:34:57] <fuzzie> Ah yes, no way to *set* the description if I make it private.
[21:35:31] <tomprince_loki> :)
[21:35:43] <tomprince_loki> Change the constructor to take a description.
[21:36:15] <fuzzie> Descriptions not available at construction time - they're passed to Open().
[21:36:21] <fuzzie> Maybe best to fiddle with it in a later commit.
[21:37:29] <tomprince_loki> Probably right then.
[21:38:02] <tomprince_loki> Nother nitpick, the breaks in BIFImporter could be returns now, since we don't need to display anything.
[21:40:40] <CIA-43> GemRB: 03fuzzie * r328628062b5a 10gemrb/gemrb/plugins/ (9 files in 4 dirs):
[21:40:41] <CIA-43> GemRB: Move type loops and output feedback from ResourceMgr/BIFImporter to GameData.
[21:40:41] <CIA-43> GemRB: Signed-off-by: Alyssa Milburn <fuzzie@fuzzie.org>
[21:40:41] <CIA-43> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[21:40:43] <CIA-43> GemRB: 03fuzzie * re82a321417c2 10gemrb/gemrb/plugins/BIFImporter/BIFImporter.cpp: simplify BIFImp::GetStream now that there's no need to display anything
[21:41:27] <fuzzie> Tested with my standard bunch of savegames, so can't be too disasterous.
[21:41:49] <fuzzie> The new class will have to wait until tomorrow, unless you preempt me overnight.
[21:41:58] <tomprince_loki> I'll do that.
[21:49:09] <lynxlynxlynx> :)
[21:53:28] <tomprince_loki> Fun.
[22:06:27] <-- Nomad010 has left IRC (Ping timeout: 260 seconds)
[22:26:32] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:34:37] --> raevol has joined #GemRb
[22:54:14] <-- Edheldil has left IRC (Remote host closed the connection)
[23:41:56] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[23:51:18] --> _pickle has joined #GemRb