Jump to content
Mib2347

I have devised a way to demonstrate heavy aim

Recommended Posts

@@-DeucEy- and @@Mib2347 it's funny we're all finding these inconsistencies, because what you guys are describing sounds a lot like what I'm seeing, things are close, or tends to vary between two points, where one is far more likely, 80-90%.  Again, I'm wondering whether my circuit is actually fine, and we're digging into a deeper Xbone specific issue here.  That BLOPSII video is also a great find, plus the fact that hard resets seem to make a difference, it seems like there is more here than just H5 heavy aim, and perhaps something about H5 just makes it far more apparent than the older installations on MCC?  I've always felt that H5 had a higher aim "resolution", like the 360 was only capable of 128 discrete aim input positions across an axis, where as the Xbone has 256 or something.  There really is a ton of fine control in H5, albeit improperly handled.

 

Also, I still haven't been convinced that my suggestion from way back here:

 

http://teambeyond.net/forum/topic/15295-i-have-devised-a-way-to-demonstrate-heavy-aim/page-12?do=findComment&comment=934237

 

Doesn't have something to do with it, although single game frames shouldn't cause that much variance, I'd think.  Let's do some quick back of the envelope math, and we'll take some numbers from my 200ms tests: 

 

p6S2LCs.png

 

If the game is running at 60fps, each game frame takes roughly 16.667 ms to complete.  So, in 200ms, that means we're dealing with 200ms/16.667ms per frame = 11.9997, or just about 12 game frames.  So, if on average we're rotating by 16.98 degrees, or ~17 degrees over the whole 200ms, we're averaging 17 degrees / 12 frames = 1.42 degrees of rotation per frame (assuming a linear rotation, which is definitely not the case given all the acceleration calculations being performed).  If we look at my spreadsheet, we see that when I'm off, I'm off by 1.66-1.71, so if we fudge that 1.42 up a bit given the acceleration changes, I think there may be some merit to all this.  ESPECIALLY considering that when I keep these sensitivity and just increase the time spent rotating, I see roughly the same variance, just a few degrees of rotation.

 

That would all lead me to believe that our errors could very well be somewhat influenced being on the wrong side of input polling for a game frame.

 

As always, someone else please please PLEASE double check my math and thinking here, I'd hate to lead us down a train of thought because I made some dumb assumption or fat fingered a calculation.

  • Upvote (+1) 7

Share this post


Link to post

No, I see exactly where you're going with it and that's an interesting train a thought. All the math checks out; and you pointed the only extenuating circumstance I was going to add which was the acceleration may cause the the degree of rotation per frame to be slightly skewed the longer it's held.

 

But yes, your formula is correct:

 

16.98 / (200 / ( (1/60)*1000 ) )  = Δ rotation per frame (1.415)

 

I will make a spreadsheet similar to yours when I run another test later today. I will write another script to do constant turning with 1500ms intermissions and record the results and I will separate the data based on an Xbox 360 controller input and the Xbox One controller input and see if there is any variance between the two sets using the same settings.

  • Upvote (+1) 6

Share this post


Link to post

No, I see exactly where you're going with it and that's an interesting train a thought. All the math checks out; and you pointed the only extenuating circumstance I was going to add which was the acceleration may cause the the degree of rotation per frame to be slightly skewed the longer it's held.

 

But yes, your formula is correct:

 

16.98 / (200 / ( (1/60)*1000 ) ) = Δ rotation per frame (1.415)

 

I will make a spreadsheet similar to yours when I run another test later today. I will write another script to do constant turning with 1500ms intermissions and record the results and I will separate the data based on an Xbox 360 controller input and the Xbox One controller input and see if there is any variance between the two sets using the same settings.

Are you planning on just testing the controllers or the same game on two different consoles? Like Halo 3 360 vs MCC Halo 3

  • Upvote (+1) 1

Share this post


Link to post

Are you planning on just testing the controllers or the same game on two different consoles? Like Halo 3 360 vs MCC Halo 3

 

Both.

 

Halo 5 - Xbox One controller and 360 controller

 

Halo 3 (MCC) - Xbox One controller and 360 controller

Halo 3 (360) - Xbox One controller and 360 controller

 

The Halo 3 tests will be to see if I still get that same consistent-inconsistency. So it's more or less for visual confirmation of what we're hypothesizing here. 

  • If we're on MCC and those same two variances occur using both the Xbox One controller and the 360 controller, then the issues could possibly lie in the script or the console itself.
  • If we're on MCC and the variances only occur on the Xbox One controller and not the 360 controller, then the issues could possibly in the console or the controllers.
  • If we're on Halo 3 360 and the same two variances occur on both controllers then the problem is the script (assuming the variance also occurs in both controllers on MCC as well).
  • If we're on Halo 3 360 and the variance only occurs on the Xbox One controller and not the 360 controller, than the problem lies in the controllers.
  • If we're on Halo 3 360 and the variance does not occur on either of the controllers and both of the controllers have the variance on MCC, then it is something wrong with the console (XB1) itself.

I believe that should cover all the possible outcomes.. Let me know if you think I'm missing one, because I very well could be for those test cases.

  • Upvote (+1) 6

Share this post


Link to post

No, I see exactly where you're going with it and that's an interesting train a thought. All the math checks out; and you pointed the only extenuating circumstance I was going to add which was the acceleration may cause the the degree of rotation per frame to be slightly skewed the longer it's held.

 

But yes, your formula is correct:

 

16.98 / (200 / ( (1/60)*1000 ) )  = Δ rotation per frame (1.415)

 

I will make a spreadsheet similar to yours when I run another test later today. I will write another script to do constant turning with 1500ms intermissions and record the results and I will separate the data based on an Xbox 360 controller input and the Xbox One controller input and see if there is any variance between the two sets using the same settings.

 

So, leading off of that I have some other theories.  Let's be a little more exact with our calculations:

 

16.6667ms per frame, and we run for 200ms, that gives us 11.999976 frames, so we just miss calculating a full 12th frame.  The problem is that in the calculation of a frame, we have no idea when the input polling happens.  One might assume it happens at the beginning of a frame, but that's a pretty naive assumption when considering game engines tend to be the kings of obscure performance tunings, and the management of the work done of every frame is a large part of that.  

 

With that, what we could do is adjust our turn time (200ms above) such that it places us at different points in cutting off a frame calculation.  For example, if I take 11.5 * 16.6667 I get ~192, so theoretically running for 192ms should cause me to lock right in the middle of a frame calculation.  However, the farther we are from the "edge" of a frame calculation (basically hitting a whole number frame count), the more error we introduce as frames stack. I'll explain:

 

Let's assume we go with that value, so that we're hitting 11.5 frames consistently, and we'll also assume input polling happens in the first half of frame calculation.  So for the first 192ms, we successfully sent input to the game engine 12, or more correctly 12 frames were calculated with our input turned on.  Now, let's assume we turn off our input for the same amount of time, another 192ms, so that we just paused for another 11.5 frames of game input.  So now we're directly at the beginning of frame 23, and we should go on happily adding 11.5 each time, and always turning our aim input on at the beginning of a frame, like so:

 

11.5 -> 23 -> 34.5 -> 46 -> 57.5, etc. etc.

 

However, if we paused for a different amount of time, say 197ms, that would mean our pause would have been for closer to 11.8 frames of engine calculation.  Rather than starting our input again at the beginning of frame 23, we're going to start at frame 11.5 + 11.8, or 23.3, or a third of the way into the frame calculation for the 23rd frame.  We may have already missed the input window for that frame, and subsequently wouldn't start registering input with the engine until frame 24.  Since we're turning on for 192ms, or 11.5 frames, we then find ourselves turning off at 23.3 + 11.5 = 34.8, which should be alright for registering input on that frame. The problem arises after this runs for a few iterations.  Let's look at the numbers again for 11.5 on, 11.5 off:

 

ON:   0

OFF: 11.5

ON:   23

OFF: 34.5

ON:   46
OFF: 57.5

ON:   69

OFF: 80.5

 

Assuming the engine does its input polling at the beginning of a frame calculation, each time we turn our input on, we manage to be within that input window.  Let's look at our example of 11.5 on, and 11.8, and follow him out:

 

ON:   0

OFF: 11.5

ON:   23.3

OFF: 34.8

ON:   46.6

OFF: 58.1

ON:   69.9

OFF: 81.4

ON:   93.2

OFF: 104.7

 

Notice anything bad?  We turned on our input at 46.6 frame time, and turned it off at 58.1 frame time.  Not only did we fail to calculate aim input on the frame we started on (as 0.6 assumes we're in the latter half of the frame calculation), we get input on frames 47-57, inclusive, or 11 frames.  Because we turned off our input at 58.1, we can't be sure we actually successfully registered input with the engine on that 0.1 of frame data, so here we only managed 11 frames of input, rather than our 12.

 

Now, this is all very contrived, and again assumes accurate timing of the output circuit, but after laying it all out I'm convinced we're hitting these issues.

 

So, what to do about it?  I like the fact that my 11.5 frames on and 11.5 frames off manages to turn our input on at the same point in a frame every time.  However, that assumes the game doesn't drop any frames, and that it handles inputs at the same time every frame.  But really, that's just about the best we're going to get, and I think some testing is in order that aims to always start and end at the same point in a frame, and hope that aim frame drop handling code doesn't get us out of sync.

 

Are we having fun yet?  :intensifies:

 

EDIT: The key might be hitting the dead ends of frames as closely as we can.  Again, ~16.667ms per frame, so 16667ms, or 16.667s should get us an even 1k frames.  The problem is we'll never be able to sync up with the beginning of the engine's frame calcs.

 

EXTRA EDIT:  I think it was @@Apoll0 who pointed out that the Xbone controller has a polling rate of every 8ms, so that sort of locks the potential for varying polling times up a bit.  Basically each game frame there are at most three points where we could change our input (given that in a best case scenario three controller polls happening 8ms apart would fit in a 16ms window, which is less than our 16.667ms per frame), but more often than not we're only going to get two.  Doing the math it looks like every 12 game frames things would line up such that we would get three, but the point still stands that it isn't like we can precisely lineup input begins and ends.

  • Upvote (+1) 4

Share this post


Link to post

 

 

 

So, leading off of that I have some other theories.  Let's be a little more exact with our calculations:

 

16.6667ms per frame, and we run for 200ms, that gives us 11.999976 frames, so we just miss calculating a full 12th frame.  The problem is that in the calculation of a frame, we have no idea when the input polling happens.  One might assume it happens at the beginning of a frame, but that's a pretty naive assumption when considering game engines tend to be the kings of obscure performance tunings, and the management of the work done of every frame is a large part of that.  

 

With that, what we could do is adjust our turn time (200ms above) such that it places us at different points in cutting off a frame calculation.  For example, if I take 11.5 * 16.6667 I get ~192, so theoretically running for 192ms should cause me to lock right in the middle of a frame calculation.  However, the farther we are from the "edge" of a frame calculation (basically hitting a whole number frame count), the more error we introduce as frames stack. I'll explain:

 

Let's assume we go with that value, so that we're hitting 11.5 frames consistently, and we'll also assume input polling happens in the first half of frame calculation.  So for the first 192ms, we successfully sent input to the game engine 12, or more correctly 12 frames were calculated with our input turned on.  Now, let's assume we turn off our input for the same amount of time, another 192ms, so that we just paused for another 11.5 frames of game input.  So now we're directly at the beginning of frame 23, and we should go on happily adding 11.5 each time, and always turning our aim input on at the beginning of a frame, like so:

 

11.5 -> 23 -> 34.5 -> 46 -> 57.5, etc. etc.

 

However, if we paused for a different amount of time, say 197ms, that would mean our pause would have been for closer to 11.8 frames of engine calculation.  Rather than starting our input again at the beginning of frame 23, we're going to start at frame 11.5 + 11.8, or 23.3, or a third of the way into the frame calculation for the 23rd frame.  We may have already missed the input window for that frame, and subsequently wouldn't start registering input with the engine until frame 24.  Since we're turning on for 192ms, or 11.5 frames, we then find ourselves turning off at 23.3 + 11.5 = 34.8, which should be alright for registering input on that frame. The problem arises after this runs for a few iterations.  Let's look at the numbers again for 11.5 on, 11.5 off:

 

ON:   0

OFF: 11.5

ON:   23

OFF: 34.5

ON:   46
OFF: 57.5

ON:   69

OFF: 80.5

 

Assuming the engine does its input polling at the beginning of a frame calculation, each time we turn our input on, we manage to be within that input window.  Let's look at our example of 11.5 on, and 11.8, and follow him out:

 

ON:   0

OFF: 11.5

ON:   23.3

OFF: 34.8

ON:   46.6

OFF: 58.1

ON:   69.9

OFF: 81.4

ON:   93.2

OFF: 104.7

 

Notice anything bad?  We turned on our input at 46.6 frame time, and turned it off at 58.1 frame time.  Not only did we fail to calculate aim input on the frame we started on (as 0.6 assumes we're in the latter half of the frame calculation), we get input on frames 47-57, inclusive, or 11 frames.  Because we turned off our input at 58.1, we can't be sure we actually successfully registered input with the engine on that 0.1 of frame data, so here we only managed 11 frames of input, rather than our 12.

 

Now, this is all very contrived, and again assumes accurate timing of the output circuit, but after laying it all out I'm convinced we're hitting these issues.

 

So, what to do about it?  I like the fact that my 11.5 frames on and 11.5 frames off manages to turn our input on at the same point in a frame every time.  However, that assumes the game doesn't drop any frames, and that it handles inputs at the same time every frame.  But really, that's just about the best we're going to get, and I think some testing is in order that aims to always start and end at the same point in a frame, and hope that aim frame drop handling code doesn't get us out of sync.

 

Are we having fun yet?  :intensifies:

 

EDIT: The key might be hitting the dead ends of frames as closely as we can.  Again, ~16.667ms per frame, so 16667ms, or 16.667s should get us an even 1k frames.  The problem is we'll never be able to sync up with the beginning of the engine's frame calcs.

 

EXTRA EDIT:  I think it was @@Apoll0 who pointed out that the Xbone controller has a polling rate of every 8ms, so that sort of locks the potential for varying polling times up a bit.  Basically each game frame there are at most three points where we could change our input (given that in a best case scenario three controller polls happening 8ms apart would fit in a 16ms window, which is less than our 16.667ms per frame), but more often than not we're only going to get two.  Doing the math it looks like every 12 game frames things would line up such that we would get three, but the point still stands that it isn't like we can precisely lineup input begins and ends.

 

 

 

 

Its entirely possible that all the variances we are finding are a matter of polling vs framerate.  The polling is every 8ms and i bet the variance of that is a heck of a lot tighter than the framerate.  just as an example, if i fire up gears on my PC and have the framerate and frame time clocks up with it locked at 60 fps you can see those values vary constantly.  usually within 1 frame of each other, but there has to be some leeway or rounding built into whatever calculations are framerate-based (or based on a tick of 60 times a second, even if not "synced" to framerate).

 

Its a little frustrating to still be working on proving that the testing method is accurate.  And i'm not even doing the testing! Lets be honest i'm basically just a sounding board/cheerleader in this thread. Until we do that we can't have confidence in results and the real meat of the testing is going to be when we can compare multiple scenarios like,

 

1)sterile testing with one player in game

2) loaded testing with multiple players in the game

3) loaded testing with multiple players and multiple observers in the game

  • Upvote (+1) 2

Share this post


Link to post

Its entirely possible that all the variances we are finding are a matter of polling vs framerate. The polling is every 8ms and i bet the variance of that is a heck of a lot tighter than the framerate. just as an example, if i fire up gears on my PC and have the framerate and frame time clocks up with it locked at 60 fps you can see those values vary constantly. usually within 1 frame of each other, but there has to be some leeway or rounding built into whatever calculations are framerate-based (or based on a tick of 60 times a second, even if not "synced" to framerate).

 

Its a little frustrating to still be working on proving that the testing method is accurate. And i'm not even doing the testing! Lets be honest i'm basically just a sounding board/cheerleader in this thread. Until we do that we can't have confidence in results and the real meat of the testing is going to be when we can compare multiple scenarios like,

 

1)sterile testing with one player in game

2) loaded testing with multiple players in the game

3) loaded testing with multiple players and multiple observers in the game

Honestly, I'm starting to think we're gonna have these game frame levels of variations no matter what, and we should just start doing testing and looking for changes that are far more drastic.

  • Upvote (+1) 5

Share this post


Link to post

Honestly, I'm starting to think we're gonna have these game frame levels of variations no matter what, and we should just start doing testing and looking for changes that are far more drastic.

 

I agree.  Its time to get multiple players and observers in a match and watch the results go nuts.

  • Upvote (+1) 3

Share this post


Link to post

Many times when I play late-night (after 3am eastern NA) I experience what I can only describe as the opposite of heavy aim. Game after game it feels as if my sensitivity is crazy high and that I have next to no aim-assist. My reticle feels slippery and seems to just slide away from enemies and will absolutely not snap to players. It feels kind of like I'm trying to shoot someone with camo. I have nearly 5,000 games of arena at a pretty high level and this has been happening quite often recently. Do yall experience this as well?

  • Upvote (+1) 3

Share this post


Link to post

Any chance ghost @@Neighbor or other 343 employees could drop a thanks in the thread for all the time and effort these people are putting into constructively trying to help solve a problem. For all the negative crap this forum gets blamed for please encourage the behavior of these guys.

 

Edit - another thanks from me. Left one a while back but you've all done a lot of work since then. Please keep it up and thanks for not only trying to get to the bottom of this but having the attitude you have throughout.

  • Upvote (+1) 2

Share this post


Link to post

Any chance ghost @@Neighbor or other 343 employees could drop a thanks in the thread for all the time and effort these people are putting into constructively trying to help solve a problem. For all the negative crap this forum gets blamed for please encourage the behavior of these guys.

 

Edit - another thanks from me. Left one a while back but you've all done a lot of work since then. Please keep it up and thanks for not only trying to get to the bottom of this but having the attitude you have throughout.

Sadly 343 isnt going to fix shit

:kappa: them

S/O to OP and others for continuing the research

Share this post


Link to post

Many times when I play late-night (after 3am eastern NA) I experience what I can only describe as the opposite of heavy aim. Game after game it feels as if my sensitivity is crazy high and that I have next to no aim-assist. My reticle feels slippery and seems to just slide away from enemies and will absolutely not snap to players. It feels kind of like I'm trying to shoot someone with camo. I have nearly 5,000 games of arena at a pretty high level and this has been happening quite often recently. Do yall experience this as well?

 

I have experienced this too but i experience this with any game when i start to get really tired and have been playing for a long time.  Everything starts to feel slippery. Generally there is also beer involved, so i dont really count this haha.

 

Any chance ghost @@Neighbor or other 343 employees could drop a thanks in the thread for all the time and effort these people are putting into constructively trying to help solve a problem. For all the negative crap this forum gets blamed for please encourage the behavior of these guys.

 

Edit - another thanks from me. Left one a while back but you've all done a lot of work since then. Please keep it up and thanks for not only trying to get to the bottom of this but having the attitude you have throughout.

 

Unyshek stopped in here within the first few pages but thats all we have heard sadly... :( 

  • Upvote (+1) 1

Share this post


Link to post

Any chance ghost @@Neighbor or other 343 employees could drop a thanks in the thread for all the time and effort these people are putting into constructively trying to help solve a problem. For all the negative crap this forum gets blamed for please encourage the behavior of these guys.

 

Edit - another thanks from me. Left one a while back but you've all done a lot of work since then. Please keep it up and thanks for not only trying to get to the bottom of this but having the attitude you have throughout.

 

 

Sadly 343 isnt going to fix shit

:kappa: them

S/O to OP and others for continuing the research

 

 

I give this thread two thumbs up. 

 

Honestly, here's my stance on the whole situation.

 

Regardless of what heavy aim actually is, whether a single issue within H5's engine, or a collection of issues that culminates in what we see as heavy aim, or more generally aim and input changes that seem to change mid game, I think it's naive to assume 343 hasn't known about them for a while now, as well as having an idea about the cause of it.

 

Now, if that was not that case, I'm not going to lie, I'd love to be the one who blew the cause of it wide open.  There's still the potential for us as a community to independently find the cause, or at least recreate it and measure it, regardless of when/if we get an official response from 343 about it.  However, even if we did so, assuming that 343 has their own direction on this problem already, I don't expect it to immediately result in a fix.  It could, but to do so it would have to be something similar to what I described here: 

 

http://teambeyond.net/forum/topic/15295-i-have-devised-a-way-to-demonstrate-heavy-aim/?view=findpost&p=934470

 

where it is caused by some series of client side actions where a check or a fix could quickly be put in place.  However, all the other theories surrounding heavy aim, such as a CPU bottleneck, or ties to latency, as well as the length of time the issue has been around, suggest a problem that lies far deeper in the engine.  By that I mean it's something that comprises a core component of the engine, where the dependencies upon that module cascade far and wide.  

 

For those who aren't a part of software development, fixing a bug isn't a matter of finding an errant line of code, adjusting a value that's produces the expected behavior, and pushing that code out to production.  Modern software, especially real time networked games such as Halo 5, is comprised of hundreds/thousands of intertwined parts.  It's written in such away that many pieces are developed independently and simultaneously with assumptions and spec defined for controlling their interactions.  Halo 5 itself was in development for something like 3 years prior to launch, and most likely uses components from prior iteration's engines.  If there was some decision made regarding truly foundational level aspects of the engine that have now been found to cause heavy aim, it's potentially not even a monumental task to correct it, it's actually impossible given the dependencies of that piece, and the man power required to correct that.

 

What sort of issue could that be?  In the case of a CPU bottleneck, just about anything.  As I've described a few posts back, H5 is running at 60 frames per second, which means you have ~16.667 milliseconds to calculate what you're doing for each frame.  That means handling player input, updating the physics a single step forward to move players and bullet trajectories and explosion blasts, changing things on the UI, etc.  That all has to happen every 16.667ms, assuming game state updates happen at the same rate as rendering updates (anyone familiar with PC fps and their concept of server tick should recognize this).  Obviously, there's a ton of fine tuning that goes into making all that happen, regardless of what map you're on, forge pieces, number of players, weapons being fired, grenades being thrown, etc. 

 

So what happens when an issue like heavy aim creeps up, and a CPU bottleneck is found to be the cause?  Well, the same thing that would happen during initial development, what do you sacrifice?  Do you make the physics engine less precise?  I'm pretty sure I've read this is the reason for CE's floaty vehicle physics, to save CPU power they cut the number of physic updates in half.  Do you limit the number of weapons on map, or the types of weapons given that calculating a projectile's hit registration costs more than a simple hit scan?  These are all extremely difficult questions to answer, and every single one ends up effecting other choices already made.  

 

Maybe there's a requirement in the animation rigging system that if he were to receive a single millisecond less of CPU time he locks up, so there's a check to make sure he doesn't get halted.  Physics systems, especially in a networked game with replay like we have in H5, are deterministic and very reliant on being able to perform their calculations immediately, so he obviously can't lose any computational time.  Heavy aim might just be the result of checks and balances for ten different absolutely necessary systems that all use up CPU time, such that input handling was the only technically non gaming breaking piece left to try and chop up.  It might not even be that someone deliberately made that choice, but rather it's just the nature of H5's event handler, and how he handles critical calculations vs (technically speaking) non critical ones.  I've often wondered if this the reason medals often seemed delayed, their attached to the game's event queue with a lower priority, basically handle and display/announce them when you've got the cycles to spare.

 

My point is this, when it comes down to it, I want nothing more than to play crispy Halo.  I've put so many years into this series, and Halo 5 has really been a love/hate relationship.  I quickly accepted its movement mechanics and the changes just like I did Halo 4's, however, going on months of playing and just knowing something was fundamentally wrong got me so frustrated I had to take a month long break.  There's nothing more soul crushing than excelling at something for years, and then getting shit on game after game, with trash messages and teabags abound when you just swear that something outside of your control is affecting the outcome.  At this point I assume the lesson has been learned on 343's side, and the issues will be corrected for Halo 6.  That said, I just want validation for myself, my friends, and for everyone else on Team Beyond.  It sounds stupid, because when it comes down to it, it's just a fucking video game.  But I'm sure many others here, like myself, have put radically more time into Halo than any other hobby they have, so that validation, that explanation of what's going on is so, so important.  So until someone else provides it, be it someone else in this thread, or Beyond, or on Waypoint or Reddit, or even 343, I'm going to keep working, and keep trying to prove that I don't just suck.

 

Or, maybe I should just git gud  :lxthul:

  • Upvote (+1) 7

Share this post


Link to post

Honestly, here's my stance on the whole situation...

 

 

I'm not in dev, but do work close enough with software developers that I know it's VERY unlikely this (if it's a thing) could get fixed in h5. My main concern is for h6 and the community relationship. We don't honestly know much about what 343 really thinks about this and so I do have fears problems might exist (real or perceived) in future games...especially if its not tested for with the kind of rigor you guys are trying to use.

 

I think there are a lot of people here who would also like the validation you seek but don't have the skills to help (at least that's the case for me) and are glad to see it being worked on. The reason I've been pushing to get 343 to interact here is because 99% of the posts on this thread are positive...well constructive is probably a better word...and passionate about halo being awesome. I think I like 343 more than many people on beyond and am simply trying to help build a bridge.

 

I get it that asking people publicly to help figure out if a fundamental part of your game is a screwed up is a weird thing (understatement). I mean we struggle with this where I work and we're a dept of 40 that does nothing publicly. But in my opinion this is the type of thing that can really bond a developer and their community if handled well or completely destroy it if handled poorly.

 

And to take a little of my own advice (admitting errors)...I should've messaged 343 guys privately instead of in this thread. The way I posted wasn't really a good way to try to achieve a closer relationship between the two groups, and reading back over my post feels more self serving than anything. (I do appreciate neighbor coming in though).

 

Keep up the hard work and I promise no more posts here outside of encouragement to continue.

  • Upvote (+1) 4

Share this post


Link to post

Honestly, here's my stance on the whole situation.

 

 

Couldn't agree more. Admittedly the bulk of my time playing online was in the Halo 2 and early Halo 3 days but I always played the campaigns multiple times because I've loved the franchise my entire life. I took the day off school to get an og Xbox launch day to play Halo and I was playing Halo 2 on launch day despite that being the same day I moved house. I bought an xbone for MCC and then Halo 5 and went from a dude laying on his couch playing with standard controller to a nerd with a dedicated room, a special chair and monitor, and a custom controller built from scuf, elite and xbone S parts. It's not just a game I play it's the only game I play. I've tried a few other games since Halo 5's release but honestly I just get bored no matter how much I try to enjoy them. There's nothing that comes close to the experience of winning or losing a tight game of Halo when you played at your absolute best.

 

The reason we've all been so determined to demonstrate heavy aim is because we know it's real and it gets in the way of that experience we love. I've always taken 343's silence on the issue to mean that they've known about it all along too. It sounds like some kind of deep and intricate issue that can't be solved easily. It's been 2 weeks since @@Unyshek responded to this thread saying it will be looked into but nothing has come back yet. Some of the things that have been discovered by people in here have taken hours to research and the people looking at them have way fewer skills and resources than people at 343. So again I believe that 343 have always understood the issue but cannot fix it. I've even made the wild suggestion the reason we don't have splitscreen is somehow related to the way the game handles things unexpectedly.

 

I love Halo

 

 

I don't think there was anything wrong with what you said from what I can see you've posted.

  • Upvote (+1) 6

Share this post


Link to post

I wonder if the spec bump in the Scorpio could help narrow the concerns/issues involved with heavy aim (specifically related to the uptick in CPU power)?

Share this post


Link to post

I wonder if the spec bump in the Scorpio could help narrow the concerns/issues involved with heavy aim (specifically related to the uptick in CPU power.

 

I hope not

Share this post


Link to post

I wonder if the spec bump in the Scorpio could help narrow the concerns/issues involved with heavy aim (specifically related to the uptick in CPU power)?

Whilst I'm not exactly sure about what affects heavy aim, it will be interesting to see how the game plays on Scorpio after Halo 6 comes out and the Halo 5 population is much lower.

Share this post


Link to post

It's going to be longer than I expected before I can use this Cronus. I thought I was going to get a week more of free time but my new employers want to move up my start date. I have a ton of things to complete. I'm going to get to it as soon as I take care of these other responsibilities. 

  • Upvote (+1) 1

Share this post


Link to post

This is Josh Menke's response when he was asked about the heavy aiming on Waypoint. I thought it was interesting that he said they know what's causing it. I wonder if it's the same things that people on here think it is or if it's something completely different.

 

In my role I've only heard third or fourth hand about the heavy aim stuff, but I can say it's something being taken very seriously. From what I've heard they know exactly what it is at this point and are working towards a solution. But I don't know how difficult that solution is or how long it would be till we see a fix.

I don't think items are related, but I'm not close enough to the solve to say exactly what it is.

 

https://www.halowaypoint.com/en-us/forums/58b8518e005f432381ab99fbcaf931e0/topics/matchmaking-feedback-update-%E2%80%93-april-17/768a2014-bfac-4f28-a372-7e82d097261d/posts?page=3

  • Upvote (+1) 3

Share this post


Link to post

This is Josh Menke's response when he was asked about the heavy aiming on Waypoint. I thought it was interesting that he said they know what's causing it. I wonder if it's the same things that people on here think it is or if it's something completely different.

 

 

https://www.halowaypoint.com/en-us/forums/58b8518e005f432381ab99fbcaf931e0/topics/matchmaking-feedback-update-%E2%80%93-april-17/768a2014-bfac-4f28-a372-7e82d097261d/posts?page=3

christ, if this problem was in the beta, I could understand, but a YEAR after release

michael-jordan-laugh.gif

I thought the incompetence could only get so high

  • Upvote (+1) 1

Share this post


Link to post

This is Josh Menke's response when he was asked about the heavy aiming on Waypoint. I thought it was interesting that he said they know what's causing it. I wonder if it's the same things that people on here think it is or if it's something completely different.

 

 

https://www.halowaypoint.com/en-us/forums/58b8518e005f432381ab99fbcaf931e0/topics/matchmaking-feedback-update-%E2%80%93-april-17/768a2014-bfac-4f28-a372-7e82d097261d/posts?page=3

Wow you really can ask that dude anything and get a straight answer. I like this guy.

  • Upvote (+1) 3

Share this post


Link to post

This is Josh Menke's response when he was asked about the heavy aiming on Waypoint. I thought it was interesting that he said they know what's causing it. I wonder if it's the same things that people on here think it is or if it's something completely different.

 

 

https://www.halowaypoint.com/en-us/forums/58b8518e005f432381ab99fbcaf931e0/topics/matchmaking-feedback-update-%E2%80%93-april-17/768a2014-bfac-4f28-a372-7e82d097261d/posts?page=3

There was once a time when it didn't exist.

 

Then there was a time where it was a matter of people fixing their sensitivities.

 

Now it's officially a thing.

 

Progress :kappa:

  • Upvote (+1) 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.