0001629: Jumping physics broken in Zandronum 2.0

(0007770)
Torr Samaho (administrator)
2013-12-30 18:33

Can you make a demo illustrating the broken behavior?

(0007771)
Edward-san (developer)
2013-12-30 21:52
edited on: 2013-12-30 21:53

Attached two simple jump demos with DOOM2.WAD in map01 which use zandronum 1.2 and zandronum 2.0beta.

(0007777)
Torr Samaho (administrator)
2013-12-31 08:36

Single player demos are not supported in Zandronum and thus usually go out of sync horribly. Did you check that when playing demos the behavior is consistent with what you originally observed when recording them?

(0007781)
Torr Samaho (administrator)
2013-12-31 09:22

In addition to the demos, can somebody go through these unofficial 2.0 beta builds and check in which build the problem first appeared?

(0007789)
Konar6 (reporter)
2013-12-31 12:11

If someone tells me what should I look for on which map (how to reproduce it as quickly as possible), I can get the revision where the problem was introduced.

(0007790)
ibm5155 (reporter)
2013-12-31 12:21

I tested a demo that got out of sync on zandronum 2.0, the weird part is that the first try that I did to run that I got a fatal error, the second try the first map was ok, but the second was doing like parkour + moonwalk at a jumpmaze map lol...
Does the demos need a tracker?
Also I'm going to test that build to check if the demos still crash

(0007794)
Edward-san (developer)
2013-12-31 14:03
edited on: 2013-12-31 14:07

Quote
Single player demos are not supported in Zandronum and thus usually go out of sync horribly. Did you check that when playing demos the behavior is consistent with what you originally observed when recording them?

I checked the demos before uploading and they were working properly when I used 'zandronum -playdemo jump_1.2.lmp' and 'zandronum -playdemo jump_2.0beta.lmp'...

[edit]I tried to record a demo with multiplayer 2.0 beta, but it seems completely broken with constant jittery ... using linux x64, btw

(0007797)
Hypnotoad (reporter)
2013-12-31 15:03

Konar6 and everyone else this is really easy to reproduce. First, in Zandronum 1.2, in Map01 jump off the first ledge at the very beginning and hold jump before hitting the ground to see how it should behave: notice that there is a delay before you jump again.

Now, in 2.0 do the same (jump off and hold jump before hitting the ground), now notice that you jump or "bounce" off the ground immediately on hitting the ground, rather than there being a delay.

(0007799)
Hypnotoad (reporter)
2013-12-31 15:19

Quote
In addition to the demos, can somebody go through these unofficial 2.0 beta builds and check in which build the problem first appeared?

Zandrodev2.0-131026-1630 is where the bug was introduced.

(0007800)
Konar6 (reporter)
2013-12-31 16:20

'https://bitbucket.org/Torr_Samaho/zandronum/commits/3859 [^]'

(0007801)
Edward-san (developer)
2013-12-31 16:36

Does this happen in gzdoom 880?

(0007802)
Hypnotoad (reporter)
2013-12-31 17:36

"- P_ZMovement() temporarily disables jumping after a landing. Don't do this if the jump timer is already running or for short falls (e.g. along the edges of slopes, since the slope floorz calculation is pretty crappy.)"

This is likely the culprit.

(0007806)
Hypnotoad (reporter)
2013-12-31 19:18

Quote
Does this happen in gzdoom 880?

Doesn't happen in GZDoom 1.8.2 if that's what you mean.

(0007810)
Edward-san (developer)
2014-01-01 10:50

No, I mean with this build.

(0007813)
Hypnotoad (reporter)
2014-01-01 16:17

Quote
No, I mean with this build.

Yes, it happens on this build.

(0007814)
Torr Samaho (administrator)
2014-01-01 16:34

Then it is a (G)ZDoom bug. Can somebody check when this was fixed?

(0007815)
Hypnotoad (reporter)
2014-01-01 17:26

Perhaps some of the later revisions mentioned in this thread fix it?'http://zandronum.com/tracker/view.php?id=171 [^]'

(0007820)
Torr Samaho (administrator)
2014-01-01 18:26

Yeah, that's quite possible. ZDoom revision 2238 broke this, 2970+2979 may fix this. I'll have a look.

(0007821)
Hypnotoad (reporter)
2014-01-01 19:03

Incidentally, I am concerned these updated jump physics could still cause possible compatibility issues even when this bug is fixed. Could I request a compat flag, something like comat_oldzdoomjumptimer?

(0007823)
Torr Samaho (administrator)
2014-01-01 21:29

Let's not talk about new compat flags unless we know that we really need them.

(0007861)
Torr Samaho (administrator)
2014-01-03 11:05
edited on: 2014-01-03 11:06

Zandronum's and ZDoom's jump code differ more than I thought. Please check if this fixes the issue. Also please check if the high jump rune and jump pads work as they did in 1.2.

(0007867)
Hypnotoad (reporter)
2014-01-03 15:13
edited on: 2014-01-03 15:23

Okay, I just wrote 5 paragraphs of feedback on this, only to be met with the error "Invalid form security token. This could be caused by a session timeout, or accidentally submitting the form twice.", going back caused my message to be COMPLETELY deleted, this is very VERY annoying.

Suffice to say, the old issue is fixed but there are now other major issues which will break many jumpmaze maps: spring pad zones (skulltag thing) are broken and don't bounce you properly anymore, actor/thing bunnyhopping is totally different - breaking maps, and jump timer behavior is very different, the latter issue may not be a bug but will definitely break many maps from all of the jumpmaze wads (as I found in the testing, e.g. 2 maps were rendered impossible and others were much harder), and possibly affect other wads (e.g. CTF relies on platforming for successful flag runs in many maps, this could affect that). My post that got deleted went into detail about all of these issues after testing over 32 maps in jumpmaze 2, I haven't the heart to recall all of the information I found again but I noted at the end that it would be very complicated to fix each of these issues individually while maintaining the new physics, which is why I strongly recommended again the compat_oldzdoomjumptimer to restore the old jumping code.

edit: forgot about the second part of your post. High jump runes do not seem to be affected. Jump pads - well there are many different ways people create jump pads, however if you mean using spring pad zones, then yes these are broken, holding jump before landing on them does not bounce you anywhere near as high as they used to on the first landing but instead simply bounces you back to where you fell from, this will break various maps.

(0007872)
Torr Samaho (administrator)
2014-01-03 16:49

Quote from Jroc
Okay, I just wrote 5 paragraphs of feedback on this, only to be met with the error "Invalid form security token. This could be caused by a session timeout, or accidentally submitting the form twice.", going back caused my message to be COMPLETELY deleted, this is very VERY annoying.

This is very annoying indeed. Happens to me often, so I just always copy a message to the clipboard before submitting. I think it's a Mantis security feature. Blzut3 should be able to tell you more about this.

Regarding the jumping: AFAIK ZDoom doesn't intend to break existing maps, but nevertheless often does so unintentionally. Instead of adding yet another compat flag, IMHO it would be better to fix this in ZDoom. Are there any ZDoom compatible maps that work as intended in Zandronum 1.2 / ZDoom 2.4.1 and break in Zandronum 2.0 / ZDoom 2.5.0?

(0007873)
Hypnotoad (reporter)
2014-01-03 17:07

At least with jumpmaze maps, the problem is jumpmaze flat out doesn't work in ZDoom (2.4.1 or 2.5.0) so you can't test properly; it has different air movement: jumpmaze relies on compat_limited_airmovement being 0 in zandro, as far as I know there is no way to replicate standard zandronum air movement in Zdoom.

I doubt these changes had any noticeable affect on zdoom compatible maps, jumpmaze is pretty much the only project I know of that relies on very specific jumping code, with the possibility of CTF also (have not tested yet), and jumpmaze is exclusive to ST/Zandro. This is why I think it should be a compat flag for zandro since changing the code again for zdoom probably wont have much use for any zdoom projects.

(0007874)
Torr Samaho (administrator)
2014-01-03 17:40

Let's try something else. Since the jumping behavior introduced in ZDoom revision 2238 is apparently broken, I'll revert this change instead of pulling even more ZDoom changes. Please test if this binary shows the 1.2 jumping behavior again. When we further upgrade our ZDoom base to also include the other jumping changes, we can still introduce a compat flag.

(0007875)
Hypnotoad (reporter)
2014-01-03 17:55

This appears to have restored everything back to normal, thanks.

I think the jumping physics and air movement we have now should be locked in as "skulltag physics", since this is how it has been in skulltag for as long as I can remember (several years, possibly since 2005). So you could have a flag like compat_skulltagphysics which instantly restores the physics to this state, in case there are any changes in the future.

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

Issue History
Date Modified	Username	Field	Change
2013-12-30 16:48	Hypnotoad	New Issue
2013-12-30 18:33	Torr Samaho	Note Added: 0007770
2013-12-30 21:51	Edward-san	File Added: jump_1.2.lmp
2013-12-30 21:51	Edward-san	File Added: jump_2.0beta.lmp
2013-12-30 21:52	Edward-san	Note Added: 0007771
2013-12-30 21:53	Edward-san	Note Edited: 0007771	View Revisions
2013-12-31 08:36	Torr Samaho	Note Added: 0007777
2013-12-31 09:22	Torr Samaho	Note Added: 0007781
2013-12-31 09:23	Torr Samaho	Status	new => feedback
2013-12-31 12:11	Konar6	Note Added: 0007789
2013-12-31 12:21	ibm5155	Note Added: 0007790
2013-12-31 14:03	Edward-san	Note Added: 0007794
2013-12-31 14:07	Edward-san	Note Edited: 0007794	View Revisions
2013-12-31 15:03	Hypnotoad	Note Added: 0007797
2013-12-31 15:03	Hypnotoad	Status	feedback => new
2013-12-31 15:19	Hypnotoad	Note Added: 0007799
2013-12-31 16:20	Konar6	Note Added: 0007800
2013-12-31 16:36	Edward-san	Note Added: 0007801
2013-12-31 17:36	Hypnotoad	Note Added: 0007802
2013-12-31 19:18	Hypnotoad	Note Added: 0007806
2014-01-01 10:50	Edward-san	Note Added: 0007810
2014-01-01 16:17	Hypnotoad	Note Added: 0007813
2014-01-01 16:34	Torr Samaho	Note Added: 0007814
2014-01-01 16:34	Torr Samaho	Status	new => feedback
2014-01-01 16:34	Torr Samaho	Target Version	=> 2.0
2014-01-01 17:26	Hypnotoad	Note Added: 0007815
2014-01-01 17:26	Hypnotoad	Status	feedback => new
2014-01-01 18:26	Torr Samaho	Note Added: 0007820
2014-01-01 18:26	Torr Samaho	Assigned To	=> Torr Samaho
2014-01-01 18:26	Torr Samaho	Status	new => assigned
2014-01-01 19:03	Hypnotoad	Note Added: 0007821
2014-01-01 21:29	Torr Samaho	Note Added: 0007823
2014-01-03 11:05	Torr Samaho	Note Added: 0007861
2014-01-03 11:06	Torr Samaho	Note Edited: 0007861	View Revisions
2014-01-03 11:06	Torr Samaho	Note Revision Dropped: 7861: 0004347
2014-01-03 11:07	Torr Samaho	Status	assigned => needs testing
2014-01-03 15:13	Hypnotoad	Note Added: 0007867
2014-01-03 15:23	Hypnotoad	Note Edited: 0007867	View Revisions
2014-01-03 16:49	Torr Samaho	Note Added: 0007872
2014-01-03 17:07	Hypnotoad	Note Added: 0007873
2014-01-03 17:40	Torr Samaho	Note Added: 0007874
2014-01-03 17:55	Hypnotoad	Note Added: 0007875
2014-02-09 16:38	Qent	Status	needs testing => resolved
2014-02-09 16:38	Qent	Fixed in Version	=> 2.0-beta
2014-02-09 16:38	Qent	Resolution	open => fixed
2015-01-23 04:56	Blzut3	Fixed in Version	2.0-beta => 2.0
2018-09-30 23:05	Blzut3	Status	resolved => closed

Notes
(0007770) Torr Samaho (administrator) 2013-12-30 18:33	Can you make a demo illustrating the broken behavior?

(0007771) Edward-san (developer) 2013-12-30 21:52 edited on: 2013-12-30 21:53	Attached two simple jump demos with DOOM2.WAD in map01 which use zandronum 1.2 and zandronum 2.0beta.

(0007777) Torr Samaho (administrator) 2013-12-31 08:36	Single player demos are not supported in Zandronum and thus usually go out of sync horribly. Did you check that when playing demos the behavior is consistent with what you originally observed when recording them?

(0007781) Torr Samaho (administrator) 2013-12-31 09:22	In addition to the demos, can somebody go through these unofficial 2.0 beta builds and check in which build the problem first appeared?

(0007789) Konar6 (reporter) 2013-12-31 12:11	If someone tells me what should I look for on which map (how to reproduce it as quickly as possible), I can get the revision where the problem was introduced.

(0007790) ibm5155 (reporter) 2013-12-31 12:21	I tested a demo that got out of sync on zandronum 2.0, the weird part is that the first try that I did to run that I got a fatal error, the second try the first map was ok, but the second was doing like parkour + moonwalk at a jumpmaze map lol... Does the demos need a tracker? Also I'm going to test that build to check if the demos still crash

(0007794) Edward-san (developer) 2013-12-31 14:03 edited on: 2013-12-31 14:07	Quote Single player demos are not supported in Zandronum and thus usually go out of sync horribly. Did you check that when playing demos the behavior is consistent with what you originally observed when recording them? I checked the demos before uploading and they were working properly when I used 'zandronum -playdemo jump_1.2.lmp' and 'zandronum -playdemo jump_2.0beta.lmp'... [edit]I tried to record a demo with multiplayer 2.0 beta, but it seems completely broken with constant jittery ... using linux x64, btw

(0007797) Hypnotoad (reporter) 2013-12-31 15:03	Konar6 and everyone else this is really easy to reproduce. First, in Zandronum 1.2, in Map01 jump off the first ledge at the very beginning and hold jump before hitting the ground to see how it should behave: notice that there is a delay before you jump again. Now, in 2.0 do the same (jump off and hold jump before hitting the ground), now notice that you jump or "bounce" off the ground immediately on hitting the ground, rather than there being a delay.

(0007799) Hypnotoad (reporter) 2013-12-31 15:19	Quote In addition to the demos, can somebody go through these unofficial 2.0 beta builds and check in which build the problem first appeared? Zandrodev2.0-131026-1630 is where the bug was introduced.

(0007800) Konar6 (reporter) 2013-12-31 16:20	'https://bitbucket.org/Torr_Samaho/zandronum/commits/3859 [^]'

(0007801) Edward-san (developer) 2013-12-31 16:36	Does this happen in gzdoom 880?

(0007802) Hypnotoad (reporter) 2013-12-31 17:36	"- P_ZMovement() temporarily disables jumping after a landing. Don't do this if the jump timer is already running or for short falls (e.g. along the edges of slopes, since the slope floorz calculation is pretty crappy.)" This is likely the culprit.

(0007806) Hypnotoad (reporter) 2013-12-31 19:18	Quote Does this happen in gzdoom 880? Doesn't happen in GZDoom 1.8.2 if that's what you mean.

(0007810) Edward-san (developer) 2014-01-01 10:50	No, I mean with this build.

(0007813) Hypnotoad (reporter) 2014-01-01 16:17	Quote No, I mean with this build. Yes, it happens on this build.

(0007814) Torr Samaho (administrator) 2014-01-01 16:34	Then it is a (G)ZDoom bug. Can somebody check when this was fixed?

(0007815) Hypnotoad (reporter) 2014-01-01 17:26	Perhaps some of the later revisions mentioned in this thread fix it?'http://zandronum.com/tracker/view.php?id=171 [^]'

(0007820) Torr Samaho (administrator) 2014-01-01 18:26	Yeah, that's quite possible. ZDoom revision 2238 broke this, 2970+2979 may fix this. I'll have a look.

(0007821) Hypnotoad (reporter) 2014-01-01 19:03	Incidentally, I am concerned these updated jump physics could still cause possible compatibility issues even when this bug is fixed. Could I request a compat flag, something like comat_oldzdoomjumptimer?

(0007823) Torr Samaho (administrator) 2014-01-01 21:29	Let's not talk about new compat flags unless we know that we really need them.

(0007861) Torr Samaho (administrator) 2014-01-03 11:05 edited on: 2014-01-03 11:06	Zandronum's and ZDoom's jump code differ more than I thought. Please check if this fixes the issue. Also please check if the high jump rune and jump pads work as they did in 1.2.

(0007867) Hypnotoad (reporter) 2014-01-03 15:13 edited on: 2014-01-03 15:23	Okay, I just wrote 5 paragraphs of feedback on this, only to be met with the error "Invalid form security token. This could be caused by a session timeout, or accidentally submitting the form twice.", going back caused my message to be COMPLETELY deleted, this is very VERY annoying. Suffice to say, the old issue is fixed but there are now other major issues which will break many jumpmaze maps: spring pad zones (skulltag thing) are broken and don't bounce you properly anymore, actor/thing bunnyhopping is totally different - breaking maps, and jump timer behavior is very different, the latter issue may not be a bug but will definitely break many maps from all of the jumpmaze wads (as I found in the testing, e.g. 2 maps were rendered impossible and others were much harder), and possibly affect other wads (e.g. CTF relies on platforming for successful flag runs in many maps, this could affect that). My post that got deleted went into detail about all of these issues after testing over 32 maps in jumpmaze 2, I haven't the heart to recall all of the information I found again but I noted at the end that it would be very complicated to fix each of these issues individually while maintaining the new physics, which is why I strongly recommended again the compat_oldzdoomjumptimer to restore the old jumping code. edit: forgot about the second part of your post. High jump runes do not seem to be affected. Jump pads - well there are many different ways people create jump pads, however if you mean using spring pad zones, then yes these are broken, holding jump before landing on them does not bounce you anywhere near as high as they used to on the first landing but instead simply bounces you back to where you fell from, this will break various maps.

(0007872) Torr Samaho (administrator) 2014-01-03 16:49	Quote from Jroc Okay, I just wrote 5 paragraphs of feedback on this, only to be met with the error "Invalid form security token. This could be caused by a session timeout, or accidentally submitting the form twice.", going back caused my message to be COMPLETELY deleted, this is very VERY annoying. This is very annoying indeed. Happens to me often, so I just always copy a message to the clipboard before submitting. I think it's a Mantis security feature. Blzut3 should be able to tell you more about this. Regarding the jumping: AFAIK ZDoom doesn't intend to break existing maps, but nevertheless often does so unintentionally. Instead of adding yet another compat flag, IMHO it would be better to fix this in ZDoom. Are there any ZDoom compatible maps that work as intended in Zandronum 1.2 / ZDoom 2.4.1 and break in Zandronum 2.0 / ZDoom 2.5.0?

(0007873) Hypnotoad (reporter) 2014-01-03 17:07	At least with jumpmaze maps, the problem is jumpmaze flat out doesn't work in ZDoom (2.4.1 or 2.5.0) so you can't test properly; it has different air movement: jumpmaze relies on compat_limited_airmovement being 0 in zandro, as far as I know there is no way to replicate standard zandronum air movement in Zdoom. I doubt these changes had any noticeable affect on zdoom compatible maps, jumpmaze is pretty much the only project I know of that relies on very specific jumping code, with the possibility of CTF also (have not tested yet), and jumpmaze is exclusive to ST/Zandro. This is why I think it should be a compat flag for zandro since changing the code again for zdoom probably wont have much use for any zdoom projects.

(0007874) Torr Samaho (administrator) 2014-01-03 17:40	Let's try something else. Since the jumping behavior introduced in ZDoom revision 2238 is apparently broken, I'll revert this change instead of pulling even more ZDoom changes. Please test if this binary shows the 1.2 jumping behavior again. When we further upgrade our ZDoom base to also include the other jumping changes, we can still introduce a compat flag.

(0007875) Hypnotoad (reporter) 2014-01-03 17:55	This appears to have restored everything back to normal, thanks. I think the jumping physics and air movement we have now should be locked in as "skulltag physics", since this is how it has been in skulltag for as long as I can remember (several years, possibly since 2005). So you could have a flag like compat_skulltagphysics which instantly restores the physics to this state, in case there are any changes in the future.

Relationships