[0.23.5] Realism Overhaul: ROv5.2 + Modlist for RSS 6/30/14

[OxalysResourceConsortium]

Don't know if this has been suggested before, but I did a quick search and couldn't find anything, so I thought I would nominate pizzaoverhead's Atmospheric Sound Enhancement mod to the RO modlist.

Adds the effects of the density, temperature and relative speed of the atmosphere to craft sounds. When breaking the sound barrier, muffled sounds (or optionally no sounds) will be heard from the craft when the camera is outside of the shock cone. When passing through the cone, you can hear the shockwave. When leaving the atmosphere, the sound gradually fades to muffled (or optionally nothing) in vacuum. Internally, sounds can always be heard but are muffled. Non-craft sounds such as music are unaffected.

The stock game’s condensation effects are now visible when travelling at transonic velocities. The plasma re-entry effects are visible when travelling at hypersonic velocities, regardless of altitude.

Download Here!

[NathanKell]

Benoît: this happens when textures are too large for your OS / video card. Open EarthColor.png and scale it down to 4096x2048. I can do it for you if needed.

OxalysResourceConsortium: ah, yeah, I keep meaning to try that!

[Benoit Hage]

@Nathan: Many thanks! It was that indeed.

[Fox62]

Is anyone else having problems with Procedural Parts? I can't edit the Procedural Parts to change them from a 1.25m cylinder, nor can I change anything about the Procedural SRBs.

[OtherBarry]

Is anyone else having problems with Procedural Parts? I can't edit the Procedural Parts to change them from a 1.25m cylinder, nor can I change anything about the Procedural SRBs.

Upgrade to the latest version. All of those problems should be fixed.

[ThorBeorn]

NathanKell: Do you know if anyone is working on updating the RO .cfg for the Fustek Space Station Parts Expansion (to resolve incompatibility with the new dev release of Fustek)?

I haven't figured out why it does not work right, cause I'm a noob. If I do, I figure I might as well fix it and share it in this thread if redde, the original author of the .cfg doesn't mind ofcourse.

[RaccoonTOF]

Ya I'm aware that the "fuel tanks" are not fully utilizing the space, due to the internal tanks and such. But if you look at the numbers I put up a little closer, you'll see that the new stock tanks are actually giving even MORE fuel tank volume than the entire volume of the cylinder that they are contained in. Even if they were purely fuel bladders, they shouldn't have that much volume

I am working "backwards" from the SLS specs, but I only have stats for the entire stage weights and propellent weights, but there is still a fair amount of "empty" volume in even the Block 0 Core (because of how they are reusing bits from the shuttle ET, the "intertank" section is a lot more wasted volume than it would need to be for a stage built from scratch.) So ya, I can give accurate numbers to duplicate the SLS itself, I just wasn't sure how to then give an accurate volume for people to use for RealFuels if they wanted to use the monolithic tank visually but for some other tank arrangement (which would be "empty" non-tank volume for the base version). The "stretched" Core Stage has a lower proportion of "wasted" space as well, because the entire length of the "stretch" is usable tank space.

As for the N-1, the NK-15 was used for the early ones, but the NK-33 (which was based heavily on the NK-15, it was almost the same engine) was used for the later tests (along with the NK-43, which is just an NK-33 adapted for better vacuum performance). So yes, while the N-1F never actually "flew" prior to cancellation, the NK-33 was definitely built for the N-1 project and assembled into a launch vehicle prior to cancellation.

ThorBeorn: The issue with the new Fustek parts is that he has split up the various elements (core, hatches, ports, etc) into different model assets, to save on space/memory and allow textures to be easily reused between the new parts. I looked at them when I first fired up RO, as I love using them in my stock Kerbin game, but it'd be a lot of work going through and rearranging all the different nodes to be in the right places. And since those locations have been changing with every few dev release versions anyway, I figured I'd just wait till the dev version gets finalized and released as an official next version prior to updating the cfg for RO.

[brooklyn666]

Hey Nathan, Medieval and I have been talking, and it seems like my RT2 cfg would be best to just include with RO at this point, rather than have it in the 2nd post as an extra. Your thoughts?

My only concern is making sure everyone has the right settings, and changing the ground station locations to match with real Earth RSS.

I'm going to be hands-off for a little while, probably until .24 hits, and then I'll see if any changes need to be made vis-a-vis Cilph's major update, and any updates to RSS/RO at that time. To that end, you can make any changes to the cfg if you like.

What do you think?

[NathanKell]

ThorBeorn: not aware of anyone. Please do give it a go!

Here's how you rescale.

Three things affect scale.

First, does the part use MODEL nodes? Skip to part B.

A (MODEL node not used; instead "mesh = blah" used)

1. "scale = foo" determines how the first three numbers for each attach node line (the X, Y, Z coords of the node) are scaled. It does *not* affect anything else. Default = 1.0 if not present

2. "rescaleFactor = bar" scales both the model (and its transforms) *and* the attach nodes. Default = 1.25 if not present.

B (MODEL node(s) used)

1. Inside the MODEL node, "scale = blahX, blahY, blahZ" determines the scaling of the model and its transforms. Default is 1.0, 1.0, 1.0. It does not affect node positions.

2. Outside the MODEL node, "scale = foo" works as above.

3. Outside the MODEL node, rescaleFactor works as above.

HOWEVER, there is a bug in scaling. For parts with MODEL nodes, rescaleFactor is applied twice to the mu, *unless* (a) the part is the root part of the vessel and ( you've reverted to launch (or perhaps switched in flight? Don't recall). All other times, it is applied twice. What this means is that if you have scale = 1.0, 1.0, 1.0 in the MODEL node (or no scale at all), and rescaleFactor = 1.25, then your mesh will actually be 1.5625 as big, but your nodes will be scaled outwards 1.25.

For this reason, when scaling parts using MODEL nodes, it is suggested to leave scale (outside the MODEL node) and rescaleFactor both at 1.0, and instead both change the scale = x, y, z inside the MODEL node and manually scale the positions of the attach nodes.

That said, that's for single-MODEL configs. You will have to, as RaccoonTOF says, multiply all positions in the MODEL nodes by the rescale you're doing, as well as the attach nodes.

RaccoonTOF: Oh, I agree they're wacked, and I look forward to your remake of them. I was just responding to the question part of your post, rather than the statement.

I see the problem now better; that's a fair point. Perhaps what you might do is set the tank volume for if it were fully utilized, but then add a default config with as much LH2 and LOX as the real SLS uses (using TANK override nodes in the module). Not sure what you should do about base mass then; maybe leave the tank part masses on automatic and stick all the rest of the mass in the interstage part.

Re: NK-33s, I was just being pedantic. You mentioned N-1, and I took you to mean N-1 the rocket, not N-1 the project. And with Denny's N-1 coming along, we're about to get -15s and -15Vs, too!

brooklyn666: I *highly* support integrating it into RO; that was pretty much my hope from the start and why I asked back then.

Because RT2 uses a dump-to-file version of confignode, rather than a GameDatabase-readable confignode for its settings, we can't patch it with ModuleManager, but I will have MedievalNerd include an RT2 settings file with RPL that will establish ground stations and make sure range model and multipliers are correct.

Thanks, and enjoy your break!

[brooklyn666]

Sounds good. I'll be around checking the forums and whatnot, I just need a little break from the clusterf**k of having a major game update, one more on the way, and a busy real life!

[ThorBeorn]

RaccoonTOF, NathanKell: Thanks for the help. I think I get it. I will start to edit the cfgs for sure. But if things in Fustek keep changing with every new dev release as Raccoon says (I just discovered the mod basically), I don't really see the point in making a complete RO cfg at the moment. Will experiment a little now and finish it when there's a new official Fustek release. That is if all goes well.

Edit: I PM:ed sumghai about upcoming changes. I'll see what he says, maybe I can start fixing the cfg soon.

Edit2: I guess I don't get it. I can change the numbers in "scale = x.x, .y.y, z.z" in the original FusTek part.cfg and it works fine. But I run into trouble when I'm trying to make an overriding .cfg.

Mass changes but size remains, what am I doing wrong?

This is an example:

@PART[FusTekKarmonyBulkhead]:Final

{

@mass = 0.096

@MODEL

{

scale = 1.6, 1.6, 1.6

}

}

When inserting rescaleFactor = 1.6 outside the MODEL node it works fine and the original 2,5 m part becomes 4 m - and that is without it being the root part (the first part on a vessel?) I think.

Edited April 24, 2014 by ThorBeorn
I'm tooo stoopid

[RaccoonTOF]

@Nathan re: Core Stage - What I have done right now is to set the total volume to the total available volume for the tank part, with the prefilled default tank values, pretty much as you had suggested there. The main issue is with the masses - there is no way to add the mass to the interstage part, because presumably people will be using procedural fairings or similar for that part (the interstage depends on the choice of second stage/payload). I could theoretically take that approach if I were to make new parts for all of the possible options, but that would be well beyond just a MM config then. And seeing as how there is already a very nice looking "true" SLS mod in the works, I think that'd be pretty redundant - my goal right now is just to get the stock parts to be accurate for what they were intended to be in the first place, adapted to RSS/RO and a few other tweaks to existing engines when there are multiple models already available for that engine. I have left the "tank mass" portion out entirely though, letting it be calculated by RealFuels created tanks, or the default tanks included in the config, while setting the part mass (with basemass=-1) to be the "dry" mass of the entire stage minus the engine block (since it IS a separate part already). End result is basically - you'll have flexibility in your tankage and the mass for it will be accurate, but if you choose to use the core stage as JUST a tank for something else, you'll have a different mass value for doing so than if you just made a procedural of the same size.

@ThorBeorn: If you are not doing rescaling in individual dimensions separately, it is much easier to rescale purely using rescaleFactor = X and setting your scale within the MODEL{} section to be (original scale/X). (In most cases "original scale" will be 1, and I believe that is the case with all of sumghai's parts, but double check them to be sure). That way all of your nodes SHOULD get adjusted as well by the same proportions, without running into the bug that applies rescaleFactor twice.

If you are having to rescale any parts in one dimension by a different value than in the other dimensions, it gets quite a bit trickier. I'm not sure if that applies to any of the FusTek parts with the new models, I don't think it does, but if so lemme know and I can try to do a more in-depth explanation of the math needed then (I had to do exactly that to rescale the core stage tank, since it required a significantly larger rescale in the vertical than in the diameter).

EDIT: Also, you are adding just "scale=1.6, 1.6, 1.6" to the MODEL node - you need that to be a "%scale=1.6, 1.6, 1.6" or else it might create a duplicate scale value within the node (on any parts that already have a scale value), which could do very strange and unpredictable things

And finally, another teaser. Block 1A Crew version with one of the ICPS variant possibilities and the solid boosters. I've also added a bottom node to the main engine section, spaced to allow adding the existing single RS-25D engine to it, for if anyone wants to run the 5-engine variant that was in the early planning ideas.

Edited April 24, 2014 by RaccoonTOF

[ThorBeorn]

@ThorBeorn: If you are not doing rescaling in individual dimensions separately, it is much easier to rescale purely using rescaleFactor = X and setting your scale within the MODEL{} section to be (original scale/X). (In most cases "original scale" will be 1, and I believe that is the case with all of sumghai's parts, but double check them to be sure). That way all of your nodes SHOULD get adjusted as well by the same proportions, without running into the bug that applies rescaleFactor twice.

If you are having to rescale any parts in one dimension by a different value than in the other dimensions, it gets quite a bit trickier. I'm not sure if that applies to any of the FusTek parts with the new models, I don't think it does, but if so lemme know and I can try to do a more in-depth explanation of the math needed then (I had to do exactly that to rescale the core stage tank, since it required a significantly larger rescale in the vertical than in the diameter).

EDIT: Also, you are adding just "scale=1.6, 1.6, 1.6" to the MODEL node - you need that to be a "%scale=1.6, 1.6, 1.6" or else it might create a duplicate scale value within the node (on any parts that already have a scale value), which could do very strange and unpredictable things

Thanks. No I don't think I need to change the proportions of any of the parts. I'm just trying to rescale everything according to how NathanKell explained it a few posts above - which I predictably got wrong

So please correct me if I'm wrong. Should using "rescaleFactor = 1.6" and scale = 0.625 (omitting the scale = X.X, Y.Y, Z.Z variant) work if the aim is 2m and 4m parts?

Also why is countering the squared "rescaleFactor =..." bug with an "inverted scale =..." considered better than just using the squareroot of the desired rescale in the "rescaleFactor=..."?

I see two reasons only. One, the attachnodes don't change correctly? Two squareroots often have lots of decimals...

Hope I express myself clearly, cause there's always that language barrier. Thanks again!

Btw, nice launcher Raccoon!

[NathanKell]

Re: scaling. RaccoonTOF, as I explained above, you *really* should not be using rescaleFactor in combination with MODEL nodes for any parts that might be the root part (and probably even if not). rescaleFactor is *only* safe for use with non-MODEL-node parts.

ThorBeorn: as RaccoonTOF says, you need to use % for that scale call. Also, since most parts contain *multiple* MODEL nodes, you need to do your change to each MODEL node. (And you need MM 2.0+) Example: FusTekKarmonyHabModule

(I also changed some stats to wild guesstimates.)

@PART[FusTekKarmonyHabModule]:Final
{
	@MODEL,0
	{
		%scale = 1.76, 1.76, 1.76 // 4.4 meters, the width of the Harmony module
	}
	@MODEL,1
	{
		%scale = 1.76, 1.76, 1.76 // 4.4 meters, the width of the Harmony module
	}
	@MODEL,2
	{
		%position = 0.0, 3.245, 0.0 // was 1.84375
		%scale = 1.76, 1.76, 1.76 // 4.4 meters, the width of the Harmony module
	}
	@MODEL,3
	{
		%position = 0.0, -3.245, 0.0 // was -1.84375
		%scale = 1.76, 1.76, 1.76 // 4.4 meters, the width of the Harmony module
	}
	@node_stack_bottom = 0.0, -3.245, 0.0, 0.0, -1.0, 0.0, 4
	@node_stack_top = 0.0, 3.245, 0.0, 0.0, 1.0, 0.0, 4

	@mass = 14.0 // ~14 tons (Harmony is 14.3t, but we assume some extras)
	@maxTemp = 1300 // not super rugged
	@breakingForce = 1280
	@breakingTorque = 1280

	@RESOURCE[ElectricCharge]
	{
		@amount = 18000 // 5kWh battery
		@maxAmount = 18000
	}
	!MODULE[ModuleReactionWheel] {}
}

[RaccoonTOF]

Er, yes, I keep forgetting that people DO actually use those parts as root parts sometimes The only one of the Fustek ones that I've ever used as a root part (aside from quick-viewing stats on them) was the new resupply module, since it is effectively an ATV in FusTek style That said, I suppose I should go re-adjust the core stage scaling just in case someone wants to use it for root as well, lol... [EDIT: the reason why I usually use rescaleFactor on multiple model parts unless it is intended to be a root, is because it handles the position and node placement much easier. But that's been for my personal use almost exclusively so far, so I feel safe doing so because I know what parts I don't/won't ever use as a root part myself. Gotta remember there is always someone out there who will make the most insensibly assembled designs, and then complain when it breaks...]

Edited April 24, 2014 by RaccoonTOF

[Guest]

Hi

if your doing fustek RO fixes, i would humbly request TAC life support versions (if your feeling super productive a version for people still using ECLSS aswell, but i fell TAC has more users and is more complete)

Fustek is great but i always felt it lacked TAC and KAS support, which would make it more useful (otherwise squad structural fuselages & crew cabin habitats serve as station components exactly the same, but with different "skins")

[RaccoonTOF]

I had a set of FusTek configs for TAC, but they are outdated now with the updates to both. And I'm really hoping that TAC is going to change to using liters for their units in the next version as has been discussed (rather than "kerbal-days") so I've not updated them yet. Could probably do so if the TAC update gets pushed off too much longer though.

[Guest]

I had a set of FusTek configs for TAC, but they are outdated now with the updates to both. And I'm really hoping that TAC is going to change to using liters for their units in the next version as has been discussed (rather than "kerbal-days") so I've not updated them yet. Could probably do so if the TAC update gets pushed off too much longer though.

the unit system of 24hrs of supplies/wastes = "1" does have the charm of being simple, as long as the mass of "1" water/food/oxygen unit equals the average daily need of a human being in mass... i dont want to be the person that works out the mass of 1 unit of "waste"/"waste water" the average human produces a day is

that said liters and kilo's as the user seen units could cause more confusion... are they eating pork chops, 1 pack of MRE's, a toothpaste like tube of astronaut nutritional supplements? so i do favor the 1 unit = 1 day production/use, as long as the masses are correct.

I have toyed with FusTek TAC additions (like supplies & scrubbers added to utility module) and KAS storage (added to, minor, logistics modules, & major, warehouse modules) thats really very simple... its the RO resize/remass of the current dev build of fustek that i dont get. If the resize is done i could add TAC/KAS support (heck and an RT2 comms unit to whatever part the "command module" is) and test it in under an hour i believe

A real question is how do we make TAC activly keep up with scrubber/solar while time warping or when not focused on vessel/station in question (so kerbals dont die needlessly when they indeed had the ability to stay alive, just the math has on "hold")... I know ECLSS is an option, but honestly i have never cared for it... TAC just seems so much more complete with larger user base (and 2 of any type of mod is just a poor idea, a single life support mod used across all other part mods, would help not only avoid confusion but allow us to have "this is THE life support mod, work with it" to speed/simplify RO completion)

So energy in kw/kj (with battery banks equaling 24hr supply under full drain), resources/wastes (with correct masses) in a 1 unit = 24 hour production/use would make it "simple and easy to understand at a glance"

Edited April 25, 2014 by Guest

[RaccoonTOF]

One unit per day definitely makes things nicer on the user end - the problem is that while we know the mass for those units, we have no idea what volume they take up. This makes creating "realistic" containers for them nearly impossible - especially in the case of food. By having them be density per day of use, rather than density per real unit of volume, every individual container-maker has been being forced to guestimate "reasonable" values (based on their own definitions of "reasonable") rather than having a universal system so that 1 unit of resource takes up x space and has y mass no matter what container type it is stored in. From the UI perspective of the user, it can still remain DISPLAYED to them in the TAC interface in "days remaining" just by having it do a conversion on "Units per time per kerbal", which itself is already a tracked and tweakable value.

[Guest]

humm. i see your point... well this is the realism thread... lets just set a "standard"! Of course this will be abit arbitrary but i think the standard "MRE" (meals ready to eat) that the Americans use in their military would be a decent soloution, it has a few flavors, is self contained and has its weights/volumes public listed here is an excerpt from wiki"

"Each meal provides about 1,200 Calories (1,200 kcal or 5,000 kJ). They are intended to be eaten for a maximum of 21 days (the assumption is that logistics units can provide superior rations by then), and have a shelf life of three years (depending on storage conditions).

Packaging requirements are strict. MREs must be able to withstand parachute drops from 380 metres (1,250 ft), and non-parachute drops of 30 metres (98 ft). The packaging is required to maintain a minimum shelf life of three and a half years at 27 °C (81 °F), nine months at 38 °C (100 °F), and short durations from −51 °C (−60 °F) to 49 °C (120 °F) must be sustainable. New forms of packaging are being considered to better meet these requirements including the use of zein to replace the foil, which can be easily punctured, conducts heat, and is reflective (which may give away a service member's position).

Each MRE weighs 510 to 740 grams (18 to 26 oz), depending on the menu. Since MREs contain water, they weigh more than freeze-dried meals providing equivalent calories."

This seems to state that MRE's:

** require no/minimal added water (stored water can be used for washing/drinking only)

** weighs 625g on average

** contain 1200 calories (making about 2 per day the average consumption requirement for males 19yrs to 50yrs of age according to "Health Canada" HERE at, in fact exceeding, the activity levels expected, yes i'm Canadian)

so thats 1.25kg of rations per day (this could be rounded to 1kg using MRE's that contain the most food mass & least water mass) giving calories meeting and/or exceeding the requirement of crew male or female ages 19yrs to 50yrs

Water

** water is 2 liters per day for the average human and water weighs 1kg per liter in liquid form, so average person needs/drinks 2kg of water per day (this infact exceeds "required amounts" by 0.2 liters, that will be attributed to "other uses" of washing ect ect)

This leaves me seriously in doubt of O2/CO2 numbers.... anyone here a SCUBA expert or perhaps submariner that could provide realistic numbers off the top of their head? If not i guess i could google it fairly quickly

EDIT i googled it and added info info below

**The average adult at rest inhales and exhales something like 7 or 8 liters (about one-fourth of a cubic foot) of air per minute. That totals something like 11,000 liters of air (the full "mix") in a day.

Totally dry air at sea level has a density of: 1.2 kg/m3 or 1.2g/L >. 1.2g x 11,000 = 13,200g or 13.2Kg per person per day

**According to a study by the United States Department of Agriculture, an average person's respiration generates approximately 450 liters (roughly 900 grams) or 0.9kg of carbon dioxide per person per day.

This said we can average the masses to>> 1 humans food per day is 1kg & 1 humans water per day is 2kg, Air used is 13.2Kg per person per day, CO2 produced is 0.9kg per person per day, waste produced is 0.12kg per person per day, waste water produced is 0.5kg per person per day

I am open to anyones opinion, so please add your 2 cents. If this is accepted by the "masses" (slight pun lol) we can more forward with this as a "new standardized mass for food & water per person per day" to be used with TAC, with TAC becoming the universally accepted standard of RO life support @ these masses

an excerpt from jrandoms TAC RO file states: (these are fairly off by my math...corrections below code box)

// Resources (in tons-per-day)
// ---------------------------------------------------------------------------- Food
// 366 kg / m^3
@RESOURCE_DEFINITION[Food]:Final
{
    @density = 0.000713 // 0.62 kg per day per kerbal + 15% packaging
}

// ---------------------------------------------------------------------------- Water
// 1000 kg / m^3
@RESOURCE_DEFINITION[Water]:Final
{
    @density = 0.004 // 4 kg per day per kerbal
}

// ---------------------------------------------------------------------------- Oxygen
// 300 kg / m^3
@RESOURCE_DEFINITION[Oxygen]:Final
{
    @density = 0.00084 // 0.84 kg per day per kerbal

// ---------------------------------------------------------------------------- CarbonDioxide
@RESOURCE_DEFINITION[CarbonDioxide]:Final
{
    @density = 0.00112 // 1.12 kg per day per kerbal
}

// ---------------------------------------------------------------------------- Waste
@RESOURCE_DEFINITION[Waste]:Final
{
    @density = 0.0011232 // 1.1232 kg per day per kerbal
}

// ---------------------------------------------------------------------------- WasteWater
@RESOURCE_DEFINITION[WasteWater]:Final
{
    @density = 0.003888 // 3.888 kg per day per kerbal
}

Corrections to numbers in code box by my research

* water use should be cut in 1/2 (who could drink 4kg of water a day EVERY day, yikes) to 0.002 // 2kg per day

* food should be increased to 0.001 // 1kg per day (we will assume this includes minimal packaging that we shall assume is accounted for in "waste")

***using my nation as a base line (Canada) >> On average, each human adult produces approximately 0.5 L of urine per day (0.5 kg) and 115 g (0.115 kg) of feces per day

* waste should be reduced to 0.00012 // 0.12kg per person per day (the additional 5g's is to account for any packaging wastes)

* waste water should be reduced to 0.0005 // 0.5kg per person per day

* oxygen (air really, the full gas mix not just O2) should be 0.0132 // 13.2Kg per person per day <<edited, i googled it

* CO2 average person's respiration generates approximately 450 liters (roughly 900 grams) of carbon dioxide per day should become 0.0009 // 0.9kg per person per day

Lets have an quick talk/debate about this, make the numbers solid, and finalize it "cut in stone" for all time as the standardized volumes/masses for life support resources/wastes

I believe the standard stored resources of 1 day power supply under full drain plus "1 days supply of food, air, water supply with the ability to store 1 day's worth of waste/waste water/CO2 @ full crew capability of pod/cockpit/cabin" without additional storage space/resources added to craft is a nice safe, even number

If someone can supply A STANDARDIZED (like the MRE's are) "freeze dried" rations weight/calories numbers, this could be used to further reduce mass/volume numbers of food rations and increase its "shelf life" to beyond human life expectancy

Once this is worked out we can focus on water/air "scrubbers" & fuel cell/electrolyser numbers and TAC will be 100% RO fixed/completed (note we will need a method to "dump" waste in space as it cant be reprocessed unless someone can make a "waste + water + power = food" greenhouse part that is realistic, but i doubt any craft thats not a space station or planetary base could support this due to its mass/volume and time requirements)

That was "almost" easy!

Although some parts (scrubbers, fuel cells, electrolysers and storage containers) may need resizing/remassing to fit in RSS/RO correctly

@Nathan: could you look that over and give your opinion on this? being "lord and master" of RO your approval is very important to this topic

Edited April 25, 2014 by Guest

[ThorBeorn]

ThorBeorn: as RaccoonTOF says, you need to use % for that scale call. Also, since most parts contain *multiple* MODEL nodes, you need to do your change to each MODEL node. (And you need MM 2.0+) Example: FusTekKarmonyHabModule

(I also changed some stats to wild guesstimates.)

@PART[FusTekKarmonyHabModule]:Final
{
	@MODEL,0
	{
		%scale = 1.76, 1.76, 1.76 // 4.4 meters, the width of the Harmony module
	}
	@MODEL,1
	{
		%scale = 1.76, 1.76, 1.76 // 4.4 meters, the width of the Harmony module
	}
	@MODEL,2
	{
		%position = 0.0, 3.245, 0.0 // was 1.84375
		%scale = 1.76, 1.76, 1.76 // 4.4 meters, the width of the Harmony module
	}
	@MODEL,3
	{
		%position = 0.0, -3.245, 0.0 // was -1.84375
		%scale = 1.76, 1.76, 1.76 // 4.4 meters, the width of the Harmony module
	}
	@node_stack_bottom = 0.0, -3.245, 0.0, 0.0, -1.0, 0.0, 4
	@node_stack_top = 0.0, 3.245, 0.0, 0.0, 1.0, 0.0, 4

	@mass = 14.0 // ~14 tons (Harmony is 14.3t, but we assume some extras)
	@maxTemp = 1300 // not super rugged
	@breakingForce = 1280
	@breakingTorque = 1280

	@RESOURCE[ElectricCharge]
	{
		@amount = 18000 // 5kWh battery
		@maxAmount = 18000
	}
	!MODULE[ModuleReactionWheel] {}
}

Thanks for your help. I'm slowly but surely learning this new way of cfg editing. I've finished a few easy parts containing "mesh" or a single "MODEL" only. I ran into trouble with the multi MODEL parts though.

Your example in the quote for instance changes everything except the size of the part. I will look more in the MM thread for answers, but if anyone knows why the size won't change please let me know.

Ps. Yes I have the latest MM 2.03.

Edited April 25, 2014 by ThorBeorn

[NathanKell]

I really, really would prefer if the 1 unit = 1 liter at STP standard is continued; RaccoonTOF is right that with the new TACLS GUI the program, rather than you, can convert to human-days of consumption. Otherwise some *very* strange tricks will have to be done to make life support in a ServiceModule RF tank work (utilization could be used, but that's really to account for things kept under high pressure, or things where extra insulation is needed).

[Guest]

I really, really would prefer if the 1 unit = 1 liter at STP standard is continued; RaccoonTOF is right that with the new TACLS GUI the program, rather than you, can convert to human-days of consumption. Otherwise some *very* strange tricks will have to be done to make life support in a ServiceModule RF tank work (utilization could be used, but that's really to account for things kept under high pressure, or things where extra insulation is needed).

Ok, thats completely reasonable... Please help me to understand how to convert 1kg of food and 1kg of waste into liters (unless we make assumption they use same space as water with 1kg = 1 liter)?

Infact that works out well... 1kg = 1 liter is an easy 1:1 conversion making the numbers the sae only with units swapped (kg into liters, with 1 liter equaling to 1kg mass)

question: STP standard is " IUPAC established standard temperature and pressure (informally abbreviated as STP)" @ 0C and 100 kPa??

Edited April 25, 2014 by Guest

[RaccoonTOF]

Yes, I used the "utilization" method myself with my old configs, taking into account the volume (packaged) of a variety of foods and food-budgets for previous RL space missions. Of course, those numbers didn't match exactly with any of the other "container" authors either . There is more talk about the "packaged density" that food should be over in the TAC thread as well. Also, bear in mind that the caloric expenditure of astronauts during a mission is historically much higher than any of the "recommended daily values" given for general civilian use dirtside, and with very different nutrition requirements. Same issues when looking at MRE specs - they are 1200 calories each (on average) but still intended to have 3 consumed per day, minimum, for a soldier in the field in any situation where they would be eating MREs in the first place, because their expected caloric intake needs are much higher than the "average" civilian at home reading ingredient labels. Coming up with these "standards" here for realism isn't a bad idea - but they should be based on a TAC-supplied baseline value for mass AND volume, and it currently does almost nothing to provide the latter.

That said, if the TAC update ends up being pushed off too far, or someone really wants something to use "right now" - you can always take the stock containers supplied in the mod (use those for a baseline reference on stats, not any of the other containers supplied by different authors), figure out how much usable space a ServiceModule tank of the same size would have, and divide that volume by the number of TAC units the equivalent container provides - that would give you a good working volume per TAC unit, which can then be converted to liters via the utilization option in the tank definition. It's clumsy, but it has worked for me in the past (I created a completely new tank type rather than using ServiceModule though, with the new resource values in the definition, and then just applied it to appropriate parts as necessary). Since the recent changes to TAC I've not updated it though, because of the good possibility that it is going to swap to using liters for units soon anyway - that's actually what got me to put my large-scale colonization efforts (fully developed self-sufficient bases on every solid planet with service stations in orbit around all, and full com/gps/mapping satellites for the entire Kerbol system was the eventual goal) in stock-Kerbin scale on hold and switch back to RSS for a while, though currently without using any life support addon

Edited April 25, 2014 by RaccoonTOF

[Guest]

Easy enough to change the numbers to 3x MRE meals equivalent per day... As for Volume and mass the base line values shouldnt be hard to figure out. The containers I am unsure of although i'm sure a real fuels setting could be given to them, as it was for ECLSS to fill containers made with procedural/stretchy tanks.

To update numbers: all numbers checked via Wikipedia or similar sources

* On average, each human adult produces approximately 0.5 L of urine per day (0.5 kg) and 115 g (0.115 kg) of feces per day **using my nation as a base line (Canada)

* On average the calorie needs of an "active" adult human male 19yr to 50yr is 2,950 kcal or 12,343 kJ per day, allotted 3x MRE meals account for 3,600 kcal or 15,000 kJ **using my nation as a base line (Canada)

* On average the drinking water needs of an "active" adult human male is 1.8 liters (1.8kg) per day allotted water accounts for drinking water & 200ml misc supply per day **using my nation as a base line (Canada)

* Air and CO2 numbers are the average for an adult human to consume/produce in 24hr period, the average person's respiration generates approximately 450 liters (roughly 900 grams) of carbon dioxide (CO2) per day

* Water use should be 0.002 // 2kg for drinking water & 200ml misc supply per day

* Food needed/used should be 0.0015 // 1.5 kg per day (assuming this includes minimal packaging that is accounted for in "waste") Increased to 3x MRE meals in mass per day 3,600 Calories (3,600 kcal or 15,000 kJ)

* Waste produced should be 0.00012 // 0.12kg per person per day (the additional 5g's is to account for any packaging wastes)

* Waste water produced should be 0.0005 // 0.5kg per person per day

* Oxygen needed/used (air really, the full gas mix not just O2) should be 0.0132 // 13.2Kg per person per day

* CO2 should become 0.0009 // 0.9kg per person per day

This said we can average the masses to: all numbers checked via Wikipedia or similar sources

* 1 human needs/uses 1.5kg of food per day Increased to 3x MRE meals in mass per day 3,600 Calories (3,600 kcal or 15,000 kJ)

* 1 human needs/uses 2kg of water per day

* 1 human needs/uses 13.2Kg of Oxygen (air) per day

* 1 human produces 0.9kg of CO2 per day

* 1 human produces 0.12kg of "waste" per day

* 1 human produces 0.5kg of "waste water" per day

That should do for masses, now it would be to find volume per 1kg in liters of each:

* Water and waste water would be 1kg = 1 liter

* The volume of CO2 would be 1kg = 500 liters, at surface pressure... not sure what pressure it would be stored at.

* Waste mass in kg per liter of sewage sludge (solid waste) is: 0.72kg per 1 liter or 1kg = 1.38888 liters

* Food, US army manual states the weight of each case is approximately 15 lbs and it measures approximately 1.02 cubic feet volume > 6.80389kg & 28.8832 liters (0.0288832 cubic meters) or 1kg = 4.2451009 liters in metric.

* Finding the volume of 1kg of air in liters, under typical storage pressure levels, should be easy enough to google.

I should be able to update Air volume in liters per 1kg, under typical storage pressure levels, and the volume in liters per kg of CO2 under typical storage pressure levels... with abit of time spent on google... will attempt

I am sure the exact power usage and input/output specs on a various spacecraft CO2 scrubbers, Waste water reprocessors, fuel cells, and electrolysers can all be found on Wikipedia or similar source, but all the parts exist.. some parts may need RO resizing/remassing

Edited April 26, 2014 by Guest