danfarnsy

So... it's cancer? I know how to cure cancer! My friend knows this doctor who does this thing with this herb... Heh. You're right, of course, but it's a little entertaining to see some folks going through the stages of grief over some forum pages. It's not cancer. We can relax. It is a significant amount of work gone, but it's nothing any of us can fix. You know what you can do? Watch trailers for the new Mass Effect game a few more times. Figure out why you stink so much at combat in Elite: Dangerous. You know, important things.

No.

This is a great idea. Hatches aren't the central point of the mod (though they're cool).

Real one is 1.2 mN/kW, which is maybe a factor of 20 worse than ion engines. Not saying you need this here. Scaling to reasonable gameplay is a great idea.

But if Squad staff are going to tease us by suggesting Kerbin has axial tilt inspiring Kerbal celebrations, you can forgive us for salivating a bit. Throw in some snow, some wind, some Ferram Aerospace, n-body mechanics, maybe some relativistic length contraction and time dilation, and if we want to get really wacky, multiplayer... There's actually a really good mod out there called Real Life, where everything obeys physics, economics, and getting into space is really hard. You get to play as an astronaut candidate and work for years as a pilot, engineer, or scientist before NASA chooses somebody more qualified than you to send into space instead. Maybe you start up your own small company living from one DARPA and ULA contract to the next, spending countless hours submitting grant proposals.

Kerbin has axial tilt and seasons? Are we announcing something? KSP 1.3: "RSS Becomes Stock"

That's odd. Spam appears to be fixed in my save with 0.5.8. I was definitely getting it in 0.5.7. Edit: Nevermind, it only fixed it in pre-launch status. This is why I try to double-check before I run my mouth.

I sometimes add a filler, like xenon, use the 45/55 LFO button, then remove the xenon. It works, but is clunky. It could be useful to have an LFO tank option.

@Nertea You're doing great, man. Manually throttling reactors is more than fine, as tuning PID controllers for even simple systems often breaks as soon as external assumptions change. As a physicist who understands how fast a "simple" problem can become very difficult, you've got my vote of confidence. Sorry there are so many armchair critics. It's understandably frustrating. I've been around long enough to get a sense for whose comments and insights are valuable, and I haven't seen anybody with a solid track record who also had bad things to say about your work. Hah, maybe that's circular: whether forummers approve of your work has become my litmus test for whether they have sound judgment!

Any spacecraft with multiple parts with heat capacities and emissive radiation (scales as 4th power of temperature, so it's a nonlinear differential equation, which very few even have analytical solutions), some types of radiators which lose effectiveness with distance from source, conduction to adjacent parts, heat input from the sun, potential convection issues in atmosphere, the cutoff temperatures at which radiators throttle (therefore pulling less heat per second from cores)... yeah, that's messy. It's much easier to do numerically, but as Nertea said, that has issues with time warp (the larger your step size between calculations, the more unstable numerical approximation becomes).

Politas created the necessary configs, but they're waiting for RoverDude to release a version of CRP he says is compatible with KSP 1.2.1. Now it's just a dependency versioning issue and the peculiarities of how CKAN works (or in this case, doesn't work). They're clearly aware of the issue, and I wouldn't ping either of them. Previous advice still stands: Manually install for now.

Stock KSP also has a settings option for using Earth calendar (365 24-hour days), so it could be more accessible than we're guessing.

That was a very exciting read. @Daishi, is this still on your radar?

Still working to get it resolved, but it turns out to be messier than I'd hoped. Don't anybody hold your breath. If you install via CKAN, it will be missing the required /GameData/REPOSoftTech/RSTKSPUtils, which is why TACLS will not work. The most obvious fix on the CKAN side will create unacceptable conflicts with other mods from JPLRepo. This is not an issue for manual installations, of course, and that works just fine.

Fixed. Thank you. There are a lot of cobwebs in that wiki. Maybe we should clean it up some day.

Correct. This feature was a response to previous user complaints about Kopernicus's incompatibility with KSP updates. It's a bit aggressive and preemptive, but it doesn't take much time reading this thread (or previous Kopernicus, or sarbian's threads, or ferram's, or...) to understand the motivation for the version lock.

Second line of the OP says, "You need to install ModuleManager for this to work." First place to go before asking questions in a mod thread is to at least read the OP and see if it has instructions for installation or guidance for what is installed. If you want to know how to install MM, go to the MM thread and read that OP too.

The things you amazing people make possible...

I'm not certain, but it looks like you can simultaneously know where this airship is AND how fast it's moving.

Which version of Kopernicus? Which version of New Horizons? Kopernicus disables itself if run in a version of KSP it wasn't built for. At least, it did for the versions you're talking about. Example: Kopernicus 1.0.3 was the first version built for KSP 1.1.2, so running that version (or later) of Kopernicus in KSP 1.1.0 will not work. I'm not sure where you can find a KSP 1.1.2 version, but the latest version of NH (v2.0) was built for the (coincidentally numbered) version 1.1.2 of Kopernicus running in KSP 1.1.2.

This is what a "grouchy" kerbalnaut looks like. He takes pictures, gets manicures, refuses to do work unless you bring him supplies...

Here's a dumb question for somebody who doesn't mean to be the dumb guy, but are you using KSP 1.1.3 or 1.2? Kopernicus hasn't been updated for KSP 1.2.

While it is still a good idea to split the config files for RF and MFT, the particular bug I was reporting wasn't due to this, apparently. It was a MFT issue which taniwha fixed with an update this morning. FYI.

I've got a null-reference exception that stops KSP 1.2 from loading using MFT 5.8.0, in combination with at least two other mods: Kerbal Planetary Base Systems and Procedural Parts. I reported it here in the KPBS thread. I was unable to resolve the issue by trying to separate the MM references for "type = ElectricPropulsion" in :NEEDS[RealFuels] and "type = Xenon" in :NEEDS[ModularFuelTanks] but when I removed KPBS's MM patch for RF/MFT, the exception occurred instead when applying MFT to Procedural Parts. I thought the issue was with tank definitions (and the difference between RF and MFT tank types), as KPBS has :NEEDS[RealFuels|ModularFuelTanks] with "type = ElectricPropulsion" instead of "type = Xenon" for its xenon tank. However, changing it to "type = Xenon" didn't resolve the issue. Moreover, the problem doesn't occur in my KSP 1.1.3 install which has MFT, Procedural Parts, and KPBS, with identical tank definitions and config files. With Procedural Parts, the displayed stuck part was proceduralConeLiquid. So... from there, I'm not sure. Best guess I've got is the reintroduction of MarkWindowDirty (), but, like I said in KBPS thread, I'm just guessing now. Otherwise, removing MFT allows KSP to load.

It should have been correct, unless I misidentified what the problem was. But changing it to "type = Xenon" didn't resolve the issue. Neither did splitting it into two entries (one with :NEEDS[RealFuels] with "type = ElectricPropulsion" and one with :NEEDS[ModularFuelTanks] with "type = Xenon"). Getting rid of the config file let it progress until it ran into the error somewhere else. I'll admit I wasn't comprehensive, and I may have forgotten to delete the MM cache between changes. Here's why I think it might be something else: the confusion with tank type definitions should have existed in KSP 1.1.3. In that install I have MFT and KPBS, and it loads just fine. RF introduced ElectricPropulsion instead of Xenon well before that (according to the RF change log). I just verified that MFT's definitions and KPBS's config files haven't changed between then and now. I wonder if it's somehow connected to @taniwha reintroducing MarkWindowDirty () in his latest update? I'm only guessing, though, since I don't follow exactly what he's doing with that in his code. I just know it's the first thing listed when the null reference exception is thrown. I've removed MFT for the time being. Talk about masking the problem, eh?