[1.12.x] Mark IV Spaceplane System (August 18, 2024)

[Jarin]

Okay, testflight of @sh1pman Spaceplane 1, amazed this can go supersonic at all, but it flies like a dream. Impressive. 300+kN drag on front pieces, 700+ on middle fuselage and each cargobay. Nearly 5kkN drag on the whole craft at mach 1. And it barely needs half throttle to hold there. That's some hefty thrust. 

Let's compare to Spaceplane 2. Same flight profile, holding at mach 1 at sea level... and at full throttle it hits a wall at mach 1.06. Let's see what the problem is. The cargo bay drag looks just like it should, each of the bays having about half the drag of the double-length ones, so there's one theory gone. Total drag is through the roof though; way higher than Sp1. And hello, the 'iguana' tailpiece has over 1500kN drag just by itself. That looks to me like it's not occluded. Let's test that... and on the SP1, it is completely occluded. The tailpiece on Spaceplane 1 has 0kN drag. 

So the question isn't just "how come Sp2 can't get to orbit" it's also "how come Sp1 can?" It obviously thinks that the tail is fully protected by the cargo bay, somehow. I re-attached everything on the rear to confirm that all nodes are in the right spot, but I'm baffled here.

 

Bottom line, Mk4 'iguana' Tailpiece, when connected to a CRG-120 cargo bay is not occluded at all, and performs like a brick wall in the airstream. While the same piece attached to the back of a CRG-240 is completely occluded and treated as if it's inside the bay itself, with no aerodynamic effect at all. I have the same tail on my Mk4 testbed craft, but it seems to be jut fine there, so I would say the issue is something on the rear node of the cargo bays. 

Edit: Tested a bit further by stuffing a Mk4 drone core between the bay and the tail. On Sp1, the core has 0 drag and the tail has 'normal' drag in the 150 range. Craft comfortably goes supersonic. Same edit on Sp2, the core has... 0 drag, tail has normal drag. Craft comfortably goes supersonic.

Whut

@Nertea, help, this is breaking my brain.

Edited February 1, 2017 by Jarin

[sh1pman]

19 minutes ago, Jarin said:

And hello, the 'iguana' tailpiece has over 1500kN drag just by itself.

Wow, this is really, really weird.

The iguana tail piece seems to be massively bugged. But it's fine if I stuff something between it and the cargo bay. 

Just tested the Mk4 dual adapter tail piece, same deal. Both seem to be completely not occluded if connected directly to half-length cargo bays.

 

[Jarin]

28 minutes ago, sh1pman said:

The iguana tail piece seems to be massively bugged.

The drone core had 0 drag in both tests, so I'm still leaning towards the cargo bays being the culprit. The tail works fine with other configurations.

[Nertea]

That seems to have tracked down one problem. Cargo bays are defined spherically, so the large cargo bay has a very large sphere defining its test radius. I can replace that with two smaller spheres which will more accurately model the bay area.

 

[Jarin]

4 minutes ago, Nertea said:

Cargo bays are defined spherically,

Wait, they're what now? Do stock parts do that too?

... reminded of the old physics joke "first consider a spherical cow..."

[sh1pman]

12 minutes ago, Nertea said:

That seems to have tracked down one problem. Cargo bays are defined spherically, so the large cargo bay has a very large sphere defining its test radius. I can replace that with two smaller spheres which will more accurately model the bay area.

But why did the tailpiece produce so much drag, as if it wasn't occluded at all?

[Nertea]

I don't know why the tailpiece is producing so much drag, that's a separate problem. The problem I'm describing is where the tailpiece is counting as inside the large cargo bay, but not the small one.

@Jarin, KSP does occlusion tests for everything in the lookup sphere, if the sphere is misconfigured then it will look too far and start including things it shouldn't. The actual occluded volume should still be defined by the bay itself. 

[Jarin]

11 minutes ago, Nertea said:

KSP does occlusion tests for everything in the lookup sphere, if the sphere is misconfigured then it will look too far and start including things it shouldn't. The actual occluded volume should still be defined by the bay itself. 

That makes a lot more sense. Thanks for clarifying.

Edit: I should note that the tailpiece drag did only occur behind the short cargo bay. Its drag was perfectly fine in all other situations I could test.

Edited February 1, 2017 by Jarin

[Nertea]

No problem. Thanks for the help, it's a relatively easy fix I think. Next release should have the following:

• Fixed both long cargo bays' occlusion lookup spheres
• Forced drag of shoulder intake to be lower
• Reduced all lifting surface values by 50%

Still the drag issue on the tail to deal with. Can you confirm at all whether the huge numbers occur with the Armadillo or Skate versions?

2 minutes ago, Jarin said:

Edit: I should note that the tailpiece drag did only occur behind the short cargo bay. Its drag was perfectly fine in all other situations I could test.

Oh, hmm. Including the medium cargo bay? And by normal we mean something in the couple hundred kN range?

[sh1pman]

1 minute ago, Nertea said:

Still the drag issue on the tail to deal with. Can you confirm at all whether the huge numbers occur with the Armadillo or Skate versions?

I can confirm that it happens with mk4 dual adapter used as a tailpiece.

[Jarin]

17 minutes ago, Nertea said:

And by normal we mean something in the couple hundred kN range?

Yeah. With the 120 cargo bay, it was seeing 1500+kN (which I assume is the front face open to the airstream), but when put in just about any other configuration, it gets about 1/10 of that, which is about on par with similarly-sized fuselage sections. I'll take the other tails out for a spin with @sh1pman's designs and let you know what I find.

Edited February 1, 2017 by Jarin

[sh1pman]

11 minutes ago, Jarin said:

Yeah. With the 120 cargo bay, it was seeing 1500+kN (which I assume is the front face open to the airstream), but when put in just about any other configuration, it gets about 1/10 of that, which is about on par with similarly-sized fuselage sections. I'll take the other tails out for a spin with @sh1pman's designs and let you know what I find.

1500 kN of drag is like having a mainsail pushing you back at full throttle. No wonder it couldn't get supersonic.

[Jarin]

13 minutes ago, sh1pman said:

1500 kN of drag is like having a mainsail pushing you back at full throttle. No wonder it couldn't get supersonic.

It's even worse than that. Near the "drag wall" just past mach 1, most of those tails are topping out near 3000kN of drag. You're flying with a boat anchor dragging behind you.

@Nertea, I tested with every tailpiece, including tossing a thunderhawk cockpit reversed onto the butt of the plane, and all showed the same extremely-high drag behavior... except for the cargo door tail. Which might be because it's a cargo bay itself.

[sh1pman]

4 minutes ago, Jarin said:

It's even worse than that. Near the "drag wall" just past mach 1, most of those tails are topping out near 3000kN of drag. You're flying with a boat anchor dragging behind you.

@Nertea, I tested with every tailpiece, including tossing a thunderhawk cockpit reversed onto the butt of the plane, and all showed the same extremely-high drag behavior... except for the cargo door tail. Which might be because it's a cargo bay itself.

So we might be on to something here. It's clearly a problem of cargo bays. It may even be happening in case of large cargo bays as well, but, hilariously, it is remedied by another bug with occlusion spheres. That's my take on what's happening here.

[Jarin]

9 minutes ago, sh1pman said:

So we might be on to something here. It's clearly a problem of cargo bays. It may even be happening in case of large cargo bays as well, but, hilariously, it is remedied by another bug with occlusion spheres. That's my take on what's happening here.

Still trying to get something big enough behind the large cargo bay while still keeping the aircraft actually capable of flight.

Edit: CONFIRMED. Parts behind the CRG-240 show the same extreme-drag behavior as those behind the CRG-120, as long as they're large enough to extend beyond the drag sphere. 

Edited February 1, 2017 by Jarin

[sh1pman]

9 minutes ago, Jarin said:

Edit: CONFIRMED. Parts behind the CRG-240 show the same extreme-drag behavior as those behind the CRG-120, as long as they're large enough to extend beyond the drag sphere. 

Yep, just as I suspected. I wonder what causes this weird cargo bay behavior. 

[Nertea]

@Jarin, @sh1pman: Ok, let me confirm, the bug sums down to this:

Any part attached behind either any of the three cargo bays (and drop cargo bays?) is not properly occluded unless it is itself a cargo bay. 

If so, can I ask a few more questions?

• Does this also occur with things behind the Crew Cabin?
• Does the Crew Cabin (when placed behind a cargo bay) also incur huge drag?
• Is there a difference in drag between these three situations:
  • Cargo bay followed by a tailpiece, with nothing in the bay
  • Cargo bay followed by a tailpiece, with an object attached to both "inner" cargo bay nodes
    • Bonus question: are the objects attached to the inner nodes properly shielded?
  • Cargo bay followed by a tailpiece, with an object attached to one of the "inner" cargo bay nodes (preferably the rear one)
    • Bonus question: is the object attached to the inner node properly shielded?

I hugely appreciate the help by the way. Too many people report a bug and don't assist in the tracking of it, you are greatly helping me here. 

Edited February 1, 2017 by Nertea

[sh1pman]

@Nertea Everything inside the cargo bays (node- or surface-attached) is properly shielded.

Haven't tested the Crew Cabin yet. I'm on mobile right now, will run some tests when I get home.

[Nertea]

 

Oh dear I think I might have found the problem. 

This is from the mk3 cargo bay in 1.2+

nodeOuterForeID = top
nodeOuterAftID = bottom
nodeInnerForeID = top2
nodeInnerAftID = bottom2

This is from the mk3 bay previously...

nodeOuterFore = top
nodeOuterAft = bottom
nodeInnerFore = top2
nodeInnerAft = bottom2

It very much appears that they changed the specification string for the nodes there between versions. My definitions are using the old one, of course - that's not something I expected to change.  This would explain all the problems, and would also explain why it wasn't a noted issue before (it just plain didn't exist). This would essentially mean that the internal node wasn't getting marked as occluded properly ever. An empty node means that it would look to the engine like there was nothing attached and that there was a virtual blunt surface in the bay. 

I'll test this when I get home. 

[Jarin]

14 minutes ago, Nertea said:

I hugely appreciate the help by the way. Too many people report a bug and don't assist in the tracking of it, you are greatly helping me here. 

Taking a few hours break from testing, but I will follow up on all these questions, unless @sh1pman gets to it first. -

 

1 minute ago, Nertea said:

I'll test this when I get home. 

or would you prefer to toss up an updated beta mod somewhere and we can run tests on that?

[Nertea]

2 minutes ago, Jarin said:

Taking a few hours break from testing, but I will follow up on all these questions, unless @sh1pman gets to it first. -

 

or would you prefer to toss up an updated beta mod somewhere and we can run tests on that?

If you're willing to be be a guinea pig, I can compile a test version and dropbox it now. With the caveat that I'm at work and therefore can't test, so it might not work great

[Nertea]

@Jarin: Here you go

Changes you should see:

•  New drag cube for Mk4 Shoulder Intake
•  Fix for cargo bay node occlusion
•  Fix for large cargo bay's occlusion testing spheres
•  Reduced air intake ratio of lift fans in LF mode (22 -> 14)
•  Reduced all fuselage body lift values by 33%

To others: not an official build, don't download unless you want to test. 

[Jarin]

58 minutes ago, Nertea said:

Here you go

Awesome. My ISP is being a butt right now though, so testing will probably be a bit later this evening. (seriously, 30 60 minutes for a 60mb file, what?)

Edited February 2, 2017 by Jarin

[sh1pman]

56 minutes ago, Nertea said:

@Jarin: Here you go

Changes you should see:

•  New drag cube for Mk4 Shoulder Intake
•  Fix for cargo bay node occlusion
•  Fix for large cargo bay's occlusion testing spheres
•  Reduced air intake ratio of lift fans in LF mode (22 -> 14)
•  Reduced all fuselage body lift values by 33%

To others: not an official build, don't download unless you want to test. 

TESTED. The occlusion sphere bug is fixed. However, the cargo bay node occlusion bug still exists. I can't even lift off with my spaceplanes now, crashing right after the runway. 

[Jarin]

3 minutes ago, sh1pman said:

TESTED. The occlusion sphere bug is fixed. However, the cargo bay node occlusion bug still exists. I can't even lift off with my spaceplanes now, crashing right after the runway. 

Hit alt+f12, go to Physics, under "Aero" select "show aero data in right click menu". Then right-click parts as you're headed down the runway and see what the individual part drags are. (<.< and just to avoid the "derp" possibility, since I did it once today... you are setting to full throttle, right? Those planes nosedive into the sea at half)

Edited February 2, 2017 by Jarin