Fractal_UK

Welcome to the forums! This one is quite an easy one to solve - although you have a nuclear reactor, you don't have a generator to produce electrical power. The reactor only creates heat (you can use heat to power thermal rockets but not electrical equipment), a generator will take the heat produced by the reactor to produce power. Your generator will need a direct attachment to your reactor in order to function. Your ship will also need some heat radiators. The plasma thrusters you have attached are also electrically powered, that's why you're getting no thrust from them. Two extra bits of information: 1) Once you put a generator on your ship, you will only need one plasma thruster - they scale their thrust to the amount of power available so adding more of them adds weight but no extra thrust (they do have a thrust limit at which point you need to add more but you're nowhere near hitting it) and 2) those plasma thrusters are very low thrust for unupgraded reactors/generators even with big nuclear reactors and Xenon fuel, at your stage in the tech tree I'd go for a thermal rocket instead or you'll be going nowhere fast. Also, check out the link to the wiki on the first thread, this might help you with some of your designs. I fiddled about with their setup in the latest update and it might not have worked as well as it first appeared to. That said, the main reason the atmospheric intake worked so well is it has incorrect intake area values (it counts as being much much bigger than the stock ones) which is one reason I want to get rid of it. Also, those intakes don't add any drag to the aircraft as normal intakes do so they make things very very easy. I assumed noone would be using them anymore since I added intake atm to all stock and modded intakes but apparently I was mistaken. The intake air values are correct though, all of those intakes have 0.2 per intake. IntakeAtm just copies the maximum resource capacity of the IntakeAir resource, I don't change that or anything. I've made some more tweaks ready for the next update anyway, you'll hopefully have an easier time with that, I've also improved the LiquidFuel/Oxidiser rocket mode so that should help you once you run out of intake air too.

Looks like this is affecting reactors and generators but all the other parts seem to be unaffected, I have this fixed too now.

You'll need to check your KSP.log file but I doubt that's a problem that Interstellar could cause very easily, the worst bugs are usually when some Exception or another appears and goes uncaught in some PartModule code, reports of these are very rare now when everything is installed correctly and even they don't tend to cause craft to disappear. Not directly but antimatter transfers like LiquidFuel so the collector and fuel tank need to be in the same stack or connected with fuel lines. https://github.com/FractalUK/KSPInterstellar/wiki/Antimatter-Collectors Note that while within an atmosphere you will always get zero, though even in low orbit amounts are negligable. I doubt it.

It turns out that the code evaluating the changes in the WarpPluginSettings file isn't getting evaluated, so the resources are reverting to default. I've got it working again now. Let me check things over, I had to make some changes in 0.23 to handle things better in the VAB and the update system was one thing that got changed, maybe I've introduced some problem there that is hiding that option.

Yes, it seems that SQUAD changed the part.requestResource() method to make it do nothing for resource requests smaller than 1e-5 for all resources that have ALL_VESSEL_FLOW. I have no idea why this was done. The code I have currently stops tritium breeding from working if you have no Lithium, which due to this change is 100% of the time when the button is available. If you take this code out, so that you can have the mode active all the time then it consumes no Lithium/produces no Tritium until you hit about 100x time warp, then suddenly starts working properly as the amount crosses this 1e-5 limit. Thankfully this problem won't affect either Fission/Fusion reactors, radiaoactive decay and various other things because these all use custom code. Generation of Tritium will still work on unfocused vessels that have the tritium breeding mode enabled but when you focus that vessel, it will immediately drop out of that mod, thinking it has no more Lithium. There are a couple of ways I can fix this: 1) I can change most of the ALL_VESSEL_FLOW resources to STACK_PRIORITY_SEARCH - this has the downside that existing ships may need significant redesign because those resources will no longer be easy to transfer or 2) I can remove all the checking code that disables mode when you have no fuel for it, which means these options will fail at low time acceleration but will begin working when you accelerate faster and when the vessel is unfocused. Technically, there is also 3) write a new method that handles resource draws for ALL_VESSEL flows properly but I'd quite like to know why this change was introduced before doing that. Yes, I'm glad I had you testing this part on that dev-build I released before I started blowing up the general Interstellar playing populace

I've not looked at blizzy's toolbar stuff yet but it's something on my list of things to do. In the mean time, hiding the bar when F2 is pressed and hiding it for ships without a megajoule resource manager should be done for the next update. Yeah, this is a problem that has been affecting numerous mods since the 0.23 update, there is a way to workaround the problem so that'll be in the next update too. There should be upgrade button in the right click menu for unupgraded parts in space. Also coming in the next update.

I'll try adding that to the OnStart() then and see if that heads off any problems, it shouldn't be needed, I don't why they would be disabled but I'll try it anyway. In other news, I've actually created some 3D models - an inline refinery part, useful for all those playing with FAR who can't easily launch the standard one, two new methane tanks (one to replace the old methane tank and one a bit smaller and more suited to landers) and a large fusion reactor - suitable for the 2.5/3.75m parts. Both the refinery and the fusion reactor, however, require texturing skills far in excess of my own. If anyone is good at texturing and would be willing to help, please send me a PM, I'd be greatly appreciative.

Can you try and see if you can replicate this with just Interstellar installed? Your log file is almost impossible to read because some of your mods are just spamming the log file to hell. The only other thing to check is maybe when you built the satellite, it's theoretically possible that the WasteHeat update to solar panels only happens to solar panels that have been produced in the VAB since the version of Interstellar that started doing this particular update procedure was installed. I'll try and check out this possibility tomorrow - seems unlikely though. I took out some code in the latest version to try to improve performance, I did not experience problems but these things can all come down to the types of ships you build - I think I have an idea about how I can improve things.

You're using Atmospheric Intakes, that'll be why. I only left those in for compatibility purposes to prevent people's craft not being selectable in the VAB. I'll edit this so that they are no longer selectable in the VAB in future updates (but still remain as a part), I should've thought of doing this already. Replace those atmospheric intakes with ram intakes and you'll be fine.

What do you mean? I'd hazard a guess that it's happening because you have upgraded radiators and unupgraded reactors - those are a bad combination because the radiator temperature can get as hot the reactor and when that happens efficiency -> 0. The problem can still be solved by more radiators though. Basically, you won't see much benefit of having upgraded radiators until you get upgraded reactors because the upgraded radiators won't be able to get hot enough to work at anywhere near full capacity. Additionally, those inline radiators are really not designed for radiating the heat of a nuclear reactor in space, it's nowhere near big enough. They're amazing little things in atmosphere but you will need a huge quantity in space to get the job done. For a 3.75m generator/reactor, four of the second largest radiators might not be enough (at least until you get those reactor upgrades). The second largest radiator dissipates 75MW when unupgraded, without upgraded reactors you won't see substantially more than this even from an upgraded radiator - you might get 100MW. The 3.75m reactor is 3GW thermal upgraded, so four lots of 100MW is not going to do the trick, not even close. 2 of the huge radiators will do the trick though, provided you don't want to run the reactor at full power all the time, if you do, try three or four. To cool the 1.25m reactor, three or four small deployable radiators or 1 medium deployable radiator will easily handle it.

If you have a generator or microwave receiver or generally any component that produces Megajoules, if you click on it, it will bring up the power management window that tells you about supply and demand of electrical power. I'll see if I can hide it for ships that don't have anything like that.

One of the most common causes of weird problems is an incorrect install location, it's worth checking that you don't have two GameData folders appearing in the path or something. Remember that when you switched to some sort of closed cycle engine overheating will not be a problem so, it's still possible to build an SSTO aircraft using these radial intakes, it simply means that you have to switch over to internal fuel a little earlier. You can actually perform the switchover just before the overheating reaches maximum and you're only losing a few hundred m/s compared to a precooled design. I just used ModuleManager to make these changes, there isn't really a way to target cargobay doors or air-breathing engines programatically so I just used MM configs to change them manually.

Yeah, it's a known problem that has been affecting a few mods since the 0.23 KSP update. I don't really know why it happens but we do now have a solution to it, so that's the main thing - that'll be in the next update. I'll try to get a revised 0.9 update out in the next few days.

Which radiator do you mean? Only the larger deployable radiators should have a deploy action, the others technically use the same module but don't show the option to deploy/retract (technically, they count as deployed all the time).

The pre-cooler thing is in the first page and the changelog but you're right, the eendless cycle of updating and then documenting updates needs to take a swing toward the documentation side! Not sure what the squeal could be though. There are no resource production modules for the refinery, there is just the refinery module which handles all of its possible actions such as fuel reprocessing, electrolysis, research, etc. The idea of the WarpPluginSettings.cfg file is to change these "hard to reach" definitions. Can you provide a ksp.log file so I can make sure that is getting loaded correctly?

Actually, yes, though this is a sympton of the same issues with part.requestResource problems. I wrote custom code for the reactors that handles the resource drawing of fission and fusion fuels in order to prevent issues like the tritium breeding problems - at some point I will write up a generic method that does this for all resources, I've been reluctant to do this so far but now that it appears that resources aren't going to be a major focus of the stock game, I'm not really expecting a major improvement of the stock API. This could, in theory, be related to the issue I'm discussing above. Can you try changing the TAC Water resource definition to STACK_PRIORITY_SEARCH instead of ALL_VESSEL just to rule this possibility out? No, the message is the same. The mechanics have changed now so waste heat will build up for a while until the vessel reaches a thermal equilibrium - the more WasteHeat you have in the bar, the hotter the radiators will get and the more heat they will dissipate. The number of radiators you need hasn't increased, in fact it has gone down slightly but the way the system operates has changed. I am not sure if radial intakes will be checked by the code - I'm more targeting an intake -> pre-cooler -> engine or intake -> pre-cooler -> reactor -> engine set up. I particularly like the combination of the B9 sabre intake and B9 sabre precooler. High altitude/velocity atmospheric flight has got much much easier since 0.23 so you shouldn't need as many intakes now anyway. This is really something I wanted to include to draw a distinction between aeroplanes designed for hypersonic flight in the atmosphere and spaceplanes that are actually capable of achieving orbit.

You should only need water to make Hydrogen Peroxide, you only need Ammonia and Hydrogen Peroxide for the final monopropellant production step. Check the water electrolysis option at the refinery, that uses the same water definition as the other refinery options. Also, be aware of fuel flow options, I don't know what the definitions for TAC water are but check that the refinery is getting access to the resources it needs.

Yes - some of the parts will not be available and you will never get any of the part upgrades. Fortunately, it's very very easy to fix. All you need to do is go into your save file folder: [KSPInstallDirectory]/saves/[your game name] and delete the "tree.cfg" file. You will get the option to choose again next time you start the game.

After some investigation this looks to be another problem with stock KSP. My code is correctly requesting the amount of Lithium to burn but the stock method simply returns 0, meaning it is not giving me any Lithium despite a connected supply being available. By time accelerating so that the amount I am requesting becomes larger, the method begins to work properly. Only thing I can do to fix this is to disable the code that turns off Tritium breeding if you have no Lithium - this won't fix the problem at low timewarp speeds - you'll still get nothing but it will, at least, allow non-focused ships and ships at high timewarp to generate Lithium.

So, the Interstellar resource manager covers some of the objectives named here but let me go through and briefly discuss what it does well and what it doesn't do so well. Capabilities of the Interstellar Resource Manager: Managed Supply of Resources - The idea here is that the resource manager doesn't want to produce more of a resource than can be used, so, if we are using the resource manager to manage a supply of Thermal Power created by a nuclear reactor, we want to supply enough to provide for the ship's power needs and no more - otherwise we are wasting nuclear fuel. Storage Independence - We don't want huge buffers to make everything work at high time acceleration, the Interstellar resource manager should still function properly with only 1 unit of storage of a given resource - it is capable of using ongoing supply to meet demand. Power Organisation and Prioritisation - Not everything needs power to the same degree, if you're running lots of science equipment on your ship that's nice but I'm guessing you want power to the engines first. The Interstellar resource manager works by organising resources by demand and by priority, it supplies the smallest demand of the highest priority and then moves onto the next smallest of the highest priority, etc. until either all the needed power has been supplied or the power has been exhausted. Minimal Conversion from Stock Resource API - No one wants to rewrite lots of code so that idea was to encapsulate all of this functionality into something very much like the part.RequestResource() method. The resource manager typically uses just two methods, supplyFNResource() and consumeFNResource(), though PartModules that wish to supply a resource must also declare which resources they intent to supply OnStart. The Interstellar resource manager is very powerful but it isn't perfect and has some drawbacks Offline Resources - This is totally unsupported at present and Interstellar's handling of offline resources is, for the most part, a very simple delta fudge. One-Off Supply and Demand - The resource manager is heavily optimised toward the handling of power supply and demand that goes on continuously for at least several frames, supplies and demands that last for only an instant are not well supported. Here is an example of the resource manager in action with many demands. Here all the draws are of the same priority so the resource manager has organised them solely by demand and you can see that the science lab with it's huge 5GW power draw is the one that missed out in order to keep the other components supplied.

Cheers, I've just added a description to my resource extraction module which fixes the problem. Just tried that out, it worked perfectly normally, no slowdown at all.

Yes, it's designed for this to be possible. You should leave the definition in ResourcesNuclear.cfg as it is (because multiple RESOURCE_DEFINITION{} nodes are bad) and ideally change all of the others with Module Manager. You will also need to change the "WaterResourceName = LqdWater" definition in WarpPluginSettings.cfg (again you can do this with MM) - this is critical because this is the one that all the refinery's internal plugin code looks at. If you change the density of water, you should increase or decrease the quantity of water so that the mass amounts remaining the same. It's better to do it with ModuleManager though because then you can save the configs, give them to other people who want them and, critically, not have to do this all over again next time I update.

I just updated the mod earlier today for 0.23, hope you enjoy!

Yeah, you're right. I've made a lot of behind the scenes changes in this update to try and seperate modules for resource extraction and resource processing - the long term goal being that you could imagine having seperate parts, some for collecting resources of each type then a distinct part for the chemical processing of those parts. That approach, of course, lends itself better to have smaller more portable parts that each have specific role rather than a single part that does essentially everything. The refinery module is something that looks very nice for surface bases but it's awkward to actually get it out there - especially if you're using FAR and need to worry about realistic aerodynamics. I will do my best to resolve this with future updates - if you know any competent modellers looking to pass some time, point them in my direction and I'll make sure they have plenty to do!

Update: It appears that this may be a stock bug, apparently it is also happening to TAC life support parts that have more than four resources defined. Removing one of the resource definitions will stop it doing that in the VAB - from some quick testing, this doesn't seem to stop the parts actually working, so I'm inclined to hold off on doing anything about this and hope the devs release a fix.