Change in door opening (pwad)

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Post Reply
User avatar
simc
Posts: 127
Joined: Fri Feb 03, 2012 11:44 am

Change in door opening (pwad)

Post by simc »

Something got changed in the door opening behavior a few months ago. With the latest GZDoom versions in MAP29 of this Doom2 wad the player gets trapped. That did not happen earlier.
https://www.doomworld.com/idgames/level ... r/rtrbtntr

The MAP29 starts with the player being inside a dark box. When the player grabs the shotgun the wall door opens and sectors get full lighted. The trouble is that both the wall door sector and the adjacant box interior sector have the same tag to change their light level and open the door.

But with older GZDoom and ZDoom versions the wall sector just opened and the interior sector ceiling stayed high above. With new versions the wall sector opens up but the interior sector drops to the floor. I don't know the exact time of this change.

With these GZDoom builds in last May and versions before the player was not trapped.
gzdoom-g3.0pre-231-ga7cc6fb (May 27th 2017)
gzdoom-bin-3-1-0a (May 31st 2017)

But with this build and even the latest one the inner sector falls instantly to the ground and the player is stuck:
gzdoom-g3.2pre-43-g78061f1 (June 7th 2017)

I don't know if this occures in other wads. But all the other ports seem to handle this door the way GZDoom did in last May.

A took a liberty to extract the opening room of the MAP29 as a test map. Also changed some wall textures to make it visually bit more clear. (Doom2, MAP01)
Attachments
door_test.zip
(14.29 KiB) Downloaded 40 times
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Change in door opening (pwad)

Post by _mental_ »

This started since this commit. The related problem was reported by me and Graf attempted to fix it without broken everything.
More information on this topic is here.

I think the only way to fix new issue is revert the commit forget about fixing this entirely. MAP09 of Congestion 384 will be fixed by an entry in compatibility lump.
Optionally we can introduce new compatibility setting for the commit that initially broke this behavior.

I need Graf's thoughts on this solution.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Change in door opening (pwad)

Post by Graf Zahl »

I think the best option would be to change the original commit to let PIT_CheckLine only run a limited set of checks that do not mess up the positioning info after it has been determined that the actor won't fit. Since we only want line activation info this is all that should be collected there.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Change in door opening (pwad)

Post by _mental_ »

There are lots of members in FCheckPosition structure. It's not obvious which should be kept intact if actor isn't feet and which can be changed.
For example, floorz and ceilingz must remain unchanged but how about the others like dropoffz.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: Change in door opening (pwad)

Post by drfrag »

Well, i don't know exactly what's going on but i think there's a map error.
First if you walk slowly it works as intended. Then changing the outer sector and open door linedef tag to 9 instead of 8 fixes the problem, the same tag shouldn't have been used for both inner and outer sectors. The inner sector shouldn't be opened anyway so could be a broken map.
Seems like it worked by pure luck since the game entered the if first for the inner sector and then for the outer one?
And yes i cherry-picked that commit.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Change in door opening (pwad)

Post by Graf Zahl »

_mental_ wrote:There are lots of members in FCheckPosition structure. It's not obvious which should be kept intact if actor isn't feet and which can be changed.
For example, floorz and ceilingz must remain unchanged but how about the others like dropoffz.

Once blocking has been determined, none should be altered anymore. All that should be done is to add more lines to spechits.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: Change in door opening (pwad)

Post by drfrag »

So in the end this was not important right?
User avatar
simc
Posts: 127
Joined: Fri Feb 03, 2012 11:44 am

Re: Change in door opening (pwad)

Post by simc »

It appears that with gzdoom-g3.3pre-1-g69abf09 the MAP29 starts without problems.
The offical 3.2.0 still trapped the player.

So is this issue solved for the future? - Thank you all!
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: Change in door opening (pwad)

Post by drfrag »

I've been watching this and haven't seen any related changes in the repo.
User avatar
simc
Posts: 127
Joined: Fri Feb 03, 2012 11:44 am

Re: Change in door opening (pwad)

Post by simc »

Sorry: This issue still exist in the latest build gzdoom-g3.3pre-11-g4f5b459. My mistake.

In general this issue is about a mapping error.

However when the wad was uploaded in idgames the MAP29 start was tolerated by the current GZDoom at that time. According to the text file it was tested with PRBoom+ and GZdoom. Both Pr/GlBoom and Eternity can run MAP29 without the player getting trapped. So it's a backwards campatibility trouble too.

Overall a minor thing.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Change in door opening (pwad)

Post by _mental_ »

Fixed in 40fd816.
Post Reply

Return to “Closed Bugs [GZDoom]”