Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000171Zandronum[All Projects] Suggestionpublic2010-11-04 14:472018-09-30 21:41
Reporterunknownna 
Assigned ToTorr Samaho 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.0-beta 
Target Version3.0Fixed in Version3.0 
Summary0000171: backport fixed and improved jumping behavior and a fix in "P_ZMovement"
DescriptionThis is something that I would really like to see ported to 98D if possible. It truly allows for a more precise and refined jumping technique, which is very good for the multiplayer scene.
Additional Information'http://zdoom.org/Changelog/2238/files [^]' - I believe the changes started here.
'http://zdoom.org/Changelog/2970/files [^]'
'http://zdoom.org/Changelog/2971/files [^]'
'http://zdoom.org/Changelog/2979/files [^]'
Attached Files? file icon dsoof_comparison_test_01.wad [^] (1,525 bytes) 2011-05-05 15:02
png file icon Screenshot_Doom_20160202_081708.png [^] (103,869 bytes) 2016-02-02 07:30


png file icon Screenshot_Doom_20160202_081911.png [^] (203,234 bytes) 2016-02-02 07:30


? file icon prdict1.wad [^] (15,998 bytes) 2016-02-14 18:34
diff file icon predFixTest.diff [^] (399 bytes) 2016-04-03 16:44 [Show Content]

- Relationships
related to 0003459resolvedLeonard Prediction regression and jitter in 3.0 when landing on the ledge of bridge things 
child of 0002172closedTorr Samaho Upgrade GZDoom base to 1.8.6 

-  Notes
User avatar (0001013)
unknownna (updater)
2011-02-07 14:26

Would it be too much to ask for a test binary with the fix in P_ZMovement? It should only be a one-digit fix. If I am not mistaken, the DSOOF sound will be played when landing from a certain height (similar to the P_NoWayTraverse fix). This should also make the player feel more like the Vanilla Doom player.

'http://zdoom.org/Changelog/2971/files [^]' - Fixed: The minimum velocity for player landing in effects in P_ZMovement should be -8, not -9.

From:

const fixed_t minvel = -9*FRACUNIT; // landing speed from a jump with normal gravity


To:

const fixed_t minvel = -8*FRACUNIT; // landing speed from a jump with normal gravity
User avatar (0001171)
Edward-san (developer)
2011-03-19 19:01

I wonder if these changes would affect some mods like Jumpmaze or Jumpix...
User avatar (0001555)
unknownna (updater)
2011-05-05 15:02

> If I am not mistaken, the DSOOF sound will be played when landing from a certain height.

Skulltag : 45 map units
ZDoom/Vanilla : 36 map units
User avatar (0001733)
Torr Samaho (administrator)
2011-05-22 15:29

This contains the "9 -> 8" change. Does it do what you hope it would?
User avatar (0001736)
unknownna (updater)
2011-05-22 18:55

> Does it do what you hope it would?

Yes. Thank you.
User avatar (0012078)
Hypnotoad (reporter)
2015-04-09 19:46

Seeing as these new jump physics will likely break backwards compatibility with certain projects, I'm hoping there could be a compatibility flag to restore the classic skulltag physics, as I mentioned here:'http://zandronum.com/tracker/view.php?id=1629#c7875 [^]'
User avatar (0012218)
Hypnotoad (reporter)
2015-05-09 20:01

After testing, it appears that the jumping has not been changed noticeably after all, at least nothing I feared from here has happened:'http://zandronum.com/tracker/view.php?id=1629#c7867 [^]'

Is it possible I can get details of what has been changed in 3.0, if anything?
User avatar (0012229)
Leonard (developer)
2015-05-10 12:27
edited on: 2015-05-10 12:38

This is because Torr kept the old behavior and didn't port any of the changes concerning jumping physics.
I think a compatibility flag is a good idea since the jumping physics were heavily altered, for example in zdoom 2.6.0 jumping while falling down the stairs of doom2 MAP01 at the start will always be succesful as opposed to zandronum.

User avatar (0012258)
StrikerMan780 (reporter)
2015-05-12 09:09

I think I prefer the new physics, the old physics weren't very responsive when running on rough terrain.
User avatar (0013776)
Ru5tK1ng (updater)
2015-11-11 00:38

So I'm assuming that the new physics are still not ported?
User avatar (0013813)
Torr Samaho (administrator)
2015-11-15 20:48

I didn't touch this yet. So, are there many people who'd like to have ZDoom's jump changes?
User avatar (0013892)
Torr Samaho (administrator)
2015-11-28 10:41

Can I interpret no answer as no interest in ZDoom's jump changes?
User avatar (0013894)
Edward-san (developer)
2015-11-28 14:34

I'm personally interested on it as a compatibility option, if it might help.
User avatar (0013895)
Leonard (developer)
2015-11-28 16:27

Yes, have the new jump physics but leave the old one as a compatibility option.
User avatar (0013962)
StrikerMan780 (reporter)
2015-12-11 22:14
edited on: 2015-12-11 22:18

I say use the new code and ditch the old. The old mechanics are kind of crap (especially on slopes), no sense leaving old cruft if it has no benefit.

User avatar (0013963)
Hypnotoad (reporter)
2015-12-11 23:35

Many older skulltag projects, most notably jumpmaze, rely on the current jumping physics, so I definitely think the current physics should remain, at least as a compatibility option (my idea was for compat_skulltagphysics).
User avatar (0013970)
Dusk (developer)
2015-12-13 01:49
edited on: 2015-12-13 01:50

I'm beginning to feel that we should backport the new jumping physics and, if possible, compatflag it to compat_limitedairmovement, which would then be inverted. So the compatflag could be used to toggle between new zdoom jumping style and the skulltag style which jumpmaze relies on.

The less delta in something this crucial the better in the long run.

User avatar (0014143)
StrikerMan780 (reporter)
2016-01-21 14:14
edited on: 2016-01-21 14:15

Basically make ZDoom behavior default, and then have old ST/Zan behavior a compatflag? Sounds like an idea. It would help reduce unpredictable movement behavior between ZDoom and Zan for mods.

User avatar (0014255)
Torr Samaho (administrator)
2016-01-30 16:26

Quote from Dusk
I'm beginning to feel that we should backport the new jumping physics and, if possible, compatflag it to compat_limitedairmovement, which would then be inverted.

For full backwards compatibility we need to be able to restore Skulltag's jumping behavior with and without compat_limitedairmovement set, so we can't use a single flag for that. We can consider inverting compat_limitedairmovement though so that the default behavior is as close to ZDoom as possible.

I gave this a first shot, but I'm not sure whether I didn't overlook anything. This binary should have the ZDoom jumping behavior introduced in ZDoom SVN revision 2790. The new flag compat_skulltagjumping allows to switch back to the jumping from Skulltag. Please test thoroughly.
User avatar (0014257)
Frits (reporter)
2016-01-30 17:22

Yes to new jumping physics! The old physics are just so gimmicky. Everyone knows how to deal with them now but that doesn't mean it should stop these improvements.
User avatar (0014265)
cobalt (updater)
2016-01-31 20:37

Issue addressed by commit ff67df887380: The ZDoom jumping physics from ZDoom SVN revision 2790 are now used. The old jumping behavior known from Skulltag can be restored with the new CVAR compat_skulltagjumping (addresses 171).
Committed by Benjamin Berkels [Torr Samaho] on Wednesday 31 December 1969 23:59:57

Changes in files:

 docs/zandronum-history.txt | 1 +
 src/d_main.cpp | 1 +
 src/doomdef.h | 2 ++
 src/p_user.cpp | 8 +++++---
 4 files changed, 9 insertions(+), 3 deletions(-)

User avatar (0014273)
unknownna (updater)
2016-01-31 23:42
edited on: 2016-01-31 23:59

As far as I know, the intended difference between the new and old jumping behavior is that with the new behavior you don't have to wait several tics before being allowed to jump when moving/dropping down small heights, unless a DSOOF grunting sound is made.

With the old (current) behavior you can't jump when running down small steps for instance. This has been corrected with the new behavior.

ZDoom 2.5.0 was supposed to have this new behavior, but it was bugged and only got fixed in 2.6.0, hence the confusion when Zandronum updated to ZDoom 2.5.0, inheriting the bugged behavior.

Regarding the testing binary, I notice no difference at all between compat_skulltagjumping 1 and 0. The forced delay when running down small steps is always there regardless of whether the flag is enabled or not. Upon further testing, it seems that compat_skulltagjumping seemingly fixes the issue with the spring pad zones below, so to me it seems to be independent from what I assumed the flag would do. Nevertheless, compat_skulltagjumping 0 does not make it work fully like 2.6.0 at the moment since you're still forced to wait before being allowed to jump when running down small steps.

I noticed that ZandroDev2.0-JumpFixTest.7z posted in'http://zandronum.com/tracker/view.php?id=1629#c7861 [^]' seems to contain the fixed 2.6.0 behavior, however, according to Hypnotoad it broke some things, most notably spring pad zones.

* ZDoom 2.5.0 was supposed to improve the jumping behavior and allow you to jump when running down steps, however, it was broken.
* ZDoom 2.6.0 fixed the wrong 2.5.0 behavior. You can now jump when running down steps. This apparently broke spring pad zones in Skulltag.
* compat_skulltagjumping fixes what ZDoom 2.6.0 broke, but you still can't jump when running down small steps, regardless of whether the flag is enabled or not.

User avatar (0014278)
Torr Samaho (administrator)
2016-02-01 07:13

Thanks for the detailed analysis! After further going through the code, I noticed that Zandronum was still missing the ZDoom 2.5.0 part of the jumping change. Back then I removed this, because it broke jumpmaze wads.

Please check if this binary has the intended behavior.
User avatar (0014285)
unknownna (updater)
2016-02-01 12:33

It fixed the behavior, however, thinking about it a bit more I'm starting to wonder whether it would be possible to have the old spring pad zone behavior in addition to the lack of forced delay when jumping while moving down small steps. Wouldn't it be in the interest of Jumpmaze players to have as much freedom of movement as possible?

Right now compat_skulltagjumping restores both the old spring pad behavior and the forced delay when jumping while running down small steps. This means that while spring pads now work in the old way when you enable compat_skulltagjumping, you lose the benefit of having no forced delay when attempting to jump while running down steps and/or on uneven terrain.

There's also the ZDoom 1.23b33 crowd that might want to have the forced delay due to sheer familiarity with the old behavior.

* Spring pad zones need a compatibility option (compat_skulltagjumping) so that they bounce you properly.
* The delay when running down steps might need a separate compatibility option (compat_oldzdoomjumping?) for ZDoom 1.23b33 familiarity. If I happened to be very familiar with ZDaemon for instance, I would've potentially been thrown off by the new behavior despite it being better.

By having 2 compatibility flags, one for the spring pads and one for the delay when running down steps you could have the best of both worlds and please all parts of the community, both old and new. This is just an idea though, I'll let you and the community decide what to do.
User avatar (0014286)
Torr Samaho (administrator)
2016-02-01 18:14

If I read things like this, I think we should try to limit the amount of compat flags. If there really is demand though, adding more flags is straightforward though.

Quote from unknownna
* Spring pad zones need a compatibility option (compat_skulltagjumping) so that they bounce you properly.

Can you elaborate in which sense the spring pads work improperly now? I just briefly tested d2dm6 and the spring pads seemed fine.
User avatar (0014291)
unknownna (updater)
2016-02-01 22:33
edited on: 2016-02-02 06:00

Quote from Torr Samaho
Can you elaborate in which sense the spring pads work improperly now? I just briefly tested d2dm6 and the spring pads seemed fine.

Using compat_skulltagjumping makes the spring pads work fine as far as I can tell from my brief testing. I didn't mean to give the impression of the flag not working properly.

Quote from Torr Samaho
If I read things like this, I think we should try to limit the amount of compat flags. If there really is demand though, adding more flags is straightforward though.

Understood, but my main concern is catering to the players that are familiar with old ZDoom/ZDaemon/Odamex with regards to player movement in particular. We've already had our fair share of "hey, make Zandronum work like ZDoom 1.23b33 (compat_oldzdoomzmovement/compat_explosionthrust)", so I thought it'd be nice to consider the option of being able to toggle the delay at will since it affects how you perceive the "physics" so to speak. By having the option of toggling the delay, Zandronum could still be made to feel like the other ports. Like I said earlier though, it's up to you to decide. It'd also be nice if the CTF and Jumpmaze crowds would give their input on this matter before doing anything though.

User avatar (0014295)
Torr Samaho (administrator)
2016-02-02 07:02

Quote from unknownna
Using compat_skulltagjumping makes the spring pads work fine as far as I can tell from my brief testing. I didn't mean to give the impression of the flag not working properly.

Sorry, for the confusion. I meant what is the problem with spring pads in case "compat_skulltagjumping 0"? They seem to work for me at first glance, i.e. I can navigate through d2dm6 without problems and also get the soul sphere that is floating high in the air.
User avatar (0014298)
unknownna (updater)
2016-02-02 07:33

With "compat_skulltagjumping 0" the spring pads don't bounce you up as high when you land on them from a high height while holding +jump.
User avatar (0014299)
Dusk (developer)
2016-02-02 10:36
edited on: 2016-02-02 10:38

Quote from "Torr Samaho"

If I read things like this...

I don't think that the persistence of ARG members to use old versions is a proper argument for development. They've not only done this with the engine, but also with CTF wads (they insist on stctfmp.wad) and they screw over everybody else doing so.

Nevertheless, I find that we shouldn't introduce yet another compatibility option with this. If Jumpmaze wishes to take advantage of the new jumping behavior it is free to adjust their maps to do so. The point of the compatibility flag is to let maps use the old behavior if they really need it. We don't need a CVar for everything, and the more we add, the more flags people need to remember and the more confusion we will get,

User avatar (0014301)
Torr Samaho (administrator)
2016-02-02 19:23

Quote from unknownna
With "compat_skulltagjumping 0" the spring pads don't bounce you up as high when you land on them from a high height while holding +jump.

I see. Would you say that the new behavior is still reasonable, just different from what we had before, or is it definitely broken? In the latter case, I could try to fix the jump pads for "compat_skulltagjumping 0", while keeping the ZDoom jumping behavior for anything that doesn't involve jump pads.

Quote from Dusk
I don't think that the persistence of ARG members to use old versions is a proper argument for development.

That's just the first example I found. I also vividly remember the guy who claimed that Skulltag is better for old school stuff and wanted to resurrect Skulltag as old school port. Anyway, these example may not be representative for the majority of players.
User avatar (0014303)
cobalt (updater)
2016-02-02 19:40

Issue addressed by commit 58a878de1d74: Fixed: "compat_skulltagjumping 0" didn't activate the jumping behavior change from ZDoom SVN revision 2238 (addresses 171).
Committed by Benjamin Berkels [Torr Samaho] on Wednesday 31 December 1969 23:59:57

Changes in files:

 docs/zandronum-history.txt | 2 +-
 src/p_mobj.cpp | 7 +++----
 2 files changed, 4 insertions(+), 5 deletions(-)

User avatar (0014304)
unknownna (updater)
2016-02-03 05:42

Quote from Torr Samaho
Would you say that the new behavior is still reasonable, just different from what we had before, or is it definitely broken?

I'd say that the behavior is more different than bugged since the new behavior doesn't count the first +jump when you land on it from a high height while holding +jump. If you don't hold +jump when landing on it from a high height, compat_skulltagjumping 0 and compat_skulltagjumping 1 both seemingly bounce you to the same height.

Quote from Torr Samaho
That's just the first example I found. I also vividly remember the guy who claimed that Skulltag is better for old school stuff and wanted to resurrect Skulltag as old school port. Anyway, these example may not be representative for the majority of players.

I'd say that you should concern yourself more with maintaining ZDoom 1.23b33 familiarity for historical reasons.
User avatar (0014441)
Leonard (developer)
2016-02-14 18:33

This commit broke the player prediction.

Here are the steps to reproduce the desync:

-host the test map I attached (prdict1.wad) on a server
-join said server with an emulated ping of 200 or more
-bounce off of the tech pillars and fall to the ground below
-notice the jitter caused by the misprediction

You can also notice the misprediction by running into the stairs on the side moderately fast and holding +jump the whole time, the same sort of desync will occur at the top.
User avatar (0014663)
Torr Samaho (administrator)
2016-04-03 16:51

Can you check if this build (based on the attached attached) improves the behavior?
User avatar (0014703)
Leonard (developer)
2016-04-12 19:52

That seems to have fixed the issue completely for me, I'm unable to reproduce the misprediction.
User avatar (0014716)
cobalt (updater)
2016-04-15 06:29

Issue addressed by commit c4104ac76a05: Fixed a problem with the client side prediction with the new ZDoom jumping physics (addresses 171).
Committed by Benjamin Berkels [Torr Samaho] on Wednesday 31 December 1969 23:59:57

Changes in files:

 src/cl_pred.cpp | 1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

User avatar (0014875)
Ru5tK1ng (updater)
2016-05-12 03:58
edited on: 2016-07-15 15:16

Has anyone ran into any desyncs with the above fix?

Edit:

Behavior with the predictfix build and the latest 3.0 seemed the same.


Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: Leonard Frits
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2010-11-04 14:47 unknownna New Issue
2011-02-07 14:26 unknownna Note Added: 0001013
2011-03-19 19:01 Edward-san Note Added: 0001171
2011-03-19 20:17 unknownna Priority high => normal
2011-05-05 15:02 unknownna File Added: dsoof_comparison_test_01.wad
2011-05-05 15:02 unknownna Note Added: 0001555
2011-05-22 15:29 Torr Samaho Note Added: 0001733
2011-05-22 15:58 Torr Samaho Assigned To => Torr Samaho
2011-05-22 15:58 Torr Samaho Status new => feedback
2011-05-22 18:55 unknownna Note Added: 0001736
2011-05-22 18:55 unknownna Status feedback => assigned
2015-04-04 20:19 Arco Relationship added child of 0002172
2015-04-05 08:12 WaTaKiD Target Version => 3.0
2015-04-09 19:46 Hypnotoad Note Added: 0012078
2015-05-09 13:59 Dusk Status assigned => needs testing
2015-05-09 20:01 Hypnotoad Note Added: 0012218
2015-05-10 12:27 Leonard Note Added: 0012229
2015-05-10 12:38 Leonard Note Edited: 0012229 View Revisions
2015-05-12 09:09 StrikerMan780 Note Added: 0012258
2015-11-11 00:38 Ru5tK1ng Note Added: 0013776
2015-11-11 00:38 Ru5tK1ng Status needs testing => feedback
2015-11-15 20:48 Torr Samaho Note Added: 0013813
2015-11-28 10:41 Torr Samaho Note Added: 0013892
2015-11-28 14:34 Edward-san Note Added: 0013894
2015-11-28 16:27 Leonard Note Added: 0013895
2015-12-11 22:14 StrikerMan780 Note Added: 0013962
2015-12-11 22:15 StrikerMan780 Note Edited: 0013962 View Revisions
2015-12-11 22:18 StrikerMan780 Note Edited: 0013962 View Revisions
2015-12-11 23:35 Hypnotoad Note Added: 0013963
2015-12-13 01:49 Dusk Note Added: 0013970
2015-12-13 01:50 Dusk Note Edited: 0013970 View Revisions
2015-12-13 01:50 Dusk Note Edited: 0013970 View Revisions
2016-01-21 14:14 StrikerMan780 Note Added: 0014143
2016-01-21 14:15 StrikerMan780 Note Edited: 0014143 View Revisions
2016-01-30 16:26 Torr Samaho Note Added: 0014255
2016-01-30 16:45 Dusk Status feedback => needs testing
2016-01-30 17:22 Frits Note Added: 0014257
2016-01-31 20:37 cobalt Note Added: 0014265
2016-01-31 23:42 unknownna Note Added: 0014273
2016-01-31 23:43 unknownna Note Edited: 0014273 View Revisions
2016-01-31 23:59 unknownna Note Edited: 0014273 View Revisions
2016-02-01 07:13 Torr Samaho Note Added: 0014278
2016-02-01 12:33 unknownna Note Added: 0014285
2016-02-01 18:14 Torr Samaho Note Added: 0014286
2016-02-01 22:33 unknownna Note Added: 0014291
2016-02-02 00:03 unknownna Note Edited: 0014291 View Revisions
2016-02-02 05:58 unknownna Note Edited: 0014291 View Revisions
2016-02-02 06:00 unknownna Note Edited: 0014291 View Revisions
2016-02-02 07:02 Torr Samaho Note Added: 0014295
2016-02-02 07:30 unknownna File Added: Screenshot_Doom_20160202_081708.png
2016-02-02 07:30 unknownna File Added: Screenshot_Doom_20160202_081911.png
2016-02-02 07:33 unknownna Note Added: 0014298
2016-02-02 10:36 Dusk Note Added: 0014299
2016-02-02 10:38 Dusk Note Edited: 0014299 View Revisions
2016-02-02 19:23 Torr Samaho Note Added: 0014301
2016-02-02 19:40 cobalt Note Added: 0014303
2016-02-03 05:42 unknownna Note Added: 0014304
2016-02-14 18:33 Leonard Note Added: 0014441
2016-02-14 18:34 Leonard File Added: prdict1.wad
2016-03-01 22:26 Ru5tK1ng Status needs testing => feedback
2016-04-03 16:44 Torr Samaho File Added: predFixTest.diff
2016-04-03 16:51 Torr Samaho Note Added: 0014663
2016-04-10 19:20 Torr Samaho Status feedback => needs testing
2016-04-12 19:52 Leonard Note Added: 0014703
2016-04-15 06:29 cobalt Note Added: 0014716
2016-05-12 03:58 Ru5tK1ng Note Added: 0014875
2016-07-15 15:16 Ru5tK1ng Note Edited: 0014875 View Revisions
2016-07-15 15:16 Ru5tK1ng Status needs testing => resolved
2016-07-15 15:16 Ru5tK1ng Resolution open => fixed
2016-07-15 15:16 Ru5tK1ng Product Version => 3.0-beta
2016-07-15 15:16 Ru5tK1ng Fixed in Version => 3.0
2018-08-23 07:18 unknownna Relationship added related to 0003459
2018-09-30 21:41 Blzut3 Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker