0000101: backport compatibility flags update from ZDoom r2340, r2341 | COMPAT_HITSCAN, COMPAT_WALLRUN

Notes
(0000342) unknownna (updater) 2010-10-11 21:32	Note: I don't expect any of these backporting suggestions to make it into 98d.

(0000343) TIHan (reporter) 2010-10-11 22:37	There have been quite a bit of backport requests lately. IMO, I would wait a bit until Skulltag starts updating the actual ZDoom revisions to a certain point, preferrably after r2000s.

(0000926) unknownna (updater) 2011-02-02 13:13 edited on: 2011-02-03 13:54	Since you've been adding more Vanilla compatibility to Skulltag lately, would it be possible to backport these compat flags? The compat_hitscan flag would be a great addition to the compat_oldrandom flag. 0000192 is also a duplicate of this and 0000031.

(0004518) ZzZombo (reporter) 2012-08-30 14:13	Zandronum has these flags. Close the ticket please.

(0004527) Torr Samaho (administrator) 2012-08-30 20:27	Zandronum has compat_hitscan?

(0004529) ZzZombo (reporter) 2012-08-31 01:54	compat_hitscan was confused with compat_oldrandom, sorry.

(0005038) AlexMax (developer) 2012-10-07 17:02	What exactly does compat_hitscan do? Is this the X-Doom tweak described in this post, because if so compat_oldrandom is a superior implementation. 'http://www.altdeath.com/fluxbb/viewtopic.php?pid=135#p135 [^]'

(0005039) AlexMax (developer) 2012-10-07 17:03	I linked the wrong post. Here is the correct one. 'http://www.altdeath.com/fluxbb/viewtopic.php?pid=141#p141 [^]'

(0005049) unknownna (updater) 2012-10-08 00:33	Quote from AlexMax What exactly does compat_hitscan do? 'http://www.zdoom.org/wiki/CVARs:Configuration [^]' Quote from ZDoom Wiki ZDoom fixed a couple of bugs in the hitscan trace routines, which had the effect of making hitscan attacks more efficient overall as in the original code they would sometimes "magically" miss. The first is that it is a monster's cross-section, rather than its bounding box, that is used to check for impact; this makes attacks with a limited range (especially player melee attacks) unlikely to hit very wide monsters. The second is the blockmap bug: if an actor crosses block boundaries and its center is in a different block than the one in which the impact happens, then there is no collision at all, letting attacks pass through it harmlessly. If enabled, this option restores the original, flawed behavior.

(0005883) StrikerMan780 (reporter) 2013-01-31 03:26	I'd like to see that get backported, as Zandronum still has the Blockmap bug with hitscans, and It's a major problem in one of my projects, due to some of the maps being huge.

(0005887) Torr Samaho (administrator) 2013-01-31 06:21	Quote from StrikerMan780 as Zandronum still has the Blockmap bug with hitscans Just to clarify: As far as I understand this flag, compat_hitscan does not fix the blockmap bug, but restores the blockmap bug Vanilla Doom had. Overall, enabling the flag will make some hits miss that would have it. Having this clarified, is this what the supporters want? Can somebody who is very familiar with the Vanilla Doom feel confirm that enabling the flag in ZDoom improves the behavior?

(0005899) StrikerMan780 (reporter) 2013-01-31 22:49	I just thought it would imply that the Fixed hitscan/blockmap behavior would be backported along with this, as that's what the compatflag disables.

(0005900) Ru5tK1ng (updater) 2013-01-31 23:58 edited on: 2013-02-01 00:00	Quote Just to clarify: As far as I understand this flag, compat_hitscan does not fix the blockmap bug, but restores the blockmap bug Vanilla Doom had. Overall, enabling the flag will make some hits miss that would have it. I was under the impression that there was more to this flag than the blockmap bug. Aside from the blockmap fix, what other changes occurred in the hitscan code? What other changes to the hitscan code or weapon behavior would this compatflag induce? I suppose it is worth a shot to have a knowledgeable player(s) observe the feel of the flag in ZDoom.

(0005902) Torr Samaho (administrator) 2013-02-01 07:04	Quote from StrikerMan780 I just thought it would imply that the Fixed hitscan/blockmap behavior would be backported along with this, as that's what the compatflag disables. As far as I can tell Zandronum already has this fix: compat_hitscan only affects FPathTraverse::AddThingIntercepts and in case compat_hitscan is false, Zandronum's implementation of this function is identical to ZDoom. Quote from Ru5tK1ng What other changes to the hitscan code or weapon behavior would this compatflag induce? 0000101:0005049 is a detailed description of the effects. Quote from Ru5tK1ng I suppose it is worth a shot to have a knowledgeable player(s) observe the feel of the flag in ZDoom. Yeah, that would be great.

(0005908) Ru5tK1ng (updater) 2013-02-02 06:09 edited on: 2013-02-02 06:12	After testing with HumanBones, it's been concluded that compat_hitscan does not alter the weapon behavior in any significant way other than introducing the blockmap bug. From our findings, the ZDoom ssg is inherently stronger when compared to Zandronum. Perhaps there is something else within the code that affects the weapon behavior aside from RNG? In any case, since the use of this flag has been fully understood and cleared up, implementation should occur with the ZDoom overhaul planned for 2.0 as currently planned.

(0007694) Qent (updater) 2013-12-11 00:02 edited on: 2014-02-09 18:41	Both compat_hitscan effects work as advertised. What should be the effects of the wallrunning changes? It has something to do with diagonal walls. EDIT: Wallrunning against diagonal walls feels more jittery in 2.0 and vanilla than in 1.2.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	unknownna Ru5tK1ng Fluffles Razgriz HumanBones fuleco Ivan Soul Mobius MassVC Keo ThatsJustPrime bluewizard
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2010-10-11 21:11	unknownna	New Issue
2010-10-11 21:32	unknownna	Note Added: 0000342
2010-10-11 22:37	TIHan	Note Added: 0000343
2011-02-02 13:13	unknownna	Note Added: 0000926
2011-02-02 13:17	unknownna	Note Edited: 0000926	View Revisions
2011-02-02 13:17	unknownna	Note Edited: 0000926	View Revisions
2011-02-03 13:54	unknownna	Note Edited: 0000926	View Revisions
2011-02-18 20:52	unknownna	Relationship added	has duplicate 0000192
2012-08-30 14:13	ZzZombo	Note Added: 0004518
2012-08-30 20:27	Torr Samaho	Note Added: 0004527
2012-08-31 01:54	ZzZombo	Note Added: 0004529
2012-09-01 11:47	Torr Samaho	Status	new => acknowledged
2012-09-01 11:47	Torr Samaho	Resolution	open => backport later
2012-10-07 17:02	AlexMax	Note Added: 0005038
2012-10-07 17:03	AlexMax	Note Added: 0005039
2012-10-08 00:33	unknownna	Note Added: 0005049
2013-01-31 03:26	StrikerMan780	Note Added: 0005883
2013-01-31 06:21	Torr Samaho	Note Added: 0005887
2013-01-31 22:49	StrikerMan780	Note Added: 0005899
2013-01-31 23:58	Ru5tK1ng	Note Added: 0005900
2013-02-01 00:00	Ru5tK1ng	Note Edited: 0005900	View Revisions
2013-02-01 07:04	Torr Samaho	Note Added: 0005902
2013-02-02 06:09	Ru5tK1ng	Note Added: 0005908
2013-02-02 06:11	Ru5tK1ng	Note Edited: 0005908	View Revisions
2013-02-02 06:11	Ru5tK1ng	Note Edited: 0005908	View Revisions
2013-02-02 06:12	Ru5tK1ng	Note Edited: 0005908	View Revisions
2013-10-13 19:30	Arco	Relationship added	child of 0001490
2013-12-08 12:47	Torr Samaho	Status	acknowledged => needs testing
2013-12-08 12:47	Torr Samaho	Target Version	=> 2.0
2013-12-11 00:02	Qent	Note Added: 0007694
2014-02-09 18:41	Qent	Note Edited: 0007694	View Revisions
2014-02-09 18:41	Qent	Status	needs testing => resolved
2014-02-09 18:41	Qent	Fixed in Version	=> 2.0-beta
2014-02-09 18:41	Qent	Resolution	backport later => fixed
2014-02-09 18:41	Qent	Assigned To	=> Qent
2015-01-23 04:56	Blzut3	Fixed in Version	2.0-beta => 2.0
2018-09-30 23:05	Blzut3	Status	resolved => closed