|
Notes |
|
|
|
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 |
|
|
|
|
|
I wonder if these changes would affect some mods like Jumpmaze or Jumpix... |
|
|
|
|
> 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 |
|
|
|
|
|
This contains the "9 -> 8" change. Does it do what you hope it would? |
|
|
|
|
> Does it do what you hope it would?
Yes. Thank you. |
|
|
|
|
|
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 [^]' |
|
|
|
|
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? |
|
|
|
(0012229)
|
|
Leonard
|
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.
|
|
|
|
|
|
I think I prefer the new physics, the old physics weren't very responsive when running on rough terrain. |
|
|
|
|
|
So I'm assuming that the new physics are still not ported? |
|
|
|
|
|
I didn't touch this yet. So, are there many people who'd like to have ZDoom's jump changes? |
|
|
|
|
|
Can I interpret no answer as no interest in ZDoom's jump changes? |
|
|
|
|
|
I'm personally interested on it as a compatibility option, if it might help. |
|
|
|
|
|
Yes, have the new jump physics but leave the old one as a compatibility option. |
|
|
|
(0013962)
|
|
StrikerMan780
|
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.
|
|
|
|
|
|
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). |
|
|
|
(0013970)
|
|
Dusk
|
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.
|
|
|
|
(0014143)
|
|
StrikerMan780
|
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.
|
|
|
|
|
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. |
|
|
|
(0014257)
|
|
Frits
|
|
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. |
|
|
|
(0014265)
|
|
cobalt
|
|
2016-01-31 20:37
|
|
|
|
|
(0014273)
|
|
unknownna
|
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.
|
|
|
|
|
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. |
|
|
|
|
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. |
|
|
|
|
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. |
|
|
|
(0014291)
|
|
unknownna
|
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.
|
|
|
|
|
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. |
|
|
|
|
|
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. |
|
|
|
(0014299)
|
|
Dusk
|
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,
|
|
|
|
|
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. |
|
|
|
(0014303)
|
|
cobalt
|
|
2016-02-02 19:40
|
|
|
|
|
|
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. |
|
|
|
|
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. |
|
|
|
|
|
Can you check if this build (based on the attached attached) improves the behavior? |
|
|
|
|
|
That seems to have fixed the issue completely for me, I'm unable to reproduce the misprediction. |
|
|
|
(0014716)
|
|
cobalt
|
|
2016-04-15 06:29
|
|
|
|
|
(0014875)
|
|
Ru5tK1ng
|
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.
|
|
dsoof_comparison_test_01.wad (1,525) 2011-05-05 15:02
Screenshot_Doom_20160202_081708.png (103,869) 2016-02-02 07:30
predFixTest.diff (399) 2016-04-03 16:44