Starwaster

New update for Heat Pumps Heat Pumps version 1.3.1 Numerous fixes and improvements. Most notable is that I discovered a stock bug in which results in added internal and skin flux being cut in half, so I was only removing half of the heat I thought I was. There's also been some work done towards improved analytic support when used with Real Fuels but since then I've discovered things about how KSP's analytic mode works that are making things difficult, so I'm not really sure how well this will work with analytic. So that's a work in progress. https://github.com/Starwaster/HeatPump/releases/tag/v1.3.1

Ok, I put out a new release that only uses the stock density method, 1.4.3 https://github.com/StupidChris/RealChute/releases/tag/v1.4.3.0 That should be the last until next KSP update or unless @stupid_chris has his new version out? Assuming that was what was being hinted at before

Yeah, actually I have the FAR-less changes on my machine that I still need to push out but I've been working on Real Fuels for the past month trying to figure out how to handle boiloff in Analytic Mode when Analytic Mode is more like the old temperature model instead of using heat flux. I'll try to get those changes pushed out the door this weekend. Now, back to bed.

The problems with TweakScale and Real Fuels go beyond just a simple recompile of Tweak Scale and it's been going on for awhile now so it's not going to be resolved any time soon. And that's just the tank mass issue. Engines are another matter. Maybe some day it will get fixed but don't count on it. And it's not even just the compatibility issue between those two mods. Tweak Scale just has too many issues right now with anything other than stock. So you want to do a patch to rescale the parts? Here's a sample of the things that need changing. It only focuses on the physical size and mass, and the tank and engine modules. These are the default values as I see them in my Module Manager cache so you probably have something different. Also be warned that I probably missed something as it is 6am in the morning and I'm going back to bed. Not fully awake right now. This is just to get you on the right track. (and for more than just these two parts obviously) @PART[j_4m_crew]:FINAL // If this is just for personal use then use :FINAL. If you want to try to get it into Realism Overhaul then don't use FINAL { @rescaleFactor = 1 // increase this to scale up the size. Rule of thumb: double the scale = 4 x surface area and 8 x volume @mass = 2.288 // increase this as appropriate. Remember hull surface area = 4x if you doubled the scale. @MODULE[ModuleFuelTanks] { @volume = 4050 // double size = 8x volume should hold true here } } @PART[j_linear_aerospike]:FINAL { @rescaleFactor = 1 // same as above @mass = 5.94 // increasing mass here is probably not as easy as above. Use your best judgement @MODULE[ModuleEnginesRF] { @minThrust = 0 @maxThrust = 656 // increase to match the maxThrust of the configuration the engine is set to. (configurations as in ModuleEngineConfigs) } @MODULE[ModuleEngineConfigs] { // go through each CONFIG and adjust thrust as needed. The MEC configs you have may be different depending on what you have installed // Your best bet here for each engine is to decide on a multiplier that you will apply to all. If you decide on 2x mult for the default config then 2x for all @CONFIG[LqdHydrogen+LqdOxygen] { @minThrust = 0 @maxThrust = 656 // increase as appropriate } } }

Stop using tweakscale and manually rescale the parts using a Module Manager patch. Or stop using Real Fuels.

Your first two sentences contradict each other. It's fixed but it's not fixed? It can't have the negative mass problem fixed and then still have negative mass. You need to articulate your problem better and maybe submit logs. As far as RSS goes, parts created for the stock game aren't going to work as well with RSS unless someone creates some Realism Overhaul configs for those parts. So any problems using this with RSS need to go over to the RO thread and hope they'll agree to add OPT to the list of supported mods or do the work yourself and submit them to Realism Overhaul. (i.e. do a pull request to their Github repository). (and all that implies that you should use RO too if you aren't already)

IIRC.... regardless of what tech node the maneuver planner is unlocked in, it depends on the tracking station being upgraded to particular level. And I think it was because of technical dependencies where the nodes that it requires just aren't exposed in the code until the tracking station is upgraded.

But why is the rum gone???

It was a feature to cut down on space junk Now your Kerbals will have to keep an eye out while on EVA or they might catch a 2 ton engine in the small of the back. (an engine is one hell of a thing to catch in the small of the back, trust me)

@K.Yeon Bug report: OPT_MFT.cfg - all references to :NEEDS[RealFuels] need to be changed to :NEEDS[ModularFuelTanks] or else it will add TWO MODULEs named ModuleFuelTanks OPT_RF.cfg - volumes are too small. They should be 5x the volumes that you assigned in OPT_MFT.cfg (so, the j_4m_crew part should have volume = 10125 as RF volumes are in liters) Also, you should probably add basemass = -1 to all the ModuleFuelTanks modules in the config. At the very least that should be done to the cockpits but probably also to the other parts as well. If not then Real Fuels will scale down the mass and probably scale it down too far. (example, with RF, the type K cockpit is coming in at around 101 kg) It doesn't make sense for the J Inline Boarding Ramp part to have resources added at all. Looking at it when open, it can't store anything in the sides or the bottom. The starboard side is open and can't hold anything and the port side is going to have crew moving through it. The bottom will also be empty. @RazeBerry the above is probably why you are seeing negative masses. When mods report mass changes, they do so as a mass delta so if ModuleFuelTank is lowering masses then it's doing it twice because there are two of that module on each OPT part.

One way it might be achieved is to be subsonic during the majority of your descent. Propulsive braking instead of aerobraking...

20 km? Congratulations, that's almost Curiosity accuracy. I guess 'something seems to be off' with real life aerobraking calculations too. It may well be that MJ2 will never achieve 100% accuracy because that's simply the nature of the beast. I think to get much better than that will require a craft that can get within that area and then use powered flight to proceed the rest of the way. MJ USED to be that accurate on planets both with AND without atmosphere. But that was before our current aerodynamic model. Orientation affects drag so predictions are easily invalidated during the actual reentry. Here are examples of the levels of accuracy we were capable of over the years. Curiosity only achieved that 12 x 4 zone by being able to fly a lifting reentry where it could steer towards the target zone.

There's no reason at all why not.

Anyone who's had problems with premature node execution should check out build # 694 on Jenkins. I tweaked the logic a bit for burn initiation, especially for cases where the cause is MJ2 not knowing burn duration due to unstable ignition situations when used with Real Fuels. (specifically, if you see that burn countdown or burn time read Inf. then this will help)

That's kilopascals not pascals.

Somewhere in there you're getting the dot product of the viewing angle and the normals, right? Are you using the absolute value of that? If not that could be why you're getting those results.

It's too dark where the normals aren't angled right at the camera, or away from it. Spots like that should still be getting light though it would be mostly blue due to scattering.

For future reference, submit logs for sessions that have run only long enough to demonstrate the problem. There are almost 800,000 'look vector zero' messages in there and it slows me to a crawl trying to process that log. (admittedly that's partially my fault because I tried to delete them to make finding the real error easier to do and it locked up Notepad++) I'll let you know when I find something. @bertibott Looks like you're missing textures. You needed to download those separately. Look at the first post again, you have a choice of different resolutions to choose from.

I need to know more about what parts you used, what engine, what tank, etc. One thing I can tell you is that 45km periapsis is an awfully shallow reentry. Your shield will do a slow bake and deplete itself long before you can brake enough to matter. Try lowering the pe to 20km. I can guess about the rest but like I said, without knowing specifics about your craft design it's just that. A guess. Stock conductivity is extremely high. I'm currently engaged in a reentry of a craft similar to what I think you're using and right now the engine is conducting into the tank at a rate of 5.73 kW/m K. If you're not familiar with conductivity expressions, that's 5.73 kilowatts per square meter per degree difference Kelvin. For comparison, aluminum has a conductivity of 250 W/m K. Not many materials have conductivities that are in the kilowatt range, at least not as far as common structural materials. So what's probably happening is that your tank is transferring that heat into your decoupler and from there into the heat shield. If it's that much of a problem I might have to look into lowering the global conduction factor. (which I've actually done in older versions of DRE; it was a simple way of increasing the deadliness of a reentry since parts couldn't easily get rid of the heat that they accumulated)

Interesting. Did any of the round robin code survive? (basically cycled crew to the back of the list after they were recovered to ensure that every Kerbal had a chance at flight experience)

@PickleBranston actually it was worse... they were hitting double.MaxValue

The author hasn't even been by in half a year. I'd say this is stillborn.

The main one being that I want to change how DRE implemented damage works. i.e. fire damage. Currently, the skin itself gets damaged from being on fire and if damage reaches 100% then the part gets destroyed outright. What I want to happen instead is that the more damaged the hull is, the more heat is let through into the interior. Thermal radiation flux and convective flux would be admitted directly into the interior. (because it now has a big freakin' hole in the hull) The easiest way to do that is that if there's a hole in it then there's a hole in it... in every direction. A little more work is involved in doing it the way it should be done, which is directional. So... it's the front part that has a hole in it. Or the aft part. Or portside.... I actually have a rudimentary form of that already but there is no visual representation of that so the player will have no way of knowing that there is a hole in their ship.

Because there are changes I wanted to complete before an official release. They haven't been completed so there hasn't been an official release. (though I did take the last release out of pre-release status so it will show up on CKAN.

As long as they are in the GameData folder or one of its sub folders it will be read by Module Manager