[Fixed] Ducking behavior
#1 Posted 24 September 2019 - 04:03 AM
#2 Posted 27 September 2019 - 01:19 AM
This post has been edited by Doom64hunter: 27 September 2019 - 01:20 AM
#3 Posted 17 November 2019 - 02:46 PM
#4 Posted 17 November 2019 - 03:40 PM
#5 Posted 17 November 2019 - 03:55 PM
#6 Posted 18 November 2019 - 07:08 AM
#7 Posted 18 November 2019 - 07:14 AM
This post has been edited by Forge: 18 November 2019 - 07:19 AM
#8 Posted 18 November 2019 - 03:07 PM
#9 Posted 18 November 2019 - 08:53 PM
This post has been edited by Forge: 18 November 2019 - 08:54 PM
#10 Posted 21 November 2019 - 09:03 PM
Hendricks266, on 18 November 2019 - 03:07 PM, said:
For example, I've found that Duke often autoducks under the berth in the room at the picture (in L2E7 "Lunar Reactor"):
This post has been edited by Vadim Z: 21 November 2019 - 09:05 PM
#11 Posted 23 December 2019 - 01:35 PM
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
#12 Posted 22 January 2020 - 12:34 PM
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
#13 Posted 23 January 2020 - 01:59 AM
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.
#14 Posted 23 January 2020 - 02:28 AM
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.
#15 Posted 23 January 2020 - 12:09 PM
Hendricks266, on 23 January 2020 - 01:59 AM, said:
Trooper Dan, on 23 January 2020 - 02:28 AM, said:
#16 Posted 24 January 2020 - 12:56 AM
LeoD, on 23 January 2020 - 12:09 PM, said:
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
#17 Posted 24 January 2020 - 03:42 AM
Hendricks266, on 23 January 2020 - 01:59 AM, said:
We are in luck, there exists a map that can serve as such a set of test cases:
Glitch_City.zip (78.94K)
Number of downloads: 143
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.
#18 Posted 29 January 2020 - 04:04 AM
#19 Posted 29 January 2020 - 09:30 AM
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.
#20 Posted 29 January 2020 - 10:12 AM
This post has been edited by Mark: 29 January 2020 - 10:12 AM
#21 Posted 29 January 2020 - 10:50 AM
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
#22 Posted 30 January 2020 - 11:23 AM
#23 Posted 31 January 2020 - 11:26 PM
Mark, on 30 January 2020 - 11:23 AM, said:
I've had the same thing with the latest version at the start of cutscenes. Just use setp[].horiz 100