aquilux

This needs more attention. Squad, why aren't you responding to/considering this. What happened when you did all that memory optimisation? Did you ever consider this and if so, what were your reasons for not implementing it?

Speaking of input, I just had an idea that may help here. I've seen many people complicate their mods by trying to add mod specific GUIs that you then have to navigate. I suggest using Module manager to add a custom module to all parts (or certain sets of parts is desired). Each part with the module would get an additional button in its context menu that when toggled on, would make the part flag itself to the plugin as a part to watch. In case of destruction or detachment of any part along the branch to that part, the plugin would trigger the abort action group, though I'm not sure how to make it aware of the difference between spontaneous disassembly and decoupling events. Do parts, or could a part, equipped with a decoupler module, report the decouple command? That way, anything further along the branch could be unflagged before the abort is triggered. Hmmm. Looking at it now, It'd probably do well as its own plugin based mod. If you decide to make it, I request tweakables compatibility, and the ability to apply the flag to all parts in the same symmetry group if I choose.

Ah well, sorry about the misunderstanding. Would it be possible to get the option to turn on the combined vent and hold down force in the .cfg?

Huh, I would've thought that the margin of error fell to the side of landing too hard, not stopping too soon. Personally I would prefer the risk of landing too hard instead of stopping too soon. If adjusted to cut out upon contact at the earliest, what would the margin of error look like? What's the highest speed impact that we'd be dealing with given there's enough delta V? What would it take to bring that number down to a reasonable level? IMO, if I were to use this on something I would only care that my major parts would be okay. I really wouldn't mind if the gear broke because they can be fixed, and I wouldn't be mad if bigger things broke because to me the nature of this part makes it a serious gamble in the first place. To me it seems more fitting if there was a serious chance of lithobraking to kill the last dozen m/s upon contact, that way you could just fire these at/just barely past the last moment and let them run until your vertical speed goes positive, then pop the vents. TLDR: I feel like people really wouldn't be using these if they wanted a gentle landing.

To go into more detail, my thought was to have two engine modules as part of the one model, one pointed down with something like... thrust: 45 isp: 300, and the other with something like... thrust: 5 isp: 20, both of which would be fed by the solid fuel in the part. The plugin would fire the primary engine like normal, but upon touchdown, it would simultaneously throttle down the primaries to a minimal level and activate the "vent" engines, giving the impression of venting the majority of the gasses out the top.

I think that the reusable version, if you make it, should look kind of like the B9 aerospace separatrons but with a "vent nozzle" on the top angled 45° out, and a section along the side that is actually the fuel plug. The thought is that the rocket fires normally until touchdown, and then the vent nozzle pops open. With a much larger opening and no nozzle to speak of, the rest of the fuel burns off at a downright horrible ISP with the downward thrust dropped to almost nothing. (In fact, I think this behavior is preferable even for the one-shot version) Actually this would be quite useful as we may not have been able to kill all lateral motion. With all the gas venting up and out it would produce a downward force that might be enough to keep all our feet on the ground for that crucial moment while the lander is trying to flip. If you wanted to get really fancy, you could animate part heat for the nozzle, plug casing, and maybe even the vent nozzle (hell, the seals may not be perfect, and the part could "leak" combustion gas, damaging any part that's in the wrong place at the wrong time, quite kerbal I would say ).In fact if you wanted that last extra bit of detail you could make the paint on the fuel plug char from the heat, giving a visual indication that it has been spent, and refreshing the texture when it's been refueled and is ready to go again. An idea I had for placing the nozzles "underneath" the pod becomes easier with the vent valve. Just have a part made so that the vent sits flush against the surface and clip the main body of the part through with the nozzle clipping back out the bottom. That would make it impossible to refuel though, but you could have the vent and plug access both sit flush with the skin if you didn't want to keep that limitation.

The original poster's question remains unanswered. A) He believes he is entering as gently as possible. His craft is not overheating. C) His craft is breaking apppart due to the high g-forces incurred by the dense atmosphere. What advice is there to be given that would help in this scenario?

How about skimming small amounts of fuel from the atmo of some bodies. For example, saturn's moon titan has methane & ethane clouds, organic compounds, and lakes of hydrocarbons. Maybe we can get a "robotic fuel skimming" station that consumes a certain amount of fuel each go, before paying it back with a bit extra. It'd be relatively small amounts of fuel at high cost (maybe 1/4 the fuel the current part delivers, requiring 25%-50% of what was delivered for another run, high electrical cost, small chance of losing a skimmer) but it would certainly be useful to get even small amounts of fuel out there. I imagine a part that houses 4 skimmers, and the fuel used for each launch, the skimmers themselves looking somewhat like NASA's X-43 hypersonic scramjet. Set it to active and every orbit it will send one down (model disappears) while consuming a large quantity of power (remote guidance control computers, right?). If power runs out, you lose the skimmer. If it makes it back, it resupplies the part outputs the excess (maybe variable?) and sends another. When you set it to inactive it will still consume power until the current skimmer is back and it's load is accepted, it will also set itself to inactive if there is no tank space left to fill. It would also be possible to bring and store extra skimmers in a separate skimmer bay in case you lose one, as well as running multiple control stations to double your resource rate as long as you have the power for both. Also, for setup, I imagine it would be much more particular about its positioning (specific orbit range per body, such as between 200km and 225km), and would require a few orbits of running at full power to scan the planets atmosphere. Afterwards, the same button can be used to start and stop the skimming operation.

I wonder if there is a way to make a tool/plugin that uploads the calculated maneuver nodes into the game from some sort of "mission plan" file, it would make this tool that much simpler to use. At the moment I find myself struggling to understand the program's outputs enough to input proper maneuver nodes. Maybe a condensed listing of each node would help as well? Also, I've found that no matter the setting on the main porkchop graph, the burn calculator will recalculate your flight to minimise both departure and arrival ÃŽâ€V. This gets particularly aggravating when trying to plan a mission that makes full use of aerocapture and braking. On a third note, I have not figured out how to include more than one flyby maneuver in the mission plan. Maybe the burn calculator should be modified into a mission profiler where you input origin and destination, final orbit, and any intermediate milestones. In return it'd give you a timeline of events, from departure to final orbit and including any flybys, where clicking each event opens a new window with details about the maneuver.

I'm afraid I missed all discussion about including a robotic arm, but if it is going to be worked on, I suggest utilizing the Kerbal Attachment System mod as the method of attaching to other objects. I'm not sure how it does what it does but at the end of the cables you can attach 3 different "hook" pieces: a regular hook that only attaches to specially designed receptacles, an electromagnet that holds onto any surface securely as long as it's consuming power, and a grappling hook that causes minor damage to the surface it's attached to and only attaches if it collides with sufficient force. I suggest using the first one on the end of the arm, with the option of attaching the electromagnet if it's needed.

For most people, just the navball is good enough for orientation. What I believe most of us are excited for is the ability to have all the important information visually represented in one place so that you can do the whole docking maneuver without looking anywhere else or reading numbers. I agree, no numbers. There are mods out there that'll spit numbers at you, this looks like a much more intuitive interface. I suggest extending the "needle" out of the "compass" to two or three times the radius. The longer line will be easier to compare to the crosshairs to see if you're dead on with the roll angle.

I think what ZRM is trying to do is to have the code be aware of SRB thrust and to include that into the calculation without having the code try to throttle the unthrottleable. Though I wonder, how would the code react to an engine that can't throttle down past a certain point without shutting off like real engines do?

I wanted to suggest one more thing that would be quite useful. The closing speed and distance numbers would be wonderful as you approach. But if you're docking manually, as you reach the final few meters, having to glance away from the needle and compass may be enough to make you fail the attempt, especially if your craft is rather tricky. I suggest two possible alterations intended to give you a visual indication of distance along with orientation and translation position: A second circle centered around the orientation compass that shrinks as you approach, ultimately merging with the outside edge of the compass when you make contact. Make the difference in radii the log of docking port separation. OR Split the translation needles for each axis into two, placed symmetrically to either side of where the translation needles sit now, and make the distance between them the log of the separation between docking ports. In my opinion, the second is a better, cleaner option. Having the separation between needles be related to the distance between ports allows the user to only worry about staying between the two needles. Additionally, the needles being separated by the log of the distance allows the display to remain useful on either extreme of distances by incrementing in large steps when far away, yet reserving a large amount of detail for when the distances are almost nothing (think of the radar altimeter in the IVA view). In fact, if you take nothing else from this suggestion, I hope you consider using a logarithmic representation on your instrument because of the flexibility of range it provides. PS: in case you don't understand what I'm talking about, here's the difference between a linear and log scale:

Oops, did something weird. ignore this post.

One of the major problems with putting a shuttle on the side of a rocket is that as you launch your center of mass shifts from primarily in your external tank, to primarily in the shuttle itself causing an unwanted pitch force. Most other shuttle mods I've seen get around this by having engines that are gimbaled enough to counter that, but a more elegant solution would be to use a mod like the one I pointed out. I'm sorry that I posted that out of the blue without explaining it better, especially with the problem not having been discussed yet, but I figured I'd head the problem off before it reared it's head.

I'm not sure if it's been brought up before, I don't have the time to go searching, so let me suggest this mod instead of some wildly vectored engine: mod It'll vary the thrust of all throttleable engines to keep your center of thrust under your center of mass, and adjust the force of RCS thrusters to produce more stable translation forces. As a bonus, it utilises varied thrust, and thrust vectoring on capable engines, to impart attitude control.

Something I'm surprised we haven't seen yet is a tri-hex hub with 5 triangular attachment points, one forward, one back, and one on each large flat side.

Could you make your code report to mechjeb the correct thrust? Would it be possible to trick mechjeb into thinking your code was the only engine and report to it what characteristics you wanted it to see?

I was going to suggest as a solution to "hampered thrust", that you could maybe take the final engine throttle settings and if none of them reach 100%, scale them all up until at least one does. That way you get the most thrust while not going past what the other engines can counter for.

Time markers, as seen here.

Hmmm, it seems I should hold off on commenting until I have a better understanding of what's going on. As it stands this looks like a wonderful tool, and I'd like to congratulate you and thank you for giving us the chance to use it. As for suggestions... is there a way to have the program automatically download the needed files on first run? I imagine most people who come across this are going to be trying to find a tool that simplifies their playing experience. While giving them a strong planning tool is great, many may not see past the hurdle of downloading multiple files as it feels like making things more complicated instead (I know I was putting off downloading it for this very reason). Would your program need everything found in the MCR package? Maybe it could contain just the files it needs? As it stands I get the impression that I need to install this big bulky complex thing, to be able to use this little, simple tool that would make my life easier. I'll go ahead and go through the installations and try this out before I say anything else. Edit one: Just downloading the two files heightens my impressions. While your package downloaded in under 5 seconds, I still have 26 minutes left on MCR, no doubt with a lengthy install process in store when it's done. It makes me wonder just how much of this download your program will actually use, and how much will be wasted space? I know that I'll probably never use the compiler aspects of the file I'm downloading.

I can't wait to use this tool, it looks great. Though, is there a way to get a standalone exe eventually? Having multiple files to install increases complexity, and may dissuade potential users.

Would it be possible to include maneuver node values for these transfers in the "selected transfer details" section? I understand the steps that have been indicated here are rather simple, but it seems a bit inefficient and repetitive to have to do more math after the script has done some already, and then have to eyeball it. There are a few different ways to plug in specific values into maneuver nodes (for example, mechjeb has a maneuver node editor built in), and it would be quite helpful if the script could give us the particulars to adjust our nodes to for each burn.

Hey guys, I really love your work and this new project looks awesome, though I am concerned about the "feel" of it all. I know, I know, "If you don't like it, don't download it." and all that, I'm not going to stop you, that's not why I'm here. It does seem to me as though squad has pointed the general feel of KSP more towards the general style of the apollo era missions though. In that spirit, I will point your eyes (and those of the people looking at this thread) at the 1969 mars mission proposal. There's just something about this project that makes it fit perfectly with the feel of the game, and I'm shocked no one has shown any interest in adding it in. Obviously, this is something that would need 10m parts to go with it, but that's a trivial matter of upscaling existing parts, even stock items. In the original plan there were 5 modules all based off of the same design: The lander pictured above. A more permanent base designed for repeated use. A cargo module to support longer-term missions. A rover lander to... land rovers, either one large one or many smaller ones. A mini nuclear power plant to generate power and oxygen from the environment, as well as possibly generating fuels from CO2 and H2. As were many mission designs of the time this plan relied heavily on the NERVA engine, and the shelving of that project was one of the factors to it's death. Obviously, we don't have that problem. The entire mission fit quite nicely together, including even probes for venus as many plans involved a venus flyby to boost their orbital velocity. This entire thing would enter orbit over mars, with some plans involving an aerocapture. The MEM would detach and descend, leaving it's base on mars after it finished the mission. The full mission vehicle would be brought together in orbit in six major, easy to assemble sections, five of which are identical. Unmanned missions would also be launched, containing multiple MEM modules of other designs to deliver the previously mentioned reactor, base, rover,and cargo modules. I'm not asking anyone to stop what they're doing to work on this, but I want to get this idea out there and in the minds of the great modders here in the hopes that someone will be inspired to bring at least some parts of this project to KSP, some time in the future.

Here's a workaround for you. The assent target marker is done by creating a phantom target in front of your pod, and altering the angle between the horizon, your pod, and itself to match the proper assent angle per altitude. That's why you can't have both that and a target designated. To use the auto-assent profile but retain most control over your launch, show assent helper (or is it manager, or something else?) use TGT+ in smart ASS to point at it, and handle everything else yourself. I haven't tried it myself, but it should work, feel free to tell me otherwise.