SHIP:MAXTHRUST ignores tweakables

[Schnobs]

I'm using MAXTHRUST as a shorthand for "how much thrust would I have if I set the throttle to maximum", a very useful bit of information that I need in (e.g.) burn time or TWR calculation. However, it doesn't take into account the tweakable settings on engines, making it considerably less useful when engines have in fact been tweaked.

[TDW89]

You can use List Engines to get the data on each engine then have the script do the maths

SET thrustCalc TO FALSE.

ON thrustCalc {
  SET mThrust TO 0. //Ship max thrust with limit modifier
  SET cThrust TO 0. //Ship current thrust
  LIST ENGINES IN engList.
  FOR eng in engList {
    SET cThrust TO cThrust + eng:THRUST.
    IF eng:IGNITION = TRUE AND eng:FLAMEOUT = FALSE {
      SET mThrust TO mThrust + eng:MAXTHRUST * (eng:THRUSTLIMIT/100).
    }.
  }.
  PRESERVE.
}.

then just

TOGGLE thrustCalc.

when you want the info and it will update mThrust and cThrust for you.

edit: not tested and may require tweaking.

[Dunbaratu]

While it's possible to do that, I think MAXTHRUST should pay attention to the thrust limiter tweakable setting. The code was written before engines had thrust limiter tweakables, and it just never was updated to use the new feature when KSP was updated.

[TDW89]

Fair enough. But there are still situations where knowing the maxthrust without the limiter may be useful. For example if you are using multiple engine groups and controlling them with the thrust limit. Would it be possible instead to keep maxthrust as it is, or maybe have it give thrust at current throttle with limits all the way up, and add maxthrottle (or something similar) to give you thrust at max throttle with current limits?

[erendrake]

@TDW89 if we leave MAXTHRUST the same the user can already find the answer from MAX * THROTTLELIMIT. We could simply document how it works and let the user derive it.

[erendrake]

@Dunbaratu I think it gets a little tricky with the tweakables. for SRB and other engines that cannot be tweaked in flight i believe MAX should be after the tweak because that is the maximum thrust that the engine can ever produce.

Im not so sure about engines that can be tweaked in flight because if we do the actual maximum thrust the engine can produce could be more than what MAX says?

[Dunbaratu]

I agree with the need for a MAXTHRUST that really does mean the max possible if all the limits are taken off, not just the max possible at the moment because of limiters. So maybe there needs to be two different named values? One for max thrust if all in-flight tweakable limits are removed, and another for max thrust if you leave all the tweakables where they are any only touch the throttle.

Maybe MAXTHRUSTCRAFT and MAXTHRUSTTWEAK, with the existing MAXTHRUST aliased to one or the other for backward compatibility (probably MAXTHRUSTCRAFT, as that is the current behavior).

[Schnobs]

MAXTHRUST in the sense of "immediately available to the throttle" is something I need all the time, be it to calculate node burn times or to get my current TWR or whatnot.

MAXTHRUST in the sense of "thrust you could have if you untweaked all engines" is a lot more academical. I can't think of a real-life usage example atm (which of course doesn't mean that there are none).

It wouldn't pain me it if the latter could only be gathered by iteration over all engines, but the former ought to be readily available, also for constructs like LOCK THRUST TO THROTTLE * MAXTHRUST.

A true kerboscript solution would be for ENGINE:MAXTHRUST to report the untweaked thrust (multiply by THRUSTLIMIT when applicable, you're looking at that engine anyway), while SHIP:MAXTHRUST returned the tweaked number.

Incidentally, thrustlimit ranges from 1..100 instead of the more common and useful 0..1.

[Schnobs]

That line about a "true kerboscript solution" was meant to be tongue-in-cheek, but on second thought, it 's quite true.

SHIP:MAXTHRUST excludes inactive and flamed-out engines, while ENGINE:MAXTHRUST reports the nominal value regardless of the engines' state. If behaviour with regard to tweakables was similar, it would be in line with the other use cases.

[Dunbaratu]

It occurs to me that my comment about backward compatibility isn't quite true. The original meaning of MAXTHRUST, when it was first implemented didn't make the distinction between "max thrust there might be" versus "max thrust given current state", because there was no such distinction at the time - tweakables didn't exist. Therefore it would not be any more "breaking" of backward compatibility to do it one way or do it the other way. Making it say MAXTHRUST meant "if tweakables were changed to max" is just as breaking-backward-compatibility as doing it the way @Schnobs wants would be. BOTH changes break backward compatibility because the previous meaning, to a certain extent, no longer exists at all in KSP anymore. So it may as well be changed the way Schnobs wants - it's already breaking compatibility the way it is now.

MAXTHRUST in the sense of "thrust you could have if you untweaked all engines" is a lot more academical. I can't think of a real-life usage example atm (which of course doesn't mean that there are none).

Keep in mind that being able to adjust the tweakables from a script is in the future plans. So it's not just academic because in the future people will be able to change the tweakables from the script, so knowing what the max thrust you could get if you maxed them all out is probably a thing someone will want to know at some point.

Incidentally, thrustlimit ranges from 1..100 instead of the more common and useful 0..1.

That seems like a bug. I'd rather it fit the same scale as THROTTLE uses. It would make a lot more sense. It slightly breaks backward compability, but I don't think anyone is using the feature except you anyway.

[Schnobs]

One can set tweakables already. Although it says clearly in the docs that this wouldn't work, I tried anyway... and found that I can, in fact, set the thrustlimit on engines (at least on the big Kerbodyne clusters, didn't try with any other engines).

Untweaked thrust is something you can gather once and treat as a constant for the time being; it won't change until the next stage or flameout. This doesn't mean that I'm opposed to a built-in that returns untweaked thrust; but if there will be only one built-in to return either tweaked or untweaked thrust, I know which one I'd prefer.

(Don't know if built-in is even the right term, but I hope you get what I mean)

[Dunbaratu]

You cannot just adjust any tweakable you feel like. thrustlimit is a special case and it doesn't work via the tweakables interface. You can't, for example, turn on an individual light by itself, or turn off the suspension of a landing leg. that ability is what's planned for the future - to adjust anything you can click on in the context menus for parts.

[TDW89]

@Schnobs

I can't think of a real-life usage example atm

The script i am working on at the moment is intended to balance a hover craft in 3 axes on 4 independently limited engines (identified by stage) and keep it level without using sas or locking the steering. Once i have the basics working the next stage is to add in the other 3 axes and have the controller give them as vectors and produce a resultant vector for each engine which Infernal Robotics will align them to and fire them at the resultant magnitude.

But that will probably take me through several iterations of kos and subsequent re-writes and optimizations to achieve - i may have bitten off to much :-/

[Dunbaratu]

@TDW89 that sounds like a cool application.

@Schnobs - I think the conclusion I've come to on this issue is this:

There needs to be 2 different types of MAXTHRUST calculated.

The backward-compatible one (the one that is still called by the same name "MAXTHRUST") will be the one that tells you the value based on the current thrustlimit settings.

The new one with a new name will be the one that does what you're finding MAXTHRUST currently does now but shouldn't- provide the answer based on what would happen if you removed all the thrustlimits.

@erendrake - do you agree that this is what we should do?

[erendrake]

@Dunbaratu I am still noodling it in my brain but this is my current idea.

We leave MAXTHRUST as the Maximum thrust that the engine or craft could produce. We add AVAILABLETHRUST that respects throttlelimit.

I had a conversation with a commercial pilot i know about the nomenclature they use in the industry when they talk about flight control and throttle and this is where we landed. I think we can deal with the issue with a comment in the release notes.

[teleksterling]

@erendrake Perhaps as a later enhancement, AVAILABLETHRUST could later also take into account flamed out air breathing engines and the like. (Further refining the idea that MAXTHRUST is what's possible in 'ideal' conditions)

[erendrake]

@teleksterling i think that is a good idea, we have talked about abstracting some of this state for other stuff, why not here.

so this would include

• 0 thrust if you are missing any of your propellants (fuel/oxidizer or mono)
• scale with atmo density for jets?

anything else? The idea being if i floor it how much thrust will i get?

[Schnobs]

I think that a shorthand for "how much thrust could the craft produce" is somewhat pointless. Some engines may be inactive for a reason, being on an upper stage, special-purpose thrusters or whatever. Just adding up all engines of a vessel and returning their combined thrust may be useful for simple vessels, but most of the time, the user will have apply some knowledge about his craft in order to get a meaningful result. On top of that, the number won't change until the next stage; so once the user has gathered the data, he can treat it as a constant for the time being.

"If I floor it how much thrust will I get" is something that can change at any time. So a shorthand for that is definitely needed.

ENGINE:MAXTHRUST should return the nominal maximum, regardless of whether the engine is flamed-out, inactive, or tweaked (in other words, just leave it as it is).

SHIP:MAXTHRUST already excludes inactive and flamed-out engines; I propose that it should also account for the tweaked thrust, rather than nominal. If it could handle jets, that would be excellent.

However, jets are tricky; their thrust scales with airspeed, their fuel consumption with either altitude or air pressure (I only have data from Kerbin, would need to test on Laythe to tell for sure). Thrust diminishes when they're short of air, but not by as much as one would expect. And just because the throttle reads 50% right now doesn't mean that you're actually having 50% thrust -- jets take a while to settle on the desired setting. In the context of jets, it would probably be much easier to have just SHIP:THRUST to tell you what your output is right now, rather than trying to get at it through maxthrust-based calculations.

Besides, it would be cool if kOS would let me keep a tally of air available / air needed. The resource panel is quite useless in that regard. But that's another topic for another day.

[Dunbaratu]

@Schnobs, I agree that what you described would be pointless. But what you described has nothing to do with what we described, and you are pretending it can be summarized by the description "how much thrust could the craft produce" when that is NOT in the slightest an accurate label for what you went on to describe. You described a scenario in which all the thrust of all the engines is summed up regardless of how they're staged, and that yields a number that is in fact not achievable ever, because some of those engines have to be disconnected to reach the other engines. They can't be thrusting at the same time because some engines are being occluded by the current stage and thrusting them won't have any effect until the occluding part is removed (and removing it causes other engines to be unusable, so it is not a situation that would be accurately described as "how much thrust could the craft produce". It is physically impossible to produce that number regardless of the piloting actions taken.

What we're talking about here, or were before that post, was the difference between two numbers that are in fact both achievable by the user's actions. One is the number achievable by adjusting only the throttle. The other is the number achievable by adjusting both the throttle and the thrust limiter piloting tweakables. But both, unlike what you described, are in fact achievable by piloting actions.

[Schnobs]

Well, but how do you determine which engines to include in your list? Keep in mind that engines may be toggled on and off at will. If you list the nominal thrust rather than what has been set, will you also include staged-but-inactive engines? These could be switched on again just as quickly as limited engines could be unlimited. And if you assume that the user knew what he was doing when he toggled engines, why do you assume that he didn't when he limited engines?

Why do people toggle engines? Why do people limit engines? Is there any qualitative difference between one and the other?

[Dunbaratu]

There is a massive difference between shutting an engine down versus throttling it down, and putting a max throttle limit on an engine is a case of throttling it down.

You apparently aren't happy with the fact that we have already accepted that it makes sense to add an ability to give MAXTHRUST in terms of pretending that the pilot-set thrust limiters are the actual max, even though the calculation for that is a horrific mess given that thrust won't scale linearly when you do that (). You seem to want to go one step further and have your preferred answer be *the only answer that kOS provides and are now arguing in favor of not allowing any more information than what you want for other people, and I'm going to push back on any such talk.

() In the case where there are more than one engine active and only *some of them are capped at 50%, then the difference between a throttle setting of 40% and 50% (where it alters all of the engines) is bigger than the difference between a throttle setting of 50% and 60% (where it only alters some of the engines). We can provide the tweaked max thrust in this case but it doesn't really work as a linear scaling factor. If the pilot is trying to fiddle that much then they probably need to do the work themselves anyway to get a meaningful number out.

The argument in favor of disallowing people from seeing information because there's edge cases it doesn't work for works just as well against your preferred result as for the true max throttle result. Either both are okay or neither are okay by that sort of argument, because neither one covers all cases perfectly and people can design craft that require manually iterating over things themselves to get a useful result out.

I really don't want to remove information from people, and this is apparently what you're arguing in favor of.

[Schnobs]

"() In the case where there are more than one engine active and only *some of them are capped at 50%, then the difference between a throttle setting of 40% and 50% (where it alters all of the engines) is bigger than the difference between a throttle setting of 50% and 60% (where it only alters some of the engines). "

Last time I tried, it didn't work that way. TEST: Build a simple rocket, then tweak the engine so you end up with a TWR of slightly more than one. (I just tried with a FLT400 tank, probe core, and LV-909 engine, the latter limited to 57%). Put it on the pad and throttle up slowly.

If you were right, the vessel would take off, slowly, as the throttle goes past 60%, and the ship shouldn't get any faster when you throttle up to 100%. But that's not what I'm seeing.

And yes, I'm of the opinion that trying to report "the maximum thrust the ship could have if the player did something or other" is somewhat problematic.

When I asked why people toggle/limit engines, this was not a rhetoric question. I went through all scenarios I can think of and found none where reporting the unlimited thrust would be useful. This doesn't mean that no such scenario exists -- but it probably means that for any actual use case someone comes up with, I can name several where it's pointless, misleading, or even flat out wrong.

That function would be like the proverbial broken clock that is still right twice a day. I'm questioning whether such a thing should be part of kOS. I'm especially concerned about it being misleading.

[Dunbaratu]

If you were right, the vessel would take off, slowly, as the throttle goes past 60%, and the ship shouldn't get any faster when you throttle up to 100%. But that's not what I'm seeing.

That makes it easier, not harder, to report two different numbers, for true max and current max. Thanks for the information, but it's actually detrimental to your argument and favors mine (mine being that both numbers are useful, not just one of them).

And yes, I'm of the opinion that trying to report "the maximum thrust the ship could have if the player did something or other" is somewhat problematic.

That's not an accurate description of the true max thrust number. It would be more accurate to describe it as "the maximum thrust the ship could have if the player didn't do something - that something being the application of an artificial governor limiting the engine's power.

You;re describing it as if the behavior with the thrust limiter turned on is the default. It's not. It's the deviation from the default. The idea that it's harder to calculate the thrust without the limiters turned on is somehow more likely to come out wrong than the calculation with the limiters on is baffling to me. It's the simpler more direct calculation. How can it be MORE likely to come out wrong than the operation that takes MORE work to calculate?

I still can't see the argument that it's wrong to tell people the actual true maximum if they want to query for it. Your argument is based on the notion that it's going to be a misleading incorrect calculation, and that's just not true.

[Schnobs]

This isn't about computation itself being incorrect, it is about the choice of input. I claim that whatever definition for maxthrust you come up with, it will be deficient more often than not.

Why do you assume that the unused thrust of a limited engine is more readily available than the unused thrust of an engine that has been shut down entirely? In both cases the player has reduced the thrust of his vessel. Yet you take the one as a matter of fact, and the other as a kind of aberration, something the player shouldn't have done in the first place. That governor is no more artificial than the on/off switch.

I have used the thrust limiter for the following reasons so far: 1) to balance asymmetric craft/shifted CoM 2) unlimited thrust induced too much wobble, making the vessel uncontrollable 3) the unlimited thrust would have torn my vessel apart 4) to improve the average ISP of my vessel

In cases 1) through 3), the engines have been limited because I can make no use of their full power. Telling me the thrust I'd have if I lifted all limits is quite pointless. Dangerous even, as it reports reserves I don't really have.

As to 4), that's an Eve lifter, using asparagus staging. It has a fair number of efficient aerospikes (ISP 388) in the core, but also a lot of conventional engines (ISP 320) in the outer stages. Each stage is designed to start with an Eve TWR of 2; as it burns out, I have excessive thrust. Rather than throttle all engines, I have kOS reduce the thrustlimit on the low-ISP engines while the aerospikes keep giving their all, hence raising the effective ISP of the craft. This actually makes quite a difference.

From the above list, 4) is the only case where including the unlimited thrust in a calculation wouldn't be flat-out wrong. However, I should maybe point out that in my first approach, I had groups of 1,2,4 engines linked to action groups, toggling them through kOS to shut down any number from 1-7 engines. But as soon as I found out that I can set thrustlimits through kOS, I adopted this as the more fine-grained and hence preferable approach.

Now, both times I was effectively doing the same thing. Yet your idea of MAXTHRUST would return different results depending on whether I toggle individual engines, or limit whole clusters.

@aighost: there will be a max-thrust-available-to-the-throttle-right-now, that has been decided. I'm still making a stink because I believe the old MAXTHRUST to be quite flawed an not worth keeping.

[peterclemenko]

How about max limited thrust as a new command? Then both sides get implementations they like.

On September 13, 2014 2:26:59 PM EDT, Schnobs notifications@github.com wrote:

Why do you assume that the unused thrust of a limited engine is more readily available than the unused thrust of an engine that has been shut down entirely?

---

Reply to this email directly or view it on GitHub: https://github.com/KSP-KOS/KOS/issues/234#issuecomment-55502346

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Dunbaratu]

there will be a max-thrust-available-to-the-throttle-right-now, that has been decided. I'm still making a stink because I believe the old MAXTHRUST to be quite flawed an not worth keeping. BOTH will be available, THAT has already been decided. You're forgetting that it worked just fine and had a well understood meaning prior to the introduction of thrust limiters, and that nothing about the introduction of thrust limiters has somehow changed the fact that it used to be useful. You're claiming a problem that doesn't exist. Until thrust limiters were added, it made sense and was understood. The addition of a new feature doesn't diminish that.

As for what's the difference between a thrust limiter and a shutdown, the answer is obvious. The thrust limiter is a type of per-engine throttle slider, and not a boolean on/off. The difference between the two types of max thrust (which there's no reason both can't be included) is which throttles it's talking about - just the one central throttle or all of them? Once upon a time there was no difference because you couldn't throttle different engines separately from each other. Now you can and so the need arose to split it into two different types of measure - one for maxing out all throttles and one for maxing out just the one combined central throttle alone.

Shutdown isn't a throttle control like a thrust limiter is.

So the definition of the two types of maxthrust are:

• Max you'd get from touching only the central throttle control (singular) and nothing else.
• Max you'd get from touching all the throttle controls (plural) and nothing else.

Neither includes changes that come from things that aren't throttles. Boolean shutdowns are not throttles. Thrust limiters are. They are a way of giving each engine its own separate throttle lever that scales from 0 to whatever the main lever is set to.

@aioghost:

How about max limited thrust as a new command? Then both sides get implementations they like.

That's exactly what the plan already is, and I haven't seen anything yet to change my mind. @erendrake may disagree.

The argument based on claiming that if it doesn't cover every instance that could exist then it should not exist at all is an argument that's dead on arrival with me. I do not agree with that premise, as applying it universally across the board would mean a lot of the aggregate data kOS provides have to be removed, including this new type of maxthrust we'll be adding that assumes the thrust limiter throttles don't move because that doesn't cover every case either. It would be horrible in the case where the user wants to get what he the actual full max thrust with all throttles would be, but first has to adjust all the thrust limiter throttles to max before kOS will reveal the number, which is what would happen if ONLY Schnob's way existed and the old way was removed.

There's lots of places where a value can't cover every use case. Finding some use cases where a value doesn't work as the yardstick for choosing to prevent anyone else from using it either is setting the bar way too low.

[Schnobs]

Nah, if it was merely a case of not covering every instance I wouldn't bother. I'm claiming that it would hardly ever be useful.

Toggling engines is the more common way of reducing a vessel's thrust, if only because it can be done conveniently through action groups, while (un)limiting more than one engine on the fly is pretty much out of the question (now kOS makes it possible, but it's still quite a hassle). I'm used to switching engines on an off just like that, while thrustlimits are something I am stuck with, at least for the duration of the burn. That's why I believe that your definition of MAXPOTENTIALTHRUST would be wrong more often than not.

ITEM: in order to calculate a meaningful figure for SHIP:MAXPOTENTIALTHRUST, you need to have some knowledge about the vessel and the situation.

ITEM: SHIP:MAXPOTENTIALTHRUST isn't exactly hidden. The user can go over engines in enginelist and add up the MAXTHRUST of all engines that are of interest, with the added value that he has an idea of which engines and limits he can take into account.

ITEM: SHIP:MAXPOTENTIALTHRUST isn't volatile. No need to recalculate it every second; you can determine your potential thrust once, store it in a variable, and keep using it until your vessel changes. At which time you have to take a new tally anyway.

Finding some use cases where a value doesn't work

That hurt. I was completely honest in presenting a list of all use cases I ever had. Such a list is naturally incomplete; yet it's the best I have.

[Dunbaratu]

Finding some use cases where a value doesn't work That hurt. I was completely honest in presenting a list of all use cases I ever had. Such a list is naturally incomplete; yet it's the best I have.

You've been presenting an argument that requires a premise you cannot possibly believe is true - that your style of adjusting thrust by toggling engines on and off is so common that nobody else will ever do it differently and use the thrust limiters as the throttle sliders that they clearly are. The UI limitation of KSP that makes it difficult to use the thrust limiters that way is not an issue when writing a kOS autopilot.

The non-removal of that value does not harm your situation one iota. That's why you pointing out how it doesn't fit your situation is an argument that is doomed to fail from the start. The value would have to be useless in all situations for such a drastic measure as you demand to be taken. And I already described why it is useful in some situations.

You do correctly point out that people who want the old style of maxthrust could just iterate over the engines manually to calculate it. But I don't think it's a good idea for you to be making that argument because the exact same thing could be said of the type of maxthrust value you want.

All of your various arguments about how kOS can't predict what the script wants to do with the engines and therefore can't presume to know the pilot's mind work just as effectively against YOUR kind of maxthrust too. It's an argument that naturally leads toward the conclusion "maxhrust should never be calculated at all by kOS", rather than "maxthrust should be calculated my way and only my way." It's not an argument that it's in your best interests to be making if you'd like to see your type of maxthrust get implemented.

As soon as there's a desire to see kOS present a summary total for maxthrust, there must automatically come with that some assumptions about how the piloting is meant to work, and about which various ways to adjust thrust output are going to be assumed to be maleable and which are going to be assumed to be fixed. And that is no LESS true of your style of max thrust than the existing one. BOTH require making those assumptions. So what you're going to get is two different ones - that make different assumptions about that, which will be explicitly documented.

You can argue that two isn't enough and there needs to be more types. But arguing that there should be fewer, narrowed down to JUST the type that fits your piloting assumptions, just comes across as sounding mean and pointless.

[Schnobs]

You've been presenting an argument that requires a premise you cannot possibly believe is true - that your style of adjusting thrust by toggling engines on and off is so common that nobody else will ever do it differently

Not quite. But I assume my cases to be "typical", and anything else to be even more rare than what I have com up with (really, why would you limit an engine in the first place? If you don't need full thrust at the moment, the mainthrottle is far more convenient than tweaking limits; if you'd not want to use that engine in this situation, you'd have toggled it outright; if you'd not need it's full thrust ever, you'd probably have mounted a smaller engine to begin with. Using half of an engine is not an everyday situation).

You seem to think of thrustlimits as just another kind of throttle that can be cranked up to max at any time. I belive that if the limit could be lifted just like that, it would not have been set in the first place. Hence my inistence that the decision to limit an engine should be taken as serious as a toggled engine.

You do correctly point out that people who want the old style of maxthrust could just iterate over the engines manually to calculate it. But I don't think it's a good idea for you to be making that argument because the exact same thing could be said of the type of maxthrust value you want.

The one difference being that "my" value can conceivably change at any time, while yours is constant. I'd also posit that my value has far more use cases than yours.

And frankly, what I really want is that the short-and-handy MAXTHRUST name is given to the function that gets the most use, while the long and winding MAX{SOME_QUALIFIER}THRUST goes to the special-purpose function(s).

[erendrake]

@Schnobs The Delta IV Heavy uses a thrust limiter in its first stage http://en.wikipedia.org/wiki/Delta_IV_Heavy. Its not an every day kind of rocket but its also not a strange idea.

in KSP. for manual launchers that have variable sized payloads, I will sometimes thrust limit engines to tune that stage rather than mucking with the main throttle or removing engines as they are commodity launchers that i dont have to redesign for each launch. I do the same with fuel tanks to limit the burn time so i dont leave junk in orbit.

[erendrake]

After talking to @Dunbaratu and watching this discussion I am going to make the following change

* Insure that MAXTHRUST is correct for engines that are throttle locked as they are not tweakable in flight. 
* Add an AVAILABLETHRUST to both the engine part and the craft that will be the thrust at 100% main throttle.

[Dunbaratu]

Insure that MAXTHRUST is correct for engines that are throttle locked as they are not tweakable in flight.

That is the correct behavior. The value should take into account what would happen if the adjustable throttle limiters were maxed, but not ones that are permanently stuck, as that would give a number that's not possible to ever achieve no matter what the pilot does.

@Schnobs:

I'd also posit that my value has far more use cases than yours.

I keep saying this and you keep not seeming to see it, so I'll make it a separate paragraph to make it stand out and be crystal clear:

Even if your claim that your use case is the majority use case is correct, that would still NOT be a good enough reason for the removal of the old MAXTHRUST.

The bar you have to pass for such a measure to be taken would be this: The number of use cases for the old MAXTHRUST being useful would have have to be zero, not just merely a minority of cases. Trying to convince people that that number is zero when I've already given such an example use case is going to be pretty hard.