Hello @YogiKlatt-CIG (and others working on MM)—I have another trichord limiter topic I'd like to raise. BLUF/TL;DR: The main problem with legacy trichording was extra pip deflection when combining horizontal/vertical strafes. Example: a legacy gladius, combining up and side, could get about 16.8g—25% more g than its base upstrafe value of 13.4. The problem with MM's trichording limiter is that it reduces horizontal/vertical strafe values when they are combined with a forward strafe. Both of these problems can be fixed by making the limiter apply only to horizontal and vertical strafes, based on the maximum available single-axis acceleration. In other words, if a ship has symmetrical strafe accelerations—up/down/left/right—the "accel space" would look like a cylinder. Non-symmetrical ships would look like a bullet. Image below. The Long(er) Version I. Problems with legacy trichording While the BLUF highlights one specific problem with legacy trichording, there were in fact more than that. To repeat the BLUF point, one problem was that combining horizontal and vertical strafes was, by far, the best way to deflect one's pip. This is because you got "more" acceleration combining the two axes. The second problem was more one of game knowledge: a player that did not know about this mechanic was, defensively and offensively, hamstrung. If you didn't do it, you weren't competitive—period. The third problem with legacy trichording was that it was impossible to perform on controllers without using third-party remapping software. Admittedly, this is more of a problem with how the game handles inputs than with the controller—there are methods for mapping a controller's circular input space onto a rectangular output. II. Problems with current limiter implementation This section will be short, because I have addressed it already in a pair of posts. Part I: https://robertsspaceindustries.com/spectrum/community/SC/forum/4/thread/master-modes-trichord-limiter-fundamentally-flawed/408347 Part II: https://robertsspaceindustries.com/spectrum/community/SC/forum/4/thread/master-modes-trichord-limiter-flawed-part-ii/417031 The short version is that the current MM limiter actively punishes people who attempt to push an enemy target with forward acceleration. Without going into too much detail, this is because the limiter acts upon and restricts the resultant acceleration vector—the "trichord." In turn, that means that aggressive, forward-pushing players lose both forward and horizontal/vertical acceleration in the process. Ultimately, this is a fundamental issue that takes a lot of the "space flight" feel away from our space game. Moreover, until it is fixed, tuning adjustments will not greatly help. CIG could totally scrap the boost speed mechanic, bump SCM speeds up to 500, make SCM speeds an egg—but until the limiter is addressed, it simply will not feel good to players that prefer to fly their ships rather than play an FPS with a ship avatar. III. The compromise solution As noted in the BLUF, my compromise solution is to have the trichord limiter become a bichord limiter. Specifically, it should act upon horizontal/vertical acceleration combinations. Up/left, up/right, down/left, down/right. This is a good solution for a few reasons: It solves legacy's issue of "extra" acceleration when combining horizontal and vertical accelerations. Again—in legacy, this permitted additional pip deflection (defense) and opponent pip control (offense) than any single-axis movement. Therefore, it also solves the related issues of competitiveness and game knowledge. It solves the problems with the modern limiter implementation. The modern limiter acts to restrict both lateral and longitudinal accelerations. This is no good because it puts control of the fight directly in the hands of the more passive player. Instead, my compromise solution makes that equal: both passive/defensive players and active/offensive players would have the exact same access to lateral movement at all times. It is control scheme neutral. It levels the playing field for sticks, keyboards, and—to some extent—controllers (controllers need additional help beyond the scope of this post). For visual learners, I have included a blender model of what the "acceleration space" would look like, in 3D, using the acceleration values of a boosted Gladius: IV. Final Notes Finally, I want to say thank you for reading, and for everyone that has put up with my trichord limiter chats to date. The upside to all of this is that I think this is a solution CIG can implement—with changes to how IFCS interprets combined inputs. Moreover, I think this is a solution that, in addition to ship/speed wall tuning, will make a flight model that everyone can enjoy. Lastly, I just want to implore CIG—even if you don't adopt this particular proposal, the issue with the limiter identified in my second post really needs a look. Moreover, I would like to implore you to investigate other possible limiter implementations. Thanks again.