#gemrb@irc.freenode.net logs for 23 Mar 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:54:31] <edheldil_> no windoze here
[01:25:39] <-- edheldil_ has left IRC (Read error: Operation timed out)
[01:54:07] --> raevol has joined #GemRb
[02:31:07] --> PixelScum has joined #GemRb
[02:34:20] <-- Drakkar has left IRC (Ping timeout: 252 seconds)
[06:15:17] --> BaldimerBrandybo has joined #GemRb
[06:18:17] <-- PixelScum has left IRC (Ping timeout: 252 seconds)
[06:40:08] --> Bo_Thomsen has joined #GemRb
[06:42:02] <-- raevol has left IRC (Quit: Leaving.)
[08:01:33] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[08:13:39] --> lynxlynxlynx has joined #GemRb
[08:13:39] <-- lynxlynxlynx has left IRC (Changing host)
[08:13:39] --> lynxlynxlynx has joined #GemRb
[08:13:39] --- ChanServ gives channel operator status to lynxlynxlynx
[08:18:21] --> adominguez has joined #GemRb
[08:43:30] <edheldil> good spring morning!
[08:44:22] <fuzzie> it's foggy.
[09:06:59] --> lubos has joined #GemRb
[09:20:22] <edheldil> not here :)
[09:29:00] <edheldil> what was the outcome of your discussion on Object non-proliferation, fuzzie?
[09:30:24] <fuzzie> I'm still not really sure.
[09:30:30] <fuzzie> It's a bit annoying that they stick around so long. :)
[09:33:25] <fuzzie> lynxlynxlynx: your issue with that Immobile() stuff was knocking unconscious via fists?
[09:36:09] <fuzzie> it looks like that is just handled as a consequence of the STATE_SLEEP, should be 5 minutes to fix
[09:36:53] <edheldil> since they need to be kept around and it would be better if core did not know about them, would some opaque object solve it, or would it be just useless obfuscation?
[09:37:22] <fuzzie> i think core has to know about them
[09:37:33] <fuzzie> i'm not sure
[09:38:07] <fuzzie> the reason i'm looking at lynx's thing is because i remembered there's a hard-coded check in this sleep stuff: you can only target STATE_SLEEP actor with SLOT_FIST if you are CLASS_MONK
[09:39:03] <fuzzie> and there are hacks like that which check object stuff (e.g. EA) all over the place
[09:39:30] <fuzzie> it's just a question of whether we put it in Object, or whether we just fetch the source via id and check it directly :/
[09:41:20] <fuzzie> i think it depends on whether any scripts care about matching long-term objects after the sources are deleted. should become obvious from testing.
[09:42:48] <fuzzie> but i am hoping to just rush through and implement this in the obvious way, then try and make it work for pst. :P
[09:43:09] <fuzzie> hopefully it should be possible to bother people to actually test for Planescape: Torment, it seems a popular enough demand
[09:44:22] <edheldil> I will
[09:46:06] <edheldil> these days I am fighting with the nebulous specification of IEScript
[09:46:46] <fuzzie> ugh
[09:46:56] <fuzzie> why? :)
[09:47:39] <edheldil> because I am trying to write a compiler for it
[09:47:46] <fuzzie> that is a huge pain to do
[09:48:06] <fuzzie> not even Avenger bothered :)
[09:48:22] <edheldil> and I want to create a formal grammar for it, which I was unable to find :)
[09:48:36] <edheldil> I know, dltcep just calls weidu
[09:48:55] <fuzzie> well, you can click the 'use internal compiler' checkbox and it will corrupt your bcs files for you :)
[09:49:12] <edheldil> and if it's not installed, fails with unhelpful error message
[09:49:27] <fuzzie> did you see the weidu source?
[09:49:48] <edheldil> I haven't tried,
[09:50:23] <edheldil> because of ocaml and I do not strive to have all quirks implemented at first
[09:50:23] <fuzzie> it has lexer+parser
[09:50:46] <edheldil> ah, maybe I should look if the grammar is discernable from it
[09:50:50] <fuzzie> ok, it is ocaml, but it is in 'traditional' form, so you can mostly work out the grammar
[09:51:12] <fuzzie> if you are familiar with lex/yacc syntax
[09:51:14] <edheldil> I looked at NI, and it looked like too much special cases
[09:51:53] <edheldil> thanks for the tip, that might be useful after all
[09:51:56] <fuzzie> well, it does not help that some of it is game-specific
[09:52:18] <fuzzie> and that not all of it is very well documented, for example the shape (circle/rectangle) bounds
[09:53:03] <edheldil> my source was primarily IESDP and that is for some reason a horrible source :(
[09:53:53] <fuzzie> iesdp doesn't seem to mention the bounds at all
[09:54:30] <edheldil> yes... and has cryptic references to parts it mentions at all :)
[09:54:55] <edheldil> what is the distinction between BS and BAF?
[09:55:50] <fuzzie> but weidu handles them correctly, things like Exists([][859.1789.982.2020]) fand NearLocation([PC][968.981.400.-1],[968.981],15)
[09:56:31] <fuzzie> at some point weidu didn't decompile them and everyone was rather confused when important bits of pst stopped working :)
[09:56:59] <fuzzie> and BS is just BCS except in scripting dir, right?
[09:57:08] <fuzzie> i need to look at exactly what the original engine does
[09:57:21] <edheldil> ah, so it is compiled as well?
[09:57:33] <fuzzie> yep
[09:58:04] <edheldil> but there are uncompiled scripts e.g. in dialogs, so gemrb has to have an ionterpreter as well, has not it?
[09:58:10] <fuzzie> yes
[09:58:26] <fuzzie> very annoying
[09:59:37] <fuzzie> because the dialogs are full of mistakes
[09:59:59] <edheldil> is this quote appropriate? : Vincent: It's the little differences. I mean, they got the same shit over there that we got here, but it's just – it's just there it's a little different
[10:00:29] <fuzzie> original engine does it very naively
[10:00:38] <edheldil> yes?
[10:01:23] <fuzzie> CGameDialogReply::Pick makes CAIScriptFile then calls CAIScriptFile::ParseResponseString(CString), which splits into lines and does ParseOneLine
[10:01:56] <fuzzie> then for each line it just handles it manually, just like our code, parsing each part as encountered
[10:03:05] <fuzzie> (based on action.ids file if you didn't work that out yet)
[10:03:25] <edheldil> or trigger.ids
[10:03:30] <fuzzie> yes
[10:04:06] <fuzzie> while the game bcs files don't necessarily nicely decompile to something which can be presented like that
[10:04:57] <-- |Cable| has left IRC (Remote host closed the connection)
[10:04:59] <edheldil> really??? Do you have examples?
[10:05:20] <fuzzie> not off the top of my head
[10:05:42] <fuzzie> but that shouldn't surprise you, that is why NI and weidu are full of special cases :-P
[10:06:34] <edheldil> because while I was testing the decompiler, those things which did not decompile looked more like errors
[10:06:53] <fuzzie> the most obvious thing is that there's stuff just plain missing from the .ids files
[10:06:57] <edheldil> NI has problems decompiling many PST scripts
[10:07:04] <fuzzie> and also that there are RES variants of actions which take different parameters, of course
[10:07:12] <fuzzie> weidu decompiles+recompiles all PST scripts i think.
[10:07:31] <edheldil> RES variants?
[10:07:43] <fuzzie> actions which take resrefs
[10:07:57] <edheldil> I know that there are some actions which differ only in signature
[10:07:58] <fuzzie> ForceSpellRES for example
[10:08:25] <fuzzie> that is ForceSpell (113), but it takes a S:RESREF rather than a I:Spell
[10:09:00] --> edheldil_ has joined #GemRb
[10:09:07] <fuzzie> for example ReallyForceSpellRES("insanity",NearestEnemyOf(Myself))
[10:09:39] <fuzzie> i should ask: you know there is an official script compiler, yes?
[10:11:39] <edheldil> there's no reallyforcespellres in my pst
[10:11:53] <edheldil> no :)
[10:11:57] <fuzzie> ok
[10:12:08] <fuzzie> well, there is an official Bioware script compiler which is on bg1/bg2 CDs :-)
[10:12:21] <fuzzie> it has a quick-reference .doc file also
[10:13:14] <fuzzie> and yes, it seems it is not used in pst
[10:13:15] <edheldil> really. Thank you for the tip
[10:13:52] <fuzzie> in fact i see it only used in bg2
[10:14:11] <edheldil> and it has the same id as forcespell?
[10:14:15] <fuzzie> yep
[10:14:24] <fuzzie> so you have to 'know' when decompiling
[10:14:31] <edheldil> eeek. Now THAT is ugly :/
[10:15:43] <fuzzie> mhm
[10:16:15] <fuzzie> it is because their compiler can't override with same name
[10:16:21] <fuzzie> and they never decompile :)
[10:16:36] <edheldil> one would think they had to pay for each action id :/
[10:16:58] <fuzzie> well, the code in original is identical apart from a quick check to see if it has a string param or not
[10:17:43] <fuzzie> their scripting doc is really bad :-P
[10:18:15] <edheldil> identical to what? Both variants are handled by the same code, no?
[10:18:33] <fuzzie> yes, i man, that is probably why they did it
[10:18:46] <fuzzie> so they didn't have to change the action dispatching code for any of this
[10:19:00] <fuzzie> i mean you know it is just huge switch table in original, by id? :)
[10:19:08] <fuzzie> no nice gemrb-style stuff
[10:20:59] <edheldil> eh
[10:21:14] <edheldil> somewhere deep it probably tortures kittens as well
[10:21:37] <fuzzie> not unlikely
[11:32:58] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[12:13:58] --> lynxlynxlynx has joined #GemRb
[12:14:07] <-- lynxlynxlynx has left IRC (Changing host)
[12:14:07] --> lynxlynxlynx has joined #GemRb
[12:14:07] --- ChanServ gives channel operator status to lynxlynxlynx
[13:28:38] --> SiENcE has joined #GemRb
[13:30:56] <-- lynxlynxlynx has left IRC (Ping timeout: 250 seconds)
[14:33:55] --> pupnik has joined #GemRb
[14:33:56] <-- pupnik has left IRC (Changing host)
[14:33:56] --> pupnik has joined #GemRb
[14:36:43] <-- pupnik_ has left IRC (Ping timeout: 248 seconds)
[15:14:30] <fuzzie> ugh
[15:14:50] <fuzzie> GetAttackFrameType calls into GetPixelValue for the real work
[15:15:09] <fuzzie> did i miss some horrible hack where this is controlled by pixel values?
[15:15:32] <wjp> does GetPixelValue do what it sounds like?
[15:17:13] <fuzzie> yes, yes it does
[15:17:32] <fuzzie> and the anim constructor does, in fact, load bitmaps into the array it uses
[15:20:09] <fuzzie> wheeee
[15:20:24] <fuzzie> rndbase[1..5].bmp, apparently
[15:20:43] <fuzzie> ah yes, this is documented when i google it
[15:21:07] <fuzzie> by Taimon as usual
[15:21:31] <wjp> ah, yes
[15:21:32] <wjp> funky
[15:22:43] <fuzzie> well that is really annoying :)
[15:23:22] <wjp> quite
[15:23:36] <fuzzie> but they seem to be in all the games and we can do GetBitmap() easily enough on the BMPImporter
[15:23:57] <wjp> why use your custom table format if you can put data in bitmaps, I guess
[15:24:02] <fuzzie> yay, bitmaps!
[15:24:21] <fuzzie> this stuff is so very absurdly complex
[15:24:39] <wjp> what are the dimensions of those bitmaps, by the way?
[15:24:56] <fuzzie> $ identify rndbase1.bmp
[15:24:56] <fuzzie> rndbase1.bmp BMP 102x11 102x11+0+0 PseudoClass 16c 8-bit 690b
[15:26:34] <wjp> comparing with Taimon's post, the 11 corresponds to initiative?
[15:27:00] <wjp> and the 102 with time?
[15:27:09] <fuzzie> it does _rndbase[num_attacks - 1]->GetPixelValue(roundstatus, speed)
[15:27:15] <fuzzie> so, yes :)
[15:28:07] <wjp> crazy
[15:28:20] * wjp idly wonders if they are identical in the various games
[15:28:55] <fuzzie> i am going to stay way away from that
[15:29:46] <fuzzie> i guess i should just implement all of this like the original game for now
[15:29:47] <fuzzie> but ugh
[15:30:34] <fuzzie> i still haven't quite worked out what deals with the round times
[15:45:24] --> Bo_Thomsen has joined #GemRb
[15:45:31] <-- Bo_Thomsen has left IRC (Client Quit)
[15:47:26] <fuzzie> oh, because i am blind. nm.
[15:52:33] <edheldil> using bitmaps for small tables ... oh my
[16:06:37] <fuzzie> well, 5610 entries :)
[16:07:08] <fuzzie> anyway i am not going to fiddle with it
[16:07:28] <fuzzie> gemrb got ridiculous, it is so close but this action code really messes up too much
[16:07:47] <fuzzie> and imo just reproducing the original's behaviour for now makes a lot more sense, someone can tidy it up again to not suck later?
[16:07:55] <fuzzie> would appreciate comments on whether i'm crazy or not
[16:16:16] <wjp> yes, I agree
[16:25:06] <edheldil> I am not sure what are you doing with the actions ... temporary solutions have the bad habit of staying indefinitely :-)
[16:25:32] <edheldil> but if you think it's better, go ahead :)
[16:28:24] --> test32894789234u has joined #GemRb
[16:29:29] <fuzzie> edheldil: rewriting to match behaviour of the original, basically
[16:30:23] <fuzzie> so here it would be using the bitmaps :)
[16:31:23] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[16:33:16] --> lynxlynxlynx has joined #GemRb
[16:33:16] <-- lynxlynxlynx has left IRC (Changing host)
[16:33:16] --> lynxlynxlynx has joined #GemRb
[16:33:16] --- ChanServ gives channel operator status to lynxlynxlynx
[16:45:21] <-- lubos has left IRC (Quit: Leaving.)
[16:53:57] --> Maighstir has joined #GemRb
[16:56:38] --> Bo_Thomsen has joined #GemRb
[16:59:51] <-- SiENcE has left IRC (Quit: @all: cya)
[17:02:24] <fuzzie> lynxlynxlynx: around?
[17:03:05] <lynxlynxlynx> mhm
[17:03:31] <fuzzie> any objection to splitting out Door.cpp/Door.h, Container.cpp/Container.h and InfoPoint.cpp/InfoPoint.h?
[17:04:30] <lynxlynxlynx> hah, of course not
[17:04:43] <fuzzie> well, i just thought i'd ask before committing :)
[17:04:53] <tomprince> :)
[17:13:24] <fuzzie> just a very very naive split, one of you with a modern cpu can play header-removal if you want :p
[17:13:49] <CIA-48> GemRB: 03fuzzie * rbd3c859606d8 10gemrb/gemrb/ (23 files in 7 dirs): split out Door, Container and InfoPoint into seperate files
[17:26:45] <fuzzie> any idea why Hide would fail for the group leader only, in some circumstances?
[17:40:24] <fuzzie> lynxlynxlynx: other showstopper bugs?
[17:41:21] <lynxlynxlynx> my spellcasting leftovers
[17:42:02] <lynxlynxlynx> i also have sience's dingux stuff there, but i don't consider it a stopper
[17:42:08] <fuzzie> ok
[17:42:20] <lynxlynxlynx> i didn't check the diff, but surely we can already merge atleast the build system stuff
[17:42:44] <fuzzie> well, the build system stuff was mostly broken
[17:42:56] <fuzzie> i mean, the changes to our files
[17:43:10] <fuzzie> while the code changes were all #ifdeffed
[17:53:11] <lynxlynxlynx> heh, the opposite of what i expected
[17:53:31] <fuzzie> i did vaguely discuss it on irc
[17:53:48] <fuzzie> sience was going to look into build stuff, but possibly waiting for me, i don't know
[17:53:54] <fuzzie> i'm pretty disorganised recently
[18:06:54] <-- adominguez has left IRC (Quit: Saliendo)
[19:17:22] --> |Cable| has joined #GemRb
[19:26:40] --> kettuz has joined #GemRb
[19:27:42] <fuzzie> hmm, our IE_VISUALRANGE defaults to 30, not 14
[19:29:20] --> dossantos has joined #GemRb
[19:29:53] <fuzzie> this is very confusing
[19:31:31] <fuzzie> i suppose edheldil did this in 2005, and Avenger promptly changed it to be confusing two days later
[19:46:37] <CIA-48> GemRB: 03fuzzie * rd359538a771d 10gemrb/gemrb/core/Map.cpp: clarifications in Map.cpp
[19:46:39] <fuzzie> i'm fairly sure that AddLOS code is the stuff which breaks the visibility, but not going to touch it now.
[19:47:48] <fuzzie> GetAllActorsInRadius is completely ridiculous, too
[19:47:57] <fuzzie> but again..
[19:58:01] <-- test32894789234u has left #GemRb
[20:00:34] <-- dossantos has left #GemRb
[20:08:08] <fuzzie> that fx_disable_button_ref in HideFailed is very annoying
[20:10:08] <fuzzie> lynxlynxlynx: that is a guess?
[20:23:54] <fuzzie> oh, i guess it's annoying because there's a button check inside TryToHide..
[20:24:26] <fuzzie> bit slow today
[20:27:37] <lynxlynxlynx> you can't hide for the rest of the round once failed
[20:27:46] <fuzzie> yes
[20:27:48] <lynxlynxlynx> or maybe the whole turn, not sure
[20:28:00] <fuzzie> i am just asking, is the way you do it via effect just a guess?
[20:28:09] <fuzzie> (it is 90 ticks, yes)
[20:29:19] <fuzzie> although combat and magic rounds seem to be 100 ticks
[20:30:15] <lynxlynxlynx> that was the cleanest way to do it, no idea how the original implemented it
[20:30:45] <fuzzie> ok
[20:30:49] <fuzzie> so it is ok if i rewrite :)
[20:30:58] <fuzzie> i just know that iwd is weird for some of this stuff..
[20:32:58] <fuzzie> the roll stuff in Hide is weird too
[20:33:42] <fuzzie> the 'roll > chance' check is good, but the LuckyRoll() at the start *adds* luck
[20:33:54] <fuzzie> i am wondering if it just needs an LR_NEGATIVE, or whether more of those calls need checking
[20:34:30] <fuzzie> or whether i am misreading.
[20:38:44] <fuzzie> the original is quite weird here
[20:39:31] <fuzzie> it does LuckyRoll(100), then checks if the result is 100 for a fail, which means you can never fail a hide based on die roll if you have even 1 luck
[20:47:40] <lynxlynxlynx> that sounds just like a critical fail
[20:50:56] <fuzzie> well i'll have to look at more code, i guess
[20:53:21] <fuzzie> i guess the thing which is confusing me here is that ActionStealthPressed() in the GUIScript is not doing what i expect
[20:54:32] <lynxlynxlynx> why not?
[20:54:57] --> edheldil_ has joined #GemRb
[20:55:08] <fuzzie> the code doesn't seem to check stuff anywhere
[20:55:22] <lynxlynxlynx> hmm, come to think of it, maybe that fx_disable_button_ref isn't needed and could be done in actor::setmodalstate
[20:55:33] <fuzzie> Actor::SetModal just sort of randomly does confusing stuff
[20:55:36] <lynxlynxlynx> we already limit changes to 1 round intervals iirc
[20:55:42] <fuzzie> you get a 'leaving bla state' when you're not leaving state
[20:56:12] <lynxlynxlynx> haven't seen that
[20:56:18] <fuzzie> and it doesn't do TryToHide()
[20:56:50] <fuzzie> and the UpdateActorState applies modal actions wrongly
[20:57:03] <fuzzie> so ok, this makes more sense than my printf()s not running :-)
[20:58:20] <fuzzie> so this code goes firmly in the 'fuzzie will rewrite' pile, if that is ok
[21:01:51] <lynxlynxlynx> must release quick :)
[21:02:17] <fuzzie> well if you go branch now.. :p
[21:13:28] <fuzzie> i dumped my TryToHide fix and the Attackers stuff on github for now, anyway
[21:13:51] <fuzzie> should be trivial enough to merge in after release
[21:49:05] <fuzzie> hm
[22:04:09] <fuzzie> oh dear, that hack i added as one of my first commits, about door cursors, is right there in the code :(
[22:05:11] <fuzzie> ( if (Cursor == IE_CURSOR_DOOR) Cursor = IE_CURSOR_PASS; )
[22:22:27] <-- kettuz has left IRC (Quit: Leaving)
[22:50:08] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[22:52:53] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:11:02] <pupnik> combat is really slow on n900
[23:11:15] <fuzzie> define slow :)
[23:13:23] <pupnik> hard to control even with stop/start
[23:14:28] <pupnik> we'll look into it when i get the openpandora
[23:54:37] --> nickdaly has joined #GemRb
[23:55:15] <nickdaly> Thanks for GemRB! IE Games on the Pandora is awesome.
[23:55:41] <-- Maighstir has left IRC (Read error: Connection reset by peer)