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

Archive Today Yesterday Tomorrow
GemRB homepage


[00:17:32] <-- raevol has left IRC (Quit: Leaving.)
[02:13:41] <Gekz> fuzzie: you only specify the path TO the save dir
[04:19:01] --> raevol has joined #GemRb
[05:01:50] --> tomprince_loki has joined #GemRb
[05:14:20] <tomprince_loki> fuzzie: Don't apply that PLT patch. I am going to split it in two. The stuff that is need for further patches will go first, and the horrid stuff can hang around until we come up with a better solution.
[05:16:59] <tomprince_loki> The thing is, everytime you balked at applying something because my code smells, we've managed to come up with something cleaner and simpler and more useful.
[05:58:19] --> lynxlynxlynx has joined #GemRb
[05:58:20] --- ChanServ gives channel operator status to lynxlynxlynx
[06:05:39] <-- Nomad010 has left IRC (Ping timeout: 276 seconds)
[06:16:14] <tomprince> There, done. :)
[06:16:35] <tomprince> I think everything except the last commit is ready to be applied, after testing. :)
[06:16:40] --> Nomad010 has joined #GemRb
[06:21:08] <tomprince> So, we have Cache, LRUCache, Variables, Dictionary. :(
[06:25:11] <tomprince> And on the topic of useless duplication, is there any reason why we take a std::vector<ResponseBlock*> and then copy it in to newScript, rather than just keeping around the vector. (this is in GameScript::CacheScript)
[06:26:48] <tomprince> I'm looking at using DirectoryImporter to have ai scripts searched for only in */scripts, and all other only in the search path.
[07:17:47] <Gekz> hi there
[07:17:54] <Gekz> tomprince: did you test my patch?
[07:21:54] <-- ratpor has left IRC (Quit: Get used to disappointment.)
[07:25:47] <-- Gekz has left IRC (Ping timeout: 240 seconds)
[07:27:49] --> Gekz has joined #GemRb
[07:46:06] <Gekz> oh what
[07:46:09] <Gekz> this is interesting
[07:46:38] <Gekz> tomprince: by using deque instead of just misusing lists, my testing reveals a drop of speed of 0.005s
[07:46:56] <Gekz> 0m0.105s vs 0m.095s
[07:47:09] <Gekz> average of 0.005s
[07:54:49] --> fuzzie_ has joined #GemRb
[07:56:39] <-- fuzzie has left IRC (*.net *.split)
[08:03:54] <Gekz> ok, so I benchmarked it using timeit
[08:04:03] <Gekz> deque takes 22 seconds with three entries
[08:04:09] <Gekz> using just del and append takes 3
[08:37:44] <fuzzie_> tomprince: ^.^, for want of a better expression
[09:06:13] <-- raevol has left IRC (Quit: Leaving.)
[09:43:28] --- fuzzie_ is now known as fuzzie
[09:43:37] --- ChanServ gives channel operator status to fuzzie
[09:48:19] --> Edheldil_ has joined #GemRb
[11:32:43] --> edheldil__ has joined #GemRb
[11:38:19] <Gekz> I am finally finished with my paper :D
[11:45:08] <-- edheldil__ has left IRC (Ping timeout: 265 seconds)
[12:20:04] <-- Gekz has left IRC (Read error: Connection reset by peer)
[12:21:16] --> Gekz has joined #GemRb
[12:27:13] <tomprince> Morning.
[12:27:24] <tomprince> Gekz: Do you have any others due this term?
[12:29:05] <-- Gekz has left IRC (Read error: Connection reset by peer)
[12:34:20] --> Gekz has joined #GemRb
[12:53:46] <-- Gekz has left IRC (Ping timeout: 264 seconds)
[12:58:12] --> Gekz has joined #GemRb
[13:06:36] <Gekz> hmm?
[13:12:37] <Gekz> http://dscarts.com/Fix_colours_on_error.patch btw
[13:13:35] <Gekz> oh, I have to care about windows, dont I
[13:13:36] <Gekz> sigh
[13:14:45] <Gekz> fixed
[13:14:55] <Lightkey> keep em closed
[13:15:03] <Gekz> haha
[13:15:35] <Gekz> fuzzie: that's the patch you requested.
[13:15:41] <Gekz> if that one doesn't get merged, then I've failed epically haha
[13:17:49] <tomprince> Well, it would probably be better to add something to win32def.h, where all the other win32/unix display specifics are, rather than adding another ifdef to the code.
[13:19:12] <Gekz> tomprince: there's already a unix specific endline there
[13:19:22] <Gekz> with no ifndef
[13:19:30] <Gekz> oops
[13:19:32] <Gekz> I was mistaken
[13:19:35] <Gekz> there is an ifndef
[13:20:49] <Gekz> tomprince: where is win32def.h located
[13:20:57] <Gekz> is it with mingw or in the project/
[13:20:57] <tomprince> germb/includes
[13:22:06] <Gekz> now how do you propose I do this without using ifndefs
[13:22:24] <Gekz> using a defined constant with nothing but a null?
[13:23:01] <Gekz> or just use BLACK
[13:24:56] <tomprince> Probably not black, there should probably be something to set it back to the default colors, rather than black. Add an inline that resets the color, and call it on both paths.
[13:26:14] <Gekz> I dont know how to reset the colours in windows
[13:26:22] <Gekz> I was under the assumption cmd did it per line anyway
[13:26:44] <tomprince> Well, in that case, you can have an empty implementation there.
[13:27:09] <Gekz> I think it's doing it wrong anyway
[13:27:14] <tomprince> But that way, all the platform specific code is hidden in one place. Or at least one less place.
[13:27:15] <Gekz> it should be using printMessage
[13:28:35] <Gekz> yes I found it.
[13:29:50] <fuzzie> oh, btw, if someone fixes the empty ImageID struct, someone should fix the POSITION struct too
[13:30:27] <fuzzie> or i suppose just zap the code entirely, but, work :(
[13:30:53] <fuzzie> and resetting the colours on windows is no problem to include in a macro if needed
[13:31:01] * fuzzie wanders off in direction of work agai
[13:32:24] <Gekz> tomprince: I think I did it without changing anything but one line :D
[13:32:26] <Gekz> lets see if it worked
[13:51:46] <Gekz> hehe
[13:51:47] <Gekz> fixed it :D
[13:53:01] <Gekz> http://dscarts.com/Fix_colours_on_error.patch
[13:58:35] <tomprince> Have we not already printed the error by the time we get back to main? And I think that will break on window, since you always set the (foreground) color to black on windows after printMessage. I think it would be better to have a seperate function that resets the console, rather than overloading printMessage.
[14:00:12] <Gekz> it never gets back to main
[14:00:14] <Gekz> it returns -1
[14:00:20] <Gekz> it exits straight after
[14:01:01] <Gekz> that should probably be fixed
[14:01:52] <Gekz> tomprince: how do you reset the console in windows?
[14:02:14] <tomprince> That function *is* main. I meant that the error has already been printed in core->Init(), and that we don't need to print ERROR again.
[14:02:45] <tomprince> No idea, you can just leave at as a do nothing, and if it doesn't do the right thing, someone who cares can figure it out an implement it.
[14:03:19] <Gekz> isn't that exactly what I just did? ll
[14:03:27] <Gekz> I could just change the foreground to white on windows
[14:04:01] <Gekz> and it doesnt print the error every time
[14:04:07] <Gekz> this is a "catch all" error statement
[14:06:49] <Gekz> oh now I see what it was doing
[14:06:52] <Gekz> it was ONLY catering for Windows
[14:07:14] <tomprince> Well, that is probably a bug then. But I still don't thin we should be printing ERROR there. I was suggesting having a ResetConsole() that resets the screen, that is just called from main, rather than changing printMessage and using textcolor.
[14:08:14] <tomprince> Also, it caters to someone who runs gemrb as 'xterm -e gemrb' for example from a menu.
[14:08:37] <Gekz> I'm doing as suggested
[14:09:38] <Gekz> no, we dont need to reset it
[14:09:40] <Gekz> it was a bug
[14:11:12] <Gekz> testing my theory now
[14:20:21] <Gekz> tomprince: http://dscarts.com/Fix_colours_on_error.patch
[14:20:25] <Gekz> that fixes the issue on both platforms
[14:20:30] <Gekz> the issue was it was windows-centric
[14:20:35] <Gekz> it was resetting to white for both platforms
[14:20:44] <Gekz> now it resets to white on Windows, and [0m on linux
[14:25:21] <tomprince> That looks good. I still don't like the printing of ERROR there, since pressing a key isn't an error.
[14:25:40] <Gekz> lol
[14:25:53] <Gekz> what do you support I put there then
[14:26:02] <Gekz> it's not saying "Press a key" because it wants to
[14:26:11] <Gekz> an error occurred and you have no option but to exit
[14:26:16] <Gekz> suppose*
[14:28:23] <tomprince> And we should probably reset the display to normal anyway.
[14:28:38] <tomprince> Well, we already print an error message.
[14:28:47] <tomprince> If we don't that is a bug.
[14:30:50] <tomprince> I wouldn't change the printf to a printMessage, I'd just add a textcolor(DEFAULT) there, and change the ifdef to a textcolor(DEFAULT) as well.
[14:34:12] <tomprince> I hope I am not discouraging you. :) I think this is a useful patch.
[14:34:40] <Gekz> nah I've just got 500,000 things to do since 5 minutes ago
[14:34:48] <Gekz> I have to write a booklet on how to defeat censorship
[14:35:08] <Gekz> because some, no better word, fuckwit decided to tell the press we'd have one ready within the week
[14:35:11] <Gekz> AND THEN DIDNT DO ANYTHING
[14:35:15] <Gekz> good job
[14:36:34] <tomprince> :)
[14:36:45] <Gekz> pirate party business yo
[14:36:55] <Gekz> and tomprince, there is no error printed
[14:37:06] <tomprince> In what case?
[14:37:10] <Gekz> I'll show you
[14:37:11] <Gekz> one sec
[14:37:27] <Gekz> GemRB Core Version v0.6.0 Loading...
[14:37:28] <Gekz> [Core]: Initializing the Event Manager...[Core]: Initializing Variables Dictionary...[OK]
[14:37:28] <Gekz> [Config]: Trying to open GemRB.cfg [NOT FOUND]
[14:37:28] <Gekz> [Config]: Trying to open /Users/Brendan/.gemrb/gemrb.cfg [NOT FOUND]
[14:37:28] <Gekz> [Config]: Trying to open /usr/local/etc/gemrb/gemrb.cfg [NOT FOUND]
[14:37:28] <Gekz> [ERROR]: Press enter to continue...
[14:37:36] <Gekz> we need a no config found error
[14:37:38] <Gekz> I'll make one
[14:37:40] <Gekz> ONWARD
[14:38:16] <Gekz> also tomprince
[14:38:22] <Gekz> I'm kinda pissed I didnt think of what you said myself
[14:38:23] <Gekz> haha
[14:38:29] <Gekz> I'm like "that's too simple"
[14:40:54] <tomprince>
[14:41:01] <Gekz> space!
[14:41:21] <tomprince> Well, I've been trying to simplify the code, so I am senstive to these things.
[14:41:52] <tomprince> And every time my code is to complicated, fuzzie has hesitated to apply it, and then something simpler occurs. :)
[14:42:01] <Gekz> lol
[14:42:11] <Gekz> I would like to assist you in this code simplification process
[14:42:11] --> kettuz has joined #GemRb
[14:42:18] <Gekz> I enjoy simplified and efficient code
[14:42:20] <Gekz> :)
[14:43:02] <tomprince> If you are looking at the config code, there is http://github.com/NickDaly/GemRB-Multiple-Configs-Branch/commit/6d0087493a5c3e937227063001187875104200db
[14:43:23] <tomprince> That is lying around, as well as some comments on it on the bug tracker.
[14:45:09] <tomprince> The other thing is, we have an in INIImporter, that probably duplicates a lot of the config file reading support.
[14:45:34] <Gekz> if (stricmp( name, "Width" ) == 0) {
[14:45:35] <Gekz> Width = atoi( value );
[14:45:35] <Gekz> } else if (stricmp( name, "Height" ) == 0) {
[14:45:35] <Gekz> Height = atoi( value );
[14:45:35] <Gekz> } else if (stricmp( name, "Bpp" ) == 0) {
[14:45:38] <Gekz> we have to do something about that
[14:45:38] <Gekz> lol
[14:45:51] <tomprince> Yes.
[14:45:59] <Gekz> does that even owrk?
[14:46:01] <Gekz> they're else ifs
[14:46:08] <Gekz> so if the first one solves the dilemma, none of the others are called
[14:47:45] <Gekz> I found where the error message should be
[14:49:08] <tomprince> Speaking of which. fuzzie: Is there any reason long term, why we should read the plugin path from the config file? The only usecase we don't handle right now is allowing the install directory to be relocatable. Once we have that, I see no reason for the plugin path to be in the config file.
[14:52:31] <Gekz> tomprince: as far as optional enhancements are concerned, should those be placed in gemrb.cfg?
[14:52:37] <Gekz> that's where my recent patch places its setting
[14:52:40] <Gekz> for AlwaysExport
[14:53:02] <Gekz> and fuzzie said something in regards to moving SetNextScript from C++ to Python
[14:53:05] <lynxlynxlynx> always export what?
[14:53:23] <Gekz> lynxlynxlynx: always export when clicking accept in the character creation window
[14:53:29] <Gekz> before going to the game
[14:53:39] <lynxlynxlynx> the character
[14:53:41] <Gekz> yes
[14:53:48] <Gekz> it could be more appropriately named, this is sure
[14:54:07] <lynxlynxlynx> you could use guienhancements
[14:54:19] <lynxlynxlynx> or something like that that we already have
[14:54:21] <Gekz> but that encompasses everything
[14:54:34] <tomprince_loki> Yes, it probably should be in .cfg
[14:54:35] <Gekz> I'm talking about giving the user the option to toggle these things on and off
[14:54:48] <Gekz> not just one big enhancement blog
[14:54:50] <Gekz> blob*
[14:55:05] <tomprince_loki> I think this is a special case, since it is intrusive.
[14:55:16] <Gekz> yes
[14:55:32] <Gekz> but I think the ability should be there for more "intrusive" features
[14:55:41] <tomprince_loki> The other gui enhancements are things like scrollbars in lists that didn't have one, which is just sensible, and isn't intrusive.
[14:55:48] <Gekz> it allows greater extendability to the user
[14:55:54] <lynxlynxlynx> it's a mod
[14:56:01] <Gekz> yes, basically
[14:57:08] <tomprince_loki> The "nicer" and much more involved way to do it would be to add another button to export the character, but that would involve creating a new CHU for each game. ;)
[14:57:47] <Gekz> exactly
[14:58:15] <Gekz> but I think GemRB should cater for these kind of enhancements to the infinity games, no?
[14:58:33] <Gekz> perhaps make all the config reading code part of the GUIScripts
[14:58:36] <Gekz> instead of in the C++
[14:59:03] <Gekz> lynxlynxlynx: http://dscarts.com/Add_AlwaysExport_and_Pythonise_GetNextScript_et_al.diff
[14:59:31] <lynxlynxlynx> the button could be autogenerated btw
[14:59:41] <tomprince_loki> Yes, it should cater to those things.
[15:00:19] <tomprince_loki> I don't think the config reading should be pushed to python. The C++ side needs to know about a bunch of the settings anyway.
[15:01:58] <lynxlynxlynx> the patch has a lot of cruft in it
[15:01:58] <Gekz> lynxlynxlynx: oh?
[15:02:02] <Gekz> oh I know
[15:02:05] <Gekz> it's not a patch, it's a diff
[15:03:40] <lynxlynxlynx> and what's the perceived difference?
[15:03:53] <Gekz> this is not a merge to tree proposal
[15:04:03] <Gekz> it was a grouped demonstration of what I changed
[15:04:12] <Gekz> I was showing fuzzie what I needed to get it compiling on this mac
[15:04:19] <Gekz> and at the same time showing the other code
[15:04:35] <Gekz> otherwise they would have been separate files
[15:04:50] <Gekz> lynxlynxlynx: anyway, the intent of the "AlwaysExport" was not to even be shown
[15:04:57] <Gekz> it was to simply save the character in the slot "backup"
[15:05:14] <Gekz> therefore overriding the previous backup
[15:05:19] <Gekz> but being entirely hidden from the user
[15:05:31] <Gekz> the reason for this was on my first load, GemRB crashed and I lost my char
[15:05:35] <Gekz> and I was rather disappointed haha
[15:07:16] <tomprince_loki> That would actually be a reasonable thing to do with GUIEnhancments=1, probably.
[15:07:18] <lynxlynxlynx> nice that you want just one slot
[15:07:40] <Gekz> tomprince_loki: indeed
[15:07:48] <lynxlynxlynx> i made thousands of chars already and i'm sure the trend won't stop soon
[15:08:05] <Gekz> lynxlynxlynx: but also, that diff was basically my first foray into the gemrb code
[15:08:13] <Gekz> and when it compiled and did what I intended, I was indeed very amused
[15:08:21] <Gekz> lynxlynxlynx: but what you may notice is my odd list
[15:08:29] <Gekz> I was using that list to be able to tell what the last script was that was run
[15:08:38] <Gekz> is there a better way to do that?
[15:09:30] <lynxlynxlynx> not that i can think of
[15:09:49] <Gekz> I'd prefer a "better" way than the way I implemented
[15:09:52] <lynxlynxlynx> you checked the efficiency of some different storages yesterday, no?
[15:10:05] <Gekz> what do you mean
[15:10:11] <Gekz> for the list?
[15:10:12] <lynxlynxlynx> deque vs others
[15:10:14] <Gekz> yes
[15:10:18] <Gekz> the most efficient way is the one in the diff
[15:10:22] <Gekz> delete the first entry
[15:10:23] <Gekz> append one
[15:10:32] <Gekz> deque took 22 seconds, the normal way took 2
[15:10:42] <lynxlynxlynx> if only the last run script is of interest, why not just use a simple variable?
[15:10:42] <Gekz> deque is used when you have many hundreds of entries
[15:10:55] <Gekz> lynxlynxlynx: for flexibility's sake>
[15:10:59] <tomprince_loki> I don't know if there is a better way to do that, but at the very least, you should have a dictionary instead of a list.
[15:11:08] <Gekz> why a dictionary
[15:11:09] <tomprince_loki> .. wth magic numbers.
[15:11:17] <wjp> or even just three variables
[15:11:27] <Gekz> I had three variables initially
[15:11:39] <Gekz> it's essentially the same as this situation, but more lines of code
[15:11:41] <tomprince_loki> So you don't need the comment # 0= .. 1= .. 2= ...
[15:11:54] <Gekz> could just change it to a dictionary
[15:11:58] <Gekz> I did consider it initially
[15:12:01] <Gekz> but I factored in speed
[15:12:08] <wjp> speed is completely irrelevant
[15:12:12] <Gekz> ok.
[15:12:24] <Gekz> then that's easily done lol
[15:12:41] <Gekz> Script = {Last: None, Current: None, Next: None}
[15:12:48] <tomprince_loki> ...premature optimization ... root of all evil ....
[15:12:50] <Gekz> quotes them
[15:12:51] <tomprince_loki> *grin*
[15:12:53] <Gekz> lol
[15:13:00] <Gekz> I've been working with python for quite some time
[15:13:06] <Gekz> I know how much of a bottleneck dictionaries can be
[15:13:08] <Gekz> when compared to lists
[15:13:09] <Gekz> >_>
[15:14:21] <lynxlynxlynx> not when you have three items
[15:14:22] <tomprince_loki> To a zeroth approximation, with the gemrb code, if it doesn't touch SDL, then performance doesn't matter.
[15:14:30] <wjp> won't these code snippets only run once or twice per chargen window?
[15:14:46] <tomprince_loki> That's not true, but close enough for this.
[15:15:42] <Gekz> wjp: well currently, the exportfile.py kinda dangles
[15:15:46] <Gekz> it has no idea where it's going
[15:15:51] <Gekz> it uses the TokenDictionary
[15:16:02] <Gekz> it's the one file that misuses the TokenDictionary in such a way
[15:19:26] <Gekz> seems to be quite a bit of code repetition here
[15:19:26] <Gekz> >_>
[15:19:31] <Gekz> here being Interface.cpp
[15:21:23] <tomprince_loki> Interface has way to much stuff with it. Everything in it is essentially a global.
[15:21:30] <Gekz> tomprince: http://dscarts.com/Fix_colours_on_error.patch
[15:21:39] <Gekz> how about now
[15:21:41] <Gekz> lol
[15:21:41] <tomprince_loki> One of my goals is to empty it out eventually.
[15:22:34] <Gekz> argh crap, that's an unclean interface.cpp
[15:22:36] <Gekz> but you see the point
[15:23:24] <Gekz> cleaned up the patch.
[15:24:42] <tomprince_loki> Yes. Except that you are missing a textcolor(DEFAULT) on the succes path.
[15:24:58] <Gekz> it isn't required
[15:25:05] <Gekz> in fact, I could remove that line from GemRB.cpp entierly
[15:25:06] <Gekz> and I will
[15:25:19] <Gekz> the fix was in the header
[15:25:21] <Gekz> that's just a remnant
[15:27:29] <tomprince_loki> I think it actually make sense. If for any reason we fall out with weird colors set, we should restore them. So we play nice with the user, regardless of what happens elsewhere in the code.
[15:28:13] <Gekz> I see.
[15:28:21] <Gekz> I put too much trust in successful code haha
[15:28:29] <tomprince_loki> And the extra errors in Interface.cpp should be a seperate patch.
[15:28:45] <Gekz> ok
[15:30:06] <Gekz> tomprince: http://dscarts.com/Fix_colours_on_error.patch
[15:30:26] <tomprince_loki> Yes. That should be applied. :)
[15:30:35] <Gekz> hurray!
[15:30:50] <Gekz> a 5 line patch
[15:30:55] <Gekz> I am a successful businessman.
[15:30:56] <Gekz> haha
[15:31:23] <Gekz> i'll probably do the guienhancement thing tomorrow
[15:31:26] <Gekz> right now I'm going to clean my tree
[15:32:21] <tomprince_loki> You should commit that patch, then either push it somewhere, or run format-patch on it and post that.
[15:32:50] <Gekz> lol
[15:32:52] <Gekz> push it somewhere.
[15:34:21] <Gekz> what does format-patch do
[15:35:21] <lynxlynxlynx> note your authorship
[15:35:27] <Gekz> oh right
[15:35:28] <Gekz> I get it now
[15:35:32] <Gekz> I'm a child of subversion
[15:35:35] <tomprince_loki> It takes a commit and turns it into a format ready for mailling. Or in the case posting, with commit message and authorship recorded. :)
[15:37:53] <Gekz> where does it put it
[15:37:54] <Gekz> >_>
[15:38:51] <lynxlynxlynx> it's just like git show
[15:39:01] <tomprince_loki> The current directory [0-9][0-9][0-9][0-9]-commit-msg.patch
[15:39:24] <Gekz> does it need parameters?
[15:39:33] <Gekz> git show works
[15:39:37] <Gekz> git format-patch does not
[15:39:40] <tomprince_loki> HEAD~1 will do what you want.
[15:40:35] <Gekz> there we go
[15:40:36] <Gekz> :D
[15:40:42] <Gekz> I cant type a tilde on this keytboard
[15:40:45] <Gekz> .-.
[15:40:49] <tomprince_loki> or -s HEAD~1 if you want to add a Signed-of-by line
[15:40:50] <lynxlynxlynx> HEAD^
[15:40:59] <lynxlynxlynx> or the real hash
[15:41:02] <Gekz> that works :)
[15:41:57] <Gekz> http://dscarts.com/0001-Fix-buggy-colour-output-by-Gekz.patch
[15:42:54] <tomprince_loki> Yep.
[15:43:17] <tomprince_loki> The difference between git show and git format-patch is the indentation of the commit-msg.
[15:43:50] <tomprince_loki> lynxlynxlnyx: Do you want to apply that?
[15:43:57] <tomprince_loki> Since you are around. :)
[15:44:01] <lynxlynxlynx> no, go ahead
[15:44:12] <lynxlynxlynx> i'm reading an eu directive >>
[15:44:21] <tomprince_loki> Me? I don't have commit access.
[15:44:46] <tomprince_loki> Although you couldn't tell by the number of my commits in the tree. :)
[15:44:51] <lynxlynxlynx> huh
[15:45:11] <lynxlynxlynx> wjp, edheldil: please give tomprince_loki rw access to the repo
[15:45:31] <lynxlynxlynx> i know fuzzie committed a lot of them, but i didn't know it was all
[15:45:34] <tomprince_loki> I don't mind. Fuzzie is a good gatekeeper. Keeps all my messes out of the tree. :)
[15:45:59] <lynxlynxlynx> it doesn't make sense for trivialities like this
[15:46:06] <tomprince_loki> True.
[15:47:38] <tomprince_loki> Gekz: You've read http://elinux.org/Developer_Certificate_Of_Origin ?
[15:50:19] <Gekz> what?
[15:50:33] <lynxlynxlynx> that doesn't load here btw
[15:50:47] <Gekz> oh
[15:50:54] <Gekz> I already considered all of these things and more
[15:51:19] <Gekz> I transfer all copyright to the project on commit
[15:51:29] <Gekz> what happens with it then is all good
[15:52:32] <Gekz> can we get the build system patched so it works on Mac OS X without me having to molest it lol
[15:52:53] <-- kettuz has left IRC (Quit: Leaving)
[15:56:35] <Gekz> lynxlynxlynx: which EU directive?
[15:57:07] <lynxlynxlynx> 2008/312
[15:57:15] <Gekz> what is it about
[15:57:47] <lynxlynxlynx> 2008/98/ES actually
[15:57:53] <Gekz> what is it about
[15:57:53] <Gekz> lol
[15:58:11] <lynxlynxlynx> it's about waste managment
[15:58:41] <lynxlynxlynx> i'm participating in a conference about some details of it with construction experts tommorow
[15:59:07] <Gekz> oh
[15:59:39] <lynxlynxlynx> why do they want a forestry student in their midst? I was part of a summoning ritual that made some 250k people do our bidding yesterday :)
[16:00:06] <Gekz> lol what
[16:00:26] <Gekz> are you some kind of wiccan
[16:00:45] <tomprince_loki> Gekz: yes, I want the cmake build to just work everywhere.
[16:00:55] <tomprince_loki> What -Werror are you hitting?
[16:01:00] <Gekz> an SDL one
[16:01:05] <Gekz> SDLmain specifically
[16:01:18] <Gekz> it's to do with SDLmain.m in the SDL.framework
[16:01:36] <lynxlynxlynx> http://www.letsdoitworld.org/news/350-000
[16:02:25] <Gekz> oh you live in slovenia
[16:02:30] <Gekz> I hear the government is quite corrupt there
[16:02:47] <lynxlynxlynx> hah
[16:04:14] <Gekz> tomprince_loki: there's a slight issue with my pathc
[16:04:16] <Gekz> patch*
[16:04:34] <Gekz> some messages now have blank backgrounds
[16:04:38] <Gekz> which is _very_ weird
[16:06:00] <Gekz> oh I know why
[16:06:06] <Gekz> >_.
[16:08:40] <Gekz> Assertion failed: (stream->GetPos() == PCOffset + i * PCSize), function PutPCs, file /Users/Brendan/Git/gemrb/gemrb/plugins/GAMImporter/GAMImporter.cpp, line 1024.
[16:08:51] <Gekz> yes, the save directory is ill defined
[16:09:01] <Gekz> however, when it hits the abort trap, it DOESNT CLEAN UP THE COLORS
[16:09:02] <Gekz> lol
[16:10:19] <Gekz> tomprince: perhaps wrap main() in a try catch?
[16:10:50] <tomprince_loki> That will never fly. :) No exceptions for us.
[16:11:21] <Gekz> lolk
[16:11:31] <Gekz> then how do we deal with abort traps making such a mess
[16:11:39] <Gekz> or do we simply "not"
[16:11:45] <Gekz> as they arent really errors
[16:12:35] <lynxlynxlynx> you can't fix everything
[16:12:58] <Gekz> this makes me sad haha
[16:13:03] <tomprince_loki> No? Not ever? :)
[16:13:13] <lynxlynxlynx> the program could receive a SIGKILL in the middle of the printing and you'd also remain with bad colors
[16:13:20] <Gekz> haha
[16:13:24] <Gekz> in other news
[16:13:34] <Gekz> that error where teh save path is set wrong needs to be fixed posthaste
[16:13:42] <Gekz> perhaps mkdir -p ? :P
[16:13:52] <Gekz> the issue is mine is set to a path that doesnt exist
[16:14:02] <Gekz> I assumed ./save would be the directory the saves went it
[16:14:03] <Gekz> in*
[16:14:06] <Gekz> turns out that makes it ./save/save
[16:14:07] <Gekz> haha
[16:18:07] <Gekz> tomprince_loki: I fixed my patch
[16:18:12] <Gekz> how do i revert a commit in git?
[16:19:07] <tomprince_loki> Gekz: what happens if you get rid of the IF(APPLE) at 186 in the root, and change the TARGET_LINK_LIBRARIES to just have gemrb_core and ${SDL_LIBRARY}
[16:19:25] <tomprince_loki> Probably in the case, you can do git commit --am, which ammends the last commit.
[16:19:45] <Gekz> my backup mod works too
[16:19:48] <Gekz> it's a whole two lines :p
[16:23:30] <Gekz> http://dscarts.com/0001-Fix-buggy-colour-output-by-Gekz.patch
[16:23:34] <Gekz> that most certainly fixes it
[16:27:47] <tomprince_loki> You sure that doesn't break code that is expecting the textcolor(WHITE)?
[16:28:03] <tomprince_loki> I honstly don't know, since I haven't looked at all the uses of that.
[16:28:25] <Gekz> none of it seems to expect textcolor(WHITE)
[16:28:29] <Gekz> but that said, nothing _should_ expect it
[16:28:41] <Gekz> I saw no noticeable difference in output
[16:29:10] <Gekz> http://dscarts.com/0001-Save-character-as-BACKUP-on-creation-when-GUIEnhance.patch
[16:29:41] <tomprince_loki> Did you try combat? I don't know. I don't actuallylokk at the output much. :)
[16:29:55] <Gekz> I did
[16:29:58] <Gekz> Actor took 1 damage
[16:30:22] <Gekz> nothing expects the colour white to dangle
[16:30:25] <tomprince_loki> That patch is much nicer than your AlwaysExport patch. :)
[16:30:44] <Gekz> yeah, as I said
[16:30:44] <Gekz> that was not merge quality
[16:30:44] <Gekz> I was simply toying around with the capabilities of the config
[16:30:55] <Gekz> and getting acquainted with completely alien code
[16:31:19] <tomprince_loki> Yes, the GUIScripts certainly is that. :)
[16:31:36] <Gekz> now, what I'm going ot do
[16:31:44] <Gekz> is make an archive of all my saves on my main pc
[16:31:45] <Gekz> and upload them
[16:31:51] <Gekz> they have the most obscure names ever haha
[16:31:59] <Gekz> and they go from Baldurs Gate through to ToB
[16:32:01] <Gekz> with the same party :D
[16:32:08] <Gekz> well, more or less
[16:35:40] <Gekz> http://dscarts.com/bg-saves.7z
[16:37:19] <Gekz> the connections button shouldnt appear in single player mode
[16:41:25] <Gekz> also, if you require a copy of my install, it can be arranged, albeit slowly
[16:41:27] <Gekz> haha
[16:41:36] <Gekz> hmm, unless..
[16:52:34] <-- Nomad010 has left IRC (Ping timeout: 264 seconds)
[17:03:12] <fuzzie> tomprince_loki: SDL 1.2 requires SDLmain on OS X
[17:03:19] <Gekz> hi fuzzie :)
[17:03:29] <fuzzie> if you don't include it, you end up without a main() function.
[17:03:35] <fuzzie> it is the stupidest thing ever.
[17:03:49] <Gekz> fuzzie: could just add one to the project
[17:03:56] <Gekz> in a mac directory
[17:04:02] <fuzzie> yes, i think they recommend you do that
[17:04:07] <fuzzie> i just don't like :(
[17:04:24] <Gekz> I will make one that doesn't shit 10,000 warnings, if I can work out ObjC
[17:04:25] <Gekz> haah
[17:04:31] <Gekz> then have it committed
[17:04:42] <Gekz> fuzzie: the link to the same games is above
[17:04:50] --> Nomad010 has joined #GemRb
[17:04:50] <fuzzie> i think you can simply go through every warning and fix it
[17:05:03] <Gekz> have you tried reading ObjC?!
[17:05:04] <Gekz> lol
[17:05:09] <Gekz> it looks like a diff
[17:05:44] <tomprince_loki> Looking at the cmake code for FindSDL, the comments make it sound like it handles that, or should.
[17:05:54] <fuzzie> oh?
[17:06:04] <fuzzie> well, the comments in my FindSDL say "you have to include an SDLmain.m"
[17:06:26] <fuzzie> and hands off the problem to us, which is very unhelpful
[17:06:29] <fuzzie> but maybe i am out-of-date?
[17:06:50] <fuzzie> "Don't forget to include SDLmain.h and SDLmain.m your project for the OS X framework based version."
[17:07:01] <fuzzie> but it is cmake 2.6.
[17:08:36] <tomprince_loki> I have 2.8 here.
[17:08:44] <fuzzie> it doesn't have that comment?
[17:09:21] <Gekz> I have 2.8 here
[17:09:28] <Gekz> anyway, I must sleep
[17:09:29] <Gekz> night
[17:09:39] <tomprince_loki> No, it has an option SDL_BUILDING_LIBRARY to set if you don't want SDLmain.
[17:09:41] <fuzzie> i see that we can lose the -framework Cocoa
[17:09:44] <tomprince_loki> At least, that is how I read it.
[17:09:51] <fuzzie> but, i mean, is it missing the comment? :)
[17:10:23] <tomprince_loki> No, it has it.
[17:10:24] <fuzzie> because there is no SDLmain *library* available in the standard distribution.
[17:11:05] <fuzzie> There's some documentation justifying that somewhere, basically that there's no way to provide a generic SDLmain library for native SDL 1.2 on OS X.
[17:11:26] <fuzzie> I don't understand it, but they do ship 4 different SDLmain.m files.
[17:11:42] <Gekz> 4?
[17:11:44] <Gekz> I only have 2
[17:11:44] <Gekz> lol
[17:11:56] <Gekz> NIBless and CocoaMain or something
[17:11:59] <fuzzie> I just built against SDL 1.3, which doesn't require any of this ridiculous hackery in the first place.
[17:12:06] <Gekz> srsly going to sleep now
[17:12:20] <fuzzie> But I had to comment out some bits of SDLVideo to do that, and I didn't check whether it ran.
[17:12:34] <tomprince_loki> I don't know if the changes i suggested above will work, but I though the error output of make VERBOSE=1 would be enlightening if it didn't.
[17:12:58] <fuzzie> Well, removing the IF(APPLE) from HEAD shouldn't be a problem.
[17:13:23] <Gekz> ... I lied once again
[17:13:28] <fuzzie> Just doesn't fix the SDLmain.m problem.
[17:13:32] <Gekz> fuzzie: you must merge my patches :)
[17:13:53] <Gekz> http://dscarts.com/0001-Save-character-as-BACKUP-on-creation-when-GUIEnhance.patch and http://dscarts.com/0001-Fix-buggy-colour-output-by-Gekz.patch
[17:14:06] * Gekz seriously goes now
[17:14:07] <fuzzie> Gekz: I think calling it 'backup' is maybe something which will make people angry when their backup character is automatically overwritten.
[17:14:17] <Gekz> fuzzie: rename it before merging then
[17:14:28] <Gekz> gembak or something
[17:14:30] <fuzzie> any suggestion? :)
[17:14:31] <fuzzie> ok.
[17:14:48] <Gekz> gemrbak lolo
[17:14:49] <Gekz> puns
[17:14:54] * Gekz says bai and sleeps
[17:15:11] <fuzzie> tomprince_loki: sorry, maybe I should explain; HEAD doesn't work with the 'native' OS X framework for SDL. You have to include this SDLmain.m thing, and the default one is full of errors.
[17:15:40] <fuzzie> Their recommended strategy is that you include it in the tree and customise as required.
[17:18:51] <fuzzie> This is a seperate issue to that IS(APPLE) bit, which can just go, I would think.
[17:23:56] --> raevol has joined #GemRb
[17:25:43] <fuzzie> i can probably borrow an OS X machine in the next couple of hours if needed
[17:25:50] <fuzzie> but am bit busy
[17:27:30] <tomprince_loki> Crazy. :)
[17:27:56] <fuzzie> basically, you have to initialise Cocoa before the app tries doing anything
[17:28:43] <fuzzie> except, OS X moved on in the meantime, and you can now do that in a better place, but SDL 1.2 is in maintenance mode.
[17:31:38] <CIA-74> GemRB: 03brendan.bbqsrc * rac455b05fc59 10gemrb/gemrb/GUIScripts/ (bg1/CharGenGui.py bg2/CharGen9.py):
[17:31:38] <CIA-74> GemRB: Save character as GEMBAK on creation when GUIEnhancements is set true
[17:31:38] <CIA-74> GemRB: Signed-off-by: Brendan Molloy <brendan.bbqsrc@gmail.com>
[17:31:43] <CIA-74> GemRB: 03brendan.bbqsrc * r591ce8641ac8 10gemrb/gemrb/ (GemRB.cpp includes/win32def.h):
[17:31:43] <CIA-74> GemRB: Fix buggy colour output
[17:31:43] <CIA-74> GemRB: Signed-off-by: Brendan Molloy <brendan.bbqsrc@gmail.com>
[17:34:41] <fuzzie> untested, etc
[17:37:19] <Lightkey> omgwtfbbq!
[17:37:26] <Lightkey> sauce
[17:41:45] <tomprince_loki> ???
[17:42:26] <fuzzie> i am waiting on the bitmap stuff to build
[17:42:35] <Lightkey> Justus, Bob and.. Thomas, was it?
[17:43:57] <tomprince_loki> ???
[17:44:50] <Lightkey> ah no, Peter was the third
[17:45:36] <Lightkey> Die drei Fragezeichen
[17:46:05] <fuzzie> tomprince_loki: did you see if msvc6 could be fixed easily for your include path changes, btw?
[17:46:24] <tomprince_loki> No, I didn't check. I can do that now.
[17:46:44] <Lightkey> seems like it was The Three Investigators in English, with the names Jupiter, Bob and Pete
[17:51:17] <Lightkey> anyway, I was just referring to "Brendan's" chosen moniker in the commit messages before
[17:52:30] <tomprince_loki> :)
[17:52:53] <tomprince_loki> fuzzie: It already looks in ../../includes, using a relative path ... so yes. :)
[17:53:03] <tomprince_loki> At least for some of it, it does.
[17:53:22] <fuzzie> well, i just wondered if it actually built, or whether disaster occurred
[17:53:55] <fuzzie> but i should really install it myself
[17:54:06] <CIA-74> GemRB: 03tom.prince * rf383d83104dc 10gemrb/gemrb/plugins/ (7 files in 2 dirs):
[17:54:06] <CIA-74> GemRB: Core/Bitmap: Add class for storing array of bytes.
[17:54:06] <CIA-74> GemRB: This will be used for SearchMap/HeightMap.
[17:54:06] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[17:54:08] <CIA-74> GemRB: 03tom.prince * r0fd30058912b 10gemrb/gemrb/plugins/Core/ (Actor.cpp ActorBlock.cpp ActorBlock.h Map.cpp Map.h):
[17:54:08] <CIA-74> GemRB: Bitmap: Switch LightMap and HeightMap to use Bitmap.
[17:54:08] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[17:54:11] <CIA-74> GemRB: 03tom.prince * r01b6614724be 10gemrb/gemrb/plugins/BMPImporter/ (BMPImporter.cpp BMPImporter.h):
[17:54:11] <CIA-74> GemRB: BMPImporter: Drop Read4to4 support.
[17:54:11] <CIA-74> GemRB: We always unpack 4bpp bitmaps to 8bpp, so do it once on load, rather
[17:54:11] <CIA-74> GemRB: than repacking at point of use.
[17:54:11] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[17:56:36] <Lightkey> http://en.wikipedia.org/wiki/Three_Investigators#International_publishing strange, there really is no mention of three question marks in the English version?
[17:57:55] <tomprince_loki> Well, there are a number of small things that break in MSVC6.
[17:58:10] <tomprince_loki> But it is a fairly straightforward change to get the include paths to work right.
[17:59:14] <Lightkey> and where is Avenger again?
[17:59:38] <tomprince_loki> Working on a MUD, apparently.
[18:00:37] <fuzzie> he lost motivation for gemrb a bit when we all got busy at the end of last year, i think
[18:27:15] --> ratpor has joined #GemRb
[18:34:49] <fuzzie> tomprince_loki: your Image patch neglects to add Image.cpp to Makefile.am
[18:35:12] <-- Edheldil_ has left IRC (Remote host closed the connection)
[18:36:02] <tomprince_loki> That cause I switched to cmake. :) Same reason my early commits all forgot about cmake. :)
[18:37:23] <fuzzie> it does seem to work fine on big-endian though
[18:37:37] <fuzzie> although i suppose i'd better find a colour lightmap
[18:47:00] <fuzzie> looks ok
[18:47:29] <fuzzie> it abort()ed pretty quickly
[18:48:20] <tomprince_loki> abort? That isn't good.
[18:48:32] <fuzzie> well, i am pretty sure that is not your fault :-)
[18:49:02] <fuzzie> AddSixSuffix is not handling IE_ANI_SLEEP.
[18:49:19] <fuzzie> so defiitely not your fault.
[18:52:12] <CIA-74> GemRB: 03tom.prince * rf90dd207d5c5 10gemrb/gemrb/plugins/Core/ (Image.cpp Image.h ImageMgr.cpp ImageMgr.h):
[18:52:12] <CIA-74> GemRB: Core/Image: Add Image class to store non-Video images.
[18:52:12] <CIA-74> GemRB: This is primarily for SearchMap.
[18:52:12] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:52:13] <CIA-74> GemRB: 03tom.prince * rbd4f6519967b 10gemrb/gemrb/plugins/Core/ (Map.cpp Map.h):
[18:52:13] <CIA-74> GemRB: Image: Switch LightMap over to Image.
[18:52:13] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:53:33] <fuzzie> that animation code drives me crazy
[18:54:16] <fuzzie> even before all the missing PS:T stuff is added to the mix
[19:01:59] <lynxlynxlynx> yep
[19:09:27] --> Edheldil_ has joined #GemRb
[19:10:44] <CIA-74> GemRB: 03fuzzie * ree9934a772b3 10gemrb/gemrb/plugins/Core/Makefile.am: add Image.cpp to Core/Makefile.am
[19:11:29] <tomprince_loki> Are data1.cab and data2.cab from iwd/how identical?
[19:11:49] <fuzzie> which version?
[19:12:10] <tomprince_loki> Don't know.
[19:14:04] <fuzzie> i mean, i guess i am confused by the question, then
[19:14:33] <tomprince_loki> From HOW.
[19:15:17] <tomprince_loki> The cd I have has data1.cab and data2.cab, and they seem to have identical contents.
[19:15:34] <fuzzie> and it's a combined iwd+how cd? or just how?
[19:15:44] <wjp> how are you checking the contents?
[19:16:50] <wjp> (because things like unshield will possibly treat them both as the same multi-part archive)
[19:17:01] <tomprince_loki> That would do it then.
[19:17:34] <fuzzie> yes, my how cd seems to have them as multi-part; data1.cab is 600k :)
[19:41:33] <Edheldil_> hi all
[19:41:42] <tomprince_loki> Hello.
[19:41:46] <Edheldil_> tomprince, what is your SF account?
[19:42:26] <fuzzie> 'rtprince'
[19:43:39] <Edheldil_> ok, I have blessed(*) you with a commit access
[19:43:59] <Edheldil_> (*) for some definitions of the word and some belief systems
[19:44:14] <tomprince_loki> The unix one. :)
[19:44:59] <fuzzie> i guess i can leave you to go forth and commit all the rest of your finished patches in the bitmap branch :)
[19:46:58] <Edheldil_> since I am doing that, should I revoke commit access from balrog, divide, doc_wagon and mattinm? not sure if it would not mean they cease to be project members, which is not the intention
[19:47:05] <fuzzie> the includes one seems fine to me if it's tested and you're sure it'll work with msvc6 etc
[19:47:36] <fuzzie> Edheldil_: well, mattinm has been around semi-recently..
[19:48:30] <fuzzie> and i think you can turn off git commit access without affecting their membership status, although it doesn't seem it really matters too much
[19:49:00] <fuzzie> if someone causes problems, it's easy enough to just push an older git tree
[19:52:50] <fuzzie> we have another thankyou note from an embedded user in the forum :) sweet of people
[19:52:51] <tomprince_loki> If you are happy with the patches through to the GetPalette one.
[19:53:03] <fuzzie> i have not tested them. they look fine.
[19:53:30] <tomprince_loki> Also, what about the FileGlob patch from the cleanup branch. The rest probably don't want to be applied just yet.
[19:53:34] <fuzzie> the enum one seems pointless, as noted before
[19:55:12] * Edheldil_ reads what are 'Three investigators' ... Ahh, I loved these books!
[19:55:32] <CIA-74> GemRB: 03tom.prince * r5904ebed812e 10gemrb/gemrb/plugins/ (4 files in 4 dirs):
[19:55:32] <CIA-74> GemRB: ImageMgr: Clean up functions obsoleted by Bitmap/Image.
[19:55:32] <CIA-74> GemRB: igned-off-by: Tom Prince <tom.prince@ualberta.net>
[19:55:34] <CIA-74> GemRB: 03tom.prince * r2e88b13374a8 10gemrb/gemrb/plugins/Core/ (Map.cpp Map.h MapControl.cpp):
[19:55:34] <CIA-74> GemRB: Map::SmallMap: Turn this into a Sprite2D.
[19:55:34] <CIA-74> GemRB: igned-off-by: Tom Prince <tom.prince@ualberta.net>
[19:55:36] <CIA-74> GemRB: 03tom.prince * r09b9c9aa1b9e 10gemrb/gemrb/plugins/Core/PathFinder.h:
[19:55:36] <CIA-74> GemRB: SearchMap: Use a meaningful enum for SearchMap values.
[19:55:36] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:55:39] <CIA-74> GemRB: 03tom.prince * ra174a24415fe 10gemrb/gemrb/plugins/Core/ (Interface.cpp Interface.h):
[19:55:39] <CIA-74> GemRB: Interface::GetPalette: Change this to use GetImage to get the palette directly.
[19:55:39] <CIA-74> GemRB: ImageMgr::GetPalette had two completely distinct usages. This splits off the
[19:55:39] <CIA-74> GemRB: part that is independent of the image filetype.
[19:55:39] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:55:43] <CIA-74> GemRB: 03tom.prince * rdf4dabbeb73f 10gemrb/gemrb/plugins/ (6 files in 3 dirs):
[19:55:43] <CIA-74> GemRB: PLTImporter: Change this to a PalettedImageMgr.
[19:55:43] <CIA-74> GemRB: PLTImporter was abusing ImageMgr::GetPalette to set the palettes to use.
[19:55:44] <CIA-74> GemRB: Now we pass in the palettes directly as we are generating the sprite.
[19:55:44] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:55:45] <CIA-74> GemRB: 03tom.prince * r2560f98b0a1b 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:
[19:55:45] <CIA-74> GemRB: GUIScript: Make all color indices mandatory for SetButtonPLT.
[19:55:45] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:55:47] <CIA-74> GemRB: 03tom.prince * r2cd129694689 10gemrb/gemrb/plugins/ (9 files in 4 dirs): (log message trimmed)
[19:55:47] <CIA-74> GemRB: ImageMgr: Simplify GetPalette to only return the actual image palette.
[19:55:47] <CIA-74> GemRB: Previously, BMPImporter would do different stuff for 24bpp images, but that
[19:56:13] <CIA-74> GemRB: code was moved to Interface, so we can drop it now. GetPalette now does nothing
[19:56:13] <CIA-74> GemRB: and reports an error in a>8bpp case.
[19:56:13] <CIA-74> GemRB: Note: MOSImporter has a palette, but we treat it as 32bpp image, so it doesn't
[19:56:13] <CIA-74> GemRB: implement GetPalette.
[19:56:25] <Lightkey> /kick CIA-74 flood
[19:56:54] <fuzzie> and i hate the way FindInDir is modifying a string passed as an argument without any documentation :) but sure, if it works
[19:57:02] <Edheldil_> btw, speaking of #ifdefs, there's a reason Linus more or less bans them in code, as they make it rather unreadable :)
[19:57:08] <lynxlynxlynx> GUIScript: Make all color indices mandatory for SetButtonPLT. <-- please adjust the docs too
[19:58:00] <Lightkey> Edheldil_: I was soo disappointed when someone told me they actually were not written by Hitchcock ;-P
[19:58:55] <tomprince_loki> The docs don't mention the optionallity one way or another.
[20:00:00] <Edheldil_> Lightkey, I did not know that ... I thought it was just a case of same names :)
[20:02:23] <Edheldil_> My most favourite were Arthur Ransome's books, though, Karl May's and plethosa of others... I used to be a serious bookworm before I started to work
[20:03:05] <Lightkey> reminds me, I was reading some other books around that time from an author who was thought to be a group, since he wrote so many books.. Sherlock Holms style, can not remember the name..
[20:04:05] <Edheldil_> Edggar Wallace, perhaps?
[20:04:42] <Lightkey> hm.. I think yes
[20:05:42] <Lightkey> I associated that name more with the horribl..y funny movie series ;p
[20:05:54] <Lightkey> somehow totally different to me
[20:06:07] <Edheldil_> I preferred D.L.Sayers's Peter Wimsey :)
[20:06:41] <Lightkey> never heard of
[20:08:08] <Lightkey> anyway, I just bought the new edition of '70-'80s series Mark Brandis, reading time
[20:08:13] <Edheldil_> something named (in Czech translation) Death needs advertising was a readlly good novelette (or how is it called)
[20:09:04] <Edheldil_> never hard of him :)
[20:09:09] <Edheldil_> heard
[20:09:20] <Lightkey> that is to be expected
[20:10:43] <Lightkey> second most popular German space opera, after Perry Rhodan of course.. though it is for juveniles, still quite a gripping story
[20:11:45] <Lightkey> and horribly distorted universe, defying the laws of physics etc...
[20:13:14] <lynxlynxlynx> http://fukung.net/v/12384/61565f075a4420767c7524469305bc2f.gif <-- consecutive criticals
[20:14:21] <CIA-74> GemRB: 03tom.prince * rb903cf3a95d7 10gemrb/gemrb/plugins/ (4 files in 2 dirs):
[20:14:21] <CIA-74> GemRB: VFS: Split FindInFile into FileGlob.
[20:14:21] <CIA-74> GemRB: This simplifies the logic in DirectoryImporter, and gets rid of a malloc on
[20:14:21] <CIA-74> GemRB: the fast-path there.
[20:14:21] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[20:14:52] <tomprince_loki> With documentation. :)
[20:15:48] <fuzzie> thankyou
[20:16:35] <Lightkey> lynxlynxlynx: wat
[20:17:01] <lynxlynxlynx> critical hit?
[20:17:40] <lynxlynxlynx> rabbid dog deals 3 damage
[20:17:46] <lynxlynxlynx> <NAME> - Death
[20:17:51] <Lightkey> oh
[20:18:25] <Lightkey> I was thinking of something different by "criticals" :-)
[20:18:29] <fuzzie> some of my palette colours are kind of odd in sf HEAD, but that might be random
[20:19:42] --> edheldil__ has joined #GemRb
[20:21:18] <fuzzie> more likely that GetImage code is broken for 32bpp
[20:22:42] <Lightkey> btw, if anyone ever find me that juvenile book series again, which played mostly under-water in submarines, under-water structures and devices to talk to dolphins (no, not SeaQuest DSV), I would be eternally greatful
[20:26:57] <-- Edheldil_ has left IRC (Quit: Really?)
[20:28:05] <edheldil__> Lightkey: there was 'Boy Scouts in submarine', but it probably is not what you are looking for :)
[20:31:07] <tomprince_loki> Is there any reason to keep the Config directory around? Does it even still work?
[20:31:13] <CIA-74> GemRB: 03tom.prince * rdd6cb8eabedd 10gemrb/ (260 files in 44 dirs):
[20:31:13] <CIA-74> GemRB: Switch to using -I to find includes, rather than relative paths.
[20:31:13] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[20:32:07] <lynxlynxlynx> it isn't even complete iirc
[20:32:27] <fuzzie> I would guess it is long-outdated by external tools.
[20:34:25] <lynxlynxlynx> and it is better to be smarter about the defaults
[20:35:08] <edheldil__> time to get rid of it :)
[20:37:32] * fuzzie sighs
[20:38:15] <fuzzie> would appreciate no-one making changes to the tree for a few minutes
[20:38:22] <fuzzie> i mean, other than the Config thing
[20:38:33] <fuzzie> i have a range of shiny new segfaults
[20:39:09] <CIA-74> GemRB: 03tom.prince * r2a83d7670b3b 10gemrb/gemrb/Config/ (Config.cpp Makefile.am):
[20:39:09] <CIA-74> GemRB: Config: get rid of old obsolete incomplete config generator.
[20:39:09] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[20:42:26] <fuzzie> so nice how libtool checks for f77
[20:52:13] <tomprince_loki> Where is it segfaulting?
[21:00:19] <fuzzie> a few places
[21:00:56] <CIA-74> GemRB: 03fuzzie * r9ebbf682a7d0 10gemrb/gemrb/plugins/Core/Map.cpp: don't segfault on missing SmallMap
[21:02:05] <lynxlynxlynx> dejavu
[21:02:36] <fuzzie> yes :)
[21:06:33] <fuzzie> the rest are maybe all unrelated..
[21:14:15] <tomprince_loki> or.cz/core: The Great Rename (part 2) and updated patch moving core out of plugins.
[21:14:42] <fuzzie> get edheldil__ to look at The Great Rename?
[21:16:08] <fuzzie> edheldil__: http://repo.or.cz/w/gemrb.git/commitdiff/321a68520f361b5ee3ef6bcfa1dced727daf6085 ?
[21:18:11] <wjp> aieee, that's big :-)
[21:18:18] <fuzzie> well, or wjp :)
[21:19:02] <tomprince_loki> Run it through 'git show -U0' and it isn't as scary.
[21:19:11] <wjp> it builds for me in any case
[21:19:22] <fuzzie> ok, current sf git is completely broken for me, for some reason.
[21:20:01] <fuzzie> a lot of things are just quietly not working, cutscenes stopping at random, etc.
[21:20:06] <fuzzie> let me build a clean tree.
[21:22:11] <fuzzie> tomprince_loki: have you run this all through valgrind at any point?
[21:22:20] <tomprince_loki> No.
[21:22:41] <fuzzie> (i am lacking in the multi-core fast x86 boxen you all have, unfortunately.)
[21:23:34] <tomprince_loki> I'll try it here now then.
[21:23:57] <fuzzie> well, i just mean, this is why it is taking me a while :)
[21:24:05] <fuzzie> but no objections, of course
[21:24:42] <wjp> I think I'm fine with The Great Rename (part 2)
[21:25:06] <fuzzie> no objections from me
[21:26:32] --> cfchris6 has joined #GemRb
[21:26:51] * edheldil__ looks
[21:27:40] <lynxlynxlynx> the general idea is fine to me too
[21:28:09] <tomprince_loki> How about the other patch there?
[21:29:46] <lynxlynxlynx> no time to look today, sorry
[21:29:49] <fuzzie> why 'Core' -> 'core'?
[21:30:33] <wjp> I have to go; good night
[21:30:36] <-- cfchris6_ has left IRC (Ping timeout: 276 seconds)
[21:30:48] <tomprince_loki> Cause most things in that directory are lowercase, and the library is gemrb_core not Core.
[21:31:35] <tomprince_loki> And probably a bit of unix-y lowercase filenames. :)
[21:31:48] <fuzzie> ok, *something* from the last few days definitely broke things.
[21:32:24] <fuzzie> clean build and almost every cutscene i try fails
[21:33:12] <fuzzie> i'll try reverting the obvious culprit..
[21:35:31] <tomprince_loki> What is the obvious culprit?
[21:35:47] <fuzzie> the VFS changes
[21:35:48] <wjp> there's quite a number of valgrind errors on bg2 startup in GetPalette, GetPixel, RefreshEffects, ...
[21:36:13] <fuzzie> RefreshEffects is a known thing, I think.
[21:36:26] <fuzzie> Maybe put the log in pastebin?
[21:37:28] <wjp> http://www.usecode.org/gemrb/valgrind.log
[21:37:30] <wjp> really going now :-)
[21:37:33] <fuzzie> ninight
[21:37:53] <wjp> (it's right after bg2 chargen)
[21:42:19] <fuzzie> That's kind of weird, it seems not introduced by recent changes at a glance.
[21:44:36] <fuzzie> Reverting VFS changes doesn't help.
[21:45:16] <lynxlynxlynx> git-bisect to the rescue
[22:05:03] <edheldil__> sigh, missing strmod.2da ...
[22:06:35] <edheldil__> used to be optional ...
[22:08:08] <fuzzie> i did offer to keep it optional at the time :)
[22:09:19] <fuzzie> could still be, if you want it
[22:11:22] <fuzzie> they're definitely not really in the spirit of generic rulesystems..
[22:11:47] <edheldil__> no, they are not
[22:12:08] <fuzzie> but unfortunately they're pretty tied into the core right now
[22:12:18] <fuzzie> i don't really see why, most of them are only accessed from python anyway
[22:13:05] <fuzzie> ok, if i revert the tree back to when cutscenes last worked for me, it doesn't help. not even with clean tree+data. i will look into it further tomorrow.
[22:13:31] <tomprince_loki> Weird.
[22:13:49] <edheldil__> if you can cheaply keep them optional good, but do not sweat about it. Touching empty files seems to work just as well
[22:14:06] <fuzzie> i guess we probably introduced some non-deterministic bug recently, hence my wondering about valgrind.
[22:15:11] <edheldil__> the great rename works ok, it seems
[22:19:50] <tomprince_loki> How about moving core?
[22:20:03] <tomprince_loki> I'll wait to apply it until lynxlynxlynx and wjp weigh in.
[22:20:06] <CIA-74> GemRB: 03tom.prince * r841f010c46bc 10gemrb/gemrb/plugins/ (53 files in 25 dirs): (log message trimmed)
[22:20:06] <CIA-74> GemRB: The Great Rename (Part 2)
[22:20:06] <CIA-74> GemRB: At some point we rename the classes as well. Rename most plugin classes to match the
[22:20:06] <CIA-74> GemRB: files they are located in.
[22:20:06] <CIA-74> GemRB: Exceptions:
[22:20:07] <CIA-74> GemRB: - ACMImporter: This is getting split up soon.
[22:20:07] <CIA-74> GemRB: - MVEPlayer: We have both MVEPlay and MVEPlayer.
[22:23:06] <tomprince_loki> It doesn't seem that the GetPalette valgrind stuff is recent.
[22:23:57] <fuzzie> I noted the same above; I wouldn't worry about it.
[22:24:42] <tomprince_loki> I suspect it is something being passed in that is undefined, that we are trying to read from a random palette.
[22:24:53] <fuzzie> The old GetPalette code was broken (it read off the end), so I was ignoring all valgrind output on the basis you'd at least fix that bit.
[22:26:08] <edheldil__> tomprince: do you mean Core -> core ? why not, but AAACore would be better ;-)
[22:26:35] <tomprince_loki> no, gemrb/plugins/Core -> gemrb/core
[22:27:23] <tomprince_loki> Which is what the include path patch was about, among other things.
[22:27:52] <fuzzie> Avenger seemed pretty positive about the idea.
[22:28:13] <fuzzie> I really don't care, it works fine for me either way.
[22:28:50] <fuzzie> You can run valgrind in a mode where it will track the source of undefined values, btw.
[22:37:00] <fuzzie> The weird cutscene/etc issue is a combination of old random bugs, it seems. Ninight!
[22:37:10] <tomprince_loki> Night.
[22:37:29] <tomprince_loki> Good we exposed them then. If that is what happened.
[22:40:19] <fuzzie> CHECK_CXX_COMPILER_FLAG seems not to work for linker flags, btw.
[22:41:36] <fuzzie> Weird though. Hm.
[22:44:17] <fuzzie> Definitely doesn't work though, I can pass nonsense. Really night now!
[22:44:20] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[22:47:53] <tomprince_loki> Yes, it does seem that CREImporter is gives a bunch of unitialized memory errors. Some, anyway of the GetPalette errors come from there.
[22:52:09] <-- ratpor has left IRC (Quit: Get used to disappointment.)
[22:55:35] <edheldil__> I am for the core move. Whatever makes gemrb more intuitive ...
[23:04:10] <-- raevol has left IRC (Quit: Leaving.)
[23:27:53] <-- edheldil__ has left IRC (Ping timeout: 265 seconds)