Hello,
I've got an issue with all command pods. When its manned with Kerbals, it still behaves as probe, so when I lost connection to space center it becomes uncontrollable.

IDK, I don't use the stock comms system. No clue how it works or what its limitations are. (MJ pilots most of my craft, and it completely ignores pilot/probe core stuff)

If you know of a solution to the problem, I'll gladly implement it, but I don't currently have time to be chasing down stock bugs.

(AFAIK as long as you have a pilot onboard, that should override the probe core; if that is not working... well, feel free to poke around in the part configs and see what you can figure out)

Thanks for reply,
I'll look to the part configs and see if i can figure something out.

NP, please let me know if you spot anything. As stated, I'll gladly fix the problem if I know what it is (and what the solution is).

You might be able to compare them versus the stock pods and probe cores to see what is different between them; one of those source should have some answers for you :)

So, I looked to the module config files and found the issue. It's caused by this setting:

MODULE
{
	name = ModuleCommand
	minimumCrew = 0
	hasHibernation = True
	RESOURCE
	{
		name = ElectricCharge
		rate = 0.0275
	}
}

If minimumCrew is set to zero, the pod is simply treated as probe. I don't know if there's any way to do hybrid command module, but it seems, that stock game has no support for remote control override.

So, I see only one fix of this issue, which is to rewrite configs for parts, so they will look like this:

MODULE
{
	name = ModuleCommand
	minimumCrew = 1
}

And for remote control add Mechjeb AR202 case in VAB/SPH.

Hmm... that would functionally break the parts being usable both crewed and uncrewed.

Will have to give this some thought on how to best handle it. I believe you are correct in that stock code has no accommodations for this kind of a setup -- stock parts are either a command pod or a probe core.

Thanks for taking the time to investigate, that at least lets me know what is going on. Will still have to deliberate a bit on what the best solution is.

You're welcome. If I could, I will fork your repo to my github and edit all configs, so the modules will work as manned command pod.

You are more than welcome to fork and make edits for your own personal use.

I will have to find a different solution for the problem in SSTU though, as those pods being usable uncrewed is a requirement for me/my games (90% of the time I launch them uncrewed for rescue missions, resupply, crew return, etc). (Of course, I also use MJ, which has no issue with uncrewed use last I checked...)

I know how you mean that. I prefer using unmanned tech too. But I don't like the situation when I lost connection, or run out of power, have Jeb onboard, but he can't do anything. The second easiest solution is to clone those modules and create one version unmanned and one manned.

No power = lost mission.

I have the comms turned off now as it's buggy as all hell and doesn't work half the time anyway. But when there is a pilot on board, I have never had issues with uncontrollable craft. But if you run out of Ec, then even a pilot can not save you.

The game's treatment of crew is unfortunately sort of bizarre. EVA and they start tumbling in stock (no crew aboard).

Hit time warp and they stop (unless you use persistent rotation) ;)

BTW: You can change the reaction wheels on each pod to work with a pilot only, maybe that is an option?

So, I cloned original parts and created their crew controlled versions. If you want I can of course create a pull request.

Thanks for the offer, but I'll have to find a different way to handle those parts. I do not believe in duplicating parts for such a simple difference in functionality; even having the CM and CMX pod versions bugs me.

Ok

Meh, don't overthink this. Another system that must brave high warps and causes problems is not the answer. KSP has enough issues on it's own; I've just given up on another save game where I get the kraken destroying my ships every other time I come out of time warp. After you get x number of ships in your save, it just freaks out and starts destroying stuff.

Why have the CMX versions? If you set heatshield to minimum and remove the ablator resource with the slider, you have the same thing. The only difference is that you have a tiny fairing portion to cover the heatshield.

If there is a desire for an orbital command pod, maybe integrate a dedicated part into the proposed horizontal lander core ? The apollo looks funky for a command pod anyway, only the Orion lends itself to futuristic horizontal pods (which is why I have a 2.5m version of it ;) ).

They exist simply to differentiate the parts between the heat-shield and non-heat shield versions, and to allow for removal of the heat-shield module on the CMX version (no reason to have the code there and running if it doesn't need to be). The models (and attach nodes) could easily be swapped through plugin code; the modules less so.

The CMX also come with extra supplies/battery/RCS fuel, and lower overall mass (this was more of an after-thought; since it was already a separate part, might as well make them a bit more different).

So basically they exist for three reasons:
1.) Stock code cannot handle addition/removal of modules from parts at run-time (both the heat shield and fairing module would need to be removed from the CMX/no-heat shield variant) (CPU efficiency).
2.) More resources/usable volume for life-support when used as a medium/long-term hab part (mass efficiency).
3.) Remove the mass penalty for the heat-shield entirely on the CMX version, allowing for better integration into craft designs when used as a cockpit/command-center (mass efficiency).

2.) I could only imagine this if for 4 crew instead of 6. The 6 crew rating is only for LEO transfers, and I think 4 crew for long missions?

Did a bit of testing on this, as I was curious exactly what was going on and why I had not noticed it in the past.

It seems I am able to control the pod just fine even when comms are occluded:

I had full manual control in the above screenshot, even though there is no comm-net connection. I did have a pilot onboard, and there was sufficient EC.

Strangely, turning on 'hibernate' mode on the probe core does disable manual control (which it should not). But otherwise manual control seems to work just fine, as-intended.

Ahh..the wonderful buggy stock implementation of features....so great....

Is there something on this problem that I'm missing that would make it an actual problem? From my testing, the only thing that was 'odd' was the hibernation bit. As long as you have EC, a pilot on board, and disable 'hibernation', you can have manual control even when not connected through comms.

That is what I have, cq working as intended™ Maybe OP was running out of Ec? I have patched all SAS to hibernate automatically as it drains energy at a high rate causing probes etc to die for no reason due to lack of Ec. I don't know why this is not set by default in KSP, but it's not the only thing I wonder about.

PS: The comnet system is unreliable as can be, I would not trust too much on it to work. It sometimes just dies all-together and only wakes up again when I restart KSP.

Running out of EC might be a cause of loss of control. But it all makes sense in context.

Think of the 'probe core' portion of the craft being the onboard computer system.

• As long as it is powered on (not in hibernate), it drains EC.
  • When connected to remote source, allows remote control.
  • Allows pilot local control if pilot is present, even when not remote-connected.
• When powered down, it still drains small amounts of EC (keeping things warm).
  • Does not allow pilot control; the flight-computer is off.
  • Does not allow remote control; again, the flight computer is off.
  • Running out of EC obviously means the flight computer is not running...
  • Orion is a computerized spacecraft. Does it even have manual controls for things like RCS/etc for when the computer fails or power runs out? (unsure; but doubt it does)

Edit: I will add that this setup might not make as much sense for other lower-tech pods/etc, so I will still be investigating how best to handle those cases. I think it is fully applicable to the existing pods in SSTU though, as all of those spacecraft were capable of autonomous flight, and required functional onboard computer systems (however primitive they may have been).