Starwaster

You know, I was curious after reading what you said just how badly the texture compressor was blurring things. I prefer empirical evidence and I haven't seen any pictures showing your cockpit in poor quality as the result of texture compression. In fact I use it myself and the cockpit looks fine to me, but if what looks fine to me is actually bad quality then I figured I'd uninstall the compressor and start the game to see what it really looked like. And honestly I can't tell the difference. But I have an outdated copy of the texture compressor, from back when it was actually called... texture compressor. (it's Active Texture management now, or something). So I re-downloaded it, the 'aggressive' version and checked the cockpit again. Pictures below. Can you tell me which one is uncompressed, compressed with the older version and compressed with the newest aggressive version? Because I can't even tell you which one is which. The only difference I see is when I look at Task Manager. (2 GB, 2.5 GB and 3.2 GB). But, I can guarantee you that 2 are uncompressed (standard KSO download, not alternate low res), 2 are compression using the December version and 2 using the most recent Aggressive.

Did you miss my experiment? It can handle more than four. Life support can go below decks.

Are those windows normal mapped only or are there extra polys involved? I want to retexture it to have moar windoez

Real world ratios will be mass, so start there. Determine what the mass requirements of each are then convert that to volume, which is what those input/output rates are. Low density resources like hydrogen as input will require more volume. Real Fuels volumes are in liters which is ~70kg per cubic meter (liquid H2 not gaseous though). (it's really really light) I'm a bit hurried right now so I can't actually sit down and do the math on this for you, at least not now. I'll leave you with this though, if your input is LiquidH2 (assuming you're shipping it to the Red Planet as the plan called for) then you're going to need a lot more intakeAir. (unless..... does the Kethane converter take mass into account at all? If so then.... I have no idea how that affects what I just told you.... ugh)

For a player stuck with the choice of installing another mod or deleting one to make room it's not about you and your artistic sensibilities. They play their way and make their choices based on what's good for them.

Is that why they bounce like The Son Of Flubber after a crash?!??

If your objection is having multiple KSO texture just for name switching, have you considered taking the FlagDecal approach? Setup the shuttle name on a separate quad and then you only need separate smaller textures just for the name instead of separate full KSO texture sheets that only changed the name. Have you ever tried NOT doing that? Unless you 1) hacked your persistence file or 2) used Crew Manifest to make death permanent, it isn't. They'll be listed as 'missing in action' and turn up a few hours/days later. As though nothing had happened.

Actually, the code looks like its from the fixed version. I'm guessing Nathan merged the fix but didnt update the download. @theSpeare, did you try just compiling that code and trying it ou before making changes?

How about the opposite of orbital decay, where we can operate our ion engines while we're actually away from the craft. (not warpable engines.... just be focused elsewhere while a probe makes its ion burn)

Psssst. Check back in the DREC thread. I revised my explanation as to why it's happening and a fix that can be done in the radial's part.cfg

I've been playing with this for most of the past evening (well actually it's morning here now) I had the problem wrong, it's the exact opposite of what I said. It looks like the transforms are too close to the bottom of the radial chute AND the radial chute is actually attached 0.0025 deeper into the surface it is mounted to. Together, that puts the transform origin inside the Mk1 pod. (btw I was totally unable to replicate this with the stock radial) This is a workaround. Add the following code to the RC radial, preferably by using a ModuleManager config. I'm guessing at an appropriate value for adjustCollider. I know for a fact that -0.25 works, but it's too aggressive. It will cause the radial to show up as shielded even if nothing is there to shield it. Haven't tested the value below but it should probably work. If not, increase it a little. (I picked -0.015 as 0.0025 *2 to compensate for the part being sunk in and an additional 0.01 to compensate for the transform, where I'm not exactly sure how far off it is. (what this does btw is to move the origin of the raycast further back along the directional vector. That's why -0.25 is too aggressive; the raycast was actually hitting the radial so it was 'shielding' itself) MODULE { name = ModuleAeroReentry adjustCollider = -0.015 }

You can't truly delete it. All that would do is delete it from the config node. However, the underlying programming always assigns a default value to any variable that can be assigned in the part's configuration file. Or for any PartModule variable that you try to change. (i.e. MODULE{}) Deleting it just means that the part will use that default value when initialized. And in the case of scale, you don't generally want to mess with that anyway. Any time you think you want to change scale, you probably really wanted to change rescaleFactor instead. OR set scale AND rescaleFactor to 1 and then change the MODEL{} node's scale vectors directly. (if you wanted to rescale one or two of its vectors only)

Well you do, mostly. It's just that the means by which part positioning is determined is necessarily fairly simplistic.

It's transforms are probably in the center where they belong

It's because of what I'm trying to tell you. There is nothing shielding that part. Remember that thing I mentioned? The transform? It's what tells unity and KSP where the part is and which way it faces. I have no idea where that parts transform is but it's probably sticking out into space and you've got it on top of a narrow cone. Tilt that cone at an angle and it tips those transforms out further. You want something more bizarre? Make your reentry orientation pointing away from the planet so the cones side faces into the reentry. So that the radial chute itself faces into reentry with the pods nose up. If using mechjeb, use SmartASS. Use SURF with HDG 90 PIT 90 ROL 90 You'll probably find they report as shielded. They should not be but they are. It's all about where their transforms are. tl;dr it's because of the way the part was made, not DREC.

The figure I came up with previously for CH4/LOX was .35/.65 Not sure those configs are compatible anymore.... and I've not got around to revising them

It gets worked on when those working on it can find time to work on it from their demanding lives.

Just speculation but it sounds to me like it just applied a little too much thrust or too soon, and zeroed your velocity too early. That can especially happen with a high TWR. I think you probably dont need to worry about it...

Here's some other information about what happens behind the scenes with the plugin: When your craft is in atmo and travelling fast enough in dense enough atmosphere to have a shockwave heating it up above ambient it is first checked to see if it is shielded. The isShielded function takes the direction of travel as its sole parameter. It checks first to see if the part is a stock parachute and is in any state of deployment. If both of those are true it is automatically unshielded and subject to thermal effects. It is then checked to see if it is a RealChute parachute and in any state of deployment. As above, if deployed it is unshielded. (IMO, a better solution might be to simulate chute failure by putting it in CUT state, assuming that's possible, which it might not be) If it's not any kind of deployed chute then a ray is cast from the part's transform (the part of it that designates its origin) in the direction of travel. If the ray hits something in its path then the part the part is treated as shielded. Since we're talking about undeployed chutes (they are undeployed right?) then that means the chutes are failing the raycast test. The ray is striking nothing in its path so the chutes are unshielded. Being higher up the cone shaped capsule would definitely decrease the likelihood of hitting any part of the cone. And it also depends on exactly where the transform of the part is. If it's closer to the attachment side of the part then that increases the chance that the ray hits the capsule. If it's further away, closer to the end that's sticking out, then that increases the chance of a miss. I specify the capsule here because there's really nothing else it might hit. You might increase the odds of survival if you don't orient the capsule at an angle. The chute part's direction of travel would then be much more likely to strike either the capsule, or maybe the battery below, depending on where its transform is. (hypothetically, it could be so close to the capsule that when attached, the chute's origin is inside the capsule, in which case it might hit nothing at all. Hypothetically) BTW if you are using the latest version of RealChutes then you want the very latest version of DeadlyReentry. I'm not sure Nathan's dropbox is updated yet with it, so here's a link to my dropbox. Source is on Github. (see front page) https://www.dropbox.com/s/e86pz9cv8i65o2l/DeadlyReentry.zip

Easy, tiger. You're being a little overzealous. Edit: Here's even MOAR pictures. They aren't meant to solidly prove anything either way, just to show, as scientifically as possible, how much room there is and is not. This is an attempt to cram an even larger number of Kerbals in than are currently being discussed. I used a cargo bay because I don't feel that showing Kerbals on the outside of the ship really tells us much. I stopped after only three Kerbals because I felt I had sufficient data for PJ Space Plane Ergonomics Mk2 (I had a full twelve Kerbals waiting to participate) Pertinent data about the experiment: The cargo deck is longer than the passenger module in question. Please note the truss in the center (bad placement, sorry). The truss marks the extreme end of a passenger module and an actual passenger module was attached to aid in placement. It is accurate. A floor was put in place as we probably won't have the seats sitting on curved floors. Twelve seats were placed. They were not given optimal placement and the floor could have been lowered a bit. Without helmets and with the seats spaced further apart we can definitely get a good number of Kerbals in there. This experiment is neither a success nor failure as its purpose was to gather data. My takeaway from this experiment is that: Helmets are out. No helmets unless we're putting the Kerbals towards the center and doing with less passengers. A floor is a must but I could have lowered this floor a bit and given the Kerbals more headroom. This is worst case scenario, not what we CAN do. We can definitely do four Kerbals, no problem. Maybe even 6-10 if we get creative.

I'll examine it in detail when I can sit at my computer but I want to address something you said right now. For EVERY single part, for it to survive thermal effects one of two things must be true, no exceptions. Either the part has to have heat shielding built into it. Or another part must be directly between it and the direction of travel, in which case it is treated as 'shielded' and will be exempt from heating as long as the part shielding it survives. Just being mounted on a heat shielded craft is not sufficient. That is how it should be.

I'm not experiencing what you are. My radials don't explode if something is between them and the shockwave. It might be time to start posting pictures of your craft and evaluating your design.

So add it. That's how config files work. If not present the program uses default values.

I hereby sentence you to wear the... pants of shame.

No harm, but it's more informative if you go into the ksp_data folder and show your output_log.txt file instead. ksp.log seldom has useful information. The good stuff is stripped out. It's like drinking watered down rootbeer :/