[00:02:21] --> mihairu has joined #gemrb
[00:09:46] <-- mihairu has left IRC (Read error: Connection reset by peer)
[00:43:48] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[01:08:34] --> pupnik has joined #gemrb
[01:09:41] <-- pupnik_ has left IRC (Read error: Operation timed out)
[01:27:25] --> mihairu has joined #gemrb
[01:38:14] --> jojohnon has joined #gemrb
[01:39:24] <jojohnon> hello i dont know if this is the place to ask this question. do anyone know if it is possible to compile gemrb on iphone?
[01:40:39] <tomprince> I believe there was a video on the forum. But I don't know if it was real, and if so, it didn't have instructions.
[01:42:19] <jojohnon> i have tried to compile it a few months ago but it failed. i dont remember the error message.
[01:59:13] <-- mihairu has left IRC (Remote host closed the connection)
[02:11:48] <tomprince> I don't think anybody here know anything about compiling for iphone, but if you have gemrb specific issues we can try to help.
[02:12:23] <tomprince> We do have some support for android.
[02:14:34] <tomprince> You'll need to get at least SDL and python working. And if you want sound, either openal or sdl-mixer.
[02:15:41] <tomprince> You'll also need zlib, but if you can get the others working, getting zlib to work is trivial.
[03:17:15] --> mihairu has joined #gemrb
[07:17:55] --> adominguez has joined #gemrb
[07:24:12] --> lynxlynxlynx has joined #gemrb
[07:24:12] <-- lynxlynxlynx has left IRC (Changing host)
[07:24:12] --> lynxlynxlynx has joined #gemrb
[07:24:12] --- ChanServ gives channel operator status to lynxlynxlynx
[07:28:38] --> edheldil has joined #gemrb
[07:28:38] --- ChanServ gives channel operator status to edheldil
[08:57:55] <-- Gekz has left IRC (Remote host closed the connection)
[08:59:24] --> Gekz has joined #gemrb
[09:29:30] <fuzzie> moo.
[09:45:16] <edheldil> (__)
[09:45:16] <edheldil> (oo)
[09:45:16] <edheldil> /------\/
[09:45:16] <edheldil> / | ||
[09:45:16] <edheldil> * /\---/\
[09:45:16] <edheldil> ~~ ~~
[09:45:18] <edheldil> ...."Have you mooed today?"...
[09:52:49] <dhewg> yo
[10:19:53] --- pupnik is now known as JHVH-1
[10:36:32] <-- Gekz has left IRC (Remote host closed the connection)
[11:00:02] --> Gekz has joined #gemrb
[11:43:29] <-- mihairu has left IRC (Remote host closed the connection)
[11:52:57] <-- JHVH-1 has left IRC (Remote host closed the connection)
[12:40:29] --> mihairu has joined #gemrb
[13:14:10] <tomprince> edheldil: Do you want to point buildbot.gemrb.org at gemrb.hocat.ca?
[13:21:04] <edheldil> heh, not until now. Do you rather mean you want me to do it? ;-)
[13:24:36] <tomprince> Yes.
[13:25:02] <-- devurandom has left IRC (Read error: Operation timed out)
[13:25:26] <edheldil> almost done ... but are you areal Tom? :)
[13:25:40] <edheldil> THE real ...
[13:26:35] <tomprince> ?
[13:26:37] <tomprince> yes
[13:29:31] <edheldil> added, but not active yet
[13:38:50] --> Bo_Thomsen has joined #gemrb
[13:43:19] <tomprince> up.
[14:02:56] <tomprince> http://buildbot.gemrb.org/binaries/GemRB-latest.zip <-- somebody want to try that out in ~10 minutes, and then add it to the wiki?
[14:03:26] <Gekz> which OS?
[14:03:31] <tomprince> win32
[14:03:41] <Gekz> might want to put that in the filename
[14:03:52] <Gekz> GemRb-win32-latest.zip
[14:04:22] <lynxlynxlynx> mhm
[14:04:49] <tomprince> makes sense. will do, next time I update the bb config.
[14:10:46] <jojohnon> iwe gotten python working. only zlib and SDL left to get
[14:15:37] <CIA-52> GemRB: 03tom.prince * r43d5b96e5e45 10gemrb/CMakeLists.txt:
[14:15:37] <CIA-52> GemRB: mingw: Don't pass -fvisibility, since it isn't supported.
[14:15:37] <CIA-52> GemRB: Symbols are hidden by default anyway, on win32.
[14:15:37] <CIA-52> GemRB: Signed-off-by: Tom Prince <email@example.com>
[14:16:49] <tomprince> That should cleanup the 2108 warning that generates. :)
[14:18:50] <lynxlynxlynx> http://lynxlynx.info/bugs/iwd2stylecombat.jpg <-- first gemrb-only (weidu) mod :)
[14:20:01] <fuzzie> hi
[14:20:29] <fuzzie> we should support bg2-style combat debugging maybe :)
[14:22:47] <fuzzie> nice though
[14:24:46] <tomprince> http://buildbot.gemrb.org/binaries/GemRB-win32-latest.zip is up.
[14:27:02] <lynxlynxlynx> you mean the more detailed rolls and all?
[14:27:07] <fuzzie> yes
[14:27:19] <fuzzie> i just trust your code, honestly..
[14:27:28] <lynxlynxlynx> but that would require us to fix our combat :)
[14:27:46] <lynxlynxlynx> we have no notion of natural ac now
[14:27:56] <fuzzie> well, i don't know how it's meant to work :P
[14:28:02] <lynxlynxlynx> but that'll be nastier for iwd2
[14:28:21] <fuzzie> well, iwd2 changes a *lot* of subtle stuff..
[14:28:32] <edheldil> Orc throws d20 die. The die hops over the table, ricochets from the Coke bottle and falls from the table, rolls under the wardrobe and vanishes
[14:28:43] <edheldil> ^^^ detailed rolls
[14:28:55] <fuzzie> but then i guess we don't even get round times right in bg2 right now
[14:30:17] <fuzzie> i looked at that and the 2da ever-so-helpfully defines things in seconds :P
[14:32:16] <lynxlynxlynx> it's using multiplication
[14:32:42] <lynxlynxlynx> from the spell data rounds do look second based
[14:32:51] <fuzzie> they're not, though
[14:33:08] <fuzzie> in bg2 they're 100 ticks, 6.66s
[14:34:45] <lynxlynxlynx> heh
[14:34:56] <fuzzie> i figured i'd check the original's poison/regen code to see how the RPD_ROUNDS works, but it turns out that's just broken in original
[14:35:17] <lynxlynxlynx> yeah, some of those are bad
[14:35:29] <fuzzie> but it's all hardcoded constants, basically
[14:36:18] <fuzzie> for combat rounds, pst uses 50, bg2 uses 100. for magic rounds, bg2 uses 100. i don't know what else i'd check..
[14:38:31] <fuzzie> but would appreciate ideas
[14:41:52] <fuzzie> since i don't want to go messing with this stuff again without a clear idea..
[14:42:24] <fuzzie> but it is a necessary prerequisite to what I *can* contribute to the combat code, which is fixing the anim/projectile timing.
[14:44:15] <fuzzie> oh, what i did find is Ascension64 saying that e8 has a delay of 100 ticks on its own trigger evaluating
[14:44:29] <fuzzie> (as opposed to HitBy etc)
[14:44:41] <fuzzie> which seems like a mighty suspicious value, but maybe just random
[14:50:12] <lynxlynxlynx> i don't think any other rounds are in play
[14:50:46] <lynxlynxlynx> do we understand the combat counter 45 and the other values?
[14:50:55] <lynxlynxlynx> or was it -45
[14:51:06] <fuzzie> not really
[14:51:16] <fuzzie> i mean, Avenger is quite right about the values, but they're mysterious :)
[14:53:13] <lynxlynxlynx> well, i've got everything set up for the next playthrough
[14:53:42] <lynxlynxlynx> i'll just start and go to some of the areas unvisited before
[14:53:43] <fuzzie> what are you intending to play?
[14:53:48] <fuzzie> SoA?
[14:53:55] <lynxlynxlynx> soa full party
[14:54:13] <lynxlynxlynx> patched and fixpacked, 5 mod npcs
[14:54:51] <lynxlynxlynx> it seems we don't abort spellcasting on taking damage (anymore?) though, so maybe i'll look at that first
[14:55:03] <lynxlynxlynx> not sure yet
[14:56:20] <lynxlynxlynx> one mod is already causing problems though
[14:56:24] <lynxlynxlynx> [MUSImporter]: Loading /home/lynx/ie/modded-bg2/music/m#blank.mus...[FOUND]
[14:56:24] <lynxlynxlynx> [ResourceManager]: Searching for Blank/BlankA... Blank/BlankA.acm...[Music]
[14:56:24] <lynxlynxlynx> Playing: Blank/BlankA
[14:56:31] <lynxlynxlynx> ALL the time
[14:56:53] <lynxlynxlynx> not sure what they wanted to achieve
[14:57:33] <fuzzie> it doesn't hack exe?
[14:58:22] <lynxlynxlynx> no, older mod
[14:58:36] <lynxlynxlynx> but i see all these npcs append some blankly named thing to songlist.2da
[14:58:55] <lynxlynxlynx> only amber's is problematic
[14:59:30] <fuzzie> > The current method of switching off the game music for the duration is to add a blank entry to the songlist, using WeiDU's ADD_MUSIC, facility to make use of the blank music file that BioWare kindly provided.
[14:59:33] <lynxlynxlynx> i'll try just removing that line
[14:59:54] <fuzzie> oh ugh
[15:00:07] <lynxlynxlynx> but we shouldn't queue it so often
[15:00:09] <fuzzie> so it looks like people don't want to actually distribute .acm files, because they're large
[15:00:15] <fuzzie> and no-one could be bothered to make a ogg->acm tool
[15:00:37] <lynxlynxlynx> it's appended as the first entry, i hope it isn't special
[15:00:37] <fuzzie> so stuff like romances just does PlaySound() on a WAV, and suppresses the music while doing so
[15:00:52] <fuzzie> it is special :P
[15:00:53] <lynxlynxlynx> heh
[15:01:38] <fuzzie> sometimes i'm really astonished by the effort people go to, just to support their hacks on top of hacks on top of hacks
[15:02:30] <fuzzie> although after Detectable Spells, i guess nothing should be surprising
[15:03:39] <tomprince> what is wrong with detectable spells?
[15:03:52] <fuzzie> it overwrites a whole bunch of used stats
[15:03:59] <tomprince> For us, we can just play oggs as music. :)
[15:04:11] <fuzzie> depending on which version is shipped with whichever mod you're using, of course..
[15:04:45] <fuzzie> i haven't been keeping up with whether it's corrupting less stuff recently
[15:06:40] <fuzzie> the sane thing to do is to get rid of the whole thing
[15:07:07] <fuzzie> hopefully they'll make that happen and we can just implement whichever triggers they end up with
[15:08:01] <lynxlynxlynx> so anything reasonable i can do about the mus stuff?
[15:08:11] <fuzzie> i have no idea how it works
[15:08:31] <lynxlynxlynx> ok
[15:08:36] <fuzzie> is it just looping as you state, no message about end-of-music?
[15:08:51] <lynxlynxlynx> just looping
[15:11:13] <fuzzie> so, no idea off the top of my head
[15:11:27] <lynxlynxlynx> huh, something broke since yesterday
[15:11:44] <lynxlynxlynx> gemrb doesn't start anymore :)
[15:12:31] <fuzzie> bad paths in config? :P
[15:13:47] <lynxlynxlynx> it is only broken if auto gametype is used
[15:14:13] <lynxlynxlynx> it resolved correctly, but then isn't tried
[15:15:01] <fuzzie> ah
[15:15:01] <lynxlynxlynx> http://pastebin.com/pixKGkTU
[15:15:02] <fuzzie> yes
[15:15:10] <fuzzie> make an 'override/auto' dir
[15:15:52] <lynxlynxlynx> that's enough
[15:21:06] <fuzzie> should check for failures there
[15:22:29] <fuzzie> going to go lie down for a bit.
[15:36:04] <-- mihairu has left IRC (Remote host closed the connection)
[16:17:30] <edheldil> eh? override/auto? I will have to look at the commits :)
[16:18:15] <fuzzie> your autodetect patch adds 'override/auto' to the search path
[16:18:22] <fuzzie> then later overwrites that with override/<gametype>
[16:19:09] <fuzzie> but i added a patch from dhewg which doesn't add non-existant dirs to the search path, to stop gemrb from wasting time checking nonexistant directories
[16:19:39] <fuzzie> hadn't considered the idea that you'd deliberately added nonexistant directories :-P
[16:22:25] --> SiENcE has joined #gemrb
[16:22:28] <edheldil> I think that the problem could be that I later muck with the path with pop() and insert(), so juct changing THAT could be enough. but I can't check atm
[16:22:37] <fuzzie> no
[16:22:45] <fuzzie> i mean, you try overwriting the first version
[16:22:55] <fuzzie> but the first one doesn't exist, so you can't overwrite it..
[16:23:09] <edheldil> ah, ok.
[16:23:39] <fuzzie> not sure of best way to resolve that
[16:24:02] <fuzzie> if having an override/auto isn't acceptable
[16:24:32] <-- SiENcE has left IRC (Client Quit)
[16:24:38] <edheldil> seems like an ugly hack
[16:24:45] <edheldil> I will look at it later
[16:24:49] <edheldil> bye
[16:24:52] <fuzzie> bye!
[16:27:37] --> test32894789234u has joined #gemrb
[16:35:38] <lynxlynxlynx> we do kill too many effects on ctrl-r
[16:35:51] <lynxlynxlynx> a permanent stat modifier effect gone
[16:38:01] --> mihairu has joined #gemrb
[16:57:15] <dhewg> are bif files only used via chitin.key?
[17:00:49] <-- adominguez has left IRC (Quit: Saliendo)
[17:03:06] <lynxlynxlynx> pretty sure, can't think of any other way
[17:09:06] <fuzzie> dhewg: are you working on something?
[17:09:20] <dhewg> poking a little
[17:09:29] <fuzzie> lynxlynxlynx: truly-permanent effects really shouldn't be removed
[17:09:37] <dhewg> i think i'll try to whip up some cache stuff
[17:09:43] <fuzzie> ok
[17:09:55] <fuzzie> well that was my plan for now but i am happy to fight the shade lord instead, thanks :P
[17:10:05] <dhewg> :)
[17:10:09] <fuzzie> my thought was to add a Cache() function to the base class
[17:10:11] <lynxlynxlynx> half of the timing modes are some kind of permanent, but we don't consider the most common one as such
[17:10:25] <fuzzie> and then call it unless a 'no caching' flag is passed to AddSource
[17:10:46] <fuzzie> lynxlynxlynx: i thought we considered everything except 'permanent but don't save'
[17:11:07] <lynxlynxlynx> grep for the fx_removable array
[17:11:16] <dhewg> was gemrb a c project once?
[17:11:18] <fuzzie> well i can't interpret that at sight :)
[17:11:30] <lynxlynxlynx> you can count :=)
[17:11:34] <fuzzie> dhewg: no, but it was a no-STL project
[17:11:58] <dhewg> but i can use stl stuff for new code, right?
[17:12:10] <fuzzie> as long as it actually works
[17:12:15] <dhewg> heh
[17:12:20] <dhewg> oh btw
[17:12:28] <dhewg> i got another crash
[17:12:30] <fuzzie> e.g. no using hash stuff which isn't in the standard
[17:13:05] <dhewg> crash happens when going from act 3 to 4
[17:13:08] <dhewg> that ship sequence
[17:13:14] <fuzzie> for the cache i think just a std::map<> from lowercase->realname would be trivial way to see if it works
[17:13:26] <dhewg> it crashes in Map::UpdateScripts() because some actors in that queue are 0
[17:13:40] <fuzzie> on which map?
[17:13:49] <dhewg> i add "if(!actor)" checks everywhere, which fixes it
[17:14:05] <dhewg> but im not sure if that update call is supposed to be there for this sequence?
[17:14:14] <fuzzie> it is
[17:14:22] <fuzzie> but the queue is not meant to have nulls in it :P
[17:14:35] <dhewg> heh
[17:14:36] <dhewg> or that :P
[17:14:46] <fuzzie> fixing it that way might result in corrupt game
[17:17:10] <fuzzie> i think if queue has nulls in it then it must've been corrupted
[17:17:29] <dhewg> lemme retry, done have a save at that spot
[17:19:16] <dhewg> cutscene mania
[17:19:27] <dhewg> but uhm
[17:19:41] <dhewg> i finished every quest i found now :)
[17:19:54] <fuzzie> you clearly missed too many :P
[17:20:30] <dhewg> well, i bet there's more, but up to act 4 i did everything i found
[17:20:48] <fuzzie> there is an issue with the spellhold dream sequence
[17:21:00] <dhewg> i mentioned that :P
[17:21:04] <fuzzie> but can be resolved by save/load for example
[17:21:20] <fuzzie> i mean, the one when you're in spellhold :-P
[17:21:31] <dhewg> ok, im not there yet :P
[17:21:40] <fuzzie> yes hence why i mention :)
[17:21:42] <dhewg> i meant the act2 -> 3 sequence
[17:21:50] <dhewg> the camera is totally off
[17:22:04] <dhewg> its at (0,0) or something where the party is warped
[17:22:05] <fuzzie> yeah, someone fiddled with center-on-actors a while ago and broke it
[17:22:10] <dhewg> but the action is like on the other end
[17:22:14] <fuzzie> because now it centers on the party when it's not meant to
[17:24:06] <dhewg> gah
[17:24:21] <lynxlynxlynx> hmpf, another death due to hp
[17:24:32] <dhewg> you can quicksave on cutscenes, which breaks the game when loading :)
[17:24:59] <dhewg> also, the cutscene fading is brokeb
[17:25:02] <dhewg> *broken
[17:25:09] <lynxlynxlynx> the minhp effect isn't applied yet at that point
[17:25:23] <dhewg> it doesnt fade to really-black, you can see actors being warped
[17:25:35] <fuzzie> you can break the original in all kinds of ways by saving in dumb places anyway
[17:25:42] <dhewg> heh
[17:25:53] <dhewg> well i saw the epic TODOs in the savegame code :P
[17:26:17] <fuzzie> yeah, but they're really not foolproof
[17:26:37] <dhewg> hmpf, now it doesnt crash
[17:26:47] <lynxlynxlynx> hp overflowed :s
[17:26:52] <dhewg> i thinl it was ar1600
[17:31:19] <fuzzie> but in general way too much of gemrb was written when not understanding stuff
[17:31:41] <fuzzie> so would not trust TODOs other than as a 'something needs to be done here'
[17:37:25] <fuzzie> well now you derailed my plans for the cache thing, i wonder what to do
[17:37:38] <dhewg> hah
[17:37:44] <dhewg> proper animations!
[17:38:12] <fuzzie> assuming my spare time today is not measured in weeks
[17:38:24] <-- jojohnon has left #gemrb
[17:38:53] <dhewg> didnt you already reverse much of whats missing?
[17:39:04] <dhewg> and even had a plan how to implement/fix it?
[17:39:48] <fuzzie> i reversed one subclass of some 16 total :P
[17:42:32] <dhewg> whats a .cbf?
[17:43:43] <fuzzie> compressed biff
[17:44:40] <fuzzie> they're the ones you get the progress bar for, on the console
[17:45:07] <dhewg> but those in bg2 are actually named .bif
[17:46:13] <dhewg> does this line "PluginHolder<ArchiveImporter> ai(IE_BIF_CLASS_ID)" create a new instance of a plugin?
[17:46:25] <fuzzie> yes
[17:46:40] <-- mihairu has left IRC (Ping timeout: 248 seconds)
[17:46:43] <dhewg> so its no problem to have multiple instances of one plugin at the same time?
[17:46:50] <fuzzie> well
[17:46:59] <fuzzie> it depends what kind, obviously
[17:47:11] <dhewg> bif in this case
[17:47:20] <fuzzie> but you can have as many resource plugins as you want
[17:47:46] <fuzzie> but if you want to start keeping bif files open, you have to actually write some serious logic
[17:48:20] <dhewg> i thought about a hashed list in the keyimporter
[17:48:41] <dhewg> because that knows in which bif to look for stuff
[17:49:57] <dhewg> if something is in the local cache it still gets precendence, right?
[17:50:07] <dhewg> its that order from interface.cpp afaict
[17:50:30] <fuzzie> yes
[17:50:59] <fuzzie> but i don't see the keyimporter taking up anything significant in the profile, after load time
[17:51:51] <dhewg> well
[17:51:59] <fuzzie> where it spends much too time building the Hash List Which Must Die™
[17:52:03] <dhewg> just trying stuff with common new classes
[17:52:15] <dhewg> if this doesnt work out there's still a hash list for reuse
[17:52:38] <dhewg> but what im seeing is, that looking up biff members sucks
[17:52:43] <fuzzie> does it?
[17:52:56] <fuzzie> i mean, that *is* a hash, afaicr
[17:52:56] <dhewg> well it pokes through 43k entries in a row :P
[17:53:00] <dhewg> no
[17:53:04] <dhewg> its an array
[17:53:08] <dhewg> the biff one
[17:53:12] <dhewg> i already fixed that
[17:53:24] <dhewg> but that 1 biff open cache in keyimporter is not enought
[17:53:29] <fuzzie> oh, the bif one
[17:53:31] <fuzzie> no?
[17:53:32] <dhewg> its switching it back and forth
[17:53:40] <dhewg> just move on the map
[17:53:57] <dhewg> it loades tiles from x.bif then it wants bag.itm form items.bif
[17:54:06] <fuzzie> sure
[17:54:20] <fuzzie> but are you going to write a serious cache system there?
[17:54:31] <dhewg> no, not yet
[17:54:53] <dhewg> just a std::map for bif and a LRU big cache in the keyimporter
[17:54:59] <fuzzie> i don't think i'd want to merge anything which kept bif files without one
[17:55:01] <dhewg> i think that should already help
[17:55:19] --> mihairu has joined #gemrb
[17:55:26] <fuzzie> but, ok
[17:55:27] <dhewg> why?
[17:55:45] <dhewg> its just a nochanging container
[17:55:48] <fuzzie> because i don't want to hardcode in stupid assumptions
[17:56:01] <fuzzie> if i delete a bif file from the cache, it should die
[17:56:20] <fuzzie> even my cache code really sucks there
[17:57:58] <dhewg> how do you mean?
[17:58:03] <fuzzie> well
[17:58:03] <dhewg> delete manually?
[17:58:16] <fuzzie> well, right now, we let the Cache size bloat incredibly
[17:58:16] <dhewg> gemrb doesnt wipe decompressed bifs from the cache, does it?
[17:58:20] <fuzzie> unless you start deleting things manually
[17:58:22] <fuzzie> that isn't ok, though
[17:58:31] <fuzzie> and i wouldn't want to merge stuff that makes it even more of a pain to implement that
[17:58:43] <dhewg> hehe sure
[17:59:12] <fuzzie> but that's all
[17:59:17] <dhewg> but thats because the file cache is stupid
[17:59:27] <dhewg> it doesnt keep state at all
[17:59:34] <fuzzie> sure
[17:59:41] <fuzzie> but you're not implementing a file cache?
[18:00:09] <dhewg> isnt the first idea
[18:00:19] <dhewg> well, lemme try stuff
[18:00:25] <fuzzie> sure
[18:00:36] <fuzzie> i mean, i haven't seen the BIF stuff showing up as a performance issue at all
[18:00:36] <dhewg> i suspect that this helps alot
[18:00:51] <dhewg> if thats the case making the filecache keep state is simple
[18:01:12] <fuzzie> but am still very confused as to what you're doing, so shall leave you to it
[18:01:20] <dhewg> and then it can be a cache with a max size too, which closes a bif on demand
[18:02:42] <fuzzie> i thought you were looking at the STO stuff, so :)
[18:13:19] <dhewg> erm yeah
[18:13:38] <dhewg> i just looked around and "noticed stuff" ;)
[18:13:47] <fuzzie> sure
[18:13:56] <fuzzie> crazy BIF stuff is an obvious target
[18:14:04] <fuzzie> just not very helpful for that problem, considering :P
[18:14:11] <dhewg> yeah
[18:15:36] <fuzzie> just you can probably imagine that i'm a bit tired of half-baked solutions at this point
[18:16:01] <dhewg> hehe
[18:16:07] <fuzzie> maybe not a v.sensible attitude for getting stuff done
[18:16:14] <dhewg> i wont force you to pick/merge anything
[18:16:37] <dhewg> im just thinking a proper cache solution need to touch multiple things
[18:17:04] <fuzzie> yes, a lot of things
[18:17:42] <fuzzie> i'm pretty sure i was rambling about that, how a file cache in directoryimporter was an awesome idea because it could be implemented pretty simply without changing behaviour
[18:18:17] <dhewg> the idea to store where a file was found?
[18:18:25] <fuzzie> no
[18:19:01] <fuzzie> just a per-directory list of files, a map from lowercased version to actual name
[18:19:40] <fuzzie> to avoid all the expensive fs checks
[18:19:53] <fuzzie> if you are not doing that, i should
[18:20:44] --> barra_home has joined #gemrb
[18:20:52] <dhewg> if you want
[18:21:00] <dhewg> i could, if you want me to
[18:21:13] <dhewg> since i try to do this hash thing in a reusable way
[18:22:06] <fuzzie> well, if you want to implement a decent hash, you should try replacing the existing one
[18:22:44] <dhewg> the hash func itself is ok
[18:22:46] <fuzzie> it has possible copyright issues
[18:22:52] <dhewg> that fictionary is weird though
[18:22:58] <dhewg> -f+d
[18:23:02] <fuzzie> if i remember correctly
[18:23:16] <dhewg> thats the glibc version you got there in keyimporter
[18:23:44] <dhewg> i mean libstdc++
[18:24:03] <fuzzie> well, you might know better than me :)
[18:24:19] <dhewg> i recognize that "<< 5" :P
[18:24:41] <dhewg> its used in the hash_map impl in libstdc++
[18:32:20] <fuzzie> i am also v.wary of this stuff because obviously subtle bugs in this code tend to cause days of confusion trying to fix game logic
[18:32:24] <fuzzie> need more tests
[18:36:33] <fuzzie> whoo, killed Thaxll'ssillyia.
[18:37:24] --> barra_away has joined #gemrb
[18:40:47] <-- barra_home has left IRC (Ping timeout: 250 seconds)
[18:41:28] --- barra_away is now known as barra_home
[18:42:04] <lynxlynxlynx> cool, what was the problem?
[18:44:17] <fuzzie> i am just messing with a bunch of hacks
[18:44:19] <fuzzie> didn't work before?
[18:45:05] <lynxlynxlynx> i don't know
[18:45:40] <fuzzie> buggy still :)
[18:45:48] <fuzzie> but gemrb really gets better
[18:48:34] <lynxlynxlynx> :)
[18:50:30] <fuzzie> although must commit svtriobj stuff
[18:54:54] <lynxlynxlynx> this mod cutscene is all kinds of suboptimal
[18:56:12] <fuzzie> oh?
[18:57:31] <lynxlynxlynx> we probably have an inventory bug, but the script itself is oddly written
[18:59:18] <lynxlynxlynx> nevermind for now
[18:59:37] <lynxlynxlynx> the bug result is funny though
[19:00:11] <lynxlynxlynx> the cutscene destroys the npcs favourite weapon and she is coded to bark if the item is put to the ground
[19:00:24] <lynxlynxlynx> so it's bark bark bark
[19:00:42] <-- test32894789234u has left #gemrb
[19:00:54] <fuzzie> o.O
[19:38:25] <fuzzie> ok, gemrb is just annoying me now
[19:47:39] <fuzzie> let's go look at the original's spell actions!
[19:54:45] <lynxlynxlynx> i found my problem
[19:55:27] <lynxlynxlynx> the freshly created item has the stacked bit set and the counting trigger takes that into account, so a removal block triggers (was there to make sure you have only one weapon)
[19:55:55] <dhewg> uhm
[19:55:58] <dhewg> funky
[19:56:05] <dhewg> weird results over here :P
[19:56:49] <lynxlynxlynx> welcome to the club :)
[19:56:59] <dhewg> no i mean, i removed lots of code
[19:57:06] <dhewg> and it works and its faster
[19:57:10] <fuzzie> removed code is debugged code? :P
[19:57:16] <dhewg> no :P
[19:57:27] <dhewg> plugins/KEYImporter/Dictionary.cpp has left my repo
[19:57:37] <fuzzie> replaced with what? :)
[19:57:49] <fuzzie> i think removed lots of code probably doesn't count if you add lots of code too
[19:57:50] <dhewg> a totally trivial hashmap template
[19:57:55] <dhewg> based on std::map
[19:58:17] <fuzzie> have to be careful with those
[19:58:19] <dhewg> and without measuring anything, the ResourceManager console output is faster :P
[19:58:55] <dhewg> yeah, lots of small allocs and stuff
[19:59:00] <dhewg> but works fine here
[19:59:01] <fuzzie> i mean, with templates at all
[19:59:16] <dhewg> because of msvc6?
[19:59:19] <fuzzie> yeah. e.g. you can't use templates which differentiate on typename and you can't partially specialise
[19:59:38] <dhewg> uhm
[20:00:10] <fuzzie> sorry, i should say, differentiate on typename and other stuff :P
[20:00:12] <dhewg> im not sure it falls into this category
[20:00:25] <dhewg> its just template<class T> class HashMap
[20:00:32] <dhewg> nothing more, obviously with T used
[20:00:32] <fuzzie> should be fine
[20:01:25] <fuzzie> also define 'works fine here', what kind of system? :P
[20:02:11] <dhewg> that means i tested it with one compiler on one box, and i didnt took numbers, it just feels faster :D
[20:02:36] <fuzzie> the profiler says the tolower() is the problem with our current code
[20:02:44] <dhewg> lol
[20:03:21] <fuzzie> but i have discussed how the optimiser doesn't seem to cooperate too much on that stuff
[20:03:44] <dhewg> im using -O0 because of debugging
[20:03:51] <fuzzie> still it seems correct, 600k calls to libc's tolower() at load time
[20:03:58] <dhewg> whoa
[20:04:24] <fuzzie> we have an array in core specifically to avoid those stupid calls, i'm not sure why it wasn't using it :P
[20:05:05] <fuzzie> all the wasted readdir/etc calls massively outweigh it though
[20:05:46] <fuzzie> but well assuming you're not just being casesensitive and hoping it works, patch pls :-P
[20:06:09] <dhewg> this isnt much yet
[20:06:50] <fuzzie> well, i would like to avoid large invasive patches if possible
[20:06:57] <fuzzie> since i can't review them and they inevitably break everything
[20:06:57] <dhewg> hehe
[20:07:14] <fuzzie> so if you could bear that in mind
[20:07:29] <fuzzie> but no rush
[20:07:37] <dhewg> yeah sure, all smallish commits
[20:07:40] <dhewg> just multiple
[20:07:42] <fuzzie> i will leave the DirectoryImporter cache alone if you might get to it in, say, some weeks
[20:07:53] <fuzzie> well, i mean, i only really care about the ease of review
[20:08:23] <dhewg> yeah sure
[20:09:01] <fuzzie> just mumbling
[20:09:12] <dhewg> did i scare you? :P
[20:09:59] <fuzzie> i just get grumpy and shout about things if they get scary
[20:10:11] <fuzzie> no breaking my precious gemrb tree! :(
[20:11:37] <dhewg> well, let me push this
[20:11:41] <lynxlynxlynx> one character fix :)
[20:11:54] <dhewg> its more like cleanup and a way to test this hashmap
[20:12:11] <lynxlynxlynx> strcmp's unintuitive return value strikes again
[20:13:54] <fuzzie> dhewg: well a profile would also be nice if you replace hashmap :)
[20:14:11] <fuzzie> but not really necessary
[20:14:35] <dhewg> yeah, but somehow i broke my oprofile here with a fancy new kernel
[20:14:49] <dhewg> didnt yet look into it
[20:15:10] <dhewg> but whatever, the hashmap can now be used for a dir listing mapping
[20:15:12] <fuzzie> just half of the 'let's fix performance' commits in recent times made things worse
[20:16:32] <fuzzie> i guess the 'speed up access to entries' one is a bad idea to commit now
[20:17:07] <fuzzie> and the VFS ones are obvious
[20:17:27] <dhewg> im not sure if the former makes things worse
[20:17:43] <dhewg> i didnt notice anything yet
[20:17:59] <fuzzie> well, if you're saying that BIFs flip back/forth a lot for you and my trivial one-file cache doesn't help, that commit is going to suck
[20:17:59] <CIA-52> GemRB: 03lynxlupodian * r8b0f2f41eb51 10gemrb/gemrb/override/iwd2/strings.2da: iwd2: added feat start/stop strrefs
[20:18:05] <CIA-52> GemRB: 03lynxlupodian * r1f2f6fbc682f 10gemrb/gemrb/core/Inventory.cpp:
[20:18:05] <CIA-52> GemRB: fixed Inventory::CountItems skipping the wrong items
[20:18:05] <CIA-52> GemRB: (fixes mod npc chloe's intro scene)
[20:18:08] <dhewg> but that combined with multiple bifs openend at a time should definitely improve things
[20:18:47] <fuzzie> but maybe say what you want cherry-picked
[20:19:16] <dhewg> hehe, no you take what you want, anything in there doesnt make toooo much sense without stuff building on it
[20:19:36] <fuzzie> the VFS cleanup commits seem to make perfect sense?
[20:19:50] <dhewg> yeah
[20:19:52] --> Maighstir has joined #gemrb
[20:20:21] <fuzzie> i mean apart from git being :-( at your whitespace
[20:20:40] <dhewg> huh?
[20:20:50] <fuzzie> you added a line at the end of one commit, apparently
[20:21:10] <dhewg> yeah
[20:21:13] <dhewg> git doesnt like that?
[20:21:24] <fuzzie> it does not
[20:21:29] <dhewg> hihi
[20:21:36] <dhewg> i do that all the time with scummvm
[20:22:04] <fuzzie> well maybe i'm using misconfigured git version :P
[20:22:14] <fuzzie> but shows up in bright red if i do 'git show' on commit, too
[20:22:40] <dhewg> huh, yeah i see that too
[20:23:52] <fuzzie> i should say, i don't care
[20:24:06] <fuzzie> as long as you don't commit stuff with whitespace errors on every line, you win
[20:24:14] <dhewg> lol no :P
[20:24:27] <dhewg> my vim hilights whitespace weirdness like git show
[20:24:30] <dhewg> big bold red
[20:25:10] <dhewg> and that linefeed at the end is more like a habit, some scummvm compilers spit out a warning if its missing
[20:26:33] <fuzzie> also if me cherry-picking gets annoying, you can probably get wjp to grant you commit rights, with sufficient cookies
[20:27:18] <dhewg> nah, forced reviews make sense since i dont know the code base
[20:27:47] <wjp> better not ask me for that right after admitting whitespace errors, though ;-P
[20:28:04] <dhewg> hehe
[20:28:10] <dhewg> its not an error! :P
[20:28:18] <wjp> uh-huh
[20:28:21] <CIA-52> GemRB: 03dhewg * rd95db020b980 10gemrb/gemrb/core/System/VFS.cpp: VFS: Fix va_start/va_end usage in PathJoin()
[20:28:22] <CIA-52> GemRB: 03dhewg * r873011b36914 10gemrb/gemrb/plugins/BIFImporter/BIFImporter.cpp: BIFImporter: Fix whitespaces
[20:28:23] <CIA-52> GemRB: 03dhewg * r0aefea0fcbcc 10gemrb/gemrb/core/System/VFS.cpp: VFS: Mark private functions as static
[20:28:23] <CIA-52> GemRB: 03dhewg * r89e7418ebcbe 10gemrb/gemrb/core/System/VFS.cpp: VFS: Use dir_exists in IsDirectory()
[20:28:39] <dhewg> also, you should see the as-is files with my whitespace error hilighting
[20:28:46] <dhewg> it cant get any worse! :P
[20:28:48] <fuzzie> yes
[20:28:55] <fuzzie> i turn it off for gemrb :P
[20:28:59] <-- mihairu has left IRC (Remote host closed the connection)
[20:30:04] <dhewg> btw, im really not sure what coding conventions i should use
[20:30:14] <dhewg> there're like multiple used
[20:30:23] <dhewg> can i use scummvm's?
[20:30:26] <fuzzie> that is a polite way of saying that none are used
[20:30:35] <dhewg> i know :P
[20:30:43] <fuzzie> i imagine _ for member variables and g_ etc is going to be hated at
[20:30:58] <dhewg> yeah, but those especiall make sense to me
[20:30:59] <fuzzie> judging by reaction so far
[20:31:40] <fuzzie> and rule#1 of gemrb is try not to confuse poor Avenger too much at times when he's gone
[20:31:45] <fuzzie> so, *shrug*
[20:32:08] <fuzzie> in stuff like the BIFImporter, if you rewrite the whole thing neatly, i can't imagine it's going to be a problem
[20:32:26] <fuzzie> in stuff which a bunch of people are likely to maintain, i think it might be more dubious
[20:32:34] <fuzzie> not helpful, should ask someone else
[20:34:03] <fuzzie> should not let me be an obstacle, i am good at being an obstacle.
[20:35:09] <fuzzie> also i am not convinced s/NULL/0/ is particularly good cleanup, i keep doing it myself but i think it's considerably less clear
[20:36:07] <dhewg> really?
[20:36:13] <dhewg> NULL is c, 0 is c++
[20:36:28] <fuzzie> NULL is 'i am a pointer', 0 is 'what the heck is this?' :P
[20:37:10] <fuzzie> but jmust personal thought, not a requirement
[20:37:12] <dhewg> i used the think the same, but reviewing coworkers and scummvm ppl disagree
[20:38:35] <fuzzie> well, i write 0 everywhere out of habit
[20:38:43] <fuzzie> but it's crazy unclear
[20:39:45] <fuzzie> although my scummvm code seems to all be NULL
[20:40:46] <fuzzie> i'm surprised no-one's o.Oed at me
[20:41:59] <dhewg> why is the game's 'Cache' folder added to the resources?
[20:42:40] <fuzzie> because the resources there should take priority over all other resources
[20:43:09] <dhewg> isnt that just the dumping ground for the original?
[20:43:18] <fuzzie> and for us
[20:43:30] <dhewg> gemrb writes there?
[20:43:41] <dhewg> it has its own cache, no?
[20:43:46] <fuzzie> oh
[20:43:57] <fuzzie> i see, you mean, GamePath/Cache *and* another Cache?
[20:44:13] <fuzzie> if so, i don't see it
[20:45:28] <dhewg> oh wait, thats just the description
[20:45:30] <dhewg> nvm :)
[20:53:23] --> PixelScum has joined #gemrb
[20:55:59] <-- BaldimerBrandybo has left IRC (Ping timeout: 250 seconds)
[20:56:55] <fuzzie> ok, what message appears on mismatched spell levels?
[20:58:24] <fuzzie> ah, "Spell caster level decreased by"
[20:58:41] <fuzzie> aka CASTER_LEVEL_DEC
[21:12:15] <fuzzie> ok spell code is pretty simple
[21:15:20] <fuzzie> after lynx coded the wild magic, anyway
[21:16:24] <lynxlynxlynx> well, GetEffectBlock is still horrible, but that's lower on the plate
[21:17:42] <fuzzie> well, that is part of what i just decoded
[21:18:05] <fuzzie> so at least i know how it's *meant* to work now :)
[21:19:42] <lynxlynxlynx> cool
[21:20:47] <fuzzie> you already did all the interesting-to-me bits though
[21:21:33] <fuzzie> but some is interesting
[21:21:37] <fuzzie> like, effect targeting is done there
[21:22:17] <fuzzie> and resistance
[21:23:18] <fuzzie> and most isn't added to projectile
[21:28:35] <fuzzie> anything else i should look at in disasm before switching it off?
[21:36:52] <tomprince> dhewg: I would say follow scummvm, except _ and g_, and with tabstop 8.
[21:37:24] <fuzzie> opinion on NULL vs 0? :P
[21:37:29] <tomprince> NULL.
[21:37:30] <dhewg> 8? o_O
[21:38:02] <tomprince> scummvm says 4, we use 8. But indent with tabs, anyway.
[21:38:39] <dhewg> that i do, but since i also use a max line with of 80, i use a tabstop of 4 :)
[21:41:27] <fuzzie> perhaps we could club together and buy you one of those fancy new colour CRTs to replace your black-and-green display? :P
[21:42:03] <dhewg> its eye-cancer amber kthx :P
[21:42:04] <tomprince> And actually, gcc seems not smart enough to treat 0 as NULL when specifying __attribute__((sentinel)) for PathJoin.
[21:47:55] <tomprince> That is a project for somebody: cleaning up the fallout from marking thing warn_unused_result. And perhaps find new places to put it.
[21:49:13] <fuzzie> mm, it is somewhere on my list :/
[21:49:44] <fuzzie> maybe you want to glance at dhewg's hashmap thing
[21:56:21] <tomprince> I don't see it?
[21:59:40] <fuzzie> on github under dhewg/gemrb
[22:00:28] <tomprince> apparently the network display wasn't updated ...
[22:02:10] <fuzzie> ah
[22:14:56] <fuzzie> sheesh, death code is complex
[22:16:20] <-- barra_home has left IRC (Quit: Verlassend)
[22:16:48] <fuzzie> mostly just stuff to do with stupid chunking/etc
[22:18:52] <tomprince> commenting inline on github ...
[22:24:15] <tomprince> I like the idea of a hashmap, but I don't like the mysterious startValue paramater.
[22:32:46] <dhewg> ah, thx for commenting
[22:33:15] <dhewg> the startValue is used by the keyimporter
[22:33:30] <fuzzie> i could add a "AAAAA TEMPLATES" comment but not really awake enough to be more helpful than that
[22:34:13] <dhewg> it uses it to yield different hashes for same resref's with a different type
[22:34:54] <dhewg> fuzzie: hehe, well, its not that bad, and seeing how many caches there are that could help to unify it
[22:35:04] <fuzzie> don't want to just categorise by type?
[22:35:17] <fuzzie> well, templates for the hashmap make perfect sense and i love them very much
[22:35:56] <dhewg> categorise how?
[22:36:04] <dhewg> one map for one type?
[22:36:23] <fuzzie> a map containing maps for each type!
[22:36:31] <dhewg> uhm, no.
[22:36:32] <fuzzie> <insert manic cackling here>
[22:37:46] <dhewg> the cache dir is the only resource source that changes, right?
[22:38:13] <fuzzie> the only one we change, yes
[22:38:25] <fuzzie> please don't hardcode that into anything except a param though
[22:38:35] <dhewg> heh no
[22:38:58] <dhewg> but to whip up a cache that doesnt suck to some extend im going to mess with that first :P
[22:39:24] <fuzzie> well, like i said, there's a nice non-invasive way to do that
[22:39:36] <fuzzie> and then there are also many horrible ways to do that which i haven't thought about :P
[22:39:40] <fuzzie> pls pick one of the prior kthx
[22:39:45] <dhewg> hehe
[22:39:55] <dhewg> well, the cache usage is rare
[22:40:02] <dhewg> as in code instances
[22:40:39] <fuzzie> yeah
[22:40:41] <dhewg> it wont be very invasive, but it does make sense to keep track of cached entries
[22:40:52] <fuzzie> it's just that you can implement it as "when you add to the cache, prod the cached list"
[22:41:04] <fuzzie> which i will fail to apply for weeks because it'll have subtle bugs everywhere
[22:41:21] <dhewg> if i read the code correctly i can now `echo zomg > cahe/meh.sto`, which will be bundled with all future savegames then
[22:41:30] <fuzzie> or you can implement it as "don't cache the cache dir" which also works for swapping stuff in/out at runtime
[22:42:01] <dhewg> the idea i have is to move the cache dir handling to the resourcemanager
[22:42:03] <fuzzie> yes, well, that is a feature for me :P
[22:42:14] <fuzzie> but yes, this is what i mean about over-complex
[22:42:21] <dhewg> which keeps track of what files are cached
[22:42:31] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:42:33] <fuzzie> this is 5 minutes to add a cache feature to make master usable, or 5 days to design complex overarching cache system :-p
[22:42:33] <dhewg> and its silly to handle it will the directorylister
[22:42:51] <dhewg> but thats what i mean by "sucks to some extend"
[22:43:11] <fuzzie> well, the directorylister has to have a cache anyway
[22:43:12] <dhewg> then you have to mess with the cache in the directorylister to it matches with the cache state
[22:43:34] <dhewg> yes, but when seperating the cachedir, the cache in a directorylister gets way simpler
[22:43:41] <fuzzie> for CaseSensitive to not do slow I/O
[22:43:48] <fuzzie> and you need the cache either way, right?
[22:43:57] <fuzzie> but well go ahead and fiddle :)
[22:44:13] <dhewg> let me fiddle, when you hate it you can always tell me
[22:44:57] <fuzzie> but i would like the ability to change stuff on the fs and have it picked up
[22:45:11] <fuzzie> no problem that being a flag of some kind though
[22:45:21] <dhewg> that i did not consider :P
[22:45:42] <fuzzie> yes, i didn't see where you were going, earlier
[22:45:42] <dhewg> you do that while gemrb is running?
[22:45:54] <fuzzie> when debugging it's very helpful to be able to swap in/out files without having to restart the entire game
[22:46:13] <dhewg> hm
[22:46:17] <fuzzie> this is not a remotely common case though
[22:47:00] <dhewg> modify or add files?
[22:47:02] <fuzzie> well, i do it a lot with the original engine :P but not with gemrb
[22:47:24] <fuzzie> well, add files which represent existing resrfs
[22:47:26] <fuzzie> resrefs
[22:47:51] <fuzzie> if it's infinitely painful to do then i wouldn't worry..
[22:48:18] <dhewg> `killall -USR1 gemrb` to force it to pick up random crap :P
[22:48:23] <fuzzie> i'm pretty sure all we need for Cache manipulation to fix saves on-the-fly is replace or delete
[22:48:42] <fuzzie> which are much easier
[22:50:34] <fuzzie> and not to worry about
[22:53:07] <fuzzie> but you see why i go crazy :)
[22:54:21] <dhewg> :p
[22:54:28] <dhewg> but sleep now
[22:54:31] <dhewg> kthxbai
[22:54:32] <fuzzie> sleep well!
[23:14:55] --> mihairu has joined #gemrb