Dunbaratu

Clustering in anything other than the bottommost stage is made highly problematic by the artificial game limitation that a craft must have a tree structure. What putting the clusters in one part does is allow you to have a clustered stage 2 without then requiring maintaining the split all the way to the bottom of the rocket. You can't build a Saturn V clone in stock KSP without such a part because a Saturn V needs to split out to multiple engines in stage 2, then fuse back together into 1 large cylinder again for stage 1's fuel tank, then split out into multiple engines again at the bottom of stage 1. That splitting out and then fusing back together again is unsupported by KSP stock.

Detecting whether or not you are at one of the ascending or descending nodes is detectable with vector cross product math. my normal = my velocity crossed with my soi body position. targets normal = its velocity crossed with (my soi body position - targets position relative to me) node line direction = my normal crossed with targets normal. keep updating them in locks, and wait until my soi body position is parallel to node line direction. What isn't easily detectable because it requires integration by numerical approximation, is the *time* it takes to get to that spot. In general, solving the problem of "how long does it take to get to point X in my orbit" is only easy when dealing with perfectly circular orbits. Once your orbit has any eccentricity to it, that problem becomes messier, so it's better to let the KSP engine do that for you (as it has the logic for this built-in). I'm not in favor of adding easily derivable things, like relative motion vector, which is literally your velocity minus the target's velocity. Closest approach distance, on the other hand, is a pain to derive and it makes sense to show that. (In general I'm annoyed with the fact that the KSP manual flying interface refuses to show that either unless it's near. If your inclination is far off it won't tell you where your nearest approach is. That makes it impossible to efficiently combine inclination correction with transfer burn because you have to correct inclination first just to even see how you're doing on the transfer orbit.) @erendrake - are you thinking that the primary goal for the next feature update should be rendezvous and docking support?

I'm not in agreement with most of what the OP says, but one thing I do agree on is the idea that the existence of a mod that does something should not be used as a reason to avoid putting that something in the stock game. It gets really tiring to hear people falsely claim that having mods means there's no reason for the stock game to have a feature. Mod writers are volunteers who are under zero obligation to make their mods compatible with each other. And sometimes even if they want to do so the task is made much harder by the inability to alter the underlying infrastructure to make commonly shared things use one unified set of code.

At no point did I advocate for there being no limits. I advocated for changing the quantity being measured to use a realistic metric instead. Good indenting and understandable long variable names and having comments are all things that exist only in the source code. They wouldn't make one bit of difference in how big the compiled code is that you'd be loading onto your limited space drive going with the craft. If you have 10k (ish) to work with, you're not going to be wasting that on sending source code. Your source code is going to stay home on the much bigger archive, and on the craft you're only going to send the result of compiling it. The cost should be based on how complex the code *actually* is, not on how much ascii text you used to pretty it up in source code. A token count is a quick estimate that gets much closer to that. (if you mention a variable name it counts as 1 variable. no matter how many characters you used to name the variable. Heck with the kRisc underpinnings it could be possible to *actually* count the compiled code. Hmm. Now that I think of it, with the kRISC underpinnings, it may be possible to *actually* implement a compiler for real - as in save the result of the parse/compile in a separate file on the Archive (perhaps with a ".kex" extension) and then make the terminal allow you to run precompiled program files… hm… that may be actually doable as a future feature.

kOS is not machine code. If you have a higher level language with longer identifier names, structured loops, whitespace indentation, and comments, then those things do not affect the size of the executable you actually install on the craft. A four byte integer called "k" with no explanatory comment takes up no more space than a four byte integer called "thisIsMyVariableName" with a comment written next to it. All the syntactic sugar of whitespace, comments, and long variable names do not take up space in the actual executable. Ironically for your argument, long variable names only started making a difference in compiled code size in *modern* languages like Java and C# where more symbol table information stays in the final compiled file for the purpose of late-binding. Even in assembler comments still don't take up code space after compilation.

You do not need to do both these things every time. You do need to type "switch to 0." each time, but you don't need to keep re-copying the text file each time. It should still be there from last time. If it's getting erased between runs then something is wrong and that's a bug. The in-game text editor was removed as it was getting in the way of more important updates. Something does need to replace it but it will probably involve just calling out to a generic UI text widget. Right now it's not there. It shouldn't be too hard to make a simple shell script or "batch file" to just copy everything into the archive from somewhere else. (I use a perl script that also strips out indents and comments as it does this to help compensate for the fact that kOS rewards you for writing illegible code. - something unrealistic that I never liked but I don't think I can convince the others to change it.) I like the idea of a config option to pick whatever archive location you like.

I've heard some people had success with just aiming based on how high your apoapsis is compared to your current altitude. If the apoapsis is a lot higher than your current altitude, then you've got enough momentum that you need to pitch down. If your apopapsis is not high enough above your current altitude than you're aiming too far horizontally for your momentum and will probably fall back in. So dynamically adjust your pitch to keep your apoapsis-altitude to a fixed constant amount. I haven't tried this technique myself (I use the srqt method similar to what you use) but it seems sound. The problem with picking a fixed pre-determined path is that it doesn't adjust to the different TWR's of different craft. The optimal shape of the path is not the same for every rocket. The apoapsis-altitude thing sounds like a good idea I'd like to try at some point, but at the moment I've shifted focus to joining the devs underneath the hood so I haven't written a new script in a while. (P.S. How did you get the BBCODE [ color ] tags inserted into your posted content like that. I assume you didn't manually type them all in and you have a program doing it for you that's aware of the syntax of kOS.)

You need to make it here. It's not inside the GameData folder, and thus slightly violates the mod installation patter. (I'd like to change this). WHEREVER_YOUR_KSP_HOME_IS/Plugins/PluginData/Archive/ You need to make the archive folder there yourself, as the automatic creation of the folder was accidentally removed from the code (it's back now but that's not released yet). Oh, and don't forget this notice on the front page of this thread:

The grammar file doesn't contain enough information on its own. For example it tells you that a function call is some identifier followed by a left parenthesis followed by a list of arguments followed by a closing parenthesis. It does NOT tell you which identifiers are functions, however. It won't tell you that MIN(x,y) is a built-in function but ASDF(x,y) is not. Similarly it will tell you what an identifier looks like, but not that "STEERING" is a magic built-in identifier while "PILOTING" is not. A lot of the information Rosco needs isn't in that file. This is why I support the idea of not using literal strings directly in the file, but instead using strings defined in a single "identifier file" that's just a simple C# class listing all the language strings that are exposed to a user of kOS (and perhaps their intended syntax in some way), and when you add a new suffix, or a new bound variable, you do it by adding the identifier to the identifier file first, then use the name you gave it there.

What limit? I can't understand the way you worded your question.

This is what I ended up having to do, just because of a problem I didn't know about before I started - KSP configured its drawing layers so that they have distance cutoffs for rendering, and they're set such that if I try to label something with giant letters really far away, the letters refuse to render if they're more than about 1.2 million meters or so from the flight camera (I'm not sure how the heck they get things like the distant Mun to render then - maybe that's on a different layer). But anyway I had to do it with 2d text objects where I project the 3D coordinates into viewport coordinates to figure out where to put the text. You were right, that's what I eventually had to do.

Uhhh... SORT of. It's actually a rotation from the KSP's native XYZ system (this many degrees rotated from whichever way the X axis is pointed, this many degrees away from whichever way the Y axis is pointed, etc). KSP's native XYZ system is a bit messy (Okay it's VERY messy) because of all the weird tricks SQUAD had to do to avoid the floating point precision problems that would come from using large coordinate numbers. It's usually best to force the rotation into a frame of mind you can make sense of, by using one of the existing known rotations first and then adding more rotation after that. For example this: lock steering to up + R(30,0,0). Will pick a rotation that's 30 degrees deflected from whichever way "up" is at the moment in the XYZ coordinate system. That's because "Up" is a special keyword that means "whichever rotation gets you from the Z axis (0,0,1) rotated up to pointing away from the planet center right now." TO make a rotation relative to the ship's current direction, use the special value "FACING", like so: set curFace to SHIP:Facing. lock steering to curFace + R(30,0,0). To rotate 30 degrees off from the current pointing direction. The reason for the extra step of 'set curFace ..." is because if you locked steering to something relative to the current ship facing directly, then it would continually update like that, and keep spinning more and more because it would be constantly saying "always keep trying to point 30 degrees off from whatever you are currently pointing at." Using HEADING() does point the ship according to the navball, but doesn't let you pick the roll. You get whatever you happen to get. For rockets this is fine, but for planes it's not quite enough. If you need to control everything exactly, and do it relative to the ship's own orientation, I recommend giving the RAW controls a try instead. They let your script directly control the craft, as if your script had its "hands" on the W,A,S,D,Q, and E keys, instead of letting the mod try to abstract the work for you. More about it here: http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/ (scroll about halfway down the page to the part entitled "Raw Control".) It's on the list of features to implement "any day now". At the moment a lot of those features are on hold as there's important bug fixes being worked on in regards to user controls getting locked out when they shouldn't be. Several ideas have been bandied about about how to do the auto-run idea, one of which was to let you put commands inside the craft description field in the VAB and they run any time that craft is loaded onto the launchpad. But the idea isn't set in stone yet. But it is true that the devs want to implement some type of auto-loading. At the moment it's not there yet.

Version .66 seems to frequently fail to refund money when using the "circle arrow" button to revert to VAB. I don't know why.

Oh, I don't think it's a good solution. Whatever is wrong needs to be looked at. I was just saying that the fact that this has worked might be a hint about what's going wrong. Triggering the problem (for me) has always required a ship with all its parts right on the central axis (a stack) and once even just a little bit of mass is off that axis the problem seems to go away.

Incorrect. They are against ANY ability to alter the solar system by feeding new numbers into a solar system generation algorithm, regardless of whether those numbers start from a random seed or not. The issue of whether or not the alternate solar system is generated with any randomness or not is irrelevant when they don't even want there to be an alternate solar system possibility in the first place. That part of the game is locked down and not open to any modding work. That argument is based on the false presumption that anything anyone thinks of is equally easy to do in a mod, ignoring the major hurdles that get in your way when trying to do a thing the original software makers didn't want to open up to public modding. Exactly. A lot of the arguments against having any random factors affecting the procedural algorithm are based on the false premise that if you allow some randomness that this means you get nothing BUT utter uncontrolled randomness, which is pure hogwash. You can still bound the randomized factors with sanity checks to avoid things like planets that collide with each other's orbits. You can have weighted algorithms making things more likely to be sane than silly (i.e. a planet's likelihood of being a small solid planet instead of a gas giant varying depending on how close to the sun it is, that sort of thing). The idea that the only two choices are "everything fixed and neverchanging" versus "everything totally silly and haphazard" is immediately dismissible and nonsense.

I get a lot of insane see-saw action from steering as of 0.12 but I don't know the cause of it. I have found that putting some mass radially out away from the center helps a lot. Making a craft that has a larger moment arm for rotations around its main axis, and therefore more rotational inertia seems to make the steering calm down. (i.e. put fuel tanks radially mounted on the side instead of having everything in one narrow stack).

Another in-between idea that contains no random seeds but also isn't fixed would be for SQUAD to open up an API to allow mods to generate a solar system. You'd still have to have manually created and designed planets, but could have more than one of them - a modder could say "I worked for months on my new cool solar system - load it up and have a look".

You are pretending the only two choices are: 1: seed is fixed forever for all games. 2: seed changes every time you load the game. And you know that's false. You can generate a seed when first starting a game and then keep that seed saved with that game. To get a new seed you start a new campaign.

Object Inheritence. More than one kind of Target, more than one kind of Part, etc.

Can you give an example .craft file?

Just an addendum to this, although it's not necessarily about Saturn itself: Because you can do this - make heterogeneous collections like LIST() - it would be nice if kOS supported some sort of an isType() function to help with iterating over such lists. (if this thing is a vector do this, else to that).

I don't think you CAN fix it, because the LIST type holds any generic kOS object of any type and, this is the important bit, is not required to hold heterogeneous types. Keep in mind that this is legal: SET mylist to LIST(). set mylist:ADD to V(1,0,0). set mylist:ADD to 5.1. set mylist:ADD to V(0,1,0). Now, after having done that, is "thing:X" valid inside a "FOR thing in mylist {...}"? The answer is: yes it is on the first and third iteration but not the second one.

Thanks for all your help. I've almost got it done, with one remaining problem: layers. If I draw the arrow on layer 10 it shows on the map but not the flight view. If I draw the arrow on layer 0 it shows up on the flight view but not the map view. I can flip between these layers by detecting whether or not I'm in map view. That's working fine. The problem is that layer 0 seems to have a cutoff distance. KSP doesn't want you to display anything more than about 1.5 million meters away on layer 0. Obviously it's able to show stuff farther away than that in some fashion, because the flight camera lets you see the distant Mun from Kerbin orbit, so there's got to be some sort of layer where it allows it. But I don't know which layer it is. I've tried everything from layer 0 to layer 20 and haven't hit one that works yet. (I was putting my label text on the vector arrow at its midpoint, and then making the scale of the text depend on the distance from the camera, so that when the letters are thousands of kilometers away, they're still visible because they're drawn several kilometers high. that worked great, until I hit this magic cutoff point and the letters just disappear entirely at that distance no matter how big they are.) What I have there so far is workable, I just have to tell users "If your vectors are really big you'll have to switch to map view to see them properly because they'll just go a limited distance and then get truncated in flight view".

I'm not entirely happy with the change because while I can understand the need to make it cleaner, there currently isn't anything else to replace it with, so algorithmic possibilities have been taken away. (Which is a much bigger deal than removing the text editor). If there was a way to specify that a WHEN/THEN shouldn't be removed after it executes once, and should remain in place, then that would provide an alternate way - you'd just put the body of your loop flat in the THEN body without the loop wrapper, tell kOS to preserve the hook and not delete it, and then kOS will keep re-triggering it each time KSP tells the mod to update itself. It would then behave sort of like a loop but slower, only executing once per game update tick. For most of the uses I'm seeing people put it to, that would be plenty fast enough.

If there was a radially-mounted kOS computer part, which of these would be the preferred behavior, I wonder: 1. Steering controls use the computer part's own orientation to decide which way is which. If the part is facing sideways, and you tell it to LOCK STEERING TO UP, it will face the PART's top toward up, not the ship's top toward up. 2. Steering controls use the Vessel's idea of up and down and left and right. The command LOCK STEERING TO UP would point the nose of the ship up, even if it was executed from a radially mounted computer part. Along similar lines I was contemplating if it would be possible to create a tiny part along the lines of the little science sensors, called a Telemetry Sensor, the purpose of which is to be nothing more than a thing that kOS scripts can use to issue a command that says "THIS is where I want my measurements taken from, rather than from the center of the ship." For the purpose of things like POSITION vectors, or altitude queries. It would allow people to place a sensor at the bottom of the ship and use that for the landing altitude, instead of having to have the software hardcode the knowledge of how far the center of mass is from the bottom of the ship.