Specific Door's seem broken from zdoom 2.8.x

[camaxide]

Hi, I found that several doors from my older maps are no longer working in zdoom 2.8.1 - they work in zdoom 2.7.1 and older.
The doors in question are made by multiple vertical bars so you can look past the "door"
the bars I have like this are all requiring keys - not sure if that could be part of what triggers the error.
In order for the player to be able to trigger the bars both if he presses use on or between the bars, I have made a line 8 pixels in front of the bars-door from wall to wall which triggers the bars with tag number.
The function I've used is generic door.

Here is a link to a testmap showing the error
https://drive.google.com/file/d/0B14nij ... sp=sharing

Also.. I've done some testing and it seem that if you try to trigger the line from a step below the line itself the trigger works.. but not if you are on the same level as the line.
Even if there are geometry in front of the trigger-line so you still cant physically see the trigger line it seem like its the actual fact you are lower than the line that allow you to trigger it.. strange.

[Caligari87]

Is something like the "3D midtexture" flag set on the line perhaps? Or maybe if you're too close to the line it considers you "past" it?

[camaxide]

it's no mid-texture - and its nothing to do with distance - any distance wont work - moving back will still not trigger the line (unless moving back means moving down a step so you can activate it)
try the test-map provided ^_^

[Graf Zahl]

I have no problems opening the doors. Have you checked your compatibility options? Maybe something in there interferes.

[camaxide]

hm, I've never touched the compability options in any of the builds - so all there is default.
Also - I downloaded the zdoom version 2.8.1 just to try this - and only changed the keybindings and resolution before testing.
Very strange if it works flawless for you.. both sides of the room opens for you in gzdoom 2.1.x?

[camaxide]

Ok, this is getting a bit weird - I now unloaded the rest of my resources - and only run this testmap since thats how you run it - and then it works..
So it seems there is something my code does - which messes up this door behaviour on the new versions of zdoom - but not on older versions.. very strange indeed.
Current suspect is something related to trigger-heigh check - but I'll have to try out a few things. Thanks for testing out the door on your end Graf - I'll report back when I find out what is causing this.

[camaxide]

I can confirm that it's the CheckSwitchRange in mapinfo that causes this. I'm not sure though why the behaviour of this switch is changed from the older versions of zdoom to the new versions - but at least now I know the cause.
Since I need the switch on in order for other functions to work as they are ment to, I'll have to find a workaround that allows the game to 'reach' the trigger even if its inside the floor.

[camaxide]

As for a workaround it seem the best thing to do is to disable the switchrange check from the mapinfo - and apply it per trigger inside the map - since udmf has a specific trigger for checking the range.. =)

[Graf Zahl]

Yes, I can see what change motivated it.

This condition:

// no switch found. Check whether the player can touch either top or bottom texture.

was badly checked, accepting the case when the player's bottom was exactly the same as the top of the bottom texture. After that was fixed your map broke.
Needless to say, your construct should reject the activation if CheckSwitchRange is used.

[camaxide]

Yes, it makes total sense actually - since in my case its the void "middle texture" which would work as the trigger for this "switch" and thus the trigger should actually fail - so its actually a fix and not a bug yes.
Good thing to find out now during development
Thanks again for the help ^_^