[1.4.1] Take Command Continued- Launch Kerbals in External Command Seats

[linuxgurugamer]

4 hours ago, Lisias said:

"kerbalEVAfemale (" + kerbal.name + ")"

Seriously? It was that?  

I failed to understand the need of such change on KSP's code, but… I'm happy the problem is solved.  

Because kerbals are vessels.  Im guessing they are using that to determine which model to use.

[Lisias]

36 minutes ago, linuxgurugamer said:

Because kerbals are vessels.  Im guessing they are using that to determine which model to use.

I will take another good look on KSP' sfs and quick save formats. I don't remember such a hack from there.

(sometimes, KSP leaves me a taste of Java^script on the mouth while drinking my coffee.)

Edited June 29, 2018 by Lisias
=P

[linuxgurugamer]

3 hours ago, JoE Smash said:

Hello,

So I downloaded the patch from this thread put it in my game data folder and launched KSP v1.4.3.

I opened my savegame and tried the Meadowlark EAS-316 pod with Jeb and intentionally a female a kerbal. I am also using Kerbal Konstructs and was at a different runway than the main KSC runway (no idea if that matters). Told it to launch. Only Jeb appeared and he wasn't in the command pod and there was no way to board it.....just climb on it. The female kerbal was MIA so I reverted flight to inside the SPH. I tried relaunching at the KSC and this time they both appeared but neither were in the pod and there was no way to board it either.

I started a new career sandbox mode, because I had not yet unlocked the normal command chair to test out. I put 4 normal command chairs on some default ship model I loaded up, and put all 4 starting kerbals in the chairs and then launched the rocket to the launchpad. All 4 kerbals were in their chairs, no one was in the mk1 command pod and I was able to launch the rocket and get into orbit.

So I guess this is a bug/issue with that specific part I was using which is a part from SXTContinued. I am including a copy paste of the part file for the specific part in the event you still wished to address this. I know you also maintain SXTContinued, Linuxgurugamer, and may be familiar with the particular part, but I was just trying to save you 5 minutes of looking things up....as far as the specific part name....how you referred to it in the file, etc.

Anyways no big deal either way. It is a cool part though, because of it's low weight, it holds two kerbals and they are exposed to the elements because the sides are open.

If you do post things like a full part's config, please put it into a spoiler.

Anyway, I suspect that if you hit F3 after launching with the Meadowlark, you will probably see that at least one kerbal was killed.  And the other is probably underground.

It's a problem with the part.  Short answer, just don't try to spawn two kerbals in it at once

[Lisias]

2 hours ago, linuxgurugamer said:

It's a problem with the part.  Short answer, just don't try to spawn two kerbals in it at once

This is somewhat sad, the EAS-316 is gorgeous.  Assuming that a proper fix is possible, would you accept it on Take Command?

In time, I did my home work by giving a peek on the persistence.sfs and quicksave.sfs files. I'll publish the results here, since it's here where I found the need for it: (This is not for LGG, it's more than obvious that he knows about - I'm just documenting the status-quo in the hope of being of use to someone in the future).

Kerbals on the SFS files are stored on their own entity called (surprisingly  ) KERBAL:

Spoiler

		KERBAL
		{
			name = Barming Kerman
			gender = Female
			type = Applicant
			trait = Pilot
			brave = 0.618894279
			dumb = 0.289769977
			badS = False
			veteran = False
			tour = False
			state = Available
			inactive = False
			inactiveTimeEnd = 0
			gExperienced = 0
			outDueToG = False
			ToD = 110846.57620010794
			idx = -1
			extraXP = 0
			suit = Default
			hero = False
			CAREER_LOG
			{
				flight = 0
			}
			FLIGHT_LOG
			{
				flight = 0
			}
			KerbalExt
			{
				experience
				{
				}
			}
		}

 

Ok, there's a "gender" atribute. But yeah, when a Kerbal goes EVA, he/she become a VESSEL, and vessels don't have genders.  

Spoiler

		VESSEL
		{
			pid = b594335855634ccbb6108218a2c7a984
			persistentId = 3995704249
			name = Sigsel Kerman
			type = EVA
			sit = LANDED
			landed = True
			skipGroundPositioning = False
			vesselSpawning = True
			launchedFrom = Runway
			landedAt = KSC_Runway_09
			displaylandedAt = Runway
			splashed = False
			met = 42.980000000938162
			lct = 15323.420391273377
			lastUT = 15366.460391274317
			distanceTraveled = 0.064401319275122881
			root = 0
			lat = -0.048624494427084997
			lon = -74.724665886657903
			alt = 69.483075282769278
			hgt = 0.284948289
			nrm = 0.00174321001,0.999995887,0.00229370594
			rot = -0.415649951,0.442353755,-0.57197541,0.551726758
			CoM = 0,0,0
			stg = 0
			prst = False
			ref = 0
			ctrl = True
			PQSMin = 2
			PQSMax = 9
			cPch = 0.3701451
			cHdg = -3.827159
			cMod = 0
			ORBIT
			{
				SMA = 300817.07669146126
				ECC = 0.99479859878685828
				INC = 0.048629048464254261
				LPE = 90.784135601380029
				LAN = 1.1999356935000378
				MNA = -3.141592367747807
				EPH = 15366.460391274317
				REF = 1
			}
			PART
			{
				name = kerbalEVAfemale
				cid = 4292080954
				uid = 394332028
				mid = 1700778371
				persistentId = 3858849331
				launchID = 4
				parent = 0
				position = 0,0,0
				rotation = 0,0,0,1
				mirror = 1,1,1
				symMethod = Radial
				istg = -1
				resPri = 0
				dstg = 0
				sqor = -1
				sepI = -1
				sidx = -1
				attm = 0
				srfN = , -1
				mass = 0.09375
				shielded = False
				temp = 301.28424429857353
				tempExt = 301.65459562585562
				tempExtUnexp = 301.65546929906708
				expt = 0
				state = 0
				PreFailState = 0
				attached = True
				autostrutMode = Off
				rigidAttachment = False
				flag = Squad/Flags/default
				rTrf = referenceTransform
				modCost = 0
				crew = Sigsel Kerman
				EVENTS
				{
				}
				ACTIONS
				{
				}
				PARTDATA
				{
				}
				MODULE
				{
					name = KerbalEVA
					isEnabled = True
					JetpackDeployed = False
					lampOn = False
					lastBoundStep = 1.20833337
					_flags = 1
					stagingEnabled = True
					state = Idle (Grounded)
					EVENTS
					{
					}
					ACTIONS
					{
					}
					vInfo
					{
						vesselName = Sigsel Kerman
						vesselType = EVA
						rootUId = 394332028
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = ModuleScienceExperiment
					isEnabled = True
					Deployed = False
					Inoperable = False
					cooldownToGo = 0
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
						DeployAction
						{
							actionGroup = None
							active = False
							wasActiveBeforePartWasAdjusted = False
						}
						ResetAction
						{
							actionGroup = None
							active = False
							wasActiveBeforePartWasAdjusted = False
						}
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = ModuleScienceExperiment
					isEnabled = True
					Deployed = False
					Inoperable = False
					cooldownToGo = 0
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
						DeployAction
						{
							actionGroup = None
							active = False
							wasActiveBeforePartWasAdjusted = False
						}
						ResetAction
						{
							actionGroup = None
							active = False
							wasActiveBeforePartWasAdjusted = False
						}
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = ModuleScienceContainer
					isEnabled = True
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
						CollectAllAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = FlagDecal
					isEnabled = True
					flagDisplayed = True
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = ModuleTripLogger
					isEnabled = True
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
					}
					Log
					{
						flight = 0
						0 = Land,Kerbin
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = ModuleEvaChute
					isEnabled = True
					chuteYawRateAtMaxSpeed = 1
					chuteMaxSpeedForYawRate = 50
					chuteYawRateAtMinSpeed = 1
					chuteMinSpeedForYawRate = 1
					chuteRollRate = 1
					chutePitchRate = 1
					chuteDefaultForwardPitch = 9
					semiDeployedChuteForwardPitch = 25
					chutePitchRateDivisorWhenTurning = 1
					chuteRollRateDivisorWhenPitching = 1
					chuteYawRateDivisorWhenPitching = 1
					persistentState = STOWED
					animTime = 0
					minAirPressureToOpen = 0.0399999991
					deployAltitude = 1000
					spreadAngle = 7
					automateSafeDeploy = 0
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
						DeployAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						CutAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = ModuleLiftingSurface
					isEnabled = True
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = ModuleLiftingSurface
					isEnabled = True
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = FlagDecal
					isEnabled = True
					flagDisplayed = True
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = ModuleAGX
					isEnabled = True
					placeHolder = Hello World
					currentKeyset = 1
					groupNames = 
					groupVisibility = 
					groupVisibilityNames = Group1‣Group2‣Group3‣Group4‣Group5
					DirectActionState = 
					hasData = False
					focusFlightID = 0
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = FMRS_PM
					isEnabled = True
					stagingEnabled = True
					MM_DYNAMIC = true
					parent_vessel = 0
					EVENTS
					{
					}
					ACTIONS
					{
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = KOSNameTag
					isEnabled = True
					nameTag = 
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = EVACamera
					isEnabled = True
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
						ZoomInAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						ZoomOutAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						ActivateCameraAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						DeactivateCameraAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						NextCameraAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						PreviousCameraAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = EVAEnhancements
					isEnabled = True
					kerbalProfession = Level 5
					jetPackPower = 1
					precisionModePower = 0.100000001
					precisionControls = False
					stagingEnabled = True
					EVENTS
					{
					}
					ACTIONS
					{
					}
					UPGRADESAPPLIED
					{
					}
				}
				RESOURCE
				{
					name = EVA Propellant
					amount = 5
					maxAmount = 5
					flowState = True
					isTweakable = False
					hideFlow = False
					isVisible = True
					flowMode = Both
				}
			}
			ACTIONGROUPS
			{
				Stage = False, 0
				Gear = False, 0
				Light = False, 0
				RCS = False, 0
				SAS = False, 0
				Brakes = False, 0
				Abort = False, 0
				Custom01 = False, 0
				Custom02 = False, 0
				Custom03 = False, 0
				Custom04 = False, 0
				Custom05 = False, 0
				Custom06 = False, 0
				Custom07 = False, 0
				Custom08 = False, 0
				Custom09 = False, 0
				Custom10 = False, 0
			}
			DISCOVERY
			{
				state = -1
				lastObservedTime = 0
				lifetime = Infinity
				refTime = Infinity
				size = 2
			}
			FLIGHTPLAN
			{
			}
			CTRLSTATE
			{
				pitch = 0
				yaw = 0
				roll = 0
				trimPitch = 0
				trimYaw = 0
				trimRoll = 0
				mainThrottle = 0
			}
			VESSELMODULES
			{
				ModularFlightIntegrator
				{
				}
				KSPWheelVesselDebug
				{
				}
				kOSVesselModule
				{
				}
				SolverFlightSys
				{
				}
				KSPWheelVesselControl
				{
				}
				ModuleStabilization
				{
				}
				CommNetVessel
				{
					controlState = None
					canComm = False
				}
				KSPWheelDustCamera
				{
				}
				RPMVesselComputer
				{
				}
			}
		}

 

So, yeah. Once you need the gender by some reason, such information must be stored somewhere. In a first though, I would store it on the KerbalEVA module's data. But then I realized: no one needs the Kerbal gender for anything but rendering the "vessel".

So… yeah. The PART section states that: this "vessel" uses a part called "kerbalEVAfemale". I don't know (yet) if the syntax <part_name> (<identifier>) is related to the vessel internal identifier, or if it's a kind of constructor for Crewed Vessels (a Kerbal doing EVA is a vessel crewed by the Kerbal! Metaconstructions, baby!), but in a way or another, that's the reason for the problem here: Take Command is instantiating "vessels", and in this specific case, it needs to correctly tell the KSP guts about the part to be used.

Edited June 29, 2018 by Lisias
oh, yeah. more typos.

[linuxgurugamer]

48 minutes ago, Lisias said:

This is somewhat sad, the EAS-316 is gorgeous.  Assuming that a proper fix is possible, would you accept it on Take Command?

Not sure what you mean.  It's an SXT part

[JoE Smash]

4 hours ago, linuxgurugamer said:

If you do post things like a full part's config, please put it into a spoiler.

Anyway, I suspect that if you hit F3 after launching with the Meadowlark, you will probably see that at least one kerbal was killed.  And the other is probably underground.

It's a problem with the part.  Short answer, just don't try to spawn two kerbals in it at once

So that particular part does that when you put two kerbals in it wether or not you use the take command mod?

[linuxgurugamer]

21 minutes ago, JoE Smash said:

So that particular part does that when you put two kerbals in it wether or not you use the take command mod?

Only when you put two kerbals in it at launch using Take Command.  I think the seat collidiers are just a bit too close together 

[Lisias]

1 hour ago, linuxgurugamer said:

Not sure what you mean.  It's an SXT part

If I understood correctly, the glitch happens because two Kerbals are being ejected at once (line 354 of the latest TakeCommand.cs):

while (this.part.protoModuleCrew.Count() > 0)
{
	kerbal = this.part.protoModuleCrew[0];
	//ProtoCrewMember kerbal = this.part.protoModuleCrew.First();
	print("[TakeCommand] ejecting " + kerbal.name + " from " + this.part.GetInstanceID());
	// blah blah blah
	if (FlightEVA.fetch.spawnEVA(kerbal, this.part, escapeHatch.transform))
	{
		myKerbal = "kerbalEVA (" + kerbal.name + ")";
		myFemaleKerbal = "kerbalEVAfemale (" + kerbal.name + ")";

		boardKerbal = true;
		escapeHatch.GetComponent<Collider>().enabled = false;
	}
	else
	{
		print("[TakeCommand] error ejecting " + kerbal.name);
		// and more blah
      	break;
	}
}

And since it's the same part, Take Command tries to use the very same hatch it created at line 61:

                if (escapeHatch == null)
                {
                    escapeHatch = new GameObject("EscapeHatch");
                    escapeHatch.tag = "Airlock";
                    escapeHatch.layer = 21;
                    escapeHatch.transform.parent = this.part.transform;
                    escapeHatch.transform.localEulerAngles = new Vector3(0, 0, 0);
                    escapeHatch.transform.localPosition = new Vector3(0, 0, 0);
					// blah blah blah
                }

With the already known consequences.

It's clear to me that the problem is not exactly the part, but TakeCommand that assumes that every part has only *one* command seat.

Creating multiple EscapeHatches appears to be overkill to me. I think that a better solution would be delaying the following Kerbal ejection until the previous one boards. But to do so, some code refactoring would be needed, as the better implementation for this would be a FSM.

[linuxgurugamer]

There are other parts which don't have this problem.   It's  interesting. I'll  look at the code

T as he command was written for a single seat, so it does make sense

[Lisias]

10 minutes ago, linuxgurugamer said:

There are other parts which don't have this problem.   It's  interesting. I'll  look at the code

Guide me to some of them so I can test them too. This is interesting, and highly educative - I learnt more today about KSP intrinsics than on the past month.

[linuxgurugamer]

7 minutes ago, Lisias said:

Guide me to some of them so I can test them too. This is interesting, and highly educative - I learnt more today about KSP intrinsics than on the past month.

Look at the various rover mods

[JoE Smash]

Well regardless of who looks at what it would be awesome if it was eventually resolved. No hurry though, I know you work on MANY projects Linuxgurugamer and probably have a RL to boot.....so as long as it's on the agenda at some point that's adequate.

I even tried to look up stuff, but I don't understand modding, unity, or programming.....so I am sure I would ask stupid questions and waste everyone's time.

I downloaded Blender, looked at it for two hours and decided I would much rather play KSP than try to mod KSP.....rofl....

[Lisias]

I had solved part of the problem. By changing line 78 of TakeCommand.cs , things stop to explode/die/poof. 

TakeCommand works fine with Meadowlark if you put only one Kerbal on the pod. By putting two (or more, as it appears), something goes wrong and nobody boards the pod. But with this change, nobody dies neither so at least I detected what was causing the deaths.

                    // Disable it for now until we need it
                    escapeHatch.GetComponent<Collider>().enabled = false;

 

My current guess is that by spawning the second Kerbal, the both of them are kicked out from the position and the boarding command fails. But with the collider disabled, nobody poofs.

Again, things work fine when only one Kerbal is assigned to the pod. Single seat pods appears to be not affected by this change.

 

POST-EDIT: This thing is smelling cheesy.  I took a peek on the Log for this file, this was always being set to true since the first commit this appeared, despite the comment stating that it should be disabled.

Edited June 30, 2018 by Lisias
typos. but you already knew it.

[JoE Smash]

I also noticed when I launch one kerbal in the Meadowlark there is no portrait or option to EVA....which makes it pretty much useless even with only one kerbal (at least for me).

Is it normally possible to eva from that pod without Take Command installed?

I suppose I could just uninstall it and find out myself, but it is getting tiresome messing with mods and then spending another 15 minutes to load KSP again....lol....

[Mark Kerbin]

right click on teh kerbal

"leave seat"

works in stock

[Lisias]

8 hours ago, JoE Smash said:

Is it normally possible to eva from that pod without Take Command installed?

Commands Seats are not pods. Technically, you are already on EVA.

[JoE Smash]

18 hours ago, Mark Kerbin said:

right click on teh kerbal

"leave seat"

works in stock

I see....thanks!

[linuxgurugamer]

New release, 1.4.12.2

• Updated .version file for all of 1.4
• Added OpenCockpit rear gunner seat

[FirroSeranel]

Hey @linuxgurugamer,

I just wanted to say thank you for all the many mods you create, revive, and maintain. You're an absolute mainstay of the modding community, and of KSP in general. The game wouldn't be the same without you!

[Jarin]

Feature confirmed stock for 1.5!

Thanks to @linuxgurugamer (and @seanmcdougall) for keeping our crazy and/or ultralight designs going all this time.

[Beetlecat]

On 8/31/2018 at 3:05 PM, Jarin said:

Feature confirmed stock for 1.5!

Thanks to @linuxgurugamer (and @seanmcdougall) for keeping our crazy and/or ultralight designs going all this time.

Thank the lord. This was always a weird situation.

[aat]

On 9/1/2018 at 7:05 AM, Jarin said:

Feature confirmed stock for 1.5!

Thanks to @linuxgurugamer (and @seanmcdougall) for keeping our crazy and/or ultralight designs going all this time.

you mean that launching kerbals in external command seats will be a feature of 1.5? any source/link to confirm this? can't find anywhere

[linuxgurugamer]

52 minutes ago, aat said:

you mean that launching kerbals in external command seats will be a feature of 1.5? any source/link to confirm this? can't find anywhere

It was mentioned in the last Kerbal Weekly

[Jarin]

5 hours ago, aat said:

you mean that launching kerbals in external command seats will be a feature of 1.5? any source/link to confirm this? can't find anywhere

 

[Beetlecat]

Standing by to see if mod-added control seat/pods will still require mod-assistance to function. I'll drop a line here later to note if MK1 Open Cockpit, etc. work w/o TCC.

1.5 fun tonight!