Fractal_UK

You're not doing anything wrong, it's a KSP issue that I am struggling to find a solution to. It's the same problem as the stock 6-way hub part has that prevents it from being attached in certain orientations - if you start with part A and try to attach part B to it, part B will only attach along one axis top-bottom, left-right, front-back but not any of the others. Once you have placed the refinery, you should be able to attach to the side node, if that helps. I believe, if it helps you, if you find the refinery part.cfg file, you can switch the order of the "node_stack_right = " and "node_stack_bottom =" lines in the file, at which point you'll be able to attach the refinery to other parts via the side node but not via the bottom node. Unfortunately, since this is an issue with the stock game, I don't think there is anything I can do about it other than try to find a compromise solution.

Obviously setting things up in this way is a lot more realistic but it opens up a large can of worms that I'd rather not get into. Once you start simulating heat flows across a vessel on a per part basis, you have a fairly complex numerical simulation going on, you need to decide on a lot of parameters for each part (parameters for specific heat capacity, convection, emissivity, reflectivity, conductivity, etc.) at which point the behaviour of the simulation is no longer intuitive - by using this kind of a simulation, problems in heatflow designs could become extremely subtle and very opaque to the player without extensive mathematical analysis of the heat flow properties of their ship. Additionally, such simulations don't respond well to large changes in timestep occuring abruptly, e.g. as a result of changing time acceleration, especially when you're potentially changing the timestep by a factor of 100,000 - it will perturb the equilibrium and cause large shocks in energy flow until the simulation stablises in the new time acceleration regime, potentially blowing up components in the process. It's bad enough making the resource manager handle time acceleration properly as it is, nevermind having hundreds of independently simulated components doing that and it's not computationally possible to maintain a fixed timestep and perform the calculations at the required speed during high time acceleration. Furthermore, you'd also want preferential heat transfer between components and would have to distinguish between things like reactor external and internal temperatures - you want the leftover internal heat going out via your reactor's heat dissipation system but you'd also need to have information about the temperature of the parts themselves, at which point you need multiple cooling loops, one for cooling reactors and primary energy systems and other systems for maintaining thermal equilibrium for the operation of electronic systems (and people) within the rest of the ship. Basically, it's a nightmare of complexity. I think the best compromise can be achieved by making heat dissipation from radiators scale with WasteHeat accumulated so you don't just get these sharp transitions in radiator temperature and consequently generator efficiency, you'll instead end up in some kind of thermal equilibrium which varies according to your reactor output. There is no more additions folder, the waste heat system is added automatically to parts with the ModuleDeployableSolarPanel so that modded solar panels are now properly supported. You cannot now delete that folder to prevent the waste heat mechanics being applied but, if it helps, you can turn off WasteHeat generation all together by changing to "ThermalMechanicsDisabled = true" in WarpPlugin.cfg. I've updated the download links for the mod with the radiator temperature problem fixed. If you already have Interstellar v0.8.2, it's not worth re-downloading the whole thing, just use this .dll fix, unzipping the file into your base KSP directory as usual.

I think this will only have a noticeable effect for the unupgraded fission reactors anyway but I think the temperature cap is being applied at the wrong time. Basically, I have to cap the maximum radiator temperature based on reactor temperature, otherwise the radiators might get hotter than the reactor and that makes no sense. When folded up, the dissipation of the radiators drops to 10% of the deployed value but the displayed temperature of the radiator isn't taking that into account at the moment so it appears to be cooler than it should. This will only happen when there is a net build-up of WasteHeat, if you have sufficient radiators to dissipate all the WasteHeat produced, you will be better off with deployed radiators but you'll need to wait for the WasteHeat bar to hit 0 before you'll actually see that. Edit: Actually it looks like it's just a copy-paste error that must've been made as a result of fixing the Jool Bug. I'll update the download link with a new dll shortly and put up a fixed .dll download, there is no need to redownload the entire mod for such a small fix. It's quite deliberate that you can't do this, pumping hot oxidiser into a nuclear reactor is a good way to make the reactor explode.

I'd guess FAR thinks the thing is as large as it is when fully deployed and calculating drag based upon that. Getting low generator efficiencies like that with unupgraded reactors is very possible, getting a high efficiency needs either a high reactor temperature, low radiator temperature, or preferably both. You shouldn't be seeing anything different with regard to efficiencies and core temperatures since the change from 0.7.X to 0.8, though recent bug fixes could have a small impact. I'm considering having the radiator temperatures vary more smoothly with waste heat, so they don't just shoot up to max temperature instantly when there is a tiny bit of heat in the bar - that would make your rocket find an equilibrium depending on current power useage and improve generator efficiency. I need to test this extensively though because I don't want to risk craft instantly overheating at high timewarp.

You are correct and I am aware of this, I suspect, however, that altering the algorthim to take distance into account is a bad idea because it increases algorithmic complexity quite a bit especially if you want to take multiple relays into account. Since this algorithm is running often, we don't want to make it more complicated. The best way I've thought of dealing with this, so far at least, is to order the list of relays by distance when the ship is loaded (and perhaps perform a re-ordering minute or so), that way the first relays in the list, i.e. the ones that are connected to first, will always at least be in the same sphere of influence (assuming such a relay exists). That way, in the worst possible case, you connect to a slightly suboptimal relay within the same SOI, at which point the energy losses will be almost indistinguishable anyway.

Version 0.8.2 Released Otherwise known as the great bug purge. Since it's been a little while since the last update, I thought I'd cram in a few small features too. The Plasma engines will now have different slightly different efficiency depending on the propellant used rather than a fixed 72% efficiency. The values are LiquidFuel (72%), Argon (76%), Xenon (69%), Lithium (86%), I've also added a new Monopropellant (Hydrazine) propellant option which functions at 52% efficiency. I've also changed the antimatter tanks to have different electrical consumptions dependent upon their size. Changelog: Version 0.8.2 -Different plasma engine propellants have different efficiencies, added monopropellant (hydrazine) as a fuel option -antimatter tanks charge use variable based on size -Jool 0 temperature radiator bug fixed -extensive microwave fixes - conservation of energy now respected -antimatter consumption with multiple tanks fixed -generator improvements, use better resource manager API -radiation improvements + second van allen belt -reactor supports unupgradeable types -electrolysis rate fix -resource manager electricity consumption fix -resource manager negative consumption bug prevented -various conversions to double precision to improve accuracy -removed more constants from part modules Download links in the first page have been updated. This update will fix it.

Yes, don't worry, it's fixed.

You could stick a microwave receiver on the ship to provide startup power. Even when upgraded the 1.25m reactor will give you over 7 years of power and over 20 years of power when un-upgraded assuming you can run at 30% power all the way. It will work over all physics loaded vessels. KSP can indeed use LINQ but I'm afraid all the changes I've made have killed the algorithm. I shall have a look at writing an updated version that can handle more relays. That said, BFS is essentially what I implemented already, only with a maximum depth of 2. In any case, the worst possible case of the total search is the case in which the only connectable relay is always the last in the list, at which point you have NT*NR*NR-1*NR-2*....*2*1 = NT*NR! (since the connection order is important). Generically, BFS is O(bd) but this search is at least constrained by the need to never revisit the same relay. Truncating the search at Y relays reduces the complexity to NT * NR! / NR-Y! The DT Vista is undeniably OP as an engine, it is conceivable that it would be capable of making an interstellar voyage to another star system given sufficient time. I cannot balance that engine based on its thrust and specific impulse performance without changing it to totally misrepresent the concept of that engine as it was conceived in real-life. The only way I can hope to balance it is with the radiation effects, which stops you using it from a lot of utility purposes (landing at your manned bases, docking at manned space stations, etc.) at which point it constrains your design - either your ship loses functionality or you have to add other parts to restore that functionality. Using it to lift-off from Kerbin always requires a good bit of cleanup to avoid frying Kerbals on the ground around KSC. In other news, I believe 0.82 is ready and complete with bug fixes aplenty. Assuming there are no last minute issues, I'll package this up for a release tomorrow.

The corrections that wasmic provided are correct for it's and its but not for the proper nouns. "Moho's status as a dwarf planet" is the correct useage, as is "This sounds like the same Kerbals who think Eve is Kerbin's sister planet" etc.

Right, I've finally got this microwave power system functioning how I want it to - namely respecting that all important first law of thermodynamics. Every receiver is now aware of how much power is being received from each satellite by every other receiver meaning that horrible energy amplification effects should no longer be possible. It's a bit difficult to demonstrate this because the power satellite is in a low orbit and moving over the sky quickly but hopefully you can see that as I deploy more receivers we're getting diminishing returns. The amount of power theoretically available is 69.79% of 61.9 KW or 43.2KW. Whether we get these optimal conditions, however, depends on the angle of reception. Total Power = 26.24 KW Total Power = 33.14 KW Total Power = 34.26 KW Total Power = 34.84 KW Transmitters and relays are already assumed to always point directly at the receiver, it's only the receiver that needs to be oriented properly.

Omni-directional is pointless for power transmission, you'd loose about 99.6% of the power transmitted with a 2.5m receiver only 10m from the transmitter. Over 10km, you'd get a million times less power than that.

The bug you mentioned is fixed in my development version, as is point 2, also I've fixed the calculation of distance losses via relays. Changing the system to add more relays is potentially problematic because the maximum number of calculations can become enormous with many relays. At present the maximum number of line of sight calculations is NT*NR where NT is the number of transmitters and NR is the number of relays. So, if you had 50 transmitters and 20 relays, you're talking 1000 calculations. If you could have unlimited relays, you're talking an upper limit of NT*NR! or, using the same numbers 1.2x1020 calculations in the worst case. In practice it won't even be close to this value but you get the idea about how quickly things scale up.

Check how your science mods are modifying the existing science experiments because you have in your log file: [LOG 11:40:09.237] [DTMagnetometer]: Activated (forced) [B][ERR 11:40:09.238] [R&D]: No Experiment definition found with id magnetosphericExperiment[/B] Of course, if you go into GameData/WarpPlugin/Parts/Resources/ScienceDefs.cfg you will see... EXPERIMENT_DEFINITION { [B] id = magnetosphericExperiment[/B] title = Analyse Magnetosphere ........ } I'd guess one of your other mods is messing with the science experiment definitions causing the magnetometer one to be deleted.

If you update to the latest version of Interstellar, it shouldn't matter what the config definitions are. Interstellar will write a custom float curve to the solar panels to produce proper inverse square behaviour, it also scales the value based on Kerbin's orbital radius for compatibility with RSS.

That's fine, a relay is completely blind to how much is being transmitted. I'm going to hide the Beamed Power entry when its in relay mode in future, it's totally irrelevant. Yes, unfortuantely there is a bug (now fixed in the development version) such that the relay state isn't stored persistently by the ship. That means if you create a relay and leave it alone, it should work fine because it will read the proper state from the text file but otherwise it will get reset into transmitter mode and you'll have to turn off the transmitter and set it back into relay mode. The one relay limit is totally unrelated to this and has nothing to do with the save file.

There's still enough information to go on to say conclusively that within the vast majority of the Fukushima exclusion zone, you could live an entire lifetime with no increased risk of cancer and that the undeniable largest health impact was the evacuation of the elderly and sick from inside the exclusion zone - something that really does place those people in genuine danger.

If you go into your game's savegame folder, you should see a WarpPlugin.cfg file next to your quicksave and persistence files, if you open that, you should see the data for your transmitters. You should have some "VESSEL_MICROWAVE_POWER_" entries with a nuclear power = entry inside showing the reactor/generator/transmitter you have at KSC. Also, check that you have three "VESSEL_MICROWAVE_RELAY_" entries with "relay = true". There is, however, a problem with your current setup (but what you have tested so far should be working). I am currently only allowing connections via one relay (to save calculations) so based on your current setup, you'd be better off having one of the geostationary satellites as the power source and setting it to transmit mode. You could then have other satellites in the same orbit but in different locations on the orbit in relay mode, that should let you receive the power anywhere on the ground, which I'm guessing is what you're going for here.

Yes but you will need to switch back to your science labs before the retroactive science will be added, it should give you a message telling you how much has been added.

Got a KSP.log file? Do you have any mods installed that makes any changes to the stock science system?

Demand governs the output, so you should always have enough power to keep your equipment running. The vista always uses the same power regardless of throttle (the throttle is controlling Isp rather than power) anyway so you shouldn't have to worry about having to run at reduced power either.

No, the reactor generates WasteHeat equal to its thermal power, the generator consumes WasteHeat equal to the amount of electrical power it produces, so say your generator is 20% efficient, 20% of the thermal power becomes electrical power and 80% of it becomes WasteHeat. Some things that consume the electrical power are also modelled to be less than 100% efficient, so some of those take in their electrical power and produce a proportion of WasteHeat. There is no fixed conversion there though.

Not quite - most hydrolox rocket engines actually run rich in Liquid Hydrogen relative to their combustion ratios, this is because having more hydrogen in the reaction mass lowers the average molar mass of the propellant increasing specific impulse. That is why even if you use RealFuels, which has realistic densities and fuel mixing ratios, electrolysis will give you more oxygen and less hydrogen than you ideally need. The difference is much bigger in stock KSP but then I have no idea where those ratios came from. I prefer to try and base numbers on something vaguely physical where possible in preference to making them up. Edit: I've also fixed the issue Scott Manley discovered in the most recent video. It appears that stock static panels (which interestingly still use the ModuleDeployableSolarPanel class) were "retracting" in response to WasteHeat buildup, stopping them generating both power and heat. I'm surprised the static panels are capable of this behaviour but anyway, I've added my own code to check for this now. In other news I'm looking at removing the distinction between the phased array microwave transmitters and receivers, letting you use either model to transmit or receive but not both at the same time.

I'm still grappling with this problem, it seems that attachment nodes only work in pairs. In other words, I can have a node on the top and a node on the bottom or a node left and right but not a node bottom and right (for example). However I set it up, one of the pair doesn't work. It's the same problem that the stock 6-way hub has, when you try to attach it to something else it will only work in a certain orientation. If you put it on top of something else, then attach something to the side node, the side node should work then. It might be better if that was the other way around though, so you could attach it to things sideways but things to it either way (if that made any sense at all).

Got a confirmed fixed for this for next version. Thanks for the very detailed report.

Yes, it's possible, you get less power if you do it but it could be worthwhile. Maybe you want the largest reactor to give you a better TWR but maybe you don't need the power output that the largest generator would offer, you could stick on a smaller generator, save mass but you still have some electrical power available.