Frederf

FAR includes "RealChute Lite" which has a totally different method of adjusting the parachute parameters. If I recall the defaults are like 0.01atm 2 seconds and 700m 6 seconds. If the nuFAR-nuStock relationship is anything like the oldFAR-oldStock relationship, FAR is slipperier and 700m is too late for certain designs. Depending on what mods you have installed (e.g. Stock Fixes) the interface with these parameters gets a little cluttered and confusing with some being completely ineffectual and others quite hidden if you're used to the stock. I believe an installation with just FAR and its dependencies shouldn't have any adjustable bars. The "toggle info" option is the one you want for adjustments to deployment parameters and/or the action menu and click the part in VAB.

I've been on and off with RealChute. I was off until the latest FAR came bundled with "RealChute Lite" so I'm working with it. The following is going to seem like a load of whinging. It's going to seem like tiny inconsequential things which make too little difference to matter. And for the most part that's true but together I think that such polishing tweaks adds up to a big improvement in usability. Usability, UI, layout, and design are the improvements that I desire. Functionally I am satisfied. It does everything I want it to do but not in the easiest or most pleasing way. "Toggle info" should be "Toggle Info" to be consistent with Squad's interaction menu capitalization convention. However I don't see a reason for this option title to be so generic. It'd be a problem if every mod that added an action to a parachute part used such a non-descriptive title. "RealChute Info" or even simply "RealChute" ensures "positive ID" in the midst of an arbitrary number of other mods. The "RealChute Info Window v1.3.2.3" isn't formatted in a friendly way. Firstly it's not an info window because it's both passive info and active edits. It doesn't need to be called a window because we can see it's a window. Having the version number is undoubtedly a good thing but on the main user-facing window is a bit tacky. In the settings window is more normal. Am I really getting picky about the title of the info window? You bet. This kind of attention to detail absolutely filters down to a user's total perception. Regarding the "info" part I would strive to keep pure the passive nature of info readouts by never having any interactive setting there. Here's an example of the current info window in the flight scene: It's long with a scroll bar and no way to resize the window. Given a few formatting and organization guidelines this can be written in much more friendly, compact way. 1. Omit unnecessary information, e.g. the part name. 2. Keep the contents in the field of the window. 3. If category level is indicated by a change of text (e.g. bold), do not use a colon too. 4. Use Squad's capitalization convention. 5. Avoid space inefficient organization items like horizontal rules when possible. 6. Justify values into columns. 7. Manage significant figures in calculated values to reasonable precision (i.e. 3). 8. If values are a direct consequence of other values or strongly related, put them on the same line. 9. Make units and description agree (e.g. speed is not measured in seconds). 10. Use clear and unambiguous language. Keeping in mind that I'll struggle to organize text into columns in a forum post, now we apply those rules with small adjustments to strip any active adjustments out of the purely informative report: Apart from the editor-type functions of altering the activation altitudes/pressures and the copy-to-other-parts buttons all the info in the original is in the proposed format but is far more readable. It's off the cuff but hopefully it shows the promise of the process. A common issue is that of language, picking the right words and phrases to describe specific events and features. Keywords, carefully chosen and disciplined in their use, really help the user feel at ease. For example the word-concept "deploy" is very muddy in KSP regarding parachutes. Is deploy referring to the "blue" state when the part is activated by staging? Is it when the first parachute part comes out (yellow state)? Is it when the canopy fully inflates (green state)? What about altitude and height? "Chute" isn't a word either. It's fine as part of the proper noun of the mod but I would avoid it as an improper noun. What is a "chute" anyway? In the case of a combo parachute is it the entire part or just a single component? Terminology should be separate and decided on to ease use. The concept of "space chutes" is quite confusing. It suggests physical duplications of materials but that isn't borne out by the mass of the part. It's not extra fabric; it's not extra attempts if one canopy breaks, but a limited number of times it can be repacked from EVA. A different terminology would suit this concept better. The Action Groups editor window is a bit of an anarchism. Having to switch to the action menu to edit the parachute info was an interesting workaround when Module Fuel Tanks did it ages ago. It has several issues. Career mode's upgrade locked action menu means that the user's UI interaction changes during the career for essentially no reason. It can't be dragged or resized. There are scrolling windows within scrolling windows. It covers the action menu editing interface. It doesn't play nice with any other mod that attempts the same. It's unnecessarily a second point of contact for the user when only one is needed. If there was a "switch to editing mode" type button on the Info window then both info and editing functions would share a single point of user contact for improved usability and efficiency. The Editor window has an odd mix of helper calculator and not. A significant amount of the visual real estate is taken up by essentially a calculator to determine canopy diameter based on certain factors. I feel this "how to arrive at a diameter" process is an optional "side loop" process which deserves a dedicated popup dialog which would radically declutter the interface. Dispensing with the laborious first step of copying an existing example, here's a re-imagined version: The more the UI can use sliders instead of directly typed in numbers the better, and clamped to round step values (no 29543.96m). Taking the hand off the mouse and typing a number is a user effort cost that should be avoided. Some reasonable default should be found for setting values, such as opening altitude/pressure. It does no one any good for the pressure deployment to default to 0.04atm since there's a 100% chance to fail given a reasonable 100x0km reentry using the stock MkI pod. The defaults are arbitrary so let's make them suitable for the most common case. Action on stage to arm or deploy should be a part-specific setting instead of a global preference. It's certainly possible to want both kinds of behavior in the same stage sequence. In conclusion I think comprehensive but relatively simple UI changes would make much more accessible and pleasurable user interaction for RealChute. The underlying functionality is quite complete but the interface with the user detracts from the experience. Thank you.

Does anywhere tell you that? I wanted to use rep->sci but I had no idea that rep controlled your contract quality.

The phrase "gravity turn" is thrown around in KSP rather loosely. A gravity turn is not the most efficient ascent. All it is is minimal steering loses and at high enough speeds, minimal AOA. Only through exceptional design attention are the zero steering loss ascent and the minimum fuel ascent equal. Imagine two rockets of different CG-CT displacements but otherwise identical engines, fuels, weights, etc. The solution for a gravity turn on each would be different but their optimum "fuel to orbit" profiles would be the same. This should show that gravity turn and fuel to orbit optimizations are not the same question. The cost associated with a non-gravity turn in fuel are rather small, a percent perhaps. This is perhaps enough to buy a new car on a real launch but few KSP players are optimizing to that degree. A huge real life motivation is the strength of the rocket structure which does not cope well with aerodynamic side loading. KSP's rockets are infinitely more robust than their real counterparts and routinely take AOA of 10-30-90 degrees in stride where more than 2-3 would collapse a real article. It seems like a nit picky distinction but these nits are the size of buffalo at this specificity. It would be embarrassing to receive exactly what you asked for only to realize you asked for not quite the right thing. The best you'll get out of Squad is some kind of "sandbox" wind tunnel simulator whazzit that you can use to try various procedures yourself and maybe find a better way. It's firmly against the design philosophy of KSP to output "answer" optimizations on behalf of the player.

Not exactly. If you place the part first and then hold ALT while clicking on that part it will make a copy of it (or the tree if stuff is tree'd beyond it).

I set the settings to "hard" but I only lost 10 units of shield out of 1000 from a direct reentry from the Mun. What are some actual good settings such that a full shield direct reentry from Mun is about 50/50 reentry depending on profile (too high = loss of shield and overheat, too low = over-G)?

I had a thought. What if the length of the lines on the "impact plus" symbol meant something. Propagate a plausible error in each axis through a trajectory and find the ellipse that encompasses these error impact locations and draw the plus legs that match the dimensions of that shape. So a long, flat reentry that is sensitive to initial conditions will have a big footprint (large plus) and the plus narrows as the solution gets more and more certain.

Is it possible to just turn the part upside down so that "negative is up" and "positive is down"?

This is a bit of a mis-application but I've found I love using procedural heat shields as end caps for fuel tanks, only with the ablative material removed. Unfortunately when the craft is loaded it always defaults to 100% full of ablative material even if it was saved as partial or empty. I don't know if this is default PP behavior or perhaps some mix of mod interactions, but if at all possible it would be wonderful to have it retain the fill level of material when the craft is saved.

It depends on what you mean by "use." The MJ "take me there" button spoils the fun of course but any of the transfer window planners (KSP_TOT is amazing) simply allow you to tailor your rocket to be efficient which can add tons of challenge and reward. KER I admit I only use for pre-launch dV/TWR calcs. With moderate pre-planning the stock (or with preciseNode) nodes are more than enough. If you're at the level I think you are the tools replace paper and pencil calcs saving you time so use them. Pretend it's your own division of engineers. I wouldn't play as if I knew less than I did. Primitive's cuteness wears off sooner or later. Even with a KSP_TOT snapshot solution you'll never hit it spot on anyway. There's always the need for a mid course correction.

It's probably a side effect of the new unity version and how it handles DX inputs

Engine nacelle for one.

Why don't the stock intakes all have air intake areas?

I always found it helpful to think that I was trapped inside the ball looking outward. Looking up I was looking through the dome lid to the ball. Looking down I was looking through the floor of my spherical cocoon.

About the aero gear being "dead weight" upon reaching LKO. I've been toying with the idea of a spaceplane capable of shedding its aero gear in LKO, flying beyond LKO, and then rendezvousing with it and recoupling to land. This avoids the penalty of lugging the aero gear any farther than absolutely necessary.

If memory serves to connect two SOIs you aim the antenna-dish at the other SOI and effectively target every thing in it simultaneously. So from a craft in Duna SOI you aim at Eve SOI and the craft in Eve SOI you aim at Duna SOI and both craft are linked.

Thank you so much for defaulting the IR GUI to hide. Having it pop up every time I staged, changed scenes, etc. was driving me bonkers.

I got this with procedural fairings. Try editing your save file and deleting the lines where parts are purchased under certain techs. Then they should be available for purchase again, even if the helpful reminder number isn't on the tech to show purchasable parts.

I'm having an issue with the Ignitor mod and FMRS as returning to the craft breaks the continuity of the engine being lit and it has no or limited restart capability. I know it's a mod-mod interaction but means I can't use both freely as I would like. Edit: A short workaround for simple situations is to not activate the engine via staging until after returning from the booster flight scene.

The best of luck and Bobspeed to ya.

One word, gentlemen. Squee.

A (not small) suggestion. Instead of having a preset CoM location is it possible to discover the center of RCS thrusters (currently activated, weighted for various thrusts) like RCSBuildAid on the fly and then have PWB pump fuel (selectable subset?) around to move the CoM to this CoT? I imagine having a preset CoM location isn't terribly compatible with docking and reconfiguring the craft to not resemble the previous craft so much. An "auto" function like this would be the most useful to the user, perhaps with a readout if full alignment isn't possible. Another notion that pops into my head is that if this balancer can shift the CoM intelligently to some zero point, it can also shift it to a point with a known offset from zero. Orbital docking prefers no offset in any situation I can imagine but aerodynamic flight would absolutely love to set a CoM position relative to CoL for a selectable stability. For example perhaps it's known that a CoM 3m ahead of the CoL makes the plane fly nice. These destination points are hard to calculate but perhaps RCSBuildAid and other mods like FAR (or stock) could supply these points externally for (optional) extended functionality.

TWR is a misnomer. All of the mod readouts of TWR (that I know) are really TMR where mass is expressed in m*g0 (aka units of weight at reference gravity). Expressing weight with respect to local gravity doesn't allow an easy understanding of acceleration since the acceleration perpendicular to gravity would depend on local gravity if expressed as a ratio. As for minimizing drag, gravity losses are a simple function of time. You start a stopwatch at launch and every second that ticks by represents loss so minimizing time is the goal. Aero drag's losses are some power greater than linear with reduced total time. To reduce gravity drag (total time) in a given segment of flight to 9/10th you have to fly 10/9ths as fast. Aero drag increases at greater than linear with speed (the quantitative function really doesn't matter here). The result is a crossover where at some speed the reduction in gravity drag by going faster results in an equal (and increasing) increase in aero drag for that speed increase. This is by definition terminal velocity. The difference between the falling body and the ascending body is the drags oppose instead of add but the desires are the same. In both cases each body desires to minimize gravity drag, one because nature and the other by design. The limit on falling is ultimately vacuum freefall but further aero drag. The limit on ascension is vacuum acceleration and further limited by aero drag. The derivation is to find the function of total drag which is the sum of both parts. Since we expect an optimum (minimum) set the derivative (with respect to v) of the total drag to zero. The only way to reconcile the two parts being zero in sum and non-zero themselves is for them to be equal, aka terminal velocity.

Intakes should have a region where they draw air from (invisible selection in front) that you can put objects in but doing so fractionally reduces the intake because of the obstruction depending on how blocked they are.

One thing I forsee taking a great deal of manual computation burden off is a wide array of generic events in the mission architect. For example rendezvousing with a probe or similar will have an event-based mass change that isn't maneuver related. Munar landers in an Apollo style profile for example has dead weight added and subtracted in mission. Joining for adding modules of fuel/supplies in orbit for interplanetary travel is another example.