162 replies to this topic

[Gas Guzzler]

Quicksilver Kalasa, on 28 March 2017 - 11:41 AM, said:

I don't think that is the full picture, because somewhere else there is another factor otherwise they made Spiders pretty much as agile as Locusts. Either way their numbers were off from what they should've been.

If that is exactly how it works (in that tonnage doesn't actually factor in, that is just something factored into their ETR number), then they set the baseline waaaaay too low for lights and meds and set some of the assaults too high.

I'm confused about the confusion. The ETR takes in to account the tonnage, and spits out an "Equivalent Engine Agility Rating".

So Tonnage * ETR = EEAR

So 55 tonner with an ETR of 5 is as agile as a 55 tonner with a 275 engine in the current game.



A 30 tonner with an ETR of 6.5 is as agile as a 30 tonner with a 195 engine in the current game, etc.

FupDup, on 28 March 2017 - 11:45 AM, said:

I'm kind of thinking that it would be easier to use a system where they set an XML value that makes a mech's agility behaves as if it has a certain engine rating, even if they don't use that engine. E.g. I think most 35-ton mechs should act like they have a 300 engine or so.

We already have a similar thing where some mechs use this method to improve their hill climbing profile, like the Gargles.

That's exactly what this is. 35 tonner with 300 agility has an ETR of 300/35 or ~8.57.

ETR is actually just more clear because you can tell how agile the mech is compared to a mech of any tonnage just by looking at the ETR.

Edited by Gas Guzzler, 28 March 2017 - 12:10 PM.

[FupDup]

Gas Guzzler, on 28 March 2017 - 12:09 PM, said:

That's exactly what this is. 35 tonner with 300 agility has an ETR of 300/35 or ~8.57.

I mean that even stuff like Adders and Panthers should be treated as having the same 300 agility, despite only having 210 and 250 engines respectively.

[Gas Guzzler]

FupDup, on 28 March 2017 - 12:10 PM, said:

I mean that even stuff like Adders and Panthers should be treated as having the same 300 agility, despite only having 210 and 250 engines respectively.

Oh, well this is PGI's way of distinguishing mechs "roles". For instance, Cyclops ends up with a higher ETR than a Mauler, consequently, the Cyclops is known for being a much more mobile assault than a Mauler is.

[Mcgral18]

FupDup, on 28 March 2017 - 12:10 PM, said:

I mean that even stuff like Adders and Panthers should be treated as having the same 300 agility, despite only having 210 and 250 engines respectively.

Which would be an ETR of ~8.5


Seems like a neat system, but the grand majority of the mechs seem to just have used their stock engine, or thereabouts.

[VanillaG]

FupDup, on 28 March 2017 - 11:45 AM, said:

I'm kind of thinking that it would be easier to use a system where they set an XML value that makes a mech's agility behaves as if it has a certain engine rating, even if they don't use that engine. E.g. I think most 35-ton mechs should act like they have a 300 engine or so.

We already have a similar thing where some mechs use this method to improve their hill climbing profile, like the Gargles.

Why would a "Ghost Engine" be simpler than the straight values in the XML? The OP explained that they are using the current engine values to figure out what the starting values should be. We can argue about what those values should be but having those values directly in the XML is significantly better than trying to reverse engineer the current situation.

[Gas Guzzler]

Mcgral18, on 28 March 2017 - 12:14 PM, said:

Which would be an ETR of ~8.5


Seems like a neat system, but the grand majority of the mechs seem to just have used their stock engine, or thereabouts.

Stock engine, or stock engine plus quirks if applicable. It seems quirks were applied in some (most?) cases but not others. Like the Atlas getting stuck with the ETR of 3... those agility quirks got completely ignored, but others didn't.

[Deathlike]

Should it just be said that our balance overlord (or henchmen) still doesn't know what he's doing?

That's what I'm interpreting from all this math talk.

[FupDup]

VanillaG, on 28 March 2017 - 12:16 PM, said:

Why would a "Ghost Engine" be simpler than the straight values in the XML? The OP explained that they are using the current engine values to figure out what the starting values should be. We can argue about what those values should be but having those values directly in the XML is significantly better than trying to reverse engineer the current situation.

The "Ghost Engine" would be an XML value, bruh. The engine decoupling PTS system currently uses a formula with several different variables, while "Ghost Engine" is just a single value that you set in.

Edited by FupDup, 28 March 2017 - 12:28 PM.

[rook]

Am I missing a calculation, then the Sliepner has a ETR = 4.75, Weight = 90 tons, so it should handle like it has a 420 engine?

[Gas Guzzler]

I can excuse things like the Atlas not getting its quirks factored in as it may have been an oversight. A lot of other assaults made out just fine, but I would rather we had no assaults with an ETR of 3. 3.25 should be the minimum IMO.

rook, on 28 March 2017 - 12:30 PM, said:

Am I missing a calculation, then the Sliepner has a ETR = 4.75, Weight = 90 tons, so it should handle like it has a 420 engine?

Yes. If you direct your attention to the large agility quirks that it is losing, it makes sense. The idea is that it will handle closer to a XL360 90 tonner with those quirks added in, which puts it up to that level of agility. Does that make sense? Its the "NuAgility Quirkening".

Executioner also has agility equal to a 95 tonner with a 427 engine (lol) because on live it has an XL380 but has accel/decel/turn rate/twist rate quirks, so the ETR accounts for those quirks.

Edited by Gas Guzzler, 28 March 2017 - 12:37 PM.

[GotShotALot]

Engine/mobility currently has very clear tradeoffs. Sacrifice payload for better mobility, or sacrifice mobility for better payload. These exchanges are quite meaningful in MWO gameplay. Also the whole IS XL/STD tradeoff.

I'm not fully clear on the benefits of the de-synch, but it almost seems to encourage larger mechs to drop engine rating and (potentially) not use XL in order to pack on more DPS/gear, and it semi-penalizes small fast mechs by removing their ability to opt for 'more agility'.

Feel free to enlighten me, but this would seem to disadvantage the least-played mechs while reducing TTK for more-played mechs. I can't really see how that's a good thing?

Edited by GotShotALot, 28 March 2017 - 12:34 PM.

[Deathlike]

FupDup, on 28 March 2017 - 12:28 PM, said:

The "Ghost Engine" would be an XML value, bruh. The engine decoupling PTS system currently uses a formula with several different variables, while "Ghost Engine" is just a single value that you set in.

XML edits could be considered future Lostech... if it wasn't already the case for other instances.

[FupDup]

GotShotALot, on 28 March 2017 - 12:33 PM, said:

Engine/mobility currently has very clear tradeoffs. Sacrifice payload for better mobility, or sacrifice mobility for better payload. These exchanges are quite meaningful in MWO gameplay. Also the whole IS XL/STD tradeoff. The Adder, for example, could upgrade its engine from 210 stock all the way up to 225 with just 0.5 tons from its stock mounted Flamer.

I'm not fully clear on the benefits of the de-synch, but it almost seems to encourage larger mechs to drop engine rating and not use XL in order to pack on more DPS/gear, and it semi-penalizes small fast mechs by removing their ability to opt for 'more agility'.

Feel free to enlighten me, but this would seem to disadvantage the least-played mechs while reducing TTK for more-played mechs. I can't really see how that's a good thing?

It actually doesn't work that way, usually.

On the lower end of the tonnage spectrum, the amount of pod space you gain for reducing your engine size is either literally zero or it's very small like 0.5-1 tons. On the other hand, you lose massive amounts of speed and agility for such small gains.

The reason for this is that there are diminishing returns on both extreme ends of the scale. On the low end, increasing your engine size costs very little tonnage (if any) and thus it is always objectively superior to do so. On the high end, like 375+, then you start paying a lot of weight for not getting much out of it.

If engine size and pod space were an equal tradeoff, wouldn't we be seeing more slow lights and slow assaults? How many lights with a high engine cap choose to intentionally go slow? How many assault mechs with a decent engine cap deliberately go at Dire Wolf speeds?

The answer is that it's not an equal tradeoff. You get more than you pay for in many cases. Going for the bigger engine is clearly superior until you reach a certain point high on the scale. The speed, agility, and heatsink slots easily outweigh the tonnage required in many cases, and in some cases these internal heatsinks allow you to SAVE tonnage by equipping more upgrades like Endo/FF.

The objectives of this whole decoupling initiative are:

1. Make mechs with low engine caps be viable instead of objectively garbage.

2. Allow lower engines to be an actual choice even on mechs that can go higher if they want to.

3. If the baseline values are chosen wisely, give mediums and lights more mobility relative to heavies and assaults (by nerfing and/or buffing one side or the other) to improve weight class balance and reduce the arm's race to get bigger robots. Also helps give mechs on the low-end of their class some sort of advantage over the more armored and more armed mechs on the high-end of their class.

Edited by FupDup, 28 March 2017 - 12:45 PM.

[VanillaG]

FupDup, on 28 March 2017 - 12:28 PM, said:

The "Ghost Engine" would be an XML value, bruh. The engine decoupling PTS system currently uses a formula with several different variables, while "Ghost Engine" is just a single value that you set in.

I am saying put the base values for Accel, Decel, Twist, etc directly in the XML and get rid of the formulas instead of trying to extrapolate those values based off some magic number in the XML. It looks like ETR based on stock engines is the justification for why certain mechs have the values that they do and gives PGI a baseline to keep the values close together.

[Deathlike]

VanillaG, on 28 March 2017 - 12:47 PM, said:

I am saying put the base values for Accel, Decel, Twist, etc directly in the XML and get rid of the formulas instead of trying to extrapolate those values based off some magic number in the XML. It looks like ETR based on stock engines is the justification for why certain mechs have the values that they do and gives PGI a baseline to keep the values close together.

Personally, I think it's "easier" on PGI's end to scale based on the "universal engine formula". There should be some practicality to adjust individual values for differentiation, but that would take a lot more time and effort... and it's not like this hasn't been fumbled before (a decimal place off doesn't take much to make things work funny).

[Ultimax]

Quicksilver Kalasa, on 28 March 2017 - 11:09 AM, said:

You mean a logical system where an Adder and Stormcrow have the same agility because they run the same speed......color me confused.

I don't have time to math it out, but IIRC SCR spends a higher percent of its tonnage vs. tonnage cost of engine (55T vs 19.5?) than Adder does.

So, yes.


I'm not opposed to some baseline boost for light mechs or even mediums for that matter, but the problem in this scenario you've manufactured is that the Adder is locked into an engine size and can't move up to a 250 to spend more tonnage for more speed and more agility.

[FupDup]

Ultimax, on 28 March 2017 - 01:07 PM, said:

I don't have time to math it out, but IIRC SCR spends a higher percent of its tonnage vs. tonnage cost of engine (55T vs 19.5?) than Adder does.

So, yes.


I'm not opposed to some baseline boost for light mechs or even mediums for that matter, but the problem in this scenario you've manufactured is that the Adder is locked into an engine size and can't move up to a 250 to spend more tonnage for more speed and more agility.

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."

[GotShotALot]

Reply to FupDup:

Thank you, that is a good explanation of the potential for the de-synch. In which case, it basically just comes down to PGI picking some reasonable base values, adjusting a few quirks for mech balance and viability, and then using a few iterations and data mining to tweak those values into something resembling a playable mix.

[Quicksilver Aberration]

Gas Guzzler, on 28 March 2017 - 12:09 PM, said:

I'm confused about the confusion. The ETR takes in to account the tonnage, and spits out an "Equivalent Engine Agility Rating".

So Tonnage * ETR = EEAR

So 55 tonner with an ETR of 5 is as agile as a 55 tonner with a 275 engine in the current game.

Then they set things waaaaaaay too low for lights, 8.5 for 35 tonners is a minimum requirement. It looks like they thought the base line should be linear when it should be exponential in some fashion.

[Deathlike]

Ultimax, on 28 March 2017 - 01:07 PM, said:

I don't have time to math it out, but IIRC SCR spends a higher percent of its tonnage vs. tonnage cost of engine (55T vs 19.5?) than Adder does.

So, yes.


I'm not opposed to some baseline boost for light mechs or even mediums for that matter, but the problem in this scenario you've manufactured is that the Adder is locked into an engine size and can't move up to a 250 to spend more tonnage for more speed and more agility.

The thing about the tonnage cost (which at this point is really the benefit/opportunity vs cost argument) is that relative to the Stormcrow, it's actually pretty reasonable for what you're getting back (a 55-ton Clan mech with a 275 engine wouldn't be too shabby either) . In the case of the Adder, you might have more tonnage for weapons, but even 35 ton engine bump on it would essentially make it "stock Jenner speed level", which in the case of Lights in general... pretty huge.