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.

Ok, I did some testing. I'm afraid it's bad news for Mk2 cargo bays. They are almost surely bugged. The problem plane happens to have 4 of them: 1 large bay centerline, followed by 1 small bay. 1 large bay on both right and left sides. Well, it turns out that the small centerline bay itself was generating 5 times the drag of the Mk2 cockpit. So I then emptied all bays, but otherwise had streamlined body parts attached to the front and back, except the centerline bays which are attached to each other, but had streamlined parts in front and back of the combo. The single most draggy parts are still the large bays, about 10% more than the cockpit when open. And here's the surprising bit, drag increases when the bays are closed by about 50%(!) Now parts inside the bay are shielded when the bay is closed, but closed bays apparently generate so much more drag there really isn't any benefit. Also when empty, the small bay generates about half as much drag as the large bays. After attaching nosecones to all the bay nodes, I saw further drag improvement, but the drag is still significantly more than one would expect for a part not directly exposed to the air. Even so, the resulting improvements are dramatic. A plane that struggled to hit 300m/s at 5km in level flight, now hits over 1000m/s at 5km on a 10° climb.

@bewing Well the arrows seem to generally agree with the action menu values. The largest individual values seems to come from the bays themselves, as well as the "shielded" items collectively. Those items aren't clipping into the outer walls of the bay, and are attached to the inside front and back ends. In the case where two bays are connected, some items cross the empty boundary, and some are attached to the bay nodes. A few parts have some slight clipping into the back end, but into another part, so it should still be covered, no? Either way, they aren't the most significant source of drag. How does KSP calculate if a part should cause drag? Is it by the center point of the object, or the bounds of the object? Would a part with a center point inside of one bay but with bounds that cross into another bay erroneously cause drag? I also understand that exposed nodes along the ships longitudinal axis causes drag, so does that mean unused bay nodes create drag? I can post the plane, but it's in a state of disarray at the moment. No part or physics mods. KSP 1.2.2

@fourfa I think the cargo bays are the issue. I'm seeing huge red lines from the (empty) bays themselves, and quite a bit from a bay that's behind another bay. Additionally, there are a number of parts causing significant drag that should be shielded in the bay. But let me clarify what you said with regard to shielded parts: Do you mean the red lines might be showing erroneous info? Or that parts are causing drag they shouldn't? If the latter, how do I fix that?

So I'm making a spaceplace in the 50-60 ton range, and I don't know what I did, but some relatively minor change now causes it to no longer go to space. I can't figure out what happened, but I think something is causing massive drag that shouldn't be, as it now feels sluggish and underpowered, and this is compared to another fairly similar spaceplane that's 15 tons heavier, with the same engines, it it goes to space just fine. Even worse, I just now forgot to retract the landing gear, and it still outperformed the lighter plane. So something's very wrong. I've tried to figure out what's causing the drag, but no luck. I'm not even sure if it's really drag, but it seems to be the most likely culprit. So far, I haven't any way to even see drag values. Supposedly MechJeb shows atmospheric drag, but I can't find that feature. And some other mods I tried were out of date. At any rate, this will only confirm if drag is the issue, not what part is causing it. Any ideas? Any suggestions to see the drag of parts?

I should probably test more on Laythe instead of Kerbin. It's entirely possible the entry in to Laythe's atmosphere is more forgiving. Kerbin's atmosphere will melt the small intake and small landing gear. For what it's worth, I did find a design that survives Kerbin entry with spedbrakes and a detachable flab covering the intake that has a smaller profile than the heat shield.

As a general rule, if the plane doesn't take off on Kerbin between 50-70 m/s, it's probably wanting wing area. Or if it has a tendency to dip it's nose after take-off (even with SAS) There are other reasons that could lead to these these problems, but those are usually the first warning signs for me saying I need more lift. If you mean to imply that the smaller craft has re-entry issues due to wing area, then no, that's not really the case. Both craft are extremely easy to fly and land. There's no safe angle mainly because of the small intake in front. On the underside is the atmosphere analyzer, and on the rear and slightly topside are other science instruments. But the small intake is the hardest to safeguard. Even if I enter tail first, the aerodynamic forces will eventually flip me forward. Now, it might be worthwhile to experiment with airbrakes, seeing as the heat shield is a little unwieldy. However, it does have the benefit of not having to touch the controls or worry at all, and being extremely forgiving on entry speed and angle. @AeroGav Does it get to orbit on Kerbin? I ask because I'm usually doing my initial testing there, and if a single spark/panther is viable on Laythe, I'm wondering if some of my other failed tries would have worked.

I've tested on Laythe, and landing wasn't an issue. I'm betting you don't have enough wing area.

Yes, I tested entry. It's only the delicate parts that need the shield. Now I did shift things around a little, so I should retest that the strut and decoupler are safe since they peak out, and have slightly less heat resistance than the wings. Yes, with the original craft, I can use high AoA for both slowing and to protect the atmosphere analyzer, however with the smaller craft, there's really no safe angle possible, hence the shield.

Ok, so using the "Science Torpedo" method, I've got a 2.5 ton disposable UAV. Naturally, this isn't a SSTO anymore, but this might be a better option. Atmospheric entry is a problem for the the various science items and the small intake, so the heat shield became necessary, adding .326 tons with the connector. After flying around for a bit, the whole back end and undercarriage with the Juno, wings, gear, and science get detached and the remaining rocket will get back to orbit. (Atmosphere analyzer on underside) @Foxster Maybe you have your reasons for 6 Oscars, but I found that bringing an ESU to LKO from ground only requires 4 with dv to spare.

That's an interesting idea, I'll have to explore that. Also, I just did some quick service bay tests. For rockets of equal mass, the service bay doesn't seem to add extra drag, and it clearly seems better to put stuff in the service bay, rather than just nix it all together and hang it off the side. The exception is when that .1 tons of the service bay makes more of a difference than the accumulated drag effects. In my case, while .1 can make a difference on a 9 ton craft, it is far outweighed by the potential drag when going 1500 m/s in the upper atmosphere.