#gemrb@irc.freenode.net logs for 7 May 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:00:51] <-- barra_home has left IRC (Quit: Verlassend)
[02:18:50] <-- DrMcCoy has left IRC (Ping timeout: 276 seconds)
[02:27:16] --> DrMcCoy has joined #gemrb
[02:45:55] --> mihairu has joined #gemrb
[04:55:32] --> raevol has joined #gemrb
[05:01:48] <-- PixelScum has left IRC (Read error: Connection reset by peer)
[05:02:19] --> PixelScum has joined #gemrb
[05:31:40] <-- raevol has left IRC (Quit: Leaving.)
[05:35:02] --> raevol has joined #gemrb
[08:35:35] <-- raevol has left IRC (Quit: Leaving.)
[08:49:55] <-- mihairu has left IRC (Ping timeout: 260 seconds)
[09:25:55] --> mihairu has joined #gemrb
[09:27:29] <dhewg> so uhm
[09:27:52] <dhewg> the whole template stuff died i guess?
[09:28:04] <fuzzie> which stuff?
[09:28:46] <dhewg> the hashmap template proposal to unify all variations?
[09:28:56] <fuzzie> oh
[09:29:00] <fuzzie> i haven't had time to look at it, myself
[09:30:01] <dhewg> its funny to watch
[09:30:14] <dhewg> i mean, when enabling its debug spew
[09:30:34] <dhewg> it kinda illustrates my point that caching more than one bif makes sense :)
[09:31:31] <fuzzie> yeah, it just needs someone to sit down and work out a plan for that
[09:31:41] <fuzzie> rather than being fuzzie and adding broken hacks at random :P
[09:31:49] <dhewg> well
[09:31:55] <dhewg> im motivated to do that
[09:32:15] <dhewg> but for that paticular issue i would whip up a templated MRU list
[09:32:30] <dhewg> it just makes more sense to me
[09:32:41] <fuzzie> i mean, the difficult bit is making sure to release the bifs at the relevant points
[09:33:27] <dhewg> right now generated streams out of bifs have their own fd
[09:33:46] <fuzzie> only if they're >16k, though?
[09:33:54] <dhewg> destroying a bif while streams are open shouldnt be a problem, right?
[09:34:20] <dhewg> hm, have to recheck, but afair its read into mem in one go
[09:34:25] <fuzzie> the trouble is, fseek() is expensive
[09:34:27] <fuzzie> really expensive
[09:34:41] <fuzzie> so trying to share streams is really tricky
[09:35:20] <dhewg> i didnt mean come up with a solution to share fds
[09:35:32] <dhewg> right now you cache the last used bif
[09:35:38] <fuzzie> yes
[09:35:39] <dhewg> just extend that to whatever
[09:35:41] <dhewg> 8 or so
[09:35:42] <fuzzie> but that's a hack
[09:35:54] <fuzzie> because it never closes the bif
[09:36:05] --> Bo_Thomsen has joined #gemrb
[09:36:37] <dhewg> i think only when destroying the keyimporter
[09:36:50] <fuzzie> atm, any open bif is force-closed when something out of another bif is requested, which sort of vaguely hides my hack
[09:37:56] <fuzzie> but something more intelligent is needed beyond a single bif
[09:38:22] <fuzzie> and i am rather hoping that if we do that, we can just keep *all* the core BIFs open anyway
[09:39:05] <dhewg> how do you distinct between core and not core?
[09:39:19] <fuzzie> for our purposes, i guess 'not compressed'
[09:39:31] <dhewg> i mean, with area chaning in mind, i MRU list may make sense, no?
[09:39:40] <fuzzie> then you can have an MRU for the compressed BIFs, and make it cooperate with the cache code
[09:40:33] <dhewg> ah, you mean do a more centralizes MRU list instead of one in the keyimporter?
[09:40:49] <dhewg> like an archive container cache?
[09:40:54] <fuzzie> well, one in the KEYImporter seems reasonable enough :P
[09:40:58] <fuzzie> i don't really care where it goes
[09:41:10] <dhewg> okay
[09:41:23] <dhewg> well, but thats independent of the hash stuff
[09:41:29] <fuzzie> yes
[09:41:42] <dhewg> so, go look! :P
[09:41:58] <fuzzie> but by 'core' i mean the stuff which is shared amongst pretty much the entire game, anyway
[09:42:07] <dhewg> i mean, you guys seem to shy away from templates
[09:42:21] <dhewg> if there's no chance it gets in, its pointless to work on it
[09:42:24] <fuzzie> i'm not sure we do
[09:42:31] <fuzzie> i mean, aren't you replacing a std::map<> here?
[09:42:45] <dhewg> for the cacheddirimporter, yes
[09:43:01] <dhewg> and i use it for the bifs instead of a plain array
[09:43:07] <fuzzie> so seems like a simple hashmap is a win
[09:43:24] <dhewg> and now it replaced the dictionary in the keyimporter
[09:43:33] <dhewg> it can replace the variables stuff too
[09:43:39] <dhewg> and the spell/store/item caches
[09:43:41] <tomprince> https://github.com/tomprince/gemrb/commit/lru-cache
[09:44:24] <fuzzie> a generic lru-cache like that needs more thought on my part
[09:44:43] <tomprince> Certainly. Just code that I had lying around.
[09:44:49] <dhewg> imho templating that makes totally sense
[09:45:08] <fuzzie> well, the store cache is a bit more complicated
[09:45:38] <dhewg> yes, but thats very specific now
[09:46:23] <fuzzie> since the stores are mutable
[09:49:04] <fuzzie> but i like anything which makes things simpler
[09:49:26] <fuzzie> 'simpler' being one of those tricky balancing-act concepts, of course
[09:51:34] <fuzzie> also why no 'cache[buf] = name;'?
[09:52:28] <tomprince> is that directed at me?
[09:52:37] <fuzzie> not at all
[09:52:47] <dhewg> me then?
[09:53:08] <fuzzie> yes!
[09:54:12] <fuzzie> seems like you could replace std::string* with 'const std::string &' too, but i saw something about this in backscroll, not possibl?
[09:54:15] <dhewg> dunno, while operator overloading is easy i expected "ugh c++ crap" as answer to it?
[09:54:43] <dhewg> and the set() returns a bool too
[09:55:03] <dhewg> which is useful to distinct between replace and insert
[09:55:07] <tomprince> I got away with a smart pointer ...
[09:55:08] <dhewg> with just one lookup
[09:55:16] <fuzzie> I personally am happy with anything that isn't horrendeously slow, doesn't pull in external dependencies, and is obvious to non-C++-experienced people.
[09:55:21] <dhewg> well right now NULL means not-there
[09:55:43] <dhewg> i guess it could be const Value *
[09:55:52] <fuzzie> The smart pointer fails the latter in some usages, honestly, but tomprince has stuck around for the long haul and maintained the relevant code.
[09:55:53] <dhewg> didnt check all instances
[09:56:57] <dhewg> if you aim for references, you need more template voodoo to distinct empty and not empty
[09:56:59] <fuzzie> But 'some_map[key] = value;' doesn't seem spectacularly difficult to read.
[09:58:05] <tomprince> I think a *little* template voodoo is fine, so long as it doesn't leak, and works with msvc6.
[09:58:22] <dhewg> fuzzie: not at all, but i think the set return value is used atm in all instances
[09:58:42] <fuzzie> I think a lot of template voodoo is fine, as long as it's not sekritly doing stuff.
[09:59:11] <fuzzie> The HashMap looks rather nice at a glance, anyway.
[10:00:27] <dhewg> i think so too
[10:00:40] <dhewg> the only thing i dont like is the TODO in the keyimporter
[10:01:14] <dhewg> the only way i can think of to solve that is to reintroduce a hash function argument again
[10:01:58] <fuzzie> That might be clearer anwyay. :P
[10:02:04] <fuzzie> But will ponder it later, bbiab.
[10:02:12] <tomprince> Another solution would to allow other types as hash arguments. But that might require member templates, which msvc doesn't support.
[10:02:44] <tomprince> Or perhaps have the hashkey actualy store the hash, and write a conversion function.
[10:06:34] <fuzzie> This is what I mean by overengineering. :P
[10:07:00] <tomprince> :)
[10:07:37] <dhewg> i would use a hash function argument, which is the seed value for the keyimporter
[10:07:45] <fuzzie> I can just about understand "hashmap template which takes key+value types and hash function" before my coffee, adding member templates starts requiring coffee.
[10:07:53] <dhewg> but that was the solution my the patches from last week or so
[10:08:07] <dhewg> which you didnt like :P
[10:08:24] <fuzzie> I didn't like the lack of buckets in whatever I saw last.
[10:08:44] <dhewg> well that was the map<> based thing
[10:09:05] <fuzzie> Haven't looked at anything since then.
[10:09:19] <dhewg> :P
[10:09:35] <fuzzie> Exam, etc.
[10:09:43] <tomprince> The better idea is to have HashKey actually be a HashKey.
[10:09:49] <dhewg> yeah, i know
[10:10:07] <dhewg> that was directed at fuzzie
[10:10:11] <dhewg> tomprince: what? :)
[10:10:22] <fuzzie> But this requires that I can't use an arbitary key, right?
[10:10:24] <dhewg> make the struct store the key itself?
[10:10:52] <fuzzie> imo HashKey<key, value, hashfunc> is an awful lot clearer than HashKey<special key type, value>.
[10:11:14] <fuzzie> dhewg: yes, see "Or perhaps have the hashkey actualy store the hash" above
[10:11:55] <dhewg> hm
[10:12:25] <dhewg> dunno if thats not so nice for the trivial keys there
[10:12:36] <dhewg> gotta run, be back in an hour or so
[10:12:57] <fuzzie> Are we using any of those?
[10:20:52] <tomprince> .... my idea can't handle collisions. :(
[10:21:20] <tomprince> not without member templates :p
[10:25:32] <fuzzie> Why not?
[10:26:28] <tomprince> Well, my idea was instead of passing in the key, (transparently) pass in the hash, that way you can have other types masquerade as keys.
[10:26:57] <fuzzie> Ah. Right. No equality operator on the underlying data.
[10:26:58] <tomprince> But you need to be able to get a real key back, to do the compairison of last resort.
[10:30:34] --> lynxlynxlynx has joined #gemrb
[10:30:34] <-- lynxlynxlynx has left IRC (Changing host)
[10:30:34] --> lynxlynxlynx has joined #gemrb
[10:30:35] --- ChanServ gives channel operator status to lynxlynxlynx
[10:39:08] <tomprince> although ... the problem is that for KEYImporter, the key is expensive to copy. Have a KeyRef type, that is a template argument of the hash, which defaults to the key, and can be compared by the HashKey object. But then specialize it for KEYImporter (and std::string/char[]) to just keep a reference, and only copy it if it escapes the scope of the function call.
[10:39:50] <fuzzie> I'm not sure it *is* so expensive to copy, it should just get memcpy()ed.
[10:39:53] <tomprince> (but I am just the local template overengineer ;))
[10:40:07] <fuzzie> But haven't thought about it.
[10:41:01] <tomprince> We probably do enough copying in PathJoin to hide the strcpy for the hash in KEYImporter in the noise in the noise.
[10:41:26] <tomprince> Still, interesting to figure out a solution, even if it is only academic.
[10:41:44] <fuzzie> I think the only expensive strncpy() in-tree is in your new Create() code, but I forget.
[10:42:26] <fuzzie> (Obviously it's irrelevant there.)
[10:43:35] <tomprince> That is an annoying behaviour.
[10:47:17] <tomprince> I was going to suggest replacing it it with PathJoin, but I just noticed/remembered that all of our path functions are subject to buffer overruns.
[11:24:31] <dhewg> the other thing i wonder about is why does ResourceSource take a char* instead of ieResRef?
[11:25:55] <fuzzie> tomprince used it for other things, like MUSImporter
[11:26:51] <dhewg> the thing is, i really try to keep ieResRef for the keyimporter, so that the char[] is part of a hash "Entry"
[11:27:24] <dhewg> but how do you feed a char* to the hashmap to compare against it?
[11:27:29] <dhewg> in a sane way, that is
[11:28:00] <dhewg> right now i hide that in the strncpy function that takes a char* because of that issue
[11:29:13] <dhewg> and there's always the alternative route to use one hashmap per keyimporter "type"
[11:29:23] <dhewg> but im not so sure if thats a good idea
[11:30:05] <fuzzie> how would you do the lookup from type to hashmap?
[11:30:43] <dhewg> since its not a simple sequence of consecutive numbers, it has to be another map
[11:30:53] <dhewg> thats why i tend more to "no" :)
[11:34:02] <dhewg> right now the keyimporter hashmap is the only one with lots of collitions
[11:34:13] <dhewg> the bucket lenghts are all ok
[11:34:25] <dhewg> most are <4
[11:34:38] <dhewg> multiple maps would likely help there
[11:34:49] <fuzzie> well, you'd have to have a bucket length greater than 16 or something to do worse than hashes in a tree
[11:34:50] <dhewg> but with another map on top, i dunno if thats better overall
[11:35:35] <dhewg> i think the largest ive seen was 9
[11:36:00] <fuzzie> but i imagine we can poke at the hash functions to see if they can be improved
[11:36:09] <fuzzie> another reason i think passing a hash function as a parameter seems smarter
[11:37:16] <dhewg> instead of the struct there?
[11:38:10] <fuzzie> yeah
[11:38:36] <dhewg> then we need a parm for an equal func too
[11:38:48] <dhewg> and copy :P
[11:38:56] <fuzzie> just use the key type
[11:39:27] <dhewg> for comparing?
[11:39:31] <fuzzie> for both
[11:39:47] <dhewg> ieResRef = ieResRef?
[11:40:19] <fuzzie> where is there a hashmap using that?
[11:40:41] <dhewg> the equals calls
[11:40:47] <fuzzie> i mean, using ieResRef
[11:41:03] <dhewg> right now only in the keyimporter
[11:41:12] <fuzzie> i don't see it there?
[11:41:18] <dhewg> but its that special case again
[11:41:22] <dhewg> because of the type
[11:41:25] <fuzzie> i mean, it seems like you're using the MapKey struct
[11:41:36] <dhewg> there's a ieResRef-only implementation is StringMap.h
[11:41:40] <fuzzie> so you can just give the struct a custom equals operator and a copy constructor
[11:41:50] <fuzzie> and the StringMap one, plus all the basic type stuff, seems unused
[11:42:14] <fuzzie> and if we can get away with something simpler, i like simple.
[11:42:17] <dhewg> the std::string StringMap is used in CachedDirectoryImporter
[11:42:35] <fuzzie> but again, std::string has an equals operator and a copy constructor, right?
[11:42:37] <dhewg> yeah i know, but the ieResRef only thing was for Variables.cpp
[11:42:41] <fuzzie> so you're left with just the Variables problem
[11:43:02] <fuzzie> sure would be great if std::string didn't suck
[11:43:26] <dhewg> well its ok for the directory thing
[11:43:37] <dhewg> its not too many entries
[11:43:45] <fuzzie> not exactly ideal, though
[11:43:48] <dhewg> using std::string for the keyimporter would seriously suck
[11:43:55] <fuzzie> since it's going to be allocing on the heap every time it looks for something
[11:44:21] <fuzzie> well, assuming you're using libstdc++/etc
[11:44:25] <dhewg> that would be solvable if ResourceSource takes a ieResRef
[11:44:33] <dhewg> which it doesnt :)
[11:44:40] <fuzzie> it wouldn't be, i think?
[11:44:57] <fuzzie> oh, you mean for the keyimporter
[11:45:04] <fuzzie> i am still grumping about the directory thing
[11:45:14] <dhewg> no, that too
[11:45:23] <dhewg> i was still talking about the dir thing
[11:45:23] <fuzzie> which needs to be able to add an extension
[11:45:43] <dhewg> ah right
[11:46:12] <dhewg> well one could use char[MAXPATH] which obviously would not be optimal too
[11:46:24] <fuzzie> certainly you can't use strncpy then :P
[11:47:21] <fuzzie> worst C library function ever, really
[11:47:39] <dhewg> hehe
[11:47:45] <dhewg> one derivate is worse
[11:47:50] <dhewg> that safe crap from MS
[11:48:34] <dhewg> anyway, im all ears to make that more bettah
[11:48:48] <dhewg> but i dont have the ultimate solution for this yet
[11:51:33] --> Dark-Star has joined #gemrb
[11:51:33] --- ChanServ gives channel operator status to Dark-Star
[11:59:01] <dhewg> the ai scripts of party members dont work all the time with the backstabbing murderers after the final spellhold fight
[11:59:35] <dhewg> the bad dude is right next to it, and it doesnt act at all
[12:03:49] <fuzzie> not invis? which ai script is set?
[12:04:02] <dhewg> minsc's default thing
[12:04:16] <dhewg> well, i bet its related to invis
[12:04:59] <fuzzie> i can only look atm if i have a name :p
[12:05:31] <dhewg> Debugdump of Actor Minsc (Minsc, Minsc):
[12:05:31] <dhewg> Scripts: minsc <none> <none> <none> default <none> <none> dplayer2
[12:05:34] <dhewg> that?
[12:06:14] <fuzzie> IF
[12:06:14] <fuzzie> InWeaponRange(NearestEnemyOf(Myself))
[12:06:14] <fuzzie> THEN
[12:06:16] <fuzzie> AttackOneRound(NearestEnemyOf(Myself))
[12:06:18] <fuzzie> END
[12:07:00] <dhewg> is that nearest thing related to that cansee thing?
[12:08:46] <fuzzie> no
[12:09:45] <dhewg> hm
[12:10:11] <dhewg> back to the yoshi situation, i get alot of this when loading a savegame in that area: [ResourceManager]: Searching for .bcs...[ERROR]
[12:10:22] <fuzzie> well stick to one thing :P
[12:10:32] <fuzzie> i wrote the NearestEnemyOf stuff
[12:10:40] <dhewg> they're all in that one spot :P
[12:10:43] <fuzzie> it uses the function DoObjectChecks in GameScript/Matching.cpp
[12:10:51] <fuzzie> with ignoreinvis = false
[12:12:28] <fuzzie> no idea if it's correct but it matches observed behaviour
[12:12:47] <fuzzie> but could be that it passes the check but the action fails
[12:12:48] <dhewg> it works most of the time, just not always to make matters worse
[12:20:13] <dhewg> why is yoshi in that situation unable to move :\
[12:20:52] <fuzzie> bad script on yoshi?
[12:21:07] <dhewg> i dunno
[12:21:31] <dhewg> if i cast dispel invis in that room, i do get the funky effects at the spot where he is standing
[12:21:41] <dhewg> just that it doesnt purge invis on him
[12:22:01] <dhewg> and if i enter that room, i see him facing the wall for a few frames
[12:22:16] <dhewg> i think he then wants to come over to me and start a dialog
[12:22:25] <dhewg> but he's stuck in the walking ani
[12:23:10] <fuzzie> can't ctrl-m?
[12:23:30] <dhewg> no, no related cursor
[12:23:35] <dhewg> attack doesnt work either
[12:23:43] <dhewg> but i think i found a way to cheat
[12:23:59] <dhewg> the cast target cursor is able to find him
[12:24:12] <dhewg> i get a tooltip, and ctrl+y works there
[12:24:35] <dhewg> as does ctrl+m
[12:24:36] <dhewg> Scripts: yoshimox
[12:25:32] <dhewg> dunno what that is 35: 0x6d: State:HoldNoIcon (0, 2) S:spin863
[12:25:46] <dhewg> 42: 0x113: HideInShadowsModifier (20, 0) S:
[12:25:55] <fuzzie> State:Hold is held
[12:25:57] <dhewg> 57: 0x14: State:Invisible (0, 0) S:spwi206
[12:26:15] <dhewg> just from the names, thats seems to be the related stuff
[12:26:20] <fuzzie> oh jesus, the HOLD_PARTY spell
[12:26:40] <dhewg> heh? :P
[12:26:58] <fuzzie> which lasts forever, deliberately
[12:27:33] <dhewg> thats the cause of the moving incapability?
[12:27:49] <fuzzie> Yoshimo got kicked out of your party before then, right?
[12:28:00] <dhewg> not by me
[12:28:26] <dhewg> as he was talken because of spellhold
[12:28:34] <fuzzie> he should be force-removed from your party just after you get teleported into the jar, the first time
[12:28:51] <dhewg> yes, thats what im talking about
[12:29:02] <fuzzie> just before that happens, he gets a NOHOLD_PARTY spell
[12:29:03] <dhewg> before that scene he was a party member for the whole game
[12:29:22] <fuzzie> and then is jumped into the cell
[12:29:28] <fuzzie> and it looks like that bit didn't take
[12:29:45] <dhewg> can i kill that one effect from his queue?
[12:29:55] <fuzzie> ctrl-r him
[12:30:02] <fuzzie> and zap the whole lot
[12:30:04] <fuzzie> but otherwise, no
[12:30:17] <dhewg> hah
[12:30:19] <dhewg> works
[12:30:28] <dhewg> but only with that spell icon exploit :P
[12:30:59] <dhewg> and alot of this after his death: [Actor]: Attack without valid target!
[12:31:38] <fuzzie> hmm, none of the rest of your party are held though?
[12:31:43] <dhewg> i also see some "spell caster level in/descreased" on him
[12:32:09] <dhewg> nope, slaying stuff just fine with 6 ppl
[12:32:19] <fuzzie> the NOHOLD_PARTY cures State:Hold and State:HoldNoIcon
[12:32:52] <dhewg> when you run into spellhold, after that tube scene
[12:33:01] <fuzzie> but it does it using ReallyForceSpell
[12:33:05] <dhewg> you get the maze thing with whats-her-name
[12:33:28] <dhewg> just when you regain control, you can only use the main char
[12:33:39] <dhewg> all others are stuck like yoshi is here, just without invis
[12:33:42] <dhewg> is that related?
[12:34:12] <fuzzie> but they're purple, right
[12:34:14] <fuzzie> ?
[12:34:17] <dhewg> yeah
[12:34:19] <fuzzie> and no held portrait icons?
[12:34:26] <dhewg> no
[12:34:36] <dhewg> if i save+load everything is fine again
[12:34:51] <dhewg> same thing when i turn into the slayer
[12:35:32] <fuzzie> yeah
[12:35:46] <fuzzie> i guess we should save unselectable state or something
[12:36:43] <fuzzie> my preliminary guess is that HOLD_PARTY followed immediately by NOHOLD_PARTY leads to effect queue fail
[12:37:18] <dhewg> what should i try?
[12:38:40] <fuzzie> i should prbly look at it
[12:39:03] <fuzzie> you could try breaking out of the cutscene just after this happens and checking if yoshimo is held
[12:39:11] <fuzzie> but it sounds annoying to examine
[13:03:49] <dhewg> i think i know why i couldnt purge invis on yoshi
[13:04:01] <dhewg> he still got the awesome equipment
[13:04:12] <dhewg> one is the cloak of non detection
[13:07:28] <fuzzie> resistances in the effect list?
[13:30:30] <dhewg> uhm
[13:30:55] <dhewg> http://pastie.org/1874854
[13:31:11] <dhewg> thats before i enter his room
[13:31:15] <dhewg> not yet invisible
[13:33:15] <fuzzie> Um.
[13:34:21] <fuzzie> that doesn't look good
[13:35:32] <fuzzie> how did you get the debug output?
[13:35:44] <dhewg> ctrl+m?
[13:35:49] <fuzzie> on yoshimo?
[13:35:53] <dhewg> yeah
[13:36:03] <fuzzie> i ask because Variable:StoreLocalVariable should never be present
[13:36:06] <dhewg> you can do that all over the map without any party member able to see him :P
[13:36:46] <dhewg> i dunno where that comes from
[13:37:42] <dhewg> just before the jon scene: http://pastie.org/1874873
[13:37:47] <fuzzie> it means that his effect queue isn't being processed
[13:38:02] <dhewg> obviously i didnt have him under control between those two dumps
[13:38:20] <fuzzie> timestop fail, maybe?
[13:38:35] <dhewg> i dunno?
[13:38:48] <dhewg> at least its the same map where that psycho elf casted that
[13:39:26] <fuzzie> that's very weird
[13:40:50] <fuzzie> the alternative is that yoshimo got disabled in some permanently sabotaging horrible manner
[13:41:50] <fuzzie> or, hm, badarea id?
[13:42:07] <fuzzie> *flail*
[13:42:34] <fuzzie> but it looks like Cleanup() isn't being called, which means either timestop fail (which should mean all your actors can't do anything) or deactivated
[13:42:38] <dhewg> no, the storelocal stuff is already there before timestop
[13:42:52] <dhewg> i can ctrl+m him in his locked cell before the fight
[13:43:12] <fuzzie> the thing is, if the local variables don't get removed, the hold isn't going to get removed either
[13:43:59] <fuzzie> but that shouldn't happen unless he's dead
[13:45:16] <fuzzie> there's the 'area mismatch' case and the 'inactive and unscheduled' case, afaict, but i imagine i'm missing the obvious
[13:48:27] <fuzzie> ugh
[13:48:36] <fuzzie> so maybe he is dead
[13:48:57] <fuzzie> who broke GetAllActorsInRadius?!
[13:48:59] <dhewg> how do i cancel a cutscene again?
[13:49:12] <dhewg> ctrl+space wise
[13:49:21] <fuzzie> i don't know, grep in GUIScript..
[13:49:49] <fuzzie> dammit, that is broken for forever
[13:49:54] <fuzzie> since late 2009
[13:50:18] <fuzzie> Avenger hacked Schedule() so it can check for invis, which is super wrong
[13:50:24] <fuzzie> oh
[13:50:34] <fuzzie> hm
[13:50:38] <fuzzie> it was broken before i guess
[13:51:30] <fuzzie> and maybe not super wrong, difficult to tell
[13:51:45] <fuzzie> it isn't checking for invis but a bunch of the callers are wrong
[13:51:48] <fuzzie> must remember to fix scheduling
[13:51:58] <fuzzie> also must remember to add more stuff to the actor debug dump so we can diagnose this stuff!
[13:51:59] <dhewg> there's no storelocal after he reveals himself
[13:52:18] <dhewg> im at the sequence where im in the tube
[13:52:22] <dhewg> well, before the tube :P
[13:52:23] <fuzzie> yeah
[13:52:28] <fuzzie> it only happens after a save+load i imagine
[13:52:40] <fuzzie> it is just a symptom
[13:53:09] <fuzzie> since they are a very obvious effect which will be removed on the first effect cleanup
[13:53:15] <fuzzie> it's confusing :)
[13:53:22] <fuzzie> and i imagine i have completely the wrong idea
[13:56:54] <-- Maighstir_ has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[14:07:16] --> Maighstir has joined #gemrb
[14:19:21] <dhewg> gah spellhold is spellhell
[14:19:33] <dhewg> the portal in ar1516 doesnt "work"
[14:25:16] <fuzzie> to the underdark?
[14:28:23] <-- mihairu has left IRC (Remote host closed the connection)
[14:29:33] <dhewg> yeah
[14:34:42] <fuzzie> and you do have the key? :P
[14:35:52] <dhewg> yeah, isnt that just for the door before the portal?
[14:36:02] <dhewg> i get the stairs icon on the portal
[14:36:17] <dhewg> if party members are behind, i also get the gather party spam
[14:36:31] <dhewg> just that nothing happens when clicking the portal
[14:40:36] <fuzzie> what's the script resref?
[14:41:06] <dhewg> Script: NONE
[14:41:37] <fuzzie> odd
[14:59:52] <dhewg> hm
[14:59:58] <dhewg> how2fix?
[15:00:23] <dhewg> is the stairs cursor even correct there?
[15:00:37] <dhewg> i think usually i got a use cursor on portals?
[15:02:52] <Gekz> yep
[15:02:58] <Gekz> use cursor, not stairs.
[15:07:57] <fuzzie> cursor is specified by the data
[15:12:56] <dhewg> thats all info i can provide: http://pastie.org/1875107
[15:13:08] <dhewg> no debug or error messages when trying to use it
[15:20:25] <fuzzie> well if it says 'fake'.. :P
[15:25:02] <dhewg> well.. yes, but... awwwwman!
[15:25:33] <dhewg> is that data correct?
[15:25:45] <fuzzie> it is not functioning data
[15:25:45] <dhewg> the output looks like some fields might be missing?
[15:25:48] <fuzzie> since there's no dest area
[15:27:20] <fuzzie> but i think that's why it's fake
[15:28:02] <fuzzie> yes, indeed
[15:28:05] <fuzzie> it is a fake region.
[15:31:08] <dhewg> any idea how its supposed to work?
[15:40:10] <fuzzie> it isn't
[15:40:18] <fuzzie> there's another region which is the correct one
[15:40:29] <fuzzie> there's a debug key for drawing region bounds which i guess might show you overlap issues?
[15:41:15] <fuzzie> i imagine that lynx and I probably never tried skipping past Saemon
[15:45:07] <dhewg> ctrl+4?
[15:45:19] <dhewg> there're 2 blue areas in front of the portal
[15:45:35] <dhewg> i get the stair cursor on one, nada on the other
[15:45:49] <fuzzie> click on the one you get nada on
[15:46:05] <fuzzie> i have no idea wtf though
[15:46:14] <dhewg> nope, nada again
[15:46:21] <dhewg> they just walk there
[15:46:24] <fuzzie> but there are two regions there
[15:46:28] <dhewg> yes
[15:46:33] <dhewg> they overlap slightly
[15:46:36] <fuzzie> one is FakeTran2100 which does nothing
[15:46:44] <fuzzie> and one is Movie04 which does the Underdark checks
[15:47:28] <dhewg> i cant see any movie04 anywhere
[15:47:48] <dhewg> ctrl-m on that thing prints the area info like on random other stuff
[15:48:10] <dhewg> so whats supposed to happen?
[15:48:18] <fuzzie> it's a stupid multi-use region
[15:48:20] <dhewg> that nada square is on front of the other
[15:48:29] <fuzzie> it's meant to trigger the cutscene when you walk into the nada square
[15:48:30] <dhewg> is it supposed to trigger anything when stepping on it?
[15:48:43] <dhewg> hm
[15:48:47] <fuzzie> it's *also* meant to do stuff when you click on it, but that stuff checks the magic rope, so clearly not for spellhold :P
[15:50:10] <dhewg> can i trigger whatever that pad is supposed to trigger manually?
[15:50:11] <fuzzie> unfortunately i don't really understand how this works
[15:50:49] <fuzzie> it is a ST_PROXIMITY, it seems ok
[15:51:59] <fuzzie> but the code there is v.flaky
[15:53:34] <dhewg> do you know whats supposed to be called when stepping on it?
[15:53:38] <dhewg> function wise
[15:54:29] <fuzzie> eventually, it should run cutscene movie04a
[15:54:51] <fuzzie> the code simply needs replacing
[16:14:40] --> Avenger has joined #gemrb
[16:14:47] <Avenger> hi
[16:18:48] <fuzzie> maybe you can get Avenger to work it out :P
[16:18:59] <Avenger> work out what?
[16:19:11] <fuzzie> some malfunctioning trap problem of dhewg's
[16:19:18] <fuzzie> i don't really have the time, i need to go soon
[16:19:55] <Avenger> faketran2100 has no destination area... i don't know how that supposed to work
[16:20:05] <fuzzie> there's the overlapping containers in the spellhold area too
[16:20:14] <fuzzie> Avenger: that is a fake, not meant to do anything
[16:20:29] <Avenger> i see
[16:20:48] <Avenger> dltcep even says, it would cause crash :D
[16:20:51] <fuzzie> movie04 is the real one, in the same place - it is trapped, activates on Entered([ANYONE])
[16:21:20] <Avenger> so the movie04 script runs?
[16:21:31] <fuzzie> i don't know, because i can't do anything :P
[16:21:35] <fuzzie> maybe dhewg will wake up again
[16:22:17] <fuzzie> i already know of some bugs in that code, like how resetting traps is broken and etc
[16:22:26] <fuzzie> but none seem relevant here
[16:23:56] <fuzzie> it is on the 'to rewrite' list, along with fixing the action AI update loops and fixing dialogs, but not today
[16:24:08] <fuzzie> maybe tomorrow, although i have to go watch a hockey game in the afternoon
[16:24:14] <Avenger> did he have the rope?
[16:24:16] <Avenger> miscbi
[16:24:27] <fuzzie> this is from Spellhold i think?
[16:24:33] <Avenger> yes
[16:24:36] <fuzzie> so it's a proximity trap checking Entered
[16:24:47] <fuzzie> not the magic rope trap checking Clicked
[16:25:13] <fuzzie> i have no idea why Bioware did it this way..
[16:26:55] <Avenger> i think this trigger is used in two places
[16:27:01] <fuzzie> yes
[16:27:05] <fuzzie> but he's using the first one :)
[16:27:18] <Avenger> the rope is used in the sahuagin palace
[16:27:28] <Avenger> so, this one should work only with the clicked
[16:27:36] <Avenger> err entered
[16:27:40] <fuzzie> yes
[16:27:48] <fuzzie> but it looks like it should work
[16:27:50] <Avenger> so, Entered[Anyone] doesn't work
[16:28:01] <Avenger> i already told you about this
[16:28:08] <Avenger> [Anyone] is buggy
[16:28:09] <fuzzie> you did?
[16:28:11] <Avenger> yes
[16:28:17] <Avenger> [ANYONE] returns null
[16:28:23] <Avenger> instead of anyone :D
[16:28:23] <fuzzie> that isn't ok?
[16:28:46] <Avenger> no, it isn't [ANYONE] should return the nearest... anyone :P
[16:28:55] <fuzzie> no, it shouldn't
[16:29:06] <Avenger> *rolleyes*
[16:29:15] <fuzzie> it should *match* anyone, surely
[16:29:28] <Avenger> yes
[16:29:33] <fuzzie> this is why MatchActor returns 'true' always, on NULL object
[16:31:11] <fuzzie> it seems someone moved all my functions about at random, here :P
[16:31:47] <Avenger> i didn't even so your code
[16:31:56] <Avenger> i will need to reboot to windows and debug
[16:32:01] <Avenger> i see this stuff for the first time
[16:32:05] <fuzzie> well
[16:32:10] <fuzzie> maybe this is a savegame bug
[16:32:15] <fuzzie> there's a lot of problems in that area
[16:32:20] <Avenger> no
[16:32:29] <Avenger> i just used a movetoarea to this area
[16:32:31] <Avenger> never been there
[16:32:38] <fuzzie> ah, doesn't work for you either? :(
[16:32:47] <Avenger> yep
[16:33:16] <Avenger> ok lets reboot
[16:33:21] <Avenger> hope msvc6 can still compile
[16:33:23] <-- Avenger has left IRC (Quit: bye!)
[16:36:05] --> Avenger has joined #gemrb
[16:36:05] --- ChanServ gives channel operator status to Avenger
[16:36:09] <fuzzie> hi
[16:37:33] <Avenger> i wonder if this could be fixed-->non dll-interface class 'Held<class Plugin>' used as base for dll-interface class 'Plugin'
[16:38:06] <fuzzie> yes
[16:39:46] <Avenger> shouldn't the plugin loader be in deeper?
[16:39:49] <Avenger> like in System?
[16:40:03] <fuzzie> dunno
[16:40:34] <fuzzie> i expect tomprince will read backscroll and comment
[16:41:02] <Avenger> i swear we had MemoryStream before :) then it was gone, and now back again
[16:41:07] <fuzzie> yes
[16:41:09] <fuzzie> sorry :P
[16:41:14] <fuzzie> it turns out that it's really useful to have
[16:41:49] <fuzzie> although the best performance fix recently was from dhewg, stopping LoadScreen from repeatedly redrawing the progress bar
[16:41:50] <Avenger> ok, i guess i made it compile
[16:41:59] <tomprince> PluginLoader could move to system, sure.
[16:42:21] <fuzzie> well, maybe another dir
[16:42:26] <Avenger> eep, the console log colors are all different
[16:43:13] <tomprince> The tables that control that are in System/Logging.cpp
[16:43:17] <Avenger> both ok and error is cyan
[16:43:25] <tomprince> Must've made a mistake when moving it.
[16:43:58] <fuzzie> the WHITE should be at the beginning
[16:44:06] <Avenger> fun, crash ..
[16:44:10] <fuzzie> before the 0
[16:44:24] <Avenger> int GameScript::AreaType(Scriptable* Sender, Trigger* parameters)
[16:44:36] <Avenger> Sender->GetCurrentArea is null
[16:44:38] <Avenger> meeh
[16:44:58] <Avenger> it is Game
[16:45:13] <Avenger> so the script runs before the game was loaded
[16:45:18] <Avenger> or something like that
[16:45:27] <fuzzie> why is a Game script checking AreaType?
[16:45:46] <Avenger> why not
[16:45:49] <fuzzie> i guess baldur.bcs does that
[16:45:51] <fuzzie> how weird
[16:45:57] <Avenger> it is the current area
[16:46:02] <Avenger> shouldn't be a problem
[16:46:10] <Avenger> but somehow it is run before the game is initialized
[16:46:11] <fuzzie> well, why is it suddenly happening, i wonder?
[16:46:16] <Avenger> right
[16:47:10] <fuzzie> hmm
[16:47:16] <fuzzie> how long since you last tried gemrb?
[16:48:08] <Avenger> not sure, someone changed GameLoop/loading recently?
[16:48:22] <fuzzie> well, i rewrote the trigger stuff
[16:49:03] <Avenger> crash is consistent
[16:49:06] <Avenger> meeh
[16:49:07] <fuzzie> and that fixed Delay(), for example, which means a lot more blocks run now
[16:49:30] <Avenger> i don't quite see why game->GetCurrentArea() returns 0
[16:49:48] <Avenger> the script shouldn't run before an area is loaded
[16:50:21] <Avenger> oh i see something else too
[16:52:06] <Avenger> it says: cannot open archive O_o
[16:52:19] <Avenger> area1900.bif
[16:52:34] <Avenger> what did you guys do :D
[16:52:36] <fuzzie> after the decompress?
[16:52:41] <Avenger> yes
[16:52:54] <Avenger> it is totally weird
[16:53:21] <Avenger> it decompresses the tile map, then says it cannot open the bif
[16:54:20] <Avenger> i guess that causes the area problem
[16:54:25] <fuzzie> your config is ok
[16:54:33] <fuzzie> you don't have GameOnCD enabled or something?
[16:54:34] <Avenger> it worked before
[16:55:00] <Avenger> no
[16:55:24] <fuzzie> and the bif shows up in Cache/?
[16:56:44] <Avenger> yes
[16:57:12] <Avenger> TileMap* tm = tmm->GetTileMap(NULL);
[16:57:14] <Avenger> returns 0
[16:58:37] <fuzzie> sure, if you can't open the archive it won't work
[16:58:49] <Avenger> ok, tjhis is some weird stuff
[16:58:57] <Avenger> in return tm;
[16:59:03] <Avenger> i still have a value
[16:59:13] <Avenger> at the end of TileMap* WEDImporter::GetTileMap(TileMap *tm)
[16:59:38] <Avenger> so wtf
[17:00:41] <Avenger> i set the IP back to the tilemap constuction, and it returned one!
[17:00:51] <Avenger> but i needed to do it twice
[17:00:55] <Avenger> what the hell
[17:01:49] <Avenger> also a crasher in the destructor of store
[17:02:02] <Avenger> ok, i guess, i need some recompile maybe
[17:02:25] <Avenger> either that, or someone messed up everything
[17:02:54] <fuzzie> well, i have to go
[17:04:21] <Avenger> well, it is dead
[17:12:39] <dhewg> hi
[17:13:00] <dhewg> erm, yeah. i tried to rm ar1516 files from the cache and reenter, portal is still broken
[17:13:02] <Avenger> GameData::SaveStore(Store * & 0xfeeefeee) is not healthy
[17:13:09] <dhewg> so its not a savegame issue i think
[17:13:29] <Avenger> dhewg, i cannot check your problem because someone messed up the cache/store stuff
[17:13:40] <Avenger> i cannot even load a game
[17:13:41] <dhewg> i just read, but its weird
[17:13:58] <dhewg> i playtest alot, and i didnt run into that
[17:14:15] <dhewg> but like fuzzie said, alot of changed. maybe stale files?
[17:14:25] <dhewg> try a full rebuild maybe?
[17:14:46] <Avenger> i tried
[17:15:03] <Avenger> deleted all old files, removed them from the project, make clean
[17:15:22] <dhewg> i think that savestore stuff comes from the store caching
[17:15:29] <dhewg> which improved master _alot_
[17:15:37] <Avenger> it tries to save a deleted store
[17:15:52] <dhewg> i have like 5 bags on my party, and master was unplayable before that commit :)
[17:16:12] <Avenger> which is not surprising
[17:16:23] <Avenger> void GameData::SaveAllStores()
[17:16:29] <Avenger> goes from beginning to end
[17:16:32] <dhewg> well, good thing is its all good now
[17:16:46] <dhewg> i had some funky bag issues i think
[17:16:51] <dhewg> is that an old savegame?
[17:17:27] <Avenger> yes, an old savegame, of the original engine
[17:17:36] <Avenger> it should work
[17:17:41] <dhewg> maybe there is an issue with loading new store stuff with savegames from before the store changes
[17:18:17] <Avenger> but it is an original engine savegame, i think
[17:18:20] <Avenger> let's see
[17:19:07] <Avenger> yes, it is
[17:19:10] <Avenger> it should work
[17:19:47] <Avenger> and when i look at void GameData::SaveAllStores(), i don't see how it is supposed to work
[17:20:07] <tomprince> It steps through all the stores in the cache, and saves them.
[17:20:28] <tomprince> I am wondering if the iterator is getting invalidated on the erase in SaveStore.
[17:21:14] <Avenger> stores.begin()->second isn't a valid store?
[17:21:46] <Avenger> ahh ok, it increases after
[17:21:50] <tomprince> It should, unless stores.begin() == stores.end()
[17:23:29] <Avenger> ok, maybe it is related to my original problem
[17:23:36] <Avenger> but i don't see how
[17:23:51] <Avenger> the original problem is that the tilemap isn't returned when loading the area first
[17:24:05] <Avenger> TileMap* tm = tmm->GetTileMap(NULL); returns null
[17:25:00] <Avenger> usedoverlays = AddOverlay(tm, &overlays.at(0), false); returns -1
[17:28:20] <tomprince> Weren't you getting a bif failing to load, before that?
[17:28:33] <Avenger> DataStream* ResourceManager::GetResource(const char* ResRef, SClass_ID type, bool silent) const returns null when called first, if i immediately restart it, it works!
[17:28:47] <Avenger> this is some resource manager bug
[17:29:00] <Avenger> the big is in the cache
[17:29:03] <Avenger> bif*
[17:29:15] <Avenger> but getresource fails first
[17:32:19] <tomprince> In KEYImporter, try removing the if (lastSeenCache.bifnum != ...), the two lastSeenCache =, and the lastSeenCache.plugin-> on the next line to ai->
[17:33:18] <Avenger> you mean the whole if construct?
[17:33:37] <tomprince> no.
[17:34:38] <Avenger> ok, just the if and a closing bracket
[17:34:53] <tomprince> Yes.
[17:35:18] <Avenger> didn't work
[17:35:46] <Avenger> same can't load bif stuff
[17:36:30] <Avenger> it goes to print("Cannot open archive %s\n", biffiles[bifnum].path );
[17:37:23] <tomprince> So, it is something in the bifimporter, or perhaps the cache changes.
[17:37:58] <Avenger> if (ai->OpenArchive( biffiles[bifnum].path ) == GEM_ERROR) {
[17:38:04] <Avenger> if i retry, it works
[17:38:09] <Avenger> heh
[17:38:21] <Avenger> what magic you put into this :D
[17:39:00] <Avenger> where is OpenArchive ?
[17:39:05] <Avenger> i want to go one level deeper
[17:39:24] <Avenger> bifimporter
[17:39:58] <Avenger> well, could it be something like: when decompressing a bif, it doesn't close the stream?
[17:40:22] <tomprince> is that an issue on win32? possibly.
[17:41:47] <Avenger> FileStream* file = FileStream::OpenFile(filename); works on the bif
[17:42:54] <Avenger> right
[17:43:00] <Avenger> stream = FileStream::OpenFile(path);
[17:43:03] <Avenger> returns 0
[17:43:13] <Avenger> this is on the decompressed stream
[17:43:47] <Avenger> out should be closed first
[17:44:32] <Avenger> Close is private?
[17:45:29] <Avenger> meh, i'm sure it was you :D
[17:45:37] <Avenger> i remember you rewriting filestream
[17:45:57] <tomprince> Probably no good reason, execept that I am not sure if we are good at checking if a stream is actually open.
[17:46:51] <Avenger> well, if the stream is already open, maybe it could be simply returned
[17:47:01] <Avenger> i see no reason why we close and reopen it
[17:47:26] <Avenger> but now i will just do that
[17:48:05] <Avenger> this shows, that we should do more automated regression testing
[17:48:16] <Avenger> just loading an area and quitting would have shown this bug
[17:48:25] <Avenger> it works now :D
[17:48:43] <dhewg> is that on windows?
[17:48:46] <Avenger> ok, except reloading an area breaks on stores
[17:48:50] <Avenger> stores are still buggy
[17:48:52] <Avenger> yes dhewg
[17:49:11] <dhewg> maybe a windows specific problem due to file handling
[17:49:28] <dhewg> is it opening the file in exclusive mode or something?
[17:49:37] <Avenger> a limitation surely, you cannot reopen an exclusively opened file
[17:49:53] <Avenger> it is opening exclusive for writing, with good reason
[17:50:00] <Avenger> that's good
[17:50:20] <dhewg> yeah, makes sense
[17:50:50] <dhewg> just that these platform differences are subtile
[17:51:34] <dhewg> i mean, opening a fd in write mode as exclusive makes sense
[17:51:44] <dhewg> maybe the posix code path should do the same
[17:52:06] <dhewg> and maybe you're seeing the same issue on stores?
[17:55:10] <tomprince> Avenger: maybe try 'while(!stores.empty()) SaveStore(store.begin()->second);' in SaveAllStores
[17:55:39] <Avenger> ok
[17:55:50] <Avenger> sounds like an elegant solution :D
[17:56:48] <dhewg> its a funky loop
[17:57:02] <dhewg> why not use ++it as 3rd for parameter?
[17:57:39] <dhewg> and if (empty()) return; on top
[17:57:53] <tomprince> Read the comment: SaveStore erase the store corresponding to the iterator, invalidating, so we need to update before we pass it in.
[17:58:05] <Avenger> MEEH
[17:58:09] <Avenger> it freezes too!
[17:58:48] <tomprince> Can you step through SaveAllStores?
[17:59:15] <tomprince> It seems the code to erase stores from the cache must be broken somehow.
[17:59:16] <Avenger> i will now
[17:59:43] <Avenger> stores.erase(it);
[17:59:49] <Avenger> causes store to be feeefeee
[17:59:58] <Avenger> then delete 0xfeeefeee obviously dies
[18:00:37] <tomprince> msvc is freeing the pointer in the erase?
[18:01:23] <Avenger> i don't know, but this is why i hate high level stuff
[18:01:29] <tomprince> No, it is the reference paramater.
[18:01:31] <Avenger> different implementations --> fail
[18:01:33] * tomprince smacks head.
[18:01:51] <Avenger> ah
[18:02:09] <Avenger> so i remove that & ?
[18:02:37] <Avenger> or... just remove the delete
[18:02:38] <tomprince> Yes. And add a Currentstore = NULL in Interface::CloseCurrentStore
[18:03:57] <Avenger> ok, removed the & and added the NULL
[18:04:55] <dhewg> on the other side, this is basic iterator stuff
[18:04:57] <Avenger> works now
[18:05:04] <dhewg> dont hate the code :)
[18:05:19] <dhewg> msvc6 is just a little old
[18:05:28] <Avenger> well, it didn't crash on linux, most likely because linux doesn't set variables to 0xfeeefeee :D
[18:05:34] <Avenger> and delete 0 works
[18:05:51] <Avenger> still, calling delete 0 is ...
[18:06:01] <dhewg> its valid :)
[18:06:07] <dhewg> as is free(0)
[18:06:09] <Avenger> its futile
[18:06:12] <tomprince> just fine, the only problem is it was accessing memory after free.
[18:06:13] <Avenger> if you know it is always 0
[18:06:18] <dhewg> but yeah, not arguing if there was a bug, didnt look that close
[18:06:53] <dhewg> but really, delete 0 is okay, thats why you dont have to check all pointers against NULL to delete it
[18:06:57] <dhewg> just delete it :)
[18:07:20] <Avenger> but if that was correct, i should have just remove the delete :D
[18:07:45] <Avenger> anyway, i don't care, it works now, most likely won't leak either
[18:07:46] <tomprince> no, that would lead to a memory leak.
[18:07:46] <CIA-52> GemRB: 03tom.prince * r0b1d2ef3f409 10gemrb/gemrb/core/ (GameData.cpp GameData.h Interface.cpp):
[18:07:46] <CIA-52> GemRB: SaveAllStores: Fix a use after free.
[18:07:46] <CIA-52> GemRB: Caught by msvc6.
[18:07:46] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:08:21] <tomprince> The store pointer was reference, which pointed into the map, which was being freed in erase.
[18:08:22] <Avenger> now i'm back to the original problem
[18:09:07] <Avenger> hmm, fuzzie was right when she said more script triggers work :D
[18:09:23] <Avenger> i get some stuff i didn't see before, hopefully the original would do the same
[18:14:51] <Avenger> hmm, the movie04 trap is triggered only once...
[18:15:00] <Avenger> if we mess up, it is deactivated
[18:15:09] <dhewg> yeah, im really impressed with how gemrb improved in the last weeks
[18:15:28] <dhewg> bg2 had so many bugfixes, its playable without beeing annoying
[18:16:15] <dhewg> there're still some stupid things though :)
[18:16:30] <wjp> speaking of which, I was just looking at dragon palettes
[18:16:34] <Avenger> first addtrigger works
[18:16:38] <dhewg> my fav is the shade lord casting finger of death on himself and screaming "this can not be!!1"
[18:16:53] --- Maighstir is now known as Maighstir|away
[18:16:55] <Avenger> eh wjp, i know i might have messed them up, but i fixed some other bug with it, in pst
[18:17:05] <Avenger> so, be careful :D
[18:17:22] <wjp> it's a bit tricky
[18:18:01] <wjp> it's copying a wrong palette into CharAnimations::palette[PAL_MAIN]
[18:19:06] <wjp> which might mean that different BAMs of the same multi-part dragon animation have different palettes
[18:19:16] <wjp> ..., which, if true, would be very annoying
[18:20:11] <wjp> it could also be it's copying a palette from an empty part of the animation, but I'm speculating now
[18:20:57] <dhewg> did i mention that the dragon palette changes if you just select another party member?
[18:21:37] <CIA-52> GemRB: 03tom.prince * r3336b012886b 10gemrb/gemrb/plugins/BIFImporter/ (BIFImporter.cpp BIFImporter.h):
[18:21:37] <CIA-52> GemRB: BIFImporter: Close uncompressed FileStream before trying to open it again.
[18:21:37] <CIA-52> GemRB: This breaks otherwise on win32.
[18:21:37] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:21:54] <wjp> dhewg: yes. I don't understand how or why, though
[18:21:58] <tomprince> Avenger: That should fix the BIF problem.
[18:22:19] <Avenger> and i can fix the trap problem
[18:22:30] <Avenger> but it is not entirely correct
[18:22:48] <Avenger> bool InfoPoint::TriggerTrap(int skill, ieDword ID) deactivates the trap too early
[18:23:02] <Avenger> deactivated traps don't run their script
[18:23:19] <Avenger> so, this one causes all single fire traps not functioning
[18:23:20] <wjp> dhewg: I also can't reproduce this selection dependency
[18:23:31] <tomprince> The file is http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=blob_plain;f=gemrb/plugins/BIFImporter/BIFImporter.cpp;h=6ca327e2b881290267439acde6fc9683b143144b;hb=3336b012886bd8289d8fb860dae042cb72714e86
[18:23:57] <tomprince> if you want to try it. (Also need to add the function to BIFImporter.h)
[18:24:20] <dhewg> wjp: i could try again, but it worked last time i tried
[18:24:45] <dhewg> does it maybe depend on the equipment? (just a wild guess, anything that changes palettes of players)
[18:27:00] <wjp> dunno
[18:27:45] <Avenger> will fuzzie come back, or she is gone for good?
[18:28:34] <tomprince> I think she is just busy.
[18:28:50] <Avenger> ok, booting back to linux
[18:28:51] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86.1 [Firefox 3.6.17/20110420140830])
[18:29:09] <wjp> I guess for this dragon I'll have to manually look at some frames and compare the palettes :-(
[18:29:13] <wjp> bah
[18:29:55] <wjp> no time for that this weekend though, so it'll have to wait
[18:29:57] <dhewg> wjp: ah, i see. its the helm of intravision. if selecting a char wearing it the shadow dragon goes from green to red
[18:30:19] <wjp> ah, so it's just the normal infravision effect
[18:30:30] <tomprince> That doesn't just affect dragons, does it?
[18:30:36] <dhewg> yeah, looks like it just amplifies the real issue
[18:35:54] <CIA-52> GemRB: 03tom.prince * r6a6abcd8b8ed 10gemrb/gemrb/core/GameData.cpp:
[18:35:54] <CIA-52> GemRB: SaveAllStores: Rewrite the loop in a clearer fashion.
[18:35:55] <CIA-52> GemRB: The use of post-increment to avoid invalidating the iterator
[18:35:55] <CIA-52> GemRB: was confusing.
[18:35:55] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:37:45] <wjp> tomprince: you should've kept the comment, though :-)
[18:38:02] <wjp> anyway, time to go. See you later
[18:55:42] <gembot> build #135 of msvc++6 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/135
[18:58:43] <dhewg> there's some really funky stuff going on in ar1606
[18:59:07] <dhewg> there's this quest where you should grab the pirate horn
[18:59:26] <dhewg> and the whole gui is going nuts
[19:00:41] <dhewg> i get "Speaker gone???" when just entering with one char, which is not the main char
[19:01:17] <dhewg> looks like its related to which chars are on which map
[19:01:58] <dhewg> if i enter with the main char, i get the "Mmm, do you sleep?" dialog from cayia, which looks correct
[19:12:52] <dhewg> i think that area just invented moonsleeping
[19:13:16] <dhewg> the 2 sleeping dudes in there just moved without getting up
[19:13:31] <dhewg> like from the bed, down to to floor, then to the door
[19:13:33] <dhewg> :)
[19:18:24] --- Maighstir|away is now known as Maighstir
[19:47:00] <-- gembot has left IRC (Quit: buildmaster reconfigured: bot disconnecting)
[19:48:21] --> gembot has joined #gemrb
[19:49:37] <tomprince> Error checking: https://github.com/tomprince/gemrb/compare/master...cleanup
[19:59:48] <tomprince> Should we be writing something to the game console, if we can't save (export, usually) a character?
[20:01:49] <tomprince> Interface::WriteCharacter is returning int, but the value is unused. Either we should drop it, or do something useful with it.
[22:04:07] --> raevol has joined #gemrb
[22:08:00] --> Avenger has joined #gemrb
[22:08:02] <Avenger> phew, g3 is back online.
[22:25:45] <-- Avenger has left IRC (Quit: bye!)
[22:31:34] <-- raevol has left IRC (Ping timeout: 252 seconds)
[23:02:41] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:30:29] <fuzzie> oh dear
[23:31:51] <fuzzie> you all did stuff!
[23:32:15] <fuzzie> tomprince: we ignore some number of return values which should display a fail
[23:32:30] <fuzzie> ideally we would do a popup dialog like in the original, but this is really annoying to do on non-win32
[23:32:46] <fuzzie> but i am tired, accidentally tried making a train connection which doesn't exist
[23:34:56] <fuzzie> tomprince: also, it occurred to me while we were out, perhaps we can #error on attempts to include exports.h into msvc with the static C library enabled?
[23:35:34] <fuzzie> i think #ifndef _DLL
[23:36:00] <fuzzie> just as a simple way to make sure that Avenger never accidentally runs into the allocation issues again
[23:39:45] <fuzzie> but well i am delightfully happy to come back to you all having already fixed the problems!
[23:56:39] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[23:57:19] <CIA-52> GemRB: 03tom.prince * rbaf0b1c44925 10gemrb/gemrb/includes/exports.h:
[23:57:20] <CIA-52> GemRB: Force gemrb to be dynamically linked with runtime library on msvc.
[23:57:20] <CIA-52> GemRB: Suggested by fuzzie.
[23:57:20] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[23:57:21] <CIA-52> GemRB: 03tom.prince * r94cbef6d54a3 10gemrb/gemrb/includes/exports.h:
[23:57:21] <CIA-52> GemRB: Add some comments to exports.h.
[23:57:21] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[23:57:23] <CIA-52> GemRB: 03tom.prince * r45217d0ec383 10gemrb/gemrb/ (core/Interface.h includes/exports.h includes/win32def.h): Merge branch 'win32' into HEAD
[23:57:25] <CIA-52> GemRB: 03tom.prince * r91e3286e59e0 10gemrb/gemrb/ (core/Interface.h includes/exports.h includes/win32def.h):
[23:57:25] <CIA-52> GemRB: Move warning pragmas into exports.h.
[23:57:25] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>