162 replies to this topic

[Deathlike]

1453 R, on 28 March 2017 - 02:55 PM, said:

Going to try and make this my last post on the subject for the moment, but I'm currently bored at work and we all know how that goes. That said...

How is it not flipping the imbalance? The specific desired intent, as laid out by Fup, was "make small engines viable". That kind of necessitates small engines being every bit as useful as big engines, and if something that weighs half of what something else does is just as useful as the something else...

Well, I've laid out that argument a million times and everyone keeps calling me names over it. But if y'all get your wish and Small Engines are as viable as Big Engines currently are, how is this not a colossal, style-destroying giganerf to 'Mechs that rely on having a significant mobility advantage over their larger, slower targets but now no longer do because all their mobility was stripped from them by the change?

That sounds an awful lot like a flipped imbalance to me.

You keep assuming that small engines are a thing. They really aren't even if you decouple agility since the most important aspect that continues to be most important is top speed of a mech (a theme you have been ignoring). When you cannot get from Point A to Point B effectively, top speed is where it's at. There is NO benefit to a mech if it takes forever to get into position (aka the Dire Wolf dilemma - it's also an ineffective short range brawler for that reason too). Saving tonnage for one more laser or DHS can literally not be worth it with sub-250 engines on big mechs... something you SHOULD be able to see on good builds (not just metamechs).

[oldradagast]

Deathlike, on 28 March 2017 - 04:05 PM, said:

The thing is, it's important to have a good idea AND a good implementation of it.

I've seen very little of the latter (which is where most complaints come from), but occasionally the former being like RNGesus (minimap, Ghost Heat v2/Energy Draw, quirks).. it's really about actually having a good design to go with the idea that needs to be done. When you don't have a good design, it looks really half arsed... mostly because it ends up that way.

What I don't understand is what is this supposed to achieve? Every single approach introduces inconsistencies into the game, reduces the number of builds you'll see, or punishes mechs:

• If mobility is based on tonnage, mechs with large engines as part of their unique features get punished relative to mechs with normal size engines. Mechs with tiny engines will also be unfairly rewarded. In short, your Pretty Baby with the 400 engine will be as mobile as a stock Awesome with a 300 engine, despite the huge tonnage cost you're paying, which seems wrong.
  
• If mobility is based on some starting value per chassis, such as stock engine size, we now get a nutty situation where a mech with a larger stock engine will always be more mobile than a mech with a small stock engine, even if the "large engine mech" is actually running the same or smaller engine than the "small engine mech" So, a Kodiak with an XL 350 would more mobile than an Atlas with a Standard 360, which makes no sense.
  
• If mobility is based on "assumed roles" or "balance," we're left with fixed numbers and hopes that PGI understands each mech's role and power level, which is sort of what we have today, but without the logic of "big engine weighs more, but increases mobility."

Not a single one of these choices, to me, makes sense. All of them are inconsistent in some way: why should one 75-ton mech be far more mobile than another one when they weigh the same and have the same size engine? Why should all 75-ton mechs have the same mobility when one has a much larger engine? And all of these options, by reducing the importance of the engine and the tradeoffs involved in engine choice, reduce the number of viable builds (and probably the number of viable mechs) on the field.

I see no benefit to this - it reeks of "change for the sake of change," some dream of punishing assault players, and yet another thing that is going to have to be regularly tweaked heavily with quirks. It also makes less sense to new players than the current system. Your mech's mobility is based on the stock engine size it's no longer carrying?! All mechs of the same tonnage have the same mobility, even though yours has a huge engine?! Come on... none of that makes sense and achieves anything for balance.

Edited by oldradagast, 28 March 2017 - 04:18 PM.

[Ultimax]

FupDup, on 28 March 2017 - 01:11 PM, said:

A higher percent of your total tonnage is irrelevant when the mech spending this "higher percent" still has much more armor, structure, and pod space in spite of that "higher spending."

That's because the ADDER is badly designed, you don't nerf the entire system because there are a few mechs with moronic design choices.

Move into a 250, maintain same % of tonnage spent compared to TBR & SCR and suddenly the light mech is twisting faster than both of them.

So same % spent, ends up with better payout in agility - which is as it should be.


Lastly, there is a limit in how much agility is actually useful on a light mech, that's one of the really silly points in all of this.

I have never once in any match I've dropped in playing an Adder thought "Gee this mech just doesn't twist fast enough".

That's not the problem the Adder, or any light mech, has. The Adders problem is that it's bad medium instead of actually being a real light mech.

The Adder's problem is raw linear speed.


So to benefit some garbo mechs with bad design limits, we are just going to drag the baseline for other classes down (or bizarrely give some mechs the advantages of free engine sizes whether spend the tonnage or not) - and incentivize people taking more guns.

Chris Lowrey, on 28 March 2017 - 02:05 PM, said:

Hey Guys,

Don't want to get in the way of the discussion here, but I do want to clear up a few things.

Yes, those values in the initial .PDF relating to engine to tonnage ratios that you can achieve in the current game. We used these values as a framework to ensure that our engine desync values roughly synced up with values that where achievable in the live game in order to test its overall framework in PTS. And to also ensure that the back end changes done to support engine desync produced comparable results to what players are used to in the live game in a general sense.

But I would not read too much into them past that point. I want to heavily stress the following:

• The values posted in those .pdf's where the values that where utilized in PTS 2. The PTS that introduced engine desync. They are not the latest values that where tested in PTS 2.5. Nor are they accurate to the value changes we are making as a result of the PTS 2.5 feedback.
  
• The purpose of the initial testing values where to test the initial implementation of the back-end changes and monitor if anything breaks. Like Deceleration did. And stress test where the initial baseline started to buckle so we knew where we could start exponentially increasing the per-tonnage baseline values.
  
• Performance will not be exactly 1 to 1 with what you see on live, we have adjusted some base turn values in regards to the performance curve that sees a bit more visible responsiveness at lower speeds.
  
• The skill tree provides higher total mobility bonus' then the current pilot lab. Engine Desync was designed with this in mind, so some values are a bit lower then their live values intentionally to factor in for the additional bump you get from your total investment in the mobility tree.
  
• On the point of the Locust, again, these where initial PTS numbers that we where observing at a macro level. The 7.5 E2T value listed on the .pdf has not been accurate since the initial Engine Desync PTS. Its Engine to tonnage template by PTS 2.5 was set to 11.5 by comparison.
  
• All other lights and mechs with significant mobility quirks received similar bumps.
  
• I want to heavily stress this last part, but this still remains an in-development feature. And as such, all values are NOT FINAL.

Feel free to continue discussion but I have to heavily stress that the posted .PDF's are not an accurate representation of the current tuning in of this feature. Nor is it accurate to what was tested in PTS 2.5.

Thanks for the input Chris.

I'll be giving it a thorough testing and honest, constructive, feedback once it's on test again.

Deathlike, on 28 March 2017 - 03:52 PM, said:

It doesn't make engines less important as top speed then is most important factor (things like previous MW games had allowed you to adjust) instead of trying to make sure the engine you need matches the agility profile desired.

I'm pretty convinced it will reduce the amount of builds with big engines - there is no reason to spend more than you need to if the benefits hit diminishing returns - which they tend to do.

Again, a KDK with a 350 only goes 4 KPH slower than one with a 375 and picks up 4.5 tons for guns. If you don't despeatey need the crit slots in the engine - that's a pretty easy swap.

Edited by Ultimax, 28 March 2017 - 04:31 PM.

[Deathlike]

oldradagast, on 28 March 2017 - 04:12 PM, said:

What I don't understand is what is this supposed to achieve? Every single approach basically reduces the number of builds you'll see or punishes mechs:

• If mobility is based on tonnage, mechs with large engines as part of their unique features get punished relative to mechs with normal size engines. Mechs with tiny engines will also be unfairly rewarded. In short, your Pretty Baby with the 400 engine will be as mobile as a stock Awesome with a 300 engine, despite the huge tonnage cost you're paying, which seems wrong.

I think you're caught up on the literal definition of what this is to accomplish.

For in the case of the Pretty Baby, sure it can equip a 400XL, but is that practical? Not really.

If the other Awesomes didn't have an engine cap, they would most likely end up around using a STD 350, but surely you'd agree that the agility "they should have" should be more than a STD 300 yes? Even as a starting buff, increasing all Awesome agility to a minimum of a 325 engine is probably a good enough start. For the 9M and PB, you could adjust the agility to 360 and 375 respectively, EVEN if their engines are lower. It's not like there's an Awesome meta to speak of (outside of PPC quirked standoffs.

Quote

• If mobility is based on some starting value per chassis, such as stock engine size, we now get a nutty situation where a mech with a larger stock engine will always be more mobile than a mech with a small stock engine, even if the "large engine mech" is actually running the same or smaller engine than the "small engine mech" So, a Kodiak with an XL 350 would outperform an Atlas with a Standard 360, which makes no sense.

Again, we're not literally tied to their stock engines either.

In that specific instance, it makes sense that the agility of the Kodiak MUST be lower than the Atlas. Where that starts is another matter. We can easily start with the Atlas having 340-350 engine level agility, and the Kodiak being 10-25 "engine levels" below that. Adjustments would still have to be made though.

Quote

• If mobility is based on "assumed roles" or "balance," we're left with fixed numbers and hopes that PGI understands each mech's role and power level.

Again, it's all relative though. A Mauler a different beast than the Highlander and the Cyclops just based on hardpoints and effective role. The "needs" of a mech depends a lot on how they compare to each other and you'll still have to reevaluate these things with their bigger or smaller tonned option. A Wubmaster would still have to be compared to a Wubshee... a Dakkashee has to be compared (to a limited extent) to a Dakka Mauler. These scenarios to get figured out by the comp community (I'm not going to trust a random guy's opinion unless there is actual facts/basis backing the logic up). Of course, this actually means PGI needing to listen to their feedback....

Quote

Not a single one of these choices, to me, makes sense. All of them are inconsistent in some way: why should one 75-ton mech be far more mobile than another one when they weight the same and have the same size engine? Why should all 75-ton mechs have the same mobility when one has a much larger engine? And all of them, by reducing the importance of the engine and the tradeoffs involved in engine choice, reduce the number of viable builds (and probably the number of viable mechs) on the field.

I don't see how builds get affected by this. It's not like you magically gain/lose firepower. Top speed (and DHS space) is the only factor builds SHOULD be giving a damn about... so really nothing's affected in the grand scheme of things. At the very least, cite an example that how this would be the case.

Quote

I see no benefit to this - it reeks of "change for the sake of change," some dream of punishing assault players, and yet another thing that is going to have to be regularly tweaked heavily with quirks.

Well, for some, this isn't the way to go. I get that. These things have to be iteratively tweaked based on high level understanding. You can't balance this by Tier 5.

[Quicksilver Aberration]

Gas Guzzler, on 28 March 2017 - 03:39 PM, said:

And you can't really run that loadout with an engine much bigger.

You could probably bump up to a 325 but you are correct, there is a limit, but like I said, the Night Gyr is sort of a special case (Dual Gauss jump tart).

Gas Guzzler, on 28 March 2017 - 03:39 PM, said:

Agility doesn't fix the problem.

No one made it out to be a silver bullet solution.

[Gas Guzzler]

Quicksilver Kalasa, on 28 March 2017 - 04:37 PM, said:

No one made it out to be a silver bullet solution.

I'm just not even sure if it solves anything though. Will have to wait and see final values first I guess.

Edited by Gas Guzzler, 28 March 2017 - 04:49 PM.

[Quicksilver Aberration]

Gas Guzzler, on 28 March 2017 - 04:49 PM, said:

I'm just not even sure if it solves anything though. Will have to wait and see final values first I guess.

It solves the issue of needing quirks on most low engine cap mechs. Just because there are some occasional superstars (MAL-MX90, Night Gyr) doesn't mean they aren't the exception to the rule.

[Johnny Z]

I think this is a great idea.

[Gas Guzzler]

Quicksilver Kalasa, on 28 March 2017 - 04:50 PM, said:

It solves the issue of needing quirks on most low engine cap mechs. Just because there are some occasional superstars (MAL-MX90, Night Gyr) doesn't mean they aren't the exception to the rule.

I'll have to see the final values because as implemented on the PTS, all it does is rename "Agility Quirks" to "Baseline Agility Stats"

[oldradagast]

Quicksilver Kalasa, on 28 March 2017 - 04:50 PM, said:

It solves the issue of needing quirks on most low engine cap mechs. Just because there are some occasional superstars (MAL-MX90, Night Gyr) doesn't mean they aren't the exception to the rule.

So, just raise the engine caps on those mechs; don't rewrite the system.

Again, I'm not seeing it. We go from a system that makes some degree of sense with engine rating and tonnage producing a consistent, logical net result to losing the ability to improve our mechs agility and thus having it locked to some mix of: tonnage, a "ghost engine" that they no longer have, or PGI's understanding of game balance and mech roles.

That's not an improvement. It means, at best, fewer effects of customization (does the game need that?), and more dependence upon what amount to extremely powerful quirks. Because the moment we start picking "numbers that feel right" as the engine rating that determines mech mobility, we've basically turned base mobility into a quirk vs. a logical system. And since all this really is, it can be achieved in the current system with quirks vs. killing my ability to improve mech agility by mounting a larger engine.

Edited by oldradagast, 28 March 2017 - 05:19 PM.

[Baulven]

I am personally also a little concerned at the base line being added via quirks and then the statement that mechs would have a % rating modifier.

What I mean by that is let's say the locust goes off the 160, gets the agility rolled in and they decide that the baseline bonus will be 3 times the normal bonus. The bonus becomes much larger quicker and has a chance of borking the system. I highly doubt the skill tree would have each section have its own values, so you wind up with one sections bonuses being worthless while another chunks is God tier.

[Gas Guzzler]

Baulven, on 28 March 2017 - 05:22 PM, said:

I am personally also a little concerned at the base line being added via quirks and then the statement that mechs would have a % rating modifier.

What I mean by that is let's say the locust goes off the 160, gets the agility rolled in and they decide that the baseline bonus will be 3 times the normal bonus. The bonus becomes much larger quicker and has a chance of borking the system. I highly doubt the skill tree would have each section have its own values, so you wind up with one sections bonuses being worthless while another chunks is God tier.

I'm not really sure what your concern is based off of this. Why would there be a 300% bonus on anything?

[Quicksilver Aberration]

oldradagast, on 28 March 2017 - 05:17 PM, said:

So, just raise the engine caps on those mechs; don't rewrite the system.

So remove uniqueness from mechs?
That is akin to saying, "oh hey, ballistics are the real reason assaults are good, why not just give everyone ballistics"

When you get to the point you are removing restrictions to avoid a certain issue, then something should tell you there is a problem with a foundation. My code smell senses are tingling.

Edited by Quicksilver Kalasa, 28 March 2017 - 05:38 PM.

[FupDup]

Quicksilver Kalasa, on 28 March 2017 - 05:37 PM, said:

So remove uniqueness from mechs?
That is akin to saying, "oh hey, ballistics are the real reason assaults are good, why not just give everyone ballistics"

I think that's a bad example because certain low-tonnage ballistics* would actually be pretty neat to have in the game for the purpose of letting almost everyone use ballistics to some extent.

*Light ACs, Magshots, AP Gauss, Protomech ACs

[Baulven]

Gas Guzzler, on 28 March 2017 - 05:23 PM, said:

I'm not really sure what your concern is based off of this. Why would there be a 300% bonus on anything?

If I remember right they already said they would be adjusting the values on a per mech basis. While 3x is pretty steep it isn't out of the realm of possibility (particularly for weaker chassis) which could inadvertently cause these issues.

[MechaBattler]

Chris Lowrey, on 28 March 2017 - 02:05 PM, said:

Hey Guys,

Don't want to get in the way of the discussion here, but I do want to clear up a few things.

Yes, those values in the initial .PDF relating to engine to tonnage ratios that you can achieve in the current game. We used these values as a framework to ensure that our engine desync values roughly synced up with values that where achievable in the live game in order to test its overall framework in PTS. And to also ensure that the back end changes done to support engine desync produced comparable results to what players are used to in the live game in a general sense.

But I would not read too much into them past that point. I want to heavily stress the following:

• The values posted in those .pdf's where the values that where utilized in PTS 2. The PTS that introduced engine desync. They are not the latest values that where tested in PTS 2.5. Nor are they accurate to the value changes we are making as a result of the PTS 2.5 feedback.
  
• The purpose of the initial testing values where to test the initial implementation of the back-end changes and monitor if anything breaks. Like Deceleration did. And stress test where the initial baseline started to buckle so we knew where we could start exponentially increasing the per-tonnage baseline values.
  
• Performance will not be exactly 1 to 1 with what you see on live, we have adjusted some base turn values in regards to the performance curve that sees a bit more visible responsiveness at lower speeds.
  
• The skill tree provides higher total mobility bonus' then the current pilot lab. Engine Desync was designed with this in mind, so some values are a bit lower then their live values intentionally to factor in for the additional bump you get from your total investment in the mobility tree.
  
• On the point of the Locust, again, these where initial PTS numbers that we where observing at a macro level. The 7.5 E2T value listed on the .pdf has not been accurate since the initial Engine Desync PTS. Its Engine to tonnage template by PTS 2.5 was set to 11.5 by comparison.
  
• All other lights and mechs with significant mobility quirks received similar bumps.
  
• I want to heavily stress this last part, but this still remains an in-development feature. And as such, all values are NOT FINAL.

Feel free to continue discussion but I have to heavily stress that the posted .PDF's are not an accurate representation of the current tuning in of this feature. Nor is it accurate to what was tested in PTS 2.5.

Concise and straightforward. And we get to know that the work on engine decoupling is ongoing. Which bodes well for the possibility of the skill trees.

I really like the cut of this Chris' jib. ...what is a jib anyways?

[El Bandito]

PGI being PGI. Better tweet Russ about this. Decoupling was supposed to help low engine cap mechs, not the other way around.

[Weeny Machine]

Deathlike, on 28 March 2017 - 04:10 PM, said:

You keep assuming that small engines are a thing. They really aren't even if you decouple agility since the most important aspect that continues to be most important is top speed of a mech (a theme you have been ignoring). When you cannot get from Point A to Point B effectively, top speed is where it's at. There is NO benefit to a mech if it takes forever to get into position (aka the Dire Wolf dilemma - it's also an ineffective short range brawler for that reason too). Saving tonnage for one more laser or DHS can literally not be worth it with sub-250 engines on big mechs... something you SHOULD be able to see on good builds (not just metamechs).

I do not agree with you entirely. Top speed is great, don't get me wrong. However, take the Jenner IIC as an example. It drives like a unresponsive school bus and it is terrible at evading fire because of this. My point is: agility plays an important role for lights and mediums. Imo PGI should aim to give those 2 classes superior agility compared to heavies and assaults and give the fatter mechs more armour and structure quirks if need be

That way you would also get a kind of role into this mess for each mech class

Ultimax, on 28 March 2017 - 04:29 PM, said:

I have never once in any match I've dropped in playing an Adder thought "Gee this mech just doesn't twist fast enough".

That's not the problem the Adder, or any light mech, has. The Adders problem is that it's bad medium instead of actually being a real light mech.

Twisting isn't the problem. Being able to take tight and unpredictable turns and decel/accel is important because with that you can actually avoid fire (and speed of course).

Edited by Bush Hopper, 29 March 2017 - 12:08 AM.

[Widowmaker1981]

El Bandito, on 28 March 2017 - 09:14 PM, said:

PGI being PGI. Better tweet Russ about this. Decoupling was supposed to help low engine cap mechs, not the other way around.

It does, in a way. Yeah, low engine cap mechs are slightly less agile than before, but the high engine cap mechs are losing waaaay more.

If you take a starting lineup of sprinters, kick one in the shins and shoot the others in the knee, technically you are helping the one you kicked in the shins.

[El Bandito]

Widowmaker1981, on 29 March 2017 - 03:07 AM, said:

It does, in a way. Yeah, low engine cap mechs are slightly less agile than before, but the high engine cap mechs are losing waaaay more.

If you take a starting lineup of sprinters, kick one in the shins and shoot the others in the knee, technically you are helping the one you kicked in the shins.

I need numbers. Cause I'm not certain just how much difference there will be.