Fractal_UK

No no, more radiators are always good. More radiators means that the average temperature of all the radiators goes down, lower average radiator temperature means more efficient generators.

The temperature and the various powers and power dissipations have slightly different effects. If you want to be totally safe against overheating, you need to be able to dissipate waste heat equal to your thermal power though in practise you'll always be safe with less than this, especially as you get better generators. The temperature, on the other hand, effects the carnot efficiency of the generators. The reactor temperature is the "hot bath" and the radiator temperature is the "cold bath". The carnot efficiency is 1 - TC/TH. In other words, you want a big difference between the reactor and radiator temperature - hot radiators dissipate far more heat than cool radiators but they also harm generator efficiency if the temperatures are close. The generators don't generate power at the carnot efficiency however, they generate it at a percentage of carnot efficiency and that is the efficiency rating that you see in the VAB. On the generator GUI, the efficiency readout takes both into account. In other news, 0.8 is almost ready.

The action group options for reactors are there because some reactors are capable of being shutdown and restarted but the nuclear reactors are not capable of this, nuclear reactors will spool down to a minimum of 30% when there is no significant power draw. If they shutdown, they can only be restarted by an EVA Kerbal. The toggle button on the science lab is for the lights, while the activate and deactive animation names can be changed on a ModuleAntimateGeneric, e.g. to "Lights ON", I don't believe this is the case for the toggle option unfortunately. Maybe someone can correct me on this though. Perhaps I'll integrate the lights animation into the internal science lab animation process at some point. The magnetometer will have action group options in version 0.8. When you re-installed, did you delete the old folders? Worth trying if you didn't. Also have a look at the part.cfg and make sure the ModuleScienceExperiment PartModule is in there. I don't know why it wouldn't be, but if you're not getting the option, it's worth checking.

Unfortunately, that doesn't work because the Megajoule resource manager prioritises the production of ElectricCharge. In other words, if the electric charge bar is set to say 5/1000 in one frame and 6/1000, you can take the delta value, consume 1 unit of EC, produce 0.001MJ and immediately the Megajoule resource manager goes "ElectricCharge bar isn't full - convert all available megajoules into ElectricCharge until the bar is full!" and you have a load of code, the net result of which does absolutely nothing. On the other hand, if the ElectricCharge bar is at 1000/1000 and you measure the change frame by frame, the change is 0 even if you would actually be accumulating charge were the bar not full. An accumulation of Megajoules can only occur when the EC bar is already full and that is the fundamental problem. The reason that this is difficult to do is because it requires many of the same features that the resource manager actually provides to avoids problems like this.

Did you add any other mods between making those changes? If you're close to the memory limit even a tiny change could be significant.

Yes, it's possible. It can be done in a variety of ways, e.g. by converting an amount of EC specified by the user into Megajoules, converting all the EC in the bar into Megajoules (though this is a bad idea because it might lead to frames without control over the vessel) or by using a variety of schemes to detect the flow of EC that is being produced and converting that exact amount into Megajoules. The last option is, in many ways, the best but also the most complicated because the game has no consistent mechanism for getting that information. Such a system would need to check for EC from solar cells and RTGs seperately and likewise would also need schemes to detect EC production from modded parts - unless those parts use stock PartModules to do the generating. The fact that there is no ideal way to implement it is the major barrier to this being in the mod already. It will happen, I mean there is really interesting science to be done in the outer solar system. Solar power just isn't very practical at those distances from the sun if you hope to run a high powered science package, nevermind things like electrical propulsion systems. When your options are nuclear or nuclear, the decision is (hopefully) a little bit easier to reach - though I'm sure there would, disappointingly, be some people who would rather just not do the science than use nuclear power to do it.

Most of the engines accessible around the upper parts of the stock tech tree tend to be quite low thrust and high Isp so they're alright when you're in space but they don't really help you get off Kerbin. It is probably a good idea to first design a fairly good medium-heavy lift vehicle to help you lift some of the big reactors into space. The power/weight ratios of the reactors go up quickly with size, so the bigger ones produce disproportionately more thrust. If you're struggling to get them to Jool though, try landing some on the Mun or Minmus. You get a multiplier to your passive science for being landed on the body, so landing some there will at least give you some. Duna and Eve are easier to get to than Jool and will also give you more passive science than the Mun/Minmus. The current system isn't ideal and it does constrain design but only in a absolutely tiny number of circumstances. I've said before that if you want an ingame justification for the difference between the two resourcs, you can consider Megajoules as AC Power produced by large generating equipment and ElectricCharge as DC power created by the likes of solar cells and thermocouples. Generators are equipped with rectifiers to supply whichever is needed but solar panels and such aren't by default equipped with inverters to provide AC power. In reality, as RadHazard suggests, this isn't purely a game constraint of design, it's a practical one as well. Megajoules (as well as ThermalPower and WasteHeat) use a custom resource manager in the mod which is far more advanced than the stock one, this is what makes the generators adapting to power demand possible. The resource manager has lots of information about the current power supply and demand situation and can also make decisions about prioritisation of power if its in short supply and generally ensure as little power is used as possible. This information simply doesn't exist in the stock resource system. I could actually use the resource manager with ElectricCharge but the problem with doing so is that any stock device that produced ElectricCharge would not be detected as a supply (this is a big problem because then that power might as well not be generated) and anything that consumed ElectricCharge would not be detected as a demand (this isn't such a problem provided there aren't lots of components doing this). Anyway, it's best not to introduce two incompatible systems, its safer to keep them seperate. Hopefully someday we'll see an improved stock resource system, it's one of the most needed features in the game at this point, particularly for modders. If I ever adapt the resource manager to support others types of resource transfer, rather than just ALL_VESSEL flow, I'll probably release it as a standalone thing for other modders to make use of.

If you already have hexcans installed, you don't need to use the one bundled with Interstellar. Greys may have released a more up to date version - I should check this before the next release of Interstellar. Mmm, I'm not entirely sure, it's just based on a dot product so it isn't something that's readily configurable in the way that you suggest. There are some options mathematically but they would serve a purpose only as fudge factors rather than permitting anything feature-wise. The new code seems to perform better in terms of quickly detecting new microwave sources, rather than giving you those funny spells where it won't detect them. I suspect you'll find the microwave systems much improved without any changes to their angular mechanics. We'll see how it goes and also see about some kind of small re-orienting dish. In other update news: I've replaced the current fuzzy inverse square behaviour of the solar panels with a true inverse square law that scales to the current size of the solar system, i.e. you can use it in both the stock KSP system and also in the Real Sized Solar System mod. I'm also well over halfway through the planetary resource maps. I think I've finally killed the remnants of the asymmetric jet thrust bug. I'm hopeful of a 0.8 release sometime this weekend or not long after.

You actually need fuel lines from the fuel tanks to the converter. Because it's a creation of fuel rather than a use of fuel, as the engines are, the flow direction works in the opposite direction to what you would expect.

The big advantage of this new system is that you'll be able to concentrate all your solar energy satellites into a low Kerbol network and deploy only relays in orbit of local bodies, to let you receive power at night and such. A microwave receiver that points directly at the transmitter is very possible, it just needs a suitable model with an appropriate pivot and the code is fairly straightforward. The existing receivers don't have such a capability, so can only point in a fixed direction. The thermal receivers coming in 0.8 are also perhaps a little more forgiving in that they can receive power side on - but from any side.

It is actually possible to relay power but the conditions under which it can happen emerge rarely in practice. In light of this discussion, however, I've decided to push forward the long-awaited rewrite of the microwave power system. The upshot of these changes is that relays will become a seperate option for any vessel with both a transmitter and a receiver. They perform no game function other than to allow line of sight tracing via a single relay. So, you can transmit power vessel->vessel or vessel -> relay -> vessel but not vessel -> relay -> relay -> vessel (or more). Proper networks with large numbers of relays should become possible as a result. The new system uses far less file IO too, which is something I was worried about in the old one.

It's difficult to get enough power to launch with satellites, though it is possible. Some people have built constellations of low Kerbol orbit satellites with enough power to do this type of thing, it's not really practical with Kerbin solar satellites though, you'd simply need too many. A constellation of nuclear powered satellites around Kerbin will be very powerful, however. In the next update we also have microwave thermal receivers coming, which will let you receive microwave power as thermal power to run the thermal rocket. Those engines have much lower specific impulse than their electric counterparts and consequently far higher thrust. With the proper infrastructure, these are very capable of facilitating more efficient launches. I'd definitely suggest deleting everything in the WarpPlugin folder, then redownload the mod and re-install it, occassionally files can become corrupted for whatever reason. Your install location looks to be correct.

In Version 0.8, I'll be introducing a new WarpPluginSettings.cfg file. This might be of interest to people who want to ensure compatibility of KSPI with other mods. This was written mainly with MFS Real Fuels in mind. At present I have a compatibility file with all the config alterations to make the engines use the appropriate propellant but the internal plugin functionality, e.g. for water electrolysis, have hard-coded resource names so, at present, you get LiquidFuel and Oxidiser from water instead of the more proper LiquidH2 and LiquidOxygen. I don't like that, so I decided to make this totally configurable. It looks like this: WARP_PLUGIN_SETTINGS { HydrogenResourceName = LiquidFuel OxygenResourceName = Oxidizer AluminiumResourceName = Aluminium MethaneResourceName = LqdMethane ArgonResourceName = Argon ThermalMechanicsDisabled = False } This only affects internal plugin code. Propellant files and, in certain cases, part.cfgs may also have to be altered to ensure complete compatibility. Regardless, this is now a matter of simply altering .cfg files rather than code changes. Also, if you don't want to play with thermal mechanics, you can set ThermalMechanicsDisabled to True. This stops the production of WasteHeat but a generator will still require 1 radiator to be attached because it still needs something to derive a thermodynamic cold bath temperature from.

I'll have a look at making another scaled down version then, I think it should still offer plenty of cooling capacity for the smallest satellites. Additionally, I'm about 1/3 of the way through the celestial body resource maps now but I have, at least, done the difficult ones (Eve, Kerbin and Laythe). Once the rest are done, the release shouldn't take long to finalise.

The only advice I can give you on using the nuclear reactors + thermal rockets is to use LiquidFuel and use the biggest reactor possible. The reactors scale non-linearly in power output with size, all of the basic ones draw quite heavily on real nuclear reactor designs that were tested for space travel. The smallest is drawn from SAFE-400, a 400KW thermal, 100KW electric nuclear reactor that NASA is currently experimenting with. This one I have scaled up somewhat to try and make the smallest size a bit more useful. At the top end, we go up to Phoebus-2, which I believe was the largest nuclear reactor ever built at just over 4GWth and would have been used as an alternative Saturn V upper stage. This would've been a little larger in volume terms but only marginally heavier than the Aegletes-2. Anyway, all of the nuclear reactors have better Isp than the stock versions at 915s compared to 800s for the stock nuclear engine but the thrusts start off very poor and become increasingly good as you go to the larger sizes. You're therefore best off using the smallest reactor solely for power generation, the 1.25m for power generation and/or aircraft thermal jets and the two larger ones can do all that plus some spacecraft propulsion. Aegletes-2 is the one that is designed to be a really competitive spacecraft engine. In 0.8, you can accentuate some of these advantages using Thorium reactors. Thorium is better suited large exploration type ships because it requires more reprocessing to remove neutron absorbing elements from the core but I have also discovered the working fluid can be higher temperature than Uranium, and that translates directly to better specific impulse. Thorium will push your Isp up to 993s and thrust up by ~27%. Aegletes 2 would therefore do, with LiquidFuel propellant, 849kN @ 993s Isp, which pushes its TWR just ahead of the stock LV-N, in addition to the superior specific impulse. Yes, you're probably right. Do you think that radiator has a place as it is and I should make a second, small version or do you think I should simply shrink the current part? Dr Nuke made these charts for every planet: Charts

0.8 is now feature complete so the vast majority of the work is now done. The remaining work lies in creating resource maps for some of the celestial bodies, testing (+bugfixing) and gameplay and balance tweaks. The final release will depend on how smoothly this all goes but we're certainly nearly there.

The fact that the spacecraft reaches thermal equilibrium with the environment is precisely the problem - indeed your whole argument relies on the spacecraft not reaching thermal equilibrium. It doesn't matter whether your computer chip or your solar panel is producing the heat because heat conduction is going to dominate the heat transfer process within your spacecraft, in other words, if your solar panels becomes warm enough to cause harm to your vulnerable components, so do the vulnerable components themselves, whether the solar panels themselves get damaged is irrelevant - if the solar panels are hot enough heat to cook your satellite's CPU, your CPU will be more or the less temperature - at which point goodbye space probe! Yeah, your solar panels aren't damaged but your probe is just as useless as if they were. I think you are being mislead by thinking of something analogous to a battery powered spacecraft. A battery powered spacecraft functions as you describe because the battery will do nothing when there is no power draw. A solar powered spacecraft is totally different. Your spacecraft does not stop absorbing energy from the sun just because you have no power draw and for most electronic systems where most of the initial electrical power ends up as Waste Heat, it makes very little difference whether the solar panels are deployed with no load or whether the equipment is running. Sure, the second case produces heat in a more localised area but you hope that your heat management system is capable of moving that away from that particular component and spreading it over a large area quickly to try and dissipate it. If this isn't the case and you have individual components overheating, you have simply designed a rubbish spacecraft, just as surely as someone who tries to run a top of the range CPU in their desktop computer without a heatsink. So yes, I'm making an approximation but my approximation is that of a well-designed spacecraft that spreads heat evenly throughout its heat rejection system and maintains thermal equilibrium rather than a badly designed spacecraft that produces localised overheating. Edit: In reality, you have a few more options because you are not obliged to point your spacecraft solar panels entirely at the sun, you can optimise the angle for better heat rejection if necessary. Unfortunately, in KSP, this would require a whole new set of solar panel code.

I'm probably going to add an option to the Kethane converter that permits conersion from Kethane to Methane at high efficiency. I don't, however, want to make this a Kethane engine because I can't neccessarily assume that everyone has Kethane installed.

This stuff is more KSP "maybe in a year or two" than KSP "Interstellar" but all new technology is exciting technology, in my opinion. So, I bring you the latest work from that renowned Kerbal entrepreneur Elon Kerman. This is a new rocket engine that instead of using LiquidFuel+Oxidiser, it uses Methane in place of the LiquidFuel. This is advantageous because Methane is cheap and easy to handle compared to traditional rocket fuels, it also offers slightly improved specific impulse compared to most lower stage engines but the fuel tanks do take a bit of a hit in terms of overall capacity. The real reason that a Methane engine is really interesting though is because of the Sabatier reaction: CO2 + 4 H2 → CH4 + 2 H2O It describes a mechanism by which we can use a small amount of hydrogen, mixed with some carbon dioxide to generate methane and water. This is of great interest because the atmosphere of Mars (and presumably by analogy Duna) have atmospheres rich in carbon dioxide. This means that by taking a small amount of Hydrogen with you, you can react it with ambient CO2 to generate Methane and Water. The water can then be electrolysed to give you Oxygen and 2/3 of the amount of Hydrogen you started with. You can thus repeat the process until all the hydrogen is sequestered way in the methane and you have only methane and oxygen. In this way, you can carry with you to Duna a small amount of Hydrogen mass, source the carbon dioxide locally and produce rocket fuel equivalent to 20x the mass of hydrogen you brought along with you. That's great if you don't want to carry all the fuel with you (which of course you don't!). So, what do we have in game? Well, to start with a beautiful new engine created by ZZZ (and a really-not-so-beautiful fuel tank textured by me - hopefully 0.23 and tweakables will improve all this!) We also have a nice new option on the Refinery to perform a Sabatier ISRU process! This ship isn't exactly the best designed so I apologise but it does the job. You can hopefully just about see LqdMethane and Oxidiser going up and LiquidFuel going down (very very slowly).

Yeah, there was something weird about the code I was using to limit the refresh rate in the 0.7.X versions. I'm not really sure why it happened, it was an intermittent problem with no apparent trigger, all I can say is I replaced the code for 0.8 and I don't get that issue anymore.

Sorry but this is completely incorrect with respect to "real life physics", a spacecraft that has solar panels deployed but is not using any power is in absolutely the worst position for production of waste heat. The photon either hits the solar panel and creates a useful electrical current or it hits the solar panel and creates heat. In the case of zero applied load, you effectively just have a black body with some albedo receiving power radiated by the sun. If you do have a load, some of that energy instead goes on promoting electrons from the valance band into the conduction band and later doing useful work, only the left over energy above this band gap and the energy from photons of inappropriate frequency is wasted as heat. It is easier to think of the devices you carry on your spacecraft not as sources of WasteHeat but instead as a way of getting rid of it, the Plasma Engine is a good example. The plasma engine is 72% efficient at turning electricity into kinetic energy for your spacecraft, that 72% therefore becomes something useful (hurray!), the overwhelming majority of the remaining 28% does become heat. Many devices aren't anything like this efficient and ultimately turn much of the electrical power they use into heat anyway but you're still better off than you would with that little bit of useful work done than you are with your solar panels pointed at the sun and doing absolutely nothing. So, if you don't want heat production, fold the solar panels away. The passive dissipation is actually fairly generous, it's modelled by making some generic assumption about spacecraft surface area based on its mass. Regardless, predictably structural parts not designed for it are far inferior as radiators than parts that are designed specifically for that purpose, all but the tiniest of low power output probes have specialised radiator components, all you need is one tiny radiator for a small solar powered probe and it isn't a problem anymore. In reality things are quite a bit more complicated and you may need to use stored energy to heat the spaceprobe when its in shadow to keep equipment within a certain range of operating temperatures in addition to dissipating heat when in sunlight. It is 1% efficient at turning energy into mass but since we have to produce particle/antimatter particle pairs (due to lepton and baryon number conservation), only half of this 1% can be antimatter. So it is 0.5% efficient at the production of antimatter. Basically, unless you can collect it in orbit, using an antimatter factory is a way of using a huge amount of energy to store a moderate amount of energy into an extremely high density energy storage medium which you can use to get far more power for a given mass than any other alternative. You are basically paying a huge cost in energy for short periods of ultra-high power output, which are nevertheless incredibly useful.

Can you try building one on the launch pad just the same and seeing if it works there? I've seen problems like this mentioned a few times but I have so far been unable to replicate it, which means either I'm doing something wrong or there may be another mod that is interfering with normal operations, do you have any other mods installed, and if so, which ones? Did it stop working when you docked the top section or did it work for a while with that attached? Also, just to check the obvious things, you still have plenty of antimatter, right?

Yes, there will be cannisters for both Uranium and Thorium - I've decided that these will be half full in the VAB. Making them completely full is problematic because it prevents you from switching between Uranium and Thorium - since the reactor starts fueled up with Uranium and you need somewhere to put it when you swap the fuel types, otherwise it won't let you swap. Reprocessing will also be improved but you will need some storage tanks with your reprocessing facilities to store the depleted fuels they produce.

Yes, loading it from a ConfigFile is an option. That said, I tend to refer to the planets in my code by their flight globals index, which I think is hardcoded? In which case, it wouldn't be a problem. (The only exception is in the resource map code, which is actually quite handy - I could see the use for having different maps for Kerbin and Earth, especially if you alter the terrain in future). You know, it's really frustrating the devs didn't make FloatCurve.evaluate() a virtual method, if they had, we could have proper inverse square rather than the very approximated behaviour we have at the moment.

Nope, not in general. You might need to perform some minor aesthetic alterations to craft with nuclear reactors but functionally everything should carry on working - additionally any nuclear reactors you have in space at the moment will be automatically topped up with fuel as if they'd just been launched, this is to avoid breaking issues.