NathanKell

The problem is that tanks, in KSP, aren't actually tanks. They're stages, with tanks inside. Check out this cutaway view of the Titan II GLV. Notice how there are capsule tanks inside each stage. The issue is that you need to estimate, for a given part, how much of the part's volume can actually be utilized by tanks, assuming two capsule tanks. You can see that the longer (higher aspect ratio height : width) lower stage has more of its volume utilized in tankage, compared to the upper stage. Now, it so happens that one gets a reasonable utilized-volume figure for most KSP tanks by multiplying their LF+Ox contents by five. But it would be the best, long term, to actually go through the parts and figure out the above. Since the users of RF however will often use procedural parts or (in the case of RO) real life rockets' parts (for which we know the tank sizes), it hasn't seemed worth the effort to recalculate volumes, with the exception of spaceplane parts where stock volumes are bonkers.

BadRocketsCo: Realism Overhual includes configs for them, yes. Dunno whether Stockalike does yet tho.

Have an excellent cruise!

joshuadery: yeah, please don't take me as being negative. I do seriously mean it's a noble effort, and you do deserve kudos for it! I will try to contribute to the wiki when I get home and have more time. For things to read, I'd suggest the two stickies in the Dev forum regarding info for developers / community docs. Which reminds me, this thread should actually be in that forum too, so...off we go!

I don't see why the 1/10th config would make a difference. I'll look through the log and try to replicate, but when starting a new game with 8.5 I was not able to replicate the error (and thus released 8.5 claiming it fixed it). It'll be a few days before I am home however. Thank you for the log!

Certainly it does for most monobehaviours that are destroyed; can't hurt to test for parts (i.e. PartModules) though.

Yep, as Agathorn says. You can use this plugin to fix the stock bugs.

OnDestroy() runs when the instance is destroyed, it's the Unity equivalent of a destructor.

Ah, bet they check for mode == Career rather than mode != Sandbox. I fixed that in RF but not PP, I think.

I think it's time to

Midanthrope: That's a side effect of my changing the VAB view limits to be what they were in RSS in .25. I'll try to fix that, but for now it's the price you pay for being able to zoom in and out further.

Again? Argh, thought I had it working. I'll fix it when I get back.

Boris-Barboris, per the Addon Posting Rules one cannot just link to a dll; any download that includes a dll must include a license (and must comply with the license terms of the project it is forked from, if any), and must either include source or a link to source. Also, even in cases where the license permits it (as this one does) it's good policy to check with the author before releasing an unofficial update.

Kamik423, thank you for adding a license to the OP. As I mentioned, however, you also need to add one to your zip.

Bender222: The AJ10-37 etc modeled in RP-0 (a clone of the poodle, or rather Ven's new SPS) does not have restarts. Later Delta engines (starting with the AJ10-110E) had restart capability, and obviously Apollo SPS (AJ10-137) had lots of restarts, but none of the early AJ10s did. Ah, I see (re: contracts/science). Spid: That is a really, really bad idea. RP-0 *requires* SXT. SXT is a parts pack. Your career will not function correctly without it, and creating copies of another DLL and naming it that will just cause problems. The Community Tech Tree is a single cfg file; without it, your tech tree will not function correctly, and if you name some other DLL to that all you are doing is breaking KSP. Please don't.

Kamik423, that's a great first mod! Alas, it's my sad duty to inform you that per the Add-on Posting Rules, you need to add a license to the download zip and to your first post in this thread. If you need help selecting a license, here's a guide.

It's up. 0.9.3 -Fixed for NEAR. -Resave PNGs so the DDS converter can read them.

Let me guess. You're using PROPELLANT nodes in your cfg. Stock bug. Reported during .24, ignored in .25 and .90.

The Mercury craft with its LES was 1.5t; the spacecraft alone was 1.1t for the capsule and another 240kg for the retro pack. If you add the mass of a DRE heat shield, the numbers come up pretty much right. Same with the Mk1-2 pod: if you add to it all the stuff the Apollo capsule had, the mass comes out about the same. Probes is where it gets weird, KSP probes are far heavier than real life ones.

Sounds like "because Jool doesn't have a PQS so never fades scaledspace out in favor of PQS"?

Last night I had no problems with this in RP-0 but I didn't have time to test much. Currently away-from-desktop for obvious reasons. Thanks again for the formulas being exposed, that's so fun to play with (and so useful!).

requimrar: odd, I was very careful when I originally wrote it to avoid line ending issues, but perhaps I forgot when I edited it later and that screwed the whole file. As to some of the target files not existing? Definitely aware of it. It's an artifact of how the script was generated, and causes no issues. That said, thankully a kind contributer has been writing a script to regenerate these, so the pruners should be more solid in future.

When using legacyAtmosphere code, KSP is hardcoded to cut things off when at 1e-6 sea level. To get around that, use a pressureCurve (RSS can do that for you).

EDIT: We are back in business. Some posts that spiraled into fighting and anger were removed. Please be excellent to one another. Whatever our situation, being rude to others won't help them or us.

A noble effort! Kudos! Looks like it needs a fair bit of polishing, though... A few examples--first, I notice you say 'rescaleFactor isn't used often'--that seems contradicted by most cfgs I've seen. Only configs from before the Great Rescaling tend to skip it...Also, it's bugged when MODEL is used. As to MODULEs, did you actually check the KSPFields for each module, or are you just reporting what settings have been commonly used in cfg files? DockingNode, for example, is missing a lot of its settings. Further, the angles and offsets in fx listings just aren't used anymore, they're spawned at the relevant transform...I'd suggest a fair bit of digging through recent threads in these forums to see the current status of this stuff, as a lot has changed from how things used to be.