Fix for sliding doors being able to be manually closed in a half-state (looks closed, actually open)#1351
Conversation
…e (looks closed, actually completely open) If a player stands with their nose crossing into the sliding door sector and manually closes the door, the code doesn't do the same checks it does in earlier code for the automatic closing of a sliding door. This allows one to manually close the door but ALSO interrupt the actual ceiling movement and application of line blocking flags. This leaves a sliding door which animates closed but remains completely open, passable, and doesn't block sight, sound, etc. Basically, I duplicated the checks from the automatic closing routine so a manual close checks for a "crushed" actor (ceiling blocked) AND (and here is where my last deleted pull request comes in, as I misunderstood sec->thinglist, thinking it also contained the player) it checks for a mobj in the way in general, so it won't close on items. Remove the " && sec->thinglist == NULL" if that last behavior is not vanilla. I added it because I *think* vanilla didn't close these doors on items, as that very check is also in the auto-close routine.
Restored a mistakenly overwritten "if (crispy->soundfix)" check to only play the manually closed sound when Crispy sound fixes are activated.
|
Just as a hint: I could reproduce the door bug itself on both chocolate and vanilla, both seeming to behave identical in that regard. The Veteran Edition behaves slightly different, as closing the door manually with the player intersecting will get the player stuck until it is reopened. Since chocolate strife and vanilla are not demo compatible with another anyways (at least when I last checked), I think fixing it is a matter of preference. But if its fixed, it probably has to happen on chocolate strife first and then be brought into crispy from there? |
I don't think this applies here. Chocolate's mission goal is not about fixing bugs in the games. If there is a bug in Vanilla, it is expected to be present in Chocolate as well. "They are not 100% identical anyway" is not an excuse. 😉 So, indeed, I think fixing this bug is Crispy's job. The fact that we are not going to risk demo compatibility, because we never had this in the first place, just makes things a bit easier. |
Guess I implicitly acknowledged Chocolate Strife as the new demo reference/reality. 😉 |
|
If I understand it correctly, this is merely a rendering bug. That is, the door is still open, but gets rendered as if it was closed. Now, instead of changing the game logic to not close the door at all, it would be a crispier solution to actually fix the rendering bug so that the door's actual opened state is reflected by its rendered state. Do you think this is possible? Changing the game logic as always the very last resort for very severe bugs - and I usually refrain from it if any other less intrusive solution is possible. This way we could at least preserve full demo compatibility with Chocolate Strife. |
3 participants
If a player stands with their nose crossing into the sliding door sector and manually closes the door, the code doesn't do the same checks it does in earlier code for the automatic closing of a sliding door.
This allows one to manually close the door but ALSO interrupt the actual ceiling movement and application of line blocking flags. This leaves a sliding door which animates closed but remains completely open, passable, and doesn't block sight, sound, etc.
Basically, I duplicated the checks from the automatic closing routine a few lines above it for sliding doors so a manual close checks for a "crushed" actor (ceiling blocked) AND (and here is where my last deleted pull request comes in, as I misunderstood sec->thinglist, thinking it also contained the player) it checks for a mobj in the way in general, so it won't close on items.
Remove the " && sec->thinglist == NULL" if that last behavior is not vanilla. I added it because I think vanilla didn't close these doors on items, as that very check is also in the auto-close routine.