Change in door opening (pwad)
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.
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.
Change in door opening (pwad)
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)
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
Re: Change in door opening (pwad)
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.
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Change in door opening (pwad)
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.
Re: Change in door opening (pwad)
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.
For example, floorz and ceilingz must remain unchanged but how about the others like dropoffz.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: Change in door opening (pwad)
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.
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Change in door opening (pwad)
_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.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: Change in door opening (pwad)
So in the end this was not important right?
Re: Change in door opening (pwad)
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!
The offical 3.2.0 still trapped the player.
So is this issue solved for the future? - Thank you all!
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: Change in door opening (pwad)
I've been watching this and haven't seen any related changes in the repo.
Re: Change in door opening (pwad)
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.
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.
Re: Change in door opening (pwad)
Fixed in 40fd816.