Tychonoir

Just installed Kcalbeloh, and everything seems to work, except I was getting weird graphical glitches when viewing the inner planets in the map view. Basically, they looked right when facing the black hole, but the background space would glitch with residual images if facing away from the black hole. Outer systems seemed fine. I tried hyper-editing a ship to the locations, and same issue. I thought this might be related to a visual mod, but the problem persisted even when turning them off. Is this a known issue with a way to fix?

This might seem silly, but how do you provide sufficient electrical power for the advanced engines that are really power hungry? I don't see any generators or power plants that can supply these levels of electrical power. Possibly related, but I also occasionally see references to part names that don't appear anywhere - though maybe those comments might be referring to earlier versions of the mod. (Sandbox mode with all parts available)

It appears this mod doesn't account for different intake performance? Is it assuming that the intake air is always met 100%? (I replaced all intakes with nosecones and it still thought my plane would fly) While that seems like a reasonable shortcut, I believe I've noticed performance differences, particularly in regards to the effective base speed stat and performance vs mach.

Aaannnddd... K Crew Compartment K Mobile Lab Both reuse the cockpit interior (KSPIVA) as well, and these are far more egregious - it doesn't even fit in the part! It doesn't look like the proper IVAs are present in the mod files, either.

I did even more investigation, and as far as I can tell the other two K interiors aren't a part of the original mod. The part cfg for all three K cockpits all reference KSPIVA (K Space Plane IVA, I'd wager, since that's the one that shows up as correct). I was hoping that it was a cut and paste job that just referenced the wrong interiors. However, looking in the 'Spaces' folder doesn't seem to have any likely candidates for the K interiors and the ones there all appear be accounted for.

Hmm, it looks like you're right, it just wasn't as noticeable on the stock parts. Probably because they have less mass.

I did some more investigation. The misalignment is due to parts bending from physics. (Cockpit was attached to a part bending from weight - cutout view model doesn't bend with outer model, causing misalignment) When time warping, the parts snap back and are aligned. It should be noted that the stock cockpits do not exhibit this behavior. Lights not working is only on 3 cockpits - 2 of the the incorrect model K ones, and the Mk 2. Here is an image showing the incorrect models: Example Image

It appears some of the cockpits have the wrong IVA models, particularly the K versions. The effect is that of two models overlapping when activating the cutout view, and also notice the external window lighting doesn't work with the wrong model ones. From inside, you can see the outer geometry we are clipped inside of. Here are the ones I've noticed: K Avatar - Uses K Space Plane model K TAV Shuttle - Uses K Space Plane model K Space Plane - Correct model but misaligned J (All) - All correct, but misaligned 2.5m (All) - Correct Mk 2 (OPT Version) - Correct Side note: I'm new to OPT, but are there no H cockpits?

It appears some of the cockpits have the wrong IVA models, particularly the K versions. The effect is that of two models overlapping when activating the cutout view, and also notice the external window lighting doesn't work with the wrong model ones. From inside, you can see the outer geometry we are clipped inside of. Here are the ones I've noticed: K Avatar - Uses K Space Plane model K TAV Shuttle - Uses K Space Plane model K Space Plane - Correct model but misaligned J (All) - All correct, but misaligned 2.5m (All) - Correct Mk 2 (OPT Version) - Correct Side note: I'm new to OPT, but are there no H cockpits?

No, wrong scale as in wrong thrust scale. You end up needing dozens of engines. Which is very Kerbal, but a bit annoying. I'm already using 6 engines, and this is <100 tons. And it's not just the engines, but the wings and plenty of other stuff. But I'm not trying to turn this into a Mk3 bashing thread.

I don't particularly care for the Mk3 parts, and the appropriate engines are the wrong scale.

My original plan was to create a cargo SSTO that could carry 4 large Mk2 bays worth of cargo, land at Mün, and return to Kerbin. This turned out to be a much bigger challenge than I though it would be! As the plane got bigger, it needed more engines, more fuel, then it couldn't land anymore, so needed more engines, more fuel, etc. So I tried going simpler with only 2 large Mk2 bays. Still took quite a bit of trial and error, but I finally did it. As a craft, it's a delicate balance of size, mass, fuel, cargo, and power. 76 tons, 3.5k - 4k ∆v after reaching LKO. How did I do?

Two versions of a versatile cargo spaceplane in the 70-75 ton range. Can lift half its weight to orbit (orange fuel tank). Each version has 4 large Mk2 cargo bays with Clamp-O-Tron Jrs, and can fit an orange tank in the center attached via a clamp-o-tron port. They both have full RCS control, solar panels, probe control point, and relay antenna. The first version is a bit harder to fly with an orange tank, it's front heavy, and you'll need the full runway to get off the ground. But it is a simpler symmetrical design and carries the tank from its end. Carries 2 passengers. The relay antenna is clipped when retracted, however. The second version has the center portion raised up to carry an orange tank with a clamp on the side, and this is a more stable flying position. This also allows the carrying of more awkwardly shaped cargo. Additionally, it has room for 4 passengers on the left side, and a stowed mini-tug probe with a claw in its own bay on the right side. Both versions get to orbit the same way: Fly level until the Rapiers can get to 500 m/s, then pitch 10° up and maintain until 70k, then circularize. If carrying an orange tank, 2 additional FL-T800 will need to be fitted in the cargo bays (1 on each side). This will get you to about 60k, then use the nukes to get the rest of the way to orbit. Alternately, there's still room for even more fuel in the cargo bays. (If part of a larger mission, the additional tanks can be clamped in as needed using the docking ports.) Keys: 1) Rapier toggle 2) Rapier mode toggle 3) Nuke toggle 4) Ladder toggle 5) Cargo bay doors, Service bay doors, Clamp-O-Tron shield, Cargo bay lights 6) Claw toggle 7) 8) Solar panel toggle, antenna toggle (Make sure fully retracted before closing doors, or they won't register as shielded.) Download: https://kerbalx.com/Tychonoir/Bulk-Spaceplane-Medium https://kerbalx.com/Tychonoir/Bulk-Spaceplane-Medium-Mk2

Ok, here's where things get weird. I just made an example plane with the intent of using it as a simple demo, and I could reproduce none of the problems. Not a single one. So I went back to the problem plane to try to figure it out what was different. One thing I noticed, is that the bays aren't connect perfectly - there was a teeny tiny overlap. I thought it was odd at the time, but it's where KSP wanted to snap them together despite several tries. Eventually I just shrugged and figured that's just how they were. But on the new plane, there was no such overlap. Hmmm. So I went back and removed everything from they bay, deleted it and reattached a new part, then put everything back together. This has appeared to fix the shielded item drag, and the open nodes bug, but I'm still getting inverted open/closed drag values, but I can't reproduce this on the new example plane. I'm starting to think that there's something wrong with the file, and the solutions is increasingly looking like, "rebuild the plane from scratch."

Additionally, I'm finding that most items supposedly shielded are still producing drag in a closed bay. I haven't been able to isolate what criteria causes them to still produce drag, but so far anything connected to a bay node causes drag. And some items connected to those items cause drag, and some do not. Not sure why. None of the items are clipping into the bay walls. (Although the default position of node-connected items might clip a little bit - the way some objects are shaped, they can't be totally unclipped from the surface with the move tool. However, the nodes between two bays have nowhere to clip into.) Let me know if you can't reproduce any behavior. If not, we'll have to try to figure out what the differences are. And as far as appropriate drag values for parts, the bays are producing more drag that the fuselage parts that have exactly the same size and shape, and typically more drag that parts they are connected behind. That alone tells me something is off, but that's a minor point compared to all the other problems.