MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001226Zandronum[All Projects] Suggestionpublic2012-12-26 16:582018-09-30 23:46
ReporterWatermelon 
Assigned ToWatermelon 
PrioritynormalSeveritytweakReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.0 
Target Version1.4Fixed in Version1.4 
Summary0001226: Leniency with vertical autoaim
DescriptionVertical autoaim barely triggers on zandronum unless you are right on the target. Since most duels involve a weapon that spreads (shotgun, or even moreso with the ssg), if you are not dead on with the player it will not trigger. On other ports there is a much larger allowance of error for the player. Now this just affects the vertical autoaim, not the horizontal.

'http://img339.imageshack.us/img339/5318/autoaimtrigger.png [^]'

It only triggers when you have your crosshair physically on the sprite. At certain distances when the player is only a around 6-8 pixels wide, this literally can affect a duel because if you hit them previously and they have 5-10 HP, only one shot would kill them, but exploiting this engine (because autoaim is ridiculously harder on zandro than ZD or Odamex) they can hope you are just a pixel off and then your shot will just hit the wall if they happen to be even 56 units above you on another platform.

I figure since no one is an aimbot, would it be possible to increase the autoaim horizontal threshold for triggering so that the vertical autoaim only can kick in?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0002078closed Dusk SetActivatorToTarget is broken with "Autoaim: Never". 
Attached Files? MAP01_BugTest_Autoaim_Adjacent.wad (846) 2013-01-05 09:39
/tracker/file_download.php?file_id=913&type=bug
? MAP01_BugTest_Autoaim_ManySectors.wad (2,278) 2013-01-05 09:39
/tracker/file_download.php?file_id=914&type=bug
Issue History
Date ModifiedUsernameFieldChange
2012-12-26 16:58WatermelonNew Issue
2012-12-26 16:59WatermelonNote Added: 0005567
2012-12-26 17:43Torr SamahoNote Added: 0005568
2012-12-26 17:44Torr SamahoStatusnew => feedback
2012-12-26 19:37DuskNote Added: 0005573
2012-12-26 19:42DuskNote Edited: 0005573bug_revision_view_page.php?bugnote_id=5573#r3048
2012-12-26 22:18DuskNote Edited: 0005573bug_revision_view_page.php?bugnote_id=5573#r3049
2012-12-26 23:53WatermelonNote Added: 0005574
2012-12-26 23:53WatermelonStatusfeedback => new
2012-12-26 23:55WatermelonNote Edited: 0005574bug_revision_view_page.php?bugnote_id=5574#r3051
2012-12-27 06:09bluewizardNote Added: 0005578
2012-12-27 06:55WatermelonNote Added: 0005580
2012-12-27 06:57WatermelonNote Edited: 0005580bug_revision_view_page.php?bugnote_id=5580#r3053
2012-12-27 07:59Torr SamahoNote Added: 0005582
2012-12-27 10:44FritsNote Added: 0005586
2012-12-28 01:49bluewizardNote Added: 0005595
2012-12-28 08:57NotIvanNote Added: 0005596
2012-12-28 15:09DuskNote Added: 0005597
2012-12-29 00:14WatermelonNote Added: 0005603
2012-12-29 00:16WatermelonNote Edited: 0005603bug_revision_view_page.php?bugnote_id=5603#r3070
2012-12-29 00:17WatermelonNote Edited: 0005603bug_revision_view_page.php?bugnote_id=5603#r3071
2012-12-29 00:18WatermelonNote Edited: 0005603bug_revision_view_page.php?bugnote_id=5603#r3072
2012-12-29 00:18WatermelonNote Edited: 0005603bug_revision_view_page.php?bugnote_id=5603#r3073
2012-12-30 12:10Torr SamahoNote Added: 0005621
2013-01-05 03:37jwaffeNote Added: 0005690
2013-01-05 03:40jwaffeNote Edited: 0005690bug_revision_view_page.php?bugnote_id=5690#r3111
2013-01-05 03:41jwaffeNote Edited: 0005690bug_revision_view_page.php?bugnote_id=5690#r3112
2013-01-05 03:43jwaffeNote Edited: 0005690bug_revision_view_page.php?bugnote_id=5690#r3113
2013-01-05 04:17jwaffeNote Edited: 0005690bug_revision_view_page.php?bugnote_id=5690#r3114
2013-01-05 04:19jwaffeNote Edited: 0005690bug_revision_view_page.php?bugnote_id=5690#r3115
2013-01-05 09:38Torr SamahoNote Added: 0005691
2013-01-05 09:39Torr SamahoFile Added: MAP01_BugTest_Autoaim_Adjacent.wad
2013-01-05 09:39Torr SamahoFile Added: MAP01_BugTest_Autoaim_ManySectors.wad
2013-01-05 09:40Torr SamahoNote Edited: 0005691bug_revision_view_page.php?bugnote_id=5691#r3117
2013-01-05 09:40Torr SamahoNote Revision Dropped: 5691: 0003116
2013-01-05 11:54Edward-sanNote Added: 0005692
2013-01-05 18:14jwaffeNote Added: 0005693
2013-01-05 18:14jwaffeNote Edited: 0005693bug_revision_view_page.php?bugnote_id=5693#r3119
2013-01-05 18:15jwaffeNote Edited: 0005693bug_revision_view_page.php?bugnote_id=5693#r3120
2013-01-05 18:16jwaffeNote Edited: 0005693bug_revision_view_page.php?bugnote_id=5693#r3121
2013-01-05 18:16jwaffeNote Edited: 0005693bug_revision_view_page.php?bugnote_id=5693#r3122
2013-01-05 18:18jwaffeNote Edited: 0005690bug_revision_view_page.php?bugnote_id=5690#r3123
2013-01-05 18:26jwaffeNote Edited: 0005693bug_revision_view_page.php?bugnote_id=5693#r3124
2013-01-05 18:29jwaffeNote Edited: 0005693bug_revision_view_page.php?bugnote_id=5693#r3125
2013-01-05 18:36jwaffeNote Edited: 0005693bug_revision_view_page.php?bugnote_id=5693#r3126
2013-01-05 18:39jwaffeNote Edited: 0005693bug_revision_view_page.php?bugnote_id=5693#r3127
2013-01-05 19:19Torr SamahoNote Added: 0005695
2013-01-05 19:34jwaffeNote Added: 0005696
2013-01-05 19:49jwaffeNote Edited: 0005696bug_revision_view_page.php?bugnote_id=5696#r3133
2013-01-05 19:49jwaffeNote Edited: 0005696bug_revision_view_page.php?bugnote_id=5696#r3134
2013-01-05 22:04WatermelonNote Added: 0005697
2013-01-05 22:10Torr SamahoNote Added: 0005698
2013-01-05 22:11jwaffeNote Added: 0005699
2013-01-05 22:12jwaffeNote Edited: 0005699bug_revision_view_page.php?bugnote_id=5699#r3136
2013-01-05 22:16jwaffeNote Edited: 0005699bug_revision_view_page.php?bugnote_id=5699#r3137
2013-01-05 22:17Torr SamahoNote Added: 0005700
2013-01-06 07:48NotIvanNote Added: 0005704
2013-01-06 17:30WatermelonNote Added: 0005708
2013-01-06 17:31WatermelonNote Edited: 0005708bug_revision_view_page.php?bugnote_id=5708#r3141
2013-01-06 18:21Torr SamahoNote Added: 0005709
2013-01-07 00:07jwaffeNote Added: 0005712
2013-01-07 00:09jwaffeNote Edited: 0005712bug_revision_view_page.php?bugnote_id=5712#r3143
2013-01-07 00:10jwaffeNote Edited: 0005712bug_revision_view_page.php?bugnote_id=5712#r3144
2013-01-07 06:20Torr SamahoNote Added: 0005713
2013-01-07 16:06WatermelonNote Added: 0005714
2013-01-07 16:07WatermelonNote Edited: 0005714bug_revision_view_page.php?bugnote_id=5714#r3146
2013-01-09 20:37Torr SamahoNote Added: 0005731
2013-02-24 21:47AlexMaxNote Added: 0006077
2013-02-24 21:53AlexMaxNote Edited: 0006077bug_revision_view_page.php?bugnote_id=6077#r3354
2013-03-20 05:52WatermelonNote Added: 0006151
2013-03-20 22:27GezNote Added: 0006157
2013-03-21 20:36Torr SamahoNote Added: 0006158
2013-03-21 21:17WatermelonNote Added: 0006159
2013-03-23 01:21DuskNote Added: 0006160
2013-03-23 01:53WatermelonNote Added: 0006161
2013-03-24 07:57Torr SamahoNote Added: 0006162
2013-04-01 19:30WatermelonNote Added: 0006199
2013-09-18 16:53WatermelonAssigned To => Watermelon
2013-09-18 16:53WatermelonStatusnew => assigned
2014-05-05 22:33WatermelonNote Added: 0008713
2014-05-09 01:10WatermelonNote Added: 0008743
2014-05-09 01:10WatermelonAssigned ToWatermelon =>
2014-05-09 01:10WatermelonStatusassigned => new
2014-05-09 01:10WatermelonNote Deleted: 0008713
2014-10-10 15:58WatermelonAssigned To => Watermelon
2014-10-10 15:58WatermelonStatusnew => assigned
2014-10-30 22:47WatermelonNote Added: 0010742
2014-10-30 22:47WatermelonStatusassigned => needs review
2014-10-31 02:57KarakurtNote Added: 0010746
2014-11-01 11:41Torr SamahoNote Added: 0010761
2014-11-01 11:41Torr SamahoStatusneeds review => feedback
2014-11-01 14:11WatermelonNote Added: 0010764
2014-11-01 14:11WatermelonStatusfeedback => assigned
2014-11-01 14:11WatermelonStatusassigned => needs review
2014-11-01 15:56Torr SamahoNote Added: 0010767
2014-11-01 15:56Torr SamahoStatusneeds review => feedback
2014-11-01 18:19WatermelonNote Added: 0010774
2014-11-01 18:19WatermelonStatusfeedback => assigned
2014-11-01 18:19WatermelonStatusassigned => needs review
2014-11-01 18:22WatermelonNote Edited: 0010774bug_revision_view_page.php?bugnote_id=10774#r5905
2014-11-01 18:38Torr SamahoNote Added: 0010775
2014-11-01 18:57WatermelonNote Added: 0010777
2014-11-01 19:03WatermelonNote Added: 0010778
2014-11-01 19:04WatermelonNote Edited: 0010778bug_revision_view_page.php?bugnote_id=10778#r5907
2014-11-01 19:04WatermelonNote Edited: 0010778bug_revision_view_page.php?bugnote_id=10778#r5908
2014-11-01 19:05WatermelonNote Edited: 0010778bug_revision_view_page.php?bugnote_id=10778#r5909
2014-11-01 19:06WatermelonNote Edited: 0010778bug_revision_view_page.php?bugnote_id=10778#r5910
2014-11-01 19:20cobaltStatusneeds review => needs testing
2014-11-01 19:20cobaltTarget Version => 1.4
2014-11-01 19:20cobaltDescription Updatedbug_revision_view_page.php?rev_id=5912#r5912
2014-11-01 19:20cobaltNote Added: 0010779
2014-11-02 01:57jwaffeNote Added: 0010784
2014-11-02 07:09cobaltNote Added: 0010786
2014-11-02 07:13Torr SamahoNote Deleted: 0010786
2014-11-02 07:24StrikerMan780Note Added: 0010787
2014-11-02 07:26StrikerMan780Note Edited: 0010787bug_revision_view_page.php?bugnote_id=10787#r5918
2015-01-18 03:00StrikerMan780Note Added: 0011418
2015-01-18 10:50DuskStatusneeds testing => resolved
2015-01-18 10:50DuskFixed in Version => 1.4
2015-01-18 10:50DuskResolutionopen => fixed
2015-01-25 12:03Edward-sanRelationship addedrelated to 0002078
2018-09-30 23:46Blzut3Statusresolved => closed

Notes
(0005567)
Watermelon   
2012-12-26 16:59   
That image I made was tested on other ports and I just moved over the line. If no one believes me, try it on the other ports for yourself.
(0005568)
Torr Samaho   
2012-12-26 17:43   
So you are asking for horizontal autoaim? Did Vanilla Doom have this? Is it any different in ZDoom?
(0005573)
Dusk   
2012-12-26 19:37   
(edited on: 2012-12-26 22:18)
Zandronum seems to be behaving like Vanilla Doom here. I tested this in chocolate Doom and I could only hit a barrel if I was pointing right at it.

However, the Doom wiki does mention that horizontal autoaim does exist for projectile weapons. Both Zandronum and ZDoom behave correctly in this aspect.

EDIT: Looking into Odamex's sources tells me that Odamex is also implementing horizontal autoaim for hitscan weapons. P_BulletSlope contains the horizontal autoaim snippet the Doom Wiki page exhibits. Comments suggest that the lack of horizontal autoaim for hitscans was considered a bug in vanilla Doom. ZDaemon is closed source so I cannot confirm there.
(0005574)
Watermelon   
2012-12-26 23:53   
(edited on: 2012-12-26 23:55)
We don't need any horizontal autoaim, the aiming horizontally is just fine in Zandronum.

The biggest problem is the vertical autoaim (to trigger that is) requires insane pinpoint accuracy to the point of insanity. If we have a buffer zone it would help very much, especially since the SSG has such a large spread and if it just triggered you would probably have killed them/won the duel.

What would need to be done code-wise to increase the autoaim horizontal detection rate to trigger the slope modification?



p_pspr.cpp says:
// P_BulletSlope
// Sets a slope so a near miss is at aproximately
// the height of the intended target
The problem is you have to be dead on the target for it to activate, a near miss will not trigger at all
(0005578)
bluewizard   
2012-12-27 06:09   
Again, stop trying to zdaemonize this port. Everyone has to deal with this, so it's completely fair.
(0005580)
Watermelon   
2012-12-27 06:55   
(edited on: 2012-12-27 06:57)
This has nothing to do with 'zdaemonization', throwing everything under that umbrella is just going to make it a pointless misnomer. If anything, you should have said 'odamization' (assuming you actually clicked on the image), but that would just be of equal uselessness like what you posted.

I've asked a lot of people about this and everyone hates the narrow range Zandro gives us. It has nothing to do with what other ports have, though by showing other ports have them maybe the dev's can grab an easy code fix for those of us who want such a feature in.
(0005582)
Torr Samaho   
2012-12-27 07:59   
It's funny how some aspects of Vanilla Doom's behavior (like this one) are declared to be bugs that need to be fixed, while other aspects that are obvious bugs (like the plasma bump bug in MAP01) are declared to be essential for gameplay and need to be preserved.

Anyway, since you are asking to stray away from Vanilla Doom here in a way that is certainly debatable, please rally all that want to have this to declare their stance in this ticket.
(0005586)
Frits   
2012-12-27 10:44   
As somebody who doesn't use auto aim, i wouldn't want to see even more aim assisting being build in. Don't give them even more advantage against us :<.
(0005595)
bluewizard   
2012-12-28 01:49   
I just think you guys should stop being babies and just aim. Even I get frustrated when autoaim doesn't work, but I wouldn't go out of my way to suggest this in order to cater to my play style.
(0005596)
NotIvan   
2012-12-28 08:57   
This sounds like it could cause bugs on other areas to me. I'm against this, just learn to aim. If you just can't shoot people it's you, not the game; as I was easily shooting anyone without problems DESPITE my ping.

Side note: I'd love if you guys haven't wasted time on requests like this and just focused on Zdoom updates :D
(0005597)
Dusk   
2012-12-28 15:09   
Alright I'll just kindly request to keep flamewars out of this thread before they even begin, I can tell this is a flammable subject, let's not ignite it. We're gauging support here, you have declared your stance on it, please leave it at that.

Quote from NotIvan
Side note: I'd love if you guys haven't wasted time on requests like this and just focused on Zdoom updates :D

Plan is to release 1.1 and then I guess there's a codebase update coming up?
(0005603)
Watermelon   
2012-12-29 00:14   
(edited on: 2012-12-29 00:18)
Quote
This sounds like it could cause bugs on other areas to me.

Like what?
Quote
I'm against this, just learn to aim. If you just can't shoot people it's you, not the game

It tends to not trigger mainly with people who lag, so if there was a wider range it would compensate for this possible error (which is a whole other tracker request)
Quote
as I was easily shooting anyone without problems DESPITE my ping.

I've seen you miss plenty of times in the past where autoaim not trigger when it should have; though I'll write this off as selective memory.
Quote
Side note: I'd love if you guys haven't wasted time on requests like this and just focused on Zdoom updates :D

I'd love it if the devs didn't waste time on Zdoom updates and gave all tracker requests an equal viewing and consideration. Fortunately they already do this and I hope they stay this way :D




Now to go onto something of actual substance... here's something interesting a group of us discovered:
After further investigation it appears that autoaim works fine up close when you're in an adjacent sector, but when you cross multiple sectors then autoaim defaults to the "be dead on the player or not trigger"
Therefore the main question is: what determines the triggering of autoaim and why does the above phenomena occur? I noticed when I'm in a room where I'm on another sector adjacent to the one the enemy is in, it will trigger... but when they're a few sectors away it won't. If the dev's want, I can upload a demo of something I found.

This may be potentially a lag/jitter issue, but I don't know if it's worth opening up another ticket for this issue. I believe Konar is trying to work on a patch for it so I don't know if there should be pre-emptive action or not.
(0005621)
Torr Samaho   
2012-12-30 12:10   
Quote from Watermelon

After further investigation it appears that autoaim works fine up close when you're in an adjacent sector, but when you cross multiple sectors then autoaim defaults to the "be dead on the player or not trigger"
This is an important observation that makes the current behavior sound like a bug. Can you make a demo and a minimal example wad to check if this is truly the case? Build the same kind of room twice, once with two and once with multiple sectors so that both versions look the same. If the autoaim works differently in both I'd say it's safe to say that this is a bug.
(0005690)
jwaffe   
2013-01-05 03:37   
(edited on: 2013-01-05 18:18)
I tested this just now in single player, autoaim set to always, in a test wad

Screenshot of bullet hole pattern where the player sector is adjacent to the target sector:
'http://imageshack.us/a/img585/7750/autoaimbugtestadjacent.png [^]'

Screenshot of bullet hole pattern where the player sector is NOT adjacent to the target sector:
'http://imageshack.us/a/img541/6883/autoaimbugtestsectorsbe.png [^]'

Those black lines are bullet holes. I did not paint over these screenshots, and each one of those was shot as a single shot, so there is no spread.

I did not move at all during this test, I only looked left and right.

There are two important aspects in these screenshots to note --

first, and most importantly, the autoaim seems to have a "wave" effect to it, as I aim at a greater angle from the player, autoaim stops briefly, then strangely decides to go back up again, eventually going back down to the proper height and staying there. Note that the voodoo doll across from me is the only other thing in the map.

Second, you will note that the initial autoaim section (the correct one) almost perfectly matches the sprite of the player.


>In case you're looking for another visual aid...

Doing a very rough approximation, considering zero degrees as having your crosshair on the center of the player sprite... looking at the left side in particular,

0-3 degrees: autoaims up to hit the player, this is exactly within the sprite boundaries

3 to 6 degrees: does not autoaim up, this is beyond the sprite borders

6 to ~12 degrees: autoaims up for an unknown reason

~12 degrees and beyond - does not autoaim up


'http://img841.imageshack.us/img841/7431/angles.png [^]'


Wads:

Player sector is adjacent to the sector the target is on:
(MAP01_BugTest_Autoaim_Adjacent.wad)
'http://www.mediafire.com/?oo1of5f910uif4m [^]'

Player sector is NOT adjacent to the sector the target is on:
(MAP01_BugTest_Autoaim_ManySectors.wad
'http://www.mediafire.com/?3u3596t9a07oa5a [^]'

Demos don't work in single player, Torr.

'http://zandronum.com/tracker/view.php?id=1199 [^]'

EDIT - changed 6-~12 because the tracker took it as a link.
(0005691)
Torr Samaho   
2013-01-05 09:38   
(edited on: 2013-01-05 09:40)
Thanks for the detailed analysis. I'll have to look at this in detail.
Quote from jwaffe
Demos don't work in single player, Torr.
Of course I know. When I ask for a demo, I'm always referring to a client side demo. So it would be very helpful to have a client side demo that shows the different behavior.

BTW: I attached your example wads to this ticket. This way we can ensure that the links don't expire.
(0005692)
Edward-san   
2013-01-05 11:54   
Does this happen with gzdoom 323 or latest gzdoom?
(0005693)
jwaffe   
2013-01-05 18:14   
(edited on: 2013-01-05 18:39)
The latest SVN build and r322 both show the same autoaim pattern as Zandronum.

r1503 (latest SVN build)

'http://imageshack.us/a/img585/9551/screenshotdoom201301051.png [^]'


r322:

'http://imageshack.us/a/img138/9551/screenshotdoom201301051.png [^]'

Re: Demo -- OK

EDIT -- in case anyone's interested, Odamex displays the same behavior (screenshot would be useless because the pistol doesn't leave bullet holes) as well as ZDaemon (strangely, shooting the voodoo doll doesn't hurt me, also the bullet holes disappeared over time so I couldn't get a screenshot) and Chocolate Doom (no bullet holes)

NOTE that my odamex and chocolate doom experimentation is less precise, since I can't look at the bullet hole pattern, though I can definitely guarantee that it follows the same up, down, up pattern of autoaim, and I am sure to about a degree of inaccuracy that the sizes of these regions are the same.
(0005695)
Torr Samaho   
2013-01-05 19:19   
Thanks a lot! So, from what I understand all tested Doom ports and versions behave the same and independent of whether the target is in an adjacent or non adjacent sector, right?
(0005696)
jwaffe   
2013-01-05 19:34   
(edited on: 2013-01-05 19:49)
That is correct. All ports (including chocolate doom) exhibit the same logic for whether the weapon autoaims or not, in single player, in the case of this specific map, within about 1 or 2 degrees of error.

I was not able to find any difference between adjacent and non-adjacent sectors on any port in single player, so I didn't bother taking screenshots.
(0005697)
Watermelon   
2013-01-05 22:04   
Therefore does this mean it's time to go to the ZDoom forums?
(0005698)
Torr Samaho   
2013-01-05 22:10   
Well, to me it looks like jwaffe's findings contradict your statement:
Quote from Watermelon
because autoaim is ridiculously harder on zandro than ZD or Odamex

All ports seem to behave the same regarding vertical autoaim. If something is different between Odamex and Zandronum, it's not when vertical autoaim triggers.
(0005699)
jwaffe   
2013-01-05 22:11   
(edited on: 2013-01-05 22:16)
The bug seems to originate from vanilla doom, I'm not sure if it's really as simple as just calling it a "bug" now and reporting it, considering all of the other bugs that weren't fixed from vanilla doom.

I don't use autoaim, personally, but for those that do, I'd recommend considering the implications of this autoaim pattern. Is it useful, and for what?

Also, what qualifies as a "fix"? Removing the gap where it DOESN'T autoaim, and making one contiguous angle range where it autoaims from 0 to 12 degrees, or removing the part where it DOES autoaim from beyond 3 degrees (thus setting it so that the game only autoaims if you are pointing directly at the sprite)?

It's important to ask what's "The bug" here,

Was it meant to autoaim up from zero to 12, making the little patch from 3-6 that doesn't aim up the bug, or was it only meant to autoaim from 0-3, making the area from 6-12 the bug?
(0005700)
Torr Samaho   
2013-01-05 22:17   
I understood the request as a "make Zanronum behave like ZDaemon/Odamex" request, but your analysis didn't reveal any differences. So what exactly should Zandronum do differently to make the aiming feel as it does in the other ports?
(0005704)
NotIvan   
2013-01-06 07:48   
Quote from Watermelon

I'd love it if the devs didn't waste time on Zdoom updates and gave all tracker requests an equal viewing and consideration. Fortunately they already do this and I hope they stay this way :D

Well they absolutely not! There is not one dev. reply on FBF_NORANDOM backport requests... I don't know what kind of a scope you have but you seem to only care about requests if they have the word "odamex" in it.
(0005708)
Watermelon   
2013-01-06 17:30   
(edited on: 2013-01-06 17:31)
Quote
Well they absolutely not! There is not one dev. reply on FBF_NORANDOM backport requests... I don't know what kind of a scope you have but you seem to only care about requests if they have the word "odamex" in it.

Port name has nothing to do with it and you know it, so please refrain from posting more pointless junk in this tracker request -- or at least stop playing naive and doing so because it's obvious otherwise. Thanks.


Quote
I understood the request as a "make Zanronum behave like ZDaemon/Odamex" request, but your analysis didn't reveal any differences. So what exactly should Zandronum do differently to make the aiming feel as it does in the other ports?

This appears to be a bug with vanilla after testing it with 75. Would there be an eligible backport if such a thing was to be fixed on ZDoom? It probably got by in vanilla doom because in online play the dead zone of autoaim is pretty critical when trying to kill players, and much easier to accidentally miss your target and end up in the dead zone because players move much faster/unpredictably compared to monsters.
(0005709)
Torr Samaho   
2013-01-06 18:21   
Quote from NotIvan
There is not one dev. reply on FBF_NORANDOM backport requests...

I explained in 0000274:0005705 why there is rarely any discussion in backpart requests.

Quote from Watermelon
This appears to be a bug with vanilla after testing it with 75. Would there be an eligible backport if such a thing was to be fixed on ZDoom?

That depends on whether the fix relies on other things in ZDoom that Zandronum doesn't have yet. But do you really want this Vanilla behavior to be changed? I understood
Quote from Watermelon
(because autoaim is ridiculously harder on zandro than ZD or Odamex)

to be your main reasons for this request. So essentially you want Zandronum to behave more like Odamex. But according to jwaffe both ports behave the same in this regard and changing this in Zandronum would make Zandronum behave even less like Odamex.

I don't really have a deep insight in how the competitive scene thinks, but changing an aspect inherited from Vanilla Doom that is the same in all three multiplayer ports sounds like a very bad idea to me.
(0005712)
jwaffe   
2013-01-07 00:07   
(edited on: 2013-01-07 00:10)
Watermelon and I (I am 75) played on Duel32 and experimented with how distance and "latency" effect this autoaim behavior

The dead zone is much worse at large distances, and it's worth noting that projectiles DO have horizontal autoaim but hitscanners do not, meaning that projectiles will alter both their horizontal and vertical trajectory to follow the target. Hitscanners only alter their vertical trajectory.

Demo of this testing session:

'http://dl.dropbox.com/u/87656485/2013.01.06_18.28.45_duel32-rc2pk3.cld [^]'

I personally believe that this aiming behavior is misleading at best and should be fixed, though it's not a huge priority for me because I rarely use autoaim.
(0005713)
Torr Samaho   
2013-01-07 06:20   
But it's the same in all three multiplayer ports?
(0005714)
Watermelon   
2013-01-07 16:06   
(edited on: 2013-01-07 16:07)
Quote
But it's the same in all three multiplayer ports?

Yes
What happened is I tried shooting next to the person in Zandro, and it happened to be in this dead zone, then on another port I was slightly off but just enough to be out of the dead zone which gave it an illusion of other ports being fine.

If there is a fix (since I'll make a post on doomworld and see what people think) is it eligible for patching up?
(0005731)
Torr Samaho   
2013-01-09 20:37   
Quote from Watermelon
If there is a fix (since I'll make a post on doomworld and see what people think) is it eligible for patching up?
From a new school perspective I wouldn't mind including such a fix although I absolutely don't see how you could justify this fix citing Odamex or ZDaemon. To the contrary, in order not to upset the players who prefer old school gameplay that fix inevitably will have to come with a compat flag to turn it off.

BTW: One should keep in mind that this fix only makes any difference (visuals aside) as long as there is spread and if the vertical autoaim trigger is solely based on where exactly the player is aiming.
(0006077)
AlexMax   
2013-02-24 21:47   
(edited on: 2013-02-24 21:53)
I added a compatibility flag for this in Odamex r3673, as I believe this falls squarely into a common-sense fix. The toggle switches between three tracers (1 per side, plus straight ahead) and twenty-one (10 per side), with the same total spread. So he may now cite Odamex. :)
(0006151)
Watermelon   
2013-03-20 05:52   
Are we interested in adding a New School autoaim fix, and making a new compatflag to emulate old vanilla behavior with 3 tracers?
I have the code set to go that I originally made, but I'm not sure if we're interested in going ahead with this.
(0006157)
Gez   
2013-03-20 22:27   
Just for reference:
'http://www.doomworld.com/vb/doom-general/62808-vanilla-doom-autoaim-glitch-bug/ [^]'
(0006158)
Torr Samaho   
2013-03-21 20:36   
I'd be interested in seeing a true fix (that can be turned off), but I'm not that interested in a band-aid that just makes the problem appear less often (like just using more tracers).
(0006159)
Watermelon   
2013-03-21 21:17   
So far the only solution I know of is to generate more tracers based on the distance autoaim is allowed and using trigonometry to determine what the smallest distance required is to hit the target.


If you want no tracer increase, then there's always this option:
- Determine LOS to all viable target sprites
- Get spread of current weapon
- Determine which actors that are properly in the LOS are in range
- Determine which of the above are closest
- Adjust pitch

That uses no tracers. The only thing is the spread would need to be passed to the new autoaim function.
(0006160)
Dusk   
2013-03-23 01:21   
So this would make autoaim spread variable by weapon? I'd imagine it should be the same between guns.. we want the blank spots filled, right? We know the max angles already. Why would you need to pass spread to a new autoaim function then?
(0006161)
Watermelon   
2013-03-23 01:53   
Depends on if we want to support the full range of the weapon. That decision is not one for me to make.
(0006162)
Torr Samaho   
2013-03-24 07:57   
The fix should only close the gaps and not change the vertical width of the autoaim in any way.
(0006199)
Watermelon   
2013-04-01 19:30   
Is there any disadvantage to more tracers? Are they huge memory hogs? I wonder if a

- LOS check
- evaluating who is closest to the middle firing angle


Would be more taxing?
(0008743)
Watermelon   
2014-05-09 01:10   
After further thought on the issue, such a thing with LOS checks cannot be used on monsters since it could become quickly expensive on massive maps.

If it were to be done on players, it's possible -- but IIRC the LOS function only checks the center of the body. Is there any way to check if the bound coordinates are visible easily?
(0010742)
Watermelon   
2014-10-30 22:47   
Submitted pull request.

Summary: Added a flag that can be turned on or off to allow for vanilla autoaim. This is purely serverside. I did my best to change the minimal amount of code possible as requested to do in other tickets.

I finished this due to a large request from others (also being fortunately relatively simple).
As a note, tracers were the only way to go. I tried LOS checks and they failed due to only checking the center/origin and not the bounding box.
(0010746)
Karakurt   
2014-10-31 02:57   
GJ
(0010761)
Torr Samaho   
2014-11-01 11:41   
This are a lot of tracers. Did you check that you need at least this many tracers to reduce the gaps sufficiently? Also did you check the influence of the large amount of tracers on CPU usage? SSG + "sv_fastweapons 2" should be a good way to test this.
(0010764)
Watermelon   
2014-11-01 14:11   
I checked my CPU while testing and there was no significant change in memory at all.

%MEM did not change whatsoever
%CPU fluctuations stayed the same before and after spamming weapons
sv_fastweapons 2 and going nuts.
(0010767)
Torr Samaho   
2014-11-01 15:56   
I didn't except the memory requirements to go up, I was just concerned about CPU usage. How about my other question, i.e. did you check that you need at least this many tracers to reduce the gaps sufficiently?
(0010774)
Watermelon   
2014-11-01 18:19   
(edited on: 2014-11-01 18:22)
This was my logic:

Using ANG_1 as a reference, I set out to find what autoaim's angle is it in degrees. 1 << 26 divided by ANG_1 yields 5.625 degrees.

Next I need to take the max distance autoaim can work at (1024 map units from the code 16*64*FRACUNIT) and find out the minimum angle needed to make it work. I made a right angle triangle with the adjacent being 1024 and the opposite being 16 (because thats the player radius), which yielded an angle of 0.89 degrees.

This means that if we have tracers fanning out from the center at 0.89 degrees each time, that is 6 required in between each.
0 (center), 0.89, 1,78, 2.67, 3.56, 4.45, 5.34, and we stop at 5.625 because that is vanilla's max range.

This leads to there being a requiremenet of 15 tracers. I did not use this many, I just used a rough estimate from testing when Zan++ was around.


Therefore if we want this to be done completely properly, the solution is then to use increments of 0xA20500 (which is 0.89 degrees in doom's binary angle format).

If you want, I can change it to use multiples of 0xA20500. That will probably add 2 more tracers. Odamex uses a method like this and they have zero performance issues even when there was one time it had 20-22 players in deathmatch.


Do you want me to upgrade to this precise angle? It makes logical sense and should be the most accurate.
(0010775)
Torr Samaho   
2014-11-01 18:38   
Wait, I'm confused now. You make a pull request with 17 tracers (and since you make a pull request I have to assume that you are convinced that the code works sufficiently well), I ask if you need at least that many tracers (aka can we use less) and now you propose to use even more?

Also, rereading all the nodes, I noticed that Odamex uses the "more tracers" solution for a while now, but you use a different of tracers than they do?
(0010777)
Watermelon   
2014-11-01 18:57   
Decided to use the 0xA20500 because it uses 2 less tracers. Pull req. updated.
(0010778)
Watermelon   
2014-11-01 19:03   
(edited on: 2014-11-01 19:06)
Quote
Wait, I'm confused now. You make a pull request with 17 tracers (and since you make a pull request I have to assume that you are convinced that the code works sufficiently well), I ask if you need at least that many tracers (aka can we use less) and now you propose to use even more?


We use less now than before, the total is 15 (6 new ones for each side). Latest pull request is updated. It's best to discard whatever I said since I've found the optimal angle that allows us to have the minimum amount of tracers possible.

Quote
Also, rereading all the nodes, I noticed that Odamex uses the "more tracers" solution for a while now, but you use a different of tracers than they do?


I checked the odamex code and odamex uses 21. My math shows that I have the minimum amount of tracers needed (15) to effectively have autoaim work.
Our tracers should be identical, they use the same code when I looked at it right now (both Zan src and Oda src).
(0010779)
cobalt   
2014-11-01 19:20   
Issue addressed by commit 18219b6dc864: Fixes deadzones in vertical autoaim, added a compatflag to emulate vanilla autoaim (fixes 1226).
Committed by WChrisK [Watermelon] on Saturday 01 November 2014 15:07:12

Changes in files:
 docs/zandronum-history.txt | 1 +
 src/d_main.cpp | 1 +
 src/doomdef.h | 2 ++
 src/p_pspr.cpp | 13 +++++++++++--
 4 files changed, 15 insertions(+), 2 deletions(-)
(0010784)
jwaffe   
2014-11-02 01:57   
Nice work water!
(0010787)
StrikerMan780   
2014-11-02 07:24   
(edited on: 2014-11-02 07:26)
I can vouch that Zan's autoaim is a bit janky online, even compared to Vanilla from what I've been able to tell. Often times, I get people asking me "Is autoaim even on here?". It may have to do with the inconsistent ping-based unlagged perhaps, but unless I aim at a sweet spot, autoaim doesn't even work at all, when compared to Vanilla or ZDaemon, Odamex, or in Zan singleplayer.

That's probably only partially related to this issue however...
(0011418)
StrikerMan780   
2015-01-18 03:00   
The autoaim seems to be a lot more effective now, especially now that gametic unlagged is in.