johnsonwax

I don't think that's how the backup code would work as a dish wouldn't iterate over all possible coordinates. My understanding is that the backup code would have a fallback to point to a specific location. So for instance in the VAB you would pick an existing target (can't be an unlaunched vessel), most likely Mission Control, and if the ship lost connection RT would activate antenna/dish and then automatically enter that default target. If that target (say Mission Control) is blocked, then you still have no control. If that target is no longer in service (you deorbited it, or nothing else is in the cone if you pick a planetary body) then you still have a dead craft. That would lead to three general strategies: 1) In Kerbin SOI, you'd likely point to Mission Control, and possibly have to wait some hours for your craft to have LOS to Kerbin and to Mission Control. Hopefully you aren't sub-orbital... 2) Outside Kerbin SOI, you'd point to Kerbin and worst case pick up Mission Control, or if you had nothing in orbit, you could tossup a satellite and it would pick up the new satellite in that case. 3) Fail to set a backup, in which case you must make sure you activate/target before you lose control from your fixed antenna, etc. So in the case of a deep space probe that was set to target a relay in solar orbit near Kerbin, should that relay need to be replaced, you'd set Kerbin as your backup. When you take the relay out of service, the probe loses connection, activates dish, targets Kerbin, picks up Mission Control or some other sat in orbit, and when the replacement relay is up, you can then re-target your probe to the new relay. The problem with iterating over the target list is that the probe might have a limited number of targets to check, but it would never have that entire list. If a single backup was insufficient, then providing two backups shouldn't be too much harder. Edit: And yes, I think omni's should be able to talk to dishes, but is that really a common problem? I never launch a dish probe that doesn't also have an omni simply so that I have a suitable recovery option if needed. That basically means that everything has an omni.

CKAN shows MJ 2.5.0, but Editor Extensions still shows 2.3 for me as well.

Another thought. In the event of a failure, can the plug-in automatically hit the abort control? Might as well give an incentive to install a proper LES.

Nice idea. One problem I have with career mode is that end-game there's no use for science other than to convert it to cash. What about a strategy provision to invest science points to decrease failure rates? Better yet, make the rate somewhat dependent on vehicle part counts so you have an incentive to simplify the craft, or need to invest more science to increase reliability.

Can't see this in CKAN. Does it take a little while to show up there? (Using CKAN for the first time...)

Roverdude, Any possibility of getting USI-LS, Exploration Pack, etc. into CKAN? With so many rapid-fire mod updates, CKAN is really helpful for your users to keep things up to date.

I think the clamps following you around happens with Extraplanetary Launchpads. Has to do with how EL handles building out from the shipyard. Check that thread for issues.

On that point, if you're checking their occupation, give priority to the scientist. If there were two scientists, priority to the more or less experienced? Hmm...

Someone needs to write a mod to put a suitable sized docking port and heatshield on said command pod.

Yeah, he said he's already got some stuff done but unreleased for 1.0 at least for KIS. So he's working on it.

MJ 2.5 is the version that supports KSP 1.0. Go download.

Boy, if you can get inverse kinematics working, then manipulator arms get way, way more interesting. Though my guess is you'd still need some kind of bounding box/collision detection as mechjeb docking autopilot has. But still much closer.

Thanks, I'll give that a whirl. Kospy, I suggest including some kind of MM fallback file like this as even though Squad will get IVAs in there, there will always be mods that don't. Tough problem for users to debug.

Is the kerbal's disappearing inventory fixed in the next version? I just sent a mess of parts to my station assuming my engineer could install the critical part I needed, only to discover that the tools I sent him out with were gone.

Might I request a feature: A set of readings for contract locations. Selected contract navigation point, whether you are in the region or not, distance to region, heading to region. I seem to always miss the notification when I'm entering a region and there's no other way to tell if you're in one or not.

This please.

Yay! Cooperation! Thanks for keeping this going.

That's not quite right. Borrowing against an appreciating asset is perfectly reasonable (house, education, etc.) but borrowing against a depreciating asset (car, etc.) is a terrible idea. Since KSC facilities allow you to run larger and longer missions that pay better, the facilities are potentially an appreciating asset (assuming you use them properly). The reputation hit would come from failure to repay the loan, not that the loan is taken out in the first place. In fact, the only real way to increase your credit rating is to borrow and repay responsibly. The interesting game dynamic in KSC is that you quite quickly move from missions that take no more than a few days to ones that take a year or more. Borrowing to get to Mun or Minmus is almost a no-brainer, but borrowing to get to Duna will likely bankrupt you fairly quickly if you use the warp button because the mission is going to take a year to complete (though it does provide a new incentive to transmit science data back home rather than wait months to deliver it.) OTOH, if you borrow to initiate your Duna mission, you may need to use the time in transit to run shorter-duration missions to keep cash-flow going until that one pays off. Put short, the warp button demonstrates how unrealistic the in-game payment system is. Nobody would take a contract for 100K that takes a year to execute when you can take one for 50K that takes a day to execute. But the contract system alleviates the need for most borrowing after the first few days as the contract advances can fill that gap if you're careful about what you take. Before I took my first Mun mission I grabbed two contracts that paid 600K+ and gave 100K+ advances. That allowed me to upgrade launchpad and unlock parts to initiate the missions, and then enough payoff on completion to upgrade tracking station, astronaut complex, and some other buildings to make the Mun mission pretty easy (unlock EVA, etc.) The problem you need to consider is the late game impact of payroll. How much cash will you need to have to launch a Jool mission and make payroll, or will you never be able to warp because you need to keep running other missions (and will there be enough short-term missions to do that?). Not sure how the contract system works late game. But for that scenario, you might want to look at Kerbal Alarm Clock to to stop warp when you're about to run out of money or some such. Slipping and hitting 10k warp instead of 100k could be a game-ending error.

Feature request: An optional setting to restrict MechJeb functionality to pilot/engineer skill as well as upgrades. A pilot that can't orient to target shouldn't be able to program a vessel to do rendezvous autopilot. I'd limit docking autopilot to higher skilled engineers. Probes shouldn't be automated without tracking station upgrades, etc.

I have to agree with the above - this is a much different (and better) game. I agree that we need a tier between 2 and 3, and possibly two tiers in there with some tweaks. 1) The current setup still favors rocketry a bit too much over planes (yes, I realize it's Kerbal SPACE Program) but you do have to get a bit far before you get a jet engine, and that really needs to be moved forward quite a lot. 2) I'd make the hangar/runway upgrades decently cheaper than the VAB/launchpad to encourage advancing there first. As noted above, getting jets going quickly really opens up science/funds through judicious selection of part testing and overflights. 3) I think TAC or something to that effect is needed to get that tier between 2 and 3 for extraplanetary manned exploration. Delta-v to other planets for a capsule is not hard. Delta-v to other planets for a ship with enough space and food and water and such for 2 years is an entirely different proposition. That's also needed for Kerbin SOI stations/bases, and something more (resource extraction + closed loop systems, even simple ones) for extraplanetary stations/bases. 4) The building upgrades are a little too unobvious. Since you can enter each one, I'd add a button/status indicator on the activity screens for each building. I can see a lot of people completely missing the upgrade functionality. 5) The missions seem a bit unbalanced in that they offer up many missions that are effectively impossible to achieve, and with an early limit of 2, it's really easy to take missions you later realize you can't possibly upgrade to achieve. I'm a pretty experienced player and I have to be extremely careful what to accept given the bounds of what I know is feasible with the science I've unlocked and the parts I can afford. If I take that Kolniya orbit around Minmus with power and an antenna and a materials bay and goo container mission before I have solar and the 48-7S unlocked means that I've burned half of my available mission slots and have to rack up 180 science on a single slot or face a failure penalty of half of my cash. To put a finer point on 5) - the game as currently set up is actually much harder in the early stage than it will be in later stages, and that strikes me as a bit wrong toward getting new players on board. Perhaps the nature of the missions could be adjusted in accordance with the difficulty so that at the easiest settings you don't get any missions that you don't have the science/parts/limitations to do. That's not necessarily easy to sort out, but I think it's necessary toward balance. New players on easier settings shouldn't get caught up against nearly impossible missions with so few avenues to get out of them.

Ah, okay. I think the problem is that I was under the impression that Unity 5 had released, and I don't believe it has yet. Unity seems to be very off the rails ATM.

I guess I don't understand that reasoning. 64 bit support in OS X is much more cleanly implemented than in Windows, much more like Linux. Granted, there are fewer of us Mac users, but there has got to be more of us than Linux users. Why not push out the 64 bit versions that are working while they sort out the Windows wonkiness?

Any sign of a 64 bit Mac version? This is frustrating given that 64 bit Mac should be effectively free.

I suspect your Mun satellite is targeting active vessel, so if you are focused on one of your Kerbin sats, the Mun sat connects to it. If you switch to the Mun sat, it's now the active vessel, so the connection drops. My general design rule for RT sats is one of the longest useful antenna, and a minimum of 3 dishes. One dish is always a downlink toward KSC or whatever control station you are relying on. One dish is a *fixed* uplink toward either a remote exploration ship or to a remote local network. The 3rd dish is to active vessel, so whatever I'm flying always benefits from a connection from literally every satellite in the solar system within range. For most permanent networks, I'll usually have 5 dishes: 1) Downlink to Kerbin 2) Peer comm sat in same SOI 3) Other peer comm sat in same SOI 4) Ground base within SOI (Mun base, etc.) 5) Active vessel 2) and 3) are for redundancy purposes. More than once I went to replace/upgrade a sat and broke my network because I forgot to switch targets on another sat and had to rendezvous with it to regain control. I always have 4) because even with sufficient antenna range, I've had problems with networks bridging from omni to target in the past, so I only use omni for transit vessels and backup - and use a fixed connection for anything permanent. 5) is only useful for transit vessels and useless for maintaining the network itself. What would be very useful and interesting is a 'lock on last active vessel' upgrade/option so that all non-focused sats connected to the active vessel (assuming they have active vessel selected and sufficient range - current behavior) and then maintained that connection when you switch to them. If you then switch to another vessel, they'd follow to that vessel. But it'd allow you to repair a mis-configured network by walking the graph up from KSC configuring each satellite as you go. It would still preserve the existing active vessel functionality, and it would be doing nothing magical since it requires already being able to create that connection - we're just having it hold the connection over vessel change.

Aha! That's why we should ask these questions. Would explain why I'm not getting the kind of memory savings I was expecting. Thanks to all for the clarification. Time to find a new approach here.