Hi,
> The pod effect is played twice:
>
> first time, when the door opens:
And it seems to work there for you...
> Then when it shuts down:
> but when I mangle the sound server to not loop on -1:
>
> Receiving song for handle aab2: 744 bytes: OK
> Set loops to -1 on handle aab2
> Playing handle aab2
> FSCI: process_sound_events(ksound.c L105): Received absolute cue 9 for aab2
> FSCI: process_sound_events(ksound.c L74): Received finished signal for aab2
>
[...]
> It's like 'signal' is not getting set correctly; or there's something
> else that is resetting it down the line, moving 'signal' into
> 'prevsignal'. I'm trying to figure this stuff out.. not familiar with
> the guts to figure out what it's checking...
Actually, it's the same here, but it appears to work.
> Interesting...
>
> 2B63: [W] send 04
> doorSound::check[FUNCT]()
> 419D: [B] pToa 12 (signal)
>
> pc=419f acc=0009 o=aab2 fp=69b0 sp=69b0
> prev=3c sbase=6994 globls=23fa &restmod=0
> Step #941452
>
> 419F: [W] bnt 0019 [41b8] *** so it basically finds the cue, no branch.
> 41A2: [W] push1
> 41A3: [B] pTos 16 (client)
> 41A5: [B] callk IsObject[6] 02
> Kernel params: (0000)
>
> 41A8: [W] bnt 0008 [41b0] *** takes the branch..
> 41B3: [B] pToa 12 (signal)
> 41B5: [B] aTop 14 (prevSignal) ** moves it into the prev signal
> 41B7: [B] ldi 00
> 41B9: [B] aTop 12 (signal)
>
> ....and then it pretty much fizzles from there. It looks like the
> client for the sound object isn't getting set correctly, so nothing is
> happening when the sound cue is coming through!
No, I don't have a client object either, and it works fine. The calling script
is probably checking doorSound explicitly.
Here's the code for my doorSound:
463D: [B] pToa 12
463F: [W] bnt 0026 [4665]
4642: [W] push
4643: [B] ldi ff ; (1)
4645: [W] eq?
4646: [W] bnt 0006 [464c]
4649: [W] push1
464A: [B] pushi 0c
464C: [B] callk DoSound[31] 02
Kernel params: (000c)
464F: [W] push1
4650: [B] pTos 16
4652: [B] callk IsObject[6] 02
4655: [W] bnt 0008 [465d]
4658: [B] pushi 7c
465A: [W] push1
465B: [W] pushSelf
465C: [B] pToa 16
465E: [W] send 06
4660: [B] pToa 12
4662: [B] aTop 14
4664: [B] ldi 00
4666: [B] aTop 12
4668: [W] ret
(1):
I haven't seen this one in your trace, but this is the place where
the door sound is actually "finished": When the "loop" signal reaches
the object, the signal property is set to 0xffff, so the 'eq' after
(1) matches, and DoSound(STOP_ALL) is invoked. I haven't checked what
happens then, but I'd guess that doorSound gets the "stopped" message
from the sound server, and the game continues as soon as soon as
it realizes that doorSound has been stopped.
This is how it works on my system with my version of SQ3. Please go
on checking where you left off- the "loop" signal (0xffff) should come
next...
(Note that you can use "save_game" and "restore_game" for debugging,
but they don't currently save the background pic, since this is done
by the scripts in Sierra's adventures).
llap,
Christoph
-- Attached file included as plaintext by Listar --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjqFIxIACgkQg4EAPSSqEf9KSACfRB/Pjw2I/rG+mlxIxwRaf/v2
WQQAn2o4/e87BoAKNn6InUF7nuGaniEK
=pAH5
-----END PGP SIGNATURE-----
