Starwaster

Oops sorry I missed that part of your question. There's a bug that was introduced in the very latest Real Fuels update that broke the hybrid engine code that the trimodals depend on. I just had a notion though that perhaps the RAPIER module could be appropriated as a workaround until Nathan gets around to the next update.... It wouldn't be a perfect solution but I think it's workable.... I'll have to look into that. (or maybe I could look into the hybrid problem itself.... hrmmm)

MJ does no such thing. It doesn't aim for the edge or anything. It aims for the docking port's transform. The only way it would deliberately aim for the edge is if the docking port has offset transforms. By default it aims for the part's transform itself, but that can be overridden when designing a docking port part. Also, I just did two flawless dockings with two quick docking targets I put together. One with the KW 3m port and one with the 2m port I'm not sure exactly where the KW port's transform is but if it's sunk into the part (which is fairly large and bulky) what would happen if MJ did not precisely align with the docking axis? It would clip the edge, wouldn't it. (that's not really a question, that is exactly what it would do) The version of MJ I'm currently using is a personally modified version of build 168 which gives guarantees that it will be aligned before approaching. It had absolutely no problem docking the two parts and I deliberately placed them back to back before initiating docking so it would have to back up the long way around on its own and then figure out how to approach. Some screenshots. Notice shots 2-4. See where the target indicator is for the port? It's actually at the BOTTOM of the part. But the top is what needs attaching to. Anything but a flawless approach risks clipping the edge.

If I understand the problem, I think the newer dev versions should dock it better. Though in my experience the new docking AP's reliability is not constant. Sometimes it does good and sometimes not so good. But when it works it is better at aligning the docking axes than pre-170 versions which tended to come in at nearly a 45 degree angle.

Which MJ function are you using for your Münar transfer? You should be using Hohmann Transfer. If that does result in a Münar encounter, then follow it up with 'Fine Tune'. The closer to circular your starting orbit, the better. (no need to go overboard, just so long as it isn't grossly elliptical)

Sorry, could you please rephrase or elaborate? I don't get what you're suggesting...

Do you have FAR installed? I just put FAR in my installation (or back in as the case may be) and that's about the only time I notice SAS 'shaking' problems. Also I notice the spaceplane guidance does have issues that I don't see with stock aerodynamics so I wonder if Deathsoul's spaceplane guidance issues were also experienced with FAR...? (problems of the 'have to keep pulling the nose up because MJ doesn't realize that it's pitching down too steeply)

Ok, this is for Hodo and anyone else wishing to use radiators / heat pumps, etc. HeatPumpFix The folder has the dll and the source file that was changed. It's not the full source for Real Fuels, just to show what was changed and fulfill Squad's transparency requirements. It carries the same license as Real Fuels itself, which is to say that you're free to do what you want as long as you attribute the source and include the disclaimer that Ialdobaoth, Nathan Kell, Starwaster, et al are a bunch of hoopy froods who really know where their towels are at. Instructions! Replace existing modularFuelTanks.dll Consider editing the heat fin part.cfg or any other radiator using ModuleHeatPump and changing or adding any, all or none of the following: (in the ModuleHeatPump section) heatConductivity = 0.12 // Best to leave this alone Experiment at your own risk heatDissipation = 0.12 // Best to leave this alone. Experiment at your own risk heatTransfer = 1.0 // Multiplier that controls how much heat is removed from the thing being cooled heatGain = 0.0 // How much of the removed heat gets added to the heat pump / radiator. Those are the default values. heatConductivity and heatDissipation are actually stock Part properties that are normally inaccessible. I've made them accessible for the radiator part by changing/adding the properties to the ModuleHeatPump section. The one that comes with RealFuels has a value of 0.05 for heatDissipation. I'm not really sure what the effects will be if you leave it in place. In general (given KSP stock heat model behavior) it will be very slow to gain or shed heat. I'd remove it because that means it will be slow to get rid of any heat it gains from the fuel tank / part that you put the radiator on. I haven't tested this since injecting it into the current code base but it should work given the success I had with it in the past. Experiments with heatConductivity / heatDissipation did not go well which is why you shouldn't play with those values unless you're using it in a test environment and don't give a dang about what happens to your ships or the Kerbals on them.

Sorry, still haven't got to this. Took a look at GitHub and realized that the code base has changed quite a bit. It's not a big deal for me but it means that what I have is out of date so I still have to pull the new code and make my changes there instead of giving you something with outdated code. And I haven't gotten to that yet Not intended. Jet engines haven't been gotten to yet. SRB... if you use Stretchy SRB you can modify those SRBs. MF doesn't do anything with intakes.

Latest version of RealChute seems to have broken DREC. While trying to land my space plane I generated a 280 MB output_log.txt file (which, needless to say I will not be posting) 280 MB of THIS: InvalidCastException: Cannot cast from source type to destination type. at DeadlyReentry.ModuleAeroReentry.IsShielded (Vector3 direction) [0x00000] in <filename unknown>:0 at DeadlyReentry.ModuleAeroReentry.ReentryHeat (Vector3 velocity) [0x00000] in <filename unknown>:0 at DeadlyReentry.ModuleAeroReentry.FixedUpdate () [0x00000] in <filename unknown>:0

How about only partially destroyed? Granted, it was the cockpit, so sadly the crew all perished but you can see from the design that it's a difficult plane to put down. Because of its long neck it tends to pitch down during braking, which is what happened here. I'm still working out optimal landing and braking procedures but the point is that MJ put this plane down. It doesn't handle throttling or braking; that's the operator's responsibility. I have landed this plane successfully using the spaceplane guidance and am confident that once I work out the flaws in the design that it will be much better in the future. Edit: @hieywiey: You'll have to step in at the end to handle braking, but it's totally doable.

Yeah, this place can be like that sometimes. Hidden, unassuming gems from time to time. And then there's the ones you look at, think to yourself, I should download that sometime. But not today. And then you download it and you're hesitant because it threatens to be so game changing. And then you finally try it and you're all like, HOLY CRAP How did I get along without this??? Kerbal Alarm Clock is that plugin for me. I could probably get by without MechJeb. I probably wouldn't LIKE it but I could do it. But manage 20 different space craft and probes with multiple events and maneuver nodes in their future? If I HAD to choose one of those to do without I'd have to let MechJeb go.

Has someone sent this man his blueberry or cherry pie yet? (someone who isn't a fulltime volunteer with no income I mean, so don't look at me!)

On the subject of the Mk2, it would be really REALLY cool if we had an S2 -> Mk2 adapter. Check out my new spaceplane...(bottom) I really like it except for what I had to do to connect the S2 fuselage to the Mk2 fuselage/cockpit. Though it does give it an interesting sort of swan neck that I like, it doesn't flow smoothly. BTW it takes off and flies like a dream. Getting into space with the RAPIER engines is tricky. (they're actually B9 SABRE engines but I whipped up a MM config to change them to use RAPIER ) Landing is a real PITA though because if I'm not careful the cockpit will come crashing down onto the runway when I touch down. On at least TEN (10) separate occasions the spaceplane has come to a perfect landing in the middle of the runway sans cockpit and crew. (thanks Stupid Chris for the drag chutes) No joke, no exaggeration And landing minus cockpit. (engines are still running so this isn't one of those perfect landings I mentioned, it probably crashed shortly after)

Re: your edit. It still sounds dirty

And an angel just lost its wings.

I think there would be conflicts with Stretchy Tanks. They would both be trying apply textures when the tank spawns.... the texture modification part of Stretchy would have to be rewritten... ideally you would want to be able (as player) to have full control over both. Where the user could select reflective textures but also to be able to pick up the ball and switch back to stretchy tank textures.

Yeah see, that's what I was afraid of. I didn't want to jinx you or naysay you though

Have you tried it with both FAR AND RSS? I finally have my spaceplane working decently but it's stock aerodynamics only (well stock with DREC) I want to get back to both FAR and RSS

Oooooo I think you can do that with Firespitter... ? isnt that what the hab uses for animation? or is it stock animation? I cant check right now

Shouldn't you change it from a Winglet to a Part? (module = Part) Because unless you do that, it's still a Winglet and most likely has default values that it will apply for dragCoeff and deflectionLiftCoeff. That's what happens if a part's properties are not set in it's config file.

It's incorrect behavior considering how KSP's thermal dynamics work. The game will replace any heat just as quickly as the heat pump moved it out from the tank to the fins. additionally, the system then turns around and tries to spread the heat around which effectively means it moves it BACK into the fuel tank. Increasing heat pump transfer values can actually result in the destruction of the heat pump and possibly the tank as well. Nathan and I have talked about this and what we'd like to do is replace the existing KSP heat system with one of our own devising. This can be done but I think both of us have too much on our plates to get around to it. I do have a workaround temporary solution and I'll post it later tonight. Basically changes the heat pump behavior and other heating behaviors. I never finished it to my satisfaction but the incomplete solution works too.

That was only coincidence. The problem you described is intermittent. When I tried the latest docking AP, it would sometimes have extreme difficulty when presented with the perfect docking vehicles and targets in the perfect situation I set up for it. Then it could turn right around and execute a perfect docking in a situation I deliberately made difficult.

Keep us posted.

By no means! You don't target textures. You target meshes. I don't think you're going to run into a situation where a mesh has multiple textures. If there's more than one texture then there's more than one mesh. Let's say I have a massive fuel tank that's made of five separate meshes. Tank side, top, bottom and two 'tank braces' In my ReflectiveShaderModule it looks like this MeshesToChange = polymsh_detached,polymsh_detached1,polymsh And the result is If you need to only apply the shader to a specific section of a given texture, then mask off the parts you don't want reflecting with black in the texture's alpha channel. (be sure to save as tga, 32 bit to ensure preservation of your alpha channel. png won't work unless it's SuperPNG. Maybe.)

thx for that, I'm always interested in any nuclear rocket stuff.