#gemrb@irc.freenode.net logs for 12 Jun 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:05:11] --> cubathy has joined #GemRb
[00:20:45] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[00:28:05] <-- budlust has left #GemRb
[00:51:24] <-- cubathy has left IRC (Ping timeout: 272 seconds)
[03:30:47] <-- Guest40195 has left IRC (*.net *.split)
[03:30:47] <-- Gekz_ has left IRC (*.net *.split)
[03:39:15] --> Guest40195 has joined #GemRb
[03:39:15] --> Gekz_ has joined #GemRb
[04:33:23] --> pupnik has joined #GemRb
[06:09:43] * pupnik makes coffee and tea for the room
[06:13:17] <Guest40195> Thank you.
[06:13:36] --- Guest40195 is now known as tomprince_loki
[06:16:55] <pupnik> pretty anxious to get my pandora and do some gemrb testing
[06:17:27] <pupnik> fried the n900 prototype :(
[06:20:38] <tomprince_loki> :(
[06:25:24] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[06:30:03] <pupnik> ok one more beer for breakfast and ill get to work in a half hour
[06:58:05] <pupnik> go wikileaks
[07:56:16] --> Gekz has joined #GemRb
[08:26:00] --> lynxlynxlynx has joined #GemRb
[08:26:00] --- ChanServ gives channel operator status to lynxlynxlynx
[10:02:13] <-- pupnik has left IRC (Ping timeout: 276 seconds)
[10:32:48] --> raevol has joined #GemRb
[10:39:59] <-- raevol has left IRC (Quit: Leaving.)
[10:47:04] --> Maighstir_laptop has joined #GemRb
[10:48:51] --> pupnik has joined #GemRb
[11:08:20] <lynxlynxlynx> something broke the pst guirec window
[11:09:07] <lynxlynxlynx> not sure if it was the rename, but it used to work a few months ago
[11:09:12] <lynxlynxlynx> ss = GemRB.LoadSymbol ("ALIGN")
[11:09:13] <lynxlynxlynx> - sym = ss.GetValue (align)
[11:09:43] <lynxlynxlynx> ss is an int, since the function returns an index, so i'm pretty sure the guiclass shortcut is bad
[11:10:07] <lynxlynxlynx> BUT, it doesn't work by directly calling GemRB.Symbol_GetValue either
[11:10:34] <lynxlynxlynx> as if the function wasn't registered in the module
[11:10:41] <fuzzie> it isn't, is it?
[11:10:53] <fuzzie> you have to go via the object now
[11:11:03] <lynxlynxlynx> METHOD(Symbol_GetValue, METH_VARARGS),
[11:11:14] <fuzzie> yes, but that's not in the GemRB module exports
[11:11:31] <lynxlynxlynx> oh, GemRBInternalMethods
[11:11:56] <lynxlynxlynx> so the "object" needs to be fixed
[11:13:14] <fuzzie> just wrap the LoadSymbol in GSymbol, maybe?
[11:16:17] <lynxlynxlynx> that works :)
[11:18:31] <fuzzie> no time to look at a proper fix
[12:00:15] --> barra_library has joined #GemRb
[12:11:22] <-- Maighstir_laptop has left #GemRb
[13:00:04] <CIA-23> GemRB: 03tom.prince * rd29d46230a77 10gemrb/gemrb/plugins/GUIScript/ (GUIScript.cpp GUIScript.h):
[13:00:04] <CIA-23> GemRB: GUIScript: Make LoadSymbol return an object.
[13:00:04] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[13:01:50] <fuzzie> thanks
[13:10:55] <CIA-23> GemRB: 03tom.prince * r9393715b1dfa 10gemrb/gemrb/ (80 files in 8 dirs):
[13:10:56] <CIA-23> GemRB: GUIScript: Rename LoadTableObject => LoadTable.
[13:10:56] <CIA-23> GemRB: Use the new version of GUIScript::ConstructObject for this.
[13:10:56] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[13:13:04] <fuzzie> hm
[13:13:11] <fuzzie> you're kinda merging commits into blobs again
[13:14:28] <fuzzie> i guess difficult to deal with that
[13:14:42] <tomprince> How is that last one a blob?
[13:15:04] <tomprince> It is s/LoadTableObject/LoadTable/
[13:15:18] <fuzzie> except it isn't
[13:16:15] <fuzzie> because if it was, it would only have a single line of change in the GUIScript.cpp
[13:17:46] <fuzzie> as it is, you just removed LoadTableObject, and i have to look at the previous commit to find where ConstructObject was added without notice in the commit message
[13:18:15] <fuzzie> and so we have an error check silently removed
[13:19:32] <tomprince> No, the check is in ConstructObject.
[13:20:08] <fuzzie> where?
[13:20:21] <fuzzie> all i see is fprintfs
[13:26:46] <CIA-23> GemRB: 03tom.prince * rfed8d0ccdaa5 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:
[13:26:46] <CIA-23> GemRB: GUIScript: Report errors to python, from ConstructObject.
[13:26:46] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[13:27:34] <lynxlynxlynx> http://pastebin.com/iKq1qfDR <-- how does this look?
[13:27:36] --> Gekz_ has joined #GemRb
[13:27:52] <-- Gekz has left IRC (Read error: Connection reset by peer)
[13:28:27] <lynxlynxlynx> i know i don't set it anywhere yet
[13:29:53] --> mvbarracuda_libr has joined #GemRb
[13:32:03] <CIA-23> GemRB: 03tom.prince * r13979917a544 10gemrb/gemrb/ (163 files in 8 dirs):
[13:32:04] <CIA-23> GemRB: GUIScript: Rename LoadWindowObject => LoadWindow.
[13:32:04] <CIA-23> GemRB: Use the new version of GUIScript::ConstructObject for this.
[13:32:04] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[13:33:07] <-- barra_library has left IRC (Ping timeout: 260 seconds)
[13:33:54] <tomprince> I agree that the description of the first commit could have been better, but I don't think the second was a blob. I think it would have required useless contusions to fit it in, without changing the functions as I did.
[13:36:29] --- mvbarracuda_libr is now known as barra_away
[13:42:30] <CIA-23> GemRB: 03lynxlupodian * r35d80cac47eb 10gemrb/gemrb/GUIScripts/pst/GUIREC.py: pst: fake Morte's race to Morte, as shown in the original
[13:54:42] <fuzzie> well, afaict, you could have changed LoadTable first, and then done the rename, but perhaps i miss something obvious; my "i guess difficult to deal with that" was meant to convey that i saw it wasn't trivial, but obviously i am being terrible at communicating today
[13:54:58] <fuzzie> what i really meant is "a commit which says it renames a function shouldn't change behaviour, please"
[13:55:37] <tomprince> Well, I guess I could have changed LoadTable, and mad LoadTableObject a forwarding function to it, and then renamed.
[13:56:10] <fuzzie> but just mentioning what you did in the commit message would also be fine for that
[13:57:31] <fuzzie> i am just going a bit mad with my limited time, trying to understand refactoring commits which are changing behaviour at the same time as renames
[13:57:40] <tomprince> I thought I hadn't, other than the wording of the error message -> I hadn't realized the constructObject only used fprintf.
[13:58:52] <tomprince> But I will try and see if I can make my commits smaller.
[13:59:12] <fuzzie> well, sorry, this is what i mean to say: if you feel you don't want to do contusions, please don't
[14:00:05] <tomprince> You do make a good point about better commit messages.
[14:00:13] <fuzzie> just say "change LoadWindow to return object, replace all uses of LoadWindowObject with it, remove LoadWindowObject as unused" or something which lets me relate the patch to the message?
[14:00:56] <fuzzie> i don't nkow.
[14:01:07] <fuzzie> just, difficult to review. maybe foolish of me to try staying on top of things with no time.
[14:07:39] <fuzzie> other thoughts on review: why don't we pick up CD6 from the config if other code does check CD[5]? the name[2] <= '5' in the previous code does seem to imply that's been there forever, so just wondering
[14:08:52] <fuzzie> oh
[14:09:09] <fuzzie> right, you broke it in 2fef9fb8; fix please? :)
[14:10:15] <fuzzie> although the code is a bit inconsistent in general, the diff for that commit seems to show CD6 not being picked up by the KeyImp
[14:11:33] <fuzzie> i guess because TotSC is always installed and so never on-cd?
[14:13:16] <tomprince> Any reason not to support it?
[14:13:28] <fuzzie> i have no idea
[14:17:00] <fuzzie> looking at c68eccfd: is 'trigger' set to NULL by default somewhere?
[14:17:48] <CIA-23> GemRB: 03tom.prince * r5ecc24a1b4f0 10gemrb/gemrb/core/Interface.cpp:
[14:17:48] <CIA-23> GemRB: Interface: Read CD6 config entry.
[14:17:48] <CIA-23> GemRB: Note: KEYImporter doesn't always look at it.
[14:17:49] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[14:17:53] <tomprince> Untested.
[14:18:10] <fuzzie> i think it is much better to have it in the tree untested, than to have it missing
[14:20:30] <CIA-23> GemRB: 03lynxlupodian * r890d86481d5c 10gemrb/gemrb/GUIScripts/pst/GUIREC.py: pst: prettify GetStatOverview by always using the stats tuple
[14:20:30] <fuzzie> and it seems, well, obvious :) i think trigger is not set to NULL by default anywhere
[14:26:05] <CIA-23> GemRB: 03tom.prince * r06879cf65d47 10gemrb/gemrb/plugins/KEYImporter/KEYImporter.cpp:
[14:26:05] <CIA-23> GemRB: KEYImporter: Honor GameOnCD for CD 6.
[14:26:05] <CIA-23> GemRB: This is untested, but matches the IESDP description.
[14:26:05] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[14:44:22] --> maighstir|phone has joined #GemRb
[14:45:56] <-- xrogaan has left #GemRb
[14:48:36] <-- maighstir|phone has left IRC (Ping timeout: 252 seconds)
[15:13:25] --> Avenger has joined #GemRb
[15:13:29] --- ChanServ gives channel operator status to Avenger
[15:13:51] <Avenger> huh, the fake morte name is a "Really Bad Hack" (tm)
[15:14:19] <Avenger> can't you at least hack the strref ?
[15:18:33] --> Gekz has joined #GemRb
[15:19:07] <Avenger> actually, i can fix it totally
[15:20:27] <Avenger> it should be correct with IE_SPECIES, at least for Morte
[15:21:24] <lynxlynxlynx> he has 0 too
[15:22:03] <Avenger> yes, that's odd
[15:22:13] <Avenger> the cre file has 0x2d
[15:22:49] <tomprince> Avenger: I was thinking of moving the '#pragma warning' lines to a separate header file, and including that with '/FI' on the command line.
[15:23:20] <tomprince> That would mean that the warnings are disabled everywhere, without having to litter all the files with an include of win32defs just for msvc6.
[15:23:55] <Avenger> ok
[15:24:17] <Avenger> that means i need to add an extra header via the project?
[15:27:12] --> maighstir|phone has joined #GemRb
[15:27:18] <tomprince> Add an extra header, and add '/FI to the compile lines.
[15:27:31] <lynxlynxlynx> Avenger: looks like we should just print the species there instead of the race
[15:27:37] <lynxlynxlynx> in all cases
[15:27:47] <Avenger> yes
[15:27:53] <Avenger> but there is a bug in the reader
[15:27:57] <lynxlynxlynx> yep
[15:29:40] <Avenger> i don't see the bug, but it causes the species field to become 0?
[15:30:24] <-- maighstir|phone has left IRC (Remote host closed the connection)
[15:30:26] <lynxlynxlynx> are you sure the offset it correct?
[15:31:44] <lynxlynxlynx> doesn't appear so, tmpByte is always 0 in my save
[15:32:11] <Avenger> when i read it in dltcep, i see values there O_o
[15:32:20] <lynxlynxlynx> me too
[15:32:24] <Avenger> gotta see with ielister
[15:34:20] <Avenger> damn, ielister cannot even show them correctly
[15:34:27] <-- Avenger has left IRC (Quit: bye!)
[15:34:56] <lynxlynxlynx> nothing with 2d in the stream after the species
[15:39:23] <lynxlynxlynx> nowhere in the stream, so i guess some field width is bad
[15:40:23] <fuzzie> tomprince: the #pragmas are msvc6-specific?
[15:40:31] <tomprince> Yes.
[15:40:41] <fuzzie> you tried msvc10?
[15:40:59] <tomprince> No, sorry msvc specific.
[15:41:16] <tomprince> Although I don't know how many of them are an issue on msvc10
[15:41:28] <tomprince> I know one is msvc6 specific.
[15:41:52] <fuzzie> it just seems a pretty odd thing to do
[15:42:09] <fuzzie> i mean, if you move the msvc-specific stuff to a header like that, why not the gcc-specific stuff?
[15:42:49] <tomprince> Well, what do we have that is gcc specific?
[15:42:58] <fuzzie> the visibility stuff, for example
[15:43:42] <tomprince> Well, that is in exports.h, and is not gcc specific.
[15:44:07] <tomprince> The reason for doing it this way, is that msvc6 won't let you disable specific warning s on the command line.
[15:44:14] <fuzzie> well, gcc and things trying to be compatible with gcc, much like the pragmas work with things trying to be compatible with msvc.
[15:44:23] --> Avenger has joined #GemRb
[15:44:25] --- ChanServ gives channel operator status to Avenger
[15:44:32] <Avenger> if i start a new game, the species field is ok
[15:45:38] <tomprince> My thought is, that for every other compiler specific thing, we want it for a particular purpose, so you include the header that provides that functionality.
[15:46:15] <tomprince> But I don't want a diable_msvc6_warnings.h, and I don't want to include win32def.h just for that.
[15:46:30] <fuzzie> well
[15:46:52] <CIA-23> GemRB: 03avenger_teambg * r22926bf44887 10gemrb/gemrb/GUIScripts/pst/GUIREC.py: fixed race --> species
[15:46:57] <fuzzie> i don't see why you'd require some compiler flag, over just having some standard header file, given you're going to need e.g. exports.h in pretty much every place anyway
[15:48:16] <tomprince> Well, I don't know if we have a header file that is everywhere.
[15:48:19] <Avenger> i don't see why we can't have a commonly included header
[15:51:25] <tomprince> Well, it just seems to me like having that would tend to encourange, or at least not discourage having tightly coupled code. That is, if you include everything everywhere, you would tend to just call everything from everywhere. Or something like that.
[15:52:23] <lynxlynxlynx> Avenger: yep, i can confirm; it also saves well
[15:52:56] <fuzzie> sure, but no-one is discussing including everything everywhere
[15:53:01] <Avenger> feel free to rearrange it, but i think it is common practice to have at least one header included by others
[15:53:18] <fuzzie> just having a header file which includes the standard settings for the program, such as the stuff in exports.h
[15:53:31] <Avenger> i agree
[15:53:45] <fuzzie> and it just seems like if you're going to go through contortions for the pragmas, you should do the same thing for the export macros.
[15:54:55] <Avenger> lynx: can you start an original pst game right now?
[15:55:03] <lynxlynxlynx> yes
[15:55:08] <tomprince> I would be fine with that.
[15:55:13] <lynxlynxlynx> err, no
[15:55:34] <Avenger> oops, ok, then i gotta reboot, i don't know if i got ANY pure original savegames
[15:55:42] <lynxlynxlynx> i tried today and with a newer wine, but i get the same crap
[15:55:49] <tomprince> I guess my motivation was that I tried to move the options to the command line, but msvc6 doesn't allow that.
[15:55:52] <lynxlynxlynx> i have none either
[15:56:14] <lynxlynxlynx> but maybe there up on ed's site
[15:56:14] <Avenger> fuzzie? you got any 100% original pst saves with Morte in it?
[15:56:19] <fuzzie> the intention of the pragmas in newer msvc versions is that they're for sabotaging warnings which are 'bad warnings'.
[15:56:31] <fuzzie> Avenger: the ones on ed's site should work, i think
[15:56:40] <fuzzie> you can load them in original pst and they show the right thing
[15:56:44] <lynxlynxlynx> http://www.eowyn.cz/gemrb/pst/saves/
[15:57:07] <Avenger> ok, will see one
[15:57:38] <fuzzie> so you have the command-line flags for warning levels, which belong to the project, and then the pragmas, which belong to the code
[15:58:02] <fuzzie> and if we're not looking at the latter here, then it might be a good idea to put the warnings up somewhere so they can be fixed
[15:58:03] <tomprince> Yes, same in msvc6, they are like -Wno-* for gcc, and post-6 versions of msvc have commandline options as well.
[15:58:29] <Avenger> weird, i cannot unpack the save
[15:58:41] <fuzzie> otherwise it seems better to have them in the header.
[15:58:53] <lynxlynxlynx> it's 9m, are you sure it's downloaded yet?
[15:59:03] <Avenger> the small 50k save (5)
[15:59:31] <lynxlynxlynx> what does file *zip # tell you?
[15:59:34] <lynxlynxlynx> the size is fishy
[15:59:56] <Avenger> yep, i picked the smallest, and of course it is corrupt
[16:00:00] <Avenger> got a bigger
[16:00:01] <lynxlynxlynx> the first zip works
[16:00:05] <tomprince> http://hermes.hocat.ca:4010/builders/msvc%2B%2B6/builds/11/steps/compile/logs/warnings
[16:00:43] <Avenger> these got 0 as species :(
[16:01:41] <Avenger> i bet these are not original
[16:01:58] <lynxlynxlynx> ;)
[16:01:59] <Avenger> hmm though they are from 2002
[16:03:06] <fuzzie> well, they're not from gemrb
[16:03:12] <Avenger> i'm getting mad :(
[16:03:19] <fuzzie> i'm not sure what you mean by original, though
[16:03:47] <Avenger> well, i guess original means original PST IE
[16:04:03] <Avenger> as in never touched by gemrb
[16:04:10] <fuzzie> well, the savegames do the right thing in the original engine+data
[16:04:32] <Avenger> then the species field is not where i expect
[16:04:46] <tomprince> Or the engine has a hack?
[16:06:43] <Avenger> hmm
[16:07:03] <Avenger> yes, actually, MY engine got code level fixpack
[16:07:18] <Avenger> maybe that's causing the problems
[16:07:46] <Avenger> but then, the original engine doesn't use the species field?
[16:10:33] <Avenger> at least now i see why dltcep shows mostly the 'correct' value for species, LOL, it does this: if (!species) species=race;
[16:11:53] <lynxlynxlynx> that's sensible even from a biological point of view :)
[16:11:56] <Avenger> so, most likely this species field is an engine hack in my 'original' game engine (as in non-gemrb)
[16:12:07] <tomprince> fuzzie: I know why I differentiate between the pragmas and the visibility stuff. The pragmas don't create any symbols, where as the export stuff gives macros GEM_EXPORT and GEM_EXPORT_DLL.
[16:12:35] <Avenger> so, we need to find out how the truly original engine works, definitely not by this field
[16:15:35] <tomprince> http://hermes.hocat.ca:4010/builders/msvc%2B%2B6/builds/10/steps/git/logs/patch
[16:17:59] <fuzzie> i think my real question is
[16:18:20] <fuzzie> does gcc really not support warning disabling via pragmas?
[16:19:17] <tomprince> It does support it.
[16:19:26] <lynxlynxlynx> http://pastebin.com/Ufp6Bsvw <-- updated turnedby
[16:20:29] <fuzzie> lynxlynxlynx: looks ok
[16:20:54] <fuzzie> tomprince: but, well, i think moving warnings to the command line is a misfeature, i guess.
[16:21:10] <fuzzie> but whatever.
[16:21:53] <fuzzie> more curious about how to make gcc disable warnings via pragmas, i can't find docs.
[16:22:28] <Avenger> bye!
[16:22:29] <-- Avenger has left IRC (Quit: bye!)
[16:22:41] <tomprince> info gcc C\ Extensions Pragmas Diagnostic\ Pragmas
[16:23:32] <fuzzie> hm
[16:23:37] <fuzzie> not really useful :(
[16:24:32] <fuzzie> was hoping for something comparable with msvc's
[16:24:42] <CIA-23> GemRB: 03lynxlupodian * r647e6136e9c8 10gemrb/gemrb/ (6 files in 2 dirs): implemented the TurnedBy trigger
[16:25:28] <tomprince> What does msvc give you.
[16:25:50] <fuzzie> the idea is, you only disable warnings where the warnings are bad.
[16:26:03] <fuzzie> so if you have a line where msvc gives you a bad warning, you turn off the warning before that line, and turn it back on after it.
[16:26:26] <lynxlynxlynx> isn't that done through special comments?
[16:26:46] <lynxlynxlynx> i'm not sure where i saw it
[16:26:49] <fuzzie> well, the gcc documentation seems to imply it's not supported at all
[16:26:58] <fuzzie> "the only supported location for them is before any data or functions are defined"
[16:27:15] <lynxlynxlynx> it was probably for coverity or some other analyser
[16:28:07] <tomprince> Well, there is some support via attributes -> things like used vs. unused. Although that may be the only one.
[16:28:10] <fuzzie> i was just wondering why the gcc command-line warning options were so miserable
[16:29:11] <fuzzie> but i guess their codebase just doesn't handle warnings very well
[16:29:56] <fuzzie> nice to discover that you can do -Wno-error=blah though
[16:31:59] <fuzzie> LLVM, on the other hand, seems to get it right
[16:32:49] <fuzzie> well, clang, i mean
[16:33:14] <tomprince> Yes.
[16:35:41] <tomprince> I can see the benefit of disabling a specific instance of a warning in code.
[16:36:23] <tomprince> But for global settings, I don't. Particularly for braindead ones like 4786.
[16:36:25] <fuzzie> well, we *don't*, at the moment
[16:37:01] <fuzzie> and, yes, 4786 is dumb
[16:37:21] <tomprince> We don't?
[16:37:25] <fuzzie> i was just wondering if there was a better solution to bad warnings than just removing things from gcc's command line
[16:37:32] <fuzzie> i mean, we don't disable a specific instance of any warnings in code, afaik
[16:38:04] <fuzzie> and -Wno-error=blah is at least something, but gcc's warning stuff is clearly just a hack, which is a bit of a pity
[16:38:15] <tomprince> Although I think there is a fair amount of code to avoid http://msdn.microsoft.com/en-us/library/b6801kcy%28VS.80%29.aspx
[16:38:54] <fuzzie> well, i guess you know why that's marked "performance warning"?
[16:40:04] <fuzzie> so i'm pretty sure i wouldn't put that one under 'dumb', especially after having spent so much time looking at disassembled code from people who clearly didn't have that warning enabled
[16:40:44] <tomprince> Is it significant, in terms of runtime?
[16:40:53] <fuzzie> it depends where it is
[16:41:08] <tomprince> And does chaning things to be != 0, or (x == 0)? false : true fix it?
[16:41:12] <fuzzie> obviously as a random check in the middle of some other code, it's almost irrelevant
[16:41:28] <CIA-23> GemRB: 03lynxlupodian * r16ef26d6903a 10gemrb/gemrb/GUIScripts/pst/GUIREC.py: pst: only set the second class level when there is something to set
[16:42:02] <fuzzie> and, no, the != 0 is still slow
[16:42:45] <-- pupnik has left IRC (Ping timeout: 240 seconds)
[16:42:56] <fuzzie> the warning basically means "you are adding a comparison to zero and a flag check here, are you sure that's a good idea?"
[16:43:08] <tomprince> I wasn't saying that it is a dumb warning, but there seems to be places where the code was written to avoid triggering that. Some of the setting of bool in LoadConfig had the ?false:true thing.
[16:43:14] <fuzzie> and it's completely irrelevant outside code which needs to be efficient
[16:44:25] <fuzzie> but having to be explicit about what you're doing is worth the warning reminding you when you're not, when you're working on the performance-sensitive stuff
[16:44:49] <fuzzie> obviously you could just #pragma it off and then #pragma it back on before/after config code, though
[16:46:22] <fuzzie> and obviously in gemrb you could just disable it for most of the codebase and just #pragma it on in a few files
[16:55:57] <tomprince> Well, my goal was to avoid having #pragma show up in random files, when the right header doesn't get included. Like happened in Interface.h. Which is the only reason win32def.h get included there.
[17:00:06] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[17:00:29] <-- Gekz has left IRC (Read error: Connection reset by peer)
[17:06:38] <CIA-23> GemRB: 03avenger_teambg * rb9400d4d217f 10gemrb/gemrb/GUIScripts/pst/GUIREC.py: fixed a runtime bug with Multi class chars (Dakkon) - 'd' means resolved string
[17:06:39] <CIA-23> GemRB: 03avenger_teambg * r5198fd4a6958 10gemrb/gemrb/ (7 files in 3 dirs): Merge branch 'master' of ssh://avenger_teambg@gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[17:07:49] --> Gekz has joined #GemRb
[17:09:02] <CIA-23> GemRB: 03lynxlupodian * rd287b96f8318 10gemrb/gemrb/GUIScripts/pst/ (GUICommonWindows.py GUIINV.py GUIWORLD.py QuitGame.py): pst: minimise includes in GUICommonWindows and fix the exposed bugs
[17:09:06] <lynxlynxlynx> still one loop to go >:(
[17:33:05] <-- barra_away has left IRC (Read error: Connection reset by peer)
[18:07:49] --> pupnik has joined #GemRb
[18:30:00] <-- lynxlynxlynx has left IRC (Ping timeout: 252 seconds)
[19:17:34] --> Maighstir_laptop has joined #GemRb
[19:18:11] --> budlust has joined #GemRb
[19:31:13] --> raevol has joined #GemRb
[21:44:22] <-- budlust has left IRC (Ping timeout: 245 seconds)
[22:10:29] --> cubathy has joined #GemRb
[22:41:19] <-- tomprince_loki has left #GemRb
[22:47:15] <-- cubathy has left IRC (Ping timeout: 240 seconds)
[23:51:54] --> budlust has joined #GemRb
[23:56:53] <-- budlust has left #GemRb