Quick Questions and (Hopefully) Quick Answers

[Diche Bach]

A lot of forums have a general thread like this that winds up being stickied, and I didn't see one for KSP in these forums. So, while I'm not exactly a "regular" or "old-timer" with any sort of social capital on this forum, I thought it might not be a bad idea, and maybe a mod will sticky it if folks use it.

I myself have like six million questions that have arisen over the summer getting back into playing KSP, and many do not deal with mods where questions specific to those would be more appropriate to their respective sub-forums.

So my first three to start with:

1. What is a "sub-assembly?" Is this stock?

2. When does the game actually load assets?

I ask because two instances struck me as 'peculiar.' A. When I've tried to delete or move files in GameData while game was initialized and in play, it wouldn't let me, which I found surprising as I figured given the time it makes to load (and for ModuleManager to patch things) I figured most of the data was in data structures in the game. Just doing my first course on data structures, so my understanding of this may be out of whack.

B. This morning I launched the game as I was browsing the forums, and decided I'd backup all my ship files, so I could have the liberty to delete the ones I scarcely use any more. Somehow in doing this, I managed to move the directory for my career campaign out of the saves\career directory and into the main KSP directory. Naturally I was puzzled when I went into the SPH and found no craft files!

So, I moved the "ships" directory back to where it belong and PRESTO! even without rebooting the game, there are my craft files again.

3. What language is the source code for this game written in? Reason I ask is, I have a years training in C++, Java, tad bit of JavaScript and PHP, and of course HTML, CSS, XML, doing my first "post-course work" apprenticeship with a 35-year career programmer this fall (I'm 48, early retired professor, and training for second "dream career") . . . Would be good to know how to write plugins for this game, and I probably have the foundation to be able to do it pretty readily at this point.

[Streetwind]

1.) Yes, this is stock. A subassembly is a bunch of parts stuck together and saved as a whole. For example, if you find yourself always using the same booster stage to launch most of your missions from Kerbin, you can save it as a subassembly and then just drag and drop it in completed form under your latest spacecraft.

2.) No clue.

3.) It's written in C#. But note that this game sits on top of the Unity game engine. What that is written in - who knows...

[Foxster]

6 hours ago, Diche Bach said:

2. When does the game actually load assets?

At start of the game. This consumes memory but does mean that once the game is running there is no lag in making use of a part. 

[Snark]

7 hours ago, Diche Bach said:

Would be good to know how to write plugins for this game, and I probably have the foundation to be able to do it pretty readily at this point.

It's super frustrating.  And also heaps of fun.    (Clearly I think the fun part outweighs the frustration, or I wouldn't be doing it myself...)

As @Streetwind says, it's C#.  Since this is .NET land, I suppose in principle you could write a plugin in any .NET compatible language, but in practice everybody uses C#.

If you're interested in getting into modding, the following sub-forum is a good place to start:

http://forum.kerbalspaceprogram.com/index.php?/forum/29-plugin-development-help-and-support/

Not only does it have various stickied threads with helpful links in it, but it's also a good place to post questions if you're trying to write a mod and need to figure out "why does it keep doing X?" or "I want to make it do X, what would I use to do that?"

Another excellent resource is the source code of mods themselves.  Every plugin mod (i.e. every mod with actual code in it) is required by the add-on posting rules to include a link to their source code.  So you can browse around the mods and follow the links to their source code repositories, and see what they actually do!  It's super useful.

[Diche Bach]

21 hours ago, Streetwind said:

1.) Yes, this is stock. A subassembly is a bunch of parts stuck together and saved as a whole. For example, if you find yourself always using the same booster stage to launch most of your missions from Kerbin, you can save it as a subassembly and then just drag and drop it in completed form under your latest spacecraft.

Sweet! I find myself making repeated use of a little 3 section length of girder reduced to size 30%. I will definitely make good use of that!

@Snark: Thanks! I will look into that stuff. Right now I MUST wrap up my Java III class before my deadline expires, but going ahead, using making some stuff for KSP as a way to get into C# seems promising.

Edited August 8, 2016 by Diche Bach
respond to Snark

[Snark]

43 minutes ago, Diche Bach said:

making some stuff for KSP as a way to get into C# seems promising.

I've really enjoyed modding KSP.  The main thing to be aware of, going into it, is that there's essentially no "official" documentation at all, and even "unofficial" documentation is spotty.  So you should expect to spend a fair amount of time playing "detective" by googling stuff, hunting in forums, looking at unofficial user-created documentation, rummaging through other mods' source code for examples, and occasionally posting questions in the mod development support forum to ask folks how to do things.  And even then, expect your mod to fail cryptically for reasons that are hard to understand until you do more detective work to figure out why, and then correct it.  It's not like being handed a well-documented SDK where you just sit down, read the instructions, and follow them.

In other words:  gotta have a pretty high tolerance for spadework.    The good news is that you're in lots of excellent company.  When I get genuinely stumped no matter how much I search (which has happened several times), I just post in the support forum for mod development, and someone generally has an answer pretty quickly.  The modder community is amazing, they're really friendly and helpful people.

 

[Diche Bach]

@Snark: Kewl, looking forward to it. The stuff I'll be doing with my mentor this fall will be all C++, and likely more "turn-based" historical military strategy game engine building. He has lots of ideas and is keen to have an apprentice to implement them and learn by doing.

Fiddling with KSP to get a bit of a handle on C# might well prove to be a nice break from the above.

No intent to keep studying Java: I got the basics and I just don't like the language for some reason. I'd take a job in it if it were a good one, and I'm sure I could be just as good with it as with the C-based ones, but it isn't my preference . . . which sort of sucks because I understand it is much easier to get an entry level position for Java developer than for C++ . . .

May also keep my toe in the water on the Stellaris and Distant Worlds modding scenes, but gotta keep an optimum number of irons in the fire . . .

-=-=-=-=-=-

ADDIT: and so back to the quick questions!

1. Does TWR have any real impact outside of an atmosphere? Or is it just, "a much smaller significance?"

Obviously at takeoff from KSC, anything too close to / less than 1 is problematic, but I sense that in orbit of Kerbin, even a small 0.25 or 0.1 can still be effective at small work.

2. Is there a "Thrust to Mass Ratio?"

3. I notice in the Kerbal Engineer Redux, that there are no default data fields for "target velocity at apoapsis/node/periapsis/intersect."

I'm still just relearning/getting the hang of rendezvous and docking, but it seems like this would be a very useful data to have at hand. Doable? Useful?

4. When I use the merge thing in VAB I sometimes find that, I'm not able to get the piece I brought into to link up. It seems that having docking ports in the mix somehow messes things up, but it still remains cryptic what is going on exactly. I can usually work it out by taking a piece or two OFF the parent assembly and fiddling, but it would be nice to know if there is a well-established "best practices" sort of doctrine for making good use of that merge thing . . . I suppose learning how to use the sub-assemblies might by solution here . . . I've been figuring out how to use that merge thing to reduce my repetition of design elements: e.g., got a probe core with like 15 lengths comprising 10 pieces of size 10% girder, all perfectly aligned and ready to be used to create super-structures an the like . . . Using the Ctrl-Z to replicate parts might even be quicker though? (remove piece and place it in the air in VAB, then use Ctrl-Z to restore the piece(s) you just removed est voila! copy of first piece ready to go!

Edited August 8, 2016 by Diche Bach
"quick" questions

[Snark]

Just now, Diche Bach said:

No intent to keep studying Java: I got the basics and I just don't like the language for some reason. I'd take a job in it if it were a good one, and I'm sure I could be just as good with it as with the C-based ones, but it isn't my preference . . . which sort of sucks because I understand it is much easier to get an entry level position for Java developer than for C++

Nerd rant in spoiler section 'coz it's getting kind of off-topic.  Good luck with C# and modding!

Spoiler

I strongly dislike Java myself, for various technical reasons not worth getting into here.  For context, I've been a professional software engineer for over 20 years, came out of a C / C++ background until managed code started poking its nose in.  For the last 7 years or so, my professional work has been almost entirely in Java-- not that I like it, it's just that that's where most of the code is these days in the space that I work in.

I like C# much better.  Semantically it's extremely similar to Java; if you're coming from an unmanaged background (e.g. C++), Java and C# will look practically the same to you, just with some different keywords (e.g. Java says "final", C# says "readonly").  For perspective, I was a professional C# programmer for several years before I ever touched Java; then I switched to a different company that did everything in Java, and on Day 1 had to start programming in a language I'd never seen before.  It was similar enough to C# that with a bit of googling I was holding my own within a day or two.

The reasons I like C# so much better than Java are technical in detail and not really worth getting into, though if you do a Google search on the terms "java", "type erasure", and <expletive of your choice>, you'll pick up at least some of the angst. 

In any case... the good news is that time you spend learning to develop in Java isn't wasted, even if your goal isn't to program in Java.  It's a skillset that's about 95% portable to C#.

 

[Diche Bach]

5. Any good tips on achieving an effective "sub-orbital" flight to complete those "Tourist over North/South Pole" missions.

I get a lot of these missions, and they tend to pay well. The sub-orbital part is not hard at all, but I find it is hit-and-miss on getting the arc to go OVER the actual pole. Trying to line up the arc of the flight using the map view location marker seems inconsistent at best.

6. Where is the "point" on those map view location makers? is it the tip of the cone below the circle or somewhere in between?

[Superfluous J]

53 minutes ago, Diche Bach said:

5. Any good tips on achieving an effective "sub-orbital" flight to complete those "Tourist over North/South Pole" missions.

I get a lot of these missions, and they tend to pay well. The sub-orbital part is not hard at all, but I find it is hit-and-miss on getting the arc to go OVER the actual pole. Trying to line up the arc of the flight using the map view location marker seems inconsistent at best.

6. Where is the "point" on those map view location makers? is it the tip of the cone below the circle or somewhere in between?

5. I've never heard of these contracts, but I tend to ignore the tourist stuff because I don't personally find it fun, but this should work fine, I've done it for polar launches before: Do one launch with your rocket, DIRECTLY NORTH. Keep the rocket pointed North throughout the entire burn. Note how many degrees off of the North Pole you are as you pass by it (roughly. Just eyeball it). Revert to launch and launch again, this time turned that many degrees West of North (again, just eyeballing it should be fine).

6. The center of the area in question is at the tip of the cone below the circle, but the entire area is usually several km (I think even as high as 25 or more in some cases) around it.

If you are interested in an elegant mod solution to contract waypoint markers, check out Waypoint Manager. Among several other things, it shows you waypoints on the in-flight screen so you can target them by eye without having to go to map mode.

[Hodari]

7 hours ago, Diche Bach said:

1. Does TWR have any real impact outside of an atmosphere? Or is it just, "a much smaller significance?"

Obviously at takeoff from KSC, anything too close to / less than 1 is problematic, but I sense that in orbit of Kerbin, even a small 0.25 or 0.1 can still be effective at small work.

2. Is there a "Thrust to Mass Ratio?"

4. When I use the merge thing in VAB I sometimes find that, I'm not able to get the piece I brought into to link up. It seems that having docking ports in the mix somehow messes things up, but it still remains cryptic what is going on exactly. I can usually work it out by taking a piece or two OFF the parent assembly and fiddling, but it would be nice to know if there is a well-established "best practices" sort of doctrine for making good use of that merge thing . . . I suppose learning how to use the sub-assemblies might by solution here . . .

1.  The presence of an atmosphere isn't really the issue here, so much as the gravity of the object you're taking off from.  If you're trying to take off from Mun, there's not atmosphere, but if your TWR is too low, you still won't be going anywhere.  And if you're trying to land with too low of a TWR, you'll probably have rather...unpleasant results. 

But yes, other than those situations, TWR is generally far less important since the exact timing of a burn while you're in orbit is far less critical in most cases.  It will still have at least SOME effect since a higher TWR means shorter burn times which will allow more accurate burns and better use of the Oberth effect.  If you're doing a transfer burn or capture burn, you'll probably still want a somewhat decent TWR, but doesn't need to be greater than 1 or anything.  For any burns done in deep space, far away from any planet/moon, TWR can be as low as you want.  This is where the nuclear or even ion engines are ideal since the only limiting factor is how patient you are(too low of a TWR can mean a burn of 20+ minutes).

2.  Never seen it mentioned or used anywhere, but it's effectively going to be the same as TWR as long as you're always talking about the TWR with respect to the same planet.

4. It's probably because with subassemblies at least(not sure about merging) you can only connect it by the "root part".  This will usually be the first part you added, but you can change it to whatever part you want.  Make sure that before saving your subassembly, you change the root part to whichever part you want to use to attach it to your main craft.

[Streetwind]

13 hours ago, Diche Bach said:

2. Is there a "Thrust to Mass Ratio?"

 

5 hours ago, Hodari said:

2.  Never seen it mentioned or used anywhere, but it's effectively going to be the same as TWR as long as you're always talking about the TWR with respect to the same planet.

The thrust-mass ratio ostensibly exists, in the form of being the same as TWR except without accounting for local gravity, but nobody really calls it that. It also serves a different purpose.

In other words, where TWR is thrust / mass / 9.807 m/s², TMR is just thrust / mass. It shows you the same information about how much push you can expect your rocket to get from its engines, but in absolute units instead of relative. Like, TWR will give you the number 1.5 "relative to Kerbin", TMR will give you the number 14.7105 m/s². You'll notice that this is an acceleration, and that's not by mistake. Thrust-weight tells you "this rocket can take off from Kerbin", thrust-mass tells you "this rocket accelerates this hard".

So people don't say "thrust-mass ratio", because that would be clumsy. They just talk about the ability to accelerate.

 

Edited August 9, 2016 by Streetwind

[Diche Bach]

So I got KSS setup last night . . . just getting my orbit to as close to precisely 0.0 inclination as I can. I brought up a crap ton of monopropellant (must've been a total of ~10k units of it between the first and second modules), but it nearly all gone (using it with those RCS thrusters as I understand RCS is far more efficient, higher IsP or whatever . . .) so I guess I'll have to bring up more if I want to change it's orbit subtantially . . .

Question:

1. I had not realized this before but: one can only effectively change the orbital inclination for any given orbit for a small arc of the orbit (well, I "got" that before, but I didn't realize it was as "limiting" as I now see it is). I realize that the "best" most efficient place to burn one way or the other is immediately around the Ascending or Descending Node, but what didn't click is that: beyond some certain angle around that point, one will begin to make the orbit go in the OTHER direction. Moreover, the size of this "effective" arc seems to get smaller as the inclination gets close to zero? I generally have used Lq/O engines for this in the past, so maybe it is something specific to the low acceleration of the RCS thrusters?

Any general guidelines, principles there? (short of elaborate mathematical proofs )

2. I'm a bit perplexed by how "carrying" science works. I've got many modules on this KSS and of course, most of them once you use them in that "area" (altitude, biome or whatever it is) any additional observations become useless. But a couple of them (goo and materials analyzer I think) will "save 1.2 points (but 0% value for the science lab or to transmit it). If I want to "recovery" that science, will I have to send the scientist out to EVA to that module, then put it in the command module that is going back home? (before he returns to his duties analyzing stuff in the science lab for the next year or so).

3. Any modules in stock (or mods) that allow for additional science packets to be cached (obviously each science device itself allows one packet to be stored but is there one that is a "generic" science storage device?). I had sort of expected that some of these modules in DMagic or the other mods I have installed worked this way but it so far has not become obvious how it works.

ADDIT: Ah NVM! Looks like Ship Manifest does all this (and probably the science stuff I asked about above) I just didn't see in Blizzy's toolbar but it is on the right side bar. 4. Any simple way to transfer all of a resource from one set of containers to another?

I've got about 100 hydrazine spheres on my space station, and the idea occurred to me that the top module (which has now been instrumental in completing two missions) could go on to do other things if I transfer all the monoprop to its tanks.

I've got "ship manifest" installed, but not even seeing the GUI icon for it now so not sure what is up . . .

Edited August 10, 2016 by Diche Bach
additional question

[Streetwind]

14 hours ago, Diche Bach said:

1. I had not realized this before but: one can only effectively change the orbital inclination for any given orbit for a small arc of the orbit (well, I "got" that before, but I didn't realize it was as "limiting" as I now see it is). I realize that the "best" most efficient place to burn one way or the other is immediately around the Ascending or Descending Node, but what didn't click is that: beyond some certain angle around that point, one will begin to make the orbit go in the OTHER direction. Moreover, the size of this "effective" arc seems to get smaller as the inclination gets close to zero? I generally have used Lq/O engines for this in the past, so maybe it is something specific to the low acceleration of the RCS thrusters?

Any general guidelines, principles there? (short of elaborate mathematical proofs )

I... don't really understand what you mean here? Orbital Mechanics is a difficult topic, and it seems you've not quite fully grokked it. Don't worry though, it took me over half a year of constant playing before it finally clicked

Each of the three burn directions - prograde/retrograde, normal/antinormal, radial-in/radial-out - has a very distinct and specific effect on the shape of your orbit. This effect is always the same, no matter where in your orbit you are, so the idea that a normal burn is only effective at a few points of the orbit is completely off. Instead, what you should take away is: although the effect is the same everywhere, the result that that effect gives you only matches the result you seek if you burn at a specific point of the orbit. Otherwise, the burn will result in the orbit changing into a shape you can't use, but it still changes all the same. It's a question of expectation vs. reality.

The individual effects of burns are:
- A prograde burn pushes the point directly opposite of you further away from the gravity well. If this point is not the apoapsis, the shape of the orbit will twist in such a way that the apoapsis travels towards that point.
- A retrograde burn pulls the point directly opposite of you deeper into the gravity well. If this point is not the periapsis, the shape of the orbit will twist in such a way that the periapsis travels towards that point.
- A normal burn will rotate the plane of the orbit counterclockwise around an axis passing through your vessel and the origin of gravity. It also adds a bit of orbital energy, resulting in a small prograde effect.
- An antinormal burn will rotate the plane of the orbit clockwise around an axis passing through your vessel and the origin of gravity. It also adds a bit of orbital energy, resulting in a small prograde effect.
- A radial-in burn will twist the orbit within its plane around an axis perpendicular to it, through your vessel, in the direction of the orbit - a bit like a hoola hoop. This twisting motion is constrained by the origin of gravity, which the orbit cannot pass. The lower the periapsis, the lesser the twisting effect you can get, and the more of the invested energy will end up raising your apoapsis instead.
- A radial-out burn will twist the orbit within its plane around an axis perpendicular to it, through your vessel, against the direction of the orbit - a bit like a hoola hoop. This twisting motion is constrained by the origin of gravity, which the orbit cannot pass. The lower the periapsis, the less of a twisting effect you can get, and the more of the invested energy will end up raising your apoapsis instead.

Among these, prograde/retrograde burns are more effective the closer to the origin of gravity you are, while normal/antinormal and radial-in/radial-out burns are more effective the further away from the origin of gravity you are.

Regarding the significance of the ascending and descending nodes:
These are not points where you somehow get a boost to the effectiveness of your normal burns at all. The burn is precisely as effective there as it is everywhere else (at the same altitude). What these nodes actually represent are the intersection points of two orbital planes. Nothing more, nothing less. Now, as I said above, a normal/antinormal burn rotates the orbit around an axis that passes through your vessel and the origin of gravity. That in turn means that the current position of your vessel, as well as its direct opposition point, are the only points of the orbit that "stay still" and don't change at all during a normal/antinormal burn; everything else moves. If you now happen to want to change from one orbital plane to another - for example, you are coming from Kerbin and want to go to Moho - then it follows that this point that "stays still", this focus point of the rotation of the orbit during the plane change, must already be located in the target orbital plane. After all, it cannot move there if it stays still. And the only two points of your current orbital plane that are also part of the target orbital plane are the intersection points between these two planes. That is what the AN and DN are: points that are on two orbital planes simultaneously, where a vessel can change back and forth between them.

In KSP, this has special significance, because the game engine cannot properly simulate axial tilt. Any and all celestial bodies in the stock system have their equator perfectly aligned with their orbital plane. Therefore, the act of matching a target body's orbital plane is almost always synonymous with assuming an equatorial orbit around it. This, together with the way players instinctively try to use the equatorial plane as a reference (it makes it easier to navigate) may give the impression of the AN/DN being 'magical' points that are the only locations where normal/antinormal burns are useful.

 

14 hours ago, Diche Bach said:

2. I'm a bit perplexed by how "carrying" science works. I've got many modules on this KSS and of course, most of them once you use them in that "area" (altitude, biome or whatever it is) any additional observations become useless. But a couple of them (goo and materials analyzer I think) will "save 1.2 points (but 0% value for the science lab or to transmit it). If I want to "recovery" that science, will I have to send the scientist out to EVA to that module, then put it in the command module that is going back home? (before he returns to his duties analyzing stuff in the science lab for the next year or so).

Think of it this way:

Whenever you run an experiment - any experiment - a science report "item" is created inside the science module onboard part that hosts the experiment. If you click reset or transmit in the science dialog, this item is destroyed again, but if you click keep, or press no buttons at all, it remains where it is. This item is the thing that must be recovered in order to get recovery science. Not the experiment that generated it - just this item. Additionally, while this item remains stored in the science module, that science module cannot generate new report items without first destroying the old one. If you want to preserve the item, you must remove it from the science module.

Science report items can be taken out of the science module they were created in by a Kerbal on EVA. However, the Kerbal is generally not able to put them back into a part. Only parts that implement ModuleScienceContainer can receive science report items and store them. Generally, all manned command modules, the mobile processing lab, and the Kerbals themselves implement this. Note that even on parts that have this container, experiments still generate the report item inside themselves. They don't put it inside the container automatically. This is why you must do the "take crew report -> EVA -> take data -> board again" dance every time. (The boarding action automatically stores data inside ModuleScienceContainer.)

There is a storage limit of one unique science report item per ModuleScienceContainer. In this context, "unique report" refers to the experiment-altitude-biome combination. A ModuleScienceContainer can store an infinite number of unique crew reports, but only one single copy of "crew report while flying above Kerbin's grasslands". This becomes important for goo canisters and materials bays, which by default don't yield their full payout from a single report even on recovery. You may want to recover more than one identical report in order to get as much science as you can, but you won't be able to carry two or more copies inside the same ModuleScienceContainer.

 

14 hours ago, Diche Bach said:

3. Any modules in stock (or mods) that allow for additional science packets to be cached (obviously each science device itself allows one packet to be stored but is there one that is a "generic" science storage device?). I had sort of expected that some of these modules in DMagic or the other mods I have installed worked this way but it so far has not become obvious how it works.

This should have been partially answered by the above too. Why are there no stock science modules that cache multiple report copies like some DMagic experiments can? I'm frankly not sure. It may be that DMagic wrote that himself as a plugin. Or it is a conscious design decision. Who knows...

Edited August 11, 2016 by Streetwind

[Diche Bach]

Wow, awesome answers Street. That is the clearest description of the basic principles I've ever read!

[FyunchClick]

On ‎11‎-‎8‎-‎2016 at 10:06 AM, Streetwind said:

(...)

- A normal burn will rotate the plane of the orbit counterclockwise around an axis passing through your vessel and the origin of gravity. It also adds a bit of orbital energy, resulting in a small prograde effect.
- An antinormal burn will rotate the plane of the orbit clockwise around an axis passing through your vessel and the origin of gravity. It also adds a bit of orbital energy, resulting in a small prograde effect.
(...)

 

Neat and concise description indeed.

WRT the normal/antinormal burn, I'd like to add that the prograde effect you seems to occur mostly when burning through a maneuver node for a significant rotation (just a few degrees has hardly any effect), and is because during the latter part of a larger burn your maneuver vector is pointing further and further away from the normal/antinormal vector.

If you'd keep your vessel pointed normal/antinormal on the navball (using SAS to make it easy) you'd hardly see any change on the eccentricity of your orbit, but it would be rather inefficient like walking along an arc to get from point a to b is less efficient than going in a straight line.

I found that when setting up a maneuver node for a significant plane rotation, adding a bit of retrograde to the node to keep the orbit similar (usually checked through the position and values of AP/PE) gives you the most efficient burn, as you're wasting no dv on a prograde component.

[Streetwind]

10 minutes ago, FyunchClick said:

WRT the normal/antinormal burn, I'd like to add that the prograde effect you seems to occur mostly when burning through a maneuver node for a significant rotation (just a few degrees has hardly any effect), and is because during the latter part of a larger burn your maneuver vector is pointing further and further away from the normal/antinormal vector.

But a maneuver node assumes an instantaneous application of dV... yet if you simply make a maneuver node and drag the normal arrow, you will find that your orbit gets raised along with rotating. I'm pretty sure this is an inherent feature, even if you perfectly track the correct direction. That's why adding retrograde dV already helps during the maneuver node setup. It actually puts your maneuver vector off of the normal marker, to compensate the orbit-raising.

(And even if it wasn't... it would still be useful to mention it, since it happens in any actual application ingame )

Edited August 12, 2016 by Streetwind

[Diche Bach]

I think the misconception I had above about how anti-normal / normal works was a simple fact that: my burns were taking so long relative to the amount of inclination change I was making that by the time I was "half-way" through my burn, I was already "half-way" to the next AN/DN node, thus, my burn stopped having the intended effect and instead having the opposite effect.

My next questions:

1. Is there a mod that makes the application of very small maneuver node changes easier to do?

I find the only really tedious and frustrating part of the game at this point is the overly sensitive response to mouse movements when I'm trying to set up a very precise maneuver node. I've seen some mods that sound like they do this mentioned, but I'd be curious to hear what folks suggest.

What I would imagine is a mod that allows you to click a hotkey, and open a small interface where you can A. adjust key/mouse input speed and/or B. switch to using keys to adjust a particular node change ( arrow keys or whatever).

I have MechJeb, RemoteTech, etc. installed, and I use KER constantly, but at this stage I still prefer to setup my maneuvers manually and build more understanding of the whole thing. I may eventually let MechJeb do a lot of the work for me, but for now manual maneuver node setup and the flight computer in RT for certain situations. Is there a mod that would fit into that niche, just basically change the UI sensitivity for maneuver nodes and not much else?

2. What is "flight planning?" I saw that an upgrade I made to the Tracking Center enabled this, but I have yet to comprehend what that means or if it simply means using maneuver nodes?

3. I find the way the maneuver node displays change when you start changing Spheres of Influence to be a bit strange. I did just manage to do a Minmus flyby at 24,000m periapsis above Minmus (to complete a lucrative tourist mission as well as a nice training mission that bumped my best pilot up to level 3) where I setup the A. Encounter burn from Kerbin orbit (obviously). Then after the encounter "node" was established, I set up; B. the "close fly-by" node, using primarily retro and either radial or anti-radial burn to go from 635km peri of Minmus down to 24km (to get below my 30km threshold to complete the tourist mission); C. I then (while still many hours away) setup a "post-flyby" node to lower my Kerbin peri from 1,800km down to like 42,000m

The main part I find strange is: Once I setup A. it seemed I was unable to place any additional maneuver nodes along the teal-colored leg of the trajectory, though I _was_ able to click right at the "Minmus Encounter" point to setup the "B." and also I was able to click on the teal arc between that point and the "Minmus Escape" node, as well as the orange node that showed my trajectory after the flyby and back toward Kerbin.

I find gravity-assists (whether braking or accelerating) aero-braking, etc. to be absolutely fascinating and I'd like to really get a solid mastery of how to use the UI to setup exact things, even if it is all setup long in advance.

Would be very cool to be able to: Get an unmanned probe into Kerbin orbit, then setup a sequence of three or four "delayed execution" manuever nodes in the RT flight computer that put it into a stable orbit of some other celestial. Is that even possible? I did notice that, referring to the "close flyby node" I setup at 3B above, once I actually got "into" Minmus SOI, and the incoming portion of the arc from Kerbin disappeared, the actual burn that had been setup for this maneuver was a tad bit off and I had to adjust it before I executed it.

Can anyone point me to a good resource for this sort of stuff?

[Streetwind]

3 minutes ago, Diche Bach said:

1. Is there a mod that makes the application of very small maneuver node changes easier to do?

You have MechJeb. There should be a module somewhere in it that lets you do this.

As a stand-alone mod, there's PreciseNode.

 

4 minutes ago, Diche Bach said:

2. What is "flight planning?" I saw that an upgrade I made to the Tracking Center enabled this, but I have yet to comprehend what that means or if it simply means using maneuver nodes?

It does simply mean using maneuver nodes, yes.

 

The rest sounds more like GUI issues and imprecisions of executing burns vs. pre-planning them. Can't really say much on it without being in your shoes there, sorry.

[Diche Bach]

Ah thanks! Will check out MechJeb more closely.

[FyunchClick]

5 hours ago, Streetwind said:

But a maneuver node assumes an instantaneous application of dV... yet if you simply make a maneuver node and drag the normal arrow, you will find that your orbit gets raised along with rotating. I'm pretty sure this is an inherent feature, even if you perfectly track the correct direction. That's why adding retrograde dV already helps during the maneuver node setup. It actually puts your maneuver vector off of the normal marker, to compensate the orbit-raising.

(And even if it wasn't... it would still be useful to mention it, since it happens in any actual application ingame )

I'm not so sure. My math skills have gone down considerably since my school days, but I think I'm onto something. Allow me to explain with a crappy diagram:

So, fig 1 shows your current speed vector (v), and your desired speed vector (v2), which is exactly the same magnitude, but has a different angle.

Now, fig2, if you add a speed vector straight up normal or anti-normal to v (blue arrow) to get to the new angle, you also get an extra bit extending out from your new speed vector, which is your prograde bit (magnitude changed, which means you're going faster forward).

So, fig 3, if you add a speed vector at an angle so it leans back a bit (actually, at an angle that is at a right angle to the line bisecting the angle between v van v2, which makes it point a bit retrograde), you end up with exactly our desired v2, regardless of the time it took to accelerate. The blue line also ends up slightly shorter than the one from fig 2, meaning less dv used.

Edited August 12, 2016 by FyunchClick
clarification

[Streetwind]

1 hour ago, FyunchClick said:

Allow me to explain with a crappy diagram:

I agree with your explanation, and I think we meant the same thing

[Spricigo]

8 hours ago, FyunchClick said:

Allow me to explain with a crappy diagram:

It explains a whole lot more than what you intended to do.  It's astonishing how often the problem a player face it's because he got adding vectors wrong. 

[fourfa]

On 8/11/2016 at 1:06 AM, Streetwind said:

There is a storage limit of one unique science report item per ModuleScienceContainer. In this context, "unique report" refers to the experiment-altitude-biome combination. A ModuleScienceContainer can store an infinite number of unique crew reports, but only one single copy of "crew report while flying above Kerbin's grasslands". This becomes important for goo canisters and materials bays, which by default don't yield their full payout from a single report even on recovery. You may want to recover more than one identical report in order to get as much science as you can, but you won't be able to carry two or more copies inside the same ModuleScienceContainer.

Great explanation!  Just wanted to point out there is one exception - the Science Lab can store multiple copies of the same science report item.  Each science lab can only process a single copy (let's not muddy the waters too much, as no one has brought up the science lab mechanics yet), but they are handy for storing tons and tons of science reports.  Even identical ones.

[TomArt]

I have a MacBook Pro - how can I get around the right-click requirement?  I'm just using the touchpad.