[Solved?] Can't stop errant sound playing after a save load

[AVNSnax]

I'm a bit baffled by this one. I go to load a save file, and the last sound that was played before the save suddenly triggers. The sound is not looped and was completed long before the game was saved.

I added an after load callback:

Code: Select all

def kill_sounds() -> None:
    renpy.sound.stop(channel='sound', fadeout=0.)
    renpy.sound.stop(channel='sound2', fadeout=0.)

config.after_load_callbacks.append(kill_sounds)

but it has no effect. (Yes, I have a second sound channel for things like ambient background sound and simultaneous sounds.)

Is it because I haven't explicitly called stop sound? The sound is really short, like only a second in length. It's as though the channel wasn't dequeued after that last sound was played. Anybody have any insight?

[m_from_space]

I'm a bit baffled by this one. I go to load a save file, and the last sound that was played before the save suddenly triggers. The sound is not looped and was completed long before the game was saved.

Renpy will rollback to the last checkpoint and redo certain stuff, that occured beginning with this checkpoint.

So how about you present the code that leads to this? Or does the sound always happen, no matter where you save your game?

By the way, there is not function "renpy.sound.stop()", but I guess that's just a typo, right?

[Ocelot]

By the way, there is not function "renpy.sound.stop()", but I guess that's just a typo, right?

There... is?
https://www.renpy.org/doc/html/audio.ht ... music.stop

Most renpy.music functions have aliases in renpy.sound. These functions are similar, except they default to the sound channel rather than the music channel, and default to not looping.[/code]

[AVNSnax]

Renpy will rollback to the last checkpoint and redo certain stuff, that occured beginning with this checkpoint.

So how about you present the code that leads to this? Or does the sound always happen, no matter where you save your game?

By the way, there is not function "renpy.sound.stop()", but I guess that's just a typo, right?

I don't know. It doesn't all the time, but when it does, it's consistent--it was whatever the last sound that was played before the save game, long since completed. The sound in question is a really loud GASP sound so it's disconcerting when you load that save (the last screen of the previous release, from four months ago) and it smacks you in the face before the new content starts to load.

renpy.sound.stop() works. I'm just curious as to why it's not actually, you know, stopping the sound from config.after_load_callbacks.

There's nothing unusual about the code in question:

Code: Select all

    ...
    scene black with {"master": Fade(clfDly,0.,0.)}
    $ fSay(character.e, ch1fadestr("Noooooooooo . . ."))

    pause clfDly

    play sound gasp
    stop music

    scene cliffhanger1 24 with vpunch
    pause fadesLength
    scene cliffhanger1 25 at zoomToNW(1.1, 30.) with slowDissolve
    pause fadesLength
    ...
    # code ends here

As far as checkpoints go, the save file loads to the proper screen. Maybe I need to try manually setting a checkpoint at the save point? I would have assumed that Ren'Py already does that...

[jeffster]

Renpy will rollback to the last checkpoint and redo certain stuff, that occured beginning with this checkpoint.

renpy.sound.stop() works. I'm just curious as to why it's not actually, you know, stopping the sound from config.after_load_callbacks.

Could it be that after processing after_load_callbacks Ren'Py reconstructs the saved checkpoint, so that the sound played at the saved interaction gets played, regardless of what you did before in callbacks?

Then if you could change "current sound" data during after_load, playing that last saved sound could be prevented (?)...

The problem then is to find out how Ren'Py saves "current sound" data...

BTW, did you try to use after_load label instead of after_load_callbacks?
As it's a Ren'Py label rather than Python functions, there might be a chance stopping sound could work there...
https://renpy.org/doc/html/label.html#special-labels

[m_from_space]

There... is?
https://www.renpy.org/doc/html/audio.ht ... music.stop

Oh, you don't say.

There's nothing unusual about the code in question:

Code: Select all

    ...
    scene black with {"master": Fade(clfDly,0.,0.)}
    $ fSay(character.e, ch1fadestr("Noooooooooo . . ."))

    pause clfDly

    play sound gasp
    stop music

    scene cliffhanger1 24 with vpunch
    pause fadesLength
    scene cliffhanger1 25 at zoomToNW(1.1, 30.) with slowDissolve
    pause fadesLength
    ...
    # code ends here

As far as checkpoints go, the save file loads to the proper screen. Maybe I need to try manually setting a checkpoint at the save point? I would have assumed that Ren'Py already does that...

Is this the only point in your game, where you play that gasp sound? Maybe it doesn't originate from right here. I remember that I had a similar problem once, but the sound was part of a screen and I don't even remember what was the issue.

Also, which Renpy version are you using?

[m_from_space]

As far as checkpoints go, the save file loads to the proper screen. Maybe I need to try manually setting a checkpoint at the save point? I would have assumed that Ren'Py already does that...

So here is an example for a sound that would play after loading:

Code: Select all

label start:
    "Welcome!"
    play sound applause
    "If you save here, the sound will play on loading."
    "If you save here, it won't."

If you don't want the sound to play:

Code: Select all

label start:
    "Welcome!"
    play sound applause
    $ renpy.checkpoint()
    "Now if you save here, the sound won't play."

[AVNSnax]

Is this the only point in your game, where you play that gasp sound? Maybe it doesn't originate from right here. I remember that I had a similar problem once, but the sound was part of a screen and I don't even remember what was the issue.

Also, which Renpy version are you using?

At the point of the save, it's the only time the gasp sound had been played. Version 8.2.0.

[AVNSnax]

Could it be that after processing after_load_callbacks Ren'Py reconstructs the saved checkpoint, so that the sound played at the saved interaction gets played, regardless of what you did before in callbacks?

Then if you could change "current sound" data during after_load, playing that last saved sound could be prevented (?)...

The problem then is to find out how Ren'Py saves "current sound" data...

BTW, did you try to use after_load label instead of after_load_callbacks?
As it's a Ren'Py label rather than Python functions, there might be a chance stopping sound could work there...
https://renpy.org/doc/html/label.html#special-labels

Hmmm. I added:

Code: Select all

label after_load:
    stop sound

And the sound didn't play. I guess it must be a race condition of some kind.

I don't want to jump to conclusions, so I'll keep testing this. It seems to me that after_load_callbacks should be called just before the after_load label is executed, so the result would be the same either way. I'm just too lazy to dig into the Ren'Py sources right now to hunt it down.

[AVNSnax]

As far as checkpoints go, the save file loads to the proper screen. Maybe I need to try manually setting a checkpoint at the save point? I would have assumed that Ren'Py already does that...

So here is an example for a sound that would play after loading:

Code: Select all

label start:
    "Welcome!"
    play sound applause
    "If you save here, the sound will play on loading."
    "If you save here, it won't."

If you don't want the sound to play:

Code: Select all

label start:
    "Welcome!"
    play sound applause
    $ renpy.checkpoint()
    "Now if you save here, the sound won't play."

In my case, as you can see from my code snippet the sound had been long finished by the time the save occurs (at the end of the game, several statements and seconds after the sound was played). The suggestion from @jeffster seemed to work, at least for now.

[jeffster]

Could it be that after processing after_load_callbacks Ren'Py reconstructs the saved checkpoint, so that the sound played at the saved interaction gets played, regardless of what you did before in callbacks?

Then if you could change "current sound" data during after_load, playing that last saved sound could be prevented (?)...

The problem then is to find out how Ren'Py saves "current sound" data...

BTW, did you try to use after_load label instead of after_load_callbacks?
As it's a Ren'Py label rather than Python functions, there might be a chance stopping sound could work there...
https://renpy.org/doc/html/label.html#special-labels

Hmmm. I added:

Code: Select all

label after_load:
    stop sound

And the sound didn't play. I guess it must be a race condition of some kind.

I don't want to jump to conclusions, so I'll keep testing this. It seems to me that after_load_callbacks should be called just before the after_load label is executed, so the result would be the same either way.

My guess was that probably

(1) after load the sound started to play because you used some custom ways to show dialog, instead of using regular Ren'Py dialog statements.
Ren'Py labels and dialog statements seem to be processed in some special way by Ren'Py engine, getting checkpoints etc.
Someone noticed earlier that calling a Ren'Py label and calling a Python function behave differently (in regards to rollback or something).

(2) Using callbacks, you might have stopped sound, but then starting the game from saved data "restarted" the save point, hence sound started to play as well.
If that is how it works, then callbacks could be used just to prepare/manipulate data; but as the sound data from the checkpoint didn't change, the sound was played.

I'm just too lazy to dig into the Ren'Py sources right now to hunt it down.

Me too .

[m_from_space]

In my case, as you can see from my code snippet the sound had been long finished by the time the save occurs (at the end of the game, several statements and seconds after the sound was played). The suggestion from @jeffster seemed to work, at least for now.

Your code snippet shows that after playing the sound you make some scene changes and pauses with auto timers, so nothing that forces a user to interact. Which player would save the game in the middle of some scene change to begin with?

[AVNSnax]

Your code snippet shows that after playing the sound you make some scene changes and pauses with auto timers, so nothing that forces a user to interact. Which player would save the game in the middle of some scene change to begin with?

I didn't include every line of code in the whole app. After the scene plays out, it returns to the main file (the start label) where it puts up a screen to save your game as it's the end of the chapter. That's where the interaction occurs, and by then the sound has finished playing for 30 seconds.