Sandworm

I don't enjoy being the buzzkill, but I suggest moving away from the Star Wars trademark asap. The new movies start in 100days and the media campaign is starting. Very soon there will be hired guns trolling around the internet looking for any "use" of Star Wars IP. So rather that wait for the inevitable demand/takedown letters, I would suggest adopting a different name. "Kar Wars" would probably do. That would at least keep the thread out of any "star wars" bot searches. KSP modders have long played fast and loose with trademarks. Most all the companies involved really don't care and probably enjoy the attention (SpaceX). But "Star Wars" is owned by Disney, which is 1/5th of the MPAA. Right or wrong, they are a 10,000lb gorilla. It's best to stay far away.

Idea: With the mute functionality in place, how about a user-defined altitude for mute/unmute? At the moment the music starts rather abruptly at a hardcoded 70km. That is meant to be the transition between atmo and space. But many people play on non-stocked sized kerbins with different atmospheres.

Poodle = Squad = nerfed. Really, there isn't much science behind the stock thrust/weight/ISP/efficiency/size ... they pull their constants out of hats. Ideally we could use the same engines with different bell options but that's an entirely different mod.

Downloading now. I'm playing on a 6.4-sized version of outerplanets and need some bigger parts. Tweakscaling engines is cheating imho. I just did a couple test launches and this is very useful. They aren't any more powerful than clusters of smaller engines, but they sure increase my fps on big launches. And they do not seem oversized in comparison to the launch pad. That flame pit is much bigger than any reasonable rocket using stock or similar dimensions. I would suggest that the monumental difference between vacuum and atmospheric ISP is too much. If a vacuum engine is really going to be that bad in atmosphere then it should have a truly massive bell ... massive is in 10x the size of an equivalent atmospheric engine. Think Apollo, tiny engine giant bell.

Please don't. I just gave this a try last night and it works wonderfully as is. Seeing stations rotate smoothly under warp and then NOT explode is a real improvement on previous attempts. But mod integration gets silly complicated very quickly. If anything, output some number and leave it to those maintaining the lifesupport mods to integrate.

This isn't an easy decision. Adding the software, or at least keeping it active during launch, presents new failure options. That software will be in control of mission-destroying hardware, namely launch-abort rockets to pull the capsule away. Should they activate improperly on assent --> launch failure. Or they might activate some time after launch, perhaps on approach to the space station (depending on how the rockets are configured and whether or not they are jettisoned after assent). That sort of failure could kill. So there needs to be a risk balance between the advantage of perhaps saving a robotic capsule in the rare case something goes wrong with the launcher, against the extra risks associated with flying that system. I would not be surprised if SpaceX decided it wasn't worth the risk. It all depends on how valuable that capsule is after abort and recovery. It certainly will require lots of work to return it to flight worthiness, if that is even possible. What if it's just carrying food and water?

I too am using the hotfix and am getting this many many times per second. [LOG 13:55:16.293] Tac.LifeSupportController[FFE3EB76][1726.08]: Cannot cast from source type to destination type. [LOG 13:55:16.313] Tac.LifeSupportController[FFE3EB76][1726.10]: Error attempting to check DeepFreeze for FrozenKerbals [LOG 13:55:16.313] Tac.LifeSupportController[FFE3EB76][1726.10]: Cannot cast from source type to destination type. [LOG 13:55:16.333] Tac.LifeSupportController[FFE3EB76][1726.12]: Error attempting to check DeepFreeze for FrozenKerbals [LOG 13:55:16.333] Tac.LifeSupportController[FFE3EB76][1726.12]: Cannot cast from source type to destination type. [LOG 13:55:16.357] Tac.LifeSupportController[FFE3EB76][1726.14]: Error attempting to check DeepFreeze for FrozenKerbals [LOG 13:55:16.357] Tac.LifeSupportController[FFE3EB76][1726.14]: Cannot cast from source type to destination type. [LOG 13:55:16.375] Tac.LifeSupportController[FFE3EB76][1726.16]: Error attempting to check DeepFreeze for FrozenKerbals [LOG 13:55:16.375] Tac.LifeSupportController[FFE3EB76][1726.16]: Cannot cast from source type to destination type. [LOG 13:55:16.395] Tac.LifeSupportController[FFE3EB76][1726.18]: Error attempting to check DeepFreeze for FrozenKerbals [LOG 13:55:16.395] Tac.LifeSupportController[FFE3EB76][1726.18]: Cannot cast from source type to destination type.

Request: Can the ratio of sats to planet size for coverage be not hardcoded? I'm giving this a try on a 6.4x-sized kerbin and needing 64 sats around kerbin seems a little high.

I've been using the various test builds with CTT without real issues. There was a hicup a couple builds ago with the largest monoprop tank but that has been resolved. CTT should work with most any mod as it doesn't remove the stock tech nodes.

Displace all the stock parts you want. I can only bring myself to use stock engines once I've found some decent textures anyway. (The less said about the 2.5 decoupler the better.) Memory isn't an issue for the linux crowd. And those sheep with memory issues can always selectively delete displaced parts. Stockalike is an aesthetic. It doesn't require respect for stock items that don't measure up.

Gravity waves. It's possible in a 2-body system if the loss due to gravity waves or like effects is enough to reduce the velocity of the inbound object. It would probably require something silly like a cloud of gas with a periaps a few feet from the horizon of a supermassive black hole, but there is almost certainly some way to do it even with just two spheres.

I don't mean that you should eyeball approaches. If you do things in stages you should be able to intercept and park beside the target all from the map view using only the stock guides on the orbits. Once you have a coplaner+phasing orbit established you can do a burn to bring the next approach within 1-200m. The result is a much slower and more predictable interception. There are many advantages to this over maneuver nodes. The biggest for beginners is probably that it allows you to place the interception point wherever you want, preferably just after dawn so docking can occur in the light. I like to place it slightly before dawn so that as I reduce my relative velocity it moves into dawn.

(1) Ignore all advice. (2) Do not use the stock 'docking mode', use the translation key bindings with the right hand. (3) Do not learn in low orbit. Docking is much easier at 2000+km where relative motions are smaller. (4) Do not use maneuver nodes. Learn to intercept in stages (launch, alignment, phasing orbits etc) (4) Do not try docking until you are 100% on node-free interceptions.

That's my point. Between all the different game modes and sliders, there isn't any core game. I might sound oldschool about this, but I believe a game should have a core, something to point to as the standard mode of play. That doesn't mean a lack of freedom. Look at mincraft: a core survival mode with a couple options. KSP doesn't have such a thing. Take the three game options (sandbox/science/career) then and the stock difficulties (low/medium/high) and you have 9 game modes. Then say three heat options (off/medium/hard) ... that's 27. Life support on/off? Now its 54. Radio communication on/off? Now 108. Three resource levels? 216. Crew respawn? 432. Science/funds rewards ratios? ... Starting a new career means picking from literally a thousand different paths before you even see the VAB. It's no wonder that the youtubers have backed off career mode and KSP generally. It's hard to start a let's play when you cannot really point to a common standard for starting a "stock" game. Too much freedom of choice becomes a burden. It really turns off new or casual players. Reply to below: I think the youtubers want to connect with their audiences. They want to play the game in a way that their fans might. So they seek some sort of common game mode. The games that do well on youtube have that default (minecraft, subnautica, stranded deep, pre-career KSP etc). That's also why they shy away from mods. Note that some of the top reviewers have stayed far away from KSP. Totalbiscuit likes KSP, but how is he to honestly review the career mode? He'd get a few hours in, realize he started with less-than-ideal gameplay settings, and have to restart.

No. The "it's optional" argument is a crutch for poor decisions. If Squad wants to add core features to a released product then they must force themselves to iron out the balance prior to release. Stock KSP already saddles users with too many balance decisions (science/heating/rewardsx3). The result is, more often than not, an unbalanced mess. One should not have to grind through career mode a half-dozen times before finding all the sweet spots. That job belongs to the developers. The game needs to be fun out of the box, all the way to the endgame content. I cannot be the only one here who dreads starting a new career-mode save. I know that no matter where I put the sliders I will eventually face a grinding cliff of procedural missions for irrational rewards. I want to play career mode, but have had too many negative experiences and now stick to science-only. Adding another slider for "life support" will only multiply this problem.

There is no way Squad can pull the a support rabbit out of its hat. Proper life support, anything deserving of that name, means Kerbals die if X or Y resources are depleted over time. That means for life support you need some means of calculating trip time. Stock KSP has absolutely none of the tools for calculating such things. Even with mods it isn't exactly easy. I predict something silly. I predict something like "If Jeb runs out of donuts, he stops wanting to hold prograde", or "scientists stop reseting experiments when snacks run low". OR imagine the cluster if they tie "life support" to the stock heat system.

The new probe cores look great. The tiny monoprop engines are great for fine tuning landings. And the whole art package fits very well with the other stockalikes. There are at least seven parts mods in this pic and RLA fits right in.

Thanks! I've been waiting for this for a while. Will test tonight.

Tellion has one in development at github but has not released. I've been playing it for a few days without issue (linux 64-bit) but that doesn't mean it is stable for anyone else. https://github.com/Tellion/OPM_64K

A deployable RTG would be cool. I know they aren't turned on and off so easily in real life, but one that couldn't generate power until it deployed fins would be kosher imho. Or along the same lines: a deployable radiator. A deployable light. Perhaps a stick with either a forward-facing or self-illumination spotlight on the end. Apollo used one for the EVA work to/from the moon. A deployable ladder. I often find myself floating around collecting science on orbit and would appreciate a stowable ladder in a wedge. RCS thrusters would be less useful but seriously cool. They need not deploy. Simply opening the doors to expose/activate some lateral thrusters would be original.

It isn't a drag problem imho. The part isn't building up heat through friction with the air. These explosions can happen in space and are not dependant on airspeed or anything else drag-related. It looks like a proper bug, an error in how Squad implemented heat on small/lightweight parts. Or, more specifically, how Squad intends heat to move from large to small parts (small parts attached to large ones often get hotter than anything they touch). Upping the part's thermal mass solved the problem for me.

I found one. I pulled the texture from the Renaissance Compilation pack (8192x4096). Just put it in the 64k directory and renamed it match the 64k's "x64k_Kerbin_Color.dds" (4096x2048). I won't say its a perfect drop in replacement but it is an improvement.

I would add that improvements in air-to-air refueling was another nail in the coffin. Improvements in flight controls, radar and radio communications during the same period made getting two large aircraft so close together much easier and more reliable. The big bombers (Bear+B52) spend a huge amount of fuel just getting to altitude. Giving them a full tank once already up there more than doubles the time aloft. So keeping enough bombers on station via refueling became the much cheaper option.

Does anyone know where I can get a higher-rez texture for kerbin suitable for 64k? Memory isn't an issue.

New theory (My US cores are exploding again).... I looked at the cores in flight and noticed they were not exactly overheating. They were in fact flashing between hot and cold very rapidly. It was like the heat 'packets' were too large when hitting a lightweight part. I saw similar flashing a few days ago with Novapunch parts connected via decouplers. When I increased the mass of the US bases the problem went away. At a mass of 5.0, instead of 0.5, the octocore didn't overheat. More importantly, at a mass between 0.5 and 1.0 it would overheat more slowly. Heat capacity is therefore based on mass, which does make some sense. Then I dug through the cfgs for parts that cool things, specifically the aero parts that cool incoming air, and noticed the "thermalMassModifier" attribute. It seems to act as a multiplier for heat capacity bypassing the need to increase part mass. So try adding this line to the octocore cfg: " thermalMassModifier = 2" That should increase the part mass for purposes of heat to 1.0. For the hex I'm using a multiplier of 5. This seems to work but I am still testing. I've been wrong before.