johnsonwax

I don't need credit. You're doing the real hard work here and I'm more than adequately compensated by being able to use your parts.

I just did a little experiment with ModuleAblator for sumghai. lossConst seems to dictate the temperature at which the ablator begins to boil off. Increasing the value lowers the temperature (stock 20 boils around 850, 50 boils closer to 770). That has the effect of removing heat faster from the part, keeping the parts max temperature lower, but slightly increasing the amount of ablator consumed. pyrolysisLossFactor seems to dictate the amount of heat energy that a given amount of ablator uses. It boils off at the same temperature, but higher values remove heat more efficiently. Doubling the value from stock 10000 to 20000 cut the ablator consumption nearly in half and lowered the max heat value the part was exposed to. Cutting the value in half to 5000 increased consumption by 80% and increased the max heat value the part was exposed to.

Ok, experimentation complete. Well, complete enough... I started by tweaking lossConst. Increasing this from 20 to 50 resulted in the ablator starting to boil off at a lower temp (about 770), keeping the max heatshield temp lower (max around 950), and slightly increasing the amount of ablator used (about 10%). I think this simply sets the temp at which the ablator starts to boil off, but doesn't change the effectiveness of the ablator. I moved on to pyrolysisLossFactor, and decreasing it from 10000 to 5000 caused the ablator to start to boil off at the same temp (around 850) but increased the max temp of the heat shield (max 1100 - above the failure temp of some surrounding parts) and increased the amount of ablator used by 80%. Increasing the value to 20000 has the opposite effect, started boiling at 850 as before, max temp of only 950 and ended up using only half of the stock values. So this value determines how much heat energy a given amount of ablator removes. This is what you want to change if you are after 'high quality ablator' - increase the stock value from 10000 as appropriate. I think 20000 would make for a VERY durable heat shield. 15000 might be a better middle ground.

Magnetometer has a high temp threshold (3500). I just stick it to the side of, well anything, and pull it slightly back inside the craft. But it probably doesn't need to be shielded at all.

Hey, if Elon Musk can land spacecraft without parachutes*, then damn right we will too. *for varying definitions of 'land'

The Bertrand was presumably safely inside the Van Allen radiation belts during that entire period. And while the food didn't spoil, diminished nutritional value can't be dismissed. A fair bit of the work done on long shelf life, low packaging food was justified by the space program, so including it as part of the tech tree isn't unreasonable. Freeze drying was first developed during WWII to ensure that blood could be shipped to the front lines from the US without spoiling. It wasn't really used for food until the space program. - - - Updated - - - True. But it still strikes me as odd that we'd go from 'sorry you can't bring any food with you' to 'here, we found this in an apocalypse prepper's bunker - take all of it'. Seems like logically there would be something in between. I'm expecting to use a Universal Storage wedge in a lot of situations, but I think that there should be something native to the mod.

Done. Sorry for not thinking of that sooner.

I think Minmus illustrates the need. A proper surface exploration sits right at the duration of not bringing food, but adding any at all adds 0.6t and gets you enough food for a year. That's a harsh inflection point early in career mode. I'd actually put a 30 day or so supply in a radial tank at 0.05t, where you can add 2-4 radially for moderately longer in-Kerbin SOI missions and put that in the existing tech node where the parts are, and move the inline parts out a tier. A year of life support is non-trivial to do relative to 30 days. It's not just the mass and volume, but also keeping it preserved and uncontaminated and all that and so it should take at least a bit more R&D before you can chuck off to Duna for a year.

Getting the following errors: 227259 [1] ERROR CKAN.ErrorDialog (null) - Failed to download "https://kerbalstuff.com/mod/348/Near Future Construction/download/0.5.0" - error: RecvError 232385 [1] ERROR CKAN.ErrorDialog (null) - Failed to download "https://kerbalstuff.com/mod/350/Near Future Spacecraft Parts/download/0.4.0" - error: RecvError I can successfully download from those links in my browser. I have had no problems downloading other parts including Near Future Solar which was released basically at the same time by the same author also from KS. Most recent version of CKAN on MacOS X 10.10.3. Update: CKAN client on MacOS X still suffers from the problem that transfer speeds plummet unless you are actively moving the mouse. If I kept the mouse moving continuously during the transfer, it was successful. Might be coincidence, but it's possible that the client isn't polling properly without the active input and timed out the download. These are reasonably large part mods. They aren't the largest I've downloaded, but they're in the top 10.

Just showed up in CKAN for me. Hour sounds about right.

That is really impressive...

Well, how about either a setting or checking for the life support mods and switching that way? I've always used TAC and am likely to switch to USI, so having real tourist missions of lengthy duration increases the challenge with life support - particularly with a OKS setup if you are trying to get close to closed loop - adding 20 tourists becomes somewhat nontrivial. For those without life support, make it hours or whatever is suitable. The station contract pack has life support resupply missions, so it's doing pretty much this.

This thread should help quite a bit. There looks like a few variables you could look to tweak. I'm guessing that it has an emissiveConstant of 0.4 (the rate at which it radiates heat away) which could be increased slightly, which would cause it to absorb heat slightly slower, so it would take longer to hit ablation temp, so it would ablate later, and slightly slower. You could similarly increase thermalMassModifier so that it can simply absorb more energy - the more it can absorb the more slowly it would increase in temp. But it doesn't emit so the former approach would cool down faster than a normal heat shield, while the latter would hold onto the heat longer than normal. There's a few parameters in the ablator module that might help, but it's possible that it's a zero sum function. You could reduce the conductivity, but that would just cause the non-ablative part to overheat and fail. If you lowered the lossCons, you similarly wouldn't boil off ablator fast enough, and again that may cause the part to overheat. The tempThresh probably just determines at what temp it should start boiling off, so that's probably not useful. pyrolysisLossFactor might dictate how much heat a given amount of ablator removes, which would make the ablator more efficient per unit. Might need to do some hyperediting and trial and error. Throw one of the temp monitoring mods on there so you can see what happens between runs.

I'm learning it often takes overnight for CKAN to pick up changes.

Alternatively you could have the heat shield dissipate a little bit of heat relative to stock and it would then consume less as a normal function of the thermo model.

I think you'd need to be careful about making the cores heat exchangers. I like the idea a lot, but in many situations it would require that you have a radiator wedge in there to keep the other wedges from blowing up. Whether to use a heat conductive core or not seems like a design decision during build, suggesting having two versions of each part - or having one that can be tweaked. And a vote for a USI-LS wedge as part of the optional part package. I suspect USI-LS will be quite popular.

Just as an FYI, NASA does use somewhat larger fairings than you've indicated. They'll take payload fairing diameter as high as 160% of the upper-stage diameter (1.3x radially). So going slightly larger is not unrealistic.

I think MM uses hyphen '-' to delete values and '!' to delete nodes, so I think you either want: @MODULE[LifeBoat] { -foodAmount = DELETE -waterAmount = DELETE -oxyAmount = DELETE } !RESOURCE[Food] {} !RESOURCE[Water] {} !RESOURCE[Oxygen] {} Or @MODULE[LifeBoat] { -foodAmount = DELETE -waterAmount = DELETE -oxyAmount = DELETE } -RESOURCE[Food]{} -RESOURCE[Water]{} -RESOURCE[Oxygen]{}

I guess my feeling is that it'd be nice if it happened in a more organic way. For instance, you would get failures on engines, because that's really where the failure would happen. The engine could fail in two ways: 1) It stops producing thrust, which either causes you to not go to space today, or if you have multiple engines causes your thrust to go out of angle and you spin off and you can or can't recover or maybe break up/burn up under the stock aero model. 2) It explodes, and you increase the heat of that part to something suitably high before you remove it, and let the stock heat transfer model determine if that should cause the adjoining fuel tank to fail, which gets the same treatment - suitable amount of heat on explosion, and on up the stage. Parts without fuel don't explode arbitrarily, but may fail under the aero model. Kerbals may die due to g-loading, etc. but the command pod itself wouldn't spontaneously explode. This gives you both an understanding of the failure and presumably some opportunity to abort, but also possibly some ability to design craft that can better protect the crew. Might be a fair bit harder to code, though. While 'structural damage' is certainly realistic, 'you died and there was nothing you could do about it' isn't terribly fun.

That bug has been fixed in 1.0. You can now attach by any node, however the node directionality is now strictly enforced, which is likely the problem. See thread here.

I'd like to put in an early request for some feedback on whether the new .Net frameworks for OS X and Linux that came out today are useless/better/worse options than mono. Anything with an interface is pretty marginal under mono on OS X (IMO) so I'm hopeful that running under official distribution will be better. I'll probably take a crack at getting it installed this weekend, but the devs might want to take a look as well.

Ladders should have almost no financial cost. Their real cost is in drag. If you can increase the drag of the parts unless they're shrouded, that'd make the most sense.

I like the plan as well. I think a focus on station/base contracts would be appreciated by many, especially given the previous considerations for attractions. Missions with relatively long durations (stay at the station for 30 days) give motivation to expand stations, plus they make running proper shuttles somewhat interesting if you have something that works a bit more like stock with different itineraries. Now you get something that can work like some of the various transportation games out there where you have many overlapping tourist missions where you're shuttling a bunch to point A (station) for various durations, dropping some off, picking up others to go to point B (Minmus base) for various durations, etc. Some of us like that sort of thing...

KCAN is picking up the mod fine, but the AVC version metadata still says 0.9: { "NAME":"Contract Pack: Kerbal Space Station", "URL": "https://github.com/severedsolo/KerbinSpaceStation/blob/master/KerbinSpaceStation.version", "DOWNLOAD":"https://github.com/severedsolo/KerbinSpaceStation/releases", "GITHUB": { "USERNAME":severedsolo, "REPOSITORY":KerbinSpaceStation "ALLOW_PRE_RELEASE":false, }, "VERSION": { "MAJOR":1, "MINOR":2, "PATCH":1, "BUILD":0 }, "KSP_VERSION": { "MAJOR":0, "MINOR":90, "PATCH":0 }, "KSP_VERSION_MIN": { "MAJOR":0, "MINOR":90, "PATCH":0 }, "KSP_VERSION_MAX": { "MAJOR":0, "MINOR":90, "PATCH":0 } }

One way to handle that would be to upgrade the comm relay at KSC when you upgrade the tracking station. For Level 1 you get geosync or thereabouts. For Level 2 you get Kerbin SOI (rounded up). For Level 3 you get the universe. Those generally correspond to when you upgrade your dishes to about those levels anyway.