Jump to content

Huge Misconception Regarding Lrm Velocity Stats


26 replies to this topic

#1 Navid A1

    Member

  • PipPipPipPipPipPipPipPipPip
  • CS 2022 Gold Champ
  • CS 2022 Gold Champ
  • 4,931 posts
  • LocationVancouver, BC

Posted 18 January 2019 - 02:04 AM

The velocity stats posted for LRMs do not correspond to the missiles themselves. They correspond to the direct distance by time to target ratio.

Missiles themselves travel at a speed corresponding to the length of the trajectory curve divided by time to target... which is much faster.



basically:

Actual missile velocity = velocity in stats * (curve length/direct distance)

Posted Image
In PTS, missile velocity is the same (as shown above) for both no LOS and LOS cases. Therefore, a lower arc results in a time to target much faster than a 175m/s projectile



FUN FACT:

Most of you know that ATMs in the game use copy/pasted LRM code... right?

I think I don't have to tell you about how fast ATMs have been travelling all this time.... yes, you guessed it.... 350m/s
game stats says 220.

Edited by Navid A1, 18 January 2019 - 09:00 PM.


#2 The6thMessenger

    Member

  • PipPipPipPipPipPipPipPipPipPip
  • Nova Captain
  • Nova Captain
  • 8,045 posts
  • LocationFrom a distance in an Urbie with a HAG, delivering righteous fury to heretics.

Posted 18 January 2019 - 02:12 AM

Posted Image

Well, it does look less of a natural curve and more like a heavily scripted trajectory, with a straight ascend and curved descent.

#3 Navid A1

    Member

  • PipPipPipPipPipPipPipPipPip
  • CS 2022 Gold Champ
  • CS 2022 Gold Champ
  • 4,931 posts
  • LocationVancouver, BC

Posted 18 January 2019 - 02:19 AM

View PostThe6thMessenger, on 18 January 2019 - 02:12 AM, said:

Posted Image

Well, it does look less of a natural curve and more like a heavily scripted trajectory, with a straight ascend and curved descent.


The thing is, in MWO, missile velocity (Only LRM category) is scaled up (about 1.6 times) to counter the extra curve distance.
As it was coded originally and there was only one curve (the higher one), there seems to be one piece of code for all of it.

PGI introduced low curves without changing this part... as a result, every LRM type projectile (like ATMs) fly around 1.6 times faster than the state velocity in game files

Edited by Navid A1, 18 January 2019 - 02:20 AM.


#4 The6thMessenger

    Member

  • PipPipPipPipPipPipPipPipPipPip
  • Nova Captain
  • Nova Captain
  • 8,045 posts
  • LocationFrom a distance in an Urbie with a HAG, delivering righteous fury to heretics.

Posted 18 January 2019 - 06:41 AM

View PostNavid A1, on 18 January 2019 - 02:19 AM, said:

The thing is, in MWO, missile velocity (Only LRM category) is scaled up (about 1.6 times) to counter the extra curve distance.
As it was coded originally and there was only one curve (the higher one), there seems to be one piece of code for all of it.

PGI introduced low curves without changing this part... as a result, every LRM type projectile (like ATMs) fly around 1.6 times faster than the state velocity in game files.


So the 1.6 multiplier is accounted for the higher curve, but the lower curve the 1.6 multiplier is still used.

Lol. PGI needs to straigthen their ****.

That being said, the 1.6 multiplier for the low-curve LRM does get the result of hitting faster. Supposed that we lowered that multiplier, mayhaps we're defeating the point of the low-curve, but if we did removed the multiplier altogether, or just the IDF, the IDF use of LRMs would be too terrible to use, and would need velocity buff anyways.

Edited by The6thMessenger, 18 January 2019 - 06:42 AM.


#5 Verilligo

    Member

  • PipPipPipPipPipPipPip
  • Bad Company
  • Bad Company
  • 789 posts
  • LocationPodunk, U.S.A.

Posted 18 January 2019 - 08:20 AM

View PostThe6thMessenger, on 18 January 2019 - 06:41 AM, said:

That being said, the 1.6 multiplier for the low-curve LRM does get the result of hitting faster. Supposed that we lowered that multiplier, mayhaps we're defeating the point of the low-curve, but if we did removed the multiplier altogether, or just the IDF, the IDF use of LRMs would be too terrible to use, and would need velocity buff anyways.

The 1.6 multiplier onto the new velocity stats is also a ~47% increase in velocity as compared to current... assuming you lowered the current velocity to the new lower arc. 190 * 1.47 = 279.3. 175 * 1.6 = 280. So that matches up roughly with what the PTS notes said and explains how they got their number... unless of course LoS LRMs end up gaining an additional velocity boost ON TOP of the 1.6 multiplier for being at the lower arc. At that low a velocity you'd have to fire an ATM and LRM at the same time and see if they hit the target at the same time, or if the ATM gets there faster. Same time would mean LoS LRMs gain an extra buff on top of the 1.6 multiplier.

#6 Daurock

    Member

  • PipPipPipPipPipPipPip
  • Bad Company
  • 529 posts
  • LocationSouth Dakota

Posted 18 January 2019 - 09:14 AM

Interesting to dive into the weeds on the actual mechanics, but to me this honestly feels like a lot of hand-waving over an incorrect stat shown on a weapon, (In the case of ATMs, possibly for quite a while) more than an actual concern about gameplay.

On the PTS, as best I can tell, IDF LRMs felt like they just as long as always to land, as did ATMs. Perhaps there are those with more compelling evidence than just my feels, but honestly, I didn't feel like ATMs or IDF LRMs felt that different than on live. The ATMs certainly didn't feel like they were moving faster. The only weapons notably different were the direct fire LRMs. Regardless of the spaghetti programming needed to get there, the gameplay function here seems to be working as intended.

Edited by Daurock, 18 January 2019 - 09:15 AM.


#7 Navid A1

    Member

  • PipPipPipPipPipPipPipPipPip
  • CS 2022 Gold Champ
  • CS 2022 Gold Champ
  • 4,931 posts
  • LocationVancouver, BC

Posted 18 January 2019 - 02:30 PM

I'm not calling for buffs or nerfs.

Just pointing this out as a piece of info.

#8 Chris Lowrey

    Design Consultant

  • Developer
  • Developer
  • 318 posts

Posted 18 January 2019 - 04:02 PM

So just an aside, not meaning to disrupt the conversation here.

First off, I'm not going to be able to confirm or deny anything that is theorized here, as this is talking about potential under the hood back-end functionality not available as public information, and as such, is not something I can publicly comment on. But I will say to take this posted information with a grain of salt.

But what I do want to say is that regarding how this impacts game-play I want to make it clear that design settings are a means to an end. We do not blindly tune anything in-game based on spread sheet values, we tune them off of practical effect for what it does in-game, and as such, missile tuning is tuned based on acquiring the desired in-game effect for how they play. If the design intent is we want a certain missile to hit a target at 600 meters under two seconds, it is irrelevant to us what the actual speed number is set to, as long as it produces the intended results we wish to acquire. Which is why we ask for feedback based on in-game experiences.

It does not matter to us what the numbers behind the scenes are set to. What matters to us is what the practical results those numbers produce in the game itself, and if that is enough to accomplish what we set out to do.

#9 TheBossOfYou

    Member

  • PipPipPip
  • Fire
  • Fire
  • 53 posts

Posted 18 January 2019 - 04:33 PM

View PostChris Lowrey, on 18 January 2019 - 04:02 PM, said:

So just an aside, not meaning to disrupt the conversation here.

First off, I'm not going to be able to confirm or deny anything that is theorized here, as this is talking about potential under the hood back-end functionality not available as public information, and as such, is not something I can publicly comment on. But I will say to take this posted information with a grain of salt.

But what I do want to say is that regarding how this impacts game-play I want to make it clear that design settings are a means to an end. We do not blindly tune anything in-game based on spread sheet values, we tune them off of practical effect for what it does in-game, and as such, missile tuning is tuned based on acquiring the desired in-game effect for how they play. If the design intent is we want a certain missile to hit a target at 600 meters under two seconds, it is irrelevant to us what the actual speed number is set to, as long as it produces the intended results we wish to acquire. Which is why we ask for feedback based on in-game play experiences.

It does not matter to us what the numbers behind the scenes are set to. What matters to us is what the practical results those numbers produce in the game itself, and if that is enough to accomplish what we set out to do.


"Missiles travel this fast" is actually what you need to be telling people in the tooltip. There is zero reason to obfuscate this. You don't have to give us the source code to the game, just TELL THE TRUTH.

#10 Chris Lowrey

    Design Consultant

  • Developer
  • Developer
  • 318 posts

Posted 18 January 2019 - 05:03 PM

We do.

As I said, take what you see here with a grain of salt. What is being described here is not how this system is handled under the hood. Beyond that, I cannot provide any further comment.

#11 Navid A1

    Member

  • PipPipPipPipPipPipPipPipPip
  • CS 2022 Gold Champ
  • CS 2022 Gold Champ
  • 4,931 posts
  • LocationVancouver, BC

Posted 18 January 2019 - 05:23 PM

View PostChris Lowrey, on 18 January 2019 - 05:03 PM, said:

We do.

As I said, take what you see here with a grain of salt. What is being described here is not how this system is handled under the hood. Beyond that, I cannot provide any further comment.


Its true that under the hood, something other than what is described might be at work.

However, based on in game measurements and tests, what is described and theorized is light years more accurate in terms of displaying the correct velocity values, compared to ingame UI, (specially for low arc ATMs)

Again, this won't change anything regarding tuning and balance changes, as balance changes should be based on actual gameplay. It is simply an accurate approximation of actual stats, based on actual tests and measurements.

Edited by Navid A1, 18 January 2019 - 05:28 PM.


#12 Kamikaze Viking

    Member

  • PipPipPipPipPipPip
  • 383 posts
  • LocationStay on Topic... STAY ON TOPIC!!!

Posted 18 January 2019 - 05:28 PM

View PostChris Lowrey, on 18 January 2019 - 05:03 PM, said:

We do.

As I said, take what you see here with a grain of salt. What is being described here is not how this system is handled under the hood. Beyond that, I cannot provide any further comment.


if you were allowed to tell us what goes on under the hood it would go a long way towards transparency and community confidence.

#13 Navid A1

    Member

  • PipPipPipPipPipPipPipPipPip
  • CS 2022 Gold Champ
  • CS 2022 Gold Champ
  • 4,931 posts
  • LocationVancouver, BC

Posted 18 January 2019 - 05:39 PM

I just want to point this out.

An example of transparency is what one of your engineers did way back, by explaining something with great detail for everyone to know:
http://www.gamasutra...rior_Online.php


THAT is transparency.

#14 Antares102

    Member

  • PipPipPipPipPipPipPipPip
  • Death Star
  • Death Star
  • 1,409 posts

Posted 18 January 2019 - 06:16 PM

View PostChris Lowrey, on 18 January 2019 - 04:02 PM, said:

It does not matter to us what the numbers behind the scenes are set to.

AKA we have no idea how our own game works because none of us is playing it.

And with enough dedication players can easily figure out exactly how the "code" works.
Using ingame tools like distance measurement, frame accurate video grabbing measuring flight time and measuring arc angle. If somebody came up with all the correct numbers would you then ban him?
For once you could throw the dedicated players (=Navid A1) a bone and tell them the truth.

Edited by Antares102, 18 January 2019 - 06:21 PM.


#15 Chris Lowrey

    Design Consultant

  • Developer
  • Developer
  • 318 posts

Posted 18 January 2019 - 06:21 PM

So I am not an engineer, I am not the one that set up our internal systems, and as you can see in my title, I am not an in-house employee of PGI. While I am free to speak on matters that I have been cleared to discuss as they pertain to my job, I am on a much tighter leash then others that have been on the team since the beginning, and can speak on such subjects with a much greater degree of certainty then I ever could.

When I say that I am not allowed to give a comment, its not because I'm trying to throw up a barrier, but because I am not actually allowed to discuss a subject beyond what I have commented on. If I gain permission to do so, I would do it as I have on many other subjects I have posted on in the past. But until then, I need to respect the line that has been drawn for me.

#16 Antares102

    Member

  • PipPipPipPipPipPipPipPip
  • Death Star
  • Death Star
  • 1,409 posts

Posted 18 January 2019 - 06:26 PM

View PostChris Lowrey, on 18 January 2019 - 06:21 PM, said:

When I say that I am not allowed to give a comment, its not because I'm trying to throw up a barrier, but because I am not actually allowed to discuss a subject beyond what I have commented on.


If you are not allowed to discuss, don't comment...
Dont comment with "I am not allowed to..."
What kind of picture does this provide?
Navid A1 gave a rational to his theory and the only thing you added to the discussion was "no it doenst work that way" without providing evidence. Just saying "no it does not work that way" could also very well be "oh crap they know, we have to launch some smoke grenades to sow doubts"

Edited by Antares102, 18 January 2019 - 06:31 PM.


#17 Chris Lowrey

    Design Consultant

  • Developer
  • Developer
  • 318 posts

Posted 18 January 2019 - 06:32 PM

I was specifically asked to comment on this subject by Navid himself.

I just chose to post here instead of the main thread so there was less chance of my response being buried in the mainline thread.

My initial statement is basically as far as I can comment on this as requested. And as I stated in my initial post, on the balance side, the part of this that I can freely comment on, we look at the physical performance in-match, and numbers behind the scenes are a means to an end as to how we want to see them operate in-game.

#18 East Indy

    Member

  • PipPipPipPipPipPipPipPip
  • The Hammer
  • The Hammer
  • 1,207 posts
  • LocationPacifica Training School, waiting for BakPhar shares to rise

Posted 18 January 2019 - 06:36 PM

Guys, guys. This has gone beyond the original observation, which itself was more of a curiosity than some great revelation, and now I'm reading weird accusations of a game designer for an internet missiles cover-up. I mean, step back a second.

Anyone can observe in absolute terms how fast ATMs or LRMs go regardless of how they're programmed. Most players (including me) criticize these weapon systems because under certain conditions they introduce asymmetry that's frustrating to both teams; the exact speed at which they travel is not a big thing, not least evidenced by the hard downvoting of the ATM-related post in the Outreach HPG subreddit this morning.

Seriously, step back and reassess. Ultimately we're talking about feel and gameplay, not numbers.

#19 Antares102

    Member

  • PipPipPipPipPipPipPipPip
  • Death Star
  • Death Star
  • 1,409 posts

Posted 18 January 2019 - 06:39 PM

View PostChris Lowrey, on 18 January 2019 - 06:32 PM, said:



Well, great to see you engaging with the community then Posted Image
Thank you for that! Really appreciated.

View PostEast Indy, on 18 January 2019 - 06:36 PM, said:

... of a game designer for an internet missiles cover-up.

90 days mate 90 days
Also players living on an island
Also Long Tom
Also reducing many buckets
Also Gauss/PPC
Also last PTS were the community said which heat change felt best and now we have even more DPS than before and none of the community feedback was considered (apparently).

Edited by Antares102, 18 January 2019 - 06:47 PM.


#20 The6thMessenger

    Member

  • PipPipPipPipPipPipPipPipPipPip
  • Nova Captain
  • Nova Captain
  • 8,045 posts
  • LocationFrom a distance in an Urbie with a HAG, delivering righteous fury to heretics.

Posted 18 January 2019 - 07:24 PM

View PostChris Lowrey, on 18 January 2019 - 06:32 PM, said:

I was specifically asked to comment on this subject by Navid himself.

I just chose to post here instead of the main thread so there was less chance of my response being buried in the mainline thread.

My initial statement is basically as far as I can comment on this as requested. And as I stated in my initial post, on the balance side, the part of this that I can freely comment on, we look at the physical performance in-match, and numbers behind the scenes are a means to an end as to how we want to see them operate in-game.


I don't want to be mean, but I think it's prudent to just have someone else to talk here. As opposed for the designer (you), who has no liberty or familiarity with how the under-the-hood stuff works, perhaps an engineer that worked with the code could entertain us instead, humor us with the theories we have.

Edited by The6thMessenger, 18 January 2019 - 07:47 PM.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users