#gemrb@irc.freenode.net logs for 25 Mar 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:01:06] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[00:24:16] <-- fireglow has left IRC (*.net *.split)
[00:24:16] <-- DrMcCoy has left IRC (*.net *.split)
[00:25:32] --- ermo is now known as ermo^
[00:39:30] --> DrMcCoy has joined #gemrb
[00:42:32] --> fireglow has joined #gemrb
[00:43:11] --> 52AAARJOU has joined #gemrb
[00:43:11] --> 52AAAPFH7 has joined #gemrb
[00:43:14] <-- 52AAAPFH7 has left IRC (Remote host closed the connection)
[00:43:14] <-- 52AAARJOU has left IRC (Read error: Connection timed out)
[01:14:37] <-- Maighstir has left IRC (Quit: .)
[05:45:07] --> GoGi_ has joined #gemrb
[05:46:22] <-- GoGi has left IRC (Ping timeout: 245 seconds)
[08:00:12] --- Pepelka16 is now known as Seniorita
[08:02:34] --> lynxlynxlynx has joined #gemrb
[08:02:34] <-- lynxlynxlynx has left IRC (Changing host)
[08:02:34] --> lynxlynxlynx has joined #gemrb
[08:02:34] --- ChanServ gives channel operator status to lynxlynxlynx
[08:10:58] --> edheldil has joined #gemrb
[08:10:58] --- ChanServ gives channel operator status to edheldil
[08:37:09] --> lynxlynxlynx_ has joined #gemrb
[08:39:57] <-- edheldil has left IRC (Ping timeout: 248 seconds)
[08:39:58] --> edheldil has joined #gemrb
[08:39:58] --- ChanServ gives channel operator status to edheldil
[08:40:21] <-- edheldil has left IRC (*.net *.split)
[08:40:26] <-- lynxlynxlynx has left IRC (*.net *.split)
[08:44:20] --> edheldil has joined #gemrb
[08:57:05] <-- edheldil has left IRC (*.net *.split)
[08:57:23] --> edheldil has joined #gemrb
[08:57:23] --- ChanServ gives channel operator status to edheldil
[09:17:33] --> WingedHussar has joined #gemrb
[11:17:38] <-- WingedHussar has left IRC (Ping timeout: 245 seconds)
[11:18:54] --> WingedHussar has joined #gemrb
[11:53:43] --> fizzle has joined #gemrb
[12:41:45] <fizzle> the problem with tamah vanishing also happens with the petrified party in felonius gist's mansion
[13:14:59] <lynxlynxlynx_> did it happen before your changes too? last i remember familiars are still broken by them
[13:17:01] <fizzle> obviously not
[13:17:22] <fizzle> before my changes, no monsters were ever deleted
[13:17:46] <fizzle> the reason is pretty obvious
[13:18:24] <fizzle> all dead characters (that includes petrified) that don't have KEEP_BODY set on them are removed when leaving the map
[13:19:06] <fizzle> familiars are a different story, I believe
[13:19:52] <fizzle> not sure whether petrified actors should simply be exempted from that check
[13:19:57] <fuzzie> no
[13:20:16] <fuzzie> there seems a disappointing lack of notes on how corpses work, i'm sure someone worked it out
[13:21:43] <fuzzie> you have tamah's area resref?
[13:22:09] <fizzle> ar3500
[13:22:56] <fizzle> felonius gist is ar0719
[13:23:51] <fuzzie> so
[13:23:54] <fuzzie> it has no-removal set
[13:24:01] <fuzzie> do we jsut ignore that?
[13:24:25] <fuzzie> no we don't
[13:24:42] <fuzzie> just I guess your new code doesn't check whether you should remove corpses?
[13:25:05] <fizzle> the new code is in DeleteActor
[13:25:13] <fizzle> the check's before that
[13:25:20] <fuzzie> right, but what calls that?
[13:25:28] <fizzle> PurgeArea
[13:25:30] <fuzzie> right
[13:25:42] <fuzzie> it shouldn't be called for any non-temporary actors
[13:25:49] <fuzzie> i mean, from there
[13:26:23] <fuzzie> actors have a field called 'RemovalTime' which tells you when to remove them, anyway
[13:26:27] <fuzzie> if it's -1, don't remove
[13:26:52] <fuzzie> if you check that then it should fix your petrified party bugs at least :)
[13:27:09] <fizzle> when I debugged Tamah, she did not have MC_KEEP_CORPSE set
[13:27:11] <fuzzie> we don't seem to *set* RemovalTime on death, but that is a different story
[13:27:25] <fuzzie> yes, MC_KEEP_CORPSE is something else entirely
[13:27:46] <fuzzie> can you add the check and see if it fixes your problems?
[13:27:49] <fizzle> what is the no-removal you mentioned?
[13:27:50] <fuzzie> I can't try it myself from here.
[13:27:58] <fuzzie> 14:26 <fuzzie> actors have a field called 'RemovalTime' which tells you when to remove them, anyway
[13:28:01] <fuzzie> 14:26 <fuzzie> if it's -1, don't remove
[13:28:04] <fuzzie> ^-
[13:28:13] <fizzle> ah, okay, no flag
[13:28:33] <fuzzie> no, sorry, just the field
[13:28:46] <fuzzie> the idea is that corpses should stay around for a while, and only vanish after some time
[13:29:03] <fuzzie> i guess this field also shows up in NI?
[13:29:13] <fizzle> lemme check
[13:29:15] <fuzzie> i didn't know what to tell you to look for, here I just used ielister
[13:29:32] <fuzzie> doesn't matter anyway. hopefully the above fixes it.
[13:29:46] <fuzzie> if not then I can take a more serious look.
[13:32:18] <fuzzie> although, oh, DeleteActor is called for loads of actors
[13:33:34] <fuzzie> hopefully shouldn't be a problem though
[13:38:38] <fizzle> if we never set RemovalTime then we're back to never deleting anything, right?
[13:38:39] <fuzzie> lynxlynxlynx_: i think the familiars thing is something else
[13:38:59] <fuzzie> fizzle: well, it's set in the area files for some actors
[13:39:10] <fuzzie> but i think we're meant to change it on death to a sensible value
[13:39:17] <fuzzie> otherwise it makes no sense
[13:39:30] <fizzle> yeah, spawns etc. won't get it otherwise
[13:39:43] <fuzzie> well, i think spawns should get removed anyway
[13:40:01] <fuzzie> if I remember this right, which I might not
[13:40:13] <fuzzie> maybe I'm thinking of summons
[13:40:13] <fizzle> new actors always have the field set to -1
[13:40:33] <fuzzie> sorry, i mean, in theory :P
[13:40:45] <fizzle> summons get assigned an unsummon effect, yes
[13:40:56] <fuzzie> yes, but they shouldn't get saved
[13:41:00] <fuzzie> is what I mean
[13:41:08] <fuzzie> but it doesn't matter, I'm going off on a tangent
[13:41:17] <fuzzie> I was thinking, first, check RemovalTime, make sure it fixes your issue :P
[13:41:21] <fizzle> okay, so in theory, what would a sensible value for RemovalTime be?
[13:41:28] <fuzzie> I don't know!
[13:41:46] <fizzle> \o/ :P
[13:42:09] <fuzzie> this is obviously the fault of whoever added the RemovalTime code
[13:42:50] <fuzzie> and git is blaming me
[13:42:51] <fizzle> well, there is no removal time code...
[13:43:01] <fuzzie> well, there is
[13:43:07] <fuzzie> it's saved and loaded and set to -1 at startup :)
[13:43:33] <fizzle> that's epic
[13:43:43] <fuzzie> better than ignoring it entirely ;)
[13:44:11] <fizzle> touché
[13:45:01] <fuzzie> gemrb used to do that a lot
[13:45:13] <fuzzie> which corrupted all the savegames forever, since the data was permanently lost
[13:46:10] <fuzzie> i don't see where this gets set
[13:46:21] <fuzzie> in original, the death opcode sets it to GameTime if MC_NO_CORPSE is set
[13:46:43] <fuzzie> which makes sense
[13:47:48] <fuzzie> well, also if not persistent, but that's implied i guess
[13:47:51] <fizzle> okay, so if I just check for RemovalTime != -1 in PurgeArea, that fixes it
[13:48:49] <fuzzie> so that's good, even if your other objection is quite correct
[13:49:36] <fuzzie> doesn't look like I have any more clue than you about what a good value for RemovalTime is.
[13:51:53] <fuzzie> i would guess GameTime + a few days.
[13:52:18] <fizzle> it's probably good enough if we set it to game time on CheckOnDeath for now?
[13:52:27] <fuzzie> yes, but please don't :P
[13:52:35] <fuzzie> because really that should remove the corpse
[13:53:11] <fuzzie> so it should at least have some time period added to it, to avoid us going mad in the future
[13:53:25] <fuzzie> other than that I don't mind as long as (obviously) there's a TODO comment
[13:54:55] <fuzzie> but i think CheckOnDeath is the right place: set it to GameTime on NO_CORPSE, set it to GameTime+<some_value> if it's not KEEP_CORPSE..?
[13:55:33] <fizzle> what about Chunking? Game time, too?
[13:56:40] <fuzzie> no
[13:56:49] <fuzzie> chunked actors actually stay around
[13:56:59] <fuzzie> yet another thing we don't implement right atm :/
[13:57:20] <fuzzie> we're meant to just replace their anim with a chunked one
[13:58:03] <fuzzie> in any case it doesn't matter since right now DeleteActor is called immediately when chunking.
[13:58:07] <fuzzie> so do what you want.
[13:58:18] <fuzzie> just I mean at some point hopefully one of us will deal with all that too.
[14:10:36] <fizzle> hm
[14:20:02] <fizzle> http://paste.debian.net/hidden/d4dc179e/ ?
[14:20:07] <Seniorita> Debian Pastezone
[14:25:47] <fuzzie> something like that :)
[14:28:18] <fuzzie> as I said I don't know any better than you about good values so..
[14:28:25] <fuzzie> if it works better than the existing code, do it
[14:29:51] <fizzle> alright, thanks for taking a look
[14:57:24] <Seniorita> [commit] Jens Granseuer: honour removal time when deleting actors http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=738310a9659a255e78a22595e527eb913f4db4f1
[15:03:49] <fuzzie> fizzle: thanks for the work!
[16:03:42] <-- WingedHussar has left IRC (Quit: WingedHussar)
[16:33:20] --> nutron has joined #gemrb
[17:19:55] --> traveler__ has joined #gemrb
[17:20:00] <traveler__> hi lynx
[17:20:09] <traveler__> how was brage's problems solved?
[17:20:23] <traveler__> or just couldn't replicate?
[17:21:21] <lynxlynxlynx_> fizzle fixed it
[17:22:17] <lynxlynxlynx_> it's likely the same thing that caused imoen to stick in the promenade sometimes
[17:22:20] <traveler__> oh ok, i just couldn't see related log
[17:25:08] <traveler__> still wondering what's exactly breaking my clang build. its like it doesn't see libstdc++ when linking to my ignorant eyes
[17:25:34] --> Maighstir has joined #gemrb
[17:27:07] <traveler__> and really, really clang is here 100% c++ functional
[17:27:20] <traveler__> boost etc not to mention clang itself builds just fine
[17:27:43] <traveler__> like something subtle changed in linking stages
[17:29:09] <traveler__> http://pastebin.com/BRk18Wfi for reference
[17:29:13] <Seniorita> [ 62%] Building CXX object gemrb/core/CMakeFiles/gemrb_core.dir/System/Logger/Fi - Pastebin.com
[17:29:43] <fuzzie> yes, it does look exactly like it's not finding libstdc++
[17:30:00] <fuzzie> maybe cmake isn't invoking your compiler right? but I have no clue
[17:30:05] <traveler__> the question is
[17:30:16] <lynxlynxlynx_> you can use make VERBOSE=yesplease
[17:30:26] <lynxlynxlynx_> it will give you the exact command line it ran
[17:30:31] <traveler__> are linking settings persistent between various tree revision? that could explain why i couldn bisect it
[17:30:40] <traveler__> will do
[17:36:08] <traveler__> now i see that cmake_link_script is reponsible for linking
[17:36:12] <traveler__> any changes there recently?
[17:40:38] <-- fizzle has left #gemrb
[17:43:46] <lynxlynxlynx_> that's not ours
[17:44:21] <traveler__> Linking CXX executable gemrb cd /home/Kuba/GemRBGit/gemrb/build/gemrb && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/gemrb.dir/link.txt --verbose=yesplease
[17:44:35] <traveler__> i think i've found something relevant
[17:45:00] <traveler__> namely flags.make
[17:45:16] <traveler__> there is -I/usr/local/include for CXX
[17:45:48] <traveler__> but for libstdc++ you need to look under /usr/lib/
[17:46:22] <lynxlynxlynx_> you mean /usr/include
[17:46:59] <traveler__> i mean /usr/lib actually
[17:47:31] <traveler__> speaking of libstdc++
[17:52:07] --> brada has joined #gemrb
[17:54:32] <traveler__> usuall headers are in /usr/local/include/ true, but i didn't found anything in flags.cmake where it would explicitly look for libstdc++
[17:56:33] --> rocket_hamster has joined #gemrb
[18:01:40] <traveler__> later, i will take it from there another time
[18:05:53] <-- traveler__ has left IRC (Ping timeout: 245 seconds)
[18:44:04] --> Yoshimo has joined #gemrb
[19:49:53] <-- rocket_hamster has left IRC (Remote host closed the connection)
[20:40:58] <-- Maighstir has left IRC (Ping timeout: 245 seconds)
[20:55:52] --> Maighstir has joined #gemrb
[21:03:30] <-- Yoshimo has left IRC (Quit: Yoshimo)
[22:10:35] <-- brada has left IRC (Quit: brada)
[22:32:04] <-- Maighstir has left IRC (Quit: .)
[23:34:10] <-- lynxlynxlynx_ has left IRC (Remote host closed the connection)