ZDoom

Sounds like a vanilla bug in that case, and the way it's always been.

Behaves the same as in DOS. Desyncs if you press use on the door while it's opening/closing, but fixes itself after staying closed for a while.

I'm just wondering if this is still an issue. Since this report all of Duke's game logic was replaced and some issues with the soundFX controller sprite were fixed so it should be rechecked.

OK, I've just had a mess around with the DOS version, EDuke32 and Raze.

In DOS, if you stand in front of a door (I used the one in the porn shop with the 3 button code in E1L2) and mash the USE key, sooner of later you will be able to get it so that the door opens silently and then the moving sound happens later. However, if you then leave the door to shut and open it again, the sound should be back in sync (I think). Certainly, if after getting the de-sync if you allow the door to shut, open the door and then allow it to shut again under its own timing, the de-sync has gone (but you can recreate it by mashing USE again).

In EDuke, as far as I can tell, it's the same.

In Raze, once you get the de-sync, it is possible for the door to be stuck in de-sync mode. i.e. even if you leave it alone to close naturally, then re-open it and allow it to close again (as described for DOS), the sound may not re-synchronise.

[edit]Update to the above. If I have created a de-sync in Raze, then the door stays stuck as de-synchronised as long as I leave to door to wait/close under its own timing. If, however, I open the door, wait until it starts to close and them press USE to reverse the door direction again (i.e. I don't let it close fully before pressing USE), this seems to re-synchronise things. [/edit]

Gammli wrote:If it's meant that, instead of the sound playing when the door begins opening, and instead playing once it has fully opened, then that's a bug that has existed since the DOS version.

Yes, that's precisely what this is about.

However, I was not able to reproduce this in EDuke32 and Rednukem so far, whereas it's very apparent in Raze.

I'm not sure I understand what "going out of sync" means in this context.

If it's meant that, instead of the sound playing when the door begins opening, and instead playing once it has fully opened, then that's a bug that has existed since the DOS version.

Can confirm.

Investigated both doors on E1L2 and their sound does indeed go noticeably out of sync, like, no sound playing when closing and starting once the door is actually closed, and so on. However, I've not had luck reproducing this in EDuke32 so far, they both manage to stay in sync for me. I've cross-checked with the 64-bit build from today.

At least on doors that go up and down, if you open and close it rapidly the door's sound starts playing out of sync, then permanently stays out of sync with successive opens and closes. This is both on EDuke32 and RedNukem codebases.

Testing in EDuke32, opening and closing the door rapidly does cause a sync issue, but it seems to reset when the door once the door is fully open or closed.

Doors tested are the Yellow Key door and Red Key door in Duke 3D E1L2.

Edit: Clarified some text.