162 replies to this topic

[razenWing]

Bud Crue, on 29 March 2017 - 10:57 AM, said:

Yes within weight classes I don't care if their is variation (I believe this is razenWing's primary beef). I don't want a Warhammer to be the same agility as the supposedly agile Grasshopper. But I would like to see some exceptions within the chassis to make some lesser mechs better. Consider making the 5J more agile than its chassis mates for example. It is this later aspect...much like with their inconsistent application of quirks where I think the decoupling system as currently presented failing. We shall see if they address this in the manner that Chris hints at, but I for one am not hopeful...cuz ya know, PGI's history.

My beef is with unclear implementation and totally in the dark information. Had they do it Khobai's way. A new 65 tonner comes out, I can expect that it will perform the same as an EBJ (say EBJ is the baseline), but then I can scroll over the quirk side and see that it actually got a 20% boost.

"O cool, I am getting something I can expect, and 20% better... let me buy this."

Clear, intuitive... over. I have NO problem with this. I don't care that New Bob 65 is 20% better than it's peers. And this is what I keep trying to tell Quicksilver and have a hard time getting across.

There is absolutely nothing wrong with the way Khobai wants to implement it. In fact, when most people hear "decoupling," I assume that's how most people will assume the implementation as well. I just don't understand how PGI made something this simple, into something complex and unliked. It's frankly unreal.

Quicksilver Kalasa, on 29 March 2017 - 11:03 AM, said:

Because of how it is dependent on engine ratings rather than being a static amount per variant. This reduces the reliance on quirks for low engine cap mechs since the baseline factors in tonnage AS WELL AS stock engine (or lore design).

For example any IS (and any Clan battlemech) mech could have a serious variance across several builds with regards to its agility.

We all want the same thing. That's is what I want as well. I want a trashcan to perform just as well as the ACH. What I don't understand is why are you trying to argue me when my above response to Bud Crue doesn't conflict with your agenda one tiny iota?

If our final goal is the same, all I am saying is for PGI to drop the nonsensical process and give us something that's clear and intuitive. I don't think that's too much to ask.

Edited by razenWing, 29 March 2017 - 11:10 AM.

[Quicksilver Aberration]

razenWing, on 29 March 2017 - 11:06 AM, said:

Clear, intuitive... over. I have NO problem with this. I don't care that New Bob 65 is 20% better than it's peers. And this is what I keep trying to tell Quicksilver and have a hard time getting across.

So your problem isn't with the system, just the visibility, those are two DIFFERENT problems....



While it would be nice if these quirks were more visible, I'm not oblivious to the perception issues those red quirks had way back in the day. Keep in mind there is more stats that aren't clearly detailed just like agility isn't right now. Again why haven't you guys pushed for more detailed information on twist/arm radius differences from baselines, same with engine caps?

Edited by Quicksilver Kalasa, 29 March 2017 - 11:15 AM.

[razenWing]

Quicksilver Kalasa, on 29 March 2017 - 11:08 AM, said:

So your problem isn't with the system, just the visibility, those are two DIFFERENT problems....

Right to some degree. Like let's go back to your GHP and WHM problem. Say PGI set a baseline for 70 tonners. Then they tell you that GHP is going to be 20% more maneuverable. That's very much acceptable.

The problem right now with this whole ETR nonsense, is that you can't expect a same starting point, as there are TWO different baselines... 1 for GHP and 1 for WHM.

This problem is even worse when applied to future mech. New Bob 70... which we can't possibly have any expectation, have an in the dark baseline which is totally unpredictable. You buy it and not like it? Too bad, there's no way to see how it's going to perform beforehand.

[Quicksilver Aberration]

razenWing, on 29 March 2017 - 11:16 AM, said:

The problem right now with this whole ETR nonsense, is that you can't expect a same starting point, as there are TWO different baselines... 1 for GHP and 1 for WHM.

They don't have different baselines, those ETR values are the baseline WITH the quirk baked in. Nitpicking semantics at this point, but it is fairly important to understand that.

I get that the baseline isn't visible because of that which makes things a bit less obvious than setting everything to the same ETR then applying quirks, but functionally they are the same, just presented differently.


Again, it comes down to the avoidance of displaying red text to the user, they are trying to hide the fact that some mechs are getting nerfed.

Edited by Quicksilver Kalasa, 29 March 2017 - 11:20 AM.

[razenWing]

Quicksilver Kalasa, on 29 March 2017 - 11:17 AM, said:

They don't have different baselines, those ETR values are the baseline WITH the quirk baked in. Nitpicking semantics at this point, but it is fairly important to understand that.

I get that the baseline isn't visible because of that which makes things a bit less obvious than setting everything to the same ETR then applying quirks, but functionally they are the same, just presented differently.

Maybe, but the visibility is WAY different, and is the point I'm trying to make.

[Bud Crue]

razenWing, on 29 March 2017 - 11:06 AM, said:

If our final goal is the same, all I am saying is for PGI to drop the nonsensical process and give us something that's clear and intuitive. I don't think that's too much to ask.

Heehee!

I love that we are all just arguing over what exactly we are irritated about...but make no mistake, when it comes to PGI, they will do something, in someway, to some aspect of the game that is assuredly irritating. Nonsensical process? Inconsistent application of rules that they create? The inability to predict future performance based on those rules? Check, check, check.
Add it my personal favorite of -nerfing content that is already substandard- and you have a typical PGI game change proposal. Gotta love it.

[VanillaG]

razenWing, on 29 March 2017 - 10:54 AM, said:

If you are a/gainst a flat baseline, then why are you against the current system then? They are ALREADY adjusting all mechs case by case. Why move from one case by case system to another case by case system?

You seem very reluctant to acknowledge the similarity between what they are doing and what they will be doing.

They are simplifying the balancing issues by taking away the ability of the player to change the mobility by changing engines. Under the current system there are three ways to change mobility; change engine, quirks, skill tree. Removing the change engine ability by decoupling the mobility from engine size and rolling the quirks into the baseline makes it easier to balance. PGI can set the baseline mobility and players can use the skill tree to enhance the mobility. It is a much simpler system than one that encourages people to take the biggest engine possible to get the best possible mobility compounded with quirks and skill tree values.

[Deathlike]

Bush Hopper, on 29 March 2017 - 12:05 AM, said:

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

Outside of the Jenner "movement profile", it's not really that much different than it was before... unless you're actually noticing the effect of the rescaling. That's what you're noticing in any case. It's no different from the next 35 tonner with respects to quirks or agility.

Mind you, all Lights need buffs, especially with respect to accel/decel... but the mechs themselves are no more or less agile since many of them are not quirked as such.

The only other notable event was the efficiency reductions which is probably the only other thing you may be experiencing.

Edited by Deathlike, 29 March 2017 - 03:10 PM.

[oldradagast]

VanillaG, on 29 March 2017 - 12:19 PM, said:

They are simplifying the balancing issues by taking away the ability of the player to change the mobility by changing engines. Under the current system there are three ways to change mobility; change engine, quirks, skill tree. Removing the change engine ability by decoupling the mobility from engine size and rolling the quirks into the baseline makes it easier to balance. PGI can set the baseline mobility and players can use the skill tree to enhance the mobility. It is a much simpler system than one that encourages people to take the biggest engine possible to get the best possible mobility compounded with quirks and skill tree values.

It is "simpler," yes - but it also reduces viable build choices since engine size has far less meaning than before and forces us to trust PGI's understanding of game balance and mech roles far more than before... a concept which is laughable based on experience.

I haven't looked at the exact numbers (has somebody posted them all somewhere?) but are we going to end up with silly things like fire support Banshees being more mobile than brawling Atlases? How will the Kodiak compare to the Atlas? Will the Urbanmech be unplayble because of its tiny stock engine? Will my Awesomes be made back into slugs because "that's the role in tabletop even though it doesn't apply at all in this game?!"

Again, I don't see the benefit. We're reducing player choice and options and replacing it with numbers we basically can't change and which are set by PGI as glorified quirks. That means they are deciding - and hard-locking - our mech roles with these changes. That means fewer build options for mechs - and probably fewer viable mechs overall - and that's not even counting the mechs that end up vastly overpowered or underpowered thanks to PGI's lack of understanding of the game.

Seriously, why are people wanting this game to be even closer to "Quirk Warrior online!" when that's all this is - replacing a logical system with "basic mobility is now a random quirk based on supposed balance and assumed mech roles?"

Edited by oldradagast, 29 March 2017 - 05:43 PM.

[Khobai]

Quote

You don't need to do all of that because you CAN make educated guesses on what will need buffs/nerfs off of that baseline based on existing quirks.

and the point is they should just use existing quirks so everyone knows the deviation from baseline

instead of obfuscating it behind an overly complex and clunky system

Quote

Maybe, but the visibility is WAY different, and is the point I'm trying to make.

exactly its a visibility thing

also theres the fact that red quirks can be eliminated simply by making the least agile mech in each tonnage increment the baseline for that tonnage.

so theres no need for red quirks at all if you do it that way. only green quirks.

Edited by Khobai, 29 March 2017 - 06:00 PM.

[Ultimax]

Quicksilver Kalasa, on 29 March 2017 - 09:41 AM, said:

big reply of stuff

I wanted to just pop in and say I have to bow out, I keep forgetting that I just can't keep up with these kinds of threads anymore. (work/kids)


Thanks for the debate though. (maybe chat about it on TS sometime)

Edited by Ultimax, 29 March 2017 - 06:43 PM.

[Quicksilver Aberration]

Khobai, on 29 March 2017 - 05:58 PM, said:

also theres the fact that red quirks can be eliminated simply by making the least agile mech in each tonnage increment the baseline for that tonnage.

That also makes the least sense, as that could change with new mechs being added, you want the baseline to be independent of whatever outliers may be added in the future. For example the 35 tonner baseline would change with the introduction of the Cougar.

Edited by Quicksilver Kalasa, 29 March 2017 - 07:15 PM.

[Khobai]

Quote

That also makes the least sense, as that could change with new mechs being added.

yeah but its only necessary because you irrationally find red quirks to be a problem in the first place

and its not like the quirks cant be readjusted when new mechs are added that are less agile than existing mechs (which wont be that often). thats kindve the whole point of quirks, theyre easily adjustable.

so it actually makes a lot of sense if you want to avoid red quirks but still give people easy access to information about how much a mech deviates from the agility baseline

again the whole point is transparency of information and not obfuscating things and forcing people to look up charts or compare mechs to find the information they need. you seem to not grasp that.

Edited by Khobai, 29 March 2017 - 07:19 PM.

[Quicksilver Aberration]

Khobai, on 29 March 2017 - 07:15 PM, said:

yeah but its only necessary because you irrationally find red quirks to be a problem in the first place

I don't specifically, there is a reason why PGI stopped doing red quirks though (which I believe connects to why they are obfuscating them).

Khobai, on 29 March 2017 - 07:15 PM, said:

and its not like the quirks cant be readjusted when new mechs are added that are less agile than existing mechs (which wont be that often). thats kindve the whole point of quirks, theyre easily adjustable.

Readjusting quirks with new mechs is how you get errors, sorry but you don't want to add to what you have to manage with a system. I mean, how many times have there been odd quirks across mechs? I work in a devops world, I know how often config errors like that happen.

Khobai, on 29 March 2017 - 07:15 PM, said:

again the whole point is transparency of information and not obfuscating things and forcing people to look up charts or compare mechs to find the information they need. you seem to not grasp that.

I grasp that perfectly fine, and I empathize with it, BUT AGAIN, PGI stopped doing red quirks for a reason, whether they consider that valid or not idk. The big point is, that still doesn't make this system bad which is what this thread REALLY was about.

Edited by Quicksilver Kalasa, 29 March 2017 - 07:21 PM.

[Maker L106]

I mean really if you want to be reassured that those numbers are bogus as **** for the final thing... scroll down to the MAD-IIC... do the math.

300 base... then 67% torso and 37% turn rate?

that's...
... I mean depending on how you calculate your stuff...

300 + 67% of the base 300...
501...

uh... SURE... it'll take a MAD-IIC with that torso twist profile... At any rate its great to see someone from Piranha post in a topic. Thanks for that!

[William Mountbank]

So, guys:

Stock Urbies on STD60 engines, are they going to have the torso twist rate of a UM with a 195 engine?

[Widowmaker1981]

William Mountbank, on 30 March 2017 - 01:41 AM, said:

So, guys:

Stock Urbies on STD60 engines, are they going to have the torso twist rate of a UM with a 195 engine?

Yes.

They will also get oneshot by the first person to see them, because 35 kph light mechs are an extremely poor idea, however fast they twist.

[Duke Nedo]

Why don't they just assign every chassi an agility number between 1 and 5 (3 being baseline) and display that to us? Then they can calculate how many radians/second that should translate to for that particular tonnage behind the hood, I don't need to know anything else than that.

[Almond Brown]

Gas Guzzler, on 28 March 2017 - 02:14 PM, said:

Thanks for that clarification, the intent was to explain the engine to tonnage ratio and what it meant primarily. Its tough to find the latest .pdf for that stuff, I thought that was the most recent, and I couldn't find a more recent .pdf, but I didn't spend an incredible time looking for it.

But given what we know about how folks react to any "numbers" be they real or Trial based, a caveat in the OP, like the nice Dev did, to stem the flow of incoming Salt, one could taste it in the air by page 2.5 ffs would have been prudent.

Thankfully, some understand this and will await another PTS session or the "real #'s" when presented.

[VanillaG]

oldradagast, on 29 March 2017 - 05:42 PM, said:

It is "simpler," yes - but it also reduces viable build choices since engine size has far less meaning than before and forces us to trust PGI's understanding of game balance and mech roles far more than before... a concept which is laughable based on experience.

I haven't looked at the exact numbers (has somebody posted them all somewhere?) but are we going to end up with silly things like fire support Banshees being more mobile than brawling Atlases? How will the Kodiak compare to the Atlas? Will the Urbanmech be unplayble because of its tiny stock engine? Will my Awesomes be made back into slugs because "that's the role in tabletop even though it doesn't apply at all in this game?!"

The problem with the current system is that you can take a heavy mech with a big engine and it will behave like a medium but with more armor/structure while carrying the same amount of weapons. Though I am not a comp player I am pretty sure that hitboxes and hardpoint types/location are more important than engine based agility.

As a general rule mechs of the same tonnage have similar agility profiles with slight deviations and the heavier the mech the less agility it has. So for your Urbanmech example it will have similar agility to other 35 ton mechs and will be more agile than a 50 mech with the same engine.