Cerebrate

1.0.4b does seem to work. Thanks muchly! -c

Just a heads-up: your 1.0.4 release for 1.3 compatibility won't install through CKAN: "Trying to install Modular Pods 1.0.4, but it's not downloaded or download is corrupted." The download file is there in the cache, though, and is at least a functional .zip file. Exception details given as follows: ************** Exception Text ************** CKAN.FileNotFoundKraken: Trying to install ModularPods 1.0.4, but it's not downloaded or download is corrupted at CKAN.ModuleInstaller.Install(CkanModule module, String filename) at CKAN.ModuleInstaller.InstallList(ICollection`1 modules, RelationshipResolverOptions options, IDownloader downloader) at CKAN.Main.WasSuccessful(Action action) at CKAN.Main.InstallMods(Object sender, DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument) -c

No, should work fine now that CBK has updated. I'll flip the bits on Spacedock. -c

Last I heard, the CBK developer was planning to update it, so hopefully that'll be soon. (I've already flipped the 1.2 compatibility switch on this on Spacedock, so it should be ready to download as soon as CBK is.) -c

Well, what d'you know, so there is... Oh, well. Guess I made my own setting anyway. With blackjack! And hookers! -c

NavBallsToYou is now updated for KSP 1.2. Enjoy! -c

That'd be because in 1.1 (and as you can see in your persistance file) all those engines aren't using ModuleEngines, they're using ModuleEnginesFX. I have a similar problem because I'm using RealFuels, which means all my engines are using ModuleEnginesRF. Either way, they won't be picked up by that check. @Whitecat106, maybe you could rewrite the first half of that check to pick up any modules whose names start with ModuleEngines? That would cover all of the alternate engine modules from various mods that I'm aware of. -c

Well, it doesn't seem to be the recompile, per se, as I stripped the mod right down to nothing but the TacLifeSupportContainers folder - with nothing in it but model, textures, and part config files that don't invoke any modules - and it still occurs. (Sadly, not being a code issue puts it beyond my ability to debug. Dammit.) -c

Quick question, for those using the 1.1 recompile above - anyone else getting a reproducible crash to desktop (without errors at end of log) trying this on Windows x64? (Just askin' before I start debugging myself.) -c

That's not a 1.1 upgrade, folks. Check the description of what changed. -c

Just released version 1.1 of this on Spacedock, updated to support Custom Barn Kit 1.1.6.0. (Note: this will no longer work with versions of Custom Barn Kit prior to 1.1.6.0. For those, please use 1.0.) -c

With regard to @Maeyanie's post above (and apologies if you already know this), I've fixed this particular error for several mods in my personal experimentation; that error shows up when you compile against the wrong version of the .NET framework. If you recompile it against 3.5, it should then work fine. -c

This is a very simple mod to do what No More Grind did back in the day. i.e., reduce (or increase) the price of facility upgrades by a given multiplier, by default, to 10%. All the actual work is done by sarbian's Custom Barn Kit which is a required prerequisite for this mod to do anything at all, as is Module Manager. All this is is a MM configuration file for those who don't feel comfortable writing their own configuration file to get this functionality. To change the multiplier from 10% to some other value, open up degrind.cfg in the GameData\NoMoreGrindRedux folders and edit the 0.1s in various places to whatever multiplier you would like. Don't change the rest of the file, and which apply to which facility should be reasonably self-evident. No More Grind Redux is in the public domain. Download here: http://spacedock.info/mod/523/No%20More%20Grind%20Redux -c

More than happy to help test. It's just not the same game without Interstellar! -c

I've got this mostly working under 1.1 (impatient, I am, and can't fly without it) with a couple of exceptions I'm still fiddling with - Tooltips, which do not display; and The gear/brake indicator lights, which I'm still working out how to get status from the replacements for ModuleLandingGear. I've sent you a pull request with the work I've done already, which hopefully will be useful. -c

NOTE: technically, this mod is obsolete, since unsetting the "Autohide navball" setting in stock now duplicates its functionality. I'm leaving the download available, however, to ease transition, but it will not be updated beyond 1.2. From my epic impatience to yours, seeing as not having this functionality available turns out to be... a considerable irritation. This mod shows the navball automatically whenever you enter map view. No more, no less. Get it here: https://github.com/cerebrate/NavBallsToYou/releases/tag/0.2 or here http://spacedock.info/mod/458/NavBallsToYou Source here: https://github.com/cerebrate/NavBallsToYou License: public domain. -c

I'm having trouble installing this via CKAN: it won't install at the same time as Real Fuels. (Specifically, "Interstellar Fuel Switch" won't; "Interstellar Fuel Switch Core" installs just fine.) Bit of a problem for me, that, since Real Fuels and KSPI are two essential parts of my All Reality, All The Time combo pack... Known problem? Any thoughts or workarounds? -c

Either sounds good to me! Thanks, -c

Apologies if I missed the answer to this while searching the thread, but: Is there a reason that crew reports, of all the different kinds of science, aren't transferable in realism mode? (I mean, even assuming Mercury-era tech so it's not just a matter of opening a new file on his kPad, I have trouble believing that Jeb "Badass" Kerman can't tear the top few pages off his clipboard and stuff them into his ModuleScienceContainer, y'know?) -c

How could I possibly NOT want the low-down on assorted kerbal booze? (Seriously, though, on this thread or on another to spare the less worldbuilding-geeky readers, I will very happily read all the background you might feel like sharin'.) -c

Thanks muchly! (Having checked CRP, I note for any passing readers that it's "EnrichedUranium" and "DepletedUranium".) -c

Hm. Which version of the stockalike pack are you using? When I try to use it (2.1.4) with my build of 10, KSP freezes during loading when it gets to the LV-N, unless I edit the config for "nuclearEngine" out of the Stockalike_Squad.cfg and remove Squad_NTR_modularEngines.cfg. -c

Yep, a mk1pod with its built-in shield plus the (thicker) 1.5 m stock heatshield directly attached below it. This was just for testing, but it's a config I've used before when anticipating coming in a little on the fast side, say. Not that I'm aware of. Just in case, I double-checked with the debug toolbar: thermal physics settings and part parameters on both the pod and the heat shield match exactly what's in the part .cfg files modified by the DeadlyReentry.cfg, no other alterations. Looks like it was convective heating for the most part, unfortunately. The positive fluxes were Conv Flux and Int Flux, for pod reaching around 3400 and 700 respectively, vis-a-vis 1300 and 70 for the shield, those numbers coming from around the time of peak heating but the proportions being similar throughout re-entry. -c

@NathanKell, which will all have appropriately different properties, right? ...anyway, look, t'be clear, in all this I am not trying t'say that it's Starwaster's job to solve this problem for me, or anyone else's for that matter, whatever I may personally think of the virtues of havin' multiple identical resources hanging around or suggest as a possible improvement, emphasis on not demandin'. (And for that matter, you should see the pull requests I have in the works to make various mods, like my fuel/oxidiser gauges, play nicely and sensibly with Real Fuels 10 once I get my hands on it.) 'Cause much as I'd like a world where everything is coded with perfection, consistency, and universal agreement such that I can drop 80 mods into my GameData and have 'em all sing in perfect harmony, sight unseen, we don't live there, no-one's being paid to take us there, and it's the multi-mod user's job to glue 'em together with as much ModuleManager code and other assorted hackery as it takes, no support expected. I'm fine with all of that. I might, though, take it a little amiss to be told that my problem ain't a problem, 'cause I'm the one who's got it, and it's a damn problem. (Well, it was. Works fine now.) -c

Y'know, it's not like no-one's mentioned the problem it's supposed to solve. Having/using both resources means that people using mods that display heat shield remaining, or things like kOS scripts that monitor heat shield resource remaining, or indeed mods that provide more heat shields which might be compatible with either standard, find themselves having to track two places instead of one place. Or, y'know, carefully ensure that every rocket they built, .craft they have built, or subassembly they have saved is using the right combination of heat shields and settings to all be using the same one. This is, not to put too fine a point on it, irritatingly inconvenient. (And not a theoretical problem, either. This would be a noticed-it-on-literally-my-first-run-with-7.0.1.-installed problem.) Sure, that may not be a problem for you, but permit me to suggest that that by no means implies that it's a problem for no-one. As is right and proper. Speaking of support - and, yes, I did remove that MM config first - before I suggest this is a bug, is there another reason why, with a Mk. 1 pod with 1.5 m stock heatshield attached below reentering tail-first, the AblativeShielding on the pod should deplete much faster and more completely than the Ablator on the heat shield (12.6/100 versus 178/200, coming back from a 100 km circular orbit with a 30 km periapsis)? The former shows pyrolysis flux and ablation an order of magnitude higher, even though intuitively it should be protected by the shield. -c