Amaroq

@MrOnak, no worries. I'm all for options for the advanced user, but we've got to make sure we leave things appropriate for the beginner as well. Given the way most of the other information-only mods install nowadays (e.g., Kerbal Alarm Clock, Science Alert, etc), I think this one is ready to be presented "partless", but with some alternate MM config files to support the sort of thing you want, etc. As I said earlier, they're going to have to keep the parts around for backwards compatability at least until the next "Squad breaks all save games" release.

This mod has the Amaroq seal of approval -- highly informative, no changes to the stock game. I highly recommend it. Congrats on the release, xEvilReeperx.

@MrOnak, how about the following ModuleManager config? // Add BuildEngineer to all Probes @PART[*]:HAS[@MODULE[ModuleCommand],#minimumCrew[0]] { MODULE { name = BuildEngineer } } // Add BuildEngineer and FlightEngineer to all crewed Command Modules @PART[*]:HAS[@MODULE[ModuleCommand],#minimumCrew[1]] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } }

Methinks 'twas a compliment, Cilph, in response to the in-game editor.

Interesting points, @MrOnak. You could, of course, use your own ModuleManager config to, say, apply KER only to manned vessels and, say, only one probe. I guess I hadn't been considering the "I don't want it, full stop" case because, with Toolbar, it just minimizes and you can even hide the button.

That sounds excellent, @smart_chris. I've been really enjoying these in my game.

@Gaiiden - Thank you, I'll give that a shot. I'd actually "solved" my problem with a high-altitude drogue chute to cut some speed. Been there, done that! I use Kerbal Engineer Redux to monitor my TWR as I burn off fuel (I aim for an active TWR of between 1.6 and 1.8 during thick atmosphere, and throttle up once I'm clear). The FAR gravity turn is radically different than the "stock" one. Try turning to about 70 degrees as soon as you're clear of the launch pad, and "rachet over" 10 degrees six or seven times as you ascend, so that you're not burning radially until you're up about 45km.

+1 Until then, have you guys checked out the Kerbal Alarm Clock mod? This is literally the only change it makes to the game - adding the ability to set alarms that (optionally) stop warp, N minutes before - arbitrary time - node - SOI change Etc. Not game-breaking in any way, but perfect for exactly this niche.

The "most efficient" approach is to burn while at periapsis. Which means, a very short prograde burn at periapsis, shut off, loop around, do it again .. until eventually, many orbits later, you'd have your intercept (or escape). Nobody does that -- KSP players because it would be terribly boring, and real programs because the mass required for the extra life support would exceed the gain.

Yeah, the plain old Mk1 w/integrated heatshield survives re-entry, but attached radial RealChutes burn up when they didn't previously. Not that that's "good" or "bad", but I was having the same "feeling like a n00b" feeling!

This is silly and cosmetic, but it appears that the "orange suit" is determined strictly by string-comparison. I wanted to use my Kerbal's names to denote their "rank", so I edited my "Jebediah Kerman" to "Lt. Jebediah Kerman", and he lost the orange suit. Same for "Ens. Bill Kerman" and "Ens. Bob Kerman". Rather than string-comparison, could we have that be an item triggered on/off via a tag in the persistent.sfs? E.g., "veteran=TRUE", or "suitTexture=orange.png", or something? I'd love to be able to use it as a "reward" for any of my Kerbals who have accomplished significant wins, not just limit it to the "first three". This would also open it up very easily to modders.

We miss you, fusty!

Sounds excellent -- can you link to a "WIP" thread in Add-On Development for those of us that would like to follow your progress?

You're welcome - please feel free to ask as many questions as you need. and yeah, before the guys created Module Manager it was a nightmare to try and get all the part configurations lined up each time a new release came out. I do strongly support your approach, though, playing around with stuff, breaking it terribly, getting it back to working Best way to learn!

Welcome to modding, you've just successfully built your first mod. Let's see, what have we missed? 1. As you've found, copying the full part folder will add a duplicate part to your game. If you want the OLD stayputnik to go away, you'd need to delete it out of the Squad folder. However, that puts you in the position where, when 0.24.0 comes out, you have to do that again .. and if the 0.24.0 Stayputnik has some other change in it, you either risk missing that change (keeping your 0.23.5 Stayputnik file) or having to re-apply your changes by hand (copying the new 0.24.0 Stayputnik, and then changing the techRequired). That is why my recommendation was to use the Module Manager 2.0.1 - linked at page 52 of that thread, here: Module Manager 2.0.1. 2. The "uniquifier" is the name= portion of the part.cfg If your only change was to the techRequired line of the config file, your change placed two items with the same "name", which can cause look-up problems. So, at the top of your version, change the "name=" line to a different new name. I presume that's why its showing up twice in the tech tree, unless you made more than one copy of the part folder. (We could verify that, for example, by not fixing the "name" but instead changing the "title" entry, which is the value displayed to the user.) = = = Here is a sample ModuleManager configuration for you: @PART[probeCoreSphere] { @TechRequired=start } That would give you an MM config capable of re-appling this change to any version of the game, e.g., 0.23.0, 0.23.5, 0.24.0, etc, without the "duplication" bug.

Ahh, perhaps I shall stay out of it then; in my excitement I'd presumed that viperfan's update was a.) correct, b.) included the hotfix update, and c.) compiled to 0.23.5. All were assumptions which may be incorrect.

My suggestion is to use a Module Manager .cfg file to update the "TechRequired" values -- that way, you can add whichever mods you like, and a well-written MM .cfg should work for both 0.23.0 and 0.23.5. (As well as forward-compatability to 0.24, etc.) http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-1-5-6-%28Jan-6%29 My understanding is that TechRequired is the only change you'd need to make, but that your values may be overwritten if you use TreeLoader to load an alternate science tree.

^^ Heheh. Yeah, ditto.

Can we get, either, an update to the first post linking viperfan's community hotfix, or a separate thread for RT2 "legacy" support?

Yes - there's a definite need here. To flesh the idea out, more: 1. Completing a map should reward you with science. 2. The map could help you identify the biomes to target landings in them. 3. The map could help you identify the elevations to target landings on flat spaces. (@Doozler - I disagree; I'd like to see the mapper unlockable fairly comparable to the Mun/Minmus landers, so you have a meaningful choice to make.) 4. The map could, as ISA MapSat did, identify some "anomolous readings" to help direct the player's exploration(s). (Alternately, anomalies could show up as very small unique biomes -- that would give us a science bonus for reaching them as well.)

Yes. Either this, or let me rename them!

Okay! My apologies for raising an old / known issue. It would be nice if that were added to the opening page documentation, as you do explicitly use spaces "for legibility", without any warning that that doesn't work in practice. I'm still very confused why the same MM .cfg appeared to behave differently from 0.23.0/1.5.6 to 0.23.5/2.0.1., but as I've been pointed to the fix I'm personally content. I do wish somebody somewhere were using String.Trim(), but it sounds like that's on the KSP parser and not you good gentlemen!

If I didn't say it before, thank you so very much - quite appreciated! From post to fix, total elapsed time: 12min.

The answer is "yes, I was missing something obvious". MM 2.0.1 does not support the spaces I had within the "HAS" tag. Removing them led to immediate success, and a big thank you to ObsessedWithKSP for the fix.

Face-palm. Yes, removing the spaces worked. That is a difference between 1.5.6 and 2.0.1, though -- my config worked fine in 1.5.6. If white-space-sensitivity is an intended feature, that's something sarbian may want to update from the O.P., as several of the "example" files have white space for legibility.