new swinging door behavoir test
#1 Posted 13 March 2020 - 08:40 AM
This post has been edited by Mark: 13 March 2020 - 08:41 AM
#3 Posted 14 March 2020 - 01:48 AM
#5 Posted 18 March 2020 - 01:16 PM
#6 Posted 08 April 2020 - 05:00 AM
The other issue I have can also be worked around with Mapster. I have a timed sequence involving a moving actor going thru swinging doors with autoclose and playing quotes/sounds. Something changed and I had to tweak code values to change timings. Not a big deal. Possibly the same issue of blocking detection too sensitive.
This post has been edited by Mark: 08 April 2020 - 05:03 AM
#7 Posted 10 April 2020 - 08:41 AM
Are there any original or user maps where an enemy is real close to a swing door? It would be good to check behavior in those maps too.
This post has been edited by Mark: 10 April 2020 - 08:42 AM
#8 Posted 10 April 2020 - 05:06 PM
#9 Posted 10 April 2020 - 06:13 PM
edit: With that actor moved inside the door it will open as it should. However, now the door won't close from the inside, manually or autoclosed. So whatever side of the door that actor is on it disrupts door behavior. And if he dies and falls in front of the door it closes, but not while he lives.
Putting another actor in his place, no issues. I'll take a look at my code but I can't imagine how any of it could affect a door. There is nothing fancy going on with him. I'll try all of them, one at a time. If I find more than one giving a problem maybe I can find a pattern. The baffling part is it was fine with versions before the door code change.
This post has been edited by Mark: 10 April 2020 - 06:31 PM
#10 Posted 10 April 2020 - 06:57 PM
EDIT: I found 3 actors that trigger the door issue. The other 4 or 5 are OK. So now I have to try and figure out what those 3 have in common and how it could interfere with a door. That can wait til tomorrow. I've done enough testing for one night.
This post has been edited by Mark: 10 April 2020 - 07:20 PM
#11 Posted 30 April 2020 - 11:11 AM
To save me a bit of searching, does anyone remember what the hardcoded differences are between enemy and notenemy?
This post has been edited by Mark: 30 April 2020 - 11:28 AM
#12 Posted 13 March 2021 - 09:16 PM
The new swing door behavior (i.e. the changes first implemented about a year ago) are a net negative and can result in softlocks in vanilla maps that used to work fine.
Example: In the map Suburban Hive, a community project map built over 10 years ago, there's a large rotating sector tagged as a swing door that functions as a catwalk. The player must flip a switch to turn it so it can be used. But currently it is broken because there is a single slimer in the area. The "swing door" bumps into the slimer and it reverses direction. Since the slimer is on the opposite side where the player can't shoot it, the player can only proceed with the jetpack.
Other less dramatic examples abound. Is there a keycard on that toilet? Good luck getting it if it is guarded by a liztroop. The swinging door of the toilet stall will bump into the enemy, and if he is close enough to the door you won't be able to get it open an inch and can't even shoot him. Or, maybe initially enemies were not near a swing door, but they are following you and you close it to buy a moment of peace. Now you are ready to open it but...nope, they are blocking the door and you are stuck.
Swing doors need to push sprites out of the way. At least normal statnum 1 sprites and slimers. If it can bounce off of the player, then fine, that's probably for the best.
#13 Posted 14 March 2021 - 02:00 AM
In newer maps, some way of workaround this is using ST30 rotating rise bridge, which can act basically the same as swing doors (but can't be activated by just pressing use on door), with a bonus of also moving sprites - and doesn't bounce from actors or obstacles.
#14 Posted 14 March 2021 - 06:55 AM
But it's all yelling into the wind until someone provides a half-dozen examples from the vanilla episodes
This post has been edited by Forge: 14 March 2021 - 07:17 AM
#15 Posted 14 March 2021 - 07:02 AM
Kinda glad I stopped bothering.
#16 Posted 14 March 2021 - 07:54 AM
of course that was an 'unused' effect, so nothing will ever be done about it and it's been like that for awhile.
r4593:
r7136:
This post has been edited by Forge: 14 March 2021 - 08:09 AM
#17 Posted 14 March 2021 - 11:55 AM
#18 Posted 15 March 2021 - 02:09 AM
#19 Posted 15 March 2021 - 04:59 AM
Forge, on 14 March 2021 - 07:54 AM, said:
of course that was an 'unused' effect, so nothing will ever be done about it and it's been like that for awhile.
r4593:
r7136:
Uhh yeah about that:
SE26 is used in Ion Fury.
commit 5364b4a53a94897be158d3c3f9ad8c55053ff1a0 Author: Evan Ramos <hendricks266@gmail.com> Date: Mon Dec 26 06:03:00 2016 +0000 Extend SE 26 to use the value provided by a GPSPEED, if any. From-SVN: r5974
It was changed so that the speed could be altered, which is used in the Fury map. This is also what causes the difference in City of Screams.
In general, it's not possible to know every single instance in which some features were used in custom maps, so naturally things may break. Especially really obscure features like this one.
Edit: It's also worth noting that the escalator in City of Screams looks somewhat broken even in DOS, so it never was a particularly robust application.
This post has been edited by Doom64hunter: 15 March 2021 - 05:01 AM
#20 Posted 15 March 2021 - 09:35 AM
#21 Posted 15 March 2021 - 12:35 PM
However this "new" door behaviour causes more problems than it solves. I can understand wanting to keep the player from getting killed randomly. Maybe instead of the current behaviour, it could be reverted back to old behaviour. Then instead of letting the player get squished, the game could just teleport the player a safe distance, like Postal 2. I dunno, just a thought.
#22 Posted 15 March 2021 - 01:01 PM
I'm not even advocating for one system over another, as far as I'm concerned I can still choose to play outdated revisions as much as I want and so I have zero stakes in this. But my experience might be interesting because it's been quite high in contrast, for I never updated my main build since 2010 until a few months ago when I needed the latest version to beta test something, so I was brutally presented to the change and honestly my first impression was quite terrible (I had read bad feedback on here already at that point but still didn't think I'd ever be bothered by something seemingly as simple, because I play Duke 3D in 2021, by definition I'm not easily bothered). Especially in maps where timed sequences exist, getting stuck behind a door for minutes because a stray respawn on the other side is blocking it is quite frustrating, and usually ends up in time wasted mashing keys, trying to manipulate the enemy or the door or reloading to try and reset the RNG (which often does nothing when you've recently saved, and would potentially ruin saveless runs). That's not just unnecessarily stressful, it also completely breaks the immersion and ruins a lot of the flow and fun of the game, so I'm tempted to support the idea that the new behavior might be doing more harm than good.
tl;dr it's not the doors, it's what people do with them.
This post has been edited by ck3D: 15 March 2021 - 01:17 PM
#23 Posted 15 March 2021 - 01:20 PM
#24 Posted 15 March 2021 - 02:16 PM
Jimmy, on 15 March 2021 - 12:35 PM, said:
But then there would be a possibility the game teleports the player outside of bounds or to a location he wasn't supposed to visit yet, which also happened in Postal 2
As for the escalator, City of Screams is the only Duke map where I've ever seen this effect used properly and working. I was a bit disappointed some time ago when I wanted to check it out and saw it's broken now, but oh well. The effect in IF is obviously much better coded and works smoothly.
#25 Posted 15 March 2021 - 02:35 PM
Aleks, on 15 March 2021 - 02:16 PM, said:
Pretty sure the out of bounds could be avoided, but hey if it shoots you somewhere you're not supposed to be, there's always DNCLIP.
Aleks, on 15 March 2021 - 02:16 PM, said:
Pretty sure that this is a new EDuke32 feature that Ion Fury takes advantage of. Many of IF's features are readily available in EDuke32, people just haven't taken advantage of them yet, probably because there's little in the way of documentation.
#26 Posted 15 March 2021 - 07:12 PM
#27 Posted 16 March 2021 - 07:31 AM
Doom64hunter, on 15 March 2021 - 04:59 AM, said:
SE26 is used in Ion Fury.
Uhh yeah about that:
the whole point is that the behavior of effects have been changed - doors, escalators, possible collision issues with teleporter SE 7's, etc. which affect hundreds, if not thousands, of user made projects that have been released over the last 25 years.
yay! an effect that has been modified works great for their commercial product - too bad about the original behavior.
Unpopular opinion: We don't need an all-in-one build engine port if it's going to break original behavior and effects in the games it's intended to support.
having to have a pre 2018 and a post 2018 snapshot kinda defeats the purpose anyway
This post has been edited by Forge: 16 March 2021 - 08:39 AM
#28 Posted 16 March 2021 - 08:36 AM
Forge, on 16 March 2021 - 07:31 AM, said:
the whole point is that the behavior of effects have been changed - doors, escalators, possible collision issues with teleporter SE 7's, etc. which effect hundreds, if not thousands, of user made projects that have been released over the last 25 years.
yay! an effect that has been modified works great for their commercial product - too bad about the original behavior.
Unpopular opinion: We don't need an all-in-one build engine port if it's going to break original behavior and effects in the games it's intended to support.
having to have a pre 2018 and a post 2018 snapshot kinda defeats the purpose anyway
#29 Posted 16 March 2021 - 09:15 AM
#30 Posted 19 March 2021 - 11:59 AM
Forge, on 16 March 2021 - 07:31 AM, said:
the whole point is that the behavior of effects have been changed - doors, escalators, possible collision issues with teleporter SE 7's, etc. which affect hundreds, if not thousands, of user made projects that have been released over the last 25 years.
yay! an effect that has been modified works great for their commercial product - too bad about the original behavior.
Unpopular opinion: We don't need an all-in-one build engine port if it's going to break original behavior and effects in the games it's intended to support.
having to have a pre 2018 and a post 2018 snapshot kinda defeats the purpose anyway
Your previous post made it sound like the effect was forgotten about though, which was not the case.
Either way it's fixed now and works in City of Screams again.