Jump to content

Misses Registering As Hits Since Friday (7/26/13) Mini Patch


28 replies to this topic

#21 xDeityx

    Member

  • PipPipPipPipPipPipPip
  • 753 posts

Posted 29 July 2013 - 06:38 AM

View PostKunae, on 29 July 2013 - 06:25 AM, said:

10-20 seconds? You are exaggerating, I presume.

Depending on the mech, I have seen it take close to 5 seconds, at times.


He probably gets the savior kill bonus from an assist and thinks it finally registered his kill. They should really differentiate between savior kills and savior assists.

I've never seen more than a few seconds of delay for a kill, and the ones that took over 2 seconds I can count on one hand.

#22 JingleHell

    Member

  • PipPipPipPipPip
  • 195 posts

Posted 29 July 2013 - 06:45 AM

View PostxDeityx, on 29 July 2013 - 06:38 AM, said:


He probably gets the savior kill bonus from an assist and thinks it finally registered his kill. They should really differentiate between savior kills and savior assists.

I've never seen more than a few seconds of delay for a kill, and the ones that took over 2 seconds I can count on one hand.


No, you're making unwarranted assumptions based on your own experiences. It's infrequent, to the point that trying to FRAPs until it happened would be a pain in the ***, but it happens exactly as I described. The server "X has killed Y" message will state that someone who's been dead for 10-20 seconds has just killed the last guy they were shooting at.

And no, it won't be spamming out other messages that delay the report either.

#23 Dakkath

    Member

  • PipPipPipPipPipPipPipPip
  • 1,980 posts
  • LocationG-14 Classified

Posted 29 July 2013 - 06:48 AM

Hey guys, Please send in support tickets to Support@mwomercs.com so they can get this in their trouble ticket system.

thanks,
Dak

#24 xDeityx

    Member

  • PipPipPipPipPipPipPip
  • 753 posts

Posted 29 July 2013 - 07:05 AM

View PostJingleHell, on 29 July 2013 - 06:45 AM, said:


No, you're making unwarranted assumptions based on your own experiences. It's infrequent, to the point that trying to FRAPs until it happened would be a pain in the ***, but it happens exactly as I described. The server "X has killed Y" message will state that someone who's been dead for 10-20 seconds has just killed the last guy they were shooting at.

And no, it won't be spamming out other messages that delay the report either.


I'm making an assumption but to say it is unwarranted is incorrect. Occam's razor is what warrants the assumption.

You are making an extraordinary claim that nobody else has reported experiencing. It is customary to provide the extraordinary evidence if you want people to believe your extraordinary claim. Otherwise we will assume that the simplest solution (human error/misunderstanding in this case) is the correct one.

#25 JingleHell

    Member

  • PipPipPipPipPip
  • 195 posts

Posted 29 July 2013 - 07:12 AM

View PostxDeityx, on 29 July 2013 - 07:05 AM, said:


I'm making an assumption but to say it is unwarranted is incorrect. Occam's razor is what warrants the assumption.

You are making an extraordinary claim that nobody else has reported experiencing. It is customary to provide the extraordinary evidence if you want people to believe your extraordinary claim. Otherwise we will assume that the simplest solution (human error/misunderstanding in this case) is the correct one.


So when even the person reporting it states that it happens to them on an extremely infrequent basis, merely that they've observed it, the observation becomes invalid? Nonsense. Lack of evidence isn't evidence of lack. When something is impossible to manually duplicate, and extremely rare, and the only way to provide concrete evidence of it is drastically inconvenient for people who can't check server logs, it's much better to just report it.

After all, this IS a Beta, right?

#26 xDeityx

    Member

  • PipPipPipPipPipPipPip
  • 753 posts

Posted 29 July 2013 - 07:33 AM

View PostJingleHell, on 29 July 2013 - 07:12 AM, said:


So when even the person reporting it states that it happens to them on an extremely infrequent basis, merely that they've observed it, the observation becomes invalid? Nonsense. Lack of evidence isn't evidence of lack. When something is impossible to manually duplicate, and extremely rare, and the only way to provide concrete evidence of it is drastically inconvenient for people who can't check server logs, it's much better to just report it.

After all, this IS a Beta, right?


I'm neither saying that you shouldn't report it nor that the observation is necessarily invalid.

I'm saying that as a /popcorning forum reader I don't believe the problem is as you described, based on my own experiences and Occam's Razor. You may be right, and you should report it, but I'm just going with the odds. I've worked enough tech support and have done enough alpha testing (internal and external) that I've seen the amount of "problems" that actually just end up being human error. Eyewitness testimony is also one of the worst sources of information possible which is why bug reports tend to ask for reproduction steps and videos if possible.

#27 JingleHell

    Member

  • PipPipPipPipPip
  • 195 posts

Posted 29 July 2013 - 07:51 AM

View PostxDeityx, on 29 July 2013 - 07:33 AM, said:


I'm neither saying that you shouldn't report it nor that the observation is necessarily invalid.

I'm saying that as a /popcorning forum reader I don't believe the problem is as you described, based on my own experiences and Occam's Razor. You may be right, and you should report it, but I'm just going with the odds. I've worked enough tech support and have done enough alpha testing (internal and external) that I've seen the amount of "problems" that actually just end up being human error. Eyewitness testimony is also one of the worst sources of information possible which is why bug reports tend to ask for reproduction steps and videos if possible.


Don't get me wrong, I actually understood all of your reasons for skepticism. My complaint was that you made assumptions about what I was stating to have seen, rather than asking questions to attempt to draw out better information.

In my own experiences along those lines, the second you make it appear to be an accusation, you've doomed yourself to obstinacy even when they do finally realize that they're wrong.

Also, I have a gift for finding the bugs that are nigh impossible to manually duplicate in any game. In Eve, I had to turn off audio in-game before shutting down or get a random audio loop that forced me to restart to clear it. (Yes I checked all drivers, yes I ran repair on client, yes my PC is updated and clean.) In BF3 I found a bug involving PB and Realtek Onboard Audio (along with, presumably, some third factor nobody has isolated yet, as these two factors alone are far too common) where the game would crash if anything besides BF3 was using my audio drivers while playing on PB enabled servers.

#28 Gelion

    Member

  • PipPipPip
  • 63 posts
  • LocationSex Dungeon

Posted 29 July 2013 - 07:56 AM

HSR on missiles are definitely out of whack with the rest of anything at the moment. This is in particular relation to srm's which seem to deal damage based on luck than skill, and their damage in an alpha is not as large as chain firing them for some strange reason. PGI needs to get to work on this.

#29 Master Q

    Member

  • PipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 440 posts

Posted 29 July 2013 - 08:04 AM

View PostGelion, on 29 July 2013 - 07:56 AM, said:

HSR on missiles are definitely out of whack with the rest of anything at the moment. This is in particular relation to srm's which seem to deal damage based on luck than skill, and their damage in an alpha is not as large as chain firing them for some strange reason. PGI needs to get to work on this.


Well, on SRMs here's what I have noticed:

- The larger the SRM volley, the larger the spread.
- The tube-matching glitches are causing some other serious issues. On the Victor, 3x SRM6 trying to fire fast-cycle (holding trigger down so the weapons fire as soon as reloaded) on an opponent leads to:

1st volley - 12 SRMs and then 6 followup
2nd volley - 4-6 srms in a cycle volley till it hits 18
3rd volley and beyond - basically chainfire anyways, because the launchers start their reload timer "when the last missile left the tube" and so the first SRM6 is halfway reloaded while the other two are still firing.

Now if you chainfire you get a tighter first spread, followed by properly matched tubing (volley of 6, volley of 6, volley of 6) on the same tighter spread over and over again for some reason. If you're firing at light mechs, a wider spread means more missiles that go wide; if you're firing at larger mechs, a wider spread = less damage than you expected near center mass where you were aiming.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users