With TERMVELOCITY gone, can we now have TWR?

[WazWaz]

TWR is one of the key properties for limiting thrust in KSP 1.0, it seems. I'm currently using:

declare function ShipTWR
{
    set mth to SHIP:MAXTHRUST. // (depends on fixed kOS issue 940)
    set r to SHIP:ALTITUDE+SHIP:BODY:RADIUS.
    set w to SHIP:MASS * SHIP:BODY:MU / r / r.
    return mth/w.
}

This conforms to KER's value.

Nicer would be SHIP:TWR.

[abenkovskii]

I don't think we should provide every possible reading through suffixes. It will make kerboscript interface too complex. What we should do is to provide enough data for users to calculate what they need themselves. You can create a library at kerboscript standard library repository instead.

[erendrake]

@WazWaz i agree with @abenkovskii. derived values like this are very useful but i think it would help us more to have a function that calculates it than a stock suffix. The idea being that more people can fiddle and build their own versions of a kerboscript functions, plus they can see the math that is involved.

now that we have functions i actually hope to find opportunities to move some suffixes we have into kerboscript.

[abenkovskii]

@erendrake > move some suffixes we have into kerboscript.

I don't think that an entry like this: "[BREAKING CHANGE] We had this suffix but then removed it so you now have to edit all your scripts, have fun figuring out the right formula and waste precious disk space" in the change log is a good marketing policy.

[Dunbaratu]

@erendrake, @abenkovskii That's not how it would I would want it work. I wouldn't support such a move until well after there's user classes and user methods, so that it would be possible to have SHIP be a user-land class, and some of its suffixes map to user functions and some map to built-in functions. Which were which would be invisible to the user unless they delve in and have a look. Sort of like using a class library. Many of those methods are just implemented in the same language your own code uses itself, while others drop down into low level assembly opcodes or system calls, but you don't know which unless you delve in and start exploring the code in the library. Is printf() implemented in C or in assembler? :shrug: dunno, don't care. Is List<>:Add() implemented in C# code or directly in .net DLL opcodes? Dunno, don't care. I'd want it to work like that.

I would want to see the language far more developed along before allowing that.sort of a move into user code libraries for existing suffixes. NEW things in the library only - fine- but existing things? No, not until it can be done invisibly, and that requires a lot more sophistication from the language. It would require user classes, and the runtime would have to get off from limited instructions per trigger, otherwise we make people pay for the user instructions and their triggers get longer and start breaking.

[erendrake]

@abenkovskii i think that would be a bad marketing move too and i never suggested we do that. You are presenting this as some kind of binary choice between having it as a simple suffix and a diskspace eating and hard to understand hurdle, which is a false choice. Why shoot down an idea because of the limits that currently exist in the mod when we control those limits? I would think that you would want to have a standard suite of scripts built by the community more than almost anyone. Have you considered that maybe we could have a new kind of read only disk drive that is included with every processor for the 'standard library', a bunch of files curated by the team?

@Dunbaratu i dont agree that it has to wait for the language to be finished before we have any stock functions that obsolete suffixes we have now. For example our current orbitinfo class contains the classical Keplerian orbital elements and the same data expressed as state vectors. I see no reason why we couldnt have one or the other in the orbitinfo as the data that is delivered to you by the OS and have some stock functions that let you convert to the other form. I think it has excellent value for users who want to learn about orbital mechanics and the math involved.

I am not saying that we remove every possible suffix and make people jump through crazy hoops to do simple tasks. It has to be designed and have a reason behind the change. Like everything else we do.

[Dunbaratu]

IMO this argument over what to move into script code is waaaaay too vague and open ended to be an issue in github. It's not focused enough. Close it?