NathanKell

Yaivenov: That's a lot of good stuff! Let me address a few; the others I suggest you make an issue for each on the RO github issues page, so each can be discussed and won't get lost in the thread . 1. We removed the electricity requirement from TACLS so that we can have per-part electricity requirements (TACLS does not at present allow per-part customization). That's intended behavior you're seeing. 2. At present, ModuleRCSFX only supports part-level tweaking of RCS. That means if you disable roll RCS on a part, no thruster will fire for roll actuation, but all thrusters that can contribute will fire for yaw and pitch still. KSP has no concept of "this particular nozzle is only good for this particular control actuation". 3 and 4: There's a bug in ModuleRCSFX that Starwaster found; that should help MechJeb a lot. The stock SAS, however, needs PID tweaking badly (that's out of RO's scope, though, IMO). 5. Stock bug. Try the mod in this forum (Clamps-Be-Gone?) that fixes it. As for Needs, the fairing thing sounds like you're trying to play career without RP-0. RO does not natively support career; you need RP-0 if you want to play career. (The OP does mention this. ) I'll try to get to the rest soon. There's a lot!

codepoet: what exactly _is_ the behavior you intend for MechJeb? If an engine is set to engineIgnited = false (but it's staged), then MJ won't compute delta V for it. That's why I leave it set to true, so you get to see dV even when your engines are at 0 thrust.

Apologies for the delay on fixing interaction with TweakScale. I was away for a bit, and remain quite busy. I'll get to it, but no promises as to when. Same with the ignition/ullage stuff. It's even tougher because I have never encountered the issue myself (when it says Very Stable but is lying). zzz: depends on what config set you're using. If you're using something that uses techlevels, that will work. If not, you need to work a bit harder (modify the keys in the atmosphereCurve in the CONFIG). RF does support global static Isp SL and Vac multipliers though, so if you're writing (or can have someone write) a very simple plugin that just sets them, that will work too. Svm420: @ works only if the value already exists. Use % (Also, try using 1.0 for everything, and instead modifying the techlevel throttle settings in REALSETTINGS) Cronus425: Yep, you can set them both to false near the bottom of RealSettings.cfg

Relevant link: http://forum.kerbalspaceprogram.com/threads/130067-Guide-Combining-and-remixing-multiple-add-ons-with-different-Creative-Commons-licences

taniwha wrote an MM patch. Dig around for threads he started in this forum. VISPr I think?

MechJeb will only check monopropellant. So you do it the manual way: record the mass of the craft with full tanks, tweak the RCS propellants to 0 each, record that mass. Calculate ln(wet/dry) * 9.80665 * RCS_Isp. That's your delta V.

Regarding the MM code in ROMini, it works fine. That is in fact the correct syntax. ~scale[] will find an absence of any scale, just as ~scale[*] will, and note that MODEL doesn't have a name = line to match against with [*]. At one point, perhaps still, that would fail. (Remember @NODE[foo] is the same as @NODE:HAS[#name[foo]] and @NODE:HAS[#name[*]] will not match a NODE that lacks a name.) What I was talking about is the bug in KSP where a part with MODEL nodes and a rescaleFactor that is not set explicitly to 1.0 will change size on revert / vessel-swap / etc. Try it yourself: give a part with a MODEL node some non-1.0 rescaleFactor. Launch it. Now revert to launch. Presto resize-o. However, since scale = x (i.e. the scale outside MODEL nodes) is _also_ bugged, one cannot simply do @MODEL,* { %scale = 1.6, 1.6, 1.6 } and then @scale *= 1.6. In some cases the nodes will not properly scale. If there were a way to wildcard-change values (i.e node_* = foo) then I could get around it, but as of now...that's why ROMini uses rescaleFactor even for MODEL nodes. You could (and should) give engines realistic TWRs without rescaling--indeed, the first half of ROMini does no rescaling whatsoever, and is all about mass and thrust and Isp. The point I was making with rescaling, however, is that stock KSP only supports three and a half sizes for LVs (.625 doesn't really work well for LVs since your payload will be wider than your LV). That means that if you force 1.25m capsules to use 2.5m rockets, you're running low on super-heavy stuff. If you scale everything up to real life densities as well as TWRs and dry fractions, then things "just work"--old-1.25m stacks work fine with old-1.25m payloads, etc. As to the Mk1-2: huh? It's 4.5 tons. Apollo, in toto, was ~5.8 to 6 tons, which is just about what a Mk1-2 with a docking port, chutes, heat shield, and RCS thrusters is. Pretty close match. That means, at the correct mass and 41% the surface area, you get 41% of the drag (2.44x the ballistic coefficient).

Hurrah!

https://github.com/NathanKell/RealSolarSystem/wiki/PQSCity-and-PQSMod_MapDecalTangent has some docs on those params.

jsimmons, apologies for missing this! SolarPowerCurve isn't needed anymore, stock natively rescales solar panels so they deliver their rated power in (home planet)'s orbit, and uses inv-square.

ModuleRCSFX ignores the resource set by SetResource because it always works off PROPELLANTs. You'd have the same problem if you tried to run SetResource on a ModuleRCS part that started out with PROPELLANT configs, IIRC.

Roverdude added charring to heatshields that use ModuleAblator (basically, darkening them). It defaults to on unless you turn it off. Setting both values to 1 turns things off.

Put this in a cfg somewhere, should do the trick: @REALHEAT { %aeroFXdensityExponent1 = 1 %aeroFXdensityMult1 = 0 }

Moved to the Modeling and Texturing subforum, where this belongs. Good luck!

Analytic mode does the following: 1. Sum up all the fluxes on the vessel (i.e. all internal fluxes, all solar/body radiative fluxes) 2. Calculate a resting temperature based on what would be required to radiate out at that same wattage. Analytic is essentially a "fast forward" button for thermo: it asks "what would be [a simplification of] the final state the vessel will acquire, in thermodynamic balance with its environemt". However, there's an interface you can use especially for this situation: it will tell your partmodule to slow down when the vessel starts overheating.

Alshain, s/he does want annular. Pegasus and Ithacus did not use linear. Best bet would indeed be using the one from Ven's but probably squashing it a bit, if I remember the small version shown for SASSTO. Esme: you might also like the old, somewhat ugly, but still serviceable one in Novapunch. IIRC it had a multitude of chambers ringing it, as God and Phil Bono intended.

SSTO is fairly easy if you use an SSME and are willing to accept a tiny amount of payload. If you mean an SSTO spaceplane, that's a fish of a different water. I built one using RL10B2s and SABREs, but it couldn't make it off KSP's runway (hyperediting into flight worked tho). Not that it could survive reentry of course.

Awesome work! ROMini adjusts scale because for a 1.5t payload, you do tend to need a 2m rocket, and because otherwise reentries are way harder than they should be (you get only ~40% of the drag on reentry with KSP's parts' size and mass, which is almost like saying you're reentering your capsule nose-first). This also allows more "useful for RSS-size planets" engine thrusts--the Mainsail in KSP is little better than an H-1 (8 of them were on Saturn I), and 1/7th an F-1. Oh, and feel free to grab anything useful from ROMini. (If Sarbian allows wildcard matching of values as well as nodes, the use of rescaleFactor could be abolished for MODEL-node parts)

Huh! Interesting. Same sort of thing I cooked up, actually. https://github.com/KSP-RO/RealismOverhaul/blob/master/ROMini.cfg

v10.5.1 * Fix a big bug where CONFIG entry costs were being set to 0. If you're playing RP-0, your upgrades will no longer be free.

That's a bugged installation. What mods do you have installed? I'd also suggest removing RP-0 and re-adding it (either via CKAN, or by going to the releases page and downloading the release zip for .35 [i.e. not the source zip or the repo itself] )

gruneisen: the temperature display was from DRE back before 1.0. Now that KSP itself provides more detailed thermal data (Debug Toolbar [mod-F12]->Physics->Thermal->Show Thermal Data) I guess Starwaster didn't see a need. Besides, there's now two temperatures to track anyway. boosters++ that's a bug in how KSP determines what should be glowing, I guess. It's not supposed to do that until things get above 750K. And....hah. sisyphean: As the OP says, to play in career you need RP-0. RO changes parts and engines willy-nilly, but doesn't touch cost or tech required, so career is basically unplayable without further mods (i.e. RP-0). You will get literally nonsense for career mode without RP-0. Kaboom!: What do you mean? I just checked the OP, it has a nice table of Required, Recommended, and Suggested mods, all in their own cells...

Cool!

Or just turn that bit off in RealHeat: @REALHEAT { %aeroFXdensityMult1 = 0 } stick that in a cfg in gamedata. Or adjust AeroFX the way RO does, the default RealHeat settings are designed to work with RO's changes to AeroFX (no flames at 20km (Earth alt) and 900m/s, slight flames at 1050 at that alt, not much of anything above 25km unless you're at Mach 10+)

Ah. Don't believe so, but the cfg explains how to add. ferram wrote that, and would know more