Duke4.net Forums: [Fixed] Ducking behavior - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

[Fixed] Ducking behavior

User is offline   NightFright 

  • The Truth is in here

#1

In latest EDuke32 builds (using r8133 here), it seems that the player is ducking automatically whenever there is any chance to do so. If there is a table and you approach it, chances are you are ducking underneath it. When there is a space lower than the player with a sloped ceiling, you are ducking. There are many other situations like that. I think this was done to reduce situations where player gets crushed, but IMO it's overdone to the point it actually becomes annoying, especially since it's happening when you don't want it to.
7

#2

Yeah this is pretty annoying and intrusive gameplay-wise, have to agree.

This post has been edited by Doom64hunter: 27 September 2019 - 01:20 AM

0

User is offline   Sanek 

#3

I was just about to make a thread about this. Bumped this one, hope it'll be fixed in the next update, since it ruins like 90% of user maps that have extensive spritework in it.
0

User is offline   Forge 

  • Speaker of the Outhouse

#4

the opposite of how a sprite ladder works, but lord forbid that should get put back the way it was originally.
0

User is offline   Mark 

#5

Yeah, there are a bunch of unfixed issues from the last few months. :o
0

User is offline   NightFright 

  • The Truth is in here

#6

Since I didn't see any entry about this in the recent EDuke32 snapshot changelog, I didn't assume it was fixed. There may be more imminent issues at hand, but it's really annoying if you duck automatically without pressing the crouch key. The "feature" is also far too sensitive, you just need to get close to a (sloped) ceiling and you are crouching.
0

User is offline   Forge 

  • Speaker of the Outhouse

#7

i've had it grab me out of the middle of a jump & slam me under a slope - which did crush me - because I brushed against the wall well above the slope

This post has been edited by Forge: 18 November 2019 - 07:19 AM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #8

Need test maps, or links to existing maps and the location where it happens.
1

User is offline   Forge 

  • Speaker of the Outhouse

#9

sectors with downward sloping ceilings in the outer wall of the ring hallway in the boss map at the end of Ion Maiden

This post has been edited by Forge: 18 November 2019 - 08:54 PM

1

User is offline   Vadim Z 

#10

View PostHendricks266, on 18 November 2019 - 03:07 PM, said:

Need test maps, or links to existing maps and the location where it happens.


For example, I've found that Duke often autoducks under the berth in the room at the picture (in L2E7 "Lunar Reactor"):
Posted Image

This post has been edited by Vadim Z: 21 November 2019 - 09:05 PM

2

#11

This issue was introduced by r8119, and it does appear to be the inverse of the sprite-ladder behavior.

A more accesible map to test this is the table at the very start of E4L10 (The Queen). In DOS Duke 3D, the player walks ontop of the table, in r8118, the player is blocked by the table, and in r8119 and up, he automatically crouches under the table.
I think the desirable behavior would be the DOS one, if we want to ensure compatibility with old User Maps.

This post has been edited by Doom64hunter: 23 December 2019 - 01:37 PM

2

#12

So I found that in order to revert this behavior, it suffices to remove the following two lines in player.cpp:
Index: source/duke3d/src/player.cpp
===================================================================
--- source/duke3d/src/player.cpp        (revision 8533)
+++ source/duke3d/src/player.cpp        (working copy)
@@ -4691,9 +4691,9 @@
             getZRangeOffset += klabs((actor[pPlayer->i].ceilingz + PMINHEIGHT) - (pPlayer->pos.z + getZRangeOffset));
     }
 
-    pPlayer->pos.z += getZRangeOffset;
     getzrange(&pPlayer->pos, pPlayer->cursectnum, &ceilZ, &highZhit, &floorZ, &lowZhit, pPlayer->clipdist - GETZRANGECLIPDISTOFFSET, CLIPMASK0);
-    pPlayer->pos.z -= getZRangeOffset;
 
     pPlayer->spritebridge = 0;
     pPlayer->sbs          = 0;

Since it temporarily lowers the player's z position just for this call of getzrange, I'm wondering what the original purpose of this was? Is the ducking behavior intentional?

This post has been edited by Doom64hunter: 22 January 2020 - 12:34 PM

3

User is offline   Hendricks266 

  • Weaponized Autism

  #13

git blame says this was introduced in r7428.

It would be useful to have a set of test cases for things fixed by the clipping changes so that regressions can be fixed without undoing the fixes.
1

User is online   Danukem 

  • Duke Plus Developer

#14

I remember that fixing SOS warping motivated some changes, but other than that I have no idea. The working assumption in the Duke community is that the original round of clipping changes was being driven by Ion Fury development. Before Ion Fury, old behavior was (mostly) regarded as sacrosanct -- even things that seemed pretty buggy were usually left alone if they were that way in DOS Duke. There were some exceptions but these major changes to clipping seem like a big policy change.

In any case, I hope you aren't saying that we can't get the regressions reversed until we have a list of things that were actually fixed. Such a list may never be forthcoming.
3

User is offline   LeoD 

  • Duke4.net topic/3513

#15

View PostHendricks266, on 23 January 2020 - 01:59 AM, said:

It would be useful to have a set of test cases for things fixed by the clipping changes so that regressions can be fixed without undoing the fixes.
Go ahead. Regression test cases belong on the developers' desks.

View PostTrooper Dan, on 23 January 2020 - 02:28 AM, said:

In any case, I hope you aren't saying that we can't get the regressions reversed until we have a list of things that were actually fixed. Such a list may never be forthcoming.
Well, using the EDuke32 bug tracking system would be a first step. But considering how this got handled in recent years, I'm not surprised that people aren't very motivated to report issues over there.
0

User is offline   Player Lin 

#16

View PostLeoD, on 23 January 2020 - 12:09 PM, said:

Well, using the EDuke32 bug tracking system would be a first step. But considering how this got handled in recent years, I'm not surprised that people aren't very motivated to report issues over there.


Hmm...

I want to say a funny thing...some years ago, the DooM source port (G)ZDooM devs did tried to use a bug tracking system for bug reports and other things about the whole project(and even for their forum and wiki softwares), but after months later, they decided "screw this, shut the bug tracking system down and put it into archive, we're back to use the forum for bug reporting again" because most of users still tend use the forum for bug reporting, and even some do post tickets on the bug tracking system but the devs rarely/never got any responses for more info or tracking down the bug, so the ZDooM devs just found these problems just defeated the purpose for setting the bug tracker system and went back the original way for bug tracking.


Look at the EDuke32 bug report sub-forum of Duke4.net forum and that's why you see the bug tracker.


I didn't say the bug tracking system is bad idea but since most of users still use this forum when they found bugs in EDuke32 so I won't surprise that happens.

EDIT: Okay, (G)ZDooM forum software do have tagging system for their closed bug reporting&feature suggestion forum but not on Duke4.net forum but still, it didn't changed the fact most people here still use the forum for bug reporting. AND I do this too, I never use the system since I know EDuke32 devs read the forum too.

This post has been edited by Player Lin: 24 January 2020 - 01:03 AM

0

#17

I think I found that bugtracker only a few weeks ago and even then I wasn't sure if it was still in use. It's not linked anywhere on the stickied threads in this forum right?

View PostHendricks266, on 23 January 2020 - 01:59 AM, said:

It would be useful to have a set of test cases for things fixed by the clipping changes so that regressions can be fixed without undoing the fixes.


We are in luck, there exists a map that can serve as such a set of test cases:


Attached File  Glitch_City.zip (78.94K)
Number of downloads: 141

Glitch City requires to player to exploit a large range of glitches of vanilla Duke 3D in order to progress through the map. The video above can serve as a guide on how to progress through it.
In particular, it has a large variety of setups for clipping exploits, and serves as an excellent set of test cases.

I managed to successfully play through the map in its entirety as intended in Rednukem, and can confirm that the port does indeed achieve accuracy to the original game, at least judging from the range of glitches used in this map.

As for eduke32, I compiled the most recent revision on the SVN, including the changes outlined in this thread as well as the one involving the sprite ladders here: https://forums.duke4...post__p__336145

Then I attempted to reproduce each of the glitches used in the video. Here is what I found: (I will denote as "Fixed" any bug that I could not reproduce)
  • [0:01] Clipping into the Safe: Fixed.
  • [0:08] Clipping through the Window Sprite with strafing + crouching: Fixed.
  • [0:14] Clipping to the top of the pillar by holding jump + crouch: Fixed.
  • [0:21] Clipping to the roof by holding jump + crouch: Fixed.
  • [0:26] Using the explosion blast to get pushed through the wall: Fixed. Also cannot get crushed by the wall by simply walking into it and crouching.
  • [0:38] Clipping through 2 SOS areas: Also fixed, and walking into the poster does not crush you anymore.
  • [0:41] Walking into the elevator and crouching to clip up: Fixed.
  • [0:43] Entering a spot too tight for crouching using Jump+Crouch: Fixed, although note that it is now possible to get in from the other side of the vent by holding crouch while jumping, which is this problem here: https://forums.duke4...theater-window/
  • [0:49] Clipping through SOS area by jumping at the bookcase: Fixed.
  • [1:19] + [1:32] Clipping to the top of the building by simply strafe-running into the wall: Fixed.
  • [1:57 - 2:16] Sequence of wall clips using the Steroids speedboost: Fixed.
  • [2:21] Stopping vertical velocity by using the tripmine: Still present as of r8534, but not relevant to the clipping changes.
  • [2:38 - 2:48] Using SR50 to move up the stream: Still possible in r8534, but not a bug.
  • [2:51] Using a single keycard to activate two access panels: Still exists in r8534, but not relevant to the clipping changes.
  • [4:00] Clipping to the top of a rotating sector: Still reproducible in r8534. Happens even without the changes I applied to the getzrange call, i.e. it can be reproduced using r8534 from synthesis.
  • [4:04] Clip through sprite and SOS area: Fixed.
  • [4:24] Using a swinging door to clip into another sector: Fixed.
  • [4:28] Using a tight compartment to clip into another sector: Fixed, the player now gets crushed instead.
  • [4:31] Using a switch through the wall: Still possible in r8534.
  • [4:53] Using a lowering door to clip through a SOS area: Fixed.
  • [6:16] Using the nuke button through the wall: Still possible in r8534.


Any parts I left out weren't really bugs or were repeats of earlier exploits.

Of these, I think the only real clipping bug that is still possible is the one shown at 4:00, where it is possible to clip to the top of a rotating sector (such as the cogs that appear in E1L3).
More importantly however, adding the autocrouch and spriteladder fix did not reintroduce any of the old clipping bugs shown here. This already provides some strong evidence that these changes would not have catastrophic effects.
7

#18

Automatic ducking under sprites is gone as of r8572 and behavior is back to how it was originally. Fixed.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#19

@Doom64hunter

I'd appreciate big time if you'd add a message to your previous bug reports (quite a lot in December...) once they're fixed. Or let a moderator add "[Fixed]" to the topic title.
0

User is offline   Mark 

#20

Good idea but I would wait a week for further community testing before declaring fixed. I have the latest loaded in a number of my new and old projects to test in the next few days.

This post has been edited by Mark: 29 January 2020 - 10:12 AM

0

User is offline   Mark 

#21

I noticed in the startup window that "all supported devices" shows by default even though I chose KB and mouse when run last time.

Mouse look and turn right/left are broke in a project but Mblackwell says its something on our end that will be fixed in the project itself and not a fix needed from eduke32.

I gave a very quick run of a few other older projects and no issues spotted so far.

This post has been edited by Mark: 29 January 2020 - 11:25 AM

0

User is offline   Mark 

#22

I noticed another small quirk. In HHR the player starts the map looking down at the floor. Previous versions look straight ahead. In other projects the glitch isn't there. Thats odd.
0

User is online   Danukem 

  • Duke Plus Developer

#23

View PostMark, on 30 January 2020 - 11:23 AM, said:

I noticed another small quirk. In HHR the player starts the map looking down at the floor. Previous versions look straight ahead. In other projects the glitch isn't there. Thats odd.


I've had the same thing with the latest version at the start of cutscenes. Just use setp[].horiz 100
0

User is offline   Mark 

#24

So far I have tested in Decay, Graveyard, HHR,Suburbs. All 4 start the player on a blocking floor sprite over a sunken green slime textured sector to render them weaponless. But for some reason only Graveyard and HHR start the player looking down. Odd.
0

Share this topic:


Page 1 of 1
  • 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