NathanKell

Moving this to Modded Install Support. While you did a *great* job of actually listing the mod versions (almost everyone forgets >.> ) we also need your log file. Please have a look at the "How to get support" sticky.

Or read the OP's changelog, which says that was an error that was corrected. Always update to the latest version.

Myrcia: KSP Windows x64 is not supported by RO, or by many required mods for RO (and by not supported I mean "won't work"). walkinator: Update RSS. My fault. Felger: as you imply, the problem is that RT doesn't simulate bitrate, it just simulates "in range vs. out of range". Whereas in real life, there isn't some magical threshold, just SNR (and thus error-corrected bitrate) goes down.

There is a dated Kethane config that eardrom (???) I think drew up for RF. I have no problem with ISRU, and I don't think it's cheating; I would love to see a complex ISRU adjunct to RF (although I would probably never play it, having not gotten out of LEO in ages...) But while I wouldn't phrase it quite the way regex does in his inimitable style, there is something a bit funky about on the one hand playing with Real Fuels, and on the other mining stuff that can be turned into any of them. (Thus my remark about an ISRU chain).

One of your engines is requesting a propellant (a RESOURCE) that doesn't exist.

Just as a general note, let's not confuse "is this version more or less stable" with "does this version, unmodded, use more memory." Because if you *add* the same amount of memory-using mods, to an install with a higher existing memory footprint, you are more likely to get occasionally out-of-memory crashes than you were before.

Welcome! Are you thinking of Planetes Co Heatshields? I think they were by Yorik, you can try PMing her/him.

Sorry, that makes sense. If you convert it to use real resources in a real resource chain at real rates, then yes it makes sense to use with RF.

Changelog v8.2.1 *Fix typo in camera clipping that made the ground flicker (at least it wasn't another loader bug). *Correct version this time in assembly info.

pingopete: Sure! Not a problem. If you change your github link to point to your repository, then people can just click the "Download ZIP" button on that page to download the current state of the repository. Doesn't get easier than that! (You can even link directly to that link) You can also make links to the release system, which I see you're already using. I handle all my releases via the release system, for the record. Note that if your actual release includes nothing other than what's already in the repository, you don't have to upload a separate file; a zip of the repository at the time of release is automatically created ("Source code zip") and that can just be downloaded. If you want to do some work that isn't stable enough for even a dev release, you can create a branch and do the work there, and people can still download from master. Then, when things are stable, you can merge that branch back into master. Finally, you will need to select a license. I suggest CC-BY-NC-SA, since as it is a derivative work of RSS (more or less), and RSS's license is somewhat more restrictive than EVE's, it will need to ensure "derivatives allowed" and "no commercial use." Expect pull request(s) shortly

No (crewed craft) heatshield has been hotter than 1530C, I believe (constant from Mercury through Shuttle, more or less). No idea what the max on Stardust was, or ICBMs, but probably close to that. So 1700 maxtemp sounds reasonable. Here's a way to find out. Give them 0 reflectivity, then tweak the HeatMultiplier in the debugging window until they're surviving. Then give them reflectivity of 1.0 - (new heatMult)/25 Should give you a rough estimate of what they need.

KSPFields are usually just members, and as DMagic said are public. If you already are referencing whatever defines OtherModule (let's say it's a stock Squad module like ModuleParachute) ModuleParachute otherModule = (ModuleParachute)part.Modules["ModuleParachute"]; otherModule.bar = 10;

You're going to want to use 0,0,0 as the direction, since mirroring doesn't (the wing on the other side is flipped...). As for reflectivity, probably something in the 0.9 range IIRC. Needs mucho shielding.

Preliator: I was busy yesterday. Please don't keep requesting, I did get your PM.

RftS isn't really updated yet, sorry

Nope, just needs a search-replace for the paths. The changes to FAR are in FAR, not in somehow making a 3m^2 wing into a 4m^2 wing.

The current log shows you alt-tabbed out of KSP very soon into the loading process, and nothing after that until you quit KSP normally--no crash at all.

You could also write a module that sits beside the stock module, and dynamically adjusts the stock module's power draw based on its brightness/dimness.

If your class is a PartModule[-derived class], and you thus have a MODULE{} node in a part.cfg that refers to your PartModule, then the only KSPFields you will see will be the ones in *your* MODULE{} node.

FennexFox: For two nodes A and B, where A's antenna has a shorter range than B: maximum connection distance = rangeA + sqrt(rangeA*rangeB) Range of a node is calculated as: the range of the longest-range dish pointed at the other node, OR the range of the longest range omni antenna, plus some fraction of sum(range of all other omni antennae) (I think maybe 0.25? Check the cfg)

The ramjet is from Taverio's Pizza and Aerospace. The VULCAN is a config in RftS for NoMrBond's MACE engine.

Not sure where you picked that up; AFAIK it isn't true at all.

I hate to semi-self-plug, but it's worth considering realism mods if you're going to use it to teach. See the Realism Overhaul thread (sig), which gives parts real life stats, and uses various other mods to make KSP as close to real performance as we can make it (obviating most of Franklin's concerns). Here's an example album from one of our users. From much older versions of the mod suite, here's RISAT-1 and Cassini-Huygens (Note that while planet names cannot yet be changed, all details are correct). That said, even KSP unmodded is a great teaching tool for (Keplerian) orbital mechanics; as the cartoon indicates, it's great for showing you exactly "what will happen if I do this?" in orbit.

Added info. Here's all-stock stats, just thrust corrected. Engine Mass Thrust SL Thr. IspSL/V LV-1/LV-1R 0.03 4 3 220 290 24-77 0.09 20 17 250 300 48-7S 0.10 30 26 300 350 LV-909 0.50 50 38 300 390 LV-N 2.25 60 17 220 800 Mark 55 Radial 0.90 120 109 290 320 Aerospike 1.50 175 174 388 390 RAPIER (Rocket) 1.20 175 156 320 360 LV-T45 1.50 200 173 320 370 LV-T30 1.25 215 186 320 370 Poodle 2.00 220 152 270 390 Skipper 3.00 650 562 320 370 Mainsail 6.00 1500 1333 320 360 LFB KR-1x2 6.00 2000 1706 290 340 Kerbodyne KR-2L 6.50 2500 1842 280 380 S3 KS-25x4 9.75 3200 2844 320 360 And finally, assuming all engines are on an equal-tech-level playing field, here is my quick rebalance (keeping mass as a given): Engine Mass Thr ThrSL IspSL/V Gimbal LV-1 0.03 4.0 1.1 100 350 0 LV-1R 0.03 3.0 1.6 200 370 8 24-77 0.09 10.0 9 310 345 8 48-7S 0.1 12.0 6.3 200 380 2 LV-909 0.5 60.0 23.1 150 390 3 Mark 55 Radial 0.9 140.0 133.8 325 340 8 Aerospike 1.5 175.0 150 330 385 0 RAPIER (rocket) 1.2 175.0 160 320 350 2 LV-T45 1.5 200.0 177.8 320 360 4 LV-T30 1.25 215.0 193.8 320 355 0 Poodle 2 210.0 51.2 100 410 4 Skipper 3 440.0 289.5 250 380 2 Mainsail 6 1000.0 929.6 330 355 2 LFB KR-1x2 6 950.0 868.6 320 350 1.5 Kerbodyne KR-2L 6.5 850.0 425 200 400 2 S3 KS-25x4 9.75 1800.0 1747.8 335 350 1

It's due to FAR. FAR caches wing interaction now, so whenever a proc wing changes, all wing interactions* need to be recalculated. *Ferram suggested "only within a certain area" but I figured better safe than sorry. If it gets very bad, we can optimize. Oh, but check your log in case you haven't updated FAR and it's spewing exceptions, thus causing lag. :]