#gemrb@irc.freenode.net logs for 20 Aug 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:06:27] * fuzzie sighs
[00:31:03] --> raevol has joined #GemRb
[00:31:22] --> tomprince_loki has joined #GemRb
[01:00:02] <Lightkey> oh, Might & Magic Heroes 6, maybe even for Mac OS X
[04:01:08] <-- Lightkey has left IRC (Ping timeout: 260 seconds)
[04:02:43] --> Lightkey has joined #GemRb
[05:12:14] <-- tomprince_loki has left IRC (Read error: Connection reset by peer)
[05:45:35] --> Maighstir has joined #GemRb
[06:09:01] <-- raevol has left IRC (Quit: Leaving.)
[07:34:47] <edheldil> Hi
[07:35:01] <-- |Cable| has left IRC (Remote host closed the connection)
[07:55:11] <edheldil> I now understand the lowest level memory management in PS:T a bit, so if you are interested, I can describe it
[07:57:03] <edheldil> no idea how much of the code actually use it, though
[08:30:42] <fuzzie> hi edheldil
[08:31:16] --> lynxlynxlynx has joined #GemRb
[08:31:16] --- ChanServ gives channel operator status to lynxlynxlynx
[08:31:45] <fuzzie> and hi lynx
[08:31:51] <lynxlynxlynx> gmornin
[09:36:37] <fuzzie> nothing on the release todo?
[09:58:16] <lynxlynxlynx> not on mine
[09:59:00] <lynxlynxlynx> i'll prepare the materials later today, so there's still some time for adding last minute breakages
[10:26:19] --> avenger has joined #GemRb
[10:26:20] --- ChanServ gives channel operator status to avenger
[10:26:29] <avenger> what changed about savegame and holder again? i cannot recompile on windows
[10:26:54] <avenger> i don't quite see why we need this thing anyway
[10:29:26] <avenger> ok, adding #include SaveGameIterator.h into the msvc section of interface.h fixed this
[10:30:06] <avenger> i don't know why suddenly i need that
[10:34:19] <avenger> cool, and the guiscript engine doesn't start
[10:38:39] <fuzzie> uh
[10:38:55] <fuzzie> nothing relevant changed for months
[10:39:04] <avenger> a day of tom.prince a day for me to recover
[10:39:13] <avenger> the include file change is recent
[10:39:16] <fuzzie> oh, i guess vc++6 is dumb with templates
[10:39:19] <fuzzie> hmm
[10:39:35] <avenger> there is no template in the include file handling
[10:39:45] <fuzzie> and, well, we don't *need* the thing, but no-one else volunteers to do it properly
[10:40:38] <fuzzie> but nothing relevant changed
[10:41:17] <avenger> this line: if ((includeFP == NULL) || (PyRun_SimpleFileEx(includeFP, includeFile, true) == -1)) {
[10:41:27] <avenger> crashes, i got the includefile, and got it opened
[10:41:36] <fuzzie> oh
[10:41:38] <avenger> it has the 2 lines in it
[10:41:46] <fuzzie> right
[10:41:59] <avenger> so?
[10:42:02] <fuzzie> right, that isn't allowed
[10:42:07] <fuzzie> revert the two commits
[10:42:17] <fuzzie> you want me to?
[10:42:32] <avenger> yes, i will just comment it out here
[10:42:41] <avenger> i'm on windows, and don't want to reboot
[10:43:03] <avenger> so what isn't allowed?
[10:43:19] <fuzzie> passing FILE* around
[10:43:24] <fuzzie> the python documentation does say
[10:43:32] <avenger> LOL
[10:43:37] <lynxlynxlynx> btw avenger, i'll tag 0.6.2 in a few hours, so if you have any last minute fixes to commit, do it soon
[10:43:48] <fuzzie> on sane operating systems, passing FILE* around is fine
[10:43:56] <avenger> lynx the current state is crashy
[10:43:58] <fuzzie> so it's easy to forget that Windows has no shared C runtime
[10:44:19] <avenger> ahh, i see this is the separate file * array in modules
[10:44:20] <lynxlynxlynx> with the reverts it will be back to less crashy
[10:44:42] <avenger> now i see why this didn't cause problem on non windows
[10:45:23] <avenger> fuzzie, i also needed that include i spoke earlier
[10:45:36] <avenger> adding #include SaveGameIterator.h into the msvc section of interface.h
[10:45:36] <fuzzie> well, that hasn't changed
[10:45:53] <avenger> it wasn't there :)
[10:46:01] <fuzzie> why is it needed?
[10:46:06] <avenger> to compile
[10:46:10] <fuzzie> yes, but why?
[10:46:41] <avenger> i remove it and will tell the error message
[10:46:55] <fuzzie> every time we add some new include there, it makes compiles slower, so i would prefer to fix the bug
[10:47:00] <avenger> e:\gemrb\gemrb\core\holder.h(63) : error C2027: use of undefined type 'SaveGame'
[10:47:02] <avenger> e:\gemrb\gemrb\core\interface.h(78) : see declaration of 'SaveGame'
[10:47:03] <avenger> e:\gemrb\gemrb\core\holder.h(61) : while compiling class-template member function '__thiscall Holder<class SaveGame>::~Holder<class SaveGame>(void)'
[10:47:05] <avenger> e:\gemrb\gemrb\core\holder.h(63) : error C2227: left of '->release' must point to class/struct/union
[10:47:06] <avenger> e:\gemrb\gemrb\core\holder.h(61) : while compiling class-template member function '__thiscall Holder<class SaveGame>::~Holder<class SaveGame>(void)'
[10:47:29] <avenger> i would simply get rid of shared data between python and the core
[10:47:44] <avenger> it causes tons of problems for no gain.
[10:47:54] <avenger> or this is to speed up the gui on savegame lists?
[10:47:59] <fuzzie> that doesn't tell me which .cpp file it is
[10:48:04] <avenger> ALL :P
[10:48:12] <fuzzie> huh?
[10:48:25] <avenger> i get it for animation.cpp, actor.cpp, actorblock.cpp for example
[10:48:43] <avenger> yes, all
[10:48:44] <fuzzie> hmm
[10:48:50] <avenger> windowmgr, worldmapmgr :)
[10:48:55] <fuzzie> that makes no sense
[10:49:15] <fuzzie> none of those line numbers have any of that stuff
[10:49:20] <avenger> or rather. Window.cpp Worldmap.cpp
[10:49:23] <avenger> the mgr's are fine
[10:49:33] <avenger> even the recently added Dialoghandler
[10:49:36] <fuzzie> you're sure you're not using broken precompiled headers or something?
[10:49:37] <avenger> that's the last now :)
[10:49:49] <avenger> ok, i do a make clean?
[10:49:51] <fuzzie> well
[10:49:55] <fuzzie> there's really no .cpp file in the error?
[10:49:59] <fuzzie> i mean, no line number?
[10:50:23] <avenger> Font.cpp
[10:50:25] <avenger> e:\gemrb\gemrb\core\holder.h(63) : error C2027: use of undefined type 'SaveGame'
[10:50:27] <avenger> e:\gemrb\gemrb\core\interface.h(78) : see declaration of 'SaveGame'
[10:50:28] <avenger> e:\gemrb\gemrb\core\holder.h(61) : while compiling class-template member function '__thiscall Holder<class SaveGame>::~Holder<class SaveGame>(void)'
[10:50:30] <avenger> e:\gemrb\gemrb\core\holder.h(63) : error C2227: left of '->release' must point to class/struct/union
[10:50:32] <avenger> e:\gemrb\gemrb\core\holder.h(61) : while compiling class-template member function '__thiscall Holder<class SaveGame>::~Holder<class SaveGame>(void)'
[10:50:36] <avenger> this is what i get when compiling font.cpp
[10:50:41] <fuzzie> but this is crazy
[10:50:46] <avenger> font uses game
[10:50:47] <fuzzie> that code is only used in SaveGameIterator
[10:51:12] <avenger> hmm font doesn't seem to use game
[10:51:25] <avenger> i thought it does, then i dont even know what causes this
[10:52:18] <fuzzie> well, i guess you have to add the header
[10:52:28] <avenger> what header? i added all
[10:52:35] <fuzzie> but this is no-one's fault, the only Holder<class SaveGame> is *in* SaveGameIterator.h
[10:52:36] <avenger> ahh you mean the thing i did?
[10:53:03] <avenger> it is complaining since that ptr->release
[10:53:25] <fuzzie> that was months ago
[10:53:31] <avenger> no
[10:53:34] <fuzzie> yes
[10:54:04] <fuzzie> the only new thing is an assert(), right?
[10:54:33] <avenger> hmm well, there is some new ptr->acquire() that's what i mixed it up with
[10:54:39] <avenger> but if i remove that, it still bugs
[10:55:19] <avenger> i would like it to not infect all compilation anyway
[10:55:27] <fuzzie> it doesn't!
[10:55:31] <avenger> if holder is not used by font, for example, then it shouldn't affect it
[10:55:33] <fuzzie> it isn't!
[10:55:39] <fuzzie> this is why i say, this makes no sense
[10:55:58] <CIA-26> GemRB: 03fuzzie * r3d6539ed22d8 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:
[10:55:59] <CIA-26> GemRB: revert e214601e and cf93e59a
[10:55:59] <CIA-26> GemRB: (passing FILE* around causes far too much trouble)
[10:56:00] <avenger> interface.h includes holder
[10:56:05] <fuzzie> your vc++ is doing something crazy, recompiling every template
[10:56:35] <fuzzie> there's no Holder<SaveGame> anywhere except SaveGameIterator.h
[10:56:58] <avenger> interface.h includes holder
[10:57:00] <fuzzie> yes
[10:57:06] <fuzzie> it uses it
[10:57:10] <fuzzie> but your errors aren't about holder
[10:57:30] <avenger> and there is Holder<video> for example
[10:57:33] <fuzzie> yes
[10:57:39] <fuzzie> but you get no error message about that :)
[10:57:41] <avenger> so nah, it is already spread out of savegameiterator
[10:58:01] <fuzzie> but, no, you're right, this is tomprince's fault
[10:58:02] <fuzzie> sigh
[10:58:07] <fuzzie> but the Holder is useful itself
[10:58:36] <fuzzie> ok, so, add a SaveGameIterator.h in there, it is necessary
[10:58:41] <avenger> ok, i admittedly don't understand this level of c++ :) too many pointers for me
[10:58:55] <fuzzie> Holder is what's called an 'intrusive smart pointer'
[10:59:07] <avenger> it is smart to hold me up ;P
[10:59:13] <fuzzie> it automatically increases and decreases RefCount in the 'held' object
[10:59:42] <fuzzie> because we had so many bugs where we leaked stuff or crashed because RefCount didn't get updated
[10:59:44] <avenger> but this is still msvc's fault, actually?
[10:59:47] <fuzzie> yeah
[11:00:00] <fuzzie> it tries constructing all the templates, for every file
[11:00:09] <fuzzie> even if they are not used
[11:00:14] <avenger> i see
[11:00:32] <fuzzie> we should make a SaveGame.h
[11:00:35] <avenger> isn't it possible to split them?
[11:00:41] <avenger> ahh ok, so it is possible
[11:01:24] <fuzzie> and i think we all agree, splitting is good
[11:02:11] <avenger> ok, i'm back to my original task, i'm just going over the effects to see what small nuances are missing
[11:02:31] <fuzzie> well, don't break anything before the release :)
[11:02:49] <avenger> not more than before :P
[11:03:01] <fuzzie> 'obvious' fixes have led to crashes before
[11:03:24] <avenger> the file stuff did break windows totally
[11:04:25] <avenger> i don't exactly see why is it a problem, though
[11:04:36] <fuzzie> because FILE* is internal to the C library which is in use
[11:04:37] <avenger> only guiscript module talks to python
[11:04:47] <fuzzie> and python is in a dll
[11:05:03] <fuzzie> and we *really* don't want to make people start building their own python
[11:05:06] <avenger> but it is not tied to interface, only the guiscript module
[11:05:27] <fuzzie> well, your cross-module malloc issues were a faulty build
[11:05:29] <avenger> so the file * should be safe in guiscript.cpp
[11:05:31] <fuzzie> you built with the wrong C library
[11:06:03] <fuzzie> but python is a different module itself, and *is* built with a different C library
[11:06:15] <avenger> oh, i see
[11:06:15] <fuzzie> so you can't pass things like this into python
[11:06:39] <avenger> ok, so this cannot even be fixed if we made gemrb non modular
[11:06:50] <fuzzie> no
[11:06:51] <avenger> because this is a gemrb vs python thing
[11:06:54] <fuzzie> yes
[11:07:09] <fuzzie> there is a warning right there at the top of the python documentation, actually
[11:07:11] <fuzzie> i missed it
[11:08:09] <avenger> ok, so the solution is how i executed the file
[11:08:13] <avenger> reading it into a buffer
[11:08:21] <avenger> and passing the buffer, instead of a file pointer
[11:08:31] <fuzzie> well, the solution is a compromise i think
[11:09:02] <avenger> why can't i pass a filename, bleh :)
[11:09:12] <avenger> if python wants to open it, do it
[11:09:28] <fuzzie> yes, it's a really dumb interface layer
[11:09:34] <avenger> it is really odd, because i do pass the filename already
[11:10:00] <fuzzie> i don't know wtf they were thinking
[11:11:03] <avenger> isn't there something like FILE *fp = Py_Open(filename); :)
[11:11:30] <avenger> so it is safe in python
[11:12:00] <fuzzie> maybe there is, but i don't see it
[11:12:18] <avenger> i still don't quite see why do i needto give filename AND pointer
[11:12:27] <fuzzie> the filename is used in error messages
[11:12:29] <avenger> maybe it is wise enough to open the file if the pointer is null?
[11:12:31] <fuzzie> it doesn't have to be an actual filename :)
[11:12:37] <avenger> oh, i see
[11:12:49] <fuzzie> i don't see any nice solution
[11:13:02] <fuzzie> given there is a code freeze today, i am not going to touch it
[11:13:15] <avenger> unless we compile python into the guiscript module
[11:13:40] <fuzzie> that means far more hassle for everyone trying to compile gemrb on Windows
[11:13:43] <fuzzie> i am not happy with that
[11:13:55] <avenger> ok, then just lets read the buffer
[11:14:22] <avenger> can you fix the repository?
[11:14:33] <fuzzie> sure, i already reverted the python stuff
[11:15:25] <avenger> ok, now finally it starts
[11:16:31] <CIA-26> GemRB: 03fuzzie * rb1f795fee95d 10gemrb/gemrb/core/ (Interface.h SaveGame.h SaveGameIterator.h): split SaveGame out into SaveGame.h, hopefully fix vc++ compilation
[11:20:53] <avenger> stores don't show items selected for selling, only the first one
[11:20:54] <avenger> :(
[11:20:57] <avenger> in bg2
[11:21:14] <avenger> the buying side works
[11:21:24] <fuzzie> i told you about this
[11:21:33] <fuzzie> the CHU has it like that
[11:21:41] <avenger> so this is a chu problem?
[11:21:57] <fuzzie> and i tried working it out in DLTCEP, but then DLTCEP had the wrong flag names
[11:21:59] <avenger> the first button is different?
[11:22:14] <fuzzie> yes, the first button is different
[11:22:46] <fuzzie> i tried asking about it: we already do some hack on CHU files in CHUImporter, to force the selected BAM cycle
[11:23:54] <avenger> yes, the same is needed here
[11:24:18] <fuzzie> it is broken for all the bg2 sell-type lists, apart from the top-most button
[11:24:33] <fuzzie> but it can be either fixed in the CHUImporter or in the GUIScript, pick one..
[11:25:07] <avenger> yes, the selected field is unset in all except the first
[11:25:49] <avenger> the buy side is fine, the sell side is only the top button, crappy file :)
[11:26:13] <fuzzie> it works fine if you hack the CHU :)
[11:27:02] <avenger> via the guiscript, yes
[11:27:13] <avenger> because you cannot do this in the chu loader
[11:27:25] <avenger> iwd2 guistore has them in this order: 1,2,0,3
[11:27:49] <avenger> and yes, the selected cycle is the 0, i checked this by looking at the bam itself
[11:28:28] <fuzzie> well, i just used DLTCEP
[11:28:36] <avenger> the new one, i guess?
[11:28:44] <fuzzie> but i got fed up when i found this hack in the CHUImporter
[11:30:06] <avenger> odd, i see this: Button.SetSprites ("GUISTBBC", Action, 0,1,2,0)
[11:30:21] <avenger> ahh this is outside
[11:30:31] <avenger> so there are already bam cycle hacks in this file :)
[11:30:51] <fuzzie> meh :P
[11:31:47] <avenger> Button.SetSprites ("GUIBTBUT", Action, 0,1,2,5)
[11:31:57] <avenger> added this at line 224
[11:33:39] <avenger> of course it didn't work first
[11:33:50] <avenger> action is... something else
[11:34:44] <avenger> Button.SetSprites ("GUIBTBUT", 0, 0,1,2,5)
[11:36:14] <avenger> ok this helped
[11:36:55] <avenger> when leaving store, the portraits are not updated
[11:37:08] <avenger> guess it misses a portrait update event flag
[11:40:45] <avenger> added core->SetEventFlag(EF_PORTRAIT); in line 5282 in guiscript.cpp
[11:50:45] <avenger> oh i see a nice openfail string in the watcher's keep, good :)
[12:02:21] <fuzzie> :)
[12:02:35] <fuzzie> i think lynx knew of some other portrait flags
[12:36:25] <Maighstir> trying to compile with GCC 3.4 (as included with the easy-to-install MinGW) gives errors, though I'm unsure if you still support that version
[12:36:26] <Maighstir> Scanning dependencies of target AREImporter
[12:36:26] <Maighstir> [ 69%] Building CXX object gemrb/plugins/AREImporter/CMakeFiles/AREImporter.dir/AREImporter.obj
[12:36:26] <Maighstir> C:\dev\gemrb\gemrb\plugins\AREImporter\AREImporter.cpp: In member function `virtual Map* AREImporter::GetMap(const char*, bool)':
[12:36:26] <Maighstir> C:\dev\gemrb\gemrb\plugins\AREImporter\AREImporter.cpp:612: warning: convertingof negative value `-0x000000001' to `ieStrRef'
[12:36:26] <Maighstir> C:\dev\gemrb\gemrb\plugins\AREImporter\AREImporter.cpp:811: warning: convertingof negative value `-0x000000001' to `ieStrRef'
[12:36:27] <Maighstir> mingw32-make[2]: *** [gemrb/plugins/AREImporter/CMakeFiles/AREImporter.dir/AREImporter.obj] Error 1
[12:36:29] <Maighstir> mingw32-make[1]: *** [gemrb/plugins/AREImporter/CMakeFiles/AREImporter.dir/all]
[12:36:30] <Maighstir> Error 2
[12:36:31] <Maighstir> mingw32-make: *** [all] Error 2
[12:37:58] <fuzzie> hm
[12:37:59] <fuzzie> my bad :)
[12:38:47] <fuzzie> does it work if you change the '-1' to '(ieStrRef)-1'?
[12:43:07] <Maighstir> it's past that point at least
[12:44:33] <fuzzie> so i should commit that?
[12:44:42] <Maighstir> more errors though
[12:44:46] <Maighstir> C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/stl_uninitialized.h: In member function `DataStream* KEYImporter::GetStream(const char*, ieWord)':
[12:44:46] <Maighstir> C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/stl_uninitialized.h:82: warning: '__cur' might be used uninitialized in this function
[12:44:46] <Maighstir> mingw32-make[2]: *** [gemrb/plugins/KEYImporter/CMakeFiles/KEYImporter.dir/KEYImporter.obj] Error 1
[12:44:46] <Maighstir> mingw32-make[1]: *** [gemrb/plugins/KEYImporter/CMakeFiles/KEYImporter.dir/all] Error 2
[12:44:46] <Maighstir> mingw32-make: *** [all] Error 2
[12:45:05] <fuzzie> hmm.
[12:45:23] <avenger> its name is stl_uninitialized.h :)
[12:48:00] <fuzzie> gcc 3.x bug, i guess
[12:48:53] <fuzzie> apparently it decides that when you do 'a = b;', a is uninitialized
[12:50:09] <fuzzie> certainly no way for me to look into it without a line number in the .cpp
[12:51:14] <Maighstir> that's the only thing it says though, when trying to build KEYImporter.obj
[12:52:57] <fuzzie> although some of this code is not so clever
[12:54:16] <fuzzie> Maighstir: what happens if you comment out the FindBIFOnCD line and the line before it?
[12:54:25] <fuzzie> (line 248 + 249 of KEYImporter.cpp)
[12:56:13] <Maighstir> building...
[12:58:54] <Maighstir> same error
[12:59:22] <fuzzie> ok. not much i can do about that.
[12:59:30] <fuzzie> you can disable warnings if you actually want to build it.
[12:59:57] <Maighstir> except it complains about FindBIFonCD being defined but not used
[13:02:05] <Maighstir> yeah, I was trying to create some easy-to-follow build instructions and then testing them myself to see if they work... I'll just either add a flag to the bat file or not recommend the older but easier to install mingw
[13:03:02] <CIA-26> GemRB: 03fuzzie * ra812bb310024 10gemrb/gemrb/plugins/AREImporter/AREImporter.cpp: explicitly cast -1 values to unsigned
[13:03:11] <CIA-26> GemRB: 03fuzzie * ree35361cf34f 10gemrb/gemrb/plugins/KEYImporter/KEYImporter.cpp: don't make a copy of pathlist every time we look for a file
[13:07:32] <avenger> fuzzie please add those changes i mentioned too, i don't want them missed
[13:08:06] <fuzzie> i can't test the store change
[13:11:11] <CIA-26> GemRB: 03fuzzie * rf0077a60698c 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: set EF_PORTRAIT when leaving a store
[13:23:13] <avenger> hmm we don't implement ac vs creature type?
[13:24:10] <lynxlynxlynx> i think there is some code for it
[13:24:32] <fuzzie> lynxlynxlynx: maybe you can test Avenger's store change?
[13:24:53] <fuzzie> it didn't cause any disasters when i did it to the CHU, so it should be 'safe' to take
[13:25:09] <avenger> i tested it, :)
[13:25:12] <lynxlynxlynx> later, i'm supposed to be working ;)
[13:25:25] <fuzzie> avenger: well, if you have a diff?
[13:25:39] <fuzzie> lynxlynxlynx: ah, ok :)
[13:26:09] --> tomprince_loki has joined #GemRb
[13:27:06] <avenger> yeah, here is: BonusAgainstCreature
[13:27:58] <avenger> no one calls it
[13:29:45] <avenger> i'm adding it
[13:30:16] <fuzzie> this is the kind of thing which is not such a good idea to change on release day :P
[13:31:26] <fuzzie> it has never been called, according to history
[13:32:07] <avenger> hey, it is safe :P
[13:32:24] <fuzzie> adding a call to an untested function? :)
[13:32:54] <avenger> yes
[13:33:07] <avenger> it is totally safe :D
[13:33:08] <fuzzie> because you hope really hard it'll not have a bug no-one saw? :)
[13:33:53] <fuzzie> if param2 is 9, then it looks up ids_stats[7], off the end of the array
[13:34:15] <avenger> the worst that can happen ....
[13:34:19] <avenger> hmm, well,
[13:34:26] <avenger> should be 2-8?
[13:34:29] <fuzzie> and is this ids stuff the same for iwd2?
[13:35:07] <avenger> no, that's why i don't do this by opcode code, but name
[13:35:26] <avenger> iwd2 shouldn't have this opcode
[13:35:51] <avenger> ok, so that 9 is actually 8?
[13:35:51] <fuzzie> so maybe a good idea to add a comment that it is game-specific
[13:36:01] <fuzzie> well, if there are only 7 IDS targets, yes
[13:36:51] <avenger> it would have caused problem only if the spell is written buggy
[13:36:58] <fuzzie> it looks ok otherwise, if you're sure 0 param1 means always match
[13:37:16] <avenger> yes, it means that
[13:37:50] <fuzzie> seems a bit pointless to bother looking up the stat in that case, but oh well :)
[13:38:36] <avenger> i think you are right, i think 0,0 would mean all too
[13:39:01] <avenger> the original crashes if it is in the range oto
[13:39:02] <avenger> too
[13:39:24] <fuzzie> well, in bg2 :)
[13:39:37] <avenger> hmm , wait, actually it won't for this opcode
[13:39:52] <fuzzie> but i would like for gemrb to avoid crashes
[13:41:22] <avenger> actually 99% of the bg2 engine crashes are actually assertions
[13:41:31] <avenger> just somehow the info window is not appearing
[13:42:01] <fuzzie> oh, right, i saw code in ToBEx to do something with that
[13:42:08] <avenger> i mean, they are intentional stops, not sloppy coding
[13:42:22] <fuzzie> but, well, if you assert on a bad spell, you have sloppy coding :)
[13:42:25] <avenger> but i agree, i would avoid them too
[13:43:59] <avenger> hmm, i don't know if i have to add or subtract this from defense :)
[13:44:26] <avenger> it was the worst design ideas to have the lower ac the better :)
[13:45:35] <fuzzie> at least that one isn't bioware's fault
[13:45:40] <avenger> yep
[13:45:42] <-- avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716])
[13:59:36] <CIA-26> GemRB: 03avenger_teambg * r849a13293c3b 10gemrb/gemrb/GUIScripts/bg2/GUISTORE.py: fixed displaying of selection of items to sell
[13:59:37] <CIA-26> GemRB: 03avenger_teambg * r98e76d5adb5c 10gemrb/gemrb/ (3 files in 3 dirs): finished AC bonus vs creature type implementation
[14:01:29] <lynxlynxlynx> that would be better done in GetDefense
[14:01:34] --> Avenger has joined #GemRb
[14:01:34] --- ChanServ gives channel operator status to Avenger
[14:01:47] <Avenger> ok, i won't add any new stuff
[14:02:15] <lynxlynxlynx> oh, you weren't here: that would be better done in GetDefense
[14:02:45] <Avenger> hmm, i didn't do that because i didn't want to pass actor there
[14:03:10] <Avenger> it is target->GetDefense... So, GetDefense would have to be getting 'this'
[14:03:55] <Avenger> it is better to keep that function simple, maybe we need it for other stuff where there is no actor to defend against
[14:04:01] <Avenger> like printing it in gui
[14:05:44] <fuzzie> well, PerformAttack should be a lot simpler
[14:06:36] <fuzzie> but that is for another time
[14:08:02] <fuzzie> but GetDefense is *already* doing attack-specific stufff
[14:08:42] <Avenger> it isn't getting another object
[14:09:59] <Avenger> lol, you can rest while in combat
[14:10:17] <fuzzie> all AC stuff is ignored entirely by critical hits?
[14:10:42] <Avenger> i don't know if it is only natural 20
[14:10:57] <Avenger> normally a natural 20 means hit
[14:13:34] <fuzzie> but this whole thing needs some work
[14:13:50] <Avenger> looks like stinking cloud doesn't make me fall asleep and unmovable
[14:14:03] <Avenger> probably it causes the stance change, but i can move
[14:14:13] <fuzzie> stances are completely broken
[14:14:14] <Avenger> i thought this worked
[14:14:18] <fuzzie> but the rest should work, so heh
[14:14:23] <Avenger> i think it is not the stance problem
[14:14:26] <fuzzie> you're sure you didn't resist? the console should tell you
[14:14:53] <Avenger> the console is full of stuff, i got the portrait icon
[14:19:46] <fuzzie> got the spell?
[14:20:07] <Avenger> ?
[14:20:13] <Avenger> i can cast it
[14:20:45] <fuzzie> i mean, the resref
[14:21:35] <Avenger> spwi213
[14:24:22] <fuzzie> odd
[14:27:46] <lynxlynxlynx> should we also check for state sleep in immobile?
[14:27:54] <fuzzie> it sets HELPLESS, i thought we checked for that now
[14:28:35] <lynxlynxlynx> if it's in state_still
[14:28:54] <fuzzie> it is not
[14:31:49] <fuzzie> if it was working before, it is possible i broke it
[14:31:55] <fuzzie> but i don't see how it would work
[16:08:22] <fuzzie> are WFX files used?
[16:14:32] <Avenger> dunno
[16:15:33] <Avenger> i think you broke it, btw :)
[16:16:05] <Avenger> when you fixed targeting immobiles, i think you did too much :)
[16:16:25] <-- Avenger has left IRC (Quit: bye!)
[16:19:24] <fuzzie> very informative :p
[16:25:13] <fuzzie> still don't see any evidence of that :)
[16:26:44] <fuzzie> i found another 5 or so bugs to add to my list when looking through the code, though
[17:38:24] <CIA-26> GemRB: 03lynxlupodian * r733a29f8c9b9 10gemrb/NEWS: NEWS: 0.6.2
[17:39:10] <fuzzie> hoorah
[17:41:06] <CIA-26> GemRB: 03lynxlupodian * r35d4f4dc5bad 10gemrb/ (configure.in gemrb/includes/globals.h): 0.6.2
[17:48:07] <CIA-26> GemRB: 03lynxlupodian * rdb791562c091 10gemrb/ (configure.in gemrb/includes/globals.h): changed the version to 0.6.2-git until the next release
[17:48:09] <CIA-26> GemRB: 03lynxlupodian * r5ebcd515df02 10gemrb/gemrb/docs/en/Release.txt: Release.txt: added note about publishing tags and the versioning change
[17:51:59] <fuzzie> thoughts about doing another release relatively quickly?
[17:52:33] <lynxlynxlynx> if we have something to show, sure
[17:53:29] <lynxlynxlynx> http://lynxlynx.info/ie/gemrb-0.6.2-git.tar.gz <-- for testing
[17:54:05] <lynxlynxlynx> gotta go though; i haven't checked anything yet, but hopefully nothing is broken
[17:54:26] <fuzzie> will try it
[17:55:07] <lynxlynxlynx> will you be able to make a windows package today/tommorow?
[17:56:21] <fuzzie> although i guess the release shouldn't be labelled 0.6.2-git?
[17:56:42] <fuzzie> and i have no way of making the windows builds, although i could look into installing SDL/etc on monday if Gekz/others can't do it
[17:58:59] <lynxlynxlynx> Gekz: are you back at your old system? I remember you had some trouble the last time (not just time related)
[17:59:27] <lynxlynxlynx> tomprince_loki: can your buildbot do it?
[17:59:52] <lynxlynxlynx> fuzzie: oops, forgot to checkout the tag
[17:59:59] <lynxlynxlynx> codewise it is the same though
[18:00:37] <fuzzie> for a fast build we probably want a modern vs build
[18:00:56] <fuzzie> but i guess it really doesn't matter, we have few Windows users
[18:01:31] <lynxlynxlynx> the download stats disagree
[18:02:47] <fuzzie> well, few Windows users who care :)
[18:02:52] <fuzzie> lots of curious people, i'd hope
[18:03:19] <-- Maighstir has left IRC (Quit: Maighstir)
[18:08:59] <fuzzie> lynxlynxlynx: if you have any time to discuss random things, it would be good
[18:24:39] <tomprince_loki> I'll see if I can get access to my buildbot. The machine is at a different ip/name, and the windows buildslave isn't talking to the master right now.
[18:25:11] <fuzzie> that would be neat
[18:26:06] <tomprince_loki> Twill be a mingw-4.5 build.
[18:26:55] <CIA-26> GemRB: 03tom.prince * rdd4c9330ab97 10gemrb/gemrb/ (8 files in 6 dirs): Sort includes again.
[18:27:28] <tomprince_loki> or.cz/include: Fixed include handling that should work on windows.
[18:27:42] <tomprince_loki> or.cz/logging: Start at hacking new logging stuff.
[18:27:46] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[18:28:18] <fuzzie> oh, nice, that saves me the effort of trying to do the include thing :)
[18:28:48] <fuzzie> that is pretty much exactly what i wanted to do, too
[18:30:11] <fuzzie> although it would be nice to make the filename work too, and i am told that is possible
[18:30:16] <fuzzie> but i guess that can be applied after
[18:31:54] <fuzzie> the logging branch is a bit less tidy, though
[18:35:03] <fuzzie> in particular, printf()+abort() shouldn't be replaced with a plain log function
[18:35:42] <fuzzie> but the general idea is pretty great
[18:37:24] <fuzzie> oh, the stupid remove win32def.h thing is silly
[18:38:17] <fuzzie> we should just make a standard include file as part of our required header, and have a script to test for it as well as the copyright headers
[19:00:55] --> Avenger has joined #GemRb
[19:00:56] --- ChanServ gives channel operator status to Avenger
[19:01:10] <Avenger> happy birthday GemRB :)
[19:02:05] --> deepinthewoods has joined #GemRb
[19:02:18] <deepinthewoods> hi.
[19:02:34] <deepinthewoods> what program can I use to look at character animations?
[19:02:56] <deepinthewoods> I seem to remember doing it with something once.
[19:03:14] <deepinthewoods> dltcep doesn't seem to do it...
[19:03:41] <deepinthewoods> bamworkshop needs the actual bam files...which aren't in my bg2 dir
[19:04:20] <Avenger> what's up with dltcep?
[19:04:24] <Avenger> it should even play the anim
[19:06:08] <deepinthewoods> aha! just wasn't clicking the right button :(
[19:06:40] <Avenger> it has lots of buttons, hehe, its complexity is its curse and its merit as well :)
[19:07:40] <Avenger> i didn't learn how to program guis so it can be unintuitive
[19:08:30] * Lightkey knuddelflauscht Avenger
[19:09:06] <deepinthewoods> could u point me towards a sstand animation?
[19:09:12] <deepinthewoods> there's so many...
[19:09:58] <Avenger> any stand up anim will do?
[19:10:18] <Avenger> i prefer the iwd style ones they are easier to find
[19:10:28] --> D_T_G has joined #GemRb
[19:10:33] <Avenger> you mean stand up, or just standing around?
[19:10:48] <deepinthewoods> erm ok.
[19:10:51] <D_T_G> hi
[19:10:57] <D_T_G> congrats on 0.6.2 :)
[19:11:06] <Lightkey> nugrud in disguise
[19:11:18] <Avenger> mcorgu is a get up anim
[19:11:23] <D_T_G> yes it's me
[19:11:52] <deepinthewoods> I've just been playing bg2 they seem to have 2 different ones
[19:12:11] <Avenger> bg2 has iwd style anims too
[19:12:20] <Avenger> lots of different types, actually
[19:12:24] <fuzzie> you get to pick whichever one you want, really
[19:12:35] <deepinthewoods> sorry it's just the standing around ones i'm looking for...number of frames
[19:12:37] <D_T_G> I'm playing bg2 atm in gemrb too and i see the text "Damage taken(x)" is hardcoded
[19:12:42] <D_T_G> in gemrb
[19:12:43] <fuzzie> the dragons are the most annoying
[19:12:43] <Avenger> mcorgsc
[19:12:47] <fuzzie> D_T_G: in the message window?
[19:12:51] <Avenger> err mcorsc
[19:13:01] <D_T_G> yes, I should have this in Polish but having in English
[19:13:14] <Avenger> fuzzie: i got an animation splitter :)
[19:13:17] <fuzzie> D_T_G: bg1/iwd?
[19:13:22] <D_T_G> bg2
[19:13:30] <Avenger> so we could have dragon anims if we want
[19:13:31] <fuzzie> bg2 shouldn't be in English
[19:13:49] <fuzzie> D_T_G: it should use string 3805
[19:14:22] <fuzzie> but, um, ok, maybe the logic there is inverted
[19:14:51] <D_T_G> http://i37.tinypic.com/653nkp.jpg -> mixed
[19:15:24] <Avenger> that should be your tlk, but i wonder how
[19:15:28] <fuzzie> this is because there's no damage source, and someone has hard-coded the string
[19:15:35] <Avenger> what?
[19:15:43] <Avenger> we have some non tlk string?
[19:15:45] <Avenger> huh
[19:15:45] <fuzzie> yes
[19:16:07] <Avenger> its true
[19:16:24] <fuzzie> lynx did it :)
[19:16:34] <fuzzie> - core->DisplayConstantStringName(STR_DAMAGE1, 0xffffff, this);
[19:16:54] <fuzzie> ^- so, something needs to retrieve that string, and use it in the snprintf
[19:17:27] <fuzzie> i think lynx just forgot that we cared about non-English bg2, he didn't realise with the "chapter" thing too, it is easy to forget!
[19:18:01] <Avenger> i think the problem is there is no DAMAGEE token in bg1
[19:18:06] <Avenger> nugrud, it is bg1 ?
[19:18:14] <Avenger> oh no, it is bg2
[19:18:28] <D_T_G> first runtime error :)
[19:18:33] <Avenger> then how goes it there
[19:19:20] <fuzzie> i'm confused
[19:19:41] <fuzzie> ok, it is strref 14027 in bg2
[19:19:52] <fuzzie> same in bg1
[19:20:42] <fuzzie> same in iwd
[19:20:48] <fuzzie> same in iwd
[19:20:51] <fuzzie> erm, in iwd2
[19:20:58] <fuzzie> not the same in pst, but that was predictable :)
[19:21:08] <Lightkey> hehe
[19:21:14] <Avenger> 14027 yes
[19:21:21] <Avenger> same in bg1
[19:21:26] <Lightkey> immer ne extrawurst
[19:21:35] <fuzzie> it is the same in bg1/bg2/iwd/how/iwd2
[19:22:36] <fuzzie> so, someone fix it
[19:25:03] <Avenger> that code is too complex for me
[19:25:24] <fuzzie> i think we need a new strref
[19:25:29] <fuzzie> are the strings actually documented anywhere?
[19:25:30] <Avenger> we got 3
[19:25:33] <Avenger> no
[19:25:45] <Avenger> there are 3 string slots reserved for this, i thought it is enough
[19:26:08] <fuzzie> ok, so, nice thing for someone to do: document the string references, or think of a better system
[19:26:16] <Avenger> yep
[19:26:25] <fuzzie> all three strings are already used
[19:27:04] <fuzzie> "Takes <AMOUNT> <TYPE> damage from <DAMAGER> (<RESISTED> damage bonus)", "Takes <AMOUNT> <TYPE> damage from <DAMAGER> (<RESISTED> damage resisted)" and "Takes <AMOUNT> <TYPE> damage from <DAMAGER>"
[19:27:20] <fuzzie> i want mods to be able to use all of these strings, so i don't want to start hacks where we re-use slots
[19:27:40] <fuzzie> but not sure what would be best to do here
[19:27:41] <Avenger> you can use the one with the most tokens
[19:27:49] <Avenger> it doesn't need to be duplicated
[19:27:51] <fuzzie> you can't use any of them, because there is no token
[19:28:00] <Avenger> ?
[19:28:05] <fuzzie> there's no DAMAGER here
[19:29:03] <Avenger> ah i see, those 3 are in iwd?
[19:29:08] <fuzzie> there's other cases this doesn't handle too!
[19:29:41] <Avenger> well then it needs more slots
[19:29:44] <fuzzie> this iwd2 thing produces bad results because it's already trying to reuse strings
[19:29:55] <fuzzie> sure, i just wonder if i can work out how many slots we need :)
[19:30:11] <fuzzie> D_T_G: thanks, anyway, this is obviously a bug
[19:30:54] <Avenger> well, i'm going back to windows :)
[19:30:57] <-- Avenger has left IRC (Quit: bye!)
[19:31:06] <D_T_G> fuzzie: no problem :)
[19:31:34] <D_T_G> you all develope using english only versions of games?
[19:33:11] <fuzzie> i think English is the only IE-game language i understand
[19:35:34] <fuzzie> i know people use gemrb to play in German, but no-one ever tells us about bugs
[19:35:37] <CIA-26> GemRB: 03tom.prince * rfd861504cb81 10gemrb/gemrb/plugins/GUIScript/ (GUIScript.cpp GUIScript.h):
[19:35:37] <CIA-26> GemRB: GUIScript: Windows compatible fix to include.py.
[19:35:37] <CIA-26> GemRB: (plus bugfix by fuzzie)
[19:35:37] <CIA-26> GemRB: Signed-off-by: Alyssa Milburn <fuzzie@fuzzie.org>
[19:35:38] <CIA-26> GemRB: 03fuzzie * r7870ea752b68 10gemrb/gemrb/GUIScripts/include.py: update comment in include.py
[19:48:36] <Lightkey> scusi :p
[19:49:17] <Lightkey> will do once my netbook is not my main computer nemore, compiling problems that hang the whole system are a pain
[19:49:22] <D_T_G> there's no message "your inventory is full" :)
[19:49:35] --> pupnik has joined #GemRb
[19:49:48] <Lightkey> pupnik could do some too
[19:50:10] <fuzzie> D_T_G: i will forget that if you don't put it on the todo or something
[19:50:12] <pupnik> hello sir
[19:51:06] <pupnik> regressions biting you in the butt?
[19:51:10] <Lightkey> pupnik: report German version related bugs
[19:51:54] <pupnik> good idea
[19:52:47] <Lightkey> on second thought, maybe not for Baldur's Gate, needs no encouraging anybody to witness the horrible translation
[19:55:52] <pupnik> heh i brought my BG1 cd out to see if it's the german version, forgetting the notebook has no cdr drive
[19:56:43] <Lightkey> should it not say so on the disc?
[19:57:02] <fuzzie> does it?
[19:57:03] <pupnik> disk is all english
[19:57:26] <fuzzie> i have four different types of BG discs, but i think all english
[19:57:35] <fuzzie> which game is best translated?
[19:58:13] <pupnik> just saw pix of nokia's next maemo/meego phone. i'll have to get it :/
[19:58:18] <Lightkey> no clue but I remember they were quite proud of P:T, since it was such a big task
[19:59:10] <fuzzie> and bg1 is awful?
[19:59:22] <pupnik> ps:t i might have in german
[19:59:28] <Lightkey> famous for its awfulness ;-)
[19:59:37] <Lightkey> really
[20:00:10] <Lightkey> it had someone speaking in saxon, the worst
[20:00:12] <fuzzie> i'm sure someone around here will have bg2 in german
[20:00:33] <fuzzie> but i need to learn german at some point, so i don't want really bad translations :P
[20:00:40] <Lightkey> I think I got enother one in the last jumble sale ;-)
[20:02:13] <fuzzie> you and your jumble sales :)
[20:02:43] <Lightkey> it's the only joy I have left :'-(
[20:02:59] <fuzzie> don't suppose you've ever seen a copy of Tequila and Boom Boom?
[20:03:06] <Lightkey> bwaha
[20:03:09] <fuzzie> i have given up on a legal copy as a lost cause
[20:05:46] <D_T_G> another minor nonenglish bug: gemrb couldn't read my save name "Final-Savemój" instead it displays "Finalsavem" but it loads so very minor
[20:06:13] <fuzzie> hmm, that one would be difficult to fix
[20:07:15] <fuzzie> does it display fine in linux?
[20:07:35] <D_T_G> yes
[20:09:53] <fuzzie> the trouble is that on Windows, they probably just use whatever the one-byte character set is
[20:10:03] <D_T_G> I can't see Amelissan in fina TOB fight
[20:10:04] <D_T_G> [ResourceManager]: Searching for mmelg12.bam...[ERROR]
[20:10:05] <D_T_G> [CharAnimations]: Couldn't create animationfactory: mmelg12 (7f3d)
[20:10:16] <fuzzie> huh
[20:10:24] <fuzzie> we have a whole list of buggy animations
[20:10:30] <fuzzie> but i didn't know Melissan was one of them
[20:10:44] <pupnik> http://www.mobygames.com/game/tequila-boom-boom ?
[20:11:51] <fuzzie> pupnik: yes. it exists because there is a pirate copy around, but otherwise i never see a sign it exists :)
[20:12:29] <fuzzie> (when i am bored i sometimes work on the scummvm engine which could support that game)
[20:15:00] <pupnik> i want to see gemrb on the nokia n9 http://www.fonearena.com/blog/21747/nokia-n9-pics-leaked.html
[20:15:23] <fuzzie> is meego any use yet?
[20:16:20] <Lightkey> pupnik: don't let the dark side win you over
[20:16:57] <Lightkey> fuzzie: well, it is not really new per se?
[20:19:01] <fuzzie> well, the release notes i saw a few days ago have notes like "don't press this button twice, it will crash the whole thing"
[20:19:06] <D_T_G> gemrb recognised and destroyed my armour from underdark wheres bg2main.exe not :(
[20:19:21] <fuzzie> haha.
[20:19:50] <fuzzie> it should only be checked in the first outside area after the underdark, i thought
[20:20:51] <D_T_G> yes, in exe it was like that
[20:21:17] <fuzzie> that is probably a gemrb bug :-)
[20:21:18] <D_T_G> i remember giving it to minsc and leaving him from that party just after leaving underdark
[20:21:36] <Lightkey> hordes of the underdark?
[20:21:41] <D_T_G> gemrb is more RPG here :)
[20:22:19] <fuzzie> your savegame probably had some actor 'attached' to it, trying to get to one of the areas (there are three) which have remove-equipment scripts attached
[20:23:30] <fuzzie> in my data, those are the elven temple at the underdark exit, the first ToB area, the pocket plane and the area outside senadi's hideout
[20:23:33] <fuzzie> that is so mean :o
[20:24:34] <D_T_G> yes it happens in pocket plane
[20:25:56] <fuzzie> well, that is scripted in the original game
[20:26:12] <D_T_G> odd bgmain.exe destroys it too, wondering how i kept that there years ago when making save, hm...
[20:26:44] <fuzzie> there's probably some mod which removes it
[20:27:00] <fuzzie> the fixpack simply does a second check when your party members re-join the party, because they are mean :)
[20:27:59] <D_T_G> I have it in the save befor final-tob-fight with mellisan, 100% i didn't play with anym mods back then
[20:28:05] <D_T_G> 100% sure
[20:28:35] <fuzzie> maybe unpatched ToB?
[20:28:38] <D_T_G> full adamantite armour +5 from draws
[20:30:43] <D_T_G> Jan Jansen has diffrent animation
[20:30:59] <fuzzie> oh?
[20:30:59] <pupnik> hmm i should play that
[20:35:36] <-- deepinthewoods has left IRC (Ping timeout: 260 seconds)
[20:35:59] <D_T_G> http://i37.tinypic.com/20qb6lx.jpg - in gemrb Jan has a coat in exe not
[20:36:28] <D_T_G> besides has 10 less HP
[20:37:12] <fuzzie> different colours, too?
[20:37:39] <fuzzie> or is this just some gamma thing?
[20:38:10] <D_T_G> kde is darkening background a bit
[20:38:32] <fuzzie> that stack number is going to drive me mad
[20:38:57] <D_T_G> in gemrb he has a bigger beard though :D
[20:39:08] <Lightkey> oO
[20:39:26] <fuzzie> maybe some paperdoll issue :)
[20:39:34] --> deepinthewoods has joined #GemRb
[20:39:42] <fuzzie> i don't know how any of that stuff works
[20:40:49] <D_T_G> he looks more like dwarf than gnome i think
[20:42:41] <D_T_G> yep, he looks like korgan :D
[20:42:53] <D_T_G> i'll add that to todo list too
[20:42:55] <fuzzie> thanks
[20:43:03] <fuzzie> i am trying to find my mouse..
[20:44:09] <fuzzie> aha
[20:46:20] <D_T_G> the npcs have different dialogs on leaving too
[20:46:55] <D_T_G> in exe jaheira leaves angry in exe i can still her say to stay
[20:47:10] <D_T_G> in gemrb i meant angry
[20:47:31] <fuzzie> in SoA or ToB?
[20:47:38] <D_T_G> tob
[20:47:40] <fuzzie> we don't support ToB :)
[20:47:44] <D_T_G> ah
[20:47:57] <fuzzie> fixing the dialog would not be so hard, though
[20:48:48] <D_T_G> in gemrb mazzy doesn't have colours applied on paperdoll
[20:50:48] <D_T_G> hm, it worked after changing of windows
[20:51:29] <D_T_G> nope it does not work on mazzy so good, on others it works much better
[20:52:37] <D_T_G> oh i see now, it sometimes works but sometimes not, for everyone :)
[20:57:16] --> tomprince_loki has joined #GemRb
[21:02:08] <D_T_G> me going, bye!
[21:02:14] <-- D_T_G has left IRC (Quit: D_T_G)
[21:03:43] <tomprince_loki> fuzzie: I introduced Logf, just so that we didn't #define printf. Although it might make sense to have a LogCriticalError function that calls abort.
[21:04:12] <tomprince_loki> We could perhaps get rid of Logf, but I wasn't sure the difference between printf and cprintf on windows.
[21:04:15] <fuzzie> well, i would prefer this get a bit of design thought first :)
[21:04:37] <fuzzie> cprintf there is solely because it happens before abort()s
[21:06:03] <fuzzie> imo the sane design there would be to have the first parameter be some kind of flags (bitmask, maybe? including types?)
[21:07:26] <fuzzie> but mostly i'm concerned because just doing s/printf/Logf/ on everything means that there's no review of the prints, just a magic conversion
[21:08:16] <fuzzie> well, and also i'm annoyed by the win32def.h patch because i thought we'd gotten over that whole thing
[21:08:24] <fuzzie> but i realise it's just a small thing and it doesn't actually need doing
[21:08:40] <tomprince_loki> Well, I'm still working on it, and it does need a bunch of cleaning up.
[21:08:58] <fuzzie> but i don't want to go back to this thing where we get no work done because we spend all the time trying to deal with intrusive refactors
[21:09:32] <tomprince_loki> A lot of things just included win32def.h for the logging stuff, and in particular the '#define printf cprintf'
[21:09:34] <fuzzie> while otherwise it seems very non-intrusive and clean, all the 'Fix more Logfs' patches are clearly just an improvement
[21:09:53] <fuzzie> no, a lot of things included win32def.h because it's our global include file with the pragmas etc in it
[21:11:02] <lynxlynxlynx> i'm back
[21:11:04] <fuzzie> the WHITE/RED stuff should ideally go first in the NewLogMessage parameter list, too, in my opinion?
[21:11:15] <lynxlynxlynx> and i don't understand the string problem
[21:11:19] <tomprince_loki> Well, then we should make it such.
[21:11:20] <fuzzie> lynxlynxlynx: it's hardcoded in English
[21:11:29] <fuzzie> tomprince_loki: well, i'm just looking for an opinion :)
[21:11:46] <fuzzie> it's just a bit confusing that the first parameter after the format string isn't the first parameter to the format string
[21:11:57] <tomprince_loki> Yes, the WHITE/RED should. But LogMessage didn't have it there, and I wanted to be consistent.
[21:12:00] <fuzzie> and wondering if this was just the way you sedded it, or if you thought it was better this way
[21:12:10] <tomprince_loki> I plan to change both to have the color first.
[21:12:13] <Lightkey> he's buck \o/
[21:12:27] <fuzzie> if we add flags, maybe we could de-hardcode all the colours?
[21:12:34] <lynxlynxlynx> oh, i see
[21:12:35] <tomprince_loki> And probably get rid of 'LogMessage'.
[21:12:39] <tomprince_loki> That too.
[21:12:57] <fuzzie> i know i'm being demanding
[21:13:07] <fuzzie> but since you're clearly going through this stuff anyway..
[21:13:27] <fuzzie> if you don't want to be bothered then, don't do it :)
[21:13:32] <tomprince_loki> I just didn't want to globably change things, in case some of the calls pass unescaped % to LogMessage.
[21:13:53] <fuzzie> i wouldn't worry about it, we'll catch it easily enough
[21:14:05] <tomprince_loki> No, I posted to get comments on it.
[21:14:39] <fuzzie> i hacked your include.py fix and commited it, btw, i hope that's ok
[21:14:46] <fuzzie> just wasn't sure whether you'd be back
[21:14:50] <tomprince_loki> Yes.
[21:14:53] <tomprince_loki> np.
[21:15:07] <tomprince_loki> I don't know either.
[21:15:34] <tomprince_loki> I may have a bit of time next week, and then I am away for three more, before I am back where I can work on gemrb regualarily.
[21:16:15] <lynxlynxlynx> http://lynxlynx.info/ie/gemrb-0.6.2.tar.gz <-- for testing #2
[21:17:07] <fuzzie> ok. well, i am hoping to do my big refactoring in the next three weeks, and then i'm not sure what i'm doing
[21:18:36] <fuzzie> likely being idle again
[21:24:59] <lynxlynxlynx> ok
[21:37:48] <tomprince_loki> Also, my idea was sort of to incrementally hack to gehter something reasonable, and then work out a reasonable series of commits to get to that point.
[21:38:13] <fuzzie> i worry things don't get committed that way, i guess
[21:45:41] <fuzzie> looks like i am stuck battling visual studio this evening, though. (not for gemrb)
[21:46:37] <pupnik> what for?
[21:46:56] <fuzzie> work :)
[21:47:19] <pupnik> last time i did that was debugging an alarm system written mostly in vb
[21:47:59] <lynxlynxlynx> ok, that tarball works great here, so it's final
[21:56:20] <pupnik> can i test that lynxlynxlynx ?>
[21:58:20] <lynxlynxlynx> ynx> http://lynxlynx.info/ie/gemrb-0.6.2.tar.gz <--
[21:59:24] <pupnik> ok new character
[22:07:02] <lynxlynxlynx> tomprince_loki: any luck with the slave?
[22:12:29] <pupnik> ok now for the new build
[22:23:58] <tomprince_loki> I probably wont get a chance today.
[22:24:50] <lynxlynxlynx> i don't know when your today ends, but we don't need it for atleast 10h
[22:25:17] <fuzzie> i can do one in the morning if need be, i imagine
[22:25:21] <pupnik> so far so good
[22:26:02] <lynxlynxlynx> all i'd like is to have the binaries on sourceforge on the 21th, so both the sources and the bins are available simultaneusly
[22:26:17] <lynxlynxlynx> i'm almost done with the pr
[22:26:40] <fuzzie> well, i can hopefully do one in the morning
[22:30:29] <lynxlynxlynx> it's late, i'm starting to write odd stuff
[22:31:04] <lynxlynxlynx> "you are the demon hearts to our development sphere"
[22:31:23] <fuzzie> :)
[22:36:49] <pupnik> a straight 'make as root' on the 0.6.2 seems to leave gemrb not finding stuff as here
[22:37:05] <pupnik> http://pastebin.ca/1917034
[22:37:36] <lynxlynxlynx> you didn't configure it
[22:38:07] <lynxlynxlynx> i tried both my old config and the noinstall one; they work
[22:38:12] --> Avenger has joined #GemRb
[22:38:13] --- ChanServ gives channel operator status to Avenger
[22:38:21] <lynxlynxlynx> the sample one did too, but of course broke when it came to the gamepath
[22:38:37] <Avenger> hmm fuzzie, help, how to use git stash?
[22:38:48] <lynxlynxlynx> git stash # to save
[22:38:54] <lynxlynxlynx> git stash pop # to load
[22:39:00] <lynxlynxlynx> load and delete
[22:39:07] <lynxlynxlynx> git stash apply to just load the last stash
[22:39:07] <Avenger> i get fatal: git-write-tree: error building trees
[22:39:09] <Avenger> Cannot save the current index state
[22:39:18] <lynxlynxlynx> huh
[22:39:22] <lynxlynxlynx> git status
[22:39:42] <Avenger> gemrb/plugins/GUIScript/GUIScript.cpp: needs merge
[22:40:05] <lynxlynxlynx> aha
[22:40:23] <lynxlynxlynx> you'll have to resolve that, there's a conflict
[22:40:42] <lynxlynxlynx> there should be the standard >>>>>>>>>> <<<<<<<<< stuff in the file
[22:42:55] <CIA-26> GemRB: 03avenger_teambg * r84a870a01738 10gemrb/gemrb/ (11 files in 9 dirs):
[22:42:55] <CIA-26> GemRB: properly implemented special race based action buttons
[22:42:55] <CIA-26> GemRB: wizard eye in bg2 depends on it
[22:42:55] <CIA-26> GemRB: also added the summon disable effect (this may need more work)
[22:42:58] <Avenger> oops
[22:42:59] <CIA-26> GemRB: 03avenger_teambg * rfe03b514bdfd 10gemrb/gemrb/ (3 files in 2 dirs):
[22:42:59] <CIA-26> GemRB: Merge branch 'master' of ssh://avenger_teambg@gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[22:42:59] <CIA-26> GemRB: Conflicts:
[22:42:59] <CIA-26> GemRB: gemrb/plugins/GUIScript/GUIScript.cpp
[22:43:03] <CIA-26> GemRB: 03avenger_teambg * r2e1f2e2f3dbf 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: more changes
[22:43:10] <Avenger> yeah, and i just pushed it into the repo
[22:43:43] <Avenger> i don't even know which one should be there
[22:43:46] <fuzzie> did you?
[22:43:56] <fuzzie> oh, you did
[22:44:00] <Avenger> int len = fs.Remains();
[22:44:13] <Avenger> sorry :>
[22:44:29] <Avenger> so the second is the right one?
[22:45:45] <fuzzie> let me poke at it
[22:46:19] <lynxlynxlynx> cool re summoning
[22:46:29] <lynxlynxlynx> the conflict doesn't look that bad
[22:46:30] <fuzzie> let me try and do this nicely
[22:47:17] <lynxlynxlynx> Avenger: will we have to add the proper action buttons to the 2da for all the possible summons or is wizard eye extra special?
[22:47:39] <Avenger> the other summons should have the default
[22:47:46] <Avenger> the engine handles the wizard eye specially
[22:47:55] <Avenger> the others are simply using the default
[22:48:30] <Avenger> it is class based, btw
[22:49:01] <Avenger> see you later!
[22:49:04] <-- Avenger has left IRC (Quit: bye!)
[22:50:17] <lynxlynxlynx> cool
[22:50:53] <lynxlynxlynx> fuzzie: can't you just revert the merge commit?
[22:50:57] <fuzzie> no
[22:51:04] <fuzzie> well, i could, but that reverts Avenger's branch
[22:51:22] <lynxlynxlynx> oh
[22:51:38] <fuzzie> i am told "revert the whole thing and push it again"
[22:51:45] <fuzzie> but i don't think Avenger would appreciate that
[22:51:51] <fuzzie> so i will manually revert
[22:52:28] <fuzzie> and maybe we can put 'git pull --rebase' in big letters somewhere.
[22:53:21] <lynxlynxlynx> patch -R should help
[22:53:59] <lynxlynxlynx> we currently don't have any special git workflow doc, so it more like something you need to teach avenger
[22:54:41] <lynxlynxlynx> it can be made default too
[22:54:52] <lynxlynxlynx> set configuration branch.<name>.rebase to true
[22:54:52] <fuzzie> and i'm a bit grumpy because Avenger just committed a broken hack
[22:56:31] <fuzzie> setting up the window controls looks good, but just adds another hack to the C++ side
[22:57:20] <lynxlynxlynx> tomprince_loki made a binary && good night
[22:57:38] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:57:59] <CIA-26> GemRB: 03fuzzie * r9e91c15a0e07 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: remove Avenger's merge conflict
[23:30:11] <tomprince_loki> It looks like PyFile_FromString/PyFile_AsFile would work to get a FILE* that can be passed to PyRun_SimpleFileEx on windows.
[23:31:14] <fuzzie> are you just wanting to fix the filename?
[23:31:24] <fuzzie> because supposedly you can do that with the high level api
[23:32:04] <fuzzie> oh, i see
[23:32:37] <fuzzie> but we don't hold the GIL and we don't have python 2.6
[23:32:45] <fuzzie> any idea how safe it is?
[23:33:30] <fuzzie> oh, i suppose we can presumably just take the GIL
[23:34:28] <tomprince_loki> I think we by default have the GIL, and it is only released if we explicitly ask for it to be.
[23:35:41] <tomprince_loki> Py_CompileString/PyEval_EvalCode could probably handle it, I think passing pMainDic for locals and globals to EvalCode.
[23:36:01] <fuzzie> well, if you really want to fix it, i guess you get to pick :)
[23:38:49] <tomprince_loki> I don't really care at this point.
[23:39:45] <fuzzie> presumably one of us is going to take a long refactoring stroll through the whole file, sometime
[23:39:45] <tomprince_loki> Perhaps when a use case other than imports for the console comes along, or somebody wants to add support for multiple or user-editable files.
[23:40:18] <fuzzie> but it has gone a bit further down my todo list
[23:40:27] <fuzzie> still haven't found a sane image API
[23:41:34] <fuzzie> it's a bit frustrating really
[23:41:57] <fuzzie> it's clear Bioware just hard-coded the whole lot
[23:42:18] <fuzzie> like, MOS files had *this* code for drawing in software, and *this* code for drawing in opengl
[23:42:35] <tomprince_loki> What is the issue?
[23:42:45] <fuzzie> memory issues, basically
[23:43:18] <fuzzie> both in video memory (so you want to limit what you hand to the video driver) and in main memory (you don't want to load huge images if only a small section is going to be rendered)
[23:44:07] <fuzzie> the world map is a good example of the latter - the underlying MOS file is in paletted tiles, and we not only load the whole thing, we convert to 32bpp, a 4x hit
[23:45:12] <fuzzie> but i don't want to just hardcode the world map to render MOS files tile-by-tile, because modders with PCs are going to want to just plonk a high-res PNG file in there
[23:46:40] <fuzzie> (not that this specific example matters much, because it's 5mb, and you get to dump all the in-game tiles etc while doing it, if we must)
[23:54:18] <fuzzie> i mean, i should clarify: i don't think MOS files matter much, even
[23:54:35] <fuzzie> it just all adds up, and not sure how to deal with it nicely :)
[23:54:37] <fuzzie> and now i am off to bed
[23:55:27] <tomprince_loki> night