Duke4.net Forums: new swinging door behavoir test - Duke4.net Forums

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

new swinging door behavoir test

User is offline   Mark 

#1

I read in a recent eduke32 revision change log that a test feature for swinging doors was added. If the door gets interrupted while moving, it will reverse direction instead of just hanging part way opened/closed until it is unblocked. After playing a couple of my projects with the new feature, I'm still deciding if I like it or not. But one minor bug I noticed is if the door was autoclosing and got interrupted, after swinging open again the autoclose doesn't close.

This post has been edited by Mark: 13 March 2020 - 08:41 AM

2

User is offline   Seb Luca 

#2

A step has been taken, it's a good start ;)
0

User is offline   oasiz 

  • Dr. Effector

#3

Autoclose is such a mess to work with, I wish it was more reliable overall. It's a miracle it works as well as it does in stock duke.
0

User is offline   TerminX 

  • el fundador

  #4

Thanks for the bug report, I'll look into it.
0

User is offline   Mark 

#5

Autoclose is working with the new swingdoor feature. Thanks. newest revision 8768
0

User is offline   Mark 

#6

I'm using the latest 8813. I'm having trouble with the new door behavior again. The issue I noticed is that the door will trigger but not open until that thug is killed or drawn away from the door. He is somehow blocking it from opening. BTW, the door swings inward, away from the player. It worked fine before the new door code. So for some reason the door is a bit overactive in determining if something is blocking it. In this instance I can work around it by moving the thug a bit farther away but I figured I would mention this unintended behavior.

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.

Attached thumbnail(s)

  • Attached Image: door problem.jpg


This post has been edited by Mark: 08 April 2020 - 05:03 AM

0

User is offline   Mark 

#7

I was going to let this drop since there was no response. But after testing how far away I had to move the enemy I decided to post again. In this pic you can see the minimum distance the enemy had to be away from the door before it would open. I turned off models in the game to check the enemy's sprite dimension. Its the same as the model so thats not the cause.

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.

Attached thumbnail(s)

  • Attached Image: doortest2.jpg


This post has been edited by Mark: 10 April 2020 - 08:42 AM

0

User is offline   TerminX 

  • el fundador

  #8

That's really strange. Can you reproduce it with Duke3D at all? I tested the new behavior specifically against enemies that were too close to the doors a LOT before pushing the change, even with silly setups where doors would bounce back and forth due to enemies blocking the movement on both sides.
0

User is offline   Mark 

#9

No, I didn't try duke maps. Thats why I was asking if there were any with enemies near doors so I could test. But it seems you have. I can't imagine why this happens. I'm going to try a different actor outside and I'll try putting this one on the inside and near the door. I'll post results shortly.

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

0

User is offline   Mark 

#10

Ha. It gets even weirder. I put 6 different actors near the outside of the door. When I pressed to open, the door actually opened the wrong way and went into a loop of attempting to close. WTF? :)

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

0

User is offline   Mark 

#11

I found what was causing only certain enemies to interfere with the new swinging door behavior. They were defined as useractor enemy. Changing them to useractor notenemy solved the problem. I hope thats a hint for why the new door behavior is causing this issue. If its still something only on my end, nevermind. I found the workaround.

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

0

User is offline   Danukem 

  • Duke Plus Developer

#12

I know this issue is discussed in at least one other thread, but this is the one I found, so...


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.
6

User is offline   Aleks 

#13

Bouncing off of the player can also be problematic, as some swing doors are opened with an activator triggered by a keycard can bounce off of unaware player and lock back without further possibility to be opened again. I've run into this several times (Arzca's X3Studio map and the final keycard for example), of course it's just a softlock as reloading the game would fix it. I've had problems with enemies blocking the door from the other side more often though (for example Gambini's Blown Fuses at the beginning), which required some reloads to "align" them properly, so the doors could open. It's also very problematic with double swing doors, as they easily go out of sync (up to the point of one wing of the door swinging the wrong way around, causing other glitches).

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.
4

User is offline   Forge 

  • Speaker of the Outhouse

#14

i'd rather run the risk of the off-hand chance of getting squished than deal with the annoyance of having an activated door bonk me on the face and close back up, or to be standing there watching an enemy hold a door closed; even if it's swinging away from them.

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

3

#15

I find the paradigm shift in recent times quite interesting. As someone who mapped predominantly for Polymer I got used to being told "You're mapping different to how things worked in 1996, this is wrong, they're supposed to work the same way, so expect things to break.", only to move to more vanilla mapping later and be told "You're mapping expecting things to work like they did in 1996, this is wrong, they don't work that way now, so expect things to break."

Kinda glad I stopped bothering.
1

User is offline   Forge 

  • Speaker of the Outhouse

#16

escalators used to work well enough if done right - like in city of screams, but now they are completely broken.

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

4

User is offline   Mark 

#17

2 thumbs up for revision 4593. My go to for a long time. I still reference it occasionally when troubleshooting old bugs
0

User is offline   oasiz 

  • Dr. Effector

#18

I don't think the escalators should do that regardless unless something seriously broke or something is off with the setup.
0

#19

View PostForge, on 14 March 2021 - 07:54 AM, said:

escalators used to work well enough if done right - like in city of screams, but now they are completely broken.

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

0

User is offline   Danukem 

  • Duke Plus Developer

#20

Its unfortunate that this topic veered off into escalators, because while it would be nice to get those working properly, they are not used in the vanilla game and we don't actually need them. Swing doors, on the other hand, are ubiquitous.
2

User is offline   Jimmy 

  • Let's go Brandon!

#21

I don't mind if behaviour is different in EDuke32. Only if it works well. Somebody could always make a new version of City of Screams that is EDuke32 compatible.

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.
1

User is online   ck3D 

#22

I never minded the behavior of doors easily killing you in Build, I always looked at it as one of the quirks of the engine which actually seems very notorious for that 'mechanic'. If anything, it's something you can potentially manipulate to create danger zones in your level, too; wouldn't go as far as calling it a feature since I can't recall someone practically building such traps in user maps ever, but what I mean is I feel like it's been widely accepted as common 'Build logic' for decades and at this point, doors that kill you in user maps are entirely on the fault of bad level design to begin with. If you can use Build properly, you know the player needs space and which way your doors should open and plan against what. That's a reflex most mappers develop real quick because we're talking elementary trial and error and a very basic cog that's easily skipped with what's in the end generally functional design. It's only logical that nothing in a level should push the player through another wall by accident, at least personally I wouldn't blame most of such occurrences on the engine.

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

2

User is offline   Sangman 

#23

Is it not possible to just freeze the door movement if it bumps into the player?
1

User is offline   Aleks 

#24

The implementation of swing door before the current one wasn't aggressively smashing player against a wall, but "gently" pushing them, but continuing its movement, and it seemed to be the best one. In this case, getting squished by the door would be on the player in like 99% cases, as it gives more than enough time to back out even if a wall is nearby that would eventually squish him. Reversing to this one would probably be a solution that would satisfy the most people out there.

View PostJimmy, on 15 March 2021 - 12:35 PM, said:

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.


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 :P

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.
1

User is offline   Jimmy 

  • Let's go Brandon!

#25

View PostAleks, on 15 March 2021 - 02:16 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 :P


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.

View PostAleks, on 15 March 2021 - 02:16 PM, said:

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.

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.
1

User is offline   Mark 

#26

Before the change to this latest door behavior I slowed down the speed of doors in my maps so as not to kill the player. A compromise I could live with.
1

User is offline   Forge 

  • Speaker of the Outhouse

#27

View PostDoom64hunter, on 15 March 2021 - 04:59 AM, said:

Uhh yeah about that:

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

3

User is offline   Paul B 

#28

View PostForge, on 16 March 2021 - 07:31 AM, said:

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 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


Posted Image
0

User is offline   Jimmy 

  • Let's go Brandon!

#29

Shit like this is why I argue that RedNukem should rebrand, and both projects dig in deeper to their paths.
0

#30

View PostForge, on 16 March 2021 - 07:31 AM, said:

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

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.
0

Share this topic:


  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options