#gemrb@irc.freenode.net logs for 26 Jan 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:11:53] --- barra_away is now known as barra_home
[00:15:42] --- barra_home is now known as barra_library
[01:17:09] --> |Cable| has joined #GemRb
[01:59:40] <-- |Cable| has left IRC (Quit: Leaving)
[02:00:01] --> |Cable| has joined #GemRb
[02:19:32] <-- |Cable| has left IRC (Quit: Leaving)
[02:19:46] --> |Cable| has joined #GemRb
[03:00:10] <-- barra_library has left IRC (Quit: Verlassend)
[03:27:32] --> Textmode has joined #GemRb
[04:58:51] --> jschall has joined #GemRb
[05:37:17] <-- jschall has left IRC (Remote host closed the connection)
[07:37:57] --> lynxlynxlynx has joined #GemRb
[07:37:57] --- ChanServ gives channel operator status to lynxlynxlynx
[07:46:26] --> Bo_Thomsen has joined #GemRb
[08:23:47] --> lubos has joined #GemRb
[08:34:57] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[09:31:12] <-- |Cable| has left IRC (Remote host closed the connection)
[10:16:34] <edheldil> fuzzie: do you suffer burn out or is it just too much RL problem?
[10:18:18] <fuzzie> I think I had this discussion before -- RL got very busy, and then recently I spent my coding time adding a Living Books engine to scummvm.
[10:18:54] <fuzzie> And every time I sit down at the GemRB code I want to fix the instants stuff, which always ends up being really difficult..
[10:19:39] <edheldil> ah
[10:27:53] <fuzzie> i should remember to bother Avenger about ReturnToSavedPlace()
[10:32:18] <fuzzie> He has it documented in a forum thread as going back to SavedPlace, as usual, but a few seconds of actually trying it in the game shows that it's weirder than that.
[10:32:35] <fuzzie> (And almost none of the scripts in PS:T bother actually saving a place.)
[10:36:13] <Textmode> :/
[10:37:41] <edheldil> so it's not clear where it really returns?
[10:37:59] <fuzzie> I'm pretty sure it returns the internal 'saved location' field.
[10:38:11] <fuzzie> Which is not updated by actions like random walk, etc.
[10:38:30] <fuzzie> So it lets them have areas like the Sensates where everyone walks around at random, but always eventually ends up where they should be.
[10:39:17] <fuzzie> But then we don't even *try* to support PS:T anims right now, of course..
[10:39:33] <fuzzie> We just have this avatars.2da hack which should only be there for 2 anims.
[10:39:53] <fuzzie> So this is also why I am a bit demotivated. :P
[10:49:13] <edheldil> I admit I do not orient myself in this anymore, do you care to explain? Why should ps:t have avatars.2da only for 2 anims? it maps animation number to various bams, no? Where else GemRB should get this info?
[10:51:55] <fuzzie> There's an anims ini file.
[10:52:11] <fuzzie> Which maps animation id and stance to a bam file.
[10:53:01] <fuzzie> You can't predict it by hardcoding the filenames because they're sometimes oddly named, and because mods change them.
[10:53:31] <fuzzie> I wrote some code for this, but it is complicated to do in GemRB's current CharAnimations system..
[10:55:42] <fuzzie> But there doesn't seem to be much point hard-coding all the PS:T anims needed for things like the Sensates, if they need to be read from the ini file in the long-term. :)
[10:58:18] <edheldil> where's that anims.ini? It's not in gemrb's override nor in ps:t data. I have anims.2da only
[10:58:59] <fuzzie> I think it's called resdata.ini in pst?
[10:59:04] <fuzzie> In pst's data.
[11:00:02] <fuzzie> We already parse it in trunk for the non-anim data.
[11:01:44] <edheldil> ah, ok ... so it would perhaps make sense to add resdata.ini for bg2 as well? Or is there something else for this?
[11:02:50] <fuzzie> It's all hardcoded in the other games, so we need the avatars.2da there.
[11:03:11] <edheldil> but why not resdata.ini instead?
[11:03:39] <fuzzie> I think because you need code to construct the different BAM names.
[11:03:49] <fuzzie> For different armour, weapons, etc.
[11:04:25] <fuzzie> PS:T doesn't have any of that - the resdata.ini just has different anim ids for TNO with different equipped weapons.
[11:04:39] <fuzzie> iwd/iwd2 has sounds.ini with just the sound information in it, I forget if we handle thatyet.
[11:07:42] <edheldil> eh?? TNO's weapons are anims.2da. resdata.ini has abishai as a first stanza
[11:07:59] <fuzzie> yes
[11:08:04] <fuzzie> *all* anims are in resdata.ini
[11:08:28] <fuzzie> see 47 (TNO with Axe), 48 (TNO with Club), 49 (TNO with Dagger), 50 (TNO with Fist), etc..
[11:09:25] --> SiENcE has joined #GemRb
[11:09:36] <edheldil> it has no circle size, though
[11:09:51] <fuzzie> I think PS:T circles are bitmaps?
[11:10:09] <edheldil> yes
[11:10:23] <edheldil> but you have to take the size somewhere
[11:10:33] <fuzzie> so, fixed size, no?
[11:11:09] <fuzzie> I forget.
[11:11:23] <fuzzie> But yes, I ended up leaving the circles in avatars.2da in my patch. I don't know if that's correct.
[11:12:30] <edheldil> they are scaled somehow for different avatars - e.g. rats
[11:12:45] <fuzzie> GroundCircleBAM1 = WMPICKL/3
[11:12:45] <fuzzie> GroundCircleBAM2 = WMPICKR
[11:12:45] <fuzzie> GroundCircleBAM3 = WMPICKL
[11:12:52] <fuzzie> ^- this is pst's gemrb.ini
[11:13:01] <fuzzie> so, i guess you must be right
[11:13:16] <fuzzie> No idea how that works.
[11:13:32] <edheldil> Avenger will find out :)
[11:13:38] <edheldil> sooner or later
[11:13:53] <fuzzie> I think last time we discussed this, Avenger was mostly hoping the problem would disappear. :P
[11:14:00] <edheldil> hehe
[11:14:20] <fuzzie> But yes, this is why I am thinking about this, if he's posting PS:T discoveries on the forum, then I guess he is looking at the PS:T code.
[11:14:50] <edheldil> later, fuzzie, I have a lunch. Thank you for explaining.
[11:15:07] <fuzzie> Yes, I guess I'd better go do work things too.
[11:16:29] <edheldil> so perhaps it would make sense to adapt resdata.ini to other games and keep avatars.2da for things like ground circle size only ... before we find out how they are processed
[11:16:33] <edheldil> see you
[11:17:11] <fuzzie> It would be really nice to find a general solution for anims which doesn't make us all crazy. :)
[11:20:33] <fuzzie> lynxlynxlynx: btw, my commit last night was ok?
[12:07:09] <-- SiENcE has left IRC (Quit: @all: cya)
[13:17:49] <lynxlynxlynx> sure
[13:17:58] <lynxlynxlynx> & woho, my new laptop is here
[13:18:15] <lynxlynxlynx> one of those from dy
[13:40:52] --> barra_home has joined #GemRb
[13:46:36] --- barra_home is now known as barra_library
[13:47:04] <lynxlynxlynx> http://ebm.si/dy.jpg ;)
[13:47:53] --- barra_library is now known as barra_home
[13:50:22] <edheldil> congtatulations ;-)
[15:14:17] <fuzzie> hehe
[16:43:01] --> Maighstir has joined #GemRb
[17:23:30] --> Bo_Thomsen has joined #GemRb
[18:16:33] --> Avenger has joined #GemRb
[18:16:33] --- ChanServ gives channel operator status to Avenger
[18:16:36] <Avenger> hi
[18:16:51] <fuzzie> Avenger: you're REing PS:T right now?
[18:17:03] <Avenger> yes
[18:17:22] <Avenger> anything you want to know?
[18:17:41] <fuzzie> yes
[18:17:49] <fuzzie> which field does ReturnToSavedPlace use?
[18:19:33] <fuzzie> I saw you mentioned it.
[18:19:36] <Avenger> it is a good question
[18:19:46] <Avenger> apparently i found those fields only in iwd
[18:19:50] <fuzzie> the PS:T scripts don't save places
[18:20:00] <Avenger> ?
[18:20:03] <fuzzie> they just call ReturnToSavedPlace.
[18:20:07] <Avenger> no
[18:20:12] <fuzzie> yes :P
[18:20:29] <Avenger> you say 207 SavePlace() is never called?
[18:20:31] <fuzzie> so, i was wondering (a year ago) if it used the internal CRE saved location field.
[18:20:34] <fuzzie> oh, maybe it's called
[18:20:40] <fuzzie> but it's not called in 90% of the scripts using ReturnToSavedPlace
[18:21:03] <fuzzie> i had a little go at debugging it, but mostly actors only move a few pixels if i call it in the original engine
[18:21:17] <fuzzie> i think back to the nearest search square or something
[18:21:22] <fuzzie> so i have been curious about it ever since
[18:21:42] <Avenger> if x or y is 0, theaction doesn't work
[18:22:07] <fuzzie> yes
[18:22:14] <fuzzie> so, is it completely useless for almost all the uses? :)
[18:22:24] <fuzzie> or, is something else putting values there, or are they in a CRE field, or something.
[18:22:41] <Avenger> 0700anam uses it
[18:22:58] <fuzzie> SavePlace is called 12 times
[18:23:10] <fuzzie> ReturnToSavedPlace is called 582 times
[18:23:18] <fuzzie> all by different scripts
[18:23:22] <fuzzie> so you see, why i would like to know :)
[18:23:41] <Avenger> i found 15 instances
[18:24:28] <fuzzie> Hm, I only find 12. This is the original game, though, not fixpacked.
[18:28:54] <fuzzie> (For those watching: Yes, the fixpack adds some calls.)
[18:32:13] <Avenger> these fields are not saved in pst
[18:33:12] <fuzzie> So, *flail*. :/
[18:33:50] <Avenger> the trigger NearSavedLocation uses it, actions: setsavedlocation, saveplace, returntosavedplace
[18:34:18] <Avenger> well, stuff that saves in in OnCreation works
[18:34:49] <fuzzie> 326 calls to NearSavedLocation..
[18:35:19] <Avenger> it also checks if any of the fields are 0
[18:35:24] <fuzzie> i guess RunToSavedLocation uses it?
[18:35:33] <fuzzie> no calls to SetSavedLocation at all, that i can see
[18:35:39] <Avenger> yes, but that is only an alias in this code
[18:35:42] <Avenger> same function
[18:35:53] <fuzzie> it's just weird
[18:36:01] <Avenger> well, setsavedlocation can be used for testing
[18:36:03] <fuzzie> almost all the scripts call RandomWalk()
[18:37:19] <fuzzie> maybe it's just standard code which they added onto the end of every script for the actors who just sit around
[18:37:31] <fuzzie> oh well. thanks for looking!
[18:37:54] <Avenger> no problem, it was an easy question :)
[18:38:35] <Avenger> now i create a trigger listing for pst, that is the last action/trigger list i still miss
[18:50:03] --> |Cable| has joined #GemRb
[19:13:19] <Avenger> haha, pst's trigger 0x4063 is doing the same as 4058. both just check if you currently got an item equipped
[19:14:32] <Avenger> but the unselectable variable triggers should work correctly, despite they are unlisted in the original
[19:15:00] <Avenger> ah my bad, i didn't see the rest of the code
[19:15:14] <Avenger> ok, inweaponrange should be fine too
[19:16:44] <Avenger> hmm inview seems to be an interesting trigger
[19:20:55] <Avenger> ahh it isn't used
[19:21:14] <Avenger> well, it is similar to see, but less checks
[19:26:52] <Avenger> fuzzie, iirc, actionlistempty in bg2 would report true if the current action is wait?
[19:27:41] <fuzzie> yes
[19:28:42] <Avenger> well, i don't think pst has this. But i couldn't recognise it in the bg2 listing either
[19:30:26] <Avenger> ok, i see it in objectactionlistempty of bg2
[19:31:10] <Avenger> not in actionlistempty, though
[19:31:49] <fuzzie> Well, I only know what you told me, I think. :)
[19:32:13] <Avenger> well, just remember this, if you got some obscure bug :)
[19:32:19] <Avenger> probably it won't cause anything
[19:44:33] <Avenger> weird, those floater messages are lined to areas, not actors, that's weird
[19:45:36] <Avenger> looks like there is a list in areas, that contains the global id of the owner
[19:45:45] <Avenger> plus the message, of course
[19:46:06] <Avenger> i would have linked the messages to the scriptables themselves
[19:46:17] <-- CIA-31 has left IRC (Ping timeout: 255 seconds)
[19:46:53] <-- CIA-76 has left IRC (Ping timeout: 264 seconds)
[19:46:58] <Avenger> haha, the ugly trigger: AssaltedBy, is not used, i'm relieved :)
[19:48:57] <fuzzie> the areas need to keep track of the floater messages so they can do the bounding-box stuff
[19:49:03] <fuzzie> but yes, i would also have kept them in the scriptables
[19:52:05] <Avenger> haha, another weirdness, there is PartyCountEQ/GT/LT which is doing exactly the same as NumInParty/GT/LT
[19:52:20] <Avenger> they reimplemented the stuff, lol
[19:53:12] <fuzzie> Remember, the world before bg1. :P
[19:54:33] <Avenger> WatchMe is dead too
[19:54:45] <Avenger> well, NumInParty is in this code too
[19:55:01] <Avenger> you could simply copy the lines from another game's trigger.ids
[19:55:35] <Avenger> its good that most of the stuff i didn't figure out is actually dead code
[20:01:24] <Avenger> stuffglobalrandom is buggy in our implementation. This trigger always returns true
[20:01:47] --> CIA-29 has joined #GemRb
[20:01:51] <Avenger> it isn't used, though
[20:04:59] <lynxlynxlynx> heh
[20:05:08] <lynxlynxlynx> how would you document that anyway
[20:05:23] <lynxlynxlynx> sounds like some wild magic effect
[20:12:32] <Avenger> inview, if used from non living, is always true, heh
[20:13:08] <Avenger> luckily it isn't used
[20:15:11] <Avenger> our implementation of vacant is surely buggy
[20:15:31] <Avenger> well, maybe not
[20:15:43] <Avenger> fuzzie, do you have vacant() used in 0700anam ?
[20:18:12] --> jschall has joined #GemRb
[20:24:43] <Avenger> hah, a direct proof of VisionRange stored in areas, in pst.
[20:25:22] <Avenger> so, i guess, it is as you suspected, this is per area in the blackisle branch
[20:29:29] <-- jschall has left IRC (Ping timeout: 264 seconds)
[20:42:47] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
[21:13:12] <CIA-29> GemRB: 03avenger_teambg * r63a419bd6b43 10gemrb/gemrb/GUIScripts/pst/GUISTORE.py: added sound support for pst temples
[21:14:04] <CIA-29> GemRB: 03avenger_teambg * rdae09ccd9cb1 10gemrb/gemrb/GUIScripts/pst/GUISTORE.py: removed debug prints
[21:19:27] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[21:20:05] <-- lynxlynxlynx has left IRC (Ping timeout: 240 seconds)
[21:22:07] --> Bo_Thomsen has joined #GemRb
[21:25:54] --> lynxlynxlynx has joined #GemRb
[21:25:54] --- ChanServ gives channel operator status to lynxlynxlynx
[23:17:50] <-- lynxlynxlynx has left IRC (Ping timeout: 276 seconds)
[23:33:46] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[23:55:11] --> barra_away has joined #GemRb
[23:58:15] <-- barra_home has left IRC (Ping timeout: 240 seconds)