by Player701 » Wed Dec 05, 2018 5:44 am
So, it appears that playing sounds and doing other non-trivial things on the first tick of a weapon's Select state doesn't work after a level transition, and
this is not a bug (though it keeps puzzling me why). So I tried to circumvent it by doing this on the second tick instead. It all seems to work fine, save for one thing: playing sounds. They work
almost fine - an average player may not even notice this, but it also depends on the sound itself. Consider this example code:
Code: Select all
class TestPistol : Pistol
{
States
{
Select:
PISG A 1 A_Raise;
PISG A 1 A_PlaySound("misc/teleport", CHAN_WEAPON);
PISG A 1 A_Raise;
Goto Select+2;
}
}
The testing procedure is given below. It is advised to turn music off so that the sound can be heard better. Also, it looks like this bug only happens when "Screen wipe style" is not "None" (see below for more on this).
- Warp to any map.
- Type "give TestPistol" in the console. The pistol plays a teleporting sound when it is selected.
- Switch to another level by using the "changemap" console command, so that the weapons you are carrying are preserved.
- When the next level starts, the following may happen: First, you hear a very short part of the teleporting sound, for a fraction of a second. Then, the sound gets interrupted for a noticeable amount of time (a second at the very least) - this is probably when the screen wipe effect happens. After that, you hear the rest of the sound.
Unfortunately, this behavior cannot be reproduced reliably. Several iterations of the testing procedure may be required for the interruption to appear. The length of the interrupted fragment also seems to vary, but it's always very short - that's why I've picked the teleporting sound for testing, as it is quite loud in the beginning, which probably makes noticing the bug easier.
I also can't reproduce this in any number of iterations if I disable the screen wipe effect. It appears that the sound erroneously starts playing before the screen wipe happens, gets interrupted by it, and then continues from where it left off. Although this is only a theory, as I haven't looked at the code yet.
- Attachments
-
- zscript.txt
- (239 Bytes) Downloaded 80 times
So, it appears that playing sounds and doing other non-trivial things on the first tick of a weapon's Select state doesn't work after a level transition, and [url=https://forum.zdoom.org/viewtopic.php?f=2&t=62283]this is not a bug (though it keeps puzzling me why)[/url]. So I tried to circumvent it by doing this on the second tick instead. It all seems to work fine, save for one thing: playing sounds. They work [u]almost[/u] fine - an average player may not even notice this, but it also depends on the sound itself. Consider this example code:
[code]class TestPistol : Pistol
{
States
{
Select:
PISG A 1 A_Raise;
PISG A 1 A_PlaySound("misc/teleport", CHAN_WEAPON);
PISG A 1 A_Raise;
Goto Select+2;
}
}[/code]
The testing procedure is given below. It is advised to turn music off so that the sound can be heard better. Also, it looks like this bug only happens when "Screen wipe style" is not "None" (see below for more on this).
[list=1][*]Warp to any map.
[*]Type "give TestPistol" in the console. The pistol plays a teleporting sound when it is selected.
[*]Switch to another level by using the "changemap" console command, so that the weapons you are carrying are preserved.
[*]When the next level starts, the following [u]may[/u] happen: First, you hear a very short part of the teleporting sound, for a fraction of a second. Then, the sound gets interrupted for a noticeable amount of time (a second at the very least) - this is probably when the screen wipe effect happens. After that, you hear the rest of the sound.[/list]
Unfortunately, this behavior cannot be reproduced reliably. Several iterations of the testing procedure may be required for the interruption to appear. The length of the interrupted fragment also seems to vary, but it's always very short - that's why I've picked the teleporting sound for testing, as it is quite loud in the beginning, which probably makes noticing the bug easier.
I also can't reproduce this in any number of iterations if I disable the screen wipe effect. It appears that the sound erroneously starts playing before the screen wipe happens, gets interrupted by it, and then continues from where it left off. Although this is only a theory, as I haven't looked at the code yet.