Starwaster

Fixed the link; it's a link to mod's original thread before I branched it. What this mod has that other life support mods don't is that none of the resource requirements are hard coded. It's possible to completely reconfigure it to use any other resource. I could add a Snacks resource and then write up configs that only use snacks. (exception: if an EVA Kerbal requires a resource named Oxygen then they don't require any while on a planet that is designated as having Oxygen in its atmosphere) The downside is that the original code is overly complex and time consuming to maintain. It breaks in strange ways with almost every KSP update. If I ever get time then I will rewrite it from the ground up. Essentially it would no longer be Ioncross though it would use its configs so it would have Ioncross's configurability, extensibility and simplicity but without the baggage of difficult to maintain code. Currently I'm struggling with a bizarre issue in KSP 1.3.1 where the game starts to lag horribly whenever a Kerbal goes on EVA. I actually have it function in KSP 1.3.1 but I just don't dare to release it with this kind of lag and I've only just recently started to zero in on the cause and as near as I can tell it's in a place I literally would never have thought of looking if I hadn't stumbled over it first.

It's just humor, no need to get pedantic.

I'm calling for help from anyone knowledgeable about cryocoolers and refrigeration in general, preferably if you've actually worked in the field and have good working knowledge on the subject (as opposed to a layperson such as myself who studies as much as he can on the subject but really doesn't know much more than what he's read) Currently the mod charges a flat rate for resources per watt of heat removed based on the DRA proposals for Mars missions. That comes out to just over 100 watts of electricity per watt of heat removed. (so passive insulation is a must which is why that's been a part of this mod and is VERY soon going to be replaced by configurable passive (MLI) in Real Fuels) If your tank is already overheated those electrical costs get VERY expensive and that strikes me as unrealistic given that the original citation was for cryogenic temperatures, specifically for liquid hydrogen at around 20K. So I need help in determining how that cost would be affected by higher temperatures. Specifically I need a range of electrical costs from 4K - 300K. The new heat pump RESOURCE node format is going to change in the next update to this: (the first number of each key is the temperature of the tank that heat is being removed from and the second number is the cost per watt removed - the last two numbers aren't important to this discussion) (actually the cost is KWe per KWt removed since that's scale used by RF but that's just a scaling issue; the math is the same) RESOURCE { name = ElectricCharge rate { key = 4 2000 -367.5568 -272.2836 key = 20.15 114 -13.8706 -13.8706 key = 40.3 28.5 -1.12649 -1.12649 key = 80 7.113802 -0.312432 -0.312432 key = 92 3.988803 -0.1483255 -0.146298 key = 120 2 -0.01839706 -0.01839706 key = 240 1 0 0 } }

You should work on your OCD instead. You'll be happier, in general, in the long run. IMNSHO

When you get 404 errors you get angry. When you get angry, you go blow off steam. When you go blow off steam, accidents happen. When accidents happen, you get an eyepatch. When you get an eyepatch, people think you're tough. When people think you're tough, people want to see how tough. And when people want to see how tough, you wake up in a roadside ditch. Don't wake up in a roadside ditch!

@crossfeedStatus = true

@Jimbodiah Don't just look at the base configs, look at the final result in ModuleManager.ConfigCache both for the clamp and for the resource definition.

Yes I had to change things because of the old particle system being deprecated. (something that has been coming for awhile) A separate release wouldn't be helpful, no. Things have gotten held up a bit because there were other code changes I wanted to go into the next update but I'm also working on other things such as Real Fuels and getting some new cryogenic changes there and that caused me to lose my DR momentum. I'll try to get a DR update pushed out soon.

Longitude of Ascending Node. Pretty much what it sounds like, just tells you where the AN is located.

I'm curious, what sort of Avionics Ring shenanigans are we talking about? I haven't seen any myself and just tried it out in KSP 1.4.2 and it behaves just fine. I'll be sorry to see it go as I use it all the time Edit: sometimes the Orion style SM just doesn't the propellant capacity that is needed for long missions. Especially with scaled up star systems where Minmus is way out in the boondocks Edit #2: The only reason the small port is given any official change in lore as to passability is so that they can fit it on top of that bay part thing in the DLC. It never had any functional limitation as to crew transfer seeing as how the stock crew transfer function does no passability checking anyway. I can't speak for anyone but myself of course but I never use the Jr unless it's for small satellite craft or some EMU part for Kerbals to dock onto. In short, it's a niche piece for me. Making this change is essentially forcing everyone not to use the standard size clampotron on any of their craft or stations because it immediately makes it incompatible with everything else unless you're planning to make the new port cross compatible.

@nickicool To put it even more bluntly than @TranceaddicT, using an older version of MM is the equivalent of burying your head in the sand and pretending the errors don't exist. The errors are still there in 2.8 even if you don't see them. The correct solution is for the problematic configs to be corrected. Something that wasn't possible before you knew about the errors. Go forth now and report the errors to SETIRebalance. (check first that they aren't already aware of the problem in case it's already been fixed) You're welcome

No, you'd have to reimport the parts AFTER fixing whatever problem the individual parts had in the first place.

I watched that for about a minute wondering how many times you were going to thrust up into the air and come down.... D'oh!

No wiki (well there is but it only has a little section on updating to a save breaking version of RC) But the first post has a FAQ and I think this was the very first question man. Or maybe the second And a video that shows you how to do these things. Always always read the FAQ. Or one day you might ask question and instead of Nice Starwaster you might get Evil Starwaster who simply replies, "Hey, space is a tough place where wimps eat flaming plasma death." Or I might do that anyway because, you know... cool quote and all.

It's worse than unnecessary because it can cause other configs that use NEEDS to trigger when they should not trigger. FOR should only ever be used by the author of the mod specified by the FOR.

Click on the Action Group editor button in the VAB/SPH and then click the chute part you want to edit. If you are playing career mode then your VAB/SPH must be upgraded before you can use the AG editor edit the chutes.

Oh I agree 69,105% The only thing I can think of is that Kerbals are so anxious to get into space that they tried to leapfrog their technology and ignore the obvious progression.... or something. It's definitely bizarre where wheels and probes and even jet engines are in the stock tech tree.

Only if you've researched logs.

Hey don't laugh! The Flat Kerbin Society has members from all around the globe!

Some physics is ignored if PhysicsSignificance is turned off. They lack their own colliders and don't get autostruts. (that doesn't mean they don't collide at all; they just don't act the same in a collision having only very simple models). They have no rigidbodies so they have no mass; instead, their mass is added to their parents. Other characteristics such as thermal and aerodynamics still apply. (AFAIK, lacking rigidbodies, drag force is applied to the parent - not sure of that though)

Using parts in ways they were never intended is the very epitome of Kerbal Space Program. Ease up.

It's possible, yes, though I think the author, Maja or both have said that it would probably necessitate making a new mod. I have a hacked version that makes amphibious craft possible (using the Lynx rover parts) but it's been so buggy that there's nothing I would even want to put into a pull request and I frequently have to intervene by editing my save file because this or that vehicle gets its landed/splashed state set incorrectly. It is NOT pretty when KSP thinks your craft is LANDED = true and it's sitting on the top of the ocean. (teleport straight to ocean floor where my rover is crushed like an egg shell) A dedicated boat autopilot mod would probably be easier. Not saying it HAS to be done that way but it would make sanity checks easier dealing with craft that are limited to one medium. Edit: The engines don't really make things intrinsically harder, though to do it right you would probably want at least some rudimentary thrust vs drag checking to get an idea of how fast the craft could go. (my version only works with the Lynx parts so I was able to make assumptions as to what kinds of speeds I could go and what it would cost me in energy)

You want them folded downwards; they start folded upwards so rotate them 180 degrees. You will also notice there is a little arrow opposite of the actual fin on the mounting part. That arrow should point up. Don't use deploy, just extend, toggle or retract. Deploy for control surfaces is if you're trying to make something like flaps. I guess could use it on the grid fins and it would stabilize things by spinning the craft the way some bombs are stabilized by their fins spinning them. I can't really imagine it would be very useful for something you wanted down in one piece, especially if it has crew on it.