AlphaMensae

@NecroBones, I have a favor to ask, could you add (or modify) a decoupler (just one size) that is truly hollow (i.e. no colliders) on the inside to match the visual appearnce, much like the Mk1 Structural Fuselage? I have use for such a thing as an interstage (with appropriate scale changes), and with the mesh-switching capability I could make all sorts of matching interstages. As you may have guessed, I found out the hard way that the FTP decouplers are not actually hollow.

The only things that would get me hyped would be: > No more memory leaks and stuttering and other bugs and an SAS that works again. > Graphics overhaul > Rocket part overhaul > Career mode overhaul If you're a non-English speaker, ok, good news for you. For me, it's a big yawn, sorry.

@NecroBones, Yup, that's exactly what happens, one dome looks and switches like normal, the other is Z-fighting. I'll go ask in the IFS thread too.

Ok, I'm experimenting with manual part welding to make custom spacecraft out of existing parts, and I thought I'd weld a Mk1 parachute into a descnt pod I'm making out of a nosecone from MRS. All I've done is include the part MODEL and all the chute modules from the Mk1 .cfg. Well, the chute can be operated like normal, it shows up on the staging stack, the deploy parameters can be adjusted, and it does deploy when staged. The problem is that it doesn't work like normal. When semi-deployed, the pod and chute turned to near horizontal and actually started climbing. The F12 aero overlay showed a strong body-lift line from the pod. After a while the pod started descending again, but when the chute fully deployed, it turned to a 45-degree angle, with the overlay showing equal-length drag and body lift lines 90 degrees apart. The pod never got into the usual vertical retrograde-pointing position. Putting a regular separate Mk1 chute on top of the pod works just fine, so there's something about welding one into a pod that's screwing things up, and I don't know what it could be.

@NecroBones, I'm trying to make a part using two of the FTP dome tank models manually welded togther, but only one of them gets the texture mesh and switching capability (using IFS). Is there a way for the texture meshes to be applied to both of the part models, either individually or collectively? Simply including a second mesh-switching module doesn't work, just duplicates the variant buttons.

@Sigma88, Ok, don't laugh , but this is a question about SD 0.4.3 with Kopernicus 0.6.2 in KSP 1.0.5 (don't ask either ( ). I noticed a bunch of exceptions showing up in the Alt-F2 debug console. Suspecting it might have had something to do with Kopernicus, I removed all other mods, but then no exceptions showed up. Adding in SD made the exceptions appear. This was even without my Kopernicus or SD change .cfg files being loaded, just the mods themselves. SD does appear to be working fine, the changes did work when I load them, but I am alarmed by the exceptions. Are they harmless? Screenshot of the debug console: KSP Log is here. Output Log is here.

@NecroBones, Ah, thank you, so that's what that section does! Never really looked that far. So I just need to copy the ones I don't want into the part where FTP is present and appearance switching is turned on?

Yep, Kopernicus is installed correctly, as all my other changes (moving stuff around, adding stuff via cloning stock moons, changing orbits) show up as expected. I saw the "FOR[]" line in the older post, was a bit confused about it. Does it go in the main "@Kopernicus:AFTER[Kopernicus]" line at the top? And what name do I use? I did Hyperedit a probe to Laythe at a 100K orbit. At first I thought I saw more land, as there was a blur of brown below the probe. Increasing the otbit to 400K though made things look like the normal stock appearance. I also tried to use Kittopia, but got lost in it, couldn't find where to adjust VertexHeightOffset in the 5 million () PQS setttings.

@The White Guardian, A Google seach brought up this post of yours, as I'm trying to lower the sea level of Laythe, the goal being to make more land visible--that is, if such a thing is even possible. I used your example, but there was no visible change to Layhe, whether the offset value was 100, 1000 or even 5,000. Here's the entry in my Koperncus .cfg:

@NecroBones, Is there a way to have only specific meshes from Fuel Tanks Plus show up as options, or even use just one texture, e.g. the Black and Soyuz ones or just the Saturn one? I'm making some custom parts using the stock fuel tanks models, and I'd like to to have only certain FTP textures be used for them. Simply deleting the unwanted ones from the "objects = " and "objectDisplayNames =" lines in the MM patch files I've made didn't work, the mesh is broken, with the Z-fighting result of what appears to be all the textures trying to be displayed at once. Restoring the lines to the orginals, with all the mesh options, made things work again.

Claw's bug-fixing-by-mod is what got him hired for the 1.1 and 1.2 development. He knew his stuff. And many of hix fixes and extras are now stock in 1.2 Of course, he's seemed to have disappeared post-1.2 release, so who knows if he'll ever continue this mod. Or even just do a 1.2 version as a last service to the community.

Yes, @linuxgurugamer does it again! Thank you very much for doing this, this was literally the last mod I was waiting for to be updated for 1.2.x I'm altering the tech tree for career mode so that the command seat is the only way to do manned flights (to put it loosely ) at the start.

Yes, please, and thank you! What's one more mod to maintain? This is what I use for docking help as well, as it provides the "missing piece" in the navball.

@FreeThinker, on Spacedock you or maybe Spacedock apparently named the 2.2.8 IFS update as one for KSP Interstellar Extended, as that was what the update notice email I got said. The download was only 755 KB, so I figured it was really IFS...also, on Spacedock there is no version 2.2.8 for IFS in the changelog, only goes up to 2.2.7.

Yeah, I've seen it used in modded unmanned-first careers, and it can make such a career all too easy in the early phase--just way too many parts; it's why BDB needs to be properly balanced in custom tech trees.

BDB is BlueDog Design Bureau, a massive real-like USA historical rocket parts collection (it's like the counterpart to Tantares). It's a good stress-test for a custom tech tree, as it already overloads the stock tree.

No, he's still alive, just moved on from KSP to something else, i.e. left Squad. Poor choice of words, I guess.

Yep, it was a design decision by KSP's creator, Felipe (HarvesteR, now moved on), to have a 1/10 scale solar system so it would be simpler and easier for rocketry newcomers. The delta-V requirements are so much less, and fuel tanks and engines don't have to have realistic specifications. Real Solar System turns the stock fictional 1/10 size solar system into the actual full-sized one.

Community Tech Tree just expands and extends the stock tree, providing additional tech nodes for various mods to place their parts; it does not alter the existing stock tech nodes. It's great if you have large part mods (like SpaceY, Near Future, USI MKS, KSP Interstellar, among others) and want a bigger stock-like tree to hold them. CTT adds some very high-science point tech nodes beyond the end of the the normal stock tree, providing some late-carreer goals Engineering Tech Tree also adds new nodes, but it also completely changes the stock tree into a more logical, realism-based one, changing the whole career progression. ETT (and other mod trees that rework the stock tree) is great if you're tired of or can't stand the silliness of the stock tree and want a whole new career (or science mode) experience.

@NecroBones, would it be possible to add built-in decouplers to the conical payload bay, at least for the front? I saw that KWR's petal bay has them, so I tried making the 3.75m end of the SpaceY one a decoupler also, but it didn't work. Missing something obviosly.

You don't even need Toolbar installed to get the bug, just the query from a mod to see it it exists is enough to trigger the bug.

Yes, there was a Squadcast last week.

I've been closely watching this discussion, as Take Command is a necessity for the revamped tech tree I've been making, because I have it that the command seat is the only way to have a "manned" craft in the early career; the actual pods and cockpits come several tech tiers later. Without being able to spawn directly into the command seat, you're limited to only unmanned stuff...which is the intent actually, but I want to do some crazy experimental "manned" stuff too...like putting a reduced-size Flea onto a girder, attach some stubby wings and elevons, put on a command seat...and launch; very quickly you get the Juno parts and basic landing gear, enough for some primitive flying action.

It looks like he just massively edited the stock tree, creating the new horizontal-branch layout by moving the stock nodes around and adding the new HP Tree-specific nodes to fill it out. That might actually be the better way, to just edit the stock nodes and use them for other purposes, though I think you should be able to delete nodes with, e.g. !RDNode:HAS[#id[basicRocketry]]{}

Hmm, would !TechTree{} delete the stock tech tree? Otherwise I don't think there is a way to simply delete the stock tree with MM in one simple command. You just have to edit/redefine/move the stock nodes around; check out @pap1723's Historical Progression Tech Tree for an example of redoing the whole stock tree into something very un-stocklike.