#gemrb@irc.freenode.net logs for 21 Feb 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:16:21] <-- devurandom has left IRC (Changing host)
[00:16:21] --> devurandom has joined #GemRb
[00:22:16] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[00:39:51] <-- raevol has left IRC (Quit: Leaving.)
[05:34:25] <Gekz> ah compilong SDL on Windows is just wonderful
[06:04:55] --> Bo_Thomsen has joined #GemRb
[06:22:21] * Gekz compiles 64-bit GemRB on Windows 7
[06:26:33] <Gekz> I found a bug guys
[06:27:50] <Gekz> mem.cpp: line 51
[06:28:00] <Gekz> change (long) to (intptr_t) and it'll compile on 64bit lol
[06:47:42] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[07:15:31] <Gekz> and I cant seem to get OGGReader to link to vorbisfile
[07:56:43] <Gekz> cd /D/Git/gemrb/bmsys/gemrb/plugins/PNGImporter && /D/Development/MinGW64/bin/g++.exe -DPNGImporter_EXPORTS -DHAVE_CONFIG_H -Werror -Wall -W -Wpointer-arith -Wcast-align -pedantic -Wno-format-y2k -Wno-long-long -fno-strict-aliasing -O2 -g -I/D/Git/gemrb/bmsys -I/D/Git/gemrb/gemrb/includes -I/D/Git/gemrb/gemrb/core -I/D/Development/MinGW64/include/libpng15 -I/D/Development/MinGW64/include -o CMakeFiles/PNGImporter.dir/PNGImporter.obj -c
[07:56:43] <Gekz> /D/Git/gemrb/gemrb/plugins/PNGImporter/PNGImporter.cpp
[07:56:43] <Gekz> cc1plus.exe: warnings being treated as errors
[07:56:43] <Gekz> In file included from d:/Git/gemrb/gemrb/plugins/PNGImporter/PNGImporter.cpp:31:0:
[07:56:43] <Gekz> d:/Development/MinGW64/include/libpng15/png.h:799:76: error: invoking macro PNG_CALLBACK argument 4: empty macro arguments are undefined in ISO C90 and ISO C++98
[08:08:02] --> lynxlynxlynx has joined #GemRb
[08:08:02] <-- lynxlynxlynx has left IRC (Changing host)
[08:08:02] --> lynxlynxlynx has joined #GemRb
[08:08:02] --- ChanServ gives channel operator status to lynxlynxlynx
[08:25:36] <Gekz> intriguing
[08:25:50] <Gekz> my win x64 build crashes at [GUIScript]: Loading Script Start...
[08:26:47] <Gekz> so I'm assuming it didn't link to python properly
[08:30:18] --> edheldil_ has joined #GemRb
[08:33:42] --> lubos has joined #GemRb
[08:41:15] <-- Demitar has left IRC (Quit: Ex-Chat)
[08:44:07] <edheldil> Gekz: in theory, by the time it loads Start script, the Python engine is up and running, as it executes other python statements before that
[08:44:53] <Gekz> how can i test?
[08:44:56] --> adominguez has joined #GemRb
[08:54:23] <Gekz> gdb spits interesting results
[08:54:53] <Gekz> it's a segfault
[08:55:16] <Gekz> d:/Git/gemrb/gemrb/core/Palette.h:76
[08:55:21] <Gekz> assert(refcount > 0);
[09:03:59] <Gekz> GetProcAddress(0x000007FEFEDE0000 [OLEAUT32.DLL], "SysFreeString") called from "MSCTF.DLL" at address 0x000007FEFECC7D9C and returned 0x000007FEFEDE1320.
[09:03:59] <Gekz> Second chance exception 0xC0000026 (Invalid Disposition) occurred in "NTDLL.DLL" at address 0x00000000774F00D8.
[09:03:59] <Gekz> Exited "GEMRB.EXE" (process 0x1144) with code -1073741786 (0xC0000026).
[09:06:48] <Gekz> hmm
[09:06:54] * Gekz remembers what might have done this
[09:06:55] <Gekz> haha
[09:10:21] <edheldil> yes? Some empty definition?
[09:12:57] <Gekz> nope
[09:12:58] <Gekz> wasnt that
[09:13:04] <Gekz> I had to change a line in BIKPlayer before
[09:13:15] <Gekz> casting a void* to long is a no-no on 64bit
[09:13:21] <Gekz> so I changed it to intptr_t
[09:15:32] <fuzzie> that should work too, i think
[09:15:49] <Gekz> it should work
[09:16:10] <Gekz> has GemRB been tried on any other 64bit platforms?
[09:16:16] <fuzzie> sure, it's fine on Linux
[09:16:23] <Gekz> ok
[09:16:45] <Gekz> I love the errors that libpng 1.5 spits when pedantic is on
[09:16:55] <fuzzie> and, well, the code in question is chopping off almost every bit of your pointer :)
[09:16:56] <Gekz> d:/Development/MinGW64/include/libpng15/png.h:2081:30: error: invoking macro PNG_FUNCTION argument 4: empty macro arguments are undefined in ISO C90 and ISO C++98
[09:17:17] <fuzzie> phft, build using a modern standard :P
[09:17:31] <Gekz> cmake isn't enabling -c99
[09:17:36] <Gekz> not my fault
[09:18:03] <Gekz> fuzzie: when I run gemrb in gdb, it ssays its segfaulting, pointing out line 76 of Pallete.h
[09:18:07] <Gekz> asser(refcount >0 )
[09:18:08] <Gekz> lol
[09:18:11] <Gekz> assert*
[09:18:12] <fuzzie> you need to know the caller
[09:18:26] <Gekz> I need more debug symbols
[09:18:29] <Gekz> >_>
[09:18:29] <fuzzie> also, to know that you're not trying to use official mingw 4.4+
[09:18:57] <Gekz> I'm using tdm-gcc 4.5.1
[09:19:06] <Gekz> I've checked all DLLs and EXEs, they're all 64bit
[09:19:08] <fuzzie> that should be fine
[09:19:21] <fuzzie> i mean, tdm-gcc
[09:20:02] <fuzzie> but you should get debug symbols by default
[09:20:13] <Gekz> bah
[09:20:18] <Gekz> why doesnt SDL have a test suite
[09:20:27] <Gekz> oh, it does.
[09:21:28] <Gekz> SDL works.
[09:22:18] <Gekz> intriguing failure mr libvorbis
[09:25:03] <Gekz> fuzzie: so how would one debug this?
[09:26:34] <fuzzie> find debug symbols, panic?
[09:26:40] <fuzzie> it's Windows, you're doomed.
[09:27:31] <Gekz> :<
[09:27:39] <Gekz> good support, devs. haha
[09:34:01] <Gekz> I had to patch SDL to work on w64 too
[09:34:06] <Gekz> but the test apps all worked >_>
[09:36:26] <Gekz> ok
[09:36:30] <Gekz> trying to rebuild with Debug symbols
[09:36:33] <Gekz> let's see what happens
[09:38:25] <Gekz> lol, an error in a new place
[09:38:26] <Gekz> what
[09:38:33] <Gekz> Holder.h 84
[09:38:42] <Gekz> OPERATOR_BOOL(Holder<T>,T,ptr)
[09:39:51] <Gekz> fuzzie: is there a debug option in the cmake lists?
[09:48:10] <fuzzie> yes, but it's default, i think. your problem is likely some uninited object, which is why i suggested you look at the backtrace.
[09:48:44] <-- |Cable| has left IRC (Remote host closed the connection)
[09:58:32] <Gekz> fuzzie: backtrace goes back to python ll
[09:58:52] <fuzzie> oh, then maybe you just have a broken python
[10:00:27] <Gekz> I'll try linking it to python2.6
[10:00:40] <fuzzie> what were you linking it to?
[10:00:44] <Gekz> 2.7
[10:04:00] <Gekz> actually, yes.
[10:04:07] <Gekz> this reminds me of an issue I was having with Python linkage in the first place
[10:04:09] <Gekz> CMakeFiles/GUIScript.dir/objects.a(GUIScript.obj):d:/Git/gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:10282: undefined reference to `__imp_Py_InitModule4'
[10:04:25] <Gekz> turns out InitModule4 is a protection against running 32bit scripts in a 64bit environment
[10:04:27] <Gekz> or some crap
[10:05:41] <Gekz> #if SIZEOF_SIZE_T != SIZEOF_INT
[10:05:41] <Gekz> modules cannot get loaded into a 2.5 interpreter */
[10:05:41] <Gekz> #define Py_InitModule4 Py_InitModule4_64
[10:05:41] <Gekz> #endif
[10:10:31] <Gekz> PyObject* pGemRB = Py_InitModule3( "GemRB", GemRBMethods, GemRB__doc );
[10:10:36] <Gekz> that'd be the line causing all the havocx
[10:10:37] <Gekz> xD
[10:14:38] <Gekz> oh
[10:14:42] <Gekz> I think I might have worked it out,
[10:16:36] <fuzzie> do tell
[10:16:53] <Gekz> that error appears if you link debug and non-debug libs together
[10:17:03] <Gekz> according to something I just saw on stackoverflow
[10:17:05] <Gekz> testing that theory now
[10:17:10] <Gekz> I dont think that's right though
[10:19:13] <Gekz> undefined reference to __imp_Py_InitModule4TraceRefs in google gives 0 results
[10:19:16] <Gekz> I think I'm fucked haha
[10:38:49] --> Maighstir has joined #GemRb
[10:41:16] <Gekz> fuzzie: I fuckign worked out what the issue is
[10:41:21] <Gekz> and it's the compile being derpy
[10:41:45] <fuzzie> :P
[10:41:48] <Gekz> well, I think it is
[10:41:49] <Gekz> :<
[10:41:50] <Gekz> it's trolling me
[10:41:53] <Gekz> and I can never be sure
[10:42:04] <Gekz> I wrotea simple c app to test the sizeof size_t and int
[10:42:11] <Gekz> 64bit mode: size_t: 8, int: 4
[10:42:19] <Gekz> 32bit mode, they're equal
[10:42:26] <Gekz> so why does the header file of python never notice they're different?
[10:45:14] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[11:05:58] <Gekz> this is stupid
[11:05:59] <Gekz> :<
[13:57:20] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[14:22:54] --> lynxlynxlynx has joined #GemRb
[14:22:55] <-- lynxlynxlynx has left IRC (Changing host)
[14:22:55] --> lynxlynxlynx has joined #GemRb
[14:22:55] --- ChanServ gives channel operator status to lynxlynxlynx
[14:39:25] <-- Maighstir has left IRC (Read error: Connection reset by peer)
[14:39:50] --> Maighstir has joined #GemRb
[14:53:21] --> Demitar has joined #GemRb
[16:48:06] <-- lubos has left IRC (Quit: Leaving.)
[17:00:14] <-- Demitar has left IRC (Quit: Ex-Chat)
[17:20:15] --> Demitar has joined #GemRb
[17:33:28] --> Bo_Thomsen has joined #GemRb
[18:30:17] --> |Cable| has joined #GemRb
[18:38:35] <-- adominguez has left IRC (Quit: Saliendo)
[18:41:30] --> Avenger has joined #GemRb
[18:41:30] --- ChanServ gives channel operator status to Avenger
[20:12:12] <lynxlynxlynx> i see why the magic missile ignores resistance
[20:12:26] <lynxlynxlynx> the sourceflags are empty, so the selective mr check fails
[20:12:57] <lynxlynxlynx> so it's like the roll was bad enough
[20:18:07] <lynxlynxlynx> need to try with a less ancient save, maybe it's corrupt
[20:20:53] --> barra_home has joined #GemRb
[20:22:24] --> edheldil_ has joined #GemRb
[20:31:57] <CIA-29> GemRB: 03lynxlupodian * r1d5e91538d46 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:
[20:31:57] <CIA-29> GemRB: GemRB_ApplySpell doesn't really need a map, fixes chargen for anything with
[20:31:57] <CIA-29> GemRB: class abilities
[20:35:41] <lynxlynxlynx> yeah, that mm thing was a dud
[20:47:49] <lynxlynxlynx> Avenger: here?
[20:47:54] <Avenger> yes
[20:48:54] <Avenger> you fixed something with MM ?
[20:49:13] <lynxlynxlynx> while i was testing mm, i saw a bunch of "resisted effect" messages, so i went to check it out
[20:49:32] <lynxlynxlynx> it was all from one spell, so we definitely don't do iwd2-like breaking
[20:49:53] <lynxlynxlynx> we return FX_NOT_APPLIED instead of FX_ABORT in many resistance checks
[20:50:13] <Avenger> that is needed only for 2 effects, i think
[20:50:29] <Avenger> resist source and resist source with message
[20:50:36] <Avenger> or whatever is their names
[20:50:42] <lynxlynxlynx> at least magic resistance should be done on the whole spell
[20:51:17] <Avenger> hmm, you are right, but that has nothing to do with fx_abort?
[20:51:17] <lynxlynxlynx> i'm sure a lot of spells need it also for the saving throws
[20:51:27] <-- tomprince has left IRC (Ping timeout: 276 seconds)
[20:51:34] <Avenger> magic resistance needs to be spell level, i guess?
[20:51:40] <lynxlynxlynx> well, isn't that the way we break it now?
[20:51:51] <lynxlynxlynx> yes
[20:52:11] <Avenger> fx_abort is to support a spell aborting itself
[20:52:18] <Avenger> before it ever goes alive
[20:52:25] <Avenger> it is used in iwd2 spells a lot
[20:52:32] <Avenger> the first effect disables th rest of the spell
[20:52:33] <lynxlynxlynx> yeah, the immunity opcodes
[20:52:39] <lynxlynxlynx> same in iwd/how
[20:52:48] <Avenger> but it is different from per spell resistance
[20:53:02] <Avenger> there is a per spell resistance/bounce check too
[20:53:16] <Avenger> it checks projectile too
[20:53:17] --> tomprince has joined #GemRb
[20:53:20] <Avenger> i think
[20:54:08] <lynxlynxlynx> nope
[20:54:17] <Avenger> fxqueue->CheckImmunity ( actor );
[20:54:29] <Avenger> that's what does a whole spell immunity check
[20:55:37] <lynxlynxlynx> yeah, need to move it there
[20:55:48] <Avenger> what do you need to move
[20:56:05] <Avenger> spell resistance?
[20:56:15] <lynxlynxlynx> well duplicate, not move
[20:56:47] <Avenger> hmm no
[20:56:55] <Avenger> maybe you need to use the same random number
[20:57:02] <Avenger> and do it per effect
[20:57:17] <Avenger> like saving throws do it
[20:57:35] <Avenger> because you cannot resist some effects in the same spell if they are marked irresistable
[20:57:45] <Avenger> so it needs to be done per effect
[20:57:51] <Avenger> but with the same roll
[20:58:08] <Avenger> just increase the saving throws array with a spell resistance roll
[20:58:57] <Avenger> hmm, there is fx->random_value
[20:59:02] <lynxlynxlynx> are you sure there are any such effects?
[20:59:36] <lynxlynxlynx> the random value is rerolled each time iirc
[20:59:44] <Avenger> yes, and i don't understand what's your problem, we already use a fixed value
[20:59:55] <lynxlynxlynx> but i also remember making it be rerolled less often months back
[20:59:55] <Avenger> no it is set in fx->random_value once per queue
[21:00:49] <Avenger> it is probably not entirely correct, because this random value is used for other stuff
[21:01:05] <lynxlynxlynx> ok, then it's mostly cosmetic, the output is misleading
[21:01:45] <lynxlynxlynx> and the fact that you have irresistible effects in resistible spells is a data relic
[21:04:32] <Avenger> well, it is how the original does it
[21:04:51] <Avenger> there may be one of 1000 spells where it counts
[21:06:03] <Avenger> there is no way to mark a spell irresistible, only effects, and i know there are spells with mixed resistance flags
[21:14:53] <lynxlynxlynx> fuzzie: now something for you
[21:16:09] <lynxlynxlynx> do you remember the PlayOnce fixes? It seems some spells use fx_play_visual_effect with param2==1 (sticky), but they shouldn't
[21:17:01] <lynxlynxlynx> armor does it like that and of course it then loops the animation a few times
[21:17:20] <fuzzie> and they have a long duration?
[21:18:13] <Avenger> i fixed something about that in the pst play bam sticky just recently
[21:18:29] <Avenger> it is a different opcode
[21:18:35] <fuzzie> i had a terrible time making pst sticky stuff work too
[21:18:40] <fuzzie> but that was the action, not any opcodes
[21:18:41] <Avenger> heh
[21:18:44] <Avenger> ah ok
[21:18:54] <Avenger> you mean the sinister poof thing ? :)
[21:19:03] <fuzzie> yeah
[21:19:10] <fuzzie> the duration was off by a factor of 1000 or something
[21:19:47] <Avenger> yes, i fixd something like that in pst too :)
[21:20:06] <Avenger> it needs AI_UPDATE_TIME as parameter, not some huge 4000 number
[21:20:18] <Avenger> that was in pst, at least
[21:20:24] <fuzzie> mm
[21:20:32] <lynxlynxlynx> it's interesting that it always loops 3 times, i'd expect it to loop forever in this case
[21:20:46] <fuzzie> well, for normal sticky anims, i wrote something which keeps anims alive as long as the effect is alive
[21:20:47] <Avenger> it is because the length calculation is multiplied
[21:20:55] <fuzzie> so it is entirely controlled by the effect
[21:21:19] <Avenger> yep, it is just most 'permanent effects' are not permanent, they live for exactly one loop
[21:21:22] <Avenger> that sucks :)
[21:21:46] <fuzzie> and i wrote it because it was needed, of course :P
[21:21:49] <lynxlynxlynx> armor has a duration of hours ;)
[21:21:59] <Avenger> even the anim?
[21:22:05] <fuzzie> lynxlynxlynx: yes, but the fx_play_visual_effect surely doesn't
[21:22:06] <Avenger> check the animation opcode
[21:22:43] <lynxlynxlynx> the spell i'm looking at doesn't even have 215 attached :s
[21:23:01] <Avenger> ohm, then where is the armor anim
[21:23:56] <Avenger> if you talk about the armor spell, it has 215
[21:24:11] <Avenger> spwi102, last effect
[21:24:14] <lynxlynxlynx> nevermind, i still had bg1 open :)
[21:25:02] <lynxlynxlynx> duration of 3 - half a round
[21:25:17] <fuzzie> which timing mode?
[21:25:35] <lynxlynxlynx> duration
[21:28:36] <lynxlynxlynx> we don't seem to copy it
[21:28:59] <lynxlynxlynx> i'll try that
[21:29:28] <fuzzie> how do you mean?
[21:29:49] <fuzzie> i mean, if it's sticky, you don't want to mess with the VVC itself
[21:30:09] <fuzzie> but there's got to be some way to differentiate between this and the ones which need it
[21:31:03] <fuzzie> i guess it is messing with the VVC anyway
[21:32:01] <fuzzie> and so in fact my code is being completely ignored
[21:32:48] <fuzzie> if you set the VVC duration manually, then you're stuck with it for that long
[21:33:01] <fuzzie> could you see if the effect is still attached during the 2nd/3rd plays?
[21:33:43] <lynxlynxlynx> will check
[21:34:11] <lynxlynxlynx> that SetDefaultDuration bit looks like it is missing an AI_UPDATE_TIME, but it had no visible effect
[21:34:25] <fuzzie> the duration is already adjusted to ticks, there
[21:36:40] <lynxlynxlynx> and yes, the effect persists
[21:37:36] <fuzzie> maybe put a PlayOnce() after the SetDefaultDuration, then
[21:38:43] <lynxlynxlynx> do you remember any spells that use sticky as we want them?
[21:39:05] <fuzzie> the logic i added *only* affects spells when SetDefaultDuration isn't called
[21:39:32] <fuzzie> so in any case, those specific spells aren't going to change behaviour here
[21:39:37] <fuzzie> i don't remember any of the other test cases :(
[21:44:09] <lynxlynxlynx> heh, looks like there's a rough mapping between the duration and the number of repeats
[21:44:19] <lynxlynxlynx> probably just due to the vvc being so short
[21:44:31] <lynxlynxlynx> setting the duration to 6 played it some 5,2 times
[21:45:15] <lynxlynxlynx> there's param1, but it's 0 here too
[21:46:55] <lynxlynxlynx> anyway, looks like you're right - even with another PlayOnce in there, the same thing happens
[21:48:22] <-- |Cable| has left IRC (Read error: Connection reset by peer)
[21:49:14] <fuzzie> what happens if you don't set the duration?
[21:49:27] <fuzzie> (and call PlayOnce)
[21:49:51] --> |Cable| has joined #GemRb
[21:54:45] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
[21:55:32] <lynxlynxlynx> no difference
[22:00:31] <CIA-29> GemRB: 03avenger_teambg * rc51db859dbe5 10ielister/ielister.cpp: new gemrb specific projectile fields in ielister
[22:02:06] <CIA-29> GemRB: 03avenger_teambg * r0e2f4d0ac8c4 10dltcep/ (7 files): dltcep update (new projectile fields and flags)
[22:20:18] <CIA-29> GemRB: 03avenger_teambg * re4701f40ab4b 10gemrb/gemrb/ (4 files in 3 dirs): fixed the description field of ResourceSources (printed garbage on windows, 0 string on linux) for CDx
[22:20:19] <CIA-29> GemRB: 03avenger_teambg * r4dd76a4ba230 10gemrb/gemrb/ (3 files in 2 dirs):
[22:20:19] <CIA-29> GemRB: implemented limited target count (optional HD) for area projectiles
[22:21:33] <CIA-29> GemRB: 03avenger_teambg * r34d20e9fcdc3 10gemrb/gemrb/override/pst/ (6 files): projectile binary data
[22:24:46] <edheldil_> I am almost done with a framework for GameType autodetection
[22:39:05] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[22:52:17] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[23:06:32] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:45:19] <-- barra_home has left IRC (Quit: Verlassend)