Video Link: https://www.youtube.com/watch?v=umqgxERUin4 Before we get started: I am not asking for trichording to be reintroduced. Hi @YogiKlatt-CIG, I have some more trichord limiter issues I would like to raise. For anyone interested in reading part I, that can be found here: https://robertsspaceindustries.com/spectrum/community/SC/forum/4/thread/master-modes-trichord-limiter-fundamentally-flawed/408347 BLUF/ TL;DR: The trichording limiter's radius appears to be inconsistent—even with the same input axes used in the tests. Sometimes it is equal to the highest single-axis acceleration commanded. E.g., if I am giving inputs that equal 13g up and 12g forward, the limiter radius is 13g. But when I give inputs that = 13g up and 14g forward, the limiter is 14g (it should be ~20.1 when boosting in a Gladius). This is a big problem because it means that players cannot adequately "feather" the forward input in order to retain maximum lateral maneuverability. This punishes aggressive players and rewards lateral kiting. The trichord limiter radius should equal the highest possible single-axis acceleration available to the player combining two inputs. E.g., if using forward and up in a non-boosted Gladius, the limiter should = 13g always. If boosted, the limiter radius should = 20.1g. If using back and up, the limiter radius should = 10g, and so on, regardless of the position of the analog inputs. Fixing this would go a long way towards giving players mobility back while retaining the trichord limiter. It would substantially benefit dueling, a recognized problem area with the current Master Modes implementation. Long Version: The issue I am seeing is this: when I mix forward and a lateral, I cannot get >13g until my forward input exceeds a value that would also be >13g… which makes it difficult as a practical matter to feather forward in order to preserve maximum sideways movement (I actually think it is impossible). What should happen instead: when I mix forward and lateral, I can IMMEDIATELY access vector addition up to the highest possible single-axis maximum. What this would do: it would mean that neither forward nor side acceleration would be truncated until the resultant vector exceeds the single axis maximum. The current limiter? What is happening below the limiter edge, the maximum length of an accel line is 10g for an unboosted gladius. The maximum length of the line increases only when the player's forward input hits (what WOULD be) 10.1 g, if only forward was used. And even then, the limiter doesn't actually increase to 13 g unless forward is fully depressed. Illustration using approximate Gladius boosted accelerations: This is a rough plot of the gladius boosted accels. These are the parameters: The X-axis maximum is 13. The Y-axis maximum is 20. The different colored curves are the limiter, assuming: (1) It is a uniform circle (has a uniform radius); and (2) its radius = largest single-axis accel commanded by the player The BLUE curved line represents what I want the limiter to actually do. That is; the limiter radius should be equal to the highest possible acceleration at all times, regardless of what the player commands The result: (1) Vector addition fully preserved until Y exceeds ~15g; and (2) minimizes lost acceleration due to the limiter, improves player mobility (speedcaps notwithstanding) Testing the Current Limiter Behavior: Current limiter behavior is very easy to test if you have analog forward input. (1) Start in NAV mode (2) Using the keyboard, hold boost for a second to bypass the ramp-in (3) Using the keyboard, strafe up (4) Using the analog forward input, add small increments of forward. Observe G-meter. (5) Observe that total Gs will not increase past the boosted upstrafe values until you input > ~12.8g forward. (6) Release Spacebar, observe G meter to verify that the forward value was in fact > 12.8g, AND equal to the limited combined acceleration. Desired Limiter Behavior, Again: At steps 4-5, total Gs should increase as forward is added regardless of the analog input's position until the total G = ~20.1, where the limiter should kick in. Thank you for reading! Edit 1: The problem described in this post may be a bug. One post describing how the trichord limiter SHOULD work is found here: https://robertsspaceindustries.com/spectrum/community/SC/forum/4/thread/master-modes-trichord-limiter-fundamentally-flawed/6647799 . The relevant language is: “In general the tri-chording limiter works by first calculating the allowed trichord accelerations and then limiting the magnitude of that acceleration vector based on the largest allowed limit for all axes.” (Emphasis added). This, to me, sounds exactly like what I propose below. That is not what I am seeing in game. Edit 2: Further testing suggests this is a bug. Testing methodology (2): 1. Spawn Gladius at SPK 2. Manually limit my strafe output using external software (max deflection = 50% thruster output) 3. Swap to Nav Mode. 4. Hold boost to bypass ramp up. 5. Strafe up, full deflection. Observe approx. 6.4g. 6. Add small increments of forward. 7. Observe G-meter increase, comporting with vector addition. 8. G-meter stops increasing at approx. 12.8g. 9. Continue adding forward throttle. 10. Once forward throttle independently exceeds 12.8g, observe Gs increase again. 11. Release strafe input. Observe forward input is > 12.8g and = total G's observed at step 10. Testing Methodology (3): 1. Limited forward to 12.5 boosted using Joystick Gremlin. 2. Boost. Apply forward. observe 12.5g. 3. Begin applying up. Observe vector addition, UP TO 16.0g (so far so good!) 4. Continue applying upstrafe. Observe the combined Gs decrease from 16.0 to 12.8 as more G is added (WHY!!!) Issue council: https://issue-council.robertsspaceindustries.com/projects/STAR-CITIZEN/issues/STARC-109446 Edit 3—probably clearer diagrams This is the ideal limiter scenario: This is what actually happens in my video linked above: