#gemrb@irc.freenode.net logs for 27 Apr 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:01:02] <tomprince> My vague thoughts on the cache was to create a new ResourceSource for it, that also exposed an interface for handling the stuff in FileCache. We would have to go through and make sure that everything that wrote to the cache used that.
[00:02:35] <tomprince> Probably not all that hard to do, since anything that touches files goes through FileStream now, so just get rid of the method for creating files in the cache, and perhaps add a check to make sure no other code paths create files there.
[00:42:32] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[06:07:12] --> ubermad has joined #gemrb
[06:11:03] <ubermad> hi, mam problem nie działa mi opcja Always Run=1 in gemRB
[06:11:22] <ubermad> sorry
[06:11:23] <ubermad> ;p
[06:11:25] <ubermad> I have a problem do not work for me the option Always Run = 1 in gemRB
[06:19:48] --> devurandom has joined #gemrb
[07:01:39] <-- mihairu has left IRC (Remote host closed the connection)
[07:13:29] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[07:14:18] --> test32894789234u has joined #gemrb
[07:42:43] --> Drakkar has joined #gemrb
[07:45:45] <-- PixelScum has left IRC (Ping timeout: 264 seconds)
[07:48:15] --> adominguez has joined #gemrb
[07:50:55] <ubermad> I have a problem do not work for me the option Always Run = 1 in gemRB
[07:51:43] --> lynxlynxlynx has joined #gemrb
[07:51:43] --- ChanServ gives channel operator status to lynxlynxlynx
[07:51:56] <ubermad> I have a problem do not work for me the option Always Run = 1 in gemRB
[07:55:34] <ubermad> is there any way to move the "save" the gemrb on pc, because for me the "save" not working on pc
[07:56:33] --> mihairu has joined #gemrb
[08:01:19] <lynxlynxlynx> Always Run is only for pst
[08:01:38] <lynxlynxlynx> i'm not sure it is implemented yet though
[08:02:11] <lynxlynxlynx> re save: i don't understand the question
[08:07:43] <ubermad> I want to play on my computer using the save from my smartphone
[08:13:55] --> PixelScum has joined #gemrb
[08:14:49] <lynxlynxlynx> that should work just fine
[08:15:07] <lynxlynxlynx> what game is it? are they both from gemrb to gemrb?
[08:16:11] <-- Drakkar has left IRC (Ping timeout: 240 seconds)
[08:16:16] <ubermad> no gemrb -> widescreen + ghostdog's
[08:18:17] <lynxlynxlynx> then we have a bug
[08:19:29] <ubermad> dame :/
[08:29:12] <fuzzie> the original savegame rules probably apply
[08:29:39] <fuzzie> which is to say, you must use the same resolution
[08:37:06] <fuzzie> and i guess same mods
[08:51:43] <fuzzie> lynxlynxlynx: so, i have mostly-complete notes for the spell and death code now, too
[08:51:59] <fuzzie> the interrupt-on-hit stuff is not in there though :)
[08:52:55] <fuzzie> maybe it's the field_3608, which produces DCS_casting_fail
[08:53:06] <lynxlynxlynx> it's probably in the damage opcode
[08:53:22] <lynxlynxlynx> you could interrupt a mage through the stoneskin via elemental damage
[08:54:12] <fuzzie> right, i have not looked at how that works :)
[08:56:17] <fuzzie> but it's a lot simpler code than we have
[08:57:37] <fuzzie> in overall design, not bothered about details
[08:58:13] <edheldil> btw, afak the problem with stl::map was that it did not work in msvc6 :-D
[08:58:29] <fuzzie> we snuck it in all over the place now
[08:58:42] <fuzzie> but std::map is pretty slow
[09:00:31] <fuzzie> maybe all you folksen motivated to fix core code will make a hashmap work out
[09:01:42] <fuzzie> but in the meantime i will grump about the lack of a directory-level cache until someone says 'ok, you can write a hack with std::map'.
[09:03:37] <edheldil> 'ok, you can write a hack with std::map'
[09:03:44] <fuzzie> ;p
[09:03:46] <fuzzie> morning edheldil :)
[09:04:03] <fuzzie> i am really happy to see anyone except me caring about the slow I/O mess, honestly
[09:04:10] <edheldil> hi, Fuzzie. Happy Easter, if late
[09:05:31] <edheldil> I am really happy to someone care about any parts of the code. There IS reason why long sequences of the gource video are rather static :)
[09:06:24] <fuzzie> hehe, well, i would prefer people care about the game logic :-)
[09:06:34] --> lubos has joined #gemrb
[09:07:18] <edheldil> Hi, lubos, what's new? Are we in deabian weekly news yet? :)
[09:08:03] <fuzzie> hm, it occurs to me that those new autodetect files are actually violating our incomplete coding style rules :P
[09:09:01] <lynxlynxlynx> nalia problem
[09:09:12] <fuzzie> yes, she really is a problem
[09:09:31] <lynxlynxlynx> taking too long to exit the cc can make her think you're meeting her for the second time - infront of the keep
[09:09:54] <lynxlynxlynx> her script doesn't have an area check, relying on other stuff
[09:10:05] <fuzzie> any idea what we're messing up?
[09:10:18] <lubos> edheldil: GemRB has still problem with license headers, so is impossible upload it to Debian
[09:12:42] <edheldil> fuzzie: which rules? :)
[09:13:05] <fuzzie> edheldil: the 'don't force your heathen 4-space-tab ways on us' ones :p
[09:13:45] <fuzzie> i mean in more seriousness, there's some discussion in backscroll about using the scummvm ones, although tomprince doesn't like the _/g_ prefixes
[09:14:13] <fuzzie> opinions welcome. also on the 0 vs NULL for pointers thing.
[09:14:49] <lynxlynxlynx> ... not yet
[09:15:07] <lynxlynxlynx> NULL is clearer to me too
[09:15:17] <fuzzie> LastTrigger is somewhat broken in master btw
[09:15:32] <fuzzie> if that is showing up
[09:16:57] <fuzzie> i'm taking another look at a profile
[09:17:25] <fuzzie> adler32 does take a lot of time, the zlib optimisations that dhewg pointed at might help, but hopefully distros will pick them up
[09:18:43] <fuzzie> and the readdir and DirectoryIterator::operator++ stuff is high up, as i suggested
[09:21:04] <fuzzie> while the BIFImporter's search and I/O is so far off the bottom of the profile to be irrelevant, as i thought :P
[09:23:35] <fuzzie> with the 'profiling unoptimised code, so unreliable' disclaimer: in the blitting code the XNEG seems expensive, due to the xor?
[09:24:31] <fuzzie> and the BLENDPIXEL is expensive but that's not really a surprise, since all the work is done there
[09:32:26] <edheldil> I prefer NULL as well
[09:33:53] <edheldil> what are _/g_ prefixes for?
[09:36:09] <fuzzie> _varName for a member variable, g_varName for a global variable
[09:36:17] <fuzzie> so you can see at a glance whether it's global, member or local
[09:36:46] <fuzzie> it's very helpful to me, but if people don't like it, we shouldn't use it
[09:42:34] <lynxlynxlynx> use _ for locals and it is less of an intrusion
[09:42:48] <fuzzie> yeah, but it gets really messy with stuff like 'i'
[09:42:57] <lynxlynxlynx> the kernel and some others use it like that __
[09:43:02] <fuzzie> you end up with no-one sticking to the rule
[09:43:14] <lynxlynxlynx> mnja
[09:51:54] <edheldil> should there be member variables called 'i' at all???? :)
[09:52:04] <fuzzie> no
[09:52:07] <fuzzie> but there are surely local ones
[09:53:40] <edheldil> I am not against that rule ... but there is also a whole Pandora's box of identifier naming
[09:54:17] <dhewg> std::map doesnt work on msvc6? o_O
[09:54:25] <fuzzie> it's used *all over the codebase*
[09:54:27] <dhewg> impossible!
[09:54:28] <edheldil> i.e. vars named like_this, likeThis, LikeThis - regardless of type
[09:54:30] <dhewg> yeah, exactly
[09:54:44] <dhewg> fuzzie: but where is it slow?
[09:54:59] <fuzzie> dhewg: in the bit which i said needs a cache, and nowhere else :P
[09:55:04] <dhewg> its only slow on creation, but fast on accessing members
[09:55:15] <fuzzie> i mean, this is on master, not your stuff
[09:55:26] <dhewg> yeah yeah, gimme some time kthx :P
[09:55:35] <fuzzie> i already have a working cache ;p
[09:55:41] <edheldil> well, maybe I remember it wrong, then - but Avenger HAD some reason to use Variables.(h|cpp) :)
[09:55:45] <dhewg> apart from braindead oneliners i started poking at the src just yesterday :P
[09:55:51] <fuzzie> edheldil: because std::map is incredibly slow :P
[09:56:25] <dhewg> it is not with libstdc++
[09:56:49] <fuzzie> libstdc++ specialises it?
[09:56:58] <dhewg> its a red/black tree
[09:57:16] <dhewg> there's no way a sequential poking is faster with 40k elements
[09:57:20] <fuzzie> yes
[09:57:23] <fuzzie> but we don't do sequential poking
[09:57:34] <dhewg> maybe it fails with msvc6, but that fails at life in the first place :P
[09:57:57] <fuzzie> i mean, you're talking about the BIF thing, but the BIF retrieval thing really doesn't get called much
[09:58:41] <fuzzie> i'm just saying why we don't use std::map in general
[09:58:46] <dhewg> what do you mean then? the keyimporter changes?
[09:58:53] <fuzzie> it was originally in the tree, and the performance totally sucked
[09:59:09] <fuzzie> you can't possibly use a non-hashmap to store variables
[09:59:46] <fuzzie> i am not criticising your changes at all ;)
[09:59:58] <fuzzie> i have not looked at them
[10:00:01] <dhewg> i know, im trying to understand :P
[10:00:16] <dhewg> obviously the std::map performance depends on the implementation, but i cant confirm the performance suckage at all
[10:00:20] <fuzzie> i'm just saying that std::map being better than a linear search doesn't mean std::map doesn't completely suck performance-wise
[10:00:49] <fuzzie> because you're still stuck doing comparisons whenever you want to retrieve anything
[10:01:51] <fuzzie> but this is nothing to do with your stuff
[10:01:54] <dhewg> yeah, but you have less comparisons with a nice tree compared to a dumb array
[10:02:08] <fuzzie> yes, but it's incredibly bad compared to a hash
[10:02:27] <fuzzie> and that is why we don't use std::map everywhere :P
[10:03:03] <fuzzie> i am going on trust that the performance of your hashmap is acceptable with the underlying std::map, for now :)
[10:03:05] <dhewg> we're comparing a map with a hash now?
[10:03:28] <fuzzie> edheldil was saying that Avenger had some reason to use Variables.cpp and not std::map
[10:03:32] <fuzzie> that is hashmap vs map :)
[10:04:18] <dhewg> oh, i didnt find that yet
[10:04:21] <fuzzie> if we have a generic templated hashmap in tree then we can replace that, too
[10:04:42] <dhewg> gah, how many variations of that are in the tree?
[10:04:50] <fuzzie> well, i thought one
[10:04:53] <dhewg> i think i found 4 or 5 now
[10:04:59] <fuzzie> but then you found the one in keyimporter
[10:05:04] <fuzzie> and i found the one in Cache.cp
[10:05:08] <dhewg> Cache.cpp too
[10:05:11] <fuzzie> so i dunno, lots :P
[10:05:17] <dhewg> silly!
[10:05:30] <dhewg> but well, i get it if msvc6 sucks at std::map
[10:05:41] <fuzzie> it doesn't suck at std::map that much
[10:05:52] <fuzzie> it's just that Variables is all over the core loops
[10:06:10] <dhewg> let me fix that :P
[10:06:24] <fuzzie> i don't think you can replace it with your hashmap as-is though
[10:07:56] <fuzzie> but i haven't seriously looked at it, and won't this week
[10:08:38] <dhewg> yeah, lemme finish the cache stuff first
[10:08:57] <fuzzie> in my local tree, i have a CachedDirectoryImporter
[10:09:05] <dhewg> is there any way that someone profiles my crap on msvc6?
[10:09:15] <fuzzie> it can be done, yes
[10:09:23] <fuzzie> but i think profiling on linux would suffice
[10:09:44] <dhewg> well msvc6 really is old and espicially sucky
[10:10:04] <dhewg> i wouldnt be really surprised of std::map there is slower
[10:10:11] <fuzzie> slower than what, though?
[10:10:23] <dhewg> lets take my keyinporter changes
[10:10:33] <fuzzie> i mean, std::map comes with log(n) performance guarantees
[10:10:35] <dhewg> that replaces a variant of variables.cpp with a std::map
[10:10:43] <dhewg> yes, exactly
[10:10:51] <fuzzie> but obviously variables.cpp is going to be faster than that
[10:11:02] <dhewg> where i dont see variables.cpp making tree optimisations
[10:11:27] <fuzzie> it doesn't need to, it's a hashmap :P
[10:13:16] <dhewg> i think my confusion is based of different meanings of what a map is :)
[10:13:45] <fuzzie> well, in STL-speak, a hashmap should be around O(1) access time, and a map should be around O(log n) access time
[10:13:57] <fuzzie> because the latter doesn't do any hashing, so it's stuck doing a binary search on an internal tree
[10:17:13] <dhewg> i need to get my profiling setup fixed
[10:17:38] <dhewg> but just with a glimpse i dont see why variables.cpp would be faster
[10:17:47] <fuzzie> because there's no tree :P
[10:18:03] <dhewg> its a sille 2 dimension list
[10:18:06] <dhewg> *silly
[10:18:14] <dhewg> chained list
[10:18:23] <dhewg> you still need to iterate and compare
[10:18:25] <fuzzie> sure, but there's no linear search on the first part
[10:20:14] <dhewg> sorry, not seeing it :P
[10:20:21] <dhewg> but well, coffee and food now
[10:27:07] <fuzzie> http://fuzzie.org/nfs/gemrb/fuzzies_amazingly_awful_directory_cacher.txt
[10:27:40] <fuzzie> not going to bother tidying it up, if it's not going to get committted
[10:29:39] <-- ubermad has left #gemrb
[10:32:55] <dhewg> why not?
[10:33:27] <dhewg> also, does it help?
[10:33:38] <fuzzie> it does not help
[10:33:42] <dhewg> :P
[10:33:46] <fuzzie> i mean, all the stupid I/O in strace is gone
[10:34:06] <dhewg> its because .sto is in the cache dir, which you cannot cache like that
[10:34:18] <dhewg> see my resourcemanager idea yesterday :)
[10:34:21] <fuzzie> the .sto is rewritten anyway
[10:34:46] <fuzzie> i mean, that is the underlying stupid with STO, it is opening+rewriting+closing repeatedly
[10:35:07] <fuzzie> it's just weird because that isn't *that* expensive
[10:35:15] <fuzzie> even if it's stupid
[10:36:16] <fuzzie> if i were to commit it, i'd put the caching logic in a Cache() function, so you could force a refresh from elsewhere
[10:37:36] <fuzzie> but there's still a bunch of tiny bam files in the cache, why
[10:38:51] <fuzzie> oh, right, compressed
[10:46:30] <fuzzie> updated the patch for that, anyway
[10:49:34] <fuzzie> re-profiling with it
[10:51:50] --> ubermad has joined #gemrb
[10:53:15] <fuzzie> well, the profiler is certainly happier
[10:53:54] <fuzzie> it's all actual file I/O, zlib or SDL at the top now
[10:54:36] <fuzzie> but now also strnlwrcpy which is doing the same idiotic padding thing
[10:54:38] <fuzzie> gah
[10:54:40] <fuzzie> STOP THAT
[10:56:12] <fuzzie> is a "copy string and null-terminate and don't waste all my cpu cycles" function really so unattainable? :(
[10:56:46] <-- ubermad has left #gemrb
[10:58:26] <fuzzie> if i disable *that*, i don't get the pauses any more.
[10:58:40] <lynxlynxlynx> 20k lines of script :s
[10:58:47] <edheldil> fuzzie: you can pick 2 out of 3 :-)
[10:59:30] <fuzzie> ah, not quite true, loading with all the bags i can find, still vaguely noticable
[11:00:13] <fuzzie> still, given how terrible the bag code is, not too bad
[11:00:46] <lynxlynxlynx> ~Did you think I wouldn't notice? Oh, I forgot: you're not supposed to think. What spell does one cast when in need of you people? Oh, that's right - 'Summon idiots'.~ :D
[11:01:25] <fuzzie> dhewg: committing this won't cause problems for your work?
[11:02:53] <dhewg> nope, didnt touch that part yet
[11:29:12] <CIA-52> GemRB: 03fuzzie * ra139d903aed1 10gemrb/gemrb/ (4 files in 3 dirs):
[11:29:12] <CIA-52> GemRB: add a CachedDirectoryImporter and use it
[11:29:12] <CIA-52> GemRB: This gets rid of a lot of useless I/O in CaseSensitive mode.
[11:29:12] <CIA-52> GemRB: It probably needs a little more work for GameOnCD mode -- feel free to
[11:29:12] <CIA-52> GemRB: revert or replace with something better!
[11:29:13] <CIA-52> GemRB: 03fuzzie * r3ef0f57c6a34 10gemrb/gemrb/core/System/ (VFS.cpp VFS.h): export the VFS PathAppend function
[11:29:22] <CIA-52> GemRB: 03fuzzie * r26ef6ef04183 10gemrb/gemrb/ (core/Core.cpp includes/globals.h): add 'pad' parameter to strnlwrcpy
[12:02:37] <fuzzie> now all the directory time is being spent in BIFImporter, which is merrily circumventing DirectoryImporter
[12:04:25] <fuzzie> so, irrelevant, i assume
[12:09:22] <fuzzie> lynxlynxlynx: i'm getting unidentified stuff in stores, did i break that?
[12:14:17] <lynxlynxlynx> not to my knowledge
[12:14:44] <lynxlynxlynx> didn't see any unidentified stuff in stores today or yesterday
[12:16:00] <fuzzie> it's really weird
[12:16:07] <fuzzie> they show up with a blue highlight, and unidentified
[12:18:51] <fuzzie> the thief upstairs in Gaelan Bayle's place, if you find any time
[12:21:42] <lynxlynxlynx> i saw him yesterday, no issues
[12:22:13] <lynxlynxlynx> but maybe a fixpack thing
[12:22:35] <fuzzie> i'm also using an original save
[12:25:18] <fuzzie> thanks, anyway
[12:40:32] <tomprince> No reason for CachedDirectoryImporter to inherit from DirectoryImporter.
[12:41:10] <tomprince> Also, the names almost seem backwards, since the Cache directory is the only one that doesn't get a CachedDirectoryHolder.
[12:41:56] <tomprince> And you broke the !CaseSensitive case.
[12:42:03] <tomprince> Looks good though.
[13:07:06] <-- mihairu has left IRC (Remote host closed the connection)
[13:22:58] --> budlust has joined #gemrb
[13:23:50] <-- budlust has left #gemrb
[13:25:54] <lynxlynxlynx> more script foo
[13:26:26] <lynxlynxlynx> 2/4 mod npcs had/have problems
[13:34:07] <fuzzie> tomprince: really? the CaseSensitive case was working here
[13:36:19] <fuzzie> oh, didn't update patch
[13:37:23] <fuzzie> lynxlynxlynx: not LastTrigger?
[13:38:07] <lynxlynxlynx> exists exits immediately since the scriptable is null
[13:38:17] <lynxlynxlynx> how would LastTrigger manifest?
[13:38:24] <fuzzie> returning null
[13:38:47] <lynxlynxlynx> :(
[13:38:48] <tomprince> Well, I didn't actually try it, but the win32 bots are complaining.
[13:39:01] <lynxlynxlynx> btw, also killed is missing
[13:39:18] <lynxlynxlynx> odd that it complains about it though, i see only uses in tob
[13:39:26] <fuzzie> tomprince: Oh, right. Oop.
[13:39:32] <lynxlynxlynx> maybe one of the mods uses it too
[13:39:41] <fuzzie> what complains about it?
[13:39:47] <lynxlynxlynx> [GameScript]: Unhandled trigger code: 0x004b killed(o:object*) <-- after area load
[13:39:52] <fuzzie> i talked about this a week or so ago, the missing important triggers
[13:40:25] <lynxlynxlynx> sendai and the shade lord or lich are the only two default script uses
[13:40:34] <fuzzie> 'detected' is also used
[13:41:54] <lynxlynxlynx> only 3 traps in the same area
[13:42:27] <fuzzie> but there's a lot of stuff which isn't implemented but you don't notice
[13:43:09] <fuzzie> ok, that CaseSensitive case is actually really annoying
[13:43:14] <lynxlynxlynx> ah, yes, amber adds a bunch of killed checks
[13:44:08] <lynxlynxlynx> anything i can help with for the lasttrigger thing?
[13:44:24] <fuzzie> where do you see it used?
[13:44:45] <fuzzie> it is easy to fix for some cases, and problematic elsewhere
[13:47:01] <lynxlynxlynx> this case: http://pastebin.com/W7yxDN7h
[13:47:20] <fuzzie> that shouldn't be affected
[13:48:20] <lynxlynxlynx> the actor does exist, i can see it in the area dump
[13:48:28] <fuzzie> and not dead?
[13:48:50] <lynxlynxlynx> NT Returns true if the active CRE killed the specified object in the last script round. <-- script round == normal round?
[13:48:57] <fuzzie> no
[13:49:04] <fuzzie> this is Killed()?
[13:49:17] <lynxlynxlynx> no
[13:49:22] <lynxlynxlynx> well yes
[13:49:30] <lynxlynxlynx> this NT is killed, the rest is on topic ;)
[13:50:46] <fuzzie> it's just a standard trigger, match trigger_killed
[13:51:33] <fuzzie> tomprince: thoughts on simply removing the CaseSensitive checks in CachedDirectoryImporter?
[13:51:46] <lynxlynxlynx> and it must be alive, since the area dump checks if (!(actors[i]->GetInternalFlag()&(IF_JUSTDIED|IF_REALLYDIED)))
[13:52:06] <fuzzie> it also checks STATE_DEAD?
[13:52:56] <-- dhewg has left IRC (Read error: Operation timed out)
[13:53:11] <lynxlynxlynx> nope
[13:53:28] <lynxlynxlynx> re killed: so just return Sender->MatchTriggerWithObject(trigger_killed, parameters->objectParameter); ?
[13:54:13] <fuzzie> yes
[13:54:26] <fuzzie> won't actually work, since nothing does trigger_killed
[13:55:42] <lynxlynxlynx> mhm
[13:56:31] <fuzzie> i can't imagine we implement Died() properly atm either
[13:56:34] <lynxlynxlynx> nope, no state_dead
[13:56:40] <lynxlynxlynx> re before
[13:57:27] --> dhewg has joined #gemrb
[13:59:05] <tomprince> fuzzie: No benefit to CaseSensitive there.
[14:00:54] <tomprince> Also, I think GemRB puts { on a new line always and only on functions.
[14:05:02] <dhewg> bah!
[14:05:29] <lynxlynxlynx> bah!
[14:05:56] <fuzzie> ok please translate 'bah!' here :p
[14:06:16] <fuzzie> the original engine has a second apply method on effects, and trigger_killed is done in some of those, blah
[14:06:54] <dhewg> 'bah!' in reply to { on newlines
[14:07:06] <dhewg> or: jehova
[14:07:36] <fuzzie> well for now i'll make it consistent
[14:07:36] <dhewg> or: plz dont make me do it, i cant stand it
[14:07:38] <dhewg> :P
[14:08:24] <lynxlynxlynx> we usually use it only like tom said
[14:09:06] <fuzzie> we could really do with magic irc bot
[14:09:08] <CIA-52> GemRB: 03fuzzie * r03d92be9962a 10gemrb/gemrb/plugins/DirectoryImporter/DirectoryImporter.cpp:
[14:09:09] <CIA-52> GemRB: don't try to special-case CaseSensitive in CachedDirectoryImporter
[14:09:09] <CIA-52> GemRB: plus make the whitespace more consistent
[14:12:24] <lynxlynxlynx> so, that exists bit - why do you think lasttrigger shouldn't matter there?
[14:13:17] <lynxlynxlynx> it's matching by scriptname, right?
[14:13:40] <fuzzie> the literal 'LastTrigger' is what matters
[14:14:34] --> gembot has joined #gemrb
[14:16:27] <fuzzie> i don't see how that block would fail
[14:17:04] <lynxlynxlynx> Exists returns 0
[14:18:49] <fuzzie> well, i guess if the area doesn't match
[14:21:43] <lynxlynxlynx> the scriptname doesn't match either
[14:21:57] <lynxlynxlynx> now i have a full dump
[14:22:58] <fuzzie> i mean, disaster might ensue if your locale converts '#' to something else in tolower()
[14:23:47] <Gekz> would a locale really fuck with a hash?
[14:24:15] <fuzzie> you would really hope not, wouldn't you?
[14:24:25] <lynxlynxlynx> trying something else
[14:34:18] <-- gembot has left #gemrb
[14:34:53] --> gembot has joined #gemrb
[14:35:07] <edheldil> # could almost be monetary unit :-)
[14:36:06] <edheldil> fuzzie: wjp could probably ask freenode ppl to run the bot here... or did you rather mean magic git post-commit hook?
[14:36:31] <tomprince> gembot: status all
[14:36:31] <gembot> autotools clang++: idle, last build 5m29s ago: build successful
[14:36:31] <gembot> autotools g++-4.2.4: idle, last build 12m42s ago: build successful
[14:36:31] <gembot> autotools g++-4.4.5: idle, last build 15m34s ago: build successful
[14:36:31] <gembot> autotools g++-4.5.2: building
[14:36:31] <gembot> autotools g++-4.6.0: idle, last build 8m45s ago: build successful
[14:36:32] <gembot> cmake clang++: idle, last build 5m01s ago: build successful
[14:36:32] <gembot> cmake g++-4.2.4: idle, last build 12m45s ago: build successful
[14:36:32] <fuzzie> no, we have magic git post-commit hooks :P
[14:36:33] <gembot> cmake g++-4.4.5: idle, last build 7m07s ago: build successful
[14:36:33] <gembot> cmake g++-4.5.2: idle, last build 9m55s ago: build successful
[14:36:34] <gembot> cmake g++-4.6.0: idle, last build 16m35s ago: build successful
[14:36:34] <gembot> mingw32: idle, last build 5m34s ago: build successful
[14:36:35] <gembot> msvc++6: idle, last build 14m13s ago: build successful
[14:36:37] <fuzzie> i think tomprince is way ahead of me here
[14:36:49] --> mihairu has joined #gemrb
[14:36:59] <fuzzie> i am assuming it'll complain if i break the build again :)
[14:37:30] <tomprince> Hopefully.
[14:38:15] <tomprince> It doesn't seem like there is an option to filter it so only builds triggered by sf are reported, though.
[14:38:35] <fuzzie> hehe, oh dear
[14:38:40] <fuzzie> we'll see how it goes maybe :)
[14:43:47] <lynxlynxlynx> nice coverage
[14:44:49] <tomprince> I would like to add mobile devices.
[14:46:32] <-- mihairu has left IRC (Remote host closed the connection)
[14:47:07] <fuzzie> well, an android build env would require some maintenance, but otherwise simple
[14:47:10] <fuzzie> don't know about the others
[14:49:05] <lynxlynxlynx> we should just port gemrb to html5 and everything will be solved :)
[14:49:22] <fuzzie> yes, html5 support being widely consistent etc :p
[14:49:29] <lynxlynxlynx> btw, i substituted that issue with another
[14:49:53] <fuzzie> oh?
[14:50:57] <lynxlynxlynx> it was a non-issue, silly modder ;)
[14:51:19] <lynxlynxlynx> now i'm stuck in a cutscene, but i only started with debugging
[14:54:33] <lynxlynxlynx> StartCutScene("G#TFCUT1")
[14:54:34] <lynxlynxlynx> DestroySelf() <-- could this kill the started cutscene?
[14:54:55] <fuzzie> no
[14:54:56] <lynxlynxlynx> an invisible observer is used to start it
[14:55:27] <fuzzie> cutscene blocks are handled immediately
[14:55:44] <fuzzie> obviously no blocks ought to run on the observer, though
[14:59:13] <edheldil> what a shame it can't work as an infobot as well
[14:59:43] <fuzzie> an infobot being just what we need?
[15:00:04] <-- lubos has left IRC (Remote host closed the connection)
[15:00:16] <edheldil> that would solve all outr problems ;-)
[15:00:49] <lynxlynxlynx> http://pastebin.com/gGxR0BQr <-- this is what gets started up there, but none of that happens
[15:00:59] <lynxlynxlynx> http://pastebin.com/pnLsybUL <-- this is the caller from above
[15:01:05] <lynxlynxlynx> everything seems to have transpired
[15:01:36] <tomprince> This channel doesn't really have faqs that would make a infobot useful, it doesn't seem to me.
[15:02:33] <fuzzie> lynxlynxlynx: that is an invalid cutscene script
[15:02:47] <lynxlynxlynx> comments?
[15:03:08] <fuzzie> do you know which actor that's meant to run on?
[15:04:37] <lynxlynxlynx> the one that halts? no idea & conceptually it doesn't need anyone to run on
[15:05:04] <fuzzie> it has to run on someone
[15:05:17] <lynxlynxlynx> should that destroyself come into play asap or after the cutscene ends?
[15:05:38] <fuzzie> it runs instantly
[15:05:58] <lynxlynxlynx> maybe it is different in the original
[15:06:01] <fuzzie> no
[15:06:21] <fuzzie> i mean, the problem here is simple, the cutscene has no CutsceneId() --> NULL object
[15:07:11] <lynxlynxlynx> shouldn't it be inherited from the one before that?
[15:07:15] <fuzzie> no
[15:07:34] <lynxlynxlynx> there is none anyway
[15:07:58] <fuzzie> the cutscene object comes from the object parameter of the first action, which is SmallWait() here
[15:08:40] <fuzzie> remove the InDebug check on GameScript.cpp:1902 i guess
[15:10:02] <fuzzie> if this works in the original, then presumably it falls back to some object, but i can't guess which
[15:11:08] <lynxlynxlynx> the message triggers as you expected
[15:15:02] <lynxlynxlynx> what if it takes the id from the first object-using action, not the absolutely first?
[15:15:32] <fuzzie> it doesn't
[15:17:59] <lynxlynxlynx> "G#Tyris" is surely the meant owner there
[15:18:13] <fuzzie> my notes say it removes the first action entirely, Taimon agrees
[15:18:21] <lynxlynxlynx> EquipMostDamagingMelee also shows that the owner is known
[15:18:52] <lynxlynxlynx> i won't argue that it is different, just thinking ahead
[15:18:58] <fuzzie> sure
[15:19:28] <fuzzie> i have no idea how it works, as i said! just i know how it doesn't work :P
[15:20:15] * lynxlynxlynx summons avenger
[15:20:58] <lynxlynxlynx> i'll bypass it for now
[15:21:16] <fuzzie> anyway it can't be G#Tyris
[15:21:20] <fuzzie> because then it wouldn't work
[15:22:52] <fuzzie> since the ActionOverrides work on G#Tyris too
[15:22:54] <lynxlynxlynx> only the two skeletons are left as choices then
[15:23:13] <fuzzie> i imagine it ends up running on the area or game
[15:23:23] <fuzzie> or maybe just a random actor
[15:23:51] <fuzzie> the only commentary on the forums i can find is that this doesn't work properly
[15:26:25] <fuzzie> not v.helpful
[15:26:40] <dhewg> holy crap
[15:27:00] <-- test32894789234u has left #gemrb
[15:27:24] <dhewg> can someone take a look at tlkoverride.cpp and tell me that goto is not insane?
[15:27:36] <tomprince> no.
[15:27:59] <fuzzie> i think all of tlkoverride.cpp has been sealed off with 'do not cross' tape
[15:27:59] <dhewg> no really, who writes stuff like that
[15:28:17] <fuzzie> someone in a hurry to implement :P
[15:28:22] <dhewg> the only reason i can think of is to confuse its readers
[15:28:33] <tomprince> That sounds about right. :)
[15:28:43] <dhewg> ok then it works as intended
[15:29:23] <tomprince> I have a partner on inflicting sane coding on gemrb. yay. :P
[15:29:29] <tomprince> s/on/in/
[15:30:05] <fuzzie> well, 'sane coding' :P
[15:30:21] <tomprince> yes, well... :P
[15:30:26] <tomprince> :)
[15:31:04] <fuzzie> i got a lot more confident about how stuff is *meant* to work in the last 2 years
[15:31:07] <dhewg> i really dont know how you end up with code liek that
[15:31:22] <fuzzie> but i do get annoyed about peopel complaining about Avenger's code
[15:31:26] <dhewg> is that direct REing with bins from insane compilers?
[15:31:29] <fuzzie> no-one else has put in a tiny fraction of the effort
[15:32:52] <dhewg> i bet, but still doesnt stop me from fixing it :)
[15:33:12] <fuzzie> and too much of the proposed 'fixing' changes behaviour
[15:34:50] <fuzzie> my gemrb coding would be much nicer without constructs like that, and impossible without Avenger's code.
[15:37:10] <dhewg> uhm, i didnt mean to attack anyone?
[15:37:31] <fuzzie> "no really, who writes stuff like that" :P
[15:38:44] <fuzzie> you can complain about *my* code all you want, mind
[15:39:00] <dhewg> ok, that may have come out a little wrong :)
[15:39:35] <fuzzie> just Avenger is v.busy person with v.busy job, and we tend to get tangled code-dumps, and they're not good
[15:42:02] --> mihairu has joined #gemrb
[15:43:15] <fuzzie> and i am v.sensitive about the whole thing!
[15:45:09] <edheldil> !coffee fuzzie
[15:45:21] <edheldil> unfortunately does not work either :-P
[15:45:58] <fuzzie> hehe
[15:46:35] <fuzzie> but i'm just tired of losing Avenger's coding for months because someone decided to break the codebase, or someone did a refactoring without good understanding
[15:46:54] <fuzzie> tomprince has worked really hard there, and added msvc6 support to a buildbot and everything
[15:50:23] --> Bo_Thomsen has joined #gemrb
[15:51:01] <tomprince> After spending some time regularly breaking msvc6 ...
[15:52:43] <tomprince> And there are something it doesn't catch, like the fact that it doesn't like function templates specialized on template arguments that aren't also function arguments.
[15:53:13] <fuzzie> and we got rid of the static library alloc issues, although i'd really have preferred that get fixed *before* you broke Avenger's release build for months :P
[15:53:53] <fuzzie> so much better nowadays and stuff like the file handling refactoring makes things like my quick filename cache *so* much easier to add, which is awesome
[15:54:16] <fuzzie> just, gah, i want a working engine already :-)
[15:56:37] <edheldil> write unittests so we can find out when it is 'working' ;-)
[15:57:10] <tomprince> Thats on my todo list.
[15:57:32] <tomprince> And there was somebody in here last week, who did their master thesis on testing.
[16:00:07] --> Maighstir has joined #gemrb
[16:01:26] <fuzzie> we could've caught most recent bugs with fairly trivial 'open file, read data' tests from python, i am just being too lazy to add them
[16:03:20] <-- devurandom has left IRC (Remote host closed the connection)
[16:03:38] --> devurandom has joined #gemrb
[17:17:24] <-- adominguez has left IRC (Quit: Saliendo)
[17:55:25] <CIA-52> GemRB: 03lynxlupodian * r948b22bba2fb 10gemrb/gemrb/core/GameScript/ (GameScript.h Triggers.cpp): added Killed trigger
[17:57:22] <fuzzie> :)
[17:57:40] <fuzzie> maybe worth adding the other used ones, but i didn't look too closely yet
[18:03:30] <lynxlynxlynx> i see what dhewg meant with bag console spam now
[18:03:35] <lynxlynxlynx> shees
[18:04:04] <dhewg> it just cant get enought of the poking
[18:04:55] <fuzzie> needs more bag cache!
[18:05:16] <fuzzie> also i guess if you have mods, it'll probably be worse
[18:17:01] <lynxlynxlynx> only one gem bag
[18:21:01] <fuzzie> i mean, mod scripts
[18:35:01] <lynxlynxlynx> could be
[18:38:17] <-- mihairu has left IRC (Remote host closed the connection)
[18:42:36] <fuzzie> not that there's a lack of crazy in the default scripts
[19:00:25] <lynxlynxlynx> except for that nalia bit, the whole de'arnise was perfect
[19:00:35] <fuzzie> really? nice
[19:01:03] <lynxlynxlynx> i didn't notice whatever was supposed to be wrong with the heightmap or whatwasit anywhere
[19:01:24] <fuzzie> yes, i sabotaged it
[19:01:29] <fuzzie> now we just ignore the heightmap there i think
[19:01:56] <fuzzie> Actor.cpp:5329 if you want to take a look
[19:02:11] <fuzzie> look, it even has a "please fix!" plea
[19:05:52] <fuzzie> oh dear, more bugs from 2004
[19:10:20] <tomprince> https://github.com/tomprince/gemrb/commit/store-hack
[19:10:40] <tomprince> Need to figure out where to call ReleaseAllStores, and need better error handling.
[19:11:02] <fuzzie> 404s?
[19:11:20] <fuzzie> store-cache?
[19:11:40] <tomprince> yes.
[19:11:40] <fuzzie> mm
[19:11:48] <fuzzie> i was saying, i don't like the idea of doing that
[19:12:09] <fuzzie> because CurrentStore is a hack
[19:12:17] <fuzzie> i mean, using it for bags
[19:12:32] <tomprince> Well, the next commit would remove that.
[19:12:50] <fuzzie> without replacing it with more python stuff?
[19:13:16] <fuzzie> i'm just not sure this makes much sense
[19:13:40] <tomprince> Well, I wasn't planning on removing CurrentStore for the store/bag screen.
[19:13:47] <fuzzie> sure
[19:13:51] <tomprince> Just for accesing stores from scripts.
[19:13:55] <fuzzie> but we don't need to cache CurrentStore
[19:14:11] <fuzzie> in fact, we probably *don't* want to
[19:14:24] <fuzzie> but this way we're stuck with caching CurrentStore until we flush the whole lot?
[19:14:50] <tomprince> Well, but if we are caching the store that is opened, we want the cached version.
[19:15:03] <fuzzie> yes
[19:15:04] <fuzzie> sorry
[19:15:08] <fuzzie> wait, maybe i am misunderstanding what this does
[19:15:16] <tomprince> No, the check about GetRefCount > 2 is to catch and free that.
[19:15:28] <fuzzie> your idea here is just to refcount the stores?
[19:15:50] <tomprince> Yes.
[19:15:53] <fuzzie> hm
[19:15:56] <fuzzie> ok, i am an idiot, then
[19:15:58] <fuzzie> and it is perfect
[19:16:02] <fuzzie> here, have a large club to bash me with
[19:17:11] <fuzzie> i think there are two places you want to drop the cache: just before saving, and in loadgame
[19:17:25] <fuzzie> loadgame is called to load the initial game if you go through chargen, so it handles that case
[19:18:12] <fuzzie> sorry, though, misread that in really stuypid way
[19:18:48] <tomprince> np. Not entirely obvious, though not sure how to improve that.
[19:18:55] <fuzzie> i'm not sure what you intend, though
[19:19:15] <fuzzie> seems like you really want a weak pointer here
[19:19:29] <tomprince> Yes, that is what I want.
[19:19:59] <fuzzie> i'm just wondering if you have a plan without one :)
[19:21:04] <fuzzie> sorry, a plan to add one
[19:21:42] <fuzzie> but it looks great as-is and i guess we probably want to be as explicit for stores
[19:22:15] <tomprince> I've considered it.
[19:22:50] <fuzzie> I wonder what it would be useful for?
[19:31:29] <tomprince> Can scripts not affect things in bags?
[19:32:02] <fuzzie> no
[19:32:14] <fuzzie> hm
[19:32:19] <fuzzie> ok, that doesn't make much sense, does it
[19:32:26] <fuzzie> i retract my 'no' and replace it with 'good question'
[19:32:50] <tomprince> I don't see anything in GemRB which does.
[19:33:16] <fuzzie> as far as I remember, there is nothing which affects things in bags other than the guiscript
[19:33:31] <fuzzie> scripts can modify stores
[19:33:43] <fuzzie> and poke through the contents of bags in a read-only way
[19:33:56] <fuzzie> but you would think that scripts would have a way to remove items from bags.
[19:34:58] <fuzzie> and indeed, some of the Take actions are able to
[19:36:24] <fuzzie> just not implemented in gemrb
[19:37:26] <fuzzie> i dread to imagine how they implemented this in the original
[19:38:34] <fuzzie> but i am rather assuming it will be simple to do this properly with your cache :)
[19:38:55] <tomprince> Does it make sense to open the store, whenever we load the corresponding item?
[19:39:17] <tomprince> I am think that we should add a bag field to CREItem.
[19:39:50] <fuzzie> no
[19:40:12] <fuzzie> i'm almost definitely sure this only works for bags on party members
[19:41:22] <tomprince> I am just looking at HasItemCore, and the only thing we have there is the Inventory.
[19:41:24] <fuzzie> so i think even hooking it to inventories would be excessive
[19:42:48] --> mihairu has joined #gemrb
[19:44:52] <fuzzie> i was going to say that you could add a bag flag, but i see that's already commented there
[19:47:01] <tomprince> What is going on with line 272 in core/Store.cpp ? copying a CREItem over a STOItem?
[19:47:05] <tomprince> I guess it works ...
[19:47:07] <fuzzie> yes
[19:47:30] <tomprince> Where would you suggest I store the store then.
[19:47:37] <fuzzie> i don't
[19:47:54] <fuzzie> i rather thought your intention here was to avoid having to do so :)
[19:48:19] <tomprince> no.
[19:48:48] <tomprince> The cache was so we don't get multiple store objects floating around for the same store.
[19:48:52] <fuzzie> ah
[19:49:20] <fuzzie> well, i thought, as a side-effect, you could simply call GetStore() in StoreHasItemCore
[19:49:50] <fuzzie> and then it would magically stay cached until something significant changed and ReleaseAllStores had to be called
[19:50:28] <fuzzie> in the absence of that, storing it in Inventory doesn't seem like it would be too bad, i don't remember non-party-members having STOs littered around
[19:50:55] <fuzzie> nor significant numbers in containers/piles
[19:52:25] <fuzzie> but then you really need a weak pointer.
[19:53:05] <fuzzie> or, no, that isn't true, you could just fill the cache with junk i guess
[19:54:33] <fuzzie> since we don't keep the items around, the stores are pretty small, doesn't matter for mem usage
[19:54:40] <tomprince> I'll think on your suggestion. It might make more sense. In that case we wouldn't need to make Store held.
[19:55:01] <fuzzie> well, i am *really* just rambling out loud :)
[19:55:14] <fuzzie> if i had answers to this, i'd have tried implementing it myself
[19:57:17] <tomprince> Well, the issue with my idea is that a bunch of objects don't have well documented lifetimes.
[19:59:54] <fuzzie> At a *guess*, the original engine is maintaining a read-only cache of party member objects manually, and batching up item removals until a single point in the frame.
[20:03:48] <fuzzie> but given I am unsure of exactly what scripts can even do, I'm pretty sure I'm not a reliable source on lifetimes.
[20:11:54] <tomprince> Updated patch pushed. Untested as always. ;)
[20:15:25] <fuzzie> thanks, will look at it shortly hopefully
[20:23:31] <tomprince> It does decrease the Searching for ...sto spam.
[20:24:09] <tomprince> Now it only does it about once/7 sec.
[20:24:28] <fuzzie> the whole spam?
[20:25:15] <tomprince> It looks like it reopens bags every 7 secs or so.
[20:25:27] <tomprince> Does ChangeStoreMarkup get called periodically?
[20:25:30] <fuzzie> no
[20:25:44] <fuzzie> and an unmodded game should only reopen bags every 10 secs or so in theory
[20:25:47] <fuzzie> maybe not a good theory
[20:32:40] <-- mihairu has left IRC (Remote host closed the connection)
[20:33:18] --> mihairu has joined #gemrb
[20:33:34] <tomprince> It would help if I actually stored the store in the cache. :)
[20:37:34] <tomprince> refreshed. and really working now. I think. ;)
[20:41:50] <fuzzie> umm
[20:42:31] <fuzzie> well
[20:42:39] <fuzzie> calling it SaveStore is nice but then how do we release stores?
[20:43:42] <fuzzie> kinda stops making sense at that point
[20:46:00] <fuzzie> also, i don't think the resref is guaranteed to be lowercase there
[20:46:20] <fuzzie> don't know if you checked that, but if not, might be worth checking or lowercasing for sanity
[20:47:13] <fuzzie> "/// Saves releases a store to the cache and frees it." doesn't make too much sense either
[20:48:17] <fuzzie> and that assert in SaveStore should probably be an abort() since the asserts don't always run
[20:48:56] <fuzzie> and i would comment the "Don't call gamedata->SaveStore" to mention *why*
[20:49:04] <tomprince> The map is case insensitive. And yes, the assert needs fixing.
[20:49:25] <fuzzie> ah :)
[20:49:46] <fuzzie> right, the magical iless
[20:49:58] <fuzzie> it looks ideal though
[20:51:53] <-- mihairu has left IRC (Quit: mihairu)
[20:52:07] --> mihairu has joined #gemrb
[20:54:39] <lynxlynxlynx> is it just me or are GameScript::Detect and ::LOS broken due to that !see ?
[20:54:50] <lynxlynxlynx> Triggers.cpp:2179
[20:55:55] <fuzzie> looks fine?
[20:56:32] <fuzzie> Detect being weird is maybe because I fiddled with it
[20:56:45] <lynxlynxlynx> cansee returns 1 when it /can see/
[20:56:53] <fuzzie> yes
[20:57:01] <lynxlynxlynx> i mean seecore
[20:57:07] <fuzzie> so if return result is false, return false
[20:57:48] <lynxlynxlynx> no, it inverts it
[20:58:07] <lynxlynxlynx> err
[20:58:14] <lynxlynxlynx> ok :)
[20:58:23] <fuzzie> that is horribly unreadable
[20:59:14] <fuzzie> i think tomprince was plotting to replace it all with 'bool'
[21:00:13] <fuzzie> but i need to work out what horrible things ToBEx is doing to the poor OR trigger first
[21:02:11] <lynxlynxlynx> NumberOfTimesTalkedTo <-- this is our TalkCount? I don't get any caseinsensitive matches
[21:02:56] <fuzzie> $ grep 0x4039 trigger.ids.soa
[21:02:56] <fuzzie> 0x4039 NumTimesTalkedTo(I:Num*)
[21:03:56] <CIA-52> GemRB: 03tom.prince * rf7fc4bad02c4 10gemrb/gemrb/ (22 files in 7 dirs): Merge branch 'error'.
[21:03:56] <CIA-52> GemRB: 03tom.prince * rd05b1f47339a 10gemrb/gemrb/ (19 files in 6 dirs):
[21:03:56] <CIA-52> GemRB: logging: Convert print+abort to error.
[21:03:56] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[21:03:56] <CIA-52> GemRB: 03tom.prince * r3e0bed851f64 10gemrb/gemrb/ (4 files in 3 dirs):
[21:03:57] <CIA-52> GemRB: logging: Add a utility function to report and quit on error.
[21:03:58] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[21:04:21] <fuzzie> oh dear
[21:04:24] <fuzzie> so much for my impending merge ;p
[21:04:37] <lynxlynxlynx> thanks
[21:04:40] <tomprince> Oh. Sorry.
[21:04:49] <fuzzie> hehe, no problem
[21:04:53] <fuzzie> i would much rather have error()
[21:06:48] <tomprince> What should I do if we can't save a store? The old code was throwing a runtime error iff the close was triggered by GUIScript, and ignoring it otherwise. Should I just log an error and ignore it?
[21:07:15] <fuzzie> well, ideally we'd pop up a big error dialog
[21:07:35] <fuzzie> it can seriously corrupt your game so i'd be tempted to error()
[21:10:17] <lynxlynxlynx> +1
[21:10:18] <-- wjp has left IRC (Ping timeout: 240 seconds)
[21:10:36] --> wjp has joined #gemrb
[21:23:44] <fuzzie> lynxlynxlynx: you didn't commit the killed triger entry? should I?
[21:24:18] <lynxlynxlynx> sure
[21:24:32] <lynxlynxlynx> didn't notice it until i checked if NumberOfTimesTalkedTo is mentioned at the start
[21:25:45] <fuzzie> i am going to add a minimal implementation for lasttrigger for now
[21:26:03] <tomprince> refreshed, now with error handling.
[21:29:40] <fuzzie> well, sort of :P
[21:30:02] <fuzzie> put the store name in your new error messages?
[21:30:07] <tomprince> k.
[21:31:26] <fuzzie> why do we gain <cstdlib> in StoreMgr.h?
[21:31:31] <tomprince> size_t
[21:31:50] <tomprince> I can get rid of that, since I dropped it after.
[21:31:53] <fuzzie> ah
[21:32:31] <fuzzie> i'm not so much in favour of these "remove code, since we can always put it back, and then disable code used by the first bit" commits
[21:34:11] <fuzzie> not because i want the code left, but because it's unclear that the "nobody needs"/unused stuff was actually used, just not usefully
[21:36:14] <mihairu> hi all...is bg1 playable with gemrb?
[21:36:23] <fuzzie> it is completeable
[21:37:03] <fuzzie> not sure what may be broken.
[21:38:59] <lynxlynxlynx> it is harder than the original due to the spawns, but some would consider that a bonus
[21:40:04] <CIA-52> GemRB: 03fuzzie * r9309f7874506 10gemrb/gemrb/core/GameScript/GameScript.cpp: set TF_CONDITION and some related tidying
[21:40:05] <CIA-52> GemRB: 03fuzzie * r411e99db4a4a 10gemrb/gemrb/core/GameScript/GameScript.cpp: add reference to new Killed trigger function
[21:40:05] <CIA-52> GemRB: 03fuzzie * rb5566de8d58c 10gemrb/gemrb/core/ (3 files in 2 dirs): load/use svtriobj
[21:41:19] <tomprince> Is the commit message better now?
[21:42:33] <fuzzie> that is clearer, thankyou!
[21:45:08] <fuzzie> InitializeIEScript() is turning into a huge mess
[21:45:09] <CIA-52> GemRB: 03fuzzie * r4a627e0e6150 10gemrb/gemrb/core/ (GUI/GameControl.cpp Map.cpp Scriptable/Scriptable.cpp): remove some unneeded LastTrigger-related code
[21:47:05] <lynxlynxlynx> maybe this fixes part of the trap problems
[21:47:35] <fuzzie> i tested with the traps in the chateau and they seemed ok
[21:48:01] <lynxlynxlynx> cool
[21:48:24] <lynxlynxlynx> now there was no payload
[21:48:49] <lynxlynxlynx> i forgot to mention, i'm noting bugs here: http://gemrb.sourceforge.net/wiki/doku.php?id=soa_playthrough_bugs#mod_run
[21:49:01] <lynxlynxlynx> uncategorised and with some known stuff
[21:50:48] <fuzzie> modal actions run every 100 adjusted ticks
[21:51:15] <fuzzie> and then fail on CONFUSED, DEAD, HELPLESS, STUNNED, PANIC, BEZERK and SLEEP, and also there's a timestop owner check.
[21:51:31] --> barra_home has joined #gemrb
[21:51:34] <lynxlynxlynx> adjusted?
[21:51:40] <fuzzie> hasted/slowed
[21:51:45] <lynxlynxlynx> right
[21:51:54] <fuzzie> 'AdjustedTicks'
[21:52:16] <fuzzie> i didn't actually commit the code which hastes/slows that yet though
[21:52:29] <lynxlynxlynx> cool, we already have part of it
[21:52:41] <fuzzie> i guess that 100 is another instance of round size..
[21:52:51] <lynxlynxlynx> yep
[21:53:15] <fuzzie> oh yes, i remember, the modal stuff is broken :(
[21:54:46] <fuzzie> anyway i just thought i'd dump that on irc, in case i don't get to fixing it myself
[21:55:10] <fuzzie> the only other notes i haveabout the function are that it maintains a ModalTicks count, and that secret door detection is InParty-only
[21:55:24] <fuzzie> and i already dumped the secret door detection probabilities into irc before i think :)
[21:56:29] <lynxlynxlynx> class/race?
[21:56:40] <lynxlynxlynx> silly details
[22:00:05] <fuzzie> yes
[22:00:23] <fuzzie> the only important bit is the 100% prob when finding traps
[22:01:13] <fuzzie> but i figured the rest might be cute
[22:06:42] <lynxlynxlynx> someday
[22:06:55] <lynxlynxlynx> i think we already do the first bit
[22:07:31] <fuzzie> no
[22:08:06] <fuzzie> i'm not really sure what we're doing there
[22:08:53] <fuzzie> so, maybe :P
[22:08:59] <fuzzie> going via fx_find_traps is too indirect for me to work it out
[22:10:56] <lynxlynxlynx> due to the timing and/or range we find things too fast
[22:11:33] <lynxlynxlynx> but zzz
[22:11:57] <fuzzie> ninight :)
[22:12:07] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:12:29] <fuzzie> tomprince: you're considering committing store stuff as-is?
[22:36:54] <tomprince> fuzzie: yes.
[22:40:11] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[22:45:53] <fuzzie> if it works for you i would just do so, then
[22:45:59] <-- mihairu has left IRC (Ping timeout: 240 seconds)
[22:46:01] <fuzzie> i thught i'd have time to try it, but seems not
[23:10:43] <tomprince> 'cept it is broken loading a game, if there are any cached stores. Silly char* that point to garbage. :(
[23:17:55] <-- barra_home has left IRC (Quit: Verlassend)
[23:19:46] <tomprince> fuzzie: https://gist.github.com/945451
[23:56:27] --> mihairu has joined #gemrb