Chris Lowrey, on 28 March 2017 - 02:05 PM, said:
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.
Thank you for the information, Chris. I don't think I'll ever agree with the decoupling as a system, but extra information on the implementation is appreciated nonetheless. The only other question I have is regarding the death of the Skill Tree, and if this decoupling change is also effectively dead or if it's in continued testing for future release outside the lost Skill Tree.
FupDup, on 28 March 2017 - 01:56 PM, said:
Your fear is making Option A better than Option B, but you are unknowingly preaching to preserve a system that just does the reserve and makes Option B better than Option A.
...
The problem is that the current system makes it so that Fast is universally better than Slow, even when you account for the "extra firepower" of the slow mech. The Dire Wolf says hello.
The point of decoupling is to try to equalize things.
I've said it before in many ways, and it fits here as well.
Flipping an imbalance is not fixing an imbalance. If Option A is currently categorically worse than Option B, but then a system is introduced which makes Option B categorically inferior to Option A, then nothing has been accomplished save pissing off a lot of people. A fix is required. I do not believe that destroying mobility-focused 'Mechs is that fix and would like to potentially investigate other fix options if any are available.

























