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

Archive Today Yesterday Tomorrow
GemRB homepage


[02:21:09] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[06:19:58] --> PixelScum has joined #GemRb
[06:20:16] --> edheldil_ has joined #GemRb
[06:21:19] <-- Drakkar has left IRC (Ping timeout: 250 seconds)
[06:31:32] <-- edheldil_ has left IRC (Ping timeout: 255 seconds)
[06:38:51] --> edheldil_ has joined #GemRb
[06:44:35] <-- edheldil_ has left IRC (Ping timeout: 255 seconds)
[06:51:04] --> Bo_Thomsen has joined #GemRb
[06:59:53] --> pupnik_ has joined #GemRb
[07:02:51] <-- pupnik has left IRC (Ping timeout: 260 seconds)
[07:28:58] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[08:01:50] <tomprince> I am curious what should happen if, in reading a compiled script, a condition in a ResponseBlock fails to be read properly.
[08:02:19] <tomprince> I am playing around with refactoring that code, and it looks like we should currently segfault.
[08:02:45] --> Demitar has joined #GemRb
[08:03:11] <tomprince> (My goal is to eventually allow multiple GameScripting languages. Perhaps starting with uncompiled code.)
[08:13:38] --> edheldil_ has joined #GemRb
[08:20:11] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[08:35:13] --> lubos has joined #GemRb
[08:35:54] <pupnik_> make the ux better
[08:42:48] <tomprince> Also, I am tempted to see if I can make OR handling special, so that we don't need the magic int return for triggers.
[08:44:48] <pupnik_> cannnot comment on that
[08:45:15] <pupnik_> do you get hard to read light text ?
[08:45:25] <pupnik_> in descriptions
[09:02:43] --> lynxlynxlynx has joined #GemRb
[09:02:44] <-- lynxlynxlynx has left IRC (Changing host)
[09:02:44] --> lynxlynxlynx has joined #GemRb
[09:02:44] --- ChanServ gives channel operator status to lynxlynxlynx
[09:08:17] --> adominguez has joined #GemRb
[09:40:01] <edheldil> tomprince: probably better to evaluate the condition as false or skip the rest of the script and warning to console/log. I would expect the original engines do the same, else they would have to fix the errors :)
[09:44:57] <fuzzie> it seems more likely that a corrupt compiled script would crash the original engines, honestly.
[09:45:40] <fuzzie> i would *also* warn that the action/trigger code is about to get rewritten again, but i expect tomprince is long asleep.
[09:47:57] <edheldil> long == 1hour at most :)
[09:48:21] <fuzzie> you are discounting the possibility of sleep-typing
[09:48:44] <edheldil> heh. My fault :-))
[09:50:05] <fuzzie> but, yes, my standard 'i will revert any code which breaks IE games' disclaimer applies
[09:51:06] <fuzzie> hah, the latest ctrl-m output for that iwd troll bug has *three* State:Hold effects applied.
[09:52:08] <fuzzie> that is a interesting problem
[09:54:54] <fuzzie> anyone know what is meant to happen in such a circumstance?
[09:57:06] <-- |Cable| has left IRC (Remote host closed the connection)
[10:04:43] <edheldil> should it happen at all?
[10:05:32] <edheldil> at least I would expect it not to stack
[10:06:00] <fuzzie> well, i mean, the circumstance in which you Hold a troll at all :)
[10:06:23] <fuzzie> since a script has to run, for the troll to die
[10:08:49] <fuzzie> but i can't run iwd from here so it goes on 'to check'
[10:27:48] <edheldil> can I test it somehow?
[10:28:00] <fuzzie> if you have iwd :)
[10:28:17] <edheldil> I do, do you have a save?
[10:28:19] <fuzzie> just cast Hold Monster (wizard spell) on a troll, then bash at it when it's held and see if it dies
[10:28:34] <fuzzie> but i have no original iwd saves i think
[10:28:41] <fuzzie> do the gemrb ones work in original?
[10:28:53] <edheldil> no idea
[10:28:59] <fuzzie> there's gemrb one attached to bug report ( https://sourceforge.net/tracker/?func=detail&aid=3200851&group_id=10122&atid=110122 ) but i think they don't
[10:29:42] --> edheldil_ has joined #GemRb
[10:32:39] <fuzzie> i think someone had a collection of saves
[10:32:42] <fuzzie> but i forget who.
[10:32:47] <fuzzie> and i guess they would be on your site.
[10:37:49] <edheldil> surprisingly they load, but I can't find the Hold monster spell
[10:38:42] <fuzzie> hm
[10:38:49] <fuzzie> it is from WIZARD_CHROMATIC_ORB
[10:38:55] <edheldil> any idea what's the resref?
[10:39:05] <edheldil> ah
[10:39:07] <fuzzie> tricky to reproduce with that, perhaps
[10:39:35] <fuzzie> spwi508 is WIZARD_HOLD_MONSTER, but i guess that is high-level
[10:39:39] <fuzzie> i don't know anything about iwd
[10:39:44] <fuzzie> i keep meaning to play it
[10:49:31] <edheldil> I have tried entangle (or whatever), and the troll went quickly from light wounds to almost dead, where it stayed. Then he killed off two party members and even when untangled, I was not able to down him. But maybe it needs more firewoer, I do not know how they are behaving
[10:50:20] <edheldil> they have some big regen when at 1hp?
[10:50:51] <fuzzie> in theory, at 1hp, they playdead
[10:51:12] <fuzzie> and then after that is finished, they gain 25hp or something
[10:51:18] <edheldil> not this one :)
[10:51:58] <fuzzie> but obviously when at 1hp, they can only be hurt by fire
[10:53:04] <fuzzie> but they do regen
[10:57:06] <edheldil> hmm, I was unable to make him playdead, he stayed at almost dead and fought on
[10:58:07] <edheldil> I need to have greater dps, but I can't train now :)
[11:00:59] <edheldil> and I haven't got fire damage at all
[11:01:38] <fuzzie> lynx suggested potn13, for fire
[11:01:55] <fuzzie> but if you can't get to the playdead bit, it won't work
[11:01:55] <edheldil> I will look to the inv
[11:05:31] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[11:43:32] --> Maighstir has joined #GemRb
[12:02:00] --- pupnik_ is now known as pupnik
[12:14:19] <fuzzie> ok, starting to work on this dialog gui stuff was a terrible idea, now i keep fixing other things
[12:41:41] <fuzzie> hukgfdhkfdgkh
[12:43:12] <pupnik> :)
[12:44:11] <fuzzie> it is quite amazing in how many places the core decides to just randomly fiddle with the GUI
[12:44:23] <fuzzie> which usually breaks it
[13:05:55] <fuzzie> so i still try working out what is breaking it
[13:06:30] <fuzzie> can't work out what stupid piece of code is calling HideGUI
[13:07:55] <edheldil> I loathed HideGUI() the first time I saw its use :)
[13:08:04] <fuzzie> well it makes sense
[13:08:19] <fuzzie> except 90% of the GUI code uses it when the GUI should *not* be hidden
[13:08:26] <edheldil> loathing it? Sure it does :-)
[13:08:32] <fuzzie> which is crazy
[13:09:41] <edheldil> exactly. It's used for 'redraw all'
[13:10:48] <fuzzie> he gui will never ever work like this
[13:12:35] <fuzzie> but it should also not be called from the core
[13:13:17] <fuzzie> i guess i have to bash at it some more, not having a lot of luck
[13:15:02] <edheldil> brb
[13:15:20] <-- edheldil has left IRC (Remote host closed the connection)
[13:22:05] --> edheldil_ has joined #GemRb
[13:32:12] --> edheldil has joined #GemRb
[13:32:12] --- ChanServ gives channel operator status to edheldil
[13:35:26] <fuzzie> aha, found the issue which was annoying me here
[13:35:38] <fuzzie> dialog code was sabotaging gui
[13:36:17] <fuzzie> great, now it works
[13:36:30] <fuzzie> you can go into map/inventory/etc and dialog interrupts correctly.
[13:37:48] <edheldil> :)
[13:42:53] <fuzzie> looks like i broke keyboard focus though
[13:57:37] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[14:20:17] --> Maighstir|phone has joined #GemRb
[14:24:55] <-- adominguez has left IRC (Read error: Operation timed out)
[14:57:32] <lynxlynxlynx> nice
[14:57:44] <lynxlynxlynx> does it also work for cutscenes?
[15:32:59] <fuzzie> no
[15:37:26] <fuzzie> i just removed the gui code from InitDialog, and moved it into my new DialogStarted() function on the guiscript side
[15:37:47] <fuzzie> it's easy to fix this stuff once the guiscript is the one doing the work
[15:38:50] <fuzzie> so it would be easy enough to do something similar for cutscenes, and i think that way we could stop EF_CONTROL from calling HideGUI/UnhhideGUI
[15:41:43] <fuzzie> but i don't see why focus is broken
[15:41:56] <fuzzie> i mean, i can't hit enter for the continue/end buttons any more
[15:42:00] <-- Demitar has left IRC (Quit: Burn the land and boil the sea, you can't take the sky from me!)
[15:47:32] <fuzzie> oh, it was a side effect of a bug :(
[15:59:29] <fuzzie> lynxlynxlynx: ok, if you have some time to test this (bg2 only) i would be grateful
[15:59:56] <fuzzie> i don't really want to merge it with all the other games until i know it's worth it
[16:03:58] <fuzzie> or well this applies to anyone else who might have time :)
[16:06:00] <fuzzie> also we seem to have become a little obsessive with the casting glows
[16:06:11] <fuzzie> applying them to all spell casts :/
[16:08:56] <fuzzie> also i seem to have re-broken spellhold :(
[16:29:40] <tomprince> fuzzie: My changes don't involve actions and triggers so much.
[16:29:48] <fuzzie> ok
[16:29:56] <fuzzie> well, my only concern is the run loops
[16:30:13] <tomprince> I realized that action and triggers and objects are generally useful, but the Response* things are only used by the scripts.
[16:30:36] <tomprince> So I split them off into a separate file, along with Update and EvaluateAllBlocks.
[16:30:51] <tomprince> And used the Resource code for them.
[16:31:21] <tomprince> Beyond that last change, most of it has been code movement, not change.
[16:31:38] <fuzzie> right, my changes are mostly in ActorBlock
[16:33:53] <tomprince> Anyway, don't worry about changing code out from under me. I am just playing around, and figuring how I think things should be structured.
[16:33:59] <fuzzie> sure
[16:34:02] <tomprince> I probably need to rewrite a bunch of my code anyway.
[16:34:09] <fuzzie> it's more of a "don't trust the current gemrb code" thing
[16:34:36] <fuzzie> but i am starting to get to the point where i can actually answer questions about that, at least.
[16:35:19] <tomprince> I think my interest in how the code works probably stop about where yours starts. :)
[16:36:45] <fuzzie> i know that i am moving more and more code into actions, which is rather spectacularly unhelpful for flexibility
[16:38:39] <tomprince> Well, when we discover the need for mor flexibility, we can simply factor out the common code.
[16:40:28] <edheldil> moving them to a plugin?
[16:40:30] <lynxlynxlynx> i already added one such todo item for the nextnext release on my list
[16:41:00] <lynxlynxlynx> fuzzie: dialogs in general or just this closing intervention?
[16:41:40] <fuzzie> this is just dialogs in general, i have not looked at the closing intervention since i last talked to you
[16:41:43] <tomprince> edheldil: That is sort of my thought, along with adding a python version.
[16:42:24] <edheldil> complement it with modularizing ie_stats and we will get somewhere ;-)
[16:42:57] <fuzzie> well this is why i am here waving the "remember we still don't have half the game working yet" flag :-)
[16:43:53] <edheldil> eh, thanks for pointing that out, spoilsport ;-)
[16:45:18] <tomprince> I will, as always, leave that to the experts. ;)
[16:45:36] <fuzzie> experts, now that sounds like a nice idea
[16:46:11] <-- lubos has left IRC (Quit: Leaving.)
[16:48:33] <fuzzie> so the spellhold following seems to depend on random factors, that is very reassuring
[16:50:03] <-- Maighstir|phone has left IRC (Read error: Connection reset by peer)
[16:52:25] <tomprince> fuzzie: Do any of your changes involve calling the action/trigger functions directly, or would it work if I hide them behind a registration interface like we do effect opcodes rightnow.
[16:52:53] <fuzzie> it depends on what you mean by directly
[16:54:04] <tomprince> Well, right now they are all defined in GameScript.h, but I want to remove the definition from the header file.
[16:54:12] <fuzzie> i can't think of a circumstance in which we couldn't refactor any such thing
[16:55:07] --> Bo_Thomsen has joined #GemRb
[16:55:09] <tomprince> Right now there is one call to SetLeavePartyDialogFile and 3 calls to ID_Alignment, and that is it.
[16:55:34] <tomprince> And your thought about refactoring was my thought, and would probably provide a nicer interface to whatever functionality anyway.
[16:55:42] <fuzzie> there is hard-coded stuff which needs to *look* at actions
[16:56:05] <fuzzie> like "is the action here in the queue the LeaveAreaLUA action?"
[16:56:10] <tomprince> But it doesn't look at the *function* does it?
[16:56:15] <fuzzie> but no, not at the function
[16:56:28] <fuzzie> and i think any function calls could just be changed to call a util function?
[16:56:44] <fuzzie> the triggers are a different story, though
[16:56:53] <tomprince> Just like the opcodes. I actually plan to refactor things, so they use common code.
[16:57:49] <fuzzie> but a refactoring another day could fix the trigger situation too
[16:58:15] <tomprince> What's the difficulty with triggers?
[16:58:32] <fuzzie> the original engine implements them completely differently
[16:58:57] <fuzzie> only the 0x4xxx ones get a function (actually, entry in a switch table)
[16:59:18] <fuzzie> i mean, there's no fundamental problem
[16:59:21] --> |Cable| has joined #GemRb
[17:00:16] <fuzzie> just that there's some gaping holes in our code which use triggers from a non-scripting viewpoint, but the non-function ones
[17:00:55] <tomprince> Speaking of triggers, what is your thought on handling OR on reading rather than on execution?
[17:01:07] <tomprince> Which would allow us to make the Triggers return bool.
[17:01:29] <fuzzie> i thought it was handled much like that now, honestly
[17:03:36] <tomprince> Right now, the trigger returns the number of entries to OR together, and then it is handle in Condition::Evaluate.
[17:03:55] <fuzzie> that is kinda strange
[17:04:22] <fuzzie> i'm not sure of the advantage, though
[17:04:43] <fuzzie> i mean, fixing that seems fine, altering Triggers to return bool is fiddling for the sake of fiddling, imo :)
[17:06:27] <tomprince> Well, as far as I can tell, the only reason they don't return bool, is so that Or can return the count of things to or together. So if Or is no longer handled by a Trigger function, then there is no reason to return anything but a bool.
[17:06:33] <fuzzie> well, we return int everywhere
[17:06:43] <fuzzie> in situations where we just use 0/1
[17:07:07] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[17:07:15] <tomprince> lots of place we don't. (perhaps just in code I've written. :))
[17:07:18] <fuzzie> it drives me quite crazy sometimes
[17:07:28] <fuzzie> well, all of gemrb drives me quite crazy sometimes :)
[17:07:56] <fuzzie> but fixing this stuff is so disruptive
[17:08:34] <-- |Cable| has left IRC (Remote host closed the connection)
[17:09:50] <fuzzie> and i'm not sure enough of the trigger design to say 'that is a super good idea', i guess
[17:09:57] --> |Cable| has joined #GemRb
[17:10:04] <fuzzie> the action stuff is clearer, we just refactored the return codes elsewhere
[17:10:24] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[17:12:21] <tomprince> Well, so long as you don't see any obvious problem with the idea, I'll write the code, and then we can figure out then if there are going to be any issues with it.
[17:16:58] <fuzzie> as usual, i just worry about the thereotical issues
[17:17:38] <lynxlynxlynx> why do you people start refactoring stuff right before release? the last one was in november :P
[17:18:19] <fuzzie> is it not more that you start thinking about release when things are interesting enough to refactor? :)
[17:18:46] <tomprince> Because I happened to have some time this week, as well as some thought on some interesting work for me. :)
[17:18:50] <fuzzie> the inability to select actors when everyone else is disabled seems to be just a UI refresh issue, weirdly enough
[17:33:45] <-- Lingerance has left IRC (Read error: Operation timed out)
[17:35:07] --> Lingerance has joined #GemRb
[17:36:54] <-- lynxlynxlynx has left IRC (Read error: Operation timed out)
[17:53:45] --> lynxlynxlynx has joined #GemRb
[17:53:45] --- ChanServ gives channel operator status to lynxlynxlynx
[18:03:23] --> Maighstir|phone has joined #GemRb
[18:20:15] <-- Lingerance has left IRC (Read error: Operation timed out)
[18:26:38] <fuzzie> does anyone have iwd+gemrb handy?
[18:29:28] <fuzzie> that ever-annoying bug with the disappearing mouse on the IWD textscreen is back to haunt me
[18:31:23] <-- Maighstir|phone has left IRC (Ping timeout: 248 seconds)
[18:31:47] <lynxlynxlynx> nope
[18:31:55] <fuzzie> well i know you don't :)
[18:35:18] <fuzzie> i just don't know whether i broke it just now
[18:36:49] --> Lingerance has joined #GemRb
[18:38:12] <fuzzie> doesn't seem so, doesn't help if i revert
[18:40:24] <lynxlynxlynx> don't remember ever seeing it
[18:40:48] <fuzzie> there is a workaround in the map script code, by wjp, dated 2006
[18:41:15] <fuzzie> does not appear to be anything to do with your merge.
[18:55:58] --> Maighstir has joined #GemRb
[18:58:18] <fuzzie> predictably enough, i can't make my new code work right in iwd2
[18:58:50] <-- Maighstir has left IRC (Client Quit)
[18:59:49] --> Maighstir has joined #GemRb
[19:03:15] --> Maighstir_ has joined #GemRb
[19:03:31] <-- Maighstir_ has left IRC (Client Quit)
[19:05:38] <-- Maighstir has left IRC (Ping timeout: 250 seconds)
[19:05:59] <fuzzie> ah, iwd2 is smart
[19:25:58] <CIA-48> GemRB: 03fuzzie * r7798fc7f73de 10gemrb/gemrb/core/Interface.cpp: don't bother changing cutscene mode if we're already in that mode
[19:26:05] <CIA-48> GemRB: 03fuzzie * r4dc2af1977ec 10gemrb/gemrb/ (14 files in 6 dirs):
[19:26:05] <CIA-48> GemRB: GUIScript dialog code update/replacement
[19:26:05] <CIA-48> GemRB: this updates all games with my recent bg2 changes, and also moves
[19:27:21] <fuzzie> i tried in all the games, with some dialogs and also making sure that you could interrupt inventory+map. seems fine but no promises :)
[19:29:43] <fuzzie> also unhelpfully fixes dialog bugs in the middle of the other code, but i'm not quite sure what fixed it
[20:09:11] <fuzzie> the spellhold battle with Jon is meant to kill folks like Wanev straight away, right?
[20:09:56] <fuzzie> also darnit Jan isn't meant to quit the party after he's *dead*.
[20:10:32] <-- Lingerance has left IRC (Read error: Operation timed out)
[20:11:36] <wjp> hm, didn't some of the inmates help out at least a little?
[20:11:45] <wjp> can't really remember though
[20:12:38] <fuzzie> maybe only at the end
[20:12:52] <fuzzie> this is completely broken though, i can't escape spellhold
[20:13:41] --> Lingerance has joined #GemRb
[20:14:15] <wjp> http://www.youtube.com/watch?v=zJLVYHWdh_8 around 1:40
[20:14:22] <wjp> they seem to survive for a bit
[20:15:08] <wjp> but they drop dead when Irenicus leaves, yes
[20:15:13] <wjp> around 2:30
[20:15:46] <fuzzie> thanks
[20:18:38] <fuzzie> hm, seems that the area script unlocks door06, door05 and door08
[20:18:41] <fuzzie> and i am trapped behind door09
[20:32:28] <fuzzie> mmh
[20:33:01] <fuzzie> i tried it a second time, and the door was open, but Lonk the Sane had spawned again.
[20:36:09] <lynxlynxlynx> which area?
[20:39:27] <fuzzie> ar1515, the variables are all perfect
[20:42:52] --> edheldil_ has joined #GemRb
[20:43:11] <lynxlynxlynx> the door leading down are locked when you came back?
[20:43:24] <lynxlynxlynx> *out of the small room leading down
[20:43:29] <fuzzie> yes
[20:43:37] <fuzzie> it makes no sense, there's no references to closing it
[20:44:11] <fuzzie> am valgrinding it
[20:44:25] <lynxlynxlynx> it is closed by default if it is the same area you first enter spellhold
[20:44:42] <fuzzie> yes, but you have to go through it to kill Lonk to win the battle with Jon
[20:45:27] <lynxlynxlynx> yes, so there should be a reference to opening it, not closing, if any
[20:45:35] <lynxlynxlynx> or unlocking
[20:45:45] <fuzzie> there is indeed a reference to unlock+open
[20:46:18] <fuzzie> i wouldn't worry about it, i will keep prodding
[20:51:46] <-- Lingerance has left IRC (Ping timeout: 260 seconds)
[20:55:23] --> Lingerance has joined #GemRb
[20:56:40] <fuzzie> well valgrind is certainly unhappy
[21:05:33] <lynxlynxlynx> break any current action only after queueing cutscene actions <-- this one has a note that it breaks blocking instants, if there are any
[21:06:09] <lynxlynxlynx> i didn't check in there yet, but MoveAreaObject seems to satisfy this condition
[21:06:19] <lynxlynxlynx> err MoveViewObject
[21:06:50] <fuzzie> hmm
[21:07:20] <lynxlynxlynx> it is the only thing that hit the breakpoint in that cutscene, but somehow some other stuff happened aswell (and not in the area script, so maybe part of m's)
[21:07:53] <fuzzie> i'd have to check original to see how that is meant to work
[21:08:17] <fuzzie> but that line itself would not break MoveViewObject.
[21:10:55] <lynxlynxlynx> ok
[21:11:03] <fuzzie> does the FinalFight get updated?
[21:11:13] <lynxlynxlynx> yes
[21:11:31] <lynxlynxlynx> i saw that yesterday, so i didn't break on setglobal now
[21:11:43] <lynxlynxlynx> nor the waits, since i thought one of the rest was problematic
[21:13:07] <lynxlynxlynx> i guess i'll go try with those too now
[21:13:42] <fuzzie> the instants code really sucks
[21:13:49] <edheldil_> do you still need to test HoW, fuzzie?
[21:14:11] <fuzzie> yes
[21:14:18] <fuzzie> i just want to know if that textscreen is broken for everyone
[21:14:25] <fuzzie> (at start of game)
[21:17:02] <lynxlynxlynx> huh, wait after wait, a few actions are skipped right there (should be smallwait)
[21:17:23] <fuzzie> you should get 30 calls to wait
[21:17:26] <edheldil_> what exactly do you mean? image with a scrolling text and voiceover?
[21:17:37] <fuzzie> edheldil_: yes - does the mouse cursor appear or not?
[21:18:10] <lynxlynxlynx> oh, i see
[21:18:15] <lynxlynxlynx> for the whole duration
[21:18:45] <fuzzie> yes. we still have a WaitCounter for some hacks but i think they're all incorrect
[21:19:16] <wjp> hm, that textscreen hack from 2006 is ancient :-)
[21:19:38] <wjp> these seem to be some notes from back then: http://www.math.leidenuniv.nl/~wpalenst/bg2/textscreen
[21:20:05] <fuzzie> yes, i know cause too
[21:20:09] <fuzzie> just don't see why it changed now
[21:20:15] <lynxlynxlynx> well, after the waits, new things are happening, but not from this script
[21:20:28] <lynxlynxlynx> the only thing i'm not breaking in it yet is the actionoverride
[21:20:57] <lynxlynxlynx> maybe the death screws everything up
[21:21:03] <fuzzie> what dies?
[21:23:03] <lynxlynxlynx> not sure, will have to check manuall
[21:23:05] <lynxlynxlynx> y
[21:23:18] <fuzzie> if the cutspy2 dies, then badness
[21:23:18] <edheldil_> no cursor
[21:23:24] <fuzzie> edheldil_: ok, thanks :/
[21:25:26] <fuzzie> ok, there is a CanCast check in Scriptable which breaks stuff
[21:28:04] <fuzzie> i guess it can be hooked onto a param but i'll have to look
[21:28:10] <lynxlynxlynx> which part?
[21:28:23] <fuzzie> the silence check, for example
[21:28:44] <edheldil_> btw, the problem with randomly appearing initial letter is there still, and the text repeats (and very quickly). But at least it nows starts at the beginning
[21:29:17] <lynxlynxlynx> i think the Force* variants ignore it in the original
[21:29:19] <fuzzie> the initial letter thing is really silly, it's just that we try and 'shortcut' the drawing code by only drawing lines we need
[21:29:28] <lynxlynxlynx> there's a lot of ai cheating lore
[21:29:29] <fuzzie> lynxlynxlynx: yes, the instance i found was a ReallyForceSpellRES
[21:29:44] <fuzzie> i wonder if 'deplete' is sufficient
[21:30:03] <fuzzie> since it's presumably not set for any AI casts
[21:30:43] <lynxlynxlynx> we can change it later if turns out to be different
[21:30:47] <lynxlynxlynx> sounds like a good start
[21:31:51] <fuzzie> i have no idea what would break your cutscene though.
[21:32:42] <lynxlynxlynx> from the live actors, there's the part and one nameless thing
[21:33:06] <lynxlynxlynx> i crashed gdb before estamblishing if that is cutspy2 or mellisan
[21:33:18] <fuzzie> well, it looks like mellisan should die quickly
[21:33:31] <lynxlynxlynx> but i think it is the former, iirc she has the names set up properly
[21:33:38] <fuzzie> i was wondering if the ReallyForceSpellRES("jwchnlgt","cutspy2") managed to interfere with cutspy2's script
[21:34:39] <lynxlynxlynx> its coordinates don't match anything in the script
[21:35:13] <lynxlynxlynx> oh right, there are two blocks - forgot about that
[21:35:15] <fuzzie> i assume 213 is TRAPSNAR (but i forget how the off-by-one stuff works) which doesn't *seem* to do anything except a fancy AoE effect
[21:35:18] <lynxlynxlynx> testing
[21:36:52] <lynxlynxlynx> uh, we don't have ReallyForceSpellRES defined anywhere
[21:36:56] <lynxlynxlynx> we override it by id?
[21:37:02] <fuzzie> yes, it's ReallyForceSpell
[21:37:11] <fuzzie> same for original engine, just the different name was required by bioware's script compiler
[21:38:21] <fuzzie> come to think of it i hope that isn't used in any dialogs
[21:38:53] <fuzzie> but i doubt original engine handles that either
[22:30:06] <lynxlynxlynx> the spells look fine
[22:34:46] <fuzzie> it does the Wait and then just stops?
[22:36:34] <lynxlynxlynx> this time i only checked the other block, which ran everything - both casts and the destroyself
[22:36:46] <fuzzie> well, that is good, i suppose :)
[22:37:05] <lynxlynxlynx> setsequence too
[22:37:17] <lynxlynxlynx> yeah
[22:40:42] <fuzzie> huh, that area script
[22:40:45] <fuzzie> just has the bios
[22:41:22] <lynxlynxlynx> yeah and that part worked once i got to it in the playthrough
[22:42:51] <fuzzie> still no idea what might go wrong there, very odd
[22:43:07] <fuzzie> i guess seeing if the CreateVisualEffectObject runs is an obvious thing
[22:43:11] <lynxlynxlynx> cutspy is alive, no interesing effects
[22:43:40] <fuzzie> we are off on the timing there though
[22:43:42] <lynxlynxlynx> it doesn't run
[22:44:00] <fuzzie> any idea about the SmallWait?
[22:44:00] <lynxlynxlynx> the first smallwait is the first thing that doesn't happen
[22:44:03] <fuzzie> ugh
[22:44:42] <fuzzie> there should be no way that should happen
[22:44:48] <fuzzie> unless the queue on cutspy2 is being wiped entirely
[22:46:18] <lynxlynxlynx> no scripts on the fella
[22:46:30] <fuzzie> you have gdb available? what's CurrentAction?
[22:46:51] <lynxlynxlynx> -1
[22:47:03] <lynxlynxlynx> but that's now that things are already over
[22:47:14] <fuzzie> well, that is not useless
[22:47:29] <fuzzie> i mean, it means it isn't blocking infinitely on something?
[22:48:29] <lynxlynxlynx> i guess
[22:48:38] <lynxlynxlynx> it broke so the other block started executing
[22:48:50] <fuzzie> they should execute simultaneously
[22:49:03] <lynxlynxlynx> oh
[22:49:29] <fuzzie> (when a cutscene is run, the entire set of actions in a block is dumped into the queue of the object referenced on the first line, all at once)
[22:49:32] <lynxlynxlynx> well, the last thing that looked fine in his block is the wait, but i doubt we have something so obvious broken
[22:49:52] <lynxlynxlynx> yes, i know that much :)
[22:50:34] <lynxlynxlynx> i'll break on clearallactions, maybe that'll catch it
[22:50:54] <fuzzie> that one is just broken :/
[22:52:19] <lynxlynxlynx> Scriptable::ClearActions then
[22:52:37] <fuzzie> that might be interesting
[22:52:45] <fuzzie> i am wondering if we ReleaseCurrentAction in a loop somewhere
[22:53:17] <fuzzie> that would quickly destroy a queue. come to think of it, some users of that should really obey the interrupt bits..
[23:02:28] <lynxlynxlynx> grr
[23:02:50] <lynxlynxlynx> such a noisy function and then gdb doesn't want to "display"
[23:07:20] <lynxlynxlynx> anyway, all the calls had actionQueue empty already
[23:07:48] <fuzzie> hmm
[23:07:53] <fuzzie> but this worked once upon a time?
[23:09:01] <fuzzie> as a really stupid check, i would print script name and queue size on GameScript.cpp:1904 or so (next to the 'this will break blocking instants' TODO)
[23:09:46] <fuzzie> just make sure they're getting there at all
[23:10:52] <lynxlynxlynx> i'll just break there
[23:13:41] <lynxlynxlynx> rS->responses[0]->actions.size() is 25 there :)
[23:14:26] <fuzzie> so that sounds great
[23:14:49] <lynxlynxlynx> right after the following release, it's at 22 (actionQueue)
[23:15:02] <fuzzie> also ok
[23:15:22] <lynxlynxlynx> ok
[23:15:23] <fuzzie> you should lose the CutSceneId, the MoveViewObject and the SetGlobal, ideally
[23:16:41] <fuzzie> well, you shouldn't :P but in gemrb's broken model, you should
[23:17:28] <fuzzie> i can't imagine any explanation other than the cutspy2 dying in there
[23:18:48] <lynxlynxlynx> appears so (re 3), front has 63 - wait
[23:19:49] <lynxlynxlynx> hmm, maybe i mistook both spies
[23:20:03] <lynxlynxlynx> one of those jw spells does deal a bit of damage
[23:21:26] <fuzzie> but you should get either a break in ClearActions, or a flood of messages about actions cancelled on death
[23:22:01] <lynxlynxlynx> Actor::Die didn't get called
[23:22:17] <lynxlynxlynx> none of that either
[23:22:21] <fuzzie> that seems to count out death then :)
[23:22:27] <lynxlynxlynx> only another break, but that's for the other block
[23:22:39] <fuzzie> but it makes no sense, the queue shouldn't empty
[23:22:49] <fuzzie> hmm
[23:22:54] <fuzzie> *is* the queue empty?
[23:23:12] <lynxlynxlynx> which queue?
[23:23:28] <fuzzie> actionQueue of cutspy2
[23:25:01] <fuzzie> oh i really hate this code sometimes
[23:25:15] <fuzzie> also check WaitCounter, if you could
[23:25:30] <lynxlynxlynx> it's 1
[23:25:47] <fuzzie> i mean, after the Wait disappears
[23:26:31] <lynxlynxlynx> this is after everything
[23:26:41] <fuzzie> that shouldn't happen
[23:26:47] <fuzzie> did you check actionQueue?
[23:26:49] <lynxlynxlynx> can i access the actions stuff from within Actor?
[23:27:08] <fuzzie> yes
[23:27:17] <fuzzie> i see "protected: //let Actor access this" :)
[23:28:07] <lynxlynxlynx> ah, only completion problem :)
[23:28:12] <lynxlynxlynx> it still has 22
[23:28:30] <fuzzie> Hold effect?
[23:28:45] <lynxlynxlynx> summondisable
[23:29:03] <lynxlynxlynx> ooh
[23:29:11] <fuzzie> scripts don't run if Immobile()
[23:29:14] <lynxlynxlynx> state_still?
[23:29:20] <lynxlynxlynx> arr
[23:29:46] <fuzzie> i think that is quite likely to be incorrect
[23:30:20] <fuzzie> was talking about it earlier, surely a troll with Hold effect should still run the scripts which turn off minhp and allow you to kill it, for example
[23:30:39] <fuzzie> but you win the debugging patience prize of the day :)
[23:32:02] <lynxlynxlynx> of the night >>
[23:32:37] <lynxlynxlynx> i don't remember for which state we added that
[23:32:52] <lynxlynxlynx> or for what
[23:33:11] <lynxlynxlynx> there was some talk whether to use immobile or that particular state in there iirc
[23:33:27] <lynxlynxlynx> see you in a few h
[23:34:13] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:34:16] <fuzzie> 'stunned' i guess
[23:34:18] <fuzzie> oh :)
[23:34:22] <fuzzie> yes, i suppose i should sleep also