Fractal_UK

Nope, everything that is required is included in the download. It is compatible with Kethane though and you can use Kethane as a thermal rocket propellant if you have it installed but it doesn't matter if you don't, Interstellar includes a "LqdMethane" propellant too.

More about Version 0.9 Version 0.9 shall feature a new part which both serves as a resource prospect for resource extraction and as a new science experiment. This part shall be a Gas Chromotography Mass Spectrometer and it will give you comprehensive details about the atmospheric composition of the current celestial body - this equipment needs an atmospheric sample in order to operate so you won't be able to just fly into a sphere of influence and take some readings, you'll therefore have to actually drop probes inside the atmosphere in order to get a sample to analyse and figure out the abundances of all the gases. Once you do that, you'll be able to collect readings as from any other science instrument. Additionally, you can also use this part in preparation for sending out atmospheric scoops, to see what kind of resources it might be productive to extract from the native atmosphere.

The efficiency that you see is different from the theoretical efficiency. So, 24% is the maximum for the unupgraded generator but it can be a lot lower. 60% is the maximum for the upgraded generator but again, it can be lower. The formula is (1-TC/TH)*generator efficiency, where TC is the average temperature of your radiators and TH is the temperature of your reactor. The efficiency you see will sometimes go up when you timewarp because the reactor and generator will run at 100% until they have filled the Megajoules and ThermalPower bars, that takes a bit of time, after a while, when those bars are full, the reactor and generator will drop down to low percentages of their maximum power output - which produces much less heat and allows the radiators to cool. When the radiators cool down, you get much higher efficiency. The 4%, however, is actually a bit lower than it should be possible due to a slight error with reactor temperatures in version 0.8 and I don't think you'll ever see lower than about ~10% efficiency in version 0.9. To be totally honestly, I don't know if that is possible - it'd be easy to give you a correct specific impulse for the plasma engine, which is enough to calculate an accurate delta-v but there is almost no chance of you getting an accurate TWR in the VAB, there are simply too many things to consider. For all the difficulty of doing it for the thermal rocket - the plasma engine is 100x worse.

I'm fairly sure this is the same problem that someone discovered with regard to another mod in the previous page. The fix should be in the next update. Generally you don't need to upgrade parts - they upgrade automatically and that's probably what's happening to you. Only parts that are leftover in space need to be upgraded, new parts will be automatically upgraded in the VAB.

Good news in version 0.9 for people who play with MechJeb: In version 0.9, you will be able to see thrust and delta-v stats for all thermal rockets in the VAB as well as in flight, I'm certain this will help you plan your missions more effectively. The thrust performance of many of these engines is difficult to predict and does vary on conditions on flight, which is why this feature was tricky to include and has been so long coming, I can't guarantee that you will get exactly the figure shown in the VAB but in 99.9% of cases, the numbers will be correct. The VAB predictions do, of course, take into account factors like reactor upgrades that massively swing performance.

In sandbox mode, all of the technologies are upgraded by default. You need to get quite a lot of technology advancements before the generators upgrade in career mode, that is why you are seeing different efficiencies. With the basic generator, it's not possible to get more than 24% efficiency. The upgrade makes them up to 60% efficient, you can see why the techs upgrade in the first page of this thread or on the Wiki. Radiators and reactors can also change efficiency, ideally, you want reactors to be high temperature and you want your radiators to be capable of dissipating lots of heat but only doing a fraction of it so they are lower temperature. The problem is: fusion reactors need some electrical power to run the laser that heats the fusion fuel. You have no generator, so the fusion reactor is stopping. Add a generator to at least one of your reactors and it will work fine.

The problem you are experiencing here is the fundamental terribleness of the stock KSP resource system. You only have 1235 units of ElectricCharge storage on your ship, so whenever a part.RequestResource() comes in that has a value greater than 1235 (either supply or demand!), it will return 0. There is nothing I can do about this - this is the whole reason almost everything power related in the mod uses my own Megajoules resource rather than ElectricCharge. Put a lot more batteries on your satellite and it will work.

Have you tested this with more than the one craft? I've just re-checked the code and there is nothing wrong with the way it is checking multiple panels. I can't see any reason why only one panel's power would be transmitted and it works perfectly when I test it. Here is another one on the launchpad 18KW * 6 panels = 108KW transmitted. Works perfectly.

The curve is updated every frame at the same time as the WasteHeat display. You can see in my picture on the previous code that 4 solar panels are working correctly in terms of energy production. Can you try an install of just the base plugin dll and see if it works properly then? Antimatter parts have had new models for ages, the nuclear ones arrived in 0.8 - you can see a picture of all 4 sizes of nuclear reactor in the first thread. It's fixed to about the limit it's possible to fix - it's possible to fly a 3.75m rocket stack into orbit without any struts at all but I can't guarantee that parts will be totally wobble free, KSP and big parts don't get along all that well. I have heard good things about ferram's joint reinforcement plugin, a lot of people over at the Real Sized Solar System are having good results with realistically sized rockets, which can be much larger than 3.75m. Unfortunately it seems he's right. It's caused by the module that determines capsule radiation, I'll fix this problem for the next update.

Yes, to be honest, I don't know why that isn't working. Are your solar panels generating waste heat properly? The change is made from that PartModule, so if the solar power curve isn't working, it's quite likely solar waste heat won't be either. My Low Kerbol Orbit test satellite is at a similar altitude to your solar satellite. The stock solar panels start at 18KW generation, here I'm getting 7MW per panel, which is 389x the expected Kerbin output. Taking into account my altitude of 417,834,000m (and Kerbol's 261,600,000m radius) and Kerbin's orbital radius of 13,599,840,256, we expect (13,599,840,256/(417,834,000+261,600,000))^2 = (20.01..)^2 = 400.65x the output at Kerbin orbit - which is very similar to my 389x figure I'm achieving in practice, the difference can easily be explained by my solar panels being not perfectly aligned.

You are mistaken, there is nothing wrong with this code. This code gets a raw power value from the solar panels and displays it - there is no inverse square multiplier quite deliberately. The solar panels already take distance into account themselves so why would there be another inverse square factor displayed? The solar power part, however, contains the inv_square_mult because it is designed to scale the energy that will be stored in the microwave persistence code to what it would be at Kerbin orbit. That is why dividing by the inv_square_mult is giving you a smaller value. This is because there is no guarantee that the satellite will be at the same place, in the future, as it was when you turned the transmitter on so Kerbin is used as a common reference point and the receiver will scale the energy based on the transmitter's current position. The problem you have detected is that the panels are indeed using a stock curve, rather than the corrected curve that I included - I am not entirely sure why this is the case but that is why you're seeing 10x the power in the sun's orbit because 10x is the maximum amount of power that the stock panels can ever produce. The problem is with the solar panels not the transmitter, the transmitter code is fine.

Speaking of radiators - good news for B9 Aerospace players in 0.9. I've decided to finally implement B9 cargo bay doors acting as radiators - based on the current cargo bay doors, because they are using a non-stock animation module I cannot make them make them like deployable radiators that work only when the doors are open, this is a shame but it may be that this will be possible in the future depending on what 0.23 brings and the changes that bac9 makes as a result of it. I'd never really considered building a 3.75m antimatter powered aircraft before but actually it works rather well, the largest reactor has poor TWR compared to the smaller ones but good enough specific impulse that using LiquidFuel all the way to orbit isn't really a problem and the lift from the wings helps to offset that lower TWR. I've built a few rockets using those 3.75m reactors but this might be a better way of using them on the ground. Of course, it's among the latest of late game things you could do but still a potentially nice cargo platform. This is all very appropriate because version 0.9 is set to contain quite a few changes with regard to the aerospace side of KSP, so those of you who are interested in spaceplanes and the like should enjoy the update. So far, I've also managed to coax a fair bit more atmospheric performance out the thermal turbojets, the changes are: Velocity curve has been tweaked to affect performance almost exclusively at high speed rather than affecting the low speed regime - this means that all thermal turbojets will have more thrust at takeoff and make those fission powered jets a bit more flyable. This is a needed change because unlike stock engines, my engines also perform worse in the low atmosphere due to lower specific impulse so the current system is like a double penalty. The atmospheric limit code no longer tops out at ~80-85%, which again means more thrust for everything that flies with a thermal turbojet. Detection of flameout has been considerably improved so that the engines aren't hampering themselves when more thrust should be available.

Did this occur using an identical craft to one previously tested on another machine or did the design differ?

I have already come to the conclusion that 0.8.3 is not worth investing the time in - it's essentially done but I'd rather spend the time I might spend on finalising a 0.8.3 release on content for 0.9. So, I will release version 0.9 after 0.23 is released. I've been doing a lot of preparatory work to ensure that all the basics for 0.9 are in place, when 0.23 releases, I'll be performing some quick tweak(able)s and I hope to be able to release the 0.9 update fairly soon after. Pencil in the 18th for KSPI 0.9 and by some combination of sleep deprivation and caffeine, I'll try to make it happen.

You're probably right that there are many better schemes that I could use for passive dissipation - the problem is temperature. Unless you're getting the part to really high temperatures, it's just not going to dissipate a large amount of heat - indeed the whole point of having radiators is that your spacecraft doesn't reach some ludicrous temperature. My fear is that by making a more comlicated simulation of passive heat loss, I'll start with the answer 2 and end up with the answer 2.173 when the answer really needs to be 500 to make a difference. I'm trying to adopt a policy of, if it doesn't matter, don't simulate it accurately because then you won't see a performance hit for calculations that ultimately make no difference. Instead, you'll have a nice quick calculation that gets the job done and gives you an answer fairly close to the correct one. Interstellar does quite a lot of calculations so I need to place fairly stringent requirements on what is important and what is not, otherwise slowdown will occur - I already worry about this because most of my testing is done on quite a powerful machine, so I worry I'll end up releasing an update that will kill framerate elsewhere. If you're reading this - tell me straight away if this ever happens!

They already have this, the rate is very small because components that aren't designed to radiate heat aren't very effective at it but the passive radiation is there. It depends upon craft size so large craft with little power generation capacity are the place to be for passive cooling. I also just added today convective passive cooling, which is way way more significant and will make a big difference toward stopping overheating in atmospheres.

It's possible but I'm not 100% sure about what I want to do about it, exploding panels and such like seems a bit excessive so it might be more on a minor malfunctions sort of level if I do anything. If ships are able to operate fine with just those small solar panels and 100% WasteHeat, it doesn't matter all that much. I might up the passive dissipation a bit so that it's rarely a problem, those small panels are so tiny they wouldn't need much cooling (except perhaps on a similarly tiny probe). It's important to have the WasteHeat mechanics on solar power in general because it's in theory possible to generate a huge amount of power using low-orbit solar arrays and microwave transmitters, besides it works well with everything else generating heat and it makes sense. Real satellites powered by solar panels most certainly have to worry about dissipating heat. Thinking about it though, I should probably add passive convective dissipation (in addition to passive radiative dissipation) so that people's existing panels in atmospheric environments don't overheat because that's a bit silly. Edit: Passive convection done.

This isn't quite true - the small panels have had their panels tweaked just the same as all the other panels and they do generate heat. The only difference is the static solar panels are coded not to "retract" which is something they are apparently capable of despite the lack of animation - it just stops them generating power. Anyway, I don't want static panels "retracting," because it just breaks the panels silently without informing the player. Basically, the static panels need some different type of consequence putting in for when they cause overheating.

Looking at this, I reckon the best solution is to switch from checking generators for power to transmit to checking reactors and their attached generators, then I can discard all the data from those inline receivers. That should kill off that exploit entirely. I'll try this out.

You're right - I've found the issue. I should be using supplyManagedFNResource rather than supplyFNResource in the thermal microwave code, otherwise the thermal receivers will not respond to demand in the smooth way that a normal reactor does. I wish everything was so simple to fix

EC useage is too high on 0.8.2.1, that's why you're seeing it when you go back to it. The dev version you are using fixes the problem partially but doesn't have a complete fix (EC is actually too low on there) as my latest build does. This will all be fixed in the next version.

Time to write a little bit about some of the features coming in 0.9: The new fusion reactors are going to see a bit of a bit makeover and have their capabilities expanded, this will come through drawing a distinction between mainly neutron producing fusion reactions (such as Deuterium/Tritium fusion) to entirely charged particle producing fusion reactions such as (Helium-3 fusion). The big advantage of a fusion reaction that produces lots of charged particles is that instead of using some kind of heat difference to generate electrical power, you can directly extract electrical energy from the motion of the charged particles making conversion extremely efficient. These second and third generation fusion fuels are only available with the upgraded fusion reactor because it is significantly harder to achieve the neccessary temperatures and pressures to attain fusion with these fuels. 0.9 will see three options for fusion fuels: Deuterium/Tritium fusion: The one in the game now. Produces 80% ThermalPower and 20% charged particles. Deuterium/Helium-3 fusion: A reaction that at first glance looks to be aneutronic but actually generates quite a lot of neutrons via Deuterium/Deuterium fusions. Produces 21% ThermalPower and 79% charged particles. Helium-3 fusion: Produces 100% charged particles. Why is this interesting? Well, as I said, charged particles can be used to generate electricity much more efficiency than heat can be so you'll have new generator options that require charged particles instead of thermal power in order to produce electrical power - and they will do it at 85% efficiency! That means if you don't need to power a thermal rocket with your reactor and you only need the electrical aspect then these new charged particle producing reactors will be unrivalled in their efficiency. Want to power a DT-vista engine or a plasma thruster without producing a ton of waste heat? This is the place to be. You can also mix and match charged particle generators and thermal rockets - for example with a Deuterium/Tritium reactor you could attach a direct conversion electrical generator and a thermal rocket, you can run your engines at full power, using 80% of the power *and* run an electrical generator, creating power at 85% efficiency, with the 20% charged particle power. This is proving to be a surprisingly useful combination in my testing! Alright, so how do I get Helium-3? This is the tricky part! Helium-3 is extremely rare but fortunately one of the fusion fuels you already have, namely Tritium, is unstable and decays with a half-life of just over 12 years. The decay product? You guessed it, Helium-3. Thus, as you spend time in space, you'll find that any Tritium you brought along will tend to decay into Helium-3 which you can collect and use for your second and third generation aneutronic fusion reactors. In the future, it will also be possible to rove around the polar regions of various moons gathering up Helium-3 but I need a very specific part model for this purpose, which I don't presently have but you can rest assured that this system has plenty of scope for advancement.

There don't appear to be any errors at all in this version, can you descrive these functionality and staging bugs in more detail?

There is nothing wrong here, all the Megajoules are being used by the Alcubierre Drive to charge up its supply of ExoticMatter. If you click "Stop Charging" on the Alcubierre drive, the Megajoule bar will begin to fill up. ThermalPower is likewise not being produced because the generator is using it all. Edit: The alcubierre drive also gets low priority on any power so anything else you try to do with your Megajoules will get a chance at the power before the Alcubierre drive gets the leftovers.

You sure this only happens with Interstellar installed? There are some errors on loading to the main menu: getObtAtUT result is NaN! UT: 112.659999999996 ObT : NaN M : NaN E : NaN V : NaN Radius: NaN vel: [NaN, NaN, NaN] AN: [NaN, NaN, NaN] period: NaN [OrbitDriver Warning!]: Apollo Station had a NaN Orbit and was removed. getObtAtUT result is NaN! UT: 112.659999999996 ObT : NaN M : NaN E : NaN V : NaN Radius: NaN vel: [NaN, NaN, NaN] AN: [NaN, NaN, NaN] period: NaN [OrbitDriver Warning!]: Apollo Station had a NaN Orbit and was removed. later [HighLogic]: =========================== Scene Change : From SPACECENTER to FLIGHT ===================== (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) NullReferenceException at (wrapper managed-to-native) UnityEngine.Component:InternalGetTransform () at UnityEngine.Component.get_transform () [0x00000] in <filename unknown>:0 at SpaceCenterCamera2.UpdateTransformOverview () [0x00000] in <filename unknown>:0 at SpaceCenterCamera2.UpdateTransform () [0x00000] in <filename unknown>:0 at SpaceCenterCamera2.Update () [0x00000] in <filename unknown>:0 and Cannot find InternalPart 'cupolaInternal' (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) ArgumentException: The thing you want to instantiate is null. at UnityEngine.Object.CheckNullArgument (System.Object arg, System.String message) [0x00000] in <filename unknown>:0 at UnityEngine.Object.Instantiate (UnityEngine.Object original) [0x00000] in <filename unknown>:0 at Part.AddInternalPart (.ConfigNode node) [0x00000] in <filename unknown>:0 at Part.CreateInternalModel () [0x00000] in <filename unknown>:0 at Part.SpawnCrew () [0x00000] in <filename unknown>:0 at Vessel.SpawnCrew () [0x00000] in <filename unknown>:0 at Vessel.MakeActive () [0x00000] in <filename unknown>:0 at FlightGlobals.setActiveVessel (.Vessel v, Boolean force) [0x00000] in <filename unknown>:0 at FlightGlobals.SetActiveVessel (.Vessel v) [0x00000] in <filename unknown>:0 at ShipConstruction.AssembleForLaunch (.ShipConstruct ship, System.String landedAt, System.String flagURL, .Game sceneState, .VesselCrewManifest crewManifest) [0x00000] in <filename unknown>:0 at FlightDriver.Start () [0x00000] in <filename unknown>:0 I'm seeing a lot of errors but nothing to do with Interstellar. Can you start a completely new savegame and try to create some ships there and see if you have the same issues?