RzTen1

I've applied the Toolbar fix from the pull request, but it looks like KeepFit is still failing to startup properly on 1.2. I'm seeing this in the log: I don't have Connected Living Space loaded. If I modify the GetCLS() function to always return null, both errors disappear and the button appears as expected. I suspect loading CLS would also fix the issue.

I just wanted to give you a heads up, it looks like Final Frontier is conflicting with the new Contract Configurator: It looks like this is due to an out of date dependency in blizzy toolbar. More info and the code to fix it is here: The merge in question is here: https://github.com/blizzy78/ksp_toolbar/commit/141485a715d11ac3d15d8d6f0ffafe5a01d853ba

If you don't mind editing your save file, you can change all the occurrences of 'BoiloffOccuring = True' to 'BoiloffOccuring = False' to stop it from happening. You'll need to do that again if you lose and regain power though. Make sure you make a copy of the file before changing it.

Holy crap those magnetic fields are amazing. I have some news from the Cryo thread. It looks like EC should be constant:

Shouldn't this code segment cause the EC usage to vary depending on tank volume? https://github.com/ChrisAdderley/CryoTanks/blob/master/Source/ModuleSimpleBoiloff.cs#L86 coolingCost = fuelAmount/1000.0 * CoolingCost; I don't see it getting redefined anywhere but I could be reading it wrong.

One other thing I noticed. It looks like SimpleBoiloff should be calculating the amount of fuel and adding that to the EC usage, but that's not what I'm seeing in game:

I realize that but that doesn't seem to be the way CryoTanks actually works: I tried unloading and reloading the vessel on the off chance it ONLY computes this on load, and it still remains at 9.72ec/s even with the tank almost empty. I'm not sure if this is intentional or not, there were major changes in Cryo recently and I think the version in GitHub looks to be out of date. I see strings in the compiled dll that aren't present in the GitHub source. I'll mention this in the NearFuture thread as well.

I'm still having the EC drain issue with 1.0.8. It looks like it may be this: Kerbalism computes the EC cost on the Cryo Tanks as follows: ec.Consume(cooling_cost * fuel.amount * 0.001 * elapsed_s) SimpleBoiloff uses: part.RequestResource("ElectricCharge", coolingCost * TimeWarp.fixedDeltaTime) I'm not sure why Simple doesn't include the amount of fuel in the energy calculation, but that seems to be what's throwing it off.

I think I may have found an issue with Kerbalism's background processing. If I put use the CryoTanks from NearFuture the power draw in simulation and in the background are totally different. In sim it works normally and matches the VAB but when I switch back to the space center the batteries flat line in a couple of seconds. The helper in the VAB is showing perpetual power. The issue occurs with both reactors and solar panels. If I remove Kerbalism the problem no longer occurs, so I don't think it's a NearFuture issue.

Hi. I think I may have found a bug in SimpleBoiloff in the CryoTanks part of the mod. It looks like whenever a tank stops cooling when it's re-enabled (or re-powered) it never stops boiling off. It persists across scene changes as well. The GUI shows that the tanks are insulated but there is still a drain shown in the resource panel equal to when the tank was uninsulated. BoiloffOccuring appears to be getting set when cooling stops and then never getting unset. I poked around the repo to try and pin it down but I can't find the 'BoiloffOccuring' string anywhere. I'm using 0.3.5.

Hi, I just switched to 0.9.9.5 and I've noticed an odd bug with time compression. When at 1000x or lower, oxygen and food deplete at the rates shown on right click vessel status menu, but going faster than 1000x appears to cause oxygen to drain at a vastly increased rate. On my current test craft I've got 14days of food and 17days of oxygen left, but if I accelerate time to 10000x I'll run out of air in 4-5 days. That's the amount of time reported with the scrubber disabled, so it looks like it may be cutting out. I've got enough power and I'm not getting any alarms until oxygen gets low. Edit: Also it looks like it's doing the same thing in the tracking station.

I noticed that DMagic and UniversalStorage parts aren't getting the ScienceTweaks the stock parts are getting. This appears to be due to DMagic using DMModuleScienceAnimate instead of ModuleScienceExperiment. Changing the ScienceTweaks.cfg file from ModuleScienceExperiment to *Science* fixes this issue. Here's the top of the file with the changes in it:

Ah, I found it. I wasn't expecting it to be on the right click menu after it had been attached. Do you think you could add base ranges to the right click description in the builder? It would make things easier to compare without having to attach every antenna to the craft.

Hi. I just switched to this mod since TAC isn't working in 1.1 yet and I gotta say it's pretty awesome. I had one comments: It would be nice if the status window shows which parts are broken on the dropdown, or they glowed a bit like in DangIt. It's a bit of a pain to find which solar panel has failed on a craft that has 20 of them. Also, do the antenna's have different ranges now? It's not clear what the range is from the description and it kinda looks like the basic antenna will work for the entire solar system. I'm not sure if that's correct, but I did like the part of RT that longer ranges required bigger dishes.

Aluminum would be a pretty interesting propellant. I think it'd make even more sense to have some sort of hot-tank for it as the melting point is quite a bit higher than lithium. Plus, it'd be interesting to have something generate wasteheat that wasn't an engine or reactor/generator. Btw, that new engine is pretty awesome looking.

I've submitted a pull request with a recommendation on SETI and power usage that hopefully looks good. I've also figured out my issue with the lithium radial can: It looks like all the other hex cans have an attachment rules of 1,1,1,1,0. The lithium can has "attachRules = 1,0,1,1,0". The second bit allows surface mounting, which is what I was trying to do. I was also wondering if the can should actually draw power since lithium doesn't actually melt until its temperature exceeds 180C. Even with full solar exposure it would have to be heated, not to mention if it's in shadow. It might be interesting if the can acted more like a cryo tank except instead of boiling off it just stopped providing fuel if power ran out.

Yep, it's this section that's doing it: (Patches/USI_NF_Mode.cfg) @PART[*]:HAS[@MODULE[FNAntimatterReactor]]:NEEDS[NearFutureElectrical|SETI]:FOR[WarpPlugin] { @MODULE[FNAntimatterReactor] { @upgradedPowerOutput *= 0.002 @neutronEmbrittlementDivider *= 0.002 %fuelUsePerMJMult = 500 %wasteHeatMultiplier = 0.002 %powerOutputMultiplier = 0.002 } } Should this be making the change for SETI as well? I understand tweaking the values if NearFuture is there so that it's more in line with their reactors, but I don't believe vanilla SETI is changing any power/thermal numbers. It also seems somewhat inconsistent as it's only tweaking some of the reactors (looks like just the anti-mater) but not all of them. Plus, with these settings thermal nozzles would need a massive boost to be even minimally useful.

I had removed SETI, but I missed one of the contract packs for it. I've narrowed it down to this section of module-manager code from SETI-Contracts: @CONTRACT_TYPE[KerbinLanding]:FOR[SETI]:NEEDS[RealChute] { } Yes, seriously, just that. If I comment those three line out, I get 120GW. Load it back in and the antimater reactor drops to 480KW. I don't see anything in the module manager that would account for this behavior. Even more oddly, only pre-1.7.0(e) appears to have issues. 1.6.9 works regardless of this patch existing. I've tried both my local compiled copy and the one from git and they both do the same thing. Best guess: FOR[SETI] causes MM to set the flag that indicates that SETI is installed, even though it isn't. Another config file has to be changing the reactor values.

NFT-E wasn't installed but SETI was. I pulled it and nothing changed so I pulled almost every other mod I had loaded and the numbers went back to normal. Something else appears to be messing with just those three reactors for some reason, I'll try and track that down later. I still can't get the lithium radial to attach though. Is there another tank that will accept lithium?

I just created an account under the same ID as here. I'll muddle around there and try to get my stuff uploaded.

I noticed some weirdness in the current build. I'm getting correct thrust numbers for everything I've thrown at it, but three reactors are acting up: 1. The 'Reactor: Antimatter' reactor is only generating 480KW of power. The thermal mechanics helper and the reactor control panel both show the same numbers. 2. The 'Antimatter Initiated Fusion Reactor' is only generating 81KW. Same as above in the helper/panel. 3. The 'Magneto Internal Fusion Reactor' is generating 13.5MW, which seems correct, but the thermal nozzle will only accept Lithium as the fuel source. I can't get the Lithium cans to attach for some reason, so I can't test with it. The 'Magnetic Confinement Fusion Reactor' seems unaffected and is generating an expected 27MW. Also both generators seem to have issues attaching to the rocket:

I wasn't all that happy with the prior code I submitted, it was close but still off in odd ways depending on engine/reactor combo, so I've redone all of it. Orbital thrust and isp now match exactly with actual in game values. Atmospheric readings are still off by a couple of percent, but that seems to be due to the EarthAtmospherePressureAtSeaLevel constant reading 101.325 while I get closer to 100 on the pad. In any case, atmospheric is much better and actually usable for orbital insertion calculations. I also redid the section for BetterBurnTime to accurately calculate the actual maximum thrust so that it matches in flight values exactly. Buoyancy calculations are still missing, so the open gas core reactor's numbers are optimistic at best. Here is a diff compared to the current version in github (the last commit added my first patch attempt). A new vairable has been added to both in-flight sections to avoid stepping on other code, calculatedMaxThrust. This will contain the maximum thrust at full throttle for the engine at the current altitude both while running and idle, as long as the engine is active. In case that's hard to read, here are the changed functions in their entirety. EstimateEditorPerformance: OnFixedUpdate - if myAttachedEngine.isOperational block: GenerateThrustFromReactorHeat:

On a related note, BetterBurnTime was also throwing incorrect numbers. It looks like it depends on engine.MaxThrust to calculate the burn time and it's just pulled out of the engine config file and never updated. Since this already getting calculated while the engine is running I just added it into OnFixedUpdate for ThermalNozzleController.cs: expectedMaxThrust = (float)(AttachedReactor.MaximumPower * GetPowerThrustModifier() * GetHeatThrustModifier() / PluginHelper.GravityConstant / _maxISP); expectedMaxThrust *= _thrustPropellantMultiplier * (1f - sootAccumulationPercentage / 200f); myAttachedEngine.maxThrust = expectedMaxThrust; The last line is the only change. Here's a diff of the changes I've made so far compared to the latest from github:

I have a bug in the code I posted, I was using AttachedReactor.MaximumThermalPower in the thrust calculation instead of AttachedReactor.MaximumPower. That was skewing reactors with charged particles. Fixing that puts everything pretty close to the editor estimate:

Thanks! I've been playing with that new code and swapping out different reactors and I've come across two things of note: 1. reactor / thermal nozzle combinations that have no thrust at sealevel can cause minISP to go negative. It looks like the correct way to fix it would be to add another atmospherecurve with the altitude where the engine actually hit's 0.1isp and clamp sealevel to zero, but it may just be a visual problem and not game impacting as negative values don't seem to break anything. 2. the 'gas core' reactor. The buoyancy effect causes weird things to happen, even with stock code. 100% throttle actually produces slightly less engine thrust then when set to around 60%. The reactor control window also seems off, thermal power is lower at 60% (as expected) even though more of it seems to be hitting the engine. There really needs to be a readout on the buoyancy impact. I also feel like the reactor needs a tiny boost in total thermal power as you lose a pretty large chunk of it while accelerating, which seems odd for a reactor that looks to be designed for thermal nozzles. All of this also means that the thrust estimate is still way off on the gas core: 371kN vac is reported on the engine and in KER with the new code, but in space it's usually quite a bit lower. I'm not sure how to calculate the thrust for this engine as it'll need to take into account both stage mass and throttle position, but I'll keep poking at it.