Starwaster

Far does not do anything to the atmosphere itself. It sets all part drag to zero and calculates and implements drag itself.

OMG you got reflective visors working! Nice.

I did not. Just what was on the front page for the original mod.

For the first one, when something like that happens, KSP_Data/output_log.txt!!!!!!! As soon as possible, before it accidentally gets deleted

I don't think we can rule out graphical settings right now, but I already tried duplicating your problem by playing with the aeroFX settings with no luck. It does look from your last screenshot like you're at a lower setting but if anything I would *think* that would decrease the likelihood of the sort of behavior you reported. (looks like the effect of that setting is less tessellation in the reentry geometry) There's also DREC specific settings that control when the effects start and when they peak but that shouldn't cause it to alternate with the supersonic effects because it doesn't touch those at all. You would, I think, already have to be at an eligible altitude and atmospheric density for those to be active in order for the reentry FX to be alternating with the supersonic (condensation) FX. Sorry, don't have anything more than that for you

... You were alt-tabbed out away from the program during that time period ... And, let me make sure I have this correct: You're upgraded to the very latest DREC and RealChutes and still seeing InvalidCastException errors? During reentry?

I have recompiled for 0.23 and released here: http://kerbalspaceprogram.com/graphotron-0-23/ Edit: The part.cfg file was also updated and will show up on the tech tree available on the basic rocketry node.

Engine fairings.

Ugh, that thing is filthy. Could you please clean it while you're out there? kkthxbai! P.S. congratulations!

Some clarification Motokid: The update I put out was explicitly to fix an incompatibility introduced when RealChutes changed how some of its variables worked. Basically you've got a version mismatch going on. Upgrading one means having to upgrade the other.

You need to update DREC. BIG EDIT: link on front page is current latest. Grab it.

Sounds a little steep. Also, if you're using the ablative variety what's the reflectivity set at? I have mine configured for reflective only, no ablation. I come in shallower than you, I think. I don't burn up.

The new Dean Drive?

It probably wouldn't be too terrible losing MHE, but before any decision gets made on that, keep in mind that (whether intended or not; it's probably a 'feature') MHE allows switching between more than two modes. The benefit of that is that you can make LANTR engines with multiple mix ratios. Only the first two configs show up in the editor but when switching modes 'in the field' you could cycle between different mix ratios.

Right click the craft's control part and click control from here.

It probably still is as a fallback. What wasn't working with it? I've been messing with the Mk1 pod IVA and I have it happily sharing the Mk1-2 pod's textures and they're all happily sitting in the same folder together, config files, model files and all. Granted it looks like crap because they weren't meant to share textures but works otherwise.

Actually, this is what I was saying in my earlier post. Except that I think the texture declarations are unnecessary if they're all residing in the same folder. Which unless I badly misunderstood Helldiver, that's what he and Nazari want. They were running into problems with the IVA's trying to load the wrong models, but that's what the MODEL{} nodes are for.

The parts need to be configured to use it. Look at the first page for example usage. Or download frizzank's FASA mod which uses it in his Mercury Atlas rocket

I'm having some trouble with what I'm hearing about how KSP handles Internals... that it does not handle them like any other part? I'm doing some experiments here and so far it seems like it very much does. KSP does not care what a part's folder is named or what it's internal's folder is named and doesn't look for internal.cfg, it's not aware of those files or folders. What it looks for are config nodes. I'm pretty much abusing the hell out of the MK1 pod internals right now. I've renamed folders, separated the model and textures from the cfg, renamed the cfg to jebs_trailer_home.cfg. All that matters is that the game can find an INTERNAL node named mk1PodCockpit //jebs_trailer_home.cfg INTERNAL { name = mk1PodCockpit MODEL { model = Squad/Spaces/MK1_Assets/jebs_trailer scale = 1.0, 1.0, 1.0 } // buncha other stuff [I]<SNIPPED!>[/I] } Right now I'm trying to learn what the meshes and textures are used by the MK1 pod model so I can separate them from the model (though for your purposes I don't think that's necessary?) and spread them across three folders. Texture designation is handled in the MODEL{} node via texture = <texture name>, <texture URL path> Edit: Oops that was wrong, it's texture name not mesh name. Much simpler But what does work right now is that I have the model and textures in one folder (Squad/Spaces/MK1_Assets/) with a model named jebs_trailer.mu as indicated in the config file excerpt above. Edit: Just to make sure it's clear: I inserted that MODEL declaration after moving model/textures and renaming the model.

Ah you should already have a pull request for RSS on github. Earth/Kerbin's curve data is part of the pull with a cutoff of 250. (below 250 to at least 200km you can still quicksave and even exit to space center safely) I did do curve data for Mars/Duna and I think I emailed that to you but it's only had minimal testing and is not part of what I have on github right now. It goes all the way up to 400km (I think) unless we want to lower it's cutoff. Given that Mars does have a larger atmospheric envelope we should have it higher than Kerbin's. But if you want a lower cutoff I can recalculate that. If you also want curve data for anything else I think I'm happy enough with the system I have to generate everything else automatically and I can have that done later tonight. (will actually only take maybe ten minutes but it's not ten minutes that I have at the moment) (actually as I write this I just realized I do have some newer code but it does nothing but move the animation curve parser into a separate function which will be useful if we want to implement non atmospheric curve data that can use the same parser. But aside from that what's on github is totally functional)

Not functional or you get a security warning?

Have you checked output_log.txt for errors when your cfg is applied? Or to see if something else is adding new engine modules in? Also, I thought it was @NODE[name,tag] with tag basically being something that was, and still is largely unused.

This is the bulk of the code I'm using. There's some debug stuff in there (_angle) which can be removed. The only other bit of code is a check I had to put in FollowDragDirection to see if forceOrientation / secForcedOrientation == -1 Use it as you like, or not. For asymmetrical craft btw, I did make a real frankenstein of a ship and tested it. Worse case scenario was for chutes placed below center of mass. I think that can easily be dealt with by checking for that and either not doing offset on them at all or compensating and putting them back up above the ship. Max angle can probably be lowered even further than 45 or made configurable. private Vector3 GetForcedVector(Transform chute, float angle) { if (angle >= 90 || (angle <= 0 && angle != -1)) { return Vector3.zero; } Vector3 follow = new Vector3(); if (angle == -1) { angle = Vector3.Angle((dragVector + this.part.vessel.findLocalCenterOfMass()).normalized, (part.vessel.findLocalCenterOfMass() + part.transform.position).normalized); // This bit here should use (pre)deployed diameter to calculate final scaling of the angle angle = Math.Min(angle * (deploymentState == DeploymentStates.PREDEPLOYED ? 0.1f : 1.025f), 45); follow = chute.transform.position - this.part.vessel.CoM; } else { follow = chute.transform.position - pos; } _angle = angle.ToString() + ": " + follow.x + ", " + follow.y + ", " + follow.z; float length = 1 / Mathf.Tan((90 - angle) * Mathf.Deg2Rad); return follow.normalized * length; }

True, I haven't tested it on non-symmetrical ships yet; just a few test articles where symmetry was important to help me keep the math straight in my head. I also tried center of pressure, and that had the interesting effect of causing the pre-deployed chutes to not spread very much at high speeds and then to gradually pull apart as the craft slowed its descent. Looked very nice actually. Unfortunately it also had the bizarre effect of causing the chutes to orient down under the ship when it reached full deployment. I'm assuming it was drag increase moved CoP above the row of chute parts, or even outside the vehicle completely.

THAT..... that is just so wrong.... or so right. I guess it depends on your perspective.