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

Archive Today Yesterday Tomorrow
GemRB homepage

[01:37:19] --> mihairu has joined #gemrb
[01:39:36] <-- |Cable| has left IRC (Read error: Operation timed out)
[01:42:57] --> |Cable| has joined #gemrb
[02:17:19] <CIA-52> GemRB: 03tom.prince * re9695cb00b46 10gemrb/gemrb/ (4 files in 2 dirs):
[02:17:19] <CIA-52> GemRB: Move definitions of string functions to separate header as well.
[02:17:19] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[02:21:07] <gembot_> build #53 of mingw32 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/53 blamelist: Tom Prince <tom.prince@ualberta.net>
[02:54:59] <gembot_> build #54 of mingw32 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/54
[02:55:04] <-- barra_home has left IRC (Quit: Verlassend)
[03:32:52] <tomprince> bikeshead: what to name inline toupper/tolower
[07:54:44] <fuzzie> no idea
[08:00:24] --> lynxlynxlynx has joined #gemrb
[08:00:24] --- ChanServ gives channel operator status to lynxlynxlynx
[08:22:10] <fuzzie> wjp: how's the blitter?
[08:24:09] --> Bo_Thomsen has joined #gemrb
[08:51:35] --> Avenger has joined #gemrb
[08:51:44] <Avenger> hi
[08:51:50] <Avenger> who made the buildbot?
[08:53:42] <Avenger> it is really cool, last time i seen some warnings produced by it, but now i cannot find them.
[08:54:02] <Avenger> it was a grid display of several builds
[08:54:23] <fuzzie> heh
[08:54:28] <fuzzie> you know where it is?
[08:54:36] <Avenger> no
[08:54:40] <fuzzie> http://buildbot.gemrb.org/
[08:54:41] <Avenger> it was 1-2 days before
[08:54:50] <Avenger> ahh yes, i know where the buildbot is
[08:54:56] <Avenger> but not that particular display
[08:55:07] <fuzzie> you can just click 'grid display' i guess?
[08:55:07] <Avenger> i saw some warnings in 2 files
[08:55:12] <fuzzie> it is by tomprince, mostly for msvc6 tests
[08:55:24] <Avenger> it was different
[08:55:30] <Avenger> it was a longer list
[08:55:58] <Avenger> kinda like a log, with x axis: builders, y axis: time
[08:56:25] <fuzzie> oh, that is 'waterfall' i think
[08:56:29] <Avenger> also, with several color codes
[08:56:36] <Avenger> i saw purple and orange :)
[08:56:52] <Avenger> well, waterfall is close to it
[08:57:02] <Avenger> maybe i'll find the stuff i look for
[08:57:06] <fuzzie> hehe
[08:57:09] <fuzzie> ok :)
[08:57:57] <fuzzie> i like the console build, but it doesn't say what is trunk and what isn't
[08:58:18] <Avenger> EffectQueue.cpp:1171:25: warning: equality comparison with extraneous parentheses [-Wparentheses]
[08:58:25] <Avenger> something like these, but with more text
[08:59:12] <fuzzie> like, the whole log, not just the warnings?
[08:59:16] <Avenger> ok, i found them
[08:59:25] <Avenger> it is enough to find them
[08:59:30] <fuzzie> :)
[09:00:00] <fuzzie> i messed with EffectQueue a bit
[09:00:34] <fuzzie> but i guess i can ask you to check it when you're not so busy
[09:00:55] <CIA-52> GemRB: 03avenger_teambg * r93951aa3edb9 10gemrb/gemrb/core/ (EffectQueue.cpp GUI/GameControl.cpp): fixed some warnings
[09:00:56] <Avenger> what did you change?
[09:01:08] <fuzzie> i changed EffectQueue::AddEffect, to make copies of the effects
[09:01:32] <fuzzie> but it is wrong, too many of these target types must not go in the projectile, i think i have to move the code somewhere else
[09:01:47] <Avenger> hmm
[09:02:27] <Avenger> i thought the target type goes into the projectile, except that the global target types resolve into separate effects
[09:03:10] <fuzzie> for spells, only FX_TARGET_PRESET and FX_TARGET_ORIGINAL go into the spell projectile
[09:03:51] <Avenger> yep, self is resolved on apply
[09:04:06] <fuzzie> but at the moment, we add everything into the projectile except self
[09:04:20] <fuzzie> so some other target types are broken
[09:04:24] <Avenger> does this change anything?
[09:05:17] <fuzzie> yeah, it screws up some things i forget
[09:05:19] <Avenger> the three most used target types are good, i don't know if the original data ever uses the rare cases
[09:05:20] <fuzzie> not important though
[09:05:32] <fuzzie> fx_apply_effect not working for scriptables is more annoying :P
[09:05:40] <Avenger> hmm
[09:05:53] <Avenger> because it doesn't stick in the queue
[09:05:57] <Avenger> because there is no queue :)
[09:06:01] <fuzzie> yes
[09:06:09] <Avenger> and it is used in any data?
[09:06:12] <fuzzie> yep
[09:06:19] <Avenger> i hoped we can avoid that queue
[09:06:21] <Avenger> really
[09:06:26] <fuzzie> well i don't think we need a queue
[09:06:48] <fuzzie> i was thinking we could just make a fake queue and run it inside the effect?
[09:07:03] <Avenger> ???
[09:07:19] <fuzzie> well
[09:07:23] <Avenger> how do you attach it to the scriptable?
[09:07:29] <fuzzie> i don't think we need to
[09:07:47] <Avenger> then who'll call it repeatedly?
[09:07:52] <fuzzie> the example dhewg found was an .eff file which only has 0x43 (fx_summon_creature) in it
[09:07:59] <Avenger> oh
[09:08:00] <fuzzie> and that doesn't need to stick, right?
[09:08:03] <Avenger> then it doesn't need a queue
[09:08:06] <fuzzie> just at the moment, it doesn't get run at all
[09:08:12] <Avenger> then it just needs a small tweak
[09:08:18] <fuzzie> ok
[09:08:28] <Avenger> phew
[09:08:31] <fuzzie> i wasn't sure whether it was ok with a small tweak, or a big problem :)
[09:08:34] <Avenger> then it isn't a queue problem
[09:08:41] <fuzzie> we need to copy the target point in there anyway
[09:08:44] <Avenger> it runs instantly
[09:08:57] <Avenger> yes, i guess it is just losing the target point
[09:09:00] <fuzzie> i checked the original to see what else is a problem
[09:09:13] <Avenger> i think i 'fixed' the target point recently, hoping i didn't mess up with something
[09:09:21] <Avenger> when i worked with projectiles
[09:09:34] <Avenger> i guess, that might be what affected it
[09:10:05] <fuzzie> i don't see anything permanent
[09:10:15] <fuzzie> i mean, no non-instant effects
[09:10:27] <Avenger> because there are none :)
[09:10:37] <Avenger> it is all hardcoded one shot effect
[09:10:48] <fuzzie> oh, there is one non-hardcoded weird one
[09:11:01] <fuzzie> CGameEffectRandomSummon::ApplyEffectNoSprite(CGameAIBase *)
[09:11:16] <fuzzie> i don't know why
[09:11:39] <fuzzie> anyway ok no problem :)
[09:11:48] <fuzzie> hope things are going well
[09:12:25] <Avenger> what is wrong now? i know one scriptable that uses summon, in irenicus dungeon the monster summoning wand trap
[09:12:57] <fuzzie> hehe, i don't know if it's actually used
[09:13:13] <fuzzie> just *every* other effect in the original takes an actor (CGameSprite)
[09:14:19] <Avenger> i guess, the summon effect works differently when the target is scriptable
[09:14:25] <Avenger> to get the target point
[09:14:31] <fuzzie> but it's weird because every other effect is hardcoded :)
[09:14:32] <Avenger> it is not a big deal
[09:14:45] <Avenger> also, the EA flag
[09:14:45] <fuzzie> but it's just weird!
[09:14:51] <fuzzie> no worrying needed :P
[09:14:59] <Avenger> we can hardcode it into the single effect
[09:15:16] <fuzzie> not much else interesting happened
[09:15:24] <fuzzie> tomprince wrote a store cache, so no more bag spm
[09:15:25] <fuzzie> spam
[09:15:42] <Avenger> does it leak? :D
[09:15:46] <fuzzie> nope
[09:15:51] <Avenger> cool
[09:16:01] <Avenger> did anyone run valgrind recently?
[09:16:01] <fuzzie> good too, if it leaked then we'd probably forget to save bags :P
[09:16:16] <fuzzie> i didn't check leaks
[09:16:49] <Avenger> there was lots of refactoring involving storage
[09:16:51] <fuzzie> oh, i fixed the cut-off text in item descriptions too
[09:17:14] <Avenger> and you removed the interface store hack too :)
[09:17:24] <Avenger> i hope that won't crash on me in windows
[09:17:25] <fuzzie> well, i rewrote half the store code :-p
[09:18:12] <fuzzie> stores work as well as the original now, i think
[09:18:43] <Avenger> cut off text reminds me about the drop capitals in scrolled textareas
[09:18:51] <fuzzie> yes
[09:18:58] <fuzzie> the cut-off text was caused by the drop capitals, too
[09:19:01] <Avenger> did you fix that too? or got any idea?
[09:19:32] <fuzzie> i think i can fix it by storing data
[09:19:48] <fuzzie> but i am still working on triggers/actions and some effect bugs
[09:20:10] <Avenger> yea, those are more important than a mere display bug ;)
[09:20:36] <Avenger> few read the scrolling text anyway
[09:20:40] <fuzzie> and lynxlynxlynx found a mod which doesn't set CutsceneId
[09:20:50] <fuzzie> i don't suppose you know what happens then? :P
[09:20:59] <fuzzie> there's no object in the first action at all
[09:21:04] <Avenger> cutsceneid is always set, the engine uses the first action's object
[09:21:07] <Avenger> oh
[09:21:23] <Avenger> kick the mod's author around the room
[09:21:34] <fuzzie> yes, that sounds good to me :)
[09:22:01] <Avenger> well, i think we shouldn't support screwed up mods
[09:22:15] <Avenger> or we end up like internet explorer
[09:22:28] <fuzzie> but if it works here, i guess maybe some original scripts might do it
[09:22:44] <fuzzie> haven't checked though, a lot of scripts
[09:23:02] <Avenger> what would ever happen anyway? if there is no object, what is the default
[09:23:13] <fuzzie> yes, well, i don't know, it is a good question
[09:23:31] <Avenger> i'm surprised the original doesn't just crash
[09:23:47] <Avenger> it should definitely ignore the first action
[09:23:50] <fuzzie> yes you would usually expect an assert :)
[09:24:01] <fuzzie> yes, i can see that it removes the first action
[09:24:17] <fuzzie> i just don't see what it tries instead, i thought you might know
[09:24:40] <Avenger> well, since there is an invalid object, i would assume it ignores the whole block
[09:24:52] <Avenger> and that's what we would do
[09:24:54] <Avenger> so, meh
[09:25:06] <fuzzie> yes, we complain and ignore :)
[09:25:54] <Avenger> i cannot imagine bg2 would do anything else: either crash, assert, and/or ignore. There is little chance it salvages the block by assuming some default object
[09:26:04] <fuzzie> it seems to work in original, unfortunately
[09:26:29] <Avenger> so, the object is.... the one that executes the cutscene?
[09:26:55] <fuzzie> in the case lynx found, that gets DestroySelf()ed
[09:27:16] <fuzzie> but maybe that gets ignored
[09:27:20] <Avenger> before or after the cutscene :)
[09:27:36] <Avenger> anyway, i think it is easier to inform the mod's author
[09:28:43] <fuzzie> yes. horrible. :)
[09:29:12] <fuzzie> ah i found one
[09:30:50] <fuzzie> bg2's cut24b doesn't have a object, but i guess it is unused, so can ignore it :P
[09:32:40] <fuzzie> that is only missing object in cut* files in bg2
[09:35:03] <fuzzie> so i guess we're probably good
[09:37:28] <Avenger> i didn't find what would use cut24a or b
[09:37:41] <Avenger> something with shthass1 as scripting name
[09:38:22] <fuzzie> oh, i worked out what your 'cangoidle' is, too
[09:38:49] <Avenger> ahh found it, it is shadow thief (ama)
[09:38:52] <fuzzie> it is dialogwait, to pause actors when you tried talking to them
[09:42:57] <Avenger> this cut24 if ever used is in the thieves stronghold storyline (so you need to be a thief to test it)
[09:43:06] <Avenger> i've never seen it
[09:43:18] <fuzzie> i don't see it referenced?
[09:43:36] <Avenger> me neither, but it references Ama (shthass1)
[09:44:21] <fuzzie> oh, i found yet another problem
[09:44:38] <fuzzie> gemrb seems to work out spell types by taking the spell number and dividing by 1000
[09:44:39] <Avenger> about cutsceneid?
[09:44:42] <Avenger> ah
[09:44:55] <Avenger> so?
[09:45:28] <Avenger> that is only when we receive a spell number
[09:45:43] <Avenger> we translate it to a spell name as soon as possible
[09:46:00] <fuzzie> the spellbook uses divided-by-1000 for type, though
[09:46:22] <fuzzie> so innates with a spwi filename get a mage type :(
[09:46:27] <Avenger> hmm
[09:46:50] <Avenger> what innates get spwi
[09:47:18] <fuzzie> the 'polymorph back to human' ones
[09:47:33] <fuzzie> polymorph disables mage spells, so..
[09:47:39] <Avenger> hehe
[09:47:41] <Avenger> i see
[09:48:21] <Avenger> bioware programmer should be kicked too
[09:48:29] <Avenger> or rather, the data creator
[09:48:54] <Avenger> can you access the spell's data?
[09:49:11] <Avenger> because spell name matching sucks
[09:49:29] <fuzzie> not really
[09:49:46] <Avenger> spell name matching would suck too, no?
[09:49:49] <fuzzie> yes
[09:50:00] <fuzzie> we need to put the correct type in Spellbook's SpellExtHeader
[09:50:10] <Avenger> oh, we don't?
[09:50:30] <Avenger> ahh, i see, i didn't want to access the spell data
[09:51:05] <fuzzie> but the alternative is you have to access the spell data every time you check the spellbook :P
[09:51:12] <fuzzie> so i thought, maybe you have an idea
[09:51:25] <fuzzie> if not, it is not urgent
[09:52:05] <Avenger> huh, someone --> const Spellbook &wikipedia = source->spellbook;
[09:52:11] <Avenger> wtf ???
[09:52:16] <fuzzie> lynx i think :)
[09:52:34] <Avenger> yes, it has a certain lynx taste...
[09:53:28] <fuzzie> that code is fine though i think ;p
[09:53:31] <Avenger> i vote for some sane name, and not 'appstore' or 'iphone'
[09:54:27] <fuzzie> oh, and i totally hacked EFFImporter to save variable effects to disk
[09:54:32] <fuzzie> that is maybe worth a look too
[09:55:57] <Avenger> we need to fix the spellbook thing
[09:56:13] <Avenger> i just don't know how
[09:56:29] <Avenger> it is fine to access the spell once
[09:56:34] <Avenger> it should exist anyway
[09:56:52] <Avenger> so it is fine to look it up when it goes into the book
[09:57:02] <Avenger> but i don't understand what's wrong yet
[09:57:07] <fuzzie> yes, but it's not so easy
[09:57:26] <fuzzie> because you have the HaveSpell trigger, for example, which takes a spell id
[09:58:45] <Avenger> int Spellbook::LearnSpell(Spell *spell, int memo) uses the spell's type though
[09:59:00] <Avenger> so, the book data is correct
[09:59:38] <Avenger> HaveSpell has a bool Spellbook::HaveSpell(const char *resref, ieDword flags) form too
[09:59:51] <Avenger> it should be used when the spell is given with ResRef
[09:59:57] <fuzzie> but you see how this breaks, right?
[10:00:12] <Avenger> no, because i don't see what uses HaveSpell with a number
[10:00:21] <Avenger> it should be used only by legacy scripts
[10:00:27] <fuzzie> the spell triggers, which almost all use ids
[10:01:00] <Avenger> but the ids would use the innate numbers, no?
[10:01:11] <fuzzie> oh, is that the idea?
[10:01:13] <Avenger> they wouldn't use the mage spell range, would they?
[10:01:44] <fuzzie> honestly i don't know
[10:01:55] <Avenger> well, what exactly is wrong :)
[10:02:06] <fuzzie> i will have to try it myself
[10:02:06] <Avenger> triggers?
[10:03:10] <fuzzie> the reason i found this was the guiscript
[10:03:23] <fuzzie> which does ResolveSpellNumber(spell->spellname)/1000, but you can just replace that with spell->type
[10:04:06] <Avenger> jaheira cannot shift directly from wolf to bear, that is the only problem
[10:04:22] <Avenger> i see the spell icon (innates section)
[10:04:27] <Avenger> but the spell doesn't work
[10:04:34] <Avenger> i can still turn back to human
[10:04:34] <fuzzie> disabled button?
[10:04:38] <Avenger> no
[10:04:52] <Avenger> the shapeshift doesn't work without going back to human
[10:04:53] <fuzzie> i think dhewg was testing with the cloak of sewers
[10:05:10] <Avenger> that isn't even a spell :)
[10:05:15] <fuzzie> yes
[10:05:21] <Avenger> do you know the item resref?
[10:05:24] <fuzzie> but it adds the spell to go back to human :)
[10:05:31] <fuzzie> clck27?
[10:05:40] --> boriskr has joined #gemrb
[10:06:01] <-- boriskr has left IRC (Remote host closed the connection)
[10:06:16] <Avenger> there is a little bug with it
[10:06:50] <Avenger> it shows all three icons of the cloak, but 2 of them has frame
[10:07:54] <Avenger> and the ability selector is wrong too
[10:08:01] <fuzzie> ah right
[10:08:13] <fuzzie> the other bug is that triggers get the wrong spell id, because ResolveSpellNumber
[10:08:17] <fuzzie> but i don't remember if that matters
[10:09:16] <Avenger> using the rat ability of the cloak, i get a disabled return to human innate
[10:09:35] <fuzzie> did you try changing the ResolveSpellNumber thing in GUIScript.cpp?
[10:09:38] <Avenger> i assume the cloak would disable only spells/divine
[10:09:54] <Avenger> no
[10:11:22] <Avenger> ok, odd thing: i ctrl-r'd jaheira, rest for a day, and the disabled shapeshifts to human innate is still here
[10:11:42] <Avenger> i doubt i have any disable spell effects
[10:13:07] <Avenger> i also wonder why is there a portrait icon in the dialog window outside dialogs
[10:13:19] <Avenger> it should be removed at the end of the dialog
[10:13:31] <fuzzie> i think EF_PORTRAIT doesn't get set
[10:13:41] <fuzzie> that is an ongoing problem
[10:13:55] <Avenger> EF_PORTRAIT would remove it from the message/dialog window?
[10:13:59] <CIA-52> GemRB: 03fuzzie * re45c0e5818fd 10gemrb/gemrb/core/GameScript/Actions.cpp:
[10:13:59] <CIA-52> GemRB: fix CreateCreatureObjectDoor position
[10:13:59] <CIA-52> GemRB: this is still broken, it should wait for the animation
[10:14:00] <CIA-52> GemRB: 03fuzzie * rc29ff3991eb8 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: use spell->type when checking for disabled spell buttons
[10:14:09] <fuzzie> oh, wait, in the *message* window? that's weird
[10:14:35] <Avenger> yes, i can even change it by attempting in-party dialogs
[10:14:40] <fuzzie> huh :-/
[10:14:42] <Avenger> the icon changes, but never goes away
[10:14:50] <fuzzie> well, i don't get that, but i did change the dialog code recently
[10:15:01] <fuzzie> i need to remove the initial dialog state check from BeginDialog anyway
[10:15:23] <Avenger> your change will fix the cloak bug?
[10:15:27] <fuzzie> i don't know :P
[10:15:32] <fuzzie> those are just two things i forgot to commit
[10:16:01] <fuzzie> i have a tree full of loads of changes
[10:16:26] <Avenger> heh, you will experience bugs we don't have
[10:16:40] <fuzzie> mostly, i have fixes that no-one else has
[10:16:51] <fuzzie> i get very confused sometimes when people report bugs, and i can't reproduce
[10:16:58] <Avenger> hehe
[10:17:48] <fuzzie> but mostly i didn't break much on trunk
[10:17:56] <fuzzie> you can't summon party members on the pocket plane any more
[10:18:59] <Avenger> it caused: my shapeshifting abilities disabled, turn back to human: also disabled
[10:19:01] <fuzzie> because it was using some hack which i didn't notice, instead of TriggerWalkTo
[10:19:01] <Avenger> lol
[10:19:21] <fuzzie> but i think otherwise, i made everything better :)
[10:21:17] <fuzzie> and, well, ok, maybe you see what i did wrong then :P
[10:22:12] <fuzzie> i guess IE_CASTING is maybe different by one bit, since it has items in the first bit
[10:37:33] <Avenger> i don't understand that last line
[10:38:05] <fuzzie> the comments say that IE_CASTING is 1 for items, 2 for cleric, 4 for mage, 8 for innate, 16 for class
[10:38:32] <fuzzie> so, '1 << spell->type' should be fine, i think?
[10:38:49] <Avenger> yes
[10:39:21] <Avenger> that was the plan, since they don't use 0-999, i allocated it for items
[10:40:02] <Avenger> but nothing uses that bit yet
[10:40:12] <Avenger> at least, i hope so
[10:40:15] <fuzzie> but i don't understand that code
[10:40:20] <Avenger> why?
[10:40:20] <fuzzie> i mean, in guiscript
[10:40:32] <fuzzie> it disables spells if CheckSpecialSpell returns true?!
[10:40:45] <fuzzie> oh i see
[10:40:47] <Avenger> yes
[10:40:50] <Avenger> identify
[10:40:54] <fuzzie> ok, that is a confusing name :)
[10:41:05] <fuzzie> but then the code looks fine
[10:41:18] <Avenger> it should disable only identify though
[10:41:51] <Avenger> ahh and silenced spells
[10:41:54] <Avenger> ok, that's fine
[10:42:37] <Avenger> yes, it should be DisableSpecialSpell :)
[10:43:31] <Avenger> i don't think it is what disables the turn back to human spell
[10:43:37] <Avenger> it is never enabled
[10:44:40] <fuzzie> if it is shown at all, it should be enabled, no?
[10:45:19] <Avenger> yes
[10:45:20] <fuzzie> oh, not if there's no count
[10:45:31] <Avenger> there is count
[10:45:41] <Avenger> i see it as 1 with disabled
[10:46:03] <Avenger> i'm pretty sure the disable mage spell button disables it
[10:46:05] <fuzzie> i think that is broken
[10:46:11] <Avenger> because the spell name is spwi*
[10:46:21] <Avenger> i don't understand how this works in the original, though :)
[10:46:24] <fuzzie> i mean, we don't call SetText if the count is 0
[10:47:04] <Avenger> it shouldn't be on the list if the count is 0
[10:47:43] <Avenger> spells that have 0 memorized counts don't appear on the list
[10:48:26] <fuzzie> i think they do, in some cases
[10:49:28] <fuzzie> hm, maybe not.
[10:51:06] <fuzzie> but disable mage spell button is only checked in the top-level controls
[10:51:45] <Avenger> yes, so it shouldn't affect that spell
[10:51:58] <Avenger> i don't know what disables it yet :)
[10:54:11] <-- mihairu has left IRC (Ping timeout: 240 seconds)
[10:55:09] <Avenger> spwi491 is not in spell.ids btw
[10:55:28] <Avenger> there is no *491 or anything like that
[10:55:30] <fuzzie> yes, that one is just gui issue i hope :P
[10:56:05] <Avenger> or something hardcoded in the original :(
[10:56:51] <Avenger> well, i don't see it hardcoded
[10:57:06] <fuzzie> i don't see why on earth it would fail :-/
[10:57:35] <Avenger> it is still odd, it is an innate with spwi*, but the original engine would go with spell names, not us
[10:57:48] <Avenger> we know it as an innate
[10:58:46] <fuzzie> but i can always add printfs later and check
[11:26:02] <Avenger> meh
[11:26:12] <Avenger> what should i use instead of printf
[11:28:02] <Avenger> fuzzie?
[11:31:32] <Avenger> funny, the committed change says 'use print' instead. But i don't see that text when compiling
[11:32:47] <Avenger> fuzzie, your change broke jaheira completely
[11:33:05] <Avenger> and minsc
[11:33:32] <Avenger> their special abilities are now disabled
[11:37:04] <Avenger> odd, minsc starts with disabled_spellcasting = 4
[11:37:14] <Avenger> oh, well, that is because of the armor
[11:38:40] <Avenger> gemrb thinks spin117 has a spell type of 2
[11:38:46] <Avenger> i wonder why
[11:40:32] <Avenger> it is innate in every bits
[11:42:34] <Avenger> oh i know
[11:58:55] <CIA-52> GemRB: 03avenger_teambg * r530ed411c7ea 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: fixed a bad array index
[12:05:56] <fuzzie> haha.
[12:06:03] <fuzzie> works now?
[12:06:11] <Avenger> not by that commit, but this one
[12:06:19] <fuzzie> but yes, use print()
[12:06:20] <Avenger> i did another commit
[12:06:30] <CIA-52> GemRB: 03avenger_teambg * r1361bf207e0f 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: fixed cloak of sewers
[12:06:45] <lynxlynxlynx> oj
[12:06:45] <Avenger> there is still a small bug, but that is only an EF_* stuff
[12:06:51] <lynxlynxlynx> still reading the backlog
[12:06:55] <Avenger> when turning back to human, the buttons are not re-enabled
[12:07:07] <fuzzie> ok, that is easy enough to deal with
[12:07:09] <Avenger> EF_ACTION needs to be set
[12:07:58] <fuzzie> i would prefer, not to deal with effect stuff, if i can avoid it :P
[12:08:20] <Avenger> basically, you should have done 1<<(type-1)
[12:08:41] <fuzzie> that is what i meant by the 'maybe different by one bit', where you said you didn't understand my line
[12:08:47] <Avenger> hehe
[12:08:50] <fuzzie> but i thought i was wrong so i didn't explain :-/
[12:10:01] <fuzzie> the wing buffet effect is completely wrong in gemrb, too
[12:11:45] <fuzzie> but i guess we worked out enough to patch it up ourselves
[12:12:07] <Avenger> so you can fix it?
[12:12:25] <fuzzie> can fix the obvious bug, anyway :-)
[12:12:37] <fuzzie> don't want to waste your time
[12:13:34] <Avenger> well... i have time in the weekends, but i feel drained a bit
[12:14:04] <Avenger> so i cannot think too well, hope it will get better :)
[12:14:19] <fuzzie> hehe, well, i'd never have found the bit error you fixed..
[12:14:53] <Avenger> it is a mess with all these different spell type representations
[12:15:15] <Avenger> i try to convert all the different ones to a single internal representation for us
[12:15:16] <fuzzie> there's some odd stuff with spell types
[12:16:11] <fuzzie> like SpellCast([GOODCUTOFF],CLERIC_DISPEL_MAGIC) in the bg2 scripts
[12:16:31] <fuzzie> but i am going to assume, script bug, for now
[12:17:05] <Avenger> what's wrong with that
[12:17:09] <fuzzie> oh, hm, maybe not, that code checks the SPL type too
[12:17:39] <fuzzie> SpellCast trigger is mage spells only
[12:18:18] <Avenger> maybe when it is a spell number, it can discern between mage/cleric
[12:18:26] <Avenger> theoretically, it could
[12:18:33] <fuzzie> it's not a 0x4xxx trigger so it just matches
[12:18:40] <fuzzie> i think, broken script :)
[12:19:23] <fuzzie> bioware wrote scripts checking STATE_DISEASED to see when to cast Cure Disease, too..
[12:20:37] <Avenger> i think that works, it just doesn't get saved?
[12:20:49] <Avenger> there is STATE_DISEASED
[12:20:54] <fuzzie> it is overwritten with deactivate state every frame
[12:21:48] <fuzzie> you wrote about it on the forum
[12:23:02] <Avenger> hmm
[12:23:11] <Avenger> maybe :)
[12:23:48] <fuzzie> there's a note from devSin somewhere agreeing
[12:23:53] <fuzzie> and i also see it in original code
[12:24:28] <fuzzie> but there's a PC check in there so *maybe* it works for PCs?
[12:24:35] <fuzzie> i didn't look so close because you said it wasn't used in disease at all
[12:26:52] <Avenger> http://forums.gibberlings3.net/index.php?s=&showtopic=9262&view=findpost&p=80884
[12:27:04] <Avenger> i found only that
[12:27:14] <fuzzie> haha.
[12:27:30] <fuzzie> that is not a nice reply :P
[12:28:25] <Avenger> http://forums.gibberlings3.net/index.php?s=&showtopic=10040&view=findpost&p=85513
[12:28:27] <Avenger> and this
[12:28:53] <fuzzie> right, the second one is the one i was thinking of
[12:29:13] <Avenger> i knew about this too, but i don't find anything where i talk about it
[12:29:26] <fuzzie> let me find it
[12:29:40] <fuzzie> http://forums.gibberlings3.net/index.php?showtopic=4174
[12:29:53] <Avenger> ah nice
[12:29:59] <Avenger> 2005 ...
[12:30:26] <fuzzie> it is set/unset by RestoreActiveAI() which is the function call right after the SynchLastObjects call in CGameSprite::ProcessAI
[12:30:50] <fuzzie> so, on every AI update :)
[12:31:04] <fuzzie> and, yes, isn't it scary?
[12:31:58] <Avenger> it is not STATE_DISEASED at all, then
[12:32:25] <Avenger> i doubt it is touched by any disease code
[12:32:34] <Avenger> sadly i don't see the code right now
[12:32:38] <fuzzie> it is used in 6 checks in iwd2 scripts
[12:32:57] <Avenger> well.... iwd2 may be different
[12:32:59] <fuzzie> so maybe it works in iwd2
[12:33:12] <fuzzie> i only found effects.src yesterday :)
[12:33:45] <Avenger> 004B57AE 81 8D 20 09 00 00 00 or dword ptr [ebp+920h],80000h
[12:33:54] <Avenger> in iwd2 disease opcode
[12:33:58] <fuzzie> yay
[12:34:01] <Avenger> that is definitely working :)
[12:34:17] <fuzzie> iwd2 is really the version of IE which wasn't broken :P
[12:35:54] <Avenger> well, effects.src helped us a lot in finding bg2 effects
[12:36:06] <fuzzie> i didn't even realise it existed
[12:36:20] <fuzzie> it looks very helpful
[12:36:56] <fuzzie> it's a pity the other stuff in dev.bif is less helpful
[12:37:16] <Avenger> http://forums.gibberlings3.net/index.php?showtopic=5219
[12:37:40] <Avenger> or, what's more releavant: http://log.usecode.org/gemrblog.php?log=21Jun2009
[12:37:42] <Avenger> lol
[12:37:53] <fuzzie> oh, haha
[12:38:09] <fuzzie> i still haven't fixed that stuff properly, either
[12:38:26] <fuzzie> and i am still asking people not to touch actions/triggers
[12:39:01] <fuzzie> not much changes
[12:41:02] <Avenger> i doubt many would touch them nowadays :)
[12:41:19] <Avenger> lynx adding the killed trigger should be fine
[12:41:25] <fuzzie> already done
[12:41:31] <fuzzie> we don't add it to the trigger list anywhere yet..
[12:41:44] <fuzzie> but that is on TODO list
[12:41:54] <Avenger> that should be easy, though
[12:42:15] <fuzzie> the original sends trig_killed to killer, trig_die to victim, and trig_died to everyone in visual range without LOS check
[12:42:30] <Avenger> oh, nice you found that out
[12:42:33] <fuzzie> i have a big list of every single added trigger in the original :P
[12:42:42] <Avenger> i couldn't tell that so well :)
[12:42:44] <fuzzie> including the ones which don't go through the message
[12:42:49] <fuzzie> so not magic, i just made a list
[12:43:36] <Avenger> i just didn't bother with the big picture of scripting
[12:43:49] <fuzzie> i wouldn't bother now, i worked it almost all out
[12:43:56] <Avenger> :)
[12:44:28] <fuzzie> i'm just very slow at fixing it
[12:46:00] <fuzzie> but i still don't even know where to start with stuff like projectiles
[12:46:31] <fuzzie> and i just take little peeks into effects :)
[12:46:56] <fuzzie> oh, i have very good question..
[12:48:02] <fuzzie> in the original, fx_cast_spell_on_condition keeps a list and checks it on new added triggers (for non-0x4xxx) or every round (for 0x4xxx)
[12:48:33] <Avenger> yes, it a trigger list
[12:48:47] <fuzzie> i was thinking of making gemrb do the 'every round' ones in the effect itself, and then having some code for new added triggers which goes through the queue and checks every fx_cast_spell_on_condition for a matching one
[12:48:54] <fuzzie> rather than actually maintaining a list
[12:49:02] <fuzzie> but you're much better at this stuff, what do you think?
[12:49:04] <Avenger> i agree
[12:49:44] <fuzzie> any idea where to put the actual check code? :)
[12:49:44] <Avenger> every round: doesn't need another list, than the old trigger list.
[12:49:58] <Avenger> which is now implemented, irrc
[12:50:00] <Avenger> iirc
[12:50:12] <fuzzie> i mean, the original maintains several lists
[12:50:50] <fuzzie> we could add a 'already checked by effect queue' flag to every trigger
[12:50:53] <Avenger> yes, it maintains an own list for fx_cast_spell_on_condition, which is superfluous
[12:51:58] <fuzzie> but triggers can stay in the main trigger list for a long time, and fx_cast_spell_on_condition must only notice a trigger when first added
[12:52:07] <Avenger> hmm, if you add such a flag to every trigger, then you will have to clear them in every ai cycle?
[12:52:20] --> mihairu has joined #gemrb
[12:52:27] <Avenger> oh, if only once, then fine
[12:52:34] <fuzzie> well, that is the problem, you see
[12:52:48] <fuzzie> there has to be some way for it to only handle the triggers once :)
[12:53:05] <Avenger> if they need to be handled only once, then the flag is perfect
[12:53:08] <fuzzie> and either i can check the effect queue in Scriptable::AddTrigger, or we can add some flag
[12:53:11] <fuzzie> flag is fine? :)
[12:53:15] <Avenger> sure
[12:53:20] <fuzzie> ok, cool
[12:53:33] <Avenger> i just feared you will have to clear those flags every now and then
[12:53:38] <Avenger> that would be a bit ugly
[12:54:08] <Avenger> single flag is fine, actually, we already have unused bits laying around, don't we?
[12:54:25] <Avenger> even if not, i don't care about an extra one :)
[12:54:26] <fuzzie> i am not actually storing triggers in the list :P
[12:54:38] <Avenger> hmm, then what do you store in the list
[12:54:44] <fuzzie> i use some custom struct which has trigger id and two params
[12:54:59] <Avenger> heh... that's different from the original
[12:54:59] <fuzzie> i'm not sure it will actually work
[12:55:12] <fuzzie> but so far, we didn't find any problems
[12:55:19] <Avenger> the original stores the whole trigger, just like it loads one from bcs
[12:55:36] <fuzzie> the main problem is, it stores actors by globalid
[12:55:51] <fuzzie> so if the actor is completely destroyed, they don't match any more
[12:55:56] <Avenger> whose problem is that? i actually like that change :)
[12:56:19] <Avenger> that means, the trigger will be valid only for the actor it was called for
[12:56:33] <fuzzie> it breaks stuff like AttackedBy([ENEMY]), maybe
[12:56:41] <Avenger> ahh i see
[12:56:52] <fuzzie> but only if they DestroySelf() before the trigger is matched
[12:56:54] <Avenger> the attacker dies a horrible death... and the trigger won't work
[12:57:19] <Avenger> it may break some weird cutscenes, probably
[12:57:27] <fuzzie> we'll see :)
[12:57:36] <fuzzie> it is easy to add a full Object in, if someone needs it
[12:57:51] <fuzzie> or if you want it
[12:57:54] <Avenger> i still like our compact method
[12:58:10] <Avenger> storing whole objects everywhere is ugly
[12:58:12] <fuzzie> but for now, i will just add some flag :)
[13:00:47] <fuzzie> well, i won't, because i am studying, but later :P
[13:02:07] <Avenger> ok
[13:02:10] <Avenger> see you later!
[13:02:15] <-- Avenger has left IRC (Quit: bye!)
[14:31:00] <tomprince> fuzzie: opinion on naming toupper/tolower?
[14:31:36] <fuzzie> i have no idea
[14:32:02] <fuzzie> i would probably do inline_toupper to make it clear what on earth
[14:32:53] <fuzzie> but i'm not sure what you're doing, quite
[14:33:15] <fuzzie> oh, nm
[14:33:23] <fuzzie> so, no, still no idea
[14:33:41] <tomprince> We could just go with toupper/tolower, but that depends on the fact that the libc versions take an int. And then we pick that version out in Interface::Interface by casting.
[14:34:16] <fuzzie> although as a comment, make them return 'unsigned char'?
[14:34:27] <fuzzie> also change the ieByte cases to unsigned char if you changed the arrays, i guess
[14:34:32] <fuzzie> ieByte casts, i mean
[14:35:07] <fuzzie> whoever made signed char the default on x86 needs some serious glaring at
[14:37:18] <tomprince> Do we want them to return unsigned? I think it perhaps makes sense to change the array to just be char.
[14:37:39] <fuzzie> well, ok, make them use char then :)
[14:40:33] <fuzzie> for me it's the same, so, i'm happy
[14:43:57] <fuzzie> but i think relying on type overloading will confuse us all terribly
[14:45:02] <tomprince> I agree. If somebody thinks of a better name, they can fix it.
[14:45:46] <fuzzie> tomprince_super_combo_action_toupper? :)
[14:46:23] * tomprince shakes head, laughing.
[14:50:30] <wjp> please no type overloading on toupper :-)
[14:51:10] <tomprince> Then what should we call the functions instead?
[14:51:30] <fuzzie> i can't think of anything better than prefixing with 'internal_' or 'fast_' or similar
[14:51:56] <fuzzie> although i am also fine with tomprince_super_combo_action_ since we're not exactly widely using it
[14:52:56] <tomprince> I actually just noticed that they are slightly different, since we add extra case conversions for pl/cz, according to the code.
[14:53:40] <dhewg> ieLower()?
[14:53:42] <fuzzie> we don't seem to actually do so
[14:53:50] <fuzzie> but i didn't look too closely
[14:54:43] <tomprince> There is code in LoadGemRBINI, to read in the conversions.
[14:55:14] <tomprince> That calls a badly named upperlower.
[14:56:45] <dhewg> heh :)
[14:56:50] <dhewg> does it use rand()?
[14:58:24] <tomprince> Anyway, code is up on github.
[15:02:18] <fuzzie> the casts there seem to be slightly insane
[15:06:41] <tomprince> In interface?
[15:08:09] <tomprince> That is 'cause of the overloading :( but it is only in one place.
[15:09:38] <fuzzie> + unsigned char upper = atoi(s);
[15:09:41] <fuzzie> + pl_uppercase[(unsigned char)lower] = upper;
[15:09:46] <fuzzie> ^- that
[15:11:03] <tomprince> fixed.
[15:15:57] <-- mihairu has left IRC (Remote host closed the connection)
[15:39:16] --> mihairu has joined #gemrb
[16:00:40] <fuzzie> dhewg: cloak thing fixed for you also?
[16:02:54] <dhewg> dunno, just came home
[16:02:58] <dhewg> gimme a few
[16:12:18] <fuzzie> ah, sorry, figured you had time
[16:15:34] <fuzzie> meh, corruption in pst somewhere
[16:34:37] <CIA-52> GemRB: 03tom.prince * r2414ca846ec1 10gemrb/gemrb/ (10 files in 5 dirs):
[16:34:37] <CIA-52> GemRB: Replace GetTime with GetTickCount.
[16:34:37] <CIA-52> GemRB: GetTime was a macro that stored into its argument. Replace it with
[16:34:37] <CIA-52> GemRB: a function that returns the value that was being stored.
[16:34:37] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[16:34:48] <CIA-52> GemRB: 03tom.prince * r59173dc3315f 10gemrb/gemrb/ (5 files in 5 dirs): Merge remote-tracking branch 'sf'
[16:34:49] <CIA-52> GemRB: 03tom.prince * rb6524d487a53 10gemrb/gemrb/includes/globals.h:
[16:34:49] <CIA-52> GemRB: Remove extraneous definition of dir_exists for globals.h.
[16:34:49] <CIA-52> GemRB: It is properly defined in VFS.h.
[16:34:49] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[16:34:51] <CIA-52> GemRB: 03tom.prince * r93f5d8a9b9f1 10gemrb/gemrb/core/Interface.cpp:
[16:34:51] <CIA-52> GemRB: Inline and remove a unenlightening upperlower function.
[16:34:51] <CIA-52> GemRB: It has only one caller, and the code is clearer without the function.
[16:34:51] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[16:34:52] <CIA-52> GemRB: 03tom.prince * rb823573705f2 10gemrb/gemrb/ (core/System/DataStream.cpp includes/globals.h):
[16:34:52] <CIA-52> GemRB: Move GEM_ENCRYPTION_KEY from global header to DataStream.cpp.
[16:34:52] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[16:34:53] <fuzzie> um!
[16:34:53] <CIA-52> GemRB: 03tom.prince * r96f4219db400 10gemrb/gemrb/ (3 files in 3 dirs):
[16:35:24] <CIA-52> GemRB: Remove bogus and unused (SYMBOL|IDS)_VALUE_NOT_LOCATED.
[16:35:24] <CIA-52> GemRB: The function actually returns -1, and the constant is never used.
[16:35:24] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[16:35:29] <tomprince> ?
[16:35:58] <fuzzie> using the name 'GetTickCount' is really not exactly moving towards sane header files :P
[16:36:51] <tomprince> Feel free to change it.
[16:37:20] <tomprince> I don't care about the name, just the silly macro.
[16:37:53] <fuzzie> ok
[16:40:02] <fuzzie> mostly it was 'um!' because you collided with a bunch of stuff again and i was o.Oing at the name
[16:42:38] <fuzzie> i wonder if that function is the only thing pulling in the system headers
[16:45:11] <tomprince> Includes in sys/ ? There is also sys/stat.h in VFS, which is needed for Interface/SaveGameIterator/VFS. And sys/types in PluginMgr, which isn't needed here.
[16:45:45] <fuzzie> well, i am mostly thinking of <windows.h>
[16:45:57] <tomprince> The sys/stat.h could/should be localised to VFS, by defining a function that does the mkdir/chmod combo.
[16:46:23] <fuzzie> would be good to do that anyway
[16:46:59] <fuzzie> i hadn't realised how messy that globals.h was
[16:52:02] <fuzzie> but not going to try futzing with it myself without stealing a faster machine to do it on
[16:52:56] <tomprince> You could try it by pushing to github ...
[16:53:16] <fuzzie> yeah, but think of your poor machine as I try all the combinations :)
[16:53:47] <tomprince> All except the windows builders run on an otherwise idle 3-core machine.
[16:54:23] <tomprince> And I plan to move the windows builder there too at some point.
[17:01:48] <gembot_> build #86 of msvc++6 is complete: Failure [failed compile minimal test] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/86
[17:06:23] <wjp> I think I wrote all the necessary 'real' code for the RLE part of this new templated blitter... now just need to call it... *shudder*
[17:06:40] <fuzzie> i seem to have gotten fed up and am ripping includes out
[17:07:41] <tomprince> cleaning up globals.h? Nice.
[17:08:00] <fuzzie> no, other stuff for now
[17:08:20] <fuzzie> well, mostly other stuff, i did touch globals.h
[17:09:47] <fuzzie> so avoiding messing with it much for now would be appreciated
[17:13:33] <tomprince> We seem to need windows.h for hConsole and LibHandle, GetTickCount, and FS stuff.
[17:16:11] <tomprince> So we should be able to nuke it. Push hConsole into Logging. Split off PluginLoader from PluginMgr, put GetTickCount in cpp, and wrap the FS stuff.
[17:16:36] <fuzzie> sounds good
[17:16:46] <fuzzie> but if you could hold off while i struggle with my slow compiler.. :)
[17:16:54] <tomprince> sure.
[17:18:14] <fuzzie> i hadn't realised quite how crazy this had become
[17:28:50] <tomprince> No you're sounding like me ;)
[17:29:25] <tomprince> s/No/Now/
[17:37:57] <fuzzie> heh
[17:38:01] <tomprince> Thoughts on getting rid of the *.cpp in core/CMakeLists.txt?
[17:38:03] <wjp> hm, trying to debug this blitter is hard with random crashes in other code :-(
[17:38:22] <fuzzie> globbing is bad
[17:38:25] <wjp> (any bets on memory corruption? :-) )
[17:38:41] <fuzzie> valgrind!
[17:39:56] <wjp> ==11001== Invalid read of size 2
[17:39:56] <wjp> ==11001== at 0x4FCF7A7: GameScript::AreaType(Scriptable*, Trigger*) (Triggers.cpp:2765)
[17:39:59] <wjp> ==11001== by 0x4FC119A: Trigger::Evaluate(Scriptable*) (GameScript.cpp:2112)
[17:40:13] <wjp> does that ring a bell, or should I blame that on my code? :-)
[17:40:25] <fuzzie> dooon't know
[17:40:40] <fuzzie> cmake seems to be rebuilding my codebase every time i touch msvc-only headers
[17:40:48] <fuzzie> can i make it not do that somehow?
[17:41:04] <dhewg> i get that all the time :\
[17:41:15] <tomprince> msvc only headers?
[17:41:23] <dhewg> is the autohell approach maintained?
[17:41:28] <fuzzie> tomprince: stuff wrapped in _MSC_VER
[17:41:45] <fuzzie> dhewg: we don't care much when it breaks
[17:41:56] <dhewg> hehe
[17:42:02] <dhewg> why's it in there though?
[17:42:19] <fuzzie> at this point, just because cmake is pretty sucky at crosscompiling
[17:42:23] <tomprince> Except my buildbots catch stuff the fails to compile.
[17:43:34] <dhewg> ok, the cloak works a little better now
[17:43:40] <dhewg> i can transform back
[17:43:51] <dhewg> but all other issues are still there :P
[17:44:01] <fuzzie> well, i was only going for 'transform back'
[17:44:15] <dhewg> k, that looks good then
[17:44:50] <fuzzie> i forget what else there was
[17:45:01] <dhewg> well
[17:45:21] <dhewg> the transform back icon/spell is still there if the shapeshift times out
[17:45:32] <dhewg> when you're already in a human form again
[17:46:03] <dhewg> and everything in unequipped while being in the equipped slots, with either the timeout or the transform back
[17:46:20] <dhewg> i get a bunch of "party has lost an item" which look related
[17:47:18] <dhewg> but more importantly, it magically did not fix the portal!
[17:47:27] <fuzzie> right
[17:47:29] <dhewg> :)
[17:47:32] <fuzzie> portal will get fixed later maybe
[17:47:39] <dhewg> aww
[17:47:40] <fuzzie> first is the conditional effects
[17:47:48] <dhewg> icanzhave djinn plz?
[17:47:49] <fuzzie> only i tried that and my whole codebase rebuilt, hence, header work
[17:51:18] <tomprince> Is there any point in keeping the plugin unloading code?
[17:51:43] <dhewg> i wonder why there are plugins at all?
[17:52:03] <tomprince> It is good coding discipline.
[17:52:20] <fuzzie> once upon a time there were multiple video plugins and everything
[17:52:38] <tomprince> And hopefully will be again.
[17:53:03] <fuzzie> it would just pick the first one which worked
[17:53:14] <fuzzie> but tomprince entirely stabotaged that code, i seem to recall :P
[17:55:41] <fuzzie> compile compile compile
[17:57:37] <tomprince> If by first that worked, you mean first that loaded, then that is still around. I don't think there was ever anything else.
[17:57:53] <tomprince> Although I don't think it is whatever happens to be first anymore.
[17:57:55] <fuzzie> tomprince: for audio/video drivers
[17:59:33] <tomprince> Yes. It used to be that PluginMgr would only load one of any given plugin, so would use the first driver plugin of each type that succesfully loaded.
[17:59:53] <fuzzie> now, it loads a whole bunch of plugins, and then fails to use any of them :)
[18:00:24] <tomprince> Well, it uses one of them.
[18:00:48] <fuzzie> ok, now core built..
[18:01:12] <dhewg> that sounds rather slow
[18:01:32] <dhewg> what are you working on?
[18:01:40] <dhewg> you mentioned some PPC
[18:01:50] <tomprince> If it really is that slow, I was serious. Use my buildbots.
[18:02:19] <fuzzie> most of the time has been spent in vim :) but it really is that slow :P
[18:03:55] <dhewg> so what it is?
[18:04:01] <dhewg> an older apple ppc?
[18:04:17] <fuzzie> yes, a 1.2ghz 7447A
[18:04:49] <fuzzie> i also have a 1.6ghz first-gen-netbook-Atom here, which is slower
[18:05:07] <dhewg> ppc is nice :)
[18:05:18] <fuzzie> well, Atom is awful
[18:05:24] <dhewg> yeah
[18:05:32] <fuzzie> i also have a heap of iBook G3 corpses
[18:05:34] <tomprince> But really, is there a reason to keep the plugin unloading code around? It is currently only used for non-debug builds on win32. Which is perhaps our least tested config.
[18:05:34] <wjp> whee, the first sprite succesfully blitted with the new code :-)
[18:06:18] <fuzzie> tomprince: i thinnk you have to ask Avenger, who usually runs those builds
[18:06:52] <fuzzie> that was reason for his heap issues, seldom-used debug library config
[18:08:10] <fuzzie> so many missing headers
[18:08:17] <tomprince> Can you ask him, next time he shows up, since it seems I am often asleep then. :)
[18:08:18] <dhewg> http://static.hackmii.com/dhewg/pixelrat.png
[18:08:43] <dhewg> fancy helm though
[18:08:43] <fuzzie> nice
[18:09:01] <dhewg> the troll has a helm too, but isnt pixelated
[18:09:13] <dhewg> and there's just nothing a jelly
[18:10:58] <wjp> ooh, shiny
[18:11:28] <wjp> clown colours gone horribly wrong?
[18:11:46] <fuzzie> tomprince: if i remember..
[18:11:47] <dhewg> looks like the same as on the dragons
[18:13:09] <dhewg> hah
[18:13:23] <dhewg> anyone got a savegame at the shadow dragon?
[18:13:37] <dhewg> or warp there, ar1402
[18:14:07] <dhewg> center the cam on the dragon, then select char 1, then char 2
[18:15:33] <fuzzie> ok, i have to run, so you get an untested commit
[18:16:01] <fuzzie> will be back in a while.
[18:16:06] <CIA-52> GemRB: 03fuzzie * ra6b2c7ac1246 10gemrb/gemrb/ (76 files in 16 dirs): pull some headers out of headers, manually
[18:17:39] <gembot_> build #89 of msvc++6 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/89
[18:23:55] <gembot_> build #90 of msvc++6 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/90 blamelist: fuzzie@fuzzie.org
[18:33:02] <CIA-52> GemRB: 03tom.prince * r27ef23dce64e 10gemrb/gemrb/core/ (GameData.h Interface.h):
[18:33:02] <CIA-52> GemRB: Fix compile failure on msvc wrt template instantiation.
[18:33:02] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:36:36] <tomprince> Is it scary that I knew exactly what the failure was, and how to fix it, without looking at the logs. (except for the specific classes involved)
[18:47:12] <dhewg> heh :)
[18:47:35] <dhewg> tomprince: i looked at the libc++ unordered_map
[18:47:45] <dhewg> it seems to be dependent on c++0x
[18:48:12] <fuzzie> tomprince: thankyou!
[18:48:12] <dhewg> so im still not sure which implementation we should use
[18:48:19] <dhewg> or maybe just base on
[18:48:31] <tomprince> You sure? I definitely supports it, but I think the c++0x support is optional.
[18:48:47] <dhewg> there're some rvalue defines
[18:48:48] <tomprince> (Although I haven't looked at it in depth)
[18:49:00] <dhewg> but there's nullptr and stuff without defines
[18:49:16] <dhewg> and initializer_list
[18:49:25] <fuzzie> no-one had any idea about why cmake's dependency stuff is being mean to me?
[18:49:38] <dhewg> hehe
[18:49:57] <dhewg> well there's tons of stuff out there
[18:50:11] <dhewg> but try ripping the unsorted_map out of boost
[18:50:25] <fuzzie> ah, it seems that cmake is just looking at #include lines..
[18:50:26] <dhewg> thats not as easy as it sounds :)
[18:50:53] <fuzzie> dhewg: this is why no-one's done it yet, of course :/
[18:51:02] <dhewg> yeah its annoying
[18:51:08] <dhewg> but i have this itch
[18:51:31] <dhewg> all these in tree cache variations do itch :P
[18:52:29] <dhewg> i didnt yet look at libstdc++. they switched to gpl3 with 4.2 or so
[18:52:42] <dhewg> maybe thats easy to rip out for this project
[18:52:45] <fuzzie> hm, the cmake faq is basically "ha ha, our dependency scanner sucks" :-/
[18:52:55] <dhewg> haha
[18:52:58] <dhewg> autohell!
[18:53:32] <CIA-52> GemRB: 03tom.prince * r60060c7f6230 10gemrb/gemrb/core/ (Region.cpp Region.h):
[18:53:32] <CIA-52> GemRB: Remove copy constructor/assignment/destructor for Region/Point.
[18:53:32] <CIA-52> GemRB: They are exactly the same as the default ones, so just let the
[18:53:32] <CIA-52> GemRB: compiler synthesize them.
[18:53:32] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:54:03] <gembot_> build #91 of msvc++6 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/91
[18:56:03] <fuzzie> i have been given a bowl of popcorn, to eat while i wait for my compiles
[18:57:21] <dhewg> hehe
[18:57:58] <fuzzie> not quite the cmake assistance i was looking for
[18:58:42] --> barra_home has joined #gemrb
[18:59:04] <gembot_> build #92 of msvc++6 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/92
[19:00:24] <fuzzie> intrsting
[19:00:45] <dhewg> why does cmake not use the gcc buildin depend stuff anyway?
[19:00:57] <dhewg> for their broken percentage stuff?
[19:02:42] <CIA-52> GemRB: 03fuzzie * rae9d0bb18028 10gemrb/gemrb/plugins/CREImporter/CREImporter.h: s/class Effect/struct Effect/
[19:08:22] <CIA-52> GemRB: 03tom.prince * r272d2c485f1c 10gemrb/gemrb/core/CMakeLists.txt:
[19:08:22] <CIA-52> GemRB: cmake: Don't use globbing to grab files in core.
[19:08:22] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:09:42] <dhewg> poor fuzzie :P
[19:10:32] <fuzzie> well, after discovering that the official cmake dependency philosophy seems to be "more is better!", maybe i should bash at automake a bit
[19:12:31] <CIA-52> GemRB: 03tom.prince * r4d415ba4cf62 10gemrb/gemrb/core/Scriptable/Scriptable.h:
[19:12:31] <CIA-52> GemRB: s/class PathNode/struct PathNode/
[19:12:31] <CIA-52> GemRB: Detected by clang.
[19:12:31] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:12:52] * fuzzie sticks an Apple advertising sticker on tomprince
[19:14:43] <tomprince> apple?
[19:15:22] <tomprince> apple+google+arm+...+academia+... :)
[19:15:40] <gembot_> build #93 of msvc++6 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/93
[19:17:49] <fuzzie> but, let us be honest here, mostly apple :p
[19:18:02] <fuzzie> i'm just wondering if i should've stuck a msvc note in the other commit ;p
[19:19:55] <tomprince> At this point yes.
[19:20:18] <fuzzie> we are all grateful for clang
[19:20:40] <tomprince> My understand is that it was originally a thesis project (or several).
[19:21:15] <fuzzie> the whole project has come a long way :)
[19:21:18] <CIA-52> GemRB: 03fuzzie * rd429bdccb641 10gemrb/gemrb/ (12 files in 3 dirs): a few more headers-out-of-headers
[19:22:25] <tomprince> I think this is the first time by buildbot hasn't been able to keep up. :)
[19:25:08] <fuzzie> poor thing
[19:30:23] <wjp> whee, blitting not crashing anymore :-)
[19:30:46] <fuzzie> hehe
[19:30:52] <wjp> all of BlitGameSprite is now using the new code, but only for the RLE bits
[19:30:58] <fuzzie> that's great
[19:31:05] <fuzzie> isn't almost all of it RLE anyway?
[19:31:08] <wjp> yes
[19:31:24] <wjp> oh, and only 32 bit
[19:32:36] <wjp> I wonder if the poor compiler can handle all the inlining and reduction it's expected to do
[19:33:12] <wjp> speed is pretty much the same as it was
[19:33:17] <fuzzie> well, i don't know what you wrote, but it's not complicated in general, just time-consuming
[19:33:54] <fuzzie> although i don't know if there are issues with depth, if you didn't just create a single templated function
[19:34:11] <wjp> I tested g++ can do all the basic reduction steps I'd like it to do, but not if it does all of them at once
[19:34:22] <fuzzie> got a diff? :)
[19:34:28] <wjp> I suppose
[19:34:45] <fuzzie> i'm in no hurry, just curious if it improves here
[19:36:20] <wjp> let me know if it applies at all: http://www.usecode.org/gemrb/sprite_templated.patch
[19:36:38] <wjp> (I've done some other half-related stuff in a separate patch before this)
[19:36:56] <wjp> support for grey/sepia tones in the tile renderer, to be specific
[19:37:51] <wjp> it's also completely un-cleaned-up, so don't look too closely :-)
[19:38:10] <fuzzie> seems happy, had to move the .inl includes
[19:39:17] <fuzzie> framerate is indeed not much changed though
[19:41:45] <wjp> 30 instantiations currently, if I'm counting correctly
[19:42:53] <wjp> but enough templating madness for tonight
[19:58:15] <fuzzie> ah, you didn't update BlitSprite
[19:59:59] <fuzzie> i wonder what's using that
[20:00:13] <fuzzie> oh, right, the stupid MOS files..
[20:02:38] <fuzzie> oh dear, we call BuildSpriteCover for every anim on every frame?
[20:03:06] <fuzzie> ah no, i'm jsut getting badness
[20:03:46] <tomprince> fuzzie: Do you want to have a quick sanity check at the second patch in my vfs branch?
[20:04:15] <fuzzie> which one?
[20:04:47] <fuzzie> MakeDirectory?
[20:04:51] <tomprince> Yes.
[20:05:14] <fuzzie> msvc6 doesn't hate it?
[20:06:17] <fuzzie> all of it looks fine to me
[20:06:28] <fuzzie> oh, not the CreateSaveGame one
[20:07:13] <fuzzie> show the strings if a save fails, please
[20:08:22] <fuzzie> that code is not good as-is though, so we can fix that later
[20:08:33] <fuzzie> when did that get broken :(
[20:09:04] <tomprince> Like so?
[20:09:10] <fuzzie> i guess Avenger broke it..
[20:09:49] <fuzzie> looks great
[20:10:25] <tomprince> Stupid mingw, takes 2+ times as much as any other build. :)
[20:11:35] <CIA-52> GemRB: 03tom.prince * rda6c9c49557a 10gemrb/gemrb/core/ (4 files in 2 dirs):
[20:11:35] <CIA-52> GemRB: VFS: Add MakeDirectory function.
[20:11:35] <CIA-52> GemRB: This also add error checking to it.
[20:11:35] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[20:11:36] <CIA-52> GemRB: 03tom.prince * rcbafd1d014b0 10gemrb/gemrb/includes/exports.h:
[20:11:36] <CIA-52> GemRB: Add macros for marking things for GCC to warn about.
[20:11:37] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[20:11:43] <CIA-52> GemRB: 03tom.prince * r7f5aff83144f 10gemrb/gemrb/core/ (Scriptable/Actor.cpp System/VFS.h):
[20:11:43] <CIA-52> GemRB: Teach gcc that PathJoin expect a terminal NULL.
[20:11:43] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[20:11:53] <CIA-52> GemRB: 03tom.prince * rff7fdb54f512 10gemrb/gemrb/ (12 files in 3 dirs): Merge remote-tracking branch 'sf'
[20:11:58] <fuzzie> but also if you keep changing headers, nothing will ever get done :)
[20:12:01] <gembot_> build #76 of cmake g++-4.5.2 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.5.2/builds/76 blamelist: Alyssa Milburn <fuzzie@fuzzie.org>, Tom Prince <tom.prince@ualberta.net>
[20:13:49] <gembot_> build #74 of cmake g++-4.4.5 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4.5/builds/74 blamelist: Alyssa Milburn <fuzzie@fuzzie.org>, Tom Prince <tom.prince@ualberta.net>
[20:14:07] <gembot_> build #74 of autotools clang++ is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/autotools%20clang%2B%2B/builds/74 blamelist: Alyssa Milburn <fuzzie@fuzzie.org>, Tom Prince <tom.prince@ualberta.net>
[20:15:41] <gembot_> build #75 of cmake clang++ is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/75 blamelist: Alyssa Milburn <fuzzie@fuzzie.org>, Tom Prince <tom.prince@ualberta.net>
[20:15:49] <gembot_> build #74 of autotools g++-4.5.2 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.5.2/builds/74 blamelist: Alyssa Milburn <fuzzie@fuzzie.org>, Tom Prince <tom.prince@ualberta.net>
[20:16:00] <tomprince> One more to go :)
[20:25:00] <gembot_> build #75 of cmake g++-4.4.5 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4.5/builds/75
[20:32:29] <gembot_> build #77 of cmake g++-4.5.2 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.5.2/builds/77
[20:33:14] <CIA-52> GemRB: 03tom.prince * r9616834f92f7 10gemrb/gemrb/plugins/ (6 files in 4 dirs):
[20:33:14] <CIA-52> GemRB: Don't keep files open longer than necessary.
[20:33:14] <CIA-52> GemRB: 2DAImporter, IDSImporter, INIImporter and PLTImporter all
[20:33:14] <CIA-52> GemRB: do all of their reading in ->Open, so close the file when
[20:33:14] <CIA-52> GemRB: we are done.
[20:33:14] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[20:34:37] --> Avenger has joined #gemrb
[20:34:55] <Avenger> music playing in pst seems to be buggy
[20:34:58] <Avenger> [OpenAL]: Error playing music source: 0xa003 [ERROR]
[20:34:59] <Avenger> [OpenAL]: Unable to buffer music data: 0xa003 [ERROR]
[20:36:16] <gembot_> build #75 of autotools clang++ is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/autotools%20clang%2B%2B/builds/75
[20:37:07] <gembot_> build #76 of cmake clang++ is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/76
[20:38:02] <fuzzie> Avenger: as far as i can tell, it's something new with openal
[20:39:40] <Avenger> --> plugins/GUIScript/GUIScript.cpp:1234:2: warning: array index of '1' indexes past the end of an array (that contains 1 elements) [-Warray-bounds]
[20:39:57] <Avenger> as far as i see this is a false warning
[20:40:23] <tomprince> Yes.
[20:40:45] <gembot_> build #75 of autotools g++-4.5.2 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.5.2/builds/75
[20:40:57] <Avenger> fixed the parentheses
[20:41:05] <Avenger> the alignment change i don't care about :)
[20:41:08] <tomprince> Avenger: Is there any reason to keep the plugin unloading code around?
[20:41:17] <tomprince> It is not very well tested.
[20:42:16] <CIA-52> GemRB: 03avenger_teambg * r1c59c5c26968 10gemrb/gemrb/core/GUI/MapControl.cpp: fixed a warning
[20:42:22] <tomprince> This is what I would like to do: https://github.com/tomprince/gemrb/compare/master...plugin-loader
[20:42:23] <Avenger> i don't know, we may need it later
[20:43:37] <Avenger> we may need unloading if something in the config changes, though i don't really see many cases. Maybe in pst, there is an option to turn off sound processing?
[20:43:56] <fuzzie> we can swap those around internally
[20:44:15] <tomprince> Well, in that case, we would need to unload a specific plugin. But that would require a bunch of other changes as well, anyway.
[20:45:16] <Avenger> so, when you talk about plugin unloading, you meant the cleanup?
[20:45:28] <-- mihairu has left IRC (Remote host closed the connection)
[20:46:07] <fuzzie> the FreeLibrary for the DLL
[20:46:13] <tomprince> Yes, the code that is currently in the destructor of PluginMgr, that is only called with _DEBUG not defined on WIN32.
[20:46:47] <fuzzie> the cleanup functions get called anyway
[20:47:52] <Avenger> I don't see how LoadPlugins is called...
[20:48:27] <Avenger> the code near 1433 in Interface
[20:50:18] <Avenger> it remains in a separate object, that is constructed, how that call works? I might be too tired :)
[20:50:22] <Avenger> but i don't see
[20:50:26] <barra_home> hola :-)
[20:50:37] <barra_home> do you guys host the buildbot yourself?
[20:50:48] <barra_home> and if so, how complicated was it to set it up?
[20:51:19] <Avenger> dunno, but it is a nice thing
[20:51:33] <barra_home> do you happen to know who set it up?
[20:51:36] <tomprince> I host it. It isn't terribly complicated.
[20:51:37] <Avenger> tomprince
[20:51:57] <tomprince> I have been fiddling with the config since I created it though.
[20:51:58] <fuzzie> dhewg maintains the scummvm buildbot, if you want someone else to bother
[20:52:08] <Avenger> :)
[20:52:20] <barra_home> not trying to steal your time fuzzie :-)
[20:52:32] <barra_home> just curious as we considered to set up a buildbot for our project in the past
[20:52:44] <barra_home> so first hand experience is always a huge plus
[20:52:57] <fuzzie> well i have no clue about any of it :)
[20:53:15] <tomprince> Avenger: so do you have any objections to removing the unloading code?
[20:56:39] <fuzzie> it's not very tidy not freeing your resources :P
[20:56:45] <fuzzie> but doesn't seem to matter, so.
[20:57:59] <tomprince> Except when the OS is going to do it for you, potentially more effeciently.
[20:58:39] <fuzzie> but then everything gets freed on exit :)
[20:59:01] <fuzzie> since we have no-one running any debug tools on windows, seems useless
[21:01:11] <tomprince> ...
[21:01:48] <fuzzie> i mean, am i missing a point here?
[21:02:16] <tomprince> Just wondering whether I should push.
[21:02:22] <fuzzie> do it!
[21:03:01] <CIA-52> GemRB: 03tom.prince * r123a43ff25e4 10gemrb/gemrb/core/ (7 files):
[21:03:01] <CIA-52> GemRB: PluginMgr: Split off plugin loading from plugin registry.
[21:03:01] <CIA-52> GemRB: This also removes almost unused code for unloading plugins.
[21:03:01] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[21:03:30] <tomprince> I guss that commit could be worded better :(
[21:05:20] <fuzzie> oh
[21:05:22] <fuzzie> that is less nice :P
[21:05:53] <tomprince> I didn't want to add a Held object, just to delete it in the next commit.
[21:06:11] <fuzzie> sure, just now we can't just 'git revert' if it's a problem
[21:06:19] <fuzzie> well, i suppose we can :-p but you might not appreciate
[21:08:11] <tomprince> Or just poke me, and I will rewrite the PluginLoader class.
[21:11:00] <tomprince> done: plugin-unloader on github :)
[21:11:16] <fuzzie> hehe
[21:11:21] <fuzzie> awesome :)
[21:11:36] <tomprince> Since I still had it in my reflog of HEAD.
[21:22:47] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[21:25:36] --- barra_home is now known as barraAway
[21:30:01] <Avenger> bye!
[21:30:03] <-- Avenger has left IRC (Quit: bye!)
[21:43:36] <tomprince> https://gist.github.com/950907
[21:44:05] <tomprince> The wording of the comment doesn't really capture what I mean, though.
[21:44:42] <tomprince> It is entirely clear to me what should go in there, but not at all clear how to express it in words.
[21:45:30] <tomprince> I don't want it to become a dumping ground like globals.h or win32def.h.
[21:46:42] <-- barraAway has left IRC (Quit: Verlassend)
[21:46:45] <fuzzie> You wouldn't rather fix the other files?
[21:47:01] <tomprince> I would, by getting rid of them.
[21:47:16] <fuzzie> I mean, that is the intention of the other ones.
[21:47:27] <fuzzie> The M_PI, the M_PI_2, the round definition, the snprintf defines, etc.
[21:48:36] <tomprince> Like I said, the description I gave wasn't clear. I don't consider those appropriate for exports.h.
[21:48:50] <fuzzie> Ok.
[21:49:29] <dhewg> ohboi
[21:49:52] <fuzzie> It seems silly to me to split compiler hacks into multiple files.
[21:50:25] <tomprince> I sort of have in mind compiler hacks vs. portability wrappers.
[21:51:39] <fuzzie> Well, I *don't* think it's a good idea to decide that everything else should be a wrapped function, if that's what you man.
[21:51:43] <fuzzie> mean.
[21:52:49] <fuzzie> I'd have to think about the whole organisation there.
[21:53:05] <fuzzie> There's plenty of stuff in core includes which would probably be far better off in includes/.
[21:53:24] <dhewg> fuzzie: http://eh.wtf.la/dump/0012-BIFImporter-epic-load-game-speedup.patch
[21:53:46] <fuzzie> dhewg: hm, i have that disabled :P
[21:53:54] <dhewg> thats like soo slow
[21:54:05] <fuzzie> i just have LoadProgress NOPed because it annoys me and causes bugs
[21:54:14] <dhewg> its the frame limiter with a delay
[21:55:02] <tomprince> Well, it isn't entirely clear to me what the distinction between includes and core is.
[21:55:32] <dhewg> not that all those redraws are fast, but for my savegames with all those files thats like day and night
[21:55:37] <tomprince> Or ... something.
[21:55:41] <fuzzie> includes is meant to have the core compiler compat headers - like your exports.h - and then all the random headers with #defines in them
[21:56:01] <fuzzie> at the moment we include a ridiculous number of core headers just for a couple of values
[21:56:31] <fuzzie> oh dear lord git is annoying sometimes
[21:58:00] <CIA-52> GemRB: 03dhewg * r2c87aaf9a736 10gemrb/gemrb/plugins/BIFImporter/BIFImporter.cpp: BIFImporter: epic load game speedup
[21:58:07] <fuzzie> i was rather worried to find Sprite2D.h in globals.h, which is what made me go clean up the headers a bit
[21:58:51] <fuzzie> but of course you've moved the compatibility string defines/functions into core
[21:59:36] <tomprince> Well most of the stuff in System is compat.
[21:59:58] <fuzzie> is it? i mean, i thought we're trying to move away from compat for the fs
[22:00:07] <fuzzie> well, we *did* move away from compat for the fs, unless i'm mistaken
[22:00:34] <fuzzie> if i do _fopen now, it won't work, right?
[22:00:51] <tomprince> I hope it won't.
[22:00:53] <tomprince> :)
[22:01:01] <fuzzie> and that makes perfect sense
[22:01:51] <fuzzie> but i don't agree with removing stuff like snprintf compat from core headers unless no code is using it
[22:02:32] <fuzzie> same goes for stricmp, which you already moved into String.h
[22:03:07] <fuzzie> of course, i can be convinced, maybe :)
[22:05:13] <tomprince> I think part of my thinking is that stuff in includes should be stuff that doesn't have a corresponding cpp file.
[22:06:21] <fuzzie> right
[22:06:48] <fuzzie> not unreasonable
[22:07:05] <fuzzie> but you want anything string-related to be in String.h, with or without implementation?
[22:07:17] <dhewg> that include/ confused me too
[22:08:47] <dhewg> from what im used to is that you have an include dir for "others", like the plugins get a -I to there, but not to anything in core/
[22:09:21] <fuzzie> well, as usual, it's a huge mess
[22:09:26] <dhewg> :)
[22:09:33] <dhewg> fixable though
[22:09:36] <fuzzie> i just don't want it to be resolved by making it an even more difficult-to-code-with mess
[22:09:46] <dhewg> yeah
[22:10:29] <fuzzie> ok, i just compared with and without that patch i applied
[22:10:32] <fuzzie> and jesus, that's terifying
[22:10:40] <dhewg> also, that waterfall for scummvm is like a hueg wall of ports now
[22:10:45] <fuzzie> i was just ignoring the blitting cost in the profiler, obviously, since i could see it was massively inefficient
[22:11:21] <fuzzie> so seriously, epic load game speedup, everyone love at dhewg
[22:11:35] <dhewg> heh
[22:11:37] <dhewg> and you know what
[22:12:00] <dhewg> i wasted like an hour to add support for direct zlib dumps for bif savegames
[22:12:12] <dhewg> only to figure out that it doesnt make any difference at all :P
[22:12:40] <fuzzie> wow, that's crazy depressing
[22:12:43] <dhewg> do i get my portal fix for that now? :P
[22:13:05] <CIA-52> GemRB: 03tom.prince * rc99c4bb85958 10gemrb/gemrb/ (5 files in 3 dirs):
[22:13:05] <CIA-52> GemRB: Video: Split SetFullscreenMode from ToggleFullscreenMode.
[22:13:05] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[22:13:33] <tomprince> I don't like having functions that have one argument value where they do something different. :)
[22:14:09] <fuzzie> dhewg: not if tomprince breaks my codebase every few minutes :P
[22:14:22] <dhewg> dont rebase :P
[22:14:54] <tomprince> bug: https://gist.github.com/950933
[22:15:13] <tomprince> ?
[22:15:43] <fuzzie> ugh
[22:15:45] <fuzzie> i hate that code
[22:16:14] <fuzzie> my fault i think
[22:16:18] <fuzzie> in any case, yes, bug, fix pls
[22:16:48] <fuzzie> yes, that is totally my fault
[22:17:01] <fuzzie> copy-and-pasted that from uncommitted code and screwed it up
[22:17:03] <fuzzie> good spotting!
[22:17:07] <tomprince> msvc6 :)
[22:18:21] <CIA-52> GemRB: 03tom.prince * r126ae84ba9db 10gemrb/gemrb/core/Interface.cpp:
[22:18:21] <CIA-52> GemRB: Fix comparison of bool with int in SetCutSceneMode.
[22:18:21] <CIA-52> GemRB: Reported by msvc6.
[22:18:21] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[22:18:24] <tomprince> That also prompted the fullscreen function split.
[22:19:04] <tomprince> Once I moved the pragmas somewhere imported by everything, you can actually look at them.
[22:19:21] <tomprince> http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/102/steps/compile/logs/warnings
[22:19:35] <fuzzie> ah, much nicer
[22:19:53] <tomprince> ~186 to ~47
[22:24:13] <dhewg> why are the stream read/write functions using void* ?
[22:24:22] <dhewg> thats like sick for overloading :P
[22:24:49] <fuzzie> because they're meant meant to be overloaded
[22:24:55] <fuzzie> the functions are all explicit
[22:24:56] <tomprince> Try changing them to char, and see if anything breaks?
[22:25:59] <dhewg> tomprince: didnt try, just wondered if there's a reason
[22:26:08] <fuzzie> i don't think there's a reason
[22:26:37] <fuzzie> i mean, for the void*
[22:26:42] <dhewg> if i wanted to add a Write(DataSteam *s, int len) now, that wont really work
[22:26:52] <fuzzie> no
[22:26:56] <fuzzie> but please don't do that anyway
[22:27:14] <dhewg> why not?
[22:27:22] <fuzzie> because it makes things less readable
[22:27:28] <fuzzie> WriteDataStream pls
[22:27:42] <dhewg> hm ok
[22:27:46] <fuzzie> i am not going to be convincing in my arguments for _ for member variables if functions start being overloaded ;p
[22:29:03] <dhewg> well since there's a void* there's a chance nobody will overload :P
[22:29:29] <dhewg> thats all part of the plan i guess
[22:29:54] <fuzzie> i wouldn't even begin to entertain the possibility of us being that competent
[22:30:41] <dhewg> heh
[22:31:58] <fuzzie> atm i am just getting a bit too freustrated about badly-written code
[22:34:07] <tomprince> I think part of my reasoning is that the contents of a header file should all be related. So strings stuff, fs stuff, logging stuff, compiler (as opposed to library) stuff. Even if we then have a header whose purpose is to include each of those headers, and be included everywhere.
[22:34:34] <fuzzie> yeah
[22:34:51] <fuzzie> i'd prefer a "stuff which pretty much everything is going to need" split :)
[22:35:25] <fuzzie> otherwise you end up saying you want the string stuff everywhere, and suddenly you're dragging in a huge amount of string stuff
[22:35:32] <fuzzie> but i'm just pondering, haven't thought about it lots
[22:36:09] <tomprince> That makes two of us.
[22:36:20] <dhewg> also, sane types are missing
[22:36:41] <dhewg> or im just not used to writing "unsigned int" everywhere
[22:36:57] <lynxlynxlynx> ieDword :()
[22:37:16] <dhewg> nah :P
[22:37:17] <fuzzie> yeah
[22:37:18] <dhewg> u32!
[22:37:23] <tomprince> Well, we aren't consistent about types.
[22:37:24] <fuzzie> i'd prefer ieDword for the actual data types
[22:37:32] <fuzzie> and something like uint for random unsigned int
[22:37:47] <dhewg> and byte as in unsigned char for streams!
[22:37:54] <tomprince> That makes sense.
[22:38:08] <fuzzie> well, alas, my proposal would give you ieByte for that :p
[22:38:42] <tomprince> I tend mostly to use size_t for random unsigned ints. :)
[22:39:07] <fuzzie> but *then* you have to drag cstdlib in everywhere :P
[22:39:23] <fuzzie> also it doesn't really make much sense :)
[22:39:57] <tomprince> I am not saying it is sane :) just a habit.
[22:40:24] <fuzzie> this fx_cast_spell_on_condition idea i had is not so easy
[22:41:53] <fuzzie> will have to look more in the morning, should sleep
[22:42:49] <fuzzie> but it's so very completely wrong right now, i reformatted it then rewrote bits then recommented and now, the sulking.
[22:43:32] <tomprince> :)
[22:44:18] <fuzzie> you shoudl really try loading a save with a build after dhewg's fix though!
[22:50:48] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[23:02:32] <tomprince> Started hacking on checking return values: cleanup branch.