Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
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?
Attached Files? file icon MAP01_BugTest_Autoaim_Adjacent.wad [^] (846 bytes) 2013-01-05 09:39
? file icon MAP01_BugTest_Autoaim_ManySectors.wad [^] (2,278 bytes) 2013-01-05 09:39

- Relationships
related to 0002078closedDusk SetActivatorToTarget is broken with "Autoaim: Never". 

-  Notes
User avatar (0005567)
Watermelon (developer)
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.
User avatar (0005568)
Torr Samaho (administrator)
2012-12-26 17:43

 So you are asking for horizontal autoaim? Did Vanilla Doom have this? Is it any different in ZDoom?
User avatar (0005573)
Dusk (developer)
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.
User avatar (0005574)
Watermelon (developer)
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
User avatar (0005578)
bluewizard (reporter)
2012-12-27 06:09

 Again, stop trying to zdaemonize this port. Everyone has to deal with this, so it's completely fair.
User avatar (0005580)
Watermelon (developer)
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.
User avatar (0005582)
Torr Samaho (administrator)
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.
User avatar (0005586)
Frits (reporter)
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 :<.
User avatar (0005595)
bluewizard (reporter)
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.
User avatar (0005596)
NotIvan (reporter)
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
User avatar (0005597)
Dusk (developer)
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?
User avatar (0005603)
Watermelon (developer)
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.
User avatar (0005621)
Torr Samaho (administrator)
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.
User avatar (0005690)
jwaffe (reporter)
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.
User avatar (0005691)
Torr Samaho (administrator)
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.
User avatar (0005692)
Edward-san (developer)
2013-01-05 11:54

 Does this happen with gzdoom 323 or latest gzdoom?
User avatar (0005693)
jwaffe (reporter)
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.
User avatar (0005695)
Torr Samaho (administrator)
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?
User avatar (0005696)
jwaffe (reporter)
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.
User avatar (0005697)
Watermelon (developer)
2013-01-05 22:04

 Therefore does this mean it's time to go to the ZDoom forums?
User avatar (0005698)
Torr Samaho (administrator)
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.
User avatar (0005699)
jwaffe (reporter)
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?
User avatar (0005700)
Torr Samaho (administrator)
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?
User avatar (0005704)
NotIvan (reporter)
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.
User avatar (0005708)
Watermelon (developer)
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.
User avatar (0005709)
Torr Samaho (administrator)
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.
User avatar (0005712)
jwaffe (reporter)
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.
User avatar (0005713)
Torr Samaho (administrator)
2013-01-07 06:20

 But it's the same in all three multiplayer ports?
User avatar (0005714)
Watermelon (developer)
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?
User avatar (0005731)
Torr Samaho (administrator)
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.
User avatar (0006077)
AlexMax (developer)
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. :)
User avatar (0006151)
Watermelon (developer)
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.
User avatar (0006157)
Gez (reporter)
2013-03-20 22:27

 Just for reference:
'http://www.doomworld.com/vb/doom-general/62808-vanilla-doom-autoaim-glitch-bug/ [^]'
User avatar (0006158)
Torr Samaho (administrator)
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).
User avatar (0006159)
Watermelon (developer)
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.
User avatar (0006160)
Dusk (developer)
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?
User avatar (0006161)
Watermelon (developer)
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.
User avatar (0006162)
Torr Samaho (administrator)
2013-03-24 07:57

 The fix should only close the gaps and not change the vertical width of the autoaim in any way.
User avatar (0006199)
Watermelon (developer)
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?
User avatar (0008743)
Watermelon (developer)
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?
User avatar (0010742)
Watermelon (developer)
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.
User avatar (0010746)
Karakurt (reporter)
2014-10-31 02:57

 GJ
User avatar (0010761)
Torr Samaho (administrator)
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.
User avatar (0010764)
Watermelon (developer)
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.
User avatar (0010767)
Torr Samaho (administrator)
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?
User avatar (0010774)
Watermelon (developer)
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.
User avatar (0010775)
Torr Samaho (administrator)
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?
User avatar (0010777)
Watermelon (developer)
2014-11-01 18:57

 Decided to use the 0xA20500 because it uses 2 less tracers. Pull req. updated.
User avatar (0010778)
Watermelon (developer)
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).
User avatar (0010779)
cobalt (updater)
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(-)
User avatar (0010784)
jwaffe (reporter)
2014-11-02 01:57

 Nice work water!
User avatar (0010787)
StrikerMan780 (reporter)
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...
User avatar (0011418)
StrikerMan780 (reporter)
2015-01-18 03:00

 The autoaim seems to be a lot more effective now, especially now that gametic unlagged is in.

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: Watermelon AlexMax StrikerMan780 Balrog Leonard Karakurt
Opponents: bluewizard NotIvan

- Issue History
Date Modified Username Field Change
2012-12-26 16:58 Watermelon New Issue
2012-12-26 16:59 Watermelon Note Added: 0005567
2012-12-26 17:43 Torr Samaho Note Added: 0005568
2012-12-26 17:44 Torr Samaho Status new => feedback
2012-12-26 19:37 Dusk Note Added: 0005573
2012-12-26 19:42 Dusk Note Edited: 0005573 View Revisions
2012-12-26 22:18 Dusk Note Edited: 0005573 View Revisions
2012-12-26 23:53 Watermelon Note Added: 0005574
2012-12-26 23:53 Watermelon Status feedback => new
2012-12-26 23:55 Watermelon Note Edited: 0005574 View Revisions
2012-12-27 06:09 bluewizard Note Added: 0005578
2012-12-27 06:55 Watermelon Note Added: 0005580
2012-12-27 06:57 Watermelon Note Edited: 0005580 View Revisions
2012-12-27 07:59 Torr Samaho Note Added: 0005582
2012-12-27 10:44 Frits Note Added: 0005586
2012-12-28 01:49 bluewizard Note Added: 0005595
2012-12-28 08:57 NotIvan Note Added: 0005596
2012-12-28 15:09 Dusk Note Added: 0005597
2012-12-29 00:14 Watermelon Note Added: 0005603
2012-12-29 00:16 Watermelon Note Edited: 0005603 View Revisions
2012-12-29 00:17 Watermelon Note Edited: 0005603 View Revisions
2012-12-29 00:18 Watermelon Note Edited: 0005603 View Revisions
2012-12-29 00:18 Watermelon Note Edited: 0005603 View Revisions
2012-12-30 12:10 Torr Samaho Note Added: 0005621
2013-01-05 03:37 jwaffe Note Added: 0005690
2013-01-05 03:40 jwaffe Note Edited: 0005690 View Revisions
2013-01-05 03:41 jwaffe Note Edited: 0005690 View Revisions
2013-01-05 03:43 jwaffe Note Edited: 0005690 View Revisions
2013-01-05 04:17 jwaffe Note Edited: 0005690 View Revisions
2013-01-05 04:19 jwaffe Note Edited: 0005690 View Revisions
2013-01-05 09:38 Torr Samaho Note Added: 0005691
2013-01-05 09:39 Torr Samaho File Added: MAP01_BugTest_Autoaim_Adjacent.wad
2013-01-05 09:39 Torr Samaho File Added: MAP01_BugTest_Autoaim_ManySectors.wad
2013-01-05 09:40 Torr Samaho Note Edited: 0005691 View Revisions
2013-01-05 09:40 Torr Samaho Note Revision Dropped: 5691: 0003116
2013-01-05 11:54 Edward-san Note Added: 0005692
2013-01-05 18:14 jwaffe Note Added: 0005693
2013-01-05 18:14 jwaffe Note Edited: 0005693 View Revisions
2013-01-05 18:15 jwaffe Note Edited: 0005693 View Revisions
2013-01-05 18:16 jwaffe Note Edited: 0005693 View Revisions
2013-01-05 18:16 jwaffe Note Edited: 0005693 View Revisions
2013-01-05 18:18 jwaffe Note Edited: 0005690 View Revisions
2013-01-05 18:26 jwaffe Note Edited: 0005693 View Revisions
2013-01-05 18:29 jwaffe Note Edited: 0005693 View Revisions
2013-01-05 18:36 jwaffe Note Edited: 0005693 View Revisions
2013-01-05 18:39 jwaffe Note Edited: 0005693 View Revisions
2013-01-05 19:19 Torr Samaho Note Added: 0005695
2013-01-05 19:34 jwaffe Note Added: 0005696
2013-01-05 19:49 jwaffe Note Edited: 0005696 View Revisions
2013-01-05 19:49 jwaffe Note Edited: 0005696 View Revisions
2013-01-05 22:04 Watermelon Note Added: 0005697
2013-01-05 22:10 Torr Samaho Note Added: 0005698
2013-01-05 22:11 jwaffe Note Added: 0005699
2013-01-05 22:12 jwaffe Note Edited: 0005699 View Revisions
2013-01-05 22:16 jwaffe Note Edited: 0005699 View Revisions
2013-01-05 22:17 Torr Samaho Note Added: 0005700
2013-01-06 07:48 NotIvan Note Added: 0005704
2013-01-06 17:30 Watermelon Note Added: 0005708
2013-01-06 17:31 Watermelon Note Edited: 0005708 View Revisions
2013-01-06 18:21 Torr Samaho Note Added: 0005709
2013-01-07 00:07 jwaffe Note Added: 0005712
2013-01-07 00:09 jwaffe Note Edited: 0005712 View Revisions
2013-01-07 00:10 jwaffe Note Edited: 0005712 View Revisions
2013-01-07 06:20 Torr Samaho Note Added: 0005713
2013-01-07 16:06 Watermelon Note Added: 0005714
2013-01-07 16:07 Watermelon Note Edited: 0005714 View Revisions
2013-01-09 20:37 Torr Samaho Note Added: 0005731
2013-02-24 21:47 AlexMax Note Added: 0006077
2013-02-24 21:53 AlexMax Note Edited: 0006077 View Revisions
2013-03-20 05:52 Watermelon Note Added: 0006151
2013-03-20 22:27 Gez Note Added: 0006157
2013-03-21 20:36 Torr Samaho Note Added: 0006158
2013-03-21 21:17 Watermelon Note Added: 0006159
2013-03-23 01:21 Dusk Note Added: 0006160
2013-03-23 01:53 Watermelon Note Added: 0006161
2013-03-24 07:57 Torr Samaho Note Added: 0006162
2013-04-01 19:30 Watermelon Note Added: 0006199
2013-09-18 16:53 Watermelon Assigned To => Watermelon
2013-09-18 16:53 Watermelon Status new => assigned
2014-05-05 22:33 Watermelon Note Added: 0008713
2014-05-09 01:10 Watermelon Note Added: 0008743
2014-05-09 01:10 Watermelon Assigned To Watermelon =>
2014-05-09 01:10 Watermelon Status assigned => new
2014-05-09 01:10 Watermelon Note Deleted: 0008713
2014-10-10 15:58 Watermelon Assigned To => Watermelon
2014-10-10 15:58 Watermelon Status new => assigned
2014-10-30 22:47 Watermelon Note Added: 0010742
2014-10-30 22:47 Watermelon Status assigned => needs review
2014-10-31 02:57 Karakurt Note Added: 0010746
2014-11-01 11:41 Torr Samaho Note Added: 0010761
2014-11-01 11:41 Torr Samaho Status needs review => feedback
2014-11-01 14:11 Watermelon Note Added: 0010764
2014-11-01 14:11 Watermelon Status feedback => assigned
2014-11-01 14:11 Watermelon Status assigned => needs review
2014-11-01 15:56 Torr Samaho Note Added: 0010767
2014-11-01 15:56 Torr Samaho Status needs review => feedback
2014-11-01 18:19 Watermelon Note Added: 0010774
2014-11-01 18:19 Watermelon Status feedback => assigned
2014-11-01 18:19 Watermelon Status assigned => needs review
2014-11-01 18:22 Watermelon Note Edited: 0010774 View Revisions
2014-11-01 18:38 Torr Samaho Note Added: 0010775
2014-11-01 18:57 Watermelon Note Added: 0010777
2014-11-01 19:03 Watermelon Note Added: 0010778
2014-11-01 19:04 Watermelon Note Edited: 0010778 View Revisions
2014-11-01 19:04 Watermelon Note Edited: 0010778 View Revisions
2014-11-01 19:05 Watermelon Note Edited: 0010778 View Revisions
2014-11-01 19:06 Watermelon Note Edited: 0010778 View Revisions
2014-11-01 19:20 cobalt Status needs review => needs testing
2014-11-01 19:20 cobalt Target Version => 1.4
2014-11-01 19:20 cobalt Description Updated View Revisions
2014-11-01 19:20 cobalt Note Added: 0010779
2014-11-02 01:57 jwaffe Note Added: 0010784
2014-11-02 07:09 cobalt Note Added: 0010786
2014-11-02 07:13 Torr Samaho Note Deleted: 0010786
2014-11-02 07:24 StrikerMan780 Note Added: 0010787
2014-11-02 07:26 StrikerMan780 Note Edited: 0010787 View Revisions
2015-01-18 03:00 StrikerMan780 Note Added: 0011418
2015-01-18 10:50 Dusk Status needs testing => resolved
2015-01-18 10:50 Dusk Fixed in Version => 1.4
2015-01-18 10:50 Dusk Resolution open => fixed
2015-01-25 12:03 Edward-san Relationship added related to 0002078
2018-09-30 23:46 Blzut3 Status resolved => closed




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker