#gemrb@irc.freenode.net logs for 19 Feb 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[01:30:05] --> Bo_Thomsen has joined #GemRb
[01:41:17] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[02:21:03] --> acimmarusti has joined #GemRb
[02:30:13] <acimmarusti> hi, I just installed gemrb 0.6.3 on my debian testing system. I have the IceWind Dale game (PC DVD version which includes iwd, iwd expansion and iwd2). I couldn't get wine 1.0.1 from the debian repositories to extract the cabs, so I did it with unshield. Now I just want to know if I should but in gamepath, cd1, cd2, cd3, etc all pointing to the same directory?
[02:33:50] <acimmarusti> I tried to tidy up the directory structure after using unshield as best as I could, but I don't really know if there's something I should be careful about
[02:38:56] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[02:39:48] <-- acimmarusti has left #GemRb
[03:47:30] <-- tomprince has left IRC (Ping timeout: 240 seconds)
[03:48:41] --> tomprince has joined #GemRb
[07:47:51] --> lynxlynxlynx has joined #GemRb
[07:47:51] <-- lynxlynxlynx has left IRC (Changing host)
[07:47:51] --> lynxlynxlynx has joined #GemRb
[07:47:51] --- ChanServ gives channel operator status to lynxlynxlynx
[09:30:39] --> edheldil_ has joined #GemRb
[10:12:53] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[10:48:04] --> Avenger has joined #GemRb
[10:48:04] --- ChanServ gives channel operator status to Avenger
[10:51:56] --> Bo_Thomsen has joined #GemRb
[10:53:01] <Avenger> lynxlynxlynx: if you miss the walksounds, check if cmake actually copied walksnd.2da
[10:53:28] <Avenger> same for pst projectiles, new files are usually ignored
[11:00:57] <lynxlynxlynx> i don't install
[11:01:20] <lynxlynxlynx> the commit reminded me it is animation based, not terrain
[11:01:45] <Avenger> but i added all bg1 anims
[11:01:52] <Avenger> and i hear sounds
[11:02:22] <Avenger> pathfind.2da has some effect too
[11:02:47] <lynxlynxlynx> i'm testing with that save from AR4800
[11:03:09] <Avenger> it works this way: most anims got a single animation, but certain anims like PC avatars come with searchmap based sounds, those are listed in pathfind.2da
[11:03:11] <lynxlynxlynx> which volume do the walksounds use?
[11:03:14] <Avenger> err single sound
[11:04:00] <Avenger> its played by core->GetAudioDrv()->Play( Sound,Pos.x,Pos.y, 0, &len );
[11:04:08] <Avenger> probably effects
[11:04:17] <lynxlynxlynx> those overrides are different for bg1 and 2
[11:04:25] <Avenger> i'm not sure we support all volumes, btw
[11:06:56] <lynxlynxlynx> it's interesting that also the b type is different in bg1/2
[11:07:06] <lynxlynxlynx> it looks like it has been so for ages
[11:09:11] <lynxlynxlynx> oh, i had it disabled ("character movement sounds")
[11:10:07] <lynxlynxlynx> Footsteps=1 ok, must be just a gui thing
[11:11:15] <lynxlynxlynx> odd
[11:15:59] <Avenger> hmm
[11:16:12] <Avenger> wal_mt exists only in bg2
[11:29:39] <Avenger> i don't understand this bugreport from beholder: Another critical bug. Chapters not switching from 2 to 3... Mulahey dead, party return to Nashkel, but chapter still 2.
[11:29:55] <Avenger> ar4800 (nashkel) doesn't handle that
[11:30:20] <Avenger> ok, there is a guy who appears there in chapter 3
[11:32:47] <fuzzie> what does handle it, mulahey's death?
[11:33:45] <fuzzie> yes, in ar5405
[11:34:12] <fuzzie> triggered on the letter
[11:34:57] <fuzzie> it looks like the only thing which could go wrong there is forgetting to pick up the letter
[11:37:06] <fuzzie> is the shooting-through-walls thing just the bug where the incorrect searchmap square is checked?
[11:40:17] <Avenger> yes, it works for me
[11:40:31] <Avenger> it needs mulahey dead and the letter in party inventory
[11:40:49] <Avenger> shoot through walls: dunno
[11:40:50] <fuzzie> i guess ask about the letter :)
[11:41:04] <Avenger> i wrote this: This works for me. You maybe forgot to pick the item needed to trigger chapter 3.
[11:41:21] <fuzzie> there's a bug where the map code does the wrong thing when working out the searchmap square
[11:42:01] <Avenger> there is a debug key to show the searchmap overlaid on the area graphics
[11:42:12] <Avenger> it seems perfect to me
[11:42:16] <Avenger> i already checked that
[11:42:21] <fuzzie> yeah? ok
[11:42:35] <fuzzie> weird then
[11:42:40] <fuzzie> you can reproduce it in bg2 very well
[11:42:43] <Avenger> i fixed some searchmap bugs recently (not so recently)
[11:42:51] <Avenger> maybe in January
[11:42:53] <fuzzie> but it uses this weird SmallFog thing
[11:43:20] <Avenger> that's because searchmap tiles are not the same size in games
[11:43:26] <fuzzie> yeah, i know why it is :)
[11:43:30] <fuzzie> but i don't understand how it works
[11:43:59] <fuzzie> let me build latest version, and see
[11:46:00] <Avenger> this is only for visibility, not searchmap. hmm, maybe the searchmap is the same size?
[11:47:14] <fuzzie> you changed GetBlocked a few days ago, commit message "added door hacks to the maze setup", but i think everything else didn't change the behaviour
[11:49:24] <Avenger> i changed the door flags only
[11:49:55] <Avenger> basically there are two types of doors: 1. opaque and impassable 2. only impassable
[11:50:21] <fuzzie> sure, it sounds fine
[11:50:35] <Avenger> that's what i changed, i think
[11:50:37] <fuzzie> yep
[11:51:01] <Avenger> maybe something about sidewalls too ?
[11:51:05] <fuzzie> nope
[11:51:38] <Avenger> ok, i considered it, but i didn't want to change it because we talked
[11:51:41] <fuzzie> we did talk about those, how the pathfind.2da sets everything to be sidewall
[11:52:19] <Avenger> yep, i don't think it is correct, but setting it back to an earlier state would probably be wrong too
[11:52:31] <fuzzie> yes
[11:52:45] <Avenger> so i just fixed the clearly buggy part where doors were sometimes passable
[11:52:49] <fuzzie> i just changed the code, because i have no idea what to put in pathfind.2da :)
[11:53:09] <Avenger> but it is easy
[11:54:23] <Avenger> btw, the flags are : PASSABLE 8 1 1 1 1 1 1 1 0 1 8 0 0 8 3 1, apparently no 4 in them
[11:54:26] <fuzzie> yep
[11:54:47] <fuzzie> the first one used to be 4, but it got changed a long time ago
[11:55:11] <Avenger> so all would be sidewall, that means, all lets you see a few bits past them
[11:55:20] <fuzzie> (and i changed the searchmap code to show sidewalls in a different colour, you can quickly see that none of them should allow you to shoot through them)
[11:55:42] <Avenger> well, sidewall isn't about passability
[11:55:45] <Avenger> it is visibility
[11:55:51] <fuzzie> sure
[11:55:55] <fuzzie> but for explored stuff only
[11:56:06] <Avenger> neither 4 or 8 should change shooting through
[11:56:08] <fuzzie> but, IsVisible is only used for stuff like CanSee
[11:56:21] <Avenger> hmm, oh
[11:56:28] <Avenger> i know what's wrong
[11:56:53] <fuzzie> so, i marked the sidewalls in blue and the impassible in red
[11:56:55] <Avenger> you know, sometimes you can see a tile, but you cannot see the actor on it?
[11:57:16] <Avenger> maybe that's the problem?
[11:57:19] <fuzzie> isn't that this wrong-searchmap-square bug?
[11:57:26] <fuzzie> i will take a screenshot
[11:57:34] <Avenger> well, it is not wrong, just lack of feature, i think
[11:58:05] <fuzzie> hm, i have lost gemrb
[11:58:09] <Avenger> ???
[11:58:14] <fuzzie> the window
[11:58:19] <fuzzie> oh, it's here
[11:58:19] <Avenger> crashed?
[12:00:39] <fuzzie> http://fuzzie.org/nfs/gemrb_searchmap_bug.png
[12:00:56] <fuzzie> ^- the explore code is picking the searchmap square which is too far right+below
[12:01:19] <fuzzie> so poor minsc is inside the sidewall, and so can't see more than a few pixels
[12:01:28] <Avenger> yes i thought that this is the problem
[12:02:24] <Avenger> hmm, ok, this is a problem, he shouldn't be standing in a point where any of his 4 searchmap tiles is blocked
[12:02:40] <Avenger> right?
[12:02:58] <fuzzie> he has 9 searchmap tiles
[12:03:03] <Avenger> 9?
[12:03:06] <fuzzie> 3x3
[12:03:14] <Avenger> hmm, maybe 9
[12:03:51] <Avenger> anyway, maybe the engine checks only one of them
[12:04:00] <fuzzie> yes, it only checks the centre one
[12:04:01] <Avenger> that's odd, though
[12:04:04] <fuzzie> and it only explores from the centre one
[12:04:13] <fuzzie> but the exploration seems to pick the wrong square to start at :/
[12:04:59] <Avenger> well, this is the kind of bug i hate :)
[12:05:01] <fuzzie> yes
[12:05:46] <fuzzie> i added this red/blue colouring and fixed some things and gave up
[12:11:11] <fuzzie> i suspect the original engine probably does the searchmap conversion somewhere more central, too
[12:11:37] <fuzzie> i guess i should go put it in IDA and take a look at the scripting
[12:16:05] --> Maighstir has joined #GemRb
[12:17:42] <Avenger> the ar4800 bug is because the saved ar4800 has lost its area script
[12:42:53] <Avenger> grr
[12:42:54] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
[12:43:15] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[12:48:08] --> Maighstir has joined #GemRb
[12:49:37] <CIA-29> GemRB: 03avenger_teambg * r3da92b5daa53 10gemrb/gemrb/core/Map.cpp: list area scripts in the debug dump
[12:54:27] <CIA-29> GemRB: 03avenger_teambg * r698a067fc554 10gemrb/gemrb/core/ (GameScript/Actions.cpp Projectile.cpp): don't block script change in areas
[13:28:35] <CIA-29> GemRB: 03avenger_teambg * r94bf84447df2 10gemrb/gemrb/plugins/AREImporter/AREImporter.cpp: forceareascript should set the area script, not the trap scripts :(
[13:30:17] --> Avenger has joined #GemRb
[13:30:17] --- ChanServ gives channel operator status to Avenger
[13:30:37] <Avenger> the complexity is staggering, maybe every single line change should be discussed
[13:31:19] <fuzzie> well, the force area script one looks obvious
[13:32:49] <Avenger> it was obvious when i messed it up, but no one seen it
[13:33:20] <fuzzie> well, i haven't been checking anything since december :/
[13:33:38] <Avenger> you are the only one who can catch my bugs :)
[13:34:56] <Avenger> the area script vanishing was also because of some recent change
[13:35:00] <fuzzie> well i do see some bugs
[13:35:08] <fuzzie> + if (change[3]) {
[13:35:08] <fuzzie> + change[2]=0;
[13:35:12] <fuzzie> ^- that one is just silly :-)
[13:35:26] <Avenger> whaa....
[13:35:27] <fuzzie> (CharAnimations::PulseRGBModifiers)
[13:36:07] <Avenger> yep, i meant exactly like these
[13:37:22] <Avenger> i moved the change fields outside so it can run a final time when the color mod is gone
[13:37:38] <CIA-29> GemRB: 03avenger_teambg * r15c79870a042 10gemrb/gemrb/core/CharAnimations.cpp: fix helmet color change
[13:37:46] <Avenger> so when the color mod is gone, the palette is set back to normal
[13:38:15] <Avenger> pst color pulse stuff was totally wrong for 0 clown color anims
[13:38:26] <Avenger> because their changeable palette was dropped
[13:38:48] <Avenger> i hope i didn't mess up something else
[13:39:07] <fuzzie> hmm, you set CasterID for everything now?
[13:39:14] <Avenger> what do you mean
[13:39:20] <Avenger> every fx
[13:39:26] <Avenger> every fx gets caster id
[13:39:31] <Avenger> they should
[13:39:39] <fuzzie> sure, they just didn't before :)
[13:39:46] <Avenger> yep, because we had no global id
[13:39:57] <Avenger> and lynx hacked only the absolutely necessary cases
[13:40:03] <fuzzie> oh, right
[13:40:59] <Avenger> maybe i still left out some effects that use the wrong id or object
[13:41:16] <Avenger> but theoretically every fx could be fixed now
[13:41:58] <-- |Cable| has left IRC (Read error: Connection reset by peer)
[13:43:29] --> |Cable| has joined #GemRb
[13:43:50] <lynxlynxlynx> you'd make the reviewing job much easier if you didn't commit everything at once
[13:44:12] <lynxlynxlynx> you still often get lots of unrelated changes into commits
[13:44:51] <lynxlynxlynx> try git add -p sometime
[13:46:36] <Avenger> ok
[13:47:00] <fuzzie> the maze stuff is an awful lot of code
[13:47:33] <Avenger> most of it is in the python script
[13:47:41] <Avenger> or in easy guiscript commands
[13:47:42] <fuzzie> + if (value & WALL_NORTH) {
[13:47:43] <fuzzie> + m2->walls|=WALL_SOUTH;
[13:47:51] <Avenger> that's right
[13:47:55] <Avenger> it changes the other side
[13:48:33] <fuzzie> ah, i guess you fixed this later
[13:48:47] <Avenger> i fixed it many times
[13:48:57] <Avenger> empirically :P
[13:49:22] <Avenger> they mixed up x and y, but i first implemented it in the logical way
[13:49:35] <Avenger> then i had to follow their swap
[13:50:11] <Avenger> ielister shows my current understanding
[13:52:28] <fuzzie> lynxlynxlynx: is it ok to change targets of features directly?
[13:53:14] <lynxlynxlynx> what do you mean?
[13:53:26] <lynxlynxlynx> effect targets?
[13:53:32] <fuzzie> the wild surge code does GetSpell() and then starts modifying it
[13:53:56] <fuzzie> like "seh->features[i].Target = caster->wildSurgeMods.target_type;"
[13:54:38] <fuzzie> but then you're modifying the shared copy of the spell
[13:54:56] <lynxlynxlynx> it seemed to work just fine
[13:55:11] <fuzzie> but does the same spell work as normal afterwards?
[13:55:30] <lynxlynxlynx> i'll have to check
[13:55:41] <lynxlynxlynx> plus if the ref change broke something there
[13:55:44] <fuzzie> it seems that you would permanently change the spell for everyone
[13:56:50] <Avenger> LOL
[13:57:21] <Avenger> that would be an awesome wm effect
[13:57:42] <fuzzie> yes :)
[13:58:10] <Avenger> where is this code?
[13:58:25] <fuzzie> Scriptable::CreateProjectile
[13:58:58] <fuzzie> i don't know if i'm reading it right, and we could easily just make it use a new copy of the spell, i expect
[13:59:31] <Avenger> why would it need a copy, why not modify the queue
[14:00:23] <fuzzie> it's too late
[14:00:35] <fuzzie> this stuff is checked when creating the queue
[14:01:00] <Avenger> where would it write back into spl?
[14:01:11] <Avenger> i see it changing only caster
[14:01:18] <fuzzie> seh = &spl->ext_headers[SpellHeader];
[14:01:28] <fuzzie> ^- anything which messes with seh
[14:01:54] <Avenger> ahh i see
[14:02:04] <fuzzie> or i guess there are also direct changes like the projectile type :)
[14:02:52] <Avenger> you can change the projectile's fxqueue, i think
[14:03:02] <fuzzie> it's too late then
[14:03:11] <Avenger> why?
[14:03:18] <fuzzie> when you call GetProjectile, you need to have updated the target
[14:03:24] <Avenger> oh because self won't go in the projectile
[14:03:24] <fuzzie> because TARGET_SELF is handled differently
[14:03:27] <fuzzie> yes :)
[14:03:46] <fuzzie> so it seems the simplest way is just to copy the spell
[14:03:53] <Avenger> meeh
[14:03:55] <fuzzie> or, rather, load a new copy
[14:04:02] <Avenger> i would rather see the original code
[14:04:05] <fuzzie> otherwise you end up adding hacks i think
[14:04:15] <fuzzie> but i am just reviewing code :)
[14:04:30] <Avenger> copying the spell for every wm effect seems weird
[14:04:43] <Avenger> it was a good spotting anyway
[14:07:47] <Avenger> the obvious change would be to move spl->GetProjectile from spell, and handle the effects one by one
[14:07:51] <fuzzie> lynxlynxlynx: also, ActorBlock.cpp lines 833, 864 ("if (!SpellResRef) {") are meant to check SpellResRef[0]?
[14:07:52] <Avenger> that's how the original does it
[14:08:40] <Avenger> yes fuzzie, SpellResRef is stored in the actor, so it is always nonzero
[14:08:57] <lynxlynxlynx> that's the ref change i was talking about
[14:09:13] <lynxlynxlynx> it was checking SpellRef before (optionally passed)
[14:09:15] <Avenger> you mean it was a pointer before?
[14:09:35] <fuzzie> sure, i see what you changed, i just thought i'd mention
[14:10:09] <fuzzie> sorry if you meant you already knew :)
[14:10:13] <lynxlynxlynx> so i need to check if wm still works from actions and any other users (multiple roll surge?)
[14:10:57] <lynxlynxlynx> and how to fix it without breaking the spell unmemorisation
[14:11:20] <Avenger> and don't modify the original spell
[14:11:53] <Avenger> spl->GetProjectile was my idea, it isn't done like that in the original, i just thought it was a good idea :)
[14:12:15] <Avenger> i just wanted to avoid context switching for every fx
[14:12:57] <lynxlynxlynx> just more hoops to jump through
[14:13:10] <lynxlynxlynx> nothing out of the ordinary :)
[14:13:12] <Avenger> though, if it gets every wm parameter, it can still work locally
[14:13:40] <fuzzie> i also am confused about the CanCast checks, are they avoided when needed? something to check later
[14:13:41] <Avenger> yeah, but the complexity is really high now
[14:15:25] <lynxlynxlynx> should they ever be avoided?
[14:15:28] <fuzzie> ok, i read back to before Christmas and the code is blurring now
[14:15:34] <fuzzie> lynxlynxlynx: things like silence, definitely
[14:15:44] <fuzzie> script-forced casts ignore all those checks
[14:16:42] <lynxlynxlynx> need more lore
[14:16:46] <fuzzie> i am not sure of the specifics, making me unhelpful as usual
[14:17:22] <lynxlynxlynx> iesdp comments suggest we should also be doing caster-level checks, but that's uncertain and blurry too
[14:17:34] <lynxlynxlynx> casterlevel
[14:18:39] <fuzzie> it's really annoying actually, you have NPCs which ignore memorisation and silence and everything
[14:19:18] <fuzzie> it makes sense for cutscenes but it's stupid elsewhere :)
[14:19:56] <CIA-29> GemRB: 03lynxlupodian * r95b541549ebe 10gemrb/gemrb/core/Scriptable/ActorBlock.cpp: Scriptable::CastSpellEnd: properly check for an empty SpellResRef
[14:19:58] <fuzzie> that's a lot of code though, lynx, and at a glance through all your new stuff looks pretty great
[14:20:12] <lynxlynxlynx> aww :)
[15:48:34] <Avenger> haha, git said i have conflicts. after a git stash/git pull/git stash apply git diff was empty
[15:49:36] <Avenger> a pity it doesn't notice the local mods are all the same
[15:52:11] <lynxlynxlynx> you sure it didn't just complain about a dirty working tree?
[15:57:35] <Avenger> yeah, it was dirty
[15:58:01] <Gekz> hey
[15:58:07] <Gekz> what's the level of touchscreen support right now?
[15:58:18] <Avenger> awesome
[15:58:24] <Gekz> oh?
[15:59:22] <Avenger> well, i touch my screen, and there will be fingerprints, but that's the intended effect here
[15:59:36] <Gekz> >_>
[15:59:47] <Gekz> I'm saying this because I saw a TOUCHSCREEN flag in the cmake output
[16:00:25] <Avenger> hmm, then we got something special for it
[16:00:38] <Gekz> so you don't know.
[16:01:21] <fuzzie> the touchscreen stuff adds zones at the screen edge, i think
[16:01:22] <Avenger> wider scrolling borders
[16:01:33] <Avenger> and some marked zones
[16:02:01] <Gekz> ah
[16:02:16] <Gekz> hopefully, I will get a multitouch device to play with
[16:02:22] <Gekz> and I will play with two-finger scrolling
[16:03:06] <Gekz> oh, and ANDROID support
[16:03:06] <Gekz> nice
[16:04:00] <Gekz> arbitrary resolutions still isnt supported though
[16:04:01] <Gekz> hmm
[16:04:07] <fuzzie> it's in the android market, i think
[16:04:25] <Gekz> I think the last time we discussed this it was agreed the lowest res possible is 640x480 right?
[16:05:06] <Gekz> in my mind, it should be possible to extend the resolution rahter "easily" by duplicating one texture over and over to the right.
[16:05:25] <fuzzie> sure
[16:05:33] <Gekz> is there any technical reason that wouldn't work?
[16:05:47] <fuzzie> i mean, that's all the widescreen mod does, right?
[16:06:03] <Gekz> afaik, yes
[16:06:18] <Gekz> is there any implementation reason that it would be hard, I should say
[16:06:20] <Gekz> :P
[16:06:24] <fuzzie> it's just that if you want it in gemrb core, you have to add code everywhere the UI coords are used..
[16:06:42] <Gekz> well, seeing as widescreen is supported by gemrb now
[16:06:54] <Gekz> it makes it a lower incentive to implement
[16:06:55] <Gekz> :P
[16:09:24] <Avenger> what we really need is to find bugs. it seems for every single commit now we introduce two new bugs
[16:11:14] <-- Avenger has left IRC (Quit: bye!)
[16:15:13] <Gekz> make -j5 is fun
[16:16:44] <Gekz> fuzzie: are there up-to-date Mac OS X build instructions?
[16:16:51] <Gekz> I ask because if there are not, I can update them
[16:18:28] <fuzzie> last time i tried it, it was trivial, but i cheated and used modern SDL
[16:18:35] <Gekz> BMac:~ brendan$ /opt/gemrb-git/bin/gemrb
[16:18:35] <Gekz> dyld: Library not loaded: libgemrb_core.dylib
[16:18:35] <Gekz> Referenced from: /opt/gemrb-git/bin/gemrb
[16:18:35] <Gekz> Reason: image not found
[16:18:35] <Gekz> Trace/BPT trap
[16:18:42] <Gekz> intriguing.
[16:18:51] <Gekz> I've had this issue a few times
[16:18:52] <fuzzie> that would be how *not* to build it :)
[16:19:03] <Gekz> no, if you install to a non-standard path
[16:19:08] <Gekz> it doesn't link the libraries correctly
[16:19:10] <Gekz> and I don't know why
[16:21:29] <Gekz> let's try using xcode
[16:22:41] <fuzzie> we don't seem to actually set INSTALL_RPATH for the gemrb binary, if i'm not blind
[16:22:50] <Gekz> yeah
[16:22:54] <Gekz> I think that might be it
[16:23:16] <fuzzie> well, i don't know if it uses that on OS X
[16:24:06] <fuzzie> there's this mess with install_name and DYLD_FALLBACK_LIBRARY_PATH and bla
[16:24:19] <fuzzie> if you just want to run the thing, the latter should do the trick
[16:34:52] <Gekz> fuzzie: sorry, what?
[16:35:05] <Gekz> add DYLD_FALLBACK_LIBRARY_PATH to cmakelists?
[16:35:45] <fuzzie> to your environment
[16:36:16] <Gekz> oh
[16:36:18] <Gekz> yeah
[16:36:21] <Gekz> just googled it
[16:36:23] <Gekz> and it says export it
[16:36:27] <fuzzie> mhm
[16:36:37] <Gekz> DIRTY HAX
[16:37:01] <fuzzie> it tells the darwin linker that you're being weird and putting libraries in strange places, and to look there when it's done checking the usual suspects
[16:37:18] <Gekz> yeah
[16:37:31] <Gekz> gonna modify the cmake to cater for that?
[16:38:02] <fuzzie> doesn't the cmake install in a sensible place by default?
[16:38:38] <fuzzie> i'm sure you can make cmake modify the install_name somehow
[16:38:56] <Gekz> it installs to /usr/local
[16:39:58] <fuzzie> which is in the default path
[16:40:06] <fuzzie> so that should Just Work?
[16:40:30] <Gekz> BMac:xb brendan$ ls /opt/gemrb-git/lib/gemrb/
[16:40:30] <Gekz> libgemrb_core.dylib plugins
[16:40:39] <Gekz> I installed it to /opt/gemrb-git
[16:40:41] <fuzzie> oh, that is not so good
[16:40:43] <Gekz> because I use /usr/local for other things
[16:40:57] <Gekz> is it meant to put the lib in a subdir of lib
[16:40:57] <Gekz> lol
[16:41:11] <fuzzie> well
[16:41:16] <fuzzie> i'm not quite sure what you did
[16:41:27] <fuzzie> you set PREFIX but didn't change LAYOUT to 'opt'?
[16:41:45] <Gekz> I left layout, yes
[16:42:06] <fuzzie> but then if it's in /lib/gemrb/ by default it won't work either
[16:42:33] <Gekz> well
[16:42:38] <Gekz> telling it where the library is directly worked
[16:42:39] <Gekz> haha
[16:42:59] <fuzzie> it would be worrying if it didn't work, no? :)
[16:43:17] <fuzzie> i guess it is broken by default, sihg
[16:43:42] <fuzzie> defaulting to opt layout on OS X would work, but i hate cmake and all it stands for
[16:43:50] <fuzzie> i still can't work out how to make it build in-tree
[16:44:04] <Gekz> I dont mind cmake
[16:44:13] <Gekz> and what do you mean build in-tree
[16:44:17] <Gekz> as in without a build directory?
[16:44:35] <fuzzie> as in, the .o files ending up in the same directory as the source
[16:45:19] <fuzzie> which is helpful for being able to run various tools without having to hack them to bits :/
[16:46:26] <Gekz> oh.
[16:46:39] <Gekz> couldnt you just make a bash script for that
[16:46:47] <Gekz> to put the .o's where they "belong"
[16:46:50] <fuzzie> yes
[16:47:12] <fuzzie> but it doesn't particularly help
[16:47:20] <Gekz> if it can even be considered a bug, the lack of icon of GemRB is notable :P
[16:47:29] <fuzzie> is there not an icon?
[16:47:35] <Gekz> nope
[16:47:46] <fuzzie> well, wait, you're running under OS X?
[16:47:51] <Gekz> yes
[16:48:08] <fuzzie> so you don't get an icon, i think
[16:48:15] <Gekz> is there evne a logo for gemrb
[16:48:16] <fuzzie> since you're running the app as a unix binary and not a bundle
[16:48:19] <fuzzie> sure, in artwork/
[16:48:22] <Gekz> I've never seen it
[16:48:41] <Gekz> not too shabby
[16:48:42] <fuzzie> you could even render a nice big 512x512 one
[16:48:45] <Gekz> yeah
[16:48:48] <Gekz> also
[16:48:53] <Gekz> you could turn gemrb into an app bundle
[16:48:57] <Gekz> although, I don't know how to do it
[16:49:00] <Gekz> I'm not a mac dev :<
[16:49:11] <Gekz> I know how to hack it into being an app bundle
[16:49:13] <Gekz> against its will
[16:49:26] <fuzzie> yes, indeed, you make a 'GemRB.app' folder and dump gemrb in 'Contents/MacOS' inside it
[16:49:55] <fuzzie> cmake has all kinds of helpful-looking things to produce bundles
[16:51:56] <Gekz> yeah
[16:51:59] <Gekz> but then it would be like
[16:52:25] <Gekz> gemrb could do with some user-friendly installation helpers for BG2 and the like
[16:54:39] * Gekz goes to sleep
[17:26:42] --> Avenger has joined #GemRb
[17:26:42] --- ChanServ gives channel operator status to Avenger
[17:27:38] <Avenger> phew, i finally found the cause of a nagging problem: why do i see only one anger/magic missile
[17:28:37] <Avenger> yeah, now i see them :) yippee
[17:29:17] <Avenger> i just should cut back on the sparkle amount and fix blending
[17:29:26] <fuzzie> what was the problem?
[17:29:38] <Avenger> you surely know :P
[17:30:00] <Avenger> hardcoding was the problem :P
[17:30:34] <Avenger> drawing missiles on top on each other without a curved path
[17:30:38] <fuzzie> ah
[17:30:51] <fuzzie> right, i guess there's a comment from me about that?
[17:30:53] <Avenger> well, now i got them nice
[17:31:32] <Avenger> it is not interesting which one has the curved path, as long as there is a 0, and then an 1, then 2, etc
[17:32:06] <Avenger> they are identical from the outside, except for the curve
[17:32:25] <fuzzie> yes, this is why i used 'type - 68'
[17:32:28] <Avenger> so i added a bend variable, instead of the id and increase it in each iteration
[17:32:33] <fuzzie> sounds good
[17:32:58] <fuzzie> i mean, it doesn't sound good, i hate that code
[17:33:03] <Avenger> :)
[17:33:15] <Avenger> it now seems relatively good
[17:33:15] <fuzzie> it doesn't work anything like the original for the paths
[17:33:28] <fuzzie> they all hit at the same time, for example
[17:33:55] <Avenger> what about a flag that modifies speed a bit
[17:34:01] <fuzzie> but i couldn't work out what the original is doing at all
[17:34:14] <fuzzie> it makes the missiles *stop* before hitting the target, or something like that
[17:34:27] <Avenger> speed = speed + (rand()%3)-1;
[17:34:29] <fuzzie> you only get the nice curve for about 3/4
[17:34:43] <Avenger> oh
[17:34:44] <fuzzie> (and that nice curve is just like ours)
[17:36:29] <Avenger> i will need the random speed anyway, i found code for it in pst.
[17:36:33] <fuzzie> http://fuzzie.org/magicmissiles.jpg
[17:36:51] <Avenger> this seems to be like ours
[17:36:54] <fuzzie> yep
[17:36:56] <Avenger> all of them are lined up
[17:37:05] <Avenger> and their blend is not exactly right
[17:37:15] <fuzzie> oh, the blend is probably DirectX sucking
[17:37:23] <fuzzie> nightmare
[17:37:50] <Avenger> there is no alpha channel?
[17:37:53] <fuzzie> but if you single-step the game, you see some missiles actually *stop* after half way, delaying for a while
[17:38:02] <Avenger> just alpha bit, it seems
[17:38:25] <Avenger> which game? the original?
[17:38:29] <fuzzie> and this is what causes the nice staged hit effect
[17:38:30] <fuzzie> yes
[17:39:36] <Avenger> well, i commit the bend thingie
[17:39:37] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
[17:42:42] --> barra_away has joined #GemRb
[17:45:52] <-- barra_home has left IRC (Ping timeout: 240 seconds)
[17:46:26] <CIA-29> GemRB: 03avenger_teambg * r82aa3b2a6674 10gemrb/gemrb/core/ (Projectile.cpp Projectile.h Video.cpp): increase bend with each curved path missile
[17:55:03] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[18:00:49] <CIA-29> GemRB: 03avenger_teambg * reb4dd9e2167d 10gemrb/gemrb/core/Map.cpp: cut back on spark amount for projectiles
[18:12:57] --> edheldil_ has joined #GemRb
[18:23:04] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[18:27:08] <lynxlynxlynx> mm looks almost perfect now
[18:27:30] <lynxlynxlynx> it's still too fast, but i guess that can be changed in the projectile itself
[18:27:51] <lynxlynxlynx> it definitely worked like that for the halve projectile speed mod wm
[18:36:08] <CIA-29> GemRB: 03avenger_teambg * r3e5614fdefa3 10gemrb/gemrb/core/ (Map.cpp Map.h Projectile.cpp Projectile.h): sparks now have a better ZPosition (height) and projectiles don't initiate them needlessly
[18:36:25] <lynxlynxlynx> interesting
[18:36:39] --> Avenger has joined #GemRb
[18:36:39] --- ChanServ gives channel operator status to Avenger
[18:36:45] <Avenger> ok, projectile sparks are much better now
[18:36:48] <lynxlynxlynx> if i slow it down, the missile in the direct line isn't affected
[18:37:04] <lynxlynxlynx> the others are, so it looks pretty cool
[18:37:07] <fuzzie> slow down the curved ones?
[18:37:15] <fuzzie> Avenger sabotaged my loop by adding a 'bend' check to it, if so
[18:37:35] <Avenger> because each projectile is a separate entity
[18:37:36] <lynxlynxlynx> i slowed down spmagmis - i thought all are from this projectile
[18:37:48] <fuzzie> yes, that should work
[18:38:30] <Avenger> it is weird you managed to modify all but one
[18:38:44] <Avenger> that means, you write back into the master copy
[18:38:56] <Avenger> which is a no-no :P
[18:39:22] <lynxlynxlynx> huh
[18:39:41] <lynxlynxlynx> it's clearly originally a data bug, since this is our override
[18:40:08] <Avenger> what is?
[18:40:25] <fuzzie> i think all our projectiles are just too fast, really
[18:40:28] <lynxlynxlynx> spmagmis.pro
[18:40:49] <Avenger> we need it,
[18:40:58] <lynxlynxlynx> anyway, i didn't try it before your bend change, so the difference could also be from there
[18:41:16] <Avenger> the speed shouldn't be bend specific
[18:41:25] <fuzzie> the bend stuff really shouldn't make a difference to speed
[18:42:13] <fuzzie> (it only modifies where the projectiles are drawn)
[18:42:29] <Avenger> MAGICMIS and SPMAGMIS are the pro files that contain speed data
[18:42:42] <Avenger> MAGICMIS is the first, SPMAGMIS are the clones
[18:42:46] <lynxlynxlynx> ah, so there are two
[18:42:49] <Avenger> yes
[18:42:53] <fuzzie> ah
[18:43:10] <Avenger> SPMAGMIS clones a projectile with one less projectile ID
[18:43:16] <Avenger> MAGICMIS doesn't
[18:43:30] <fuzzie> that's confusing
[18:43:33] <Avenger> also SPMAGMIS has curved path bit set, which now makes the lower ID projectile one more bent
[18:43:49] <Avenger> believe me, this is almost like how they did it in the original :)
[18:44:01] <lynxlynxlynx> ok, so i'll just modify magicmis too
[18:44:16] <Avenger> gemproj.ids imitates their internal jumptables
[18:45:24] <Avenger> so what did you do lynx? try to slow it down to the speed of the original?
[18:45:44] <lynxlynxlynx> yeah
[18:45:47] <Avenger> problem is, you shouldn't touch it, you should rather calibrate the speed on a .pro file from the original engine
[18:46:04] <Avenger> once that's correct, we can try to change ours
[18:46:33] <lynxlynxlynx> ok
[18:46:36] <Avenger> i try to fill our pro file fields with data from the engine
[18:46:50] <Avenger> which means, they will behave the same as tob .pro files
[18:47:00] <lynxlynxlynx> btw, it looks better like this, i'll keep it in my local copy
[18:47:25] <Avenger> if you have other than speed changes tell me, though
[18:47:39] <fuzzie> Projectile.cpp:749 is where you'd adjust the speed, i guess
[18:47:43] <lynxlynxlynx> i'm not sure, i found another problem
[18:47:54] <lynxlynxlynx> my monk with 60% didn't resist any magic missile
[18:48:12] <lynxlynxlynx> that's at least 6x2 chances in 6 casts
[18:48:22] <Avenger> that is effect problem
[18:49:04] <lynxlynxlynx> well sure
[18:49:10] <fuzzie> you never fought a dragon and managed to shove a whole bunch of magic missiles past their protection? :)
[18:50:14] <lynxlynxlynx> not without lower resistance
[18:51:17] <lynxlynxlynx> another thing to put on my list
[18:56:14] <Avenger> lol, i never seen this in the original
[18:56:33] <Avenger> in bg2, trademeet, there are some philosophers
[18:56:43] <Avenger> attacking each other
[19:10:16] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[19:25:56] <lynxlynxlynx> you didn't :s
[20:26:37] --> edheldil_ has joined #GemRb
[20:33:52] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[20:39:27] --> edheldil_ has joined #GemRb
[21:05:10] <-- Avenger has left IRC (Quit: bye!)
[21:06:26] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:21:53] <-- Demitar has left IRC (Quit: Ex-Chat)
[22:45:03] --> Demitar has joined #GemRb