NathanKell

FAR + Procedural Wings Note that DYJ needs to release a patch for it to work with FAR 14.3 though...

Engines already have that taken into account; heatProduction is always reduced in proportion to maxTemp reduction.

If you want to *deprecate* the part (i.e. not kill vessels that use it, but make it not show up in the editor) that will work. If you want to literally hide the part from KSP, you can do !PART[foo] {} and actually delete its config before it's compiled, leading it to not be compiled. Same caveat applies regarding its textures being loaded anyway, though.

We eagerly await your pull request to fix it.

No it is not done by MM. It is from loooooong before MM supported wildcards.

Download this version: http://jenkins.mumech.com/job/MechJeb2/lastSuccessfulBuild/artifact/jenkins-MechJeb2-341/MechJeb2-2.4.0.0-341.zip EDIT: this is a direct link to what steve_v suggested, but since #340 (the official release) had some issues, I highly suggest #341, what I linked.

Renegade: In comparison to an F-15, it is. (Note that the Douglas D-558-3 was rejected because its heat shielding was too *good*, however >.>) The SR-71 needs a very special skin structure for M=3+ flight, rather more than the XB-70/XF-108 was going to need for M=3 flight. M=5+ is...much worse. Yes, of course in comparison to the STS Orbiter it needs far less shielding; but it certainly *has* heat shielding, and not the minor shielding the XB-70 was given.

Ph34rb0t: Check my post immediately above yours. xXIndestructibleEVAXx: I am aware of no interaction issues between this and RemoteTech.

Problem is that KSP (and mods) require certain sizes of certain icons. Like 38x38, which is not divisible by 4. It's worth checking that icons don't appear to shift/stretch/shrink after conversion/resize-to-4power.

I said by Meta Materials, you will not have limits; that is not the same thing as saying, *until then* in the tech tree you won't have limits. My assumption (perhaps invalid) was that the screenshots were from earlier on in the tech tree, where things are limited. Regarding procedural engines: not happening any time soon. At *best* I will keep this mod *working*, which I stepped up to do because no one else had forked by then. I am not in a position to code gigantic new features, sorry. (Although, as always, pull requests are very welcome!)

Note that RSS has just updated quite a bit. (The perils of modpacking! ) Also: FAR is not on the rec list in the OP. Also also: the original 6.4x install seems to have rather more stuff than this--like launchsites (?)...

As CKAN will natively support github release tags, neither taniwha nor I see much point in adding .version support, and the way our build and packaging scripts work .version is a bit of a pain. You could ask AVC to support CKAN's metadata, though!

As a moderator, let me just point out that civil discussion is very possible, and by no means unproductive. Further, while modpacks tend to raise the ire of many modders, package managers offer the same ease of use to the end user without the down sides of modpacks. Here is a recent thread about a package manager, and there is a second one under development in the Addon Tools and Applications forum. Further, there is nismobg's excellent Community Mods and Plugins Library for a catalog of mods, as well as the one TheAlmightyOS is starting in this subforum.

D'aww. :] Procedural Parts and Procedural Wings and TweakScale make many, many things possible.

xXIndestructibleEVAXx: If your engines don't gimbal, you won't have enough control. In stock, where the "air" doesn't really apply much force, it doesn't take much torque to turn. In FAR (and real life) where things reorient to keep the center of mass in front of the center of pressure, it may take quite a bit of torque to turn at all. Reaction wheels won't cut it.

I have just confirmed a Mk1-2 pod from 250x250 reentering with perikerb of 40km is absolutely fine; temps don't go over 450 even on ballistic descent, chutes popped at subsonic, no problem. Currently doing a trans-munar reentry. EDIT: Also fine.

If you've actually used KSP mods, rather than being used to other games, you will find that KSP mods *don't* have trouble working with one another. We don't collide resource indicators, we don't need to recompile the game's own dlls, etc. The only issue that regularly makes using many mods difficult is the RAM limit, and mod packs don't make a difference at all there. That said, modhat ON, this thread about addon affairs is going to General Addon Affairs!

Indeed that is the case. GameDatabase URIs don't have extensions.

Wonderful! Thanks!

It is a big thread. Thought I had that on the OP, but apparently not. PM on the way.

Changelog v8.1.2 *Fixed normal map loading *Added ability to set both far and near clip planes in cfg, added cfg support for camScaledSpace (camScaledSpaceNearClip like cam01FarClip in cfg) *Water now no longer disappears when close (by setting cam01NearClip to 1)

VonFrank: guess what. We tried that in .24. It didn't work. We still got tons of (rude) support requests, got our mods blamed for stock issues, got users offering bad advice as to how to "fix" things, or saying "lol ignore the incompatibility warning, ~so kerbal~" and on top of that could do nothing to help anyway. Apparently no amount of warnings is enough for people to pay attention and respect them. For that reason, the official download will not support KSP Win x64 until KSP Win x64 is stable. I have said on this thread before, and will say again, that if you personally (or any other user) wants an unlocked copy, I *will* distribute it by PM, on condition that it is not redistributed and that you agree to neither ask for nor receive support from me or any other person.

My policy has been, if I don't care enough, to "take partmodders at their word" as to how much tank volume is available (as you speculated). If I *do* care enough, I measure with a stretchy, try to figure out the volume utilization for the shape, and then correct for something like "is it a service module with other gadgets in it." Starwaster: that's in the TANK_DEFINITION though, not the ModuleFuelTanks module...

And yet those of us who deploy parachutes at sane altitudes (and fly sane reentries---oh, and use the current version of the plugin) somehow, magically, don't experience this "bug." Funny, that.

Day 1 Year 1 is Jan 1 1951 at midnight GMT. Since KSP thinks *every* year is 365 days (oh, and make sure your settings are on "Earth time" not "Kerbin time" in KSP's settings menu), you will have to figure out what day of the year Oct 15 is, then offset by the number of leap years since 1951.