[0.20] Ioncross Crew Support Plugin ([0.22] dev build)

[yongedevil]

For a change development has come along well the last couple of days and I fully expect to release it tomorrow. The next version supports custom resources and makes use of ModuleManager by ialdabaoth to apply the module to the stock parts. I'll post more details with the update.

[Marder1986]

For a change development has come along well the last couple of days and I fully expect to release it tomorrow. The next version supports custom resources and makes use of ModuleManager by ialdabaoth to apply the module to the stock parts. I'll post more details with the update.

This a great NEWS )))

[Moon Goddess]

For a change development has come along well the last couple of days and I fully expect to release it tomorrow. The next version supports custom resources and makes use of ModuleManager by ialdabaoth to apply the module to the stock parts. I'll post more details with the update.

Does custom resources mean I can track water? And supplies? Does it mean I can use Oxidizer as breathing gas?

[cxg2827]

Looking forward to the release!

[Sandworm]

Does custom resources mean I can track water? And supplies? Does it mean I can use Oxidizer as breathing gas?

Doing that is easy enough. Adding an appropriate section to the cfgs for either the IonCross or Kethane mods can create converters for anything to anything. It's only a matter of cut-and=paste then renaming the inputs and outputs. But that's all up in the air until both mods get released.

[Kethevin]

Yay! :-)

Thanks for your hard work!

[yongedevil]

Mod has been updated to version 1.10. Highlights of changes in this version:

- custom textures by zzz

- converted to Kerbal 0.20 format

- configurable setup allowing for just about everything to be customized

- use of ModuleManage to add the module and resources to the stock parts without overwriting the files

The first post has been updated with information on how it works now. If anything isn't clear please let me know.

For the next updating I'm aiming to work on:

- Resource use calculation for inactive craft

- EVA resource use

Further down the line I plan on working on:

- Simple warning message when resources reach critical levels

- Intakes and general collector improvements

- Optional versions of the mod to support food and water

I was wondering about the mod:

I have noticed that the CO2 scrubber that needs to be activated via the menu constantly shuts off when flying/switching a different ship. My fear is that my Kerbals will die when I switch to a different ship/mission for too long of CO2 poisoning. I havent confirmed this but I believe this will also happen with the Oxygen recycler since its also activated via menu. Do the Kerbals consume/produce O2/CO2 even when not switched to that flight? (I am assuming yes but not 100% sure)

If yes is there a way around this problem??

The module only runs if the ship is currently active. I am working on adding consumption calculations for inactive ships but even when that is added kill checks will only ever be done on the active ship and they're only made once every hour after at least one hour (though this interval can be changed in the configuration file). Worse case you'll ever have is switching to a ship to find it out of oxygen and needing to switch off of it before the hour has elapsed.

First, thank you so much for writing this mod!

I have an idea regarding the intakes killing Kerbals: use two resource types to distinguish between 'ambient CO2' and 'compressed CO2'? Scrubbers could then convert ambient CO2 into compressed CO2. Intakes convert atmosphere into compressed CO2.

If there's an excess of CO2 and nowhere to store it, it could be vented (no need for a separate part here; it can be done automatically by an overpressure valve).

Having worked in the aerospace industry for nearly 10 years on cockpit display systems, I must insist that ALL command modules should consume electric charge. Modules with crew should consume more than unmanned modules because in addition to the communication systems and the built-in SAS, the flight instrumentation consumes power. Once a command modules is hacked to consume power, it becomes inoperable when you run out of power. As such I see no reason to kill the crew simply for lack of power.

If you consider that the crew could freeze without power, remember that in space there is no atmosphere into which heat can be lost due to convection (it is lost through a process called black body radiation). That said, decompression of oxygen requires heat for it to be breathable (ideal gas law); you could also model oxygen in two forms (ambient and compressed) but I don't feel it's necessary since the crew will die from CO2 build up while the scrubber is unpowered.

I like this idea for handling CO2 though I'm not sure it's worth adding an additional resource. There's also the fact that unless there's a use for uncompressed CO2 there's no reason to not use the scrubbers to convert it to compressed CO2. I think if a system is added it should be there to give the player a choice. Still automatic systems to vent excess CO2 make a lot of sense and I'll keep this in mind when I move on to focusing on the intake systems

Does custom resources mean I can track water? And supplies? Does it mean I can use Oxidizer as breathing gas?

Yes. Yes. Yes. You'll have to add water and supplies resources but once you do they should work fine with this mod. See the first post for details on how to edit the configuration file.

[zzz]

Glad to see it was helpfull.

But

You will have to contact zzz if you want permission to distribute the textures.

Just in case if someone need it(no idea who else) then no need to ask me, please. If you really need permission of someone you can ask Squad because base texture and most work is made by them.

Edited June 1, 2013 by zzz

[Kethevin]

This is the first time I've tried adding the code to modded modules. I can get it to show Oxygen and an area for CO2, but the Oxygen isn't being used and no CO2 is being generated. I cut and pasted the following from the readme file:

MODULE

{

name = IonModuleLifeSupport

}

RESOURCE

{

name = Oxygen

amount = 300

maxAmount = 300

//24 per day per Kerbal

}

RESOURCE

{

name = CarbonDioxide

amount = 0

maxAmount = 10

//24 per day per Kerbal

}

[yongedevil]

Opps. That would be because the readme is wrong. It should be:

MODULE
{
name = IonModuleCrewSupport
}

EDIT: Okay I fixed that error in the readme.

Edited June 1, 2013 by yongedevil

[Kethevin]

Opps. That would be because the readme is wrong. It should be:

MODULE
{
name = IonModuleCrewSupport
}

EDIT: Okay I fixed that error in the readme.

Works fine now, THANKS! :-)

[Marder1986]

Very Cool Thanks for your hard an phantasic work I love it. and Start Rebuild my Kerb Lab Spacestation

[Benno]

Thanks for the update Ioncross. Any particular reason why the parts are now called crewSupport rather than lifeSupport? I think that's why my ships de-oribted. Do you see any problem if I just rename relevant entries back to lifeSupport in the various part.cfg files?

[Sandworm]

Very good update. The Kethane mod has also been patched/updated to work with .20.2, and the owner has lifted the license restrictions temporarily. So I am free to post this trick to combine the IonCross and Kethane mods. Add the following text to either of the kethane converters if you want to create IonCross 02. Just rightclick on the converter. I'm working on a similar patch for the Ioncross converters, which would not be a violation of the Kethane license, but that will take a while and I want to actually play with these mods today.

MODULE

{

name = KethaneConverter

TargetResource = Oxygen

ConversionEfficiency = .99

KethaneConsumption = 4

PowerConsumption = 8

HeatProduction = 300

}

[yongedevil]

Thanks for the update Ioncross. Any particular reason why the parts are now called crewSupport rather than lifeSupport? I think that's why my ships de-oribted. Do you see any problem if I just rename relevant entries back to lifeSupport in the various part.cfg files?

Because at some point between the last update and now amid replacing large portions of code and moving the files around for the new file structure I decided to standardize the naming convention without really thinking about it.

I can't see any problems with renaming the parts themselves back to the old naming convention. The module names though can't be changed back since the code has changed, but an invalid module name should only cause the module to not work. Another possible option might be editing persistent.sfs. You'd be searching for the following names to replace. No guarantee that will work so make a backup.

lifeSupportIntake -> crewSupportIntake

lifeSupportRecycler -> crewSupportRecycler

lifeSupportRecycler.Large -> crewSupportRecycler.Large

lifeSupportTank -> crewSupportTank

lifeSupportTank.Large -> crewSupportTank.Large

lifeSupportTank.Radial -> crewSupportTank.Radial

Very good update. The Kethane mod has also been patched/updated to work with .20.2, and the owner has lifted the license restrictions temporarily. So I am free to post this trick to combine the IonCross and Kethane mods. Add the following text to either of the kethane converters if you want to create IonCross 02. Just rightclick on the converter. I'm working on a similar patch for the Ioncross converters, which would not be a violation of the Kethane license, but that will take a while and I want to actually play with these mods today.

Ah I'd glanced at that before and the licence seamed pretty restrictive. I didn't see that using the Kethane resource was allowed. Since it is, a simple converter can be made based on the recycler parts.

Just add this module to the recycler parts. This will result in each recycler having two IonModuleGenerator modules and you'll see two sets of buttons on the part interface. I have no idea if the rate values are appropriate, someone who uses Kethane might be able to suggest better values.

	MODULE
	{
		name = IonModuleGenerator
		generatorName = KethaneConverter
		generatorGUIName = Kethane Cracker
		requiresAllInputs = True

		INPUT_RESOURCE
		{
			name = ElectricCharge
			rate = 2.00000000
		}
		INPUT_RESOURCE
		{
			name = Kethane
			rate = 4.000000
		}
		OUTPUT_RESOURCE
		{
			name = Oxygen
			rate = 4.000000
		}	
	}

[Sandworm]

Thanks. That's exactly what I was looking for.

Before anyone tries the above and has problems, remember that under .20 we cannot just add text to the end of a cfg anymore. We have to be careful to add any text before that last }.

[ialdabaoth]

I would like to make a request, to get people off my back.

I'm managing the DeadlyReentry mod, and there are a few things that I think are out-of-scope for DRE, that properly belong in a LSS mod (even though they seem peripherally related to reentry).

1. Can you add a 'Cabin Temperature' readout to the GUI, that will use electricity to try to maintain at 25C regardless of part.temperature (consuming electricity as a fraction of (part.temperature - 25) * CrewCapacity), which makes crew kill rolls at anything below -10 or above +60 (with the percent chance of crew death based on the rate above 50 or below 0, with absolute certainty at -20 and +70?

2. Can you add the following code to FixedUpdate:

double avgGeeForce = 0;
double lastGeeForce = 0;
public void FixedUpdate()
{
  			float deltaTime = TimeWarp.fixedDeltaTime;
			double geeForce = vessel.geeForce_immediate;
			if (part == null || vessel == null || deltaTime > 0.5 || deltaTime <= 0)
				return; // don't check G-forces in warp
			else if (geeForce > 40 && geeForce > lastGForce) {
				// G forces over 40 are probably a Kraken twitch unless they last multiple frames
				avgGeeForce = avgGeeForce * (1 - deltaTime) + (float)(lastGForce * deltaTime);
			} else {
				//keep a running average of G force over 1s, to further prevent absurd spikes (mostly decouplers & parachutes)
				avgGeeForce = avgGeeForce * (1 - deltaTime) + (float)(vessel.geeForce_immediate * deltaTime);
			}
}

And then whenever avgGeeForce exceeds 15.0, start making kill rolls with a probability that peaks to maximum at say 45G's?

[yongedevil]

Isn't temperature directly related to re-entry through? I see the connection to crew survivability, but I don't really see how it's more appropriate to model the crew dieing through a life support mod rather than destroying the whole part in a re-entry mod. Not trying to say I don't want to do this but I'll need more understanding of what I'm trying to model and why if I am going to add it in.

G forces I can more clearly see as being applicable to this rather than re-entry. I'll add it to the todo list.

[Camacha]

I am not sure electricity is needed for a survivable reentry in real life.

[Scotius]

Well, maintaining optimal temperature is an important part of life support system. And it's not restricted only to re-entry conditions. If you are aiming at realistic outcome, then some sort of temperature balancing is needed. Heaters + radiators? Or maybe just increased power drain when craft is in full shade/full sunlight.

[ialdabaoth]

Isn't temperature directly related to re-entry through? I see the connection to crew survivability, but I don't really see how it's more appropriate to model the crew dieing through a life support mod rather than destroying the whole part in a re-entry mod. Not trying to say I don't want to do this but I'll need more understanding of what I'm trying to model and why if I am going to add it in.

G forces I can more clearly see as being applicable to this rather than re-entry. I'll add it to the todo list.

Reentry handles external temperature (aka part temperature). I'm talking about cabin temperature in command pods - the temperature of the air that the Kerbals are breathing. You need an electrical A/C system to keep that air cool or warm, and if you don't have power, cabin temperature slowly heats or cools until it matches part.temperature - at which point, if the part isn't too hot or too cold, your kerbals are fine. Otherwise, they start freezing or roasting.

Am I making sense?

Example 1: during reentry, my command pod heats to 700 degrees. That's totally survivable - the pod is made of reinforced aluminum and composite ceramics, so it can survive temperatures of up to 1700 degrees. As long as the life support system is operational, 700 degrees is no problem for the AC - it just pulls .0625 units of power per second to keep the cabin at 25 degrees.

If power goes off, then the cabin temperature slowly raises from 25 to 700 - and the Kerbals get parboiled.

Example 2: I'm orbiting the sun, where the ambient temperature is somewhere around 800 degrees. The command pod heats up to 800 degrees, which is totally fine - again, reinforced aluminum, composite ceramics, yadda yadda. But if it runs out of electricity, the cabin is going to slowly roast our little Kerbals.

Edited June 2, 2013 by ialdabaoth

[Benno]

Thanks for the update Ioncross. Any particular reason why the parts are now called crewSupport rather than lifeSupport? I think that's why my ships de-oribted. Do you see any problem if I just rename relevant entries back to lifeSupport in the various part.cfg files?

Because at some point between the last update and now amid replacing large portions of code and moving the files around for the new file structure I decided to standardize the naming convention without really thinking about it.

I can't see any problems with renaming the parts themselves back to the old naming convention. The module names though can't be changed back since the code has changed, but an invalid module name should only cause the module to not work. Another possible option might be editing persistent.sfs. You'd be searching for the following names to replace. No guarantee that will work so make a backup.

lifeSupportIntake -> crewSupportIntake

lifeSupportRecycler -> crewSupportRecycler

lifeSupportRecycler.Large -> crewSupportRecycler.Large

lifeSupportTank -> crewSupportTank

lifeSupportTank.Large -> crewSupportTank.Large

lifeSupportTank.Radial -> crewSupportTank.Radial.

Wow. Thanks for the quick and detailed response yongedevil! It did load up ok after renaming the parts, but I wasn't convinced I wouldn't run in to issues at some point. I just tried your suggesting of doing a find and replace on persisten.sfs (just replaced 'life' with 'crew'), but for all my ships as well, and so far so good. Thanks for the support.

Cheers,

Benno.

Edited June 2, 2013 by Benno
forgot to quote

[mdosogne]

Example 2: I'm orbiting the sun, where the ambient temperature is somewhere around 800 degrees.

I'm not an expert, but I think you're toast - turbocharged A/C or not. You can easily survive reentry where the tiles reach over 1000 degrees because they are thermally isolated from the cabin, and that temperature is not sustained. In orbit close enough to the sun, I don't think you'd be able to dissipate that much heat through A/C (in space there's no atmosphere; you can only dissipate heat through a process called 'black body radiation', which takes a large surface area). You'd be better off cooling the air in the cabin by a) decompressing oxygen and/or venting a heated gas/liquid (both require a consumable resource).

Perhaps yongedevil would consider an enhancing the module to kill the crew when a configurable resource exceeds or drops below a given threshold + a specified time elapses? That could be used to model temperature, water, cabin C02, etc.

[Camacha]

Example 1: during reentry, my command pod heats to 700 degrees. That's totally survivable - the pod is made of reinforced aluminum and composite ceramics, so it can survive temperatures of up to 1700 degrees. As long as the life support system is operational, 700 degrees is no problem for the AC - it just pulls .0625 units of power per second to keep the cabin at 25 degrees.

Is any AC capable of maintaining room temperature when the outside temperature is 700 degrees? To be honest I think those are short lived peaks, the internal systems will not be built to cope with those kinds of differences.

I applaud any mod intending to add realism by adding complexity, but that does have to have a relation with reality.

Edited June 2, 2013 by Camacha

[Sandworm]

The AC? Even if a pod was heated evenly to 700*, nothing describable as "AC" would cool it fast enough to be relevant. At those temps, in atmosphere, the most effective cooling will be purely passive, ie into the surrounding air via convection/radiation. The SR-71 had systems for cooling metal in reentry-like conditions because it lived in those conditions for hours. (in short, its fuel absorbed the heat and was burnt, sending the heat out the tailpipe). Space capsules need only survive a couple minutes. The air inside doesn't have time to heat before the reentry is over and entire capsule is cooling down.

As for getting close to the sun, continuous 700* is a problem. But the answer is gold foil. 0.0001mm of gold or silver will passively hold off even the most intense sunlight. The side of the craft facing away from the sun also radiates heat out into space. Between the protection on one side and passive cooling on the other, active systems are not essential. Just look at the gold used on the james webb telescope to see what I mean.

Edited June 2, 2013 by Sandworm