#gemrb@irc.freenode.net logs for 31 May 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:24:38] <tomprince_loki> Do we care if what happens if all the actions in a dialog fail to compile. Whether we treat it as having actions or not?
[00:26:14] <fuzzie> umm
[00:26:39] <fuzzie> i don't think so
[00:27:10] <fuzzie> but dialog actions failing to compile is pretty much an error condition, i would imagine
[00:27:23] <tomprince_loki> Yes, that was my thought.
[00:27:28] <fuzzie> as usual, gemrb's implementation of the actions is incorrect..
[00:27:39] <tomprince_loki> What should it be?
[00:27:43] <tomprince_loki> Do you know?
[00:27:51] <fuzzie> nothing relevant to you, i imagine
[00:28:10] <fuzzie> the behaviour is incorrect after the actions are added to the scriptable's queue, that's all
[00:28:38] <fuzzie> it's meant to only run a whitelisted subset of actions immediately, and then not attempt to run anything else
[00:29:14] <fuzzie> (see .. instant.ids, I think?)
[00:30:01] <fuzzie> but as usual it's a bit subtle with regards to specific engine versions, and so i never got around to doing it properly
[00:32:14] <fuzzie> the folks on gibberlings3 are terribly helpful for bg2, devSin knows bg1 pretty well and scient knows some bits of pst very well, but unfortunately there's no magical person with knowledge of everything
[00:36:07] <fuzzie> but it's definitely worth just asking about things on the forums :)
[00:36:10] <fuzzie> ok, sleepy time
[00:37:40] <tomprince_loki> I am going to apply the dialog trigger patch.
[00:38:08] <tomprince_loki> If we need to vary the behavior, we can add a condition in Condition::Evalutate.
[00:39:12] <fuzzie> i'd suggest trying it, but i couldn't find anywhere it could possibly matter
[00:39:58] <tomprince_loki> I think that the only thing for which it could mater is something like See, which has side effects.
[00:40:23] <tomprince_loki> But if something is depending on LastSeen, then it probably has a check before it in the AI script anyway?
[00:42:53] <fuzzie> yes
[00:44:20] <fuzzie> bg2/pthral01.d:Attack(LastSeenBy(Myself))~ EXIT
[00:44:42] <fuzzie> ^- only hit, seems irrelevant here, since not trigger-set
[01:06:14] --> Gekz has joined #GemRb
[01:17:48] <tomprince_loki> gcc can now be coded in c++ ... :)
[01:35:06] <-- Maighstir has left #GemRb
[01:52:02] <Gekz> tomprince_loki: lol
[02:01:06] <-- Gekz has left IRC (Ping timeout: 240 seconds)
[02:28:11] --> Gekz has joined #GemRb
[02:30:17] --> Gekz_ has joined #GemRb
[02:33:48] <-- budlust has left IRC (Ping timeout: 276 seconds)
[03:13:13] <-- _pickle has left IRC (Remote host closed the connection)
[04:13:09] --> raevol has joined #GemRb
[04:39:45] <-- raevol has left IRC (Quit: Leaving.)
[04:40:24] --> budlust has joined #GemRb
[04:54:03] <-- Gekz has left IRC (Ping timeout: 248 seconds)
[04:59:14] <tomprince> Another shot in the dark about mingw: I see some things suggesting that 64-bit machine might be a culprit...
[05:25:45] <tomprince> And I can confirm that it happens here.
[06:01:36] <-- budlust has left IRC (Ping timeout: 272 seconds)
[06:13:07] <-- cubathy has left IRC (Quit: Leaving)
[07:27:21] <-- tomprince_loki has left IRC (Ping timeout: 265 seconds)
[07:36:23] <-- Gekz_ has left IRC (Ping timeout: 260 seconds)
[07:57:17] <edheldil> Gekz: pirate party had 0.8% in general elections here :)
[08:09:13] --> lynxlynxlynx has joined #GemRb
[08:09:13] --- ChanServ gives channel operator status to lynxlynxlynx
[08:38:32] <-- |Cable| has left IRC (Remote host closed the connection)
[09:13:55] <fuzzie> morning
[09:16:08] <lynxlynxlynx> oj
[09:18:10] --> kettuz has joined #GemRb
[09:20:38] <edheldil> hi
[09:20:49] <lynxlynxlynx> i found out we have a CasterID field in the effect struct
[09:21:12] <lynxlynxlynx> currently unused, but it seems perfect for solving this turning and the recurring damager problems
[09:22:50] <lynxlynxlynx> but it would require changing all of the AddEffect calls, so i'm not sure if we shouldn't just store it in each effect that needs it manually
[09:23:20] <lynxlynxlynx> what do you think?
[09:23:30] <lynxlynxlynx> & hi ed :)
[09:24:13] <fuzzie> it's an extended field, so it'll be missing from loaded effects, don't know if that's a problem
[09:24:35] <lynxlynxlynx> not for these use cases
[09:25:22] <lynxlynxlynx> hmm, it would actually
[09:25:39] <fuzzie> well, remember that only permanent effects get saved out
[09:25:42] <lynxlynxlynx> at least until we allow saving so freely
[09:26:28] <fuzzie> i wonder why nothing sets CasterID?
[09:27:07] <lynxlynxlynx> my guess is that it is not certain that it does what it does
[09:27:21] <lynxlynxlynx> and there was just no need for it yet
[09:28:45] <lynxlynxlynx> it was added at the end of 09
[09:29:38] <fuzzie> which opcodes are you looking at?
[09:30:18] <lynxlynxlynx> currently fx_control_undead, but poison and fx_damage would be next
[09:30:49] <lynxlynxlynx> it is easy to set this in the effect when needed with the FirstApply check
[09:33:06] <fuzzie> 122_protection_helper:004BF53C 8B 86 0C 01 00 00 mov eax,dword ptr [esi+10Ch] ;;caster (source of spell)
[09:33:25] <fuzzie> $ grep "+10Ch" 00c_damage -c
[09:33:25] <fuzzie> 15
[09:33:46] <fuzzie> ^- so, yes, i guess this is the right thing
[09:34:06] <lynxlynxlynx> thanks
[09:35:23] <fuzzie> also in 107 (controlundead) and 19 (poison) :)
[09:35:44] <lynxlynxlynx> :)
[09:36:19] <fuzzie> Avenger surely knew this, though, I wonder what his plan was
[09:36:23] <fuzzie> he added it at the end of 09?
[09:36:32] <fuzzie> if so, i guess he just didn't find the time
[10:02:42] --> Gekz has joined #GemRb
[10:22:02] <CIA-24> GemRB: 03lynxlupodian * r6375c78f200f 10gemrb/gemrb/plugins/IWDOpcodes/IWDOpcodes.cpp:
[10:22:02] <CIA-24> GemRB: fx_control_undead: save the caster, so the next applications don't reset
[10:22:02] <CIA-24> GemRB: the effect (the owner changes); run the pcf, so the feet circle is updated
[10:22:04] <CIA-24> GemRB: 03lynxlupodian * r84f833afc29d 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: fx_set_charmed_state: run the pcf, so the feet circle is updated
[10:41:54] <CIA-24> GemRB: 03lynxlupodian * rc072e63b846d 10gemrb/gemrb/override/ (how/turn.spl iwd2/turn.spl shared/turn.spl):
[10:41:54] <CIA-24> GemRB: turn.spl: minimised the duration, so it doesn't extend into another round;
[10:41:54] <CIA-24> GemRB: it is reapplied with the actor state updates
[10:42:00] <CIA-24> GemRB: 03lynxlupodian * r2e8bea3f7612 10gemrb/gemrb/ (7 files in 7 dirs):
[10:42:00] <CIA-24> GemRB: use the ControlUndead2 effect when evil-turning, so there is no clash
[10:42:00] <CIA-24> GemRB: with effects from other games
[10:42:22] <lynxlynxlynx> turning: done :)
[10:46:32] <fuzzie> ^.^
[11:23:54] <-- kettuz has left IRC (Quit: Leaving)
[11:30:34] <CIA-24> GemRB: 03lynxlupodian * r6e074e6807a8 10gemrb/gemrb/ (4 files in 3 dirs):
[11:30:34] <CIA-24> GemRB: split SetModalSpell from the guiscript code and reused it to set the spell
[11:30:34] <CIA-24> GemRB: on game load, so modal actions continue to work
[12:55:36] <lynxlynxlynx> any idea why gdb sees Scriptable pointers as void* pointers?
[13:11:30] <lynxlynxlynx> ah, just need to add "struct" to the cast and it works
[13:37:17] --> cubathy has joined #GemRb
[13:48:26] <-- cubathy has left IRC (Ping timeout: 245 seconds)
[14:34:52] --> pupnik has joined #GemRb
[15:13:28] <-- fuzzie has left IRC (Ping timeout: 260 seconds)
[15:20:38] --> Maighstir has joined #GemRb
[15:24:45] <Maighstir> tomprince: what about 64-bit machines?
[15:25:21] <tomprince> I really don't know, and don't have it working, but some thing I read suggest that it *might* be an issue that only shows up on 64-bit machines.
[15:26:41] <Maighstir> Heh, figures. And I doubt I still have a working 32-bit box for testing.
[15:27:26] <tomprince> I wonder if fuzzie tested it on a 32-bit machine...
[15:34:22] <tomprince> Do you get a bunch of warnings about auto-import?
[15:36:06] <edheldil> I have 32 bit machine only :-P
[15:37:39] --> fuzzie_ has joined #GemRb
[15:37:51] <fuzzie_> i tested it under wine, where i assume weird issues wouldn't show up anyway.
[15:38:30] <fuzzie_> and the auto-import warnings are because mingw's libstdc++ headers don't actually mark things as to be imported, as far as I could tell.
[15:42:55] <fuzzie_> actually, looking into it, that is known to cause crashes.
[15:43:33] <fuzzie_> apparently the "warning: enabling auto-import" means something along the lines of "warning: not actually doing auto-import, your binaries will promptly crash at startup".
[15:44:39] <tomprince> :)
[15:45:00] <tomprince> I thought that might be the case.
[15:48:02] <fuzzie_> They might as well put "p.s. using gcc on Windows and expecting it to work is crazy" at the end of these release notes, really.
[15:48:14] <fuzzie_> But it is in there:
[15:48:22] <fuzzie_> * When linking C++ modules with shared libstdc++ (the default), the
[15:48:22] <fuzzie_> linker may warn about activating auto-import. The workaround is to
[15:48:22] <fuzzie_> add one of the following flags:
[15:48:22] <fuzzie_> a) -Wl,--enable-runtime-pseudo-reloc-v2
[15:48:22] <fuzzie_> The warning is still printed, but is now harmless.
[15:48:25] <fuzzie_> b) -Wl,--enable-auto-import
[15:48:27] <fuzzie_> Actually does what the warning suggests.
[15:48:30] <fuzzie_> c) -static-libstdc++
[15:48:32] <fuzzie_> Avoids creating the issue in the first place.
[15:48:35] <fuzzie_> d) none of the above.
[15:48:37] <fuzzie_> You may get a 0xc0000005 error at runtime.
[15:48:40] <fuzzie_> And now I have to go rescue people from their incompetence, be back in a bit.
[15:51:10] <lynxlynxlynx> how edwin of you
[15:52:28] <Maighstir> I'm glad it wasn't a complete PEBKAC, I was worried for a while.
[16:03:37] <tomprince> Success.
[16:03:51] <Gekz> yay
[16:05:53] <tomprince> Maighstir: do you have 3.4.6 installed to test?
[16:08:13] <CIA-24> GemRB: 03tom.prince * ree0c9cb06109 10gemrb/gemrb/includes/win32def.h: msvc6: Warning fix.
[16:10:50] <Maighstir> gcc? no
[16:11:20] <tomprince> I was just wondering if I need to test versions before passing -Wl,--enable-auto-import in cmake.
[16:12:47] --> Avenger has joined #GemRb
[16:12:52] --- ChanServ gives channel operator status to Avenger
[16:13:04] <tomprince> Hello.
[16:13:05] <Avenger> tom i got: Actor.cpp:3627: warning: comparison between signed and unsigned integer expressions
[16:14:10] <Avenger> hehe, i wonder why that (signed) remained there
[16:14:43] <Avenger> hmm that was lynx
[16:15:51] <lynxlynxlynx> oj
[16:16:14] <lynxlynxlynx> if (state >= (signed)core->ModalStates.size()) { <-- this one?
[16:16:18] <Avenger> hey lynx, you left some towel in the patient :)
[16:16:21] <Avenger> yep
[16:16:30] <lynxlynxlynx> ok
[16:16:40] <Avenger> i committed it without signed now
[16:16:53] <Avenger> err just tried
[16:17:01] <lynxlynxlynx> pull again
[16:17:36] <Avenger> i hate git :)
[16:17:46] <CIA-24> GemRB: 03avenger_teambg * r466ce31b361f 10gemrb/gemrb/core/Actor.cpp: removed (signed) to avoid a warning
[16:17:48] <CIA-24> GemRB: 03avenger_teambg * rcb9899ed498b 10gemrb/gemrb/includes/win32def.h: Merge branch 'master' of ssh://avenger_teambg@gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[16:19:24] <lynxlynxlynx> if you've got some time&will, i would appreciate if you figured out the two check_iwd_targeting bugs
[16:20:02] <Avenger> didn't you just switched some signs recently :)
[16:20:47] <lynxlynxlynx> no, i haven't committed that
[16:21:01] <Avenger> oh good
[16:21:20] <Avenger> then i just have to figure out what i wanted
[16:21:39] <Avenger> these bugs are filed in our tracker?
[16:21:44] <lynxlynxlynx> no, the first thing is that the return status is inconsistent
[16:21:52] <tomprince> Fuzzie and I were discussing splitting up core into seperate directories.
[16:22:17] <lynxlynxlynx> then there is that spell immunity 3 effect that needs to have the check inverted for soul eater to work
[16:22:24] <Avenger> well, i don't mind the gui components to be moved
[16:22:29] <Maighstir> tomprince: now I have 3.4.5 installed, does that suffice?
[16:22:32] <Avenger> button/window/.. these
[16:22:43] <tomprince> Yes.
[16:23:26] <Avenger> lynx: the problem is: i'm totally losing motivation when i try to compile on msvc and i fail
[16:23:37] <tomprince> Try running cmake with -DCMAKE_SHARED_LINKER_LINKER_FLAGS=-Wl,--enable-auto-import -DCMAKE_MODULE_LINKER_LINKER_FLAGS=-Wl,--enable-auto-import
[16:23:56] <Avenger> last week i wasted half a day for nothing
[16:23:58] <tomprince> I have a buildbot setup now, that build msvc6 using cmake.
[16:24:07] --> Gekz_ has joined #GemRb
[16:24:24] <tomprince> So the compile it self is regularly tested. For exactly that reason.
[16:24:27] <lynxlynxlynx> Avenger: when things break, more actively blame the one that did it
[16:24:38] <lynxlynxlynx> we can own up to our mistakes
[16:24:43] <Avenger> well i don't want to hurt feelings :P
[16:25:02] <Avenger> i just though i will wait till the dust settles
[16:25:06] <-- Gekz_ has left IRC (Client Quit)
[16:25:08] <lynxlynxlynx> i have the emotional stability of sand :P
[16:25:59] <Avenger> it is mostly tom who stirs up the stuff anyway, your sign 'mistake' is by no way hindering me
[16:26:27] <Avenger> i can try to go back to windows and compile now, if you say it is fine, tom ;)
[16:26:33] <tomprince> It is.
[16:26:41] <lynxlynxlynx> it doesn't matter who it is
[16:27:15] <Avenger> ok, brb
[16:27:16] <-- Avenger has left IRC (Quit: bye!)
[16:31:18] --> Avenger has joined #GemRb
[16:31:23] --- ChanServ gives channel operator status to Avenger
[16:31:29] <tomprince> I don't want you to lose motivation, and I know that I have cause the most churn with msvc6, so I set things up so that I can test it.
[16:31:43] <Avenger> ok
[16:31:56] <Avenger> it compiles now
[16:32:03] <Avenger> oops
[16:32:10] <Avenger> i said too early ;P
[16:32:26] <tomprince> I would like to convince you to use cmake for generating the project files, since that is what I use here.
[16:32:30] <Avenger> Compiling...
[16:32:31] <Avenger> ACMImporter.cpp
[16:32:33] <Avenger> e:\gemrb\gemrb\includes\plugindef.h(109) : error C2259: 'ACMImp' : cannot instantiate abstract class due to following members:
[16:32:34] <Avenger> e:\gemrb\gemrb\plugins\acmimporter\acmimporter.h(39) : see declaration of 'ACMImp'
[16:32:57] <Maighstir> tomprince: output: http://www.ops-area.net/annat/GemRB/oldmingw.txt
[16:33:43] <tomprince> That is because we don't have ACMImporter any more.
[16:34:06] <Avenger> oh hehe
[16:34:14] <tomprince> I don't have access to update the project files, I just use cmake to build them automatically.
[16:34:20] <tomprince> Which is nicer anyway.
[16:34:35] <Avenger> we don't have acmimporter at all?
[16:34:43] <Avenger> so i can remove that complete dir?
[16:35:12] <tomprince> Maighistir: also add -DDISABLE_WERROR=Yes
[16:35:14] <tomprince> Yes.
[16:35:41] <Avenger> ok, that's good, i thought i already figured out the project structure earlier
[16:35:46] <Avenger> or maybe this was removed later :)
[16:35:57] <Avenger> ok, now i got it compiled !!
[16:36:14] --> fuzzie has joined #GemRb
[16:36:22] <Avenger> and it starts too
[16:36:34] <Avenger> hi fuzzie!
[16:36:36] <-- Gekz has left IRC (Quit: Leaving)
[16:37:13] <tomprince> Maighstir: Also, it should just be one LINKER, not LINKER_LINKER.
[16:38:01] <tomprince> Avenger: If you still had ACMImporter, do you have (ACM|OGG|WAV)Reader?
[16:38:16] <Avenger> ok, my sound player is broken
[16:38:35] <Avenger> tom: did we have ogg reader?
[16:38:52] <tomprince> We didn't. We do now.
[16:39:19] <tomprince> I actually haven't tested that or png on msvc6, since I haven't got around to installing them yet.
[16:39:26] <Avenger> oh that's why i don't have sound?
[16:39:38] <Maighstir> it starts up anyway :-P
[16:39:51] <Avenger> ok, so there are 3 new projects?
[16:40:09] <Avenger> i didn't compile ogg/wavreader
[16:40:20] <tomprince> Yes.
[16:40:27] <Avenger> ok, i add these
[16:40:34] <tomprince> I think it would save you a bunch of hassle to try cmake out.
[16:42:03] <Avenger> i like my old rusty msvc :)
[16:42:23] <tomprince> Yes, and cmake will generate msvc6 files.
[16:42:30] <tomprince> That is how i test msvc6.
[16:42:42] <Avenger> but i will spend days till cmake starts working
[16:43:03] <tomprince> Why will it take that long?
[16:46:08] <tomprince> I sucessfully build gemrb with cmake generated project files every day.
[16:48:58] <Avenger> you have cmake set up
[16:50:20] <Avenger> i have a cmake 2.6 patch 2 icon on my machine, i don't know how to use it, and i don't have time to find that out
[16:51:26] <tomprince> I want to make things as seemless as possible for you on msvc6.
[16:51:59] <Avenger> ok, what i need to download for the vorbis stuff....
[16:52:01] <tomprince> But fuzzie was talking about moving things around, and if you had cmake setup, then that wouldn't be an issue.
[16:52:37] <tomprince> Vorbis: I don't know I haven't set that up yet.
[16:52:49] <Avenger> then how do you compile the ogg reader
[16:53:19] <Avenger> E:\gemrb\gemrb\plugins\OGGReader\OGGReader.h(28) : fatal error C1083: Cannot open include file: 'vorbis/vorbisfile.h': No such file or directory
[16:53:25] <tomprince> I haven't, on windows.
[16:53:34] <Avenger> oh, well :)
[16:53:51] <Avenger> ok, then i exclude that from compiling
[16:55:17] <Avenger> see, a working cmake (if it works at all) wouldn't have helped here
[16:55:22] <fuzzie_> well, i wonder about moving things around, but i would rather we keep Avenger's project working
[16:55:27] <-- fuzzie_ has left IRC (Quit: leaving)
[16:56:32] <Avenger> well, i hope once we are through the big changes it will be calmer
[16:58:32] <Avenger> ok, rebuilding all except ogg
[17:01:01] <tomprince> Well, I would rather make lots of small changes over time, rather than a few big changes...
[17:02:47] <fuzzie> but cmake builds break too, it is not really a magical solution
[17:03:21] <fuzzie> much better than manually maintaining a seperate file, but still
[17:04:55] <Avenger> well, i ALREADY made it compile, with cmake i would still tear my hair out
[17:05:30] <Avenger> the only problem is ogg, which seems to come in source with no msvc6 support
[17:05:50] <Avenger> so, i leave that for tom :)
[17:06:06] <Avenger> i found this: http://www.xiph.org/downloads/
[17:06:40] <Avenger> i guess both libogg and libvorbis zips are needed
[17:06:55] <Avenger> the worst that happens is we include them in the code :P
[17:08:31] <Avenger> btw, we had the ogg reader
[17:08:37] <Avenger> and i swear it worked
[17:09:08] <Avenger> openal had it, no?
[17:09:15] <Avenger> hmm, maybe it wasn't in openal soft?
[17:10:57] <Avenger> Ahh, it was ifdefed with HAS_VORBIS_SUPPORT
[17:11:09] <Avenger> ok, then it probably never ran on win32
[17:12:09] <Avenger> i got my sound, that's all i needed
[17:13:04] <tomprince> There seems to be no way to pass environment variables to cmake through the gui.
[17:13:07] <tomprince> :(
[17:13:35] <Avenger> that's not so important now, i removed oggreader from the win dependency list
[17:14:02] <Avenger> eep, crash on exit
[17:16:06] --> Avenger_ has joined #GemRb
[17:16:06] <-- Avenger has left IRC (Read error: Connection reset by peer)
[17:16:08] --- Avenger_ is now known as Avenger
[17:16:15] --- ChanServ gives channel operator status to Avenger
[17:16:19] <Avenger> meh
[17:18:15] --> kettuz has joined #GemRb
[17:18:47] <fuzzie> i said the other day that tomprince seemed to have added some globals with constructors/destructors, which is a possible culprit if you're seeing difficult-to-debug crashes after main() is done
[17:19:24] <Avenger> this crashes in ~sdlvideo in freeing the subtitle text
[17:19:26] <fuzzie> otherwise i didn't see anything though
[17:19:34] <Avenger> calls core->freestring(subtitletext)
[17:19:40] <Avenger> core in turn calls into strings
[17:19:52] <Avenger> which is freed first? sdlvideo or strings?
[17:20:01] <fuzzie> not predictable order, i think
[17:20:08] <Avenger> what???
[17:20:21] <Avenger> it was predictable before
[17:20:24] <fuzzie> it wasn't
[17:20:34] <fuzzie> this is why NullSound worked for some people and not for others
[17:20:38] <CIA-24> GemRB: 03lynxlupodian * rc1ed04da6f7a 10gemrb/gemrb/core/ (ActorBlock.h Interface.cpp):
[17:20:38] <CIA-24> GemRB: Scriptable: added a virtual GetName, so the actor names can be dumped
[17:20:38] <CIA-24> GemRB: without a cast when debugging
[17:20:39] <CIA-24> GemRB: 03lynxlupodian * r70967fa47651 10gemrb/gemrb/core/GSUtils.cpp:
[17:20:39] <CIA-24> GemRB: DisplayStringCore: ignore also single-space strings
[17:20:39] <CIA-24> GemRB: (the last female voice in bg2 causes extraneus output otherwise)
[17:20:40] <CIA-24> GemRB: 03lynxlupodian * rc9fd30dc4429 10gemrb/gemrb/core/ (Interface.cpp Interface.h): added an overloaded Interface::DisplayStringName to display custom strings
[17:20:43] <CIA-24> GemRB: 03lynxlupodian * r3b8e1b870290 10gemrb/gemrb/core/ (Actor.cpp Actor.h):
[17:20:43] <CIA-24> GemRB: made ModifyDamage and DisplayCombatFeedback take a scriptable instead;
[17:20:43] <CIA-24> GemRB: improved the bg1/iwd combat feedback and used the same one for traps
[17:20:43] <CIA-24> GemRB: that usually have no owner
[17:20:47] <Avenger> strings is not a plugin
[17:20:47] <CIA-24> GemRB: 03lynxlupodian * rd9936980e5a7 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp:
[17:20:47] <CIA-24> GemRB: save the caster in the effects that do recurring damage
[17:20:47] <CIA-24> GemRB: (now we don't say you are poisoning yourself in the next rounds)
[17:20:52] <fuzzie> oh
[17:21:06] <fuzzie> sdlvideo should surely be freed first, then
[17:21:20] <Avenger> wait
[17:21:24] <Avenger> actually, yes, it is
[17:21:29] <Avenger> oh
[17:21:30] <Avenger> hehe
[17:21:32] <Avenger> ok
[17:21:55] <fuzzie> i thought strings came from TLK files
[17:22:02] <fuzzie> but i don't have the code here, as usual recently :(
[17:22:09] <Avenger> you knew right
[17:22:25] <Avenger> so, you say we did free plugins in random order?
[17:22:28] <tomprince> SDLVideo is freed last.
[17:22:40] <Avenger> that sucks here :)
[17:22:44] <tomprince> No, we free them bottom up.
[17:22:48] <Avenger> because sdlvideo calls into strings
[17:22:56] <Avenger> ~sdlvideo
[17:22:59] <fuzzie> tomprince: you force plugin load order?
[17:23:15] <tomprince> No, that is on desctructor call, which is handled by ~Holder.
[17:23:15] <Avenger> we need two phase free, or a set free order
[17:23:48] <Avenger> strings seems to be needed to free after sdlvideo
[17:23:55] <tomprince> At the end of ~Interface, all the desctructors of member variables are called, from the end of the class up.
[17:24:03] <fuzzie> oh, so the real bug is that sdlvideo's destructor shouldn't be doing that
[17:24:16] <tomprince> For that, could we just turn it into a free?
[17:24:28] <Avenger> dunno
[17:24:54] <fuzzie> this is why i don't like just putting smart pointers everywhere, you hide behaviour
[17:25:34] <Avenger> hehe, is this tom's fault too :D ?
[17:25:55] <Avenger> i thought i was just lucky before
[17:26:04] <lynxlynxlynx> does gemrb still compile now? :)
[17:26:08] <Avenger> i know i watched movies with subtitle
[17:26:12] <Avenger> yes it compiles
[17:26:13] <fuzzie> i'm not sure whether it was luck before or not :)
[17:26:31] <Avenger> it just dies on exit if you got subtitled movie
[17:26:54] <Avenger> well, definitely and improve from last week
[17:27:31] <fuzzie> did lynx ask about CasterID?
[17:27:44] <lynxlynxlynx> nope
[17:28:09] <fuzzie> i see that it is used in the original opcode functions a lot, so i wonder why gemrb doesn't set it for all effects
[17:31:28] <Avenger> because i likely added it later when i noticed it is inevitable
[17:31:37] <Avenger> or smething like that
[17:31:46] <fuzzie> that is what lynx found, i think, i just wondered if there was some other reason :)
[17:32:22] <Avenger> i wonder too, because it is needed for the 'original caster' targeting mode in bg2
[17:32:34] <Avenger> so it must be set, always
[17:33:41] <Avenger> that fixes the summoning problems?
[17:34:42] <lynxlynxlynx> what summoning problems? :)
[17:35:20] <lynxlynxlynx> this was for damage/poison/disease (basically all the damage fx in fxopcodes)
[17:35:40] <lynxlynxlynx> except for fx_death, which i trust not to be recurring
[17:35:42] <Avenger> the EA field for summoned creatures was always incompatible with the original engine
[17:35:54] <Avenger> maybe the original caster field can help there
[17:36:15] <Avenger> anyway, i'm gone for now :)
[17:36:18] <lynxlynxlynx> wait
[17:36:19] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])
[17:36:35] <lynxlynxlynx> :)
[17:39:10] <fuzzie> huh, the death effect is kinda complicated
[17:40:39] <fuzzie> i should've checked it before
[17:40:44] <tomprince> :\
[17:40:56] <fuzzie> some really obvious fixes to be made
[17:42:28] <fuzzie> unfortunately, first exam is tomorrow afternoon
[17:42:52] <lynxlynxlynx> we're not going anywhere
[17:53:33] <tomprince> Pity about cmake.
[17:54:28] <fuzzie> i thought there was a gui for it
[17:54:39] <lynxlynxlynx> there is
[17:54:45] <fuzzie> like, this is why everyone helpfully sabotaged ccmake from their packages
[17:59:32] --> barra_library has joined #GemRb
[18:00:05] <tomprince> It is fairly straight forward, but as far as I can tell, you need to specify the paths of everything by hand on windows.
[18:00:54] <fuzzie> but only once?
[18:01:25] <tomprince> Should be.
[18:02:53] <fuzzie> there used to just be some trivial GUI thing which would take a cmake input directory and let you click for a file browser in a list with all the required paths in it, shipped with cmake for Windows
[18:03:15] <tomprince> Still is.
[18:03:22] <fuzzie> which seems like it would be quite adequate
[18:03:48] <fuzzie> assuming it generates msvc6 files which manage to regenerate themselves fine
[18:03:54] <tomprince> cmake-gui, which works on linux as well.
[18:06:24] <fuzzie> an 8.1mb binary, heh.
[18:07:04] <lynxlynxlynx> only 2.5 here
[18:07:09] <fuzzie> lynxlynxlynx: on windows?
[18:07:14] <lynxlynxlynx> nope
[18:07:41] <fuzzie> the Windows one has to statically link Qt
[18:08:15] <fuzzie> i imagine anything packaged is just going to drag all the Qt libs along with it..
[18:17:44] <tomprince> http://hermes.hocat.ca:4010/waterfall for now. Though I don't want it on the wiki yet.
[18:18:19] <fuzzie> no architecture noted?
[18:18:43] <tomprince> It is all x86_64.
[18:40:28] <lynxlynxlynx> nice
[18:46:12] <pupnik> cool tomprince
[18:47:02] <pupnik> has anyone been building for arm?
[18:48:27] <tomprince> Not that I know of.
[18:48:51] <tomprince> Of the people that hang out here, I think fuzzie is probably the only who might have.
[18:49:58] <tomprince> I don't have access to anything other than x86/x86_64, but if somebody has cycles to donate, I could hook them up as buildslaves.
[18:50:30] <fuzzie> i doubt anyone has ever built arm gemrb binaries on anything except x86/x86_64 :p
[18:51:21] <tomprince> Well, maybe I'll see about setting up cross-compilers, and figure out how to make cmake play nice with them.
[18:52:10] <pupnik> it could be a headache with little utility
[18:52:52] <pupnik> since builds targeting arm devices will be less frequent
[18:53:42] <fuzzie> i think tomprince wants to know when he breaks things
[18:54:07] <fuzzie> and all the pandora/maemo/etc people tend to only start trying builds when releases happen, it seeems
[18:54:19] <tomprince> Or anybody, and if it even works on other platforms.
[18:55:06] <fuzzie> sparc tends to be terribly useful for spotting alignment bugs
[18:55:34] <fuzzie> the arm machines i have access to just silently corrupt misaligned reads/writes, it's annoying
[18:57:12] <pupnik> yes heres the latest working maemo build http://bundyo.com/things/gemrb-0.6.0-maemo0.deb
[18:57:42] <pupnik> the omaps can alert to some of that
[18:58:17] <tomprince> So what does one need to setup to run a mameo build?
[18:59:12] <pupnik> it was once a library building adventure
[18:59:48] <pupnik> havent done it lately. std build system uses qemu, not crosscompiling per se
[19:00:25] <pupnik> i use the scratchbox vmware image to do my builds
[19:02:17] <pupnik> maybe user bundyo can help more http://talk.maemo.org/showthread.php?t=16947&highlight=gemrb&page=2
[19:08:46] <tomprince> Maighstir: Still around? Did it work with 3.4.5?
[19:09:42] <Maighstir> I replied long ago :-P yeah, even with linker_linker
[19:10:35] <tomprince> Must have missed it. Does it work with just LINKER. I am curious whether there is support for it there.
[19:10:48] <tomprince> With LINKER_LINKER, it would just do nothing.
[19:10:49] <Maighstir> and changing it to just linker didn't change anything, from my short testing
[19:11:04] <tomprince> Good. Then I'll push the changes. :)
[19:13:12] <Maighstir> 4.5.0 spouted a load of garbage though, but I don't know if it's of any relevance: http://ops-area.net/annat/GemRB/gcc450.txt
[19:13:36] <CIA-24> GemRB: 03tom.prince * raabf5cb67ff2 10gemrb/CMakeLists.txt:
[19:13:36] <CIA-24> GemRB: mingw: Fix gcc 4.5.0 support.
[19:13:36] <CIA-24> GemRB: GCC 4.5.0 adds shared libstdc++.
[19:13:36] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:15:11] <lynxlynxlynx> interesting thread
[19:16:40] <CIA-24> GemRB: 03tom.prince * rae783cb338ff 10gemrb/gemrb/core/ActorBlock.h:
[19:16:40] <CIA-24> GemRB: clang: Fix warning.
[19:16:40] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:36:34] <Lightkey> /topic 18:25:03 <@lynxlynxlynx> i have the emotional stability of sand :P
[19:36:43] <Lightkey> ooops
[19:37:45] <lynxlynxlynx> http://hyperboleandahalf.blogspot.com/2010/05/sneaky-hate-spiral.html <-- from here ;)
[19:39:52] <Lightkey> variation/stability?
[19:40:53] <Lightkey> cat in face :-D
[19:49:55] <Lightkey> "I'm running out of places to bury the Cub Scouts that have tried to sell me popcorn."
[19:54:52] --> |Cable| has joined #GemRb
[20:04:14] <-- tomprince has left IRC (Ping timeout: 265 seconds)
[20:06:13] <Maighstir> where'd the function go that selects <program-name>.cfg as the default cfg file?
[20:06:46] <Maighstir> mine doesn't want to do that, but only goes for GemRB.cfg regardless of how the exe is named
[20:07:30] <Maighstir> minor annoyance though
[20:12:38] <fuzzie> WIN32 not defined?
[20:12:48] <fuzzie> or, rather, WIN32 defined, even
[20:13:42] <Maighstir> compiling/running on Win32/MinGW, yes...
[20:14:13] <fuzzie> not the question :)
[20:14:22] <fuzzie> not really aimed at you though
[20:14:31] <fuzzie> but that code is wrapped in a '#ifndef WIN32'
[20:14:40] <fuzzie> and has been forever, as far as i can tell
[20:14:54] <Maighstir> hmm... just a case of it-did-work-before
[20:18:54] <fuzzie> so i wonder if that got newly defined or something
[20:20:19] <fuzzie> yes, i guess caused by tomprince's patch to remove -ansi
[20:22:01] <fuzzie> strange though
[20:22:44] <fuzzie> since i don't see how it would ever work. maybe i miss something.
[20:22:54] <Maighstir> heh, and 3.4.5 fails again, didn't I test it throroughly just recently?
[20:25:07] <Maighstir> Scanning dependencies of target gemrb_core
[20:25:07] <Maighstir> [ 1%] Building CXX object gemrb/core/CMakeFiles/gemrb_core.dir/Actions.obj
[20:25:07] <Maighstir> K:\__gemrb\git\gemrb\gemrb\core\Actions.cpp: In static member function `static void GameScript::SaveGame(Scriptable*, Action*)':
[20:25:07] <Maighstir> K:\__gemrb\git\gemrb\gemrb\core\Actions.cpp:5474: warning: passing negative value `-0x000000001' for converting 1 of `virtual const char* TableMgr::QueryField(unsigned int, unsigned int) const'
[20:29:02] <fuzzie> and that's recent gemrb?
[20:29:15] <fuzzie> oh, right, tomprince broke it
[20:29:16] <Maighstir> yes
[20:29:18] * fuzzie tips tomprince
[20:29:49] <Maighstir> not more than 10 minutes ago
[20:29:53] <fuzzie> add the '(unsigned int)' back, so it's '(unsigned int) -1')
[20:30:23] <lynxlynxlynx> the buildbot detected it too
[20:30:37] <fuzzie> but that is just a warning, it shouldn't break your compile, and that change is a week old, no?
[20:31:14] --> tomprince has joined #GemRb
[20:31:48] <Maighstir> I just pulled the source and compiled. Building into a clean directory, it breaks and quits just after those lines.
[20:32:01] <Maighstir> gcc4.5.0 works, gcc3.4.5 doesn't
[20:33:33] <Maighstir> yup, adding unsigned kicks it alive again
[20:33:54] <lynxlynxlynx> clang also issues a warning in the bikplayer code
[20:34:13] <fuzzie> yes, but i couldn't work out quite what was the right fix there
[20:34:20] <fuzzie> the ffmpeg people fixed it by rewriting the entire function
[20:34:31] <lynxlynxlynx> heh
[20:34:47] <pupnik> can we ignore gcc 3.4.x?
[20:35:38] <fuzzie> it's more about whether we can assume gcc 4.x, and the answer is not quite yet
[20:35:58] <wjp> can't we just remove the -Werror on 3.4.x then?
[20:36:20] <wjp> if it would take heroic measures to get rid of the warnings on all gcc versions, I mean
[20:36:49] <fuzzie> that would be my preferred option :-) but i'm not quite sure
[20:36:59] <fuzzie> eg, that stupid -Wcast-align causes huge numbers of warnings
[20:37:08] <fuzzie> but it did catch one bad line of code
[20:37:45] <pupnik> this is very educational to watch
[20:38:02] <fuzzie> so what i really want is a "just display the warnings which aren't stupid, and error on those" option
[20:38:11] <fuzzie> i assume it is the manpage under 'mindreading'
[20:38:13] <wjp> hehe
[20:38:22] <wjp> -WDWIW
[20:38:33] <-- tomprince has left IRC (Ping timeout: 265 seconds)
[20:38:44] <fuzzie> exactly! someone go fix that up :)
[20:38:57] <Maighstir> unfortunately, AI technology isn't really there, yet, and even if it were it would be up to humans to fix errors in the AI :-P
[20:40:17] --> tomprince has joined #GemRb
[20:44:50] <-- tomprince has left IRC (Ping timeout: 265 seconds)
[20:52:04] <Lightkey> oh w00t, Eschalon: Book II got released
[20:59:51] <Maighstir> can I temporarily disable -Werror?
[21:00:10] <lynxlynxlynx> of course
[21:00:25] <wjp> Lightkey: I just downloaded the demo, but it looks like I have to update libstdc++ and glibc first...
[21:00:32] <wjp> (so doing that now...)
[21:00:50] * wjp hopes they made walking around less tedious :-)
[21:00:51] <Maighstir> wrong question, should be "how can I ..."
[21:01:41] <lynxlynxlynx> for the build system, tom already told you, but you can probably just append -Wno-error to CXXFLAGS
[21:02:16] <Maighstir> -Wno-error then, thanks
[21:02:19] <Lightkey> wjp: what are you using? RHEL 5.4?
[21:03:31] <wjp> updating to 5.5 now
[21:04:05] <Lightkey> OMG
[21:04:13] <Lightkey> I was just joking!
[21:04:20] <wjp> centos actually
[21:04:51] <wjp> :-)
[21:04:56] <pupnik> i must try eschalon, thanks
[21:09:07] <lynxlynxlynx> Lightkey: what kind of link are you on?
[21:10:15] <wjp> hm, still no luck with 5.5. Ah well, will try it later when I'm back behind my 'real' PC. (On laptop now)
[21:11:11] <Lightkey> lynxlynxlynx: scusi?
[21:12:49] <lynxlynxlynx> la tua connessione
[21:14:10] <Lightkey> erm.. why?
[21:14:47] <lynxlynxlynx> just wondering, since i forgot
[21:15:43] <Lightkey> riiiight, next you will ask for my credit card data, since you forgot - no chance :-P
[21:16:58] <lynxlynxlynx> :)
[21:19:24] <Lightkey> ah well, it is 6000/640 I think, can not get anything faster so high above the city
[21:19:51] <Lightkey> or actually 6140 down!!1
[21:21:57] --> Dark-Star|Away has joined #GemRb
[21:21:57] --- ChanServ gives channel operator status to Dark-Star|Away
[21:25:04] --- Dark-Star|Away is now known as Dark-Star
[22:27:26] <-- kettuz has left IRC (Remote host closed the connection)
[22:29:56] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:01:19] <-- Maighstir has left #GemRb
[23:07:14] --> Gekz has joined #GemRb
[23:26:06] <-- Dark-Star has left IRC ()
[23:34:56] <Lightkey> edheldil: funneh how similar the result is to our first nation-wide election, 0.80 %, 11th place of 27 to 0.87 % 11th place of 32 ;-)
[23:38:50] --> tomprince has joined #GemRb
[23:48:59] <Gekz> ?
[23:49:55] <tomprince> ?
[23:50:18] <Gekz> ?
[23:50:49] <tomprince> ?!?
[23:50:52] <tomprince> :)
[23:55:13] <-- Gekz has left IRC (Quit: This computer has gone to sleep)