Starwaster

That has NEVER stopped anyone's fears from running rampant any time Squad does or does not do something that someone thinks they shouldn't or should do, now has it?

ModuleEngines can't be used to create engines that only use electricity because electricity is massless. The proposal by @Jatwaa will not work as is. Either electricity would have to be patched to give it mass (bad idea) or generators (ModuleGenerator or ModuleResourceConverter) would have to be added to the part to constantly generate a resource with mass that the engine uses (with ElectricCharge as an input resource). The engine part could then be configured to store very small amounts to the engine, the bare minimum it needs each physics frame at full thrust.

Funding.Instance.AddFunds(double amount, TransactionReason reason) https://kerbalspaceprogram.com/api/class_funding-members.html

That's the fault of so-called Smart RCS which tampers with actuation settings and its functions are not optional. If it's set to using RCS for rotation then every single RCS part is set to allow all rotations even if they were user-disabled. If it's set to not use RCS for rotation then all RCS parts are changed to disable all rotations.

It doesn't handle mining at all. That is totally outside the scope of this mod and always will be. Real ISRU is what you want but it is in an incomplete state. I've recently started working on contributing fixes to it but it's nowhere near release ready. You can check it out here: https://github.com/KSP-RO/RealISRU/tree/master/GameData/RealISRU liquefaction works (converting gasses to cryogenic liquid) for O2, H2, CH4 and NH3. Harvesting of various atmospheric gasses Sabatier reactors (methane from CO2 + H2) and drills for harvesting water and hydrates.

They occasionally use them to boost the ISS orbit and there was talk of using one to de-orbit the Pirs module ... I'm not sure that last has actually happened?

How is it cheating to use a Progress as a tug? They use it that way IRL sometimes....

@Tonas1997 looks like engine clusters had more than one MEC... This will fix it. Not sure what the solution is for engines with tanks in them... I stuck something else in there that might do it. No idea if it does or doesn't @PART[*]:HAS[@MODULE[ModuleEngineConfigs]]:NEEDS[RealFuels,TweakScale]:FINAL { @MODULE[ModuleEngineConfigs],* { @origMass = -1 @CONFIG[*],* { @origMass = -1 } } } @PART[*]:HAS[@MODULE[ModuleEngines*],@MODULE[ModuleFuelTanks]]:NEEDS[RealFuels,TweakScale]:FINAL { @MODULE[ModuleFuelTanks],* { %basemass = -1 } }

@Tonas1997 Give this a try. Make a file ending in .cfg and paste the following contents into it. Save that file. (somewhere in your GameData folder) I have no idea if it will work and you will lose any tech level increase benefits on mass from using this. @PART[*]:HAS[@MODULE[ModuleEngineConfigs]]:NEEDS[RealFuels,TweakScale]:FINAL { @MODULE[ModuleEngineConfigs] { @origMass = -1 @CONFIG[*],* { @origMass = -1 } } }

You could try making a Module Manager patch that sets origMass on ModuleEngineConfigs and every nested CONFIG to -1. That should stop RF from adjusting engine mass but that also means you get no mass reduction from tech level increases. BUT... remember I also mentioned that this can happen if the engine also has ModuleFuelTanks on the part! In which case baseMass on module ModuleFuelTanks should be -1. (in which case you might not have to do anything to ModuleEngineConfigs) If I knew what part you were experiencing this on I could probably give a more precise answer. I'd need your ModuleManager.ConfigCache file and the name of the parts in question. (or does it happen on every single engine part that you tweak?)

My favorite manifestation of that bug involved a tall rocket stack becoming pinned in place in the location of the errant engine allowing me to send the entire stack spinning like a ferris wheel without ever leaving the launch pad. Anyway... If the engine in question can actually store resources, such a bug becomes more likely. I find such engines should always have their baseMass (in ModuleFuelTanks) set to -1 which means MFT won't touch the mass (as far as the fuel tank portion of it goes) If it's just an engine (no tanks on the part) then it's an issue with the two mods each trying to operate on the mass and it's hard to even impose any kind of sanity checking because it may not be possible for either mod to know what the final outcome is going to be because neither one actually sees the final mass outcome. They only know what the original mass of the part was and how much they want to adjust it by. Neither one actually adjusts the mass directly; they're only passing along a mass delta.. (I'm making an assumption here in that TweakScale does the same thing as RF and makes use of GetModuleMass) Edit: Squad's implementation of GetModuleMass has long been problematic (especially but not limited to cases where resources are concerned) and really needs some work by Squad to Don't allow any single module to drop mass to a negative value, especially not ever. (this is just a basic sanity check that should always have been there but isn't) Don't allow the final result of multiple modules to drop mass to a negative value. Allow modules to pass along a lower limit as to how low the mass could actually go in the event that multiple modules are affecting mass. Not sure this has ever been raised on the bug tracker about GetModuleMass but we really should do so...

@siimav do the pull request and I'll review your changes and see if they can be incorporated or if I need to request changes also what mod's radiators are we talking about?

That's the same as saying that it's too late for a reentry burn but SR calculates that and determines if there is a point to continue trying to recover the craft anyway. That's the same as saying it's too late for a landing burn but SR calculates that and determines if there is a point to continue trying to recover the craft anyway. And it it meets those criteria THEN it goes on to calculate what the distance from the KSC would have been and calculates what the recovery percent is based on the distance. Performing one more calculation to see if it would have had enough fuel to close that distance is no more or less difficult than all the other calculations that went into making recovery possible even though the vehicle was already deemed destroyed by KSP when it was (going by your logic) way too late for recovery.

There's no point in discussing my idea here though, it won't get any traction. Eventually when I can take the time I'll implement it for my own use myself.

Doesn't matter. Not sure why you're thinking there's some difficulty here but there isn't any. The distance from KSC is already being calculated (necessary in order to determine refund amount) and from there it's just a matter of determining if there's enough delta-v to boost back in addition to the checks made for reentry burn and landing. It's just math.

No, it just tries to land them where they are. It shouldn't be too hard to do a simple check to see if after deducting enough to decelerate to safe speeds and then to land if there also would have been enough to send it back to the launch site...

Nowhere in this game does it state that you HAVE to do everything by hand or you lose the game. There's no such thing as cheating here.

Nothing stands out in the log and I can't repro the problem Double check the mass of the chute because that tool you're using looks off. Use the RealChute Parachute Editor and see what it says the total part mass is. Or use the stock Engineer's Report. (compare mass before and after part is added) You've also got a lot of mods altering the RC parts so it might be time to remove them all and then see if you can still repro the problem. If you can't then add mods back in one at a time until the problem happens again.

Also: Too bad I can't get anyone interested in modelling this: Inflatable shield with hard cap which has hatches for landing gear AND landing thrusters... (decelerator retracts after landing thus getting around the problem of how to safely separate from it before landing)

@siimav That's usually set to 0 by RO, are you just using RP1 without a full RO install? I'll just rip that section out of there; it's got to do with the stock radiator code and it's not really needed now. In the meantime if you patch it and set it to 0 like RO does then that would fix it.

MLI is passive; there is no power usage; it stands for multi layered insulation. It's double reflective mylar. In vacuum, the main heat transfer through MLI is radiation so each layer receives less and less thermal radiation. (there is increased heat leakage in an atmosphere because the layers are filled with gas but it's still better than a naked tank) It's meant to complement an active cooling system like cryocoolers which radiators emulate. If you didn't have any then there should have been some boiloff and I'm not sure why reloading would make a difference unless there had been an error but I don't see any exceptions in your log, at least not relevant here. The kinds I would be looking for would also have shown up in your screenshot as NaN for certain numbers like conductivity or the MLI data. (stands for Not a Number which is really bad when you need to do accurate maths) As far as it being overpowered, IRL you would be seeing differences between 10s of kilowatts (only basic foam insulation which you can't see but all H2 tanks have) and 10s of watts or less for MLI depending on how many layers. It's basically just aluminized mylar so it doesn't have much mass to it. There is a cost in money which I made pretty linear and is based on the total surface area for material cost + labor costs which I had to guess at. If it needs further balancing then maybe a future update can limit layer quantity based on research advancement and I'm open to specific suggestions and feedback as to how it can improve.

The bottom one has thermal conductivity consistent with about 100 layers of MLI for 0.0435 Watts x 40.48 m2 = 1.761 Watts getting through the insulation which is a pretty trivial amount of heat for radiators to take care of. The tank walls are under 20.15 which is the boiling point of hydrogen as configured for all of the tank types that carry hydrogen. The only way I see a problem there is if there weren't any radiators to be getting rid of that 1.761 watts. Otherwise those numbers look right.

@Pixie Perfect No, that question mark being inserted at the end is wrong; if your editor program autocorrects then change it back to what I said to put in there or it won't work right. Also, the text in the screenshots has to be readable. I can't do anything with those. I feel like I'm going blind trying to read it. Use something like imgur. You don't even have to log into it to upload a picture.

not enough information. In the RealFuels folder edit the RealSettings.cfg file and in the section that says RFSETTINGS add a line that says debugBoilOff = True Enable thermal debugging (Alt-F12 -> physics -> thermal check the top box) Put a Default type tank (when viewing the tanks in inventory in the VAB it will tell you what type they are) with LH2 in it and leave MLI at 0 Then launch it into orbit. Once it is in orbit right click on the tank and post a screenshot of the tank with its context menu showing (what you get when right clicking) Also ModuleManager.ConfigCache files and output_log.txt file

Replace the file RealActiveRadiators.cfg with this one https://raw.githubusercontent.com/Starwaster/RealActiveRadiators/master/GameData/RealActiveRadiators/RealActiveRadiators.cfg The problem is almost certainly caused by my having scaled down the maxEnergyTransfer. If the numbers are looked at though, I have a feeling that even at 1/50th of its original value that it SHOULD Have been enough to cool those parts and that the problem is due to Squad's implementation of ModuleCoreHeat and how it scales heat transfer. I've seen a similar problem with a reactor I wrote a config for constantly shutting down even though the radiators have a cooling capacity of 50kW and the reactor only needs 13kW. As I mentioned earlier, it's not the radiator code that removes core heat, the core code itself moves its own heat out to the radiator based on what the radiator says it can handle. Also, FYI (I forgot this earlier) it's ok if the throttling debug field says 100%. It is always at 100% unless there is insufficient power for the heat pump. It's not a percentage of full power, it's a percentage of the amount that was requested.