Antennas on airplanes, now more bendy?

[AeroGav]

My latest career game is running into an annoyance.    My early science planes can't seem to transmit crew reports etc. on the fly any more.  The basic communotron 16 breaks when i extend it in the air, unless i fly the plane  into a stall.  Unfortunately, silly me, I designed my airplane to be stable and i can't hold the stalled attitude long enough to transmit anything.

I tried putting the thing in a mk1 service bay but it appears they changed these things so they cannot deploy while bay doors are shut.  So back to square one.

I then spent my hard earned science to purchase an experiment storage module instead.  Just spent an hour and a half doing 4 atmospheric survey contracts and collecting temp readings, pressure measurements and crew reports from multiple biomes.    On landing, I fell victim to the unupgraded runway and my plane broke in half.  Fortunately, Jeb was fine, and only two parts of the airplane were actually destroyed (our space program is currently in a cash flow situation).

Unfortunately, the experiment storage module was one of them.    

[Snark]

57 minutes ago, AeroGav said:

The basic communotron 16 breaks when i extend it in the air

So why not use the Communotron 16-S instead?  That's what it's for.  Doesn't break due to atmospheric force.

Also, FWIW, antennas inside fairings work just fine.  For example, if I have a plane with a 1.25m fuselage, I can put on a 1.25m fairing (either on the nose, or in-line in the middle) with an RA-2 antenna tucked neatly inside.  (Disable staging on the fairing, of course.)  Works great! 

[swjr-swis]

15 hours ago, AeroGav said:

My early science planes can't seem to transmit crew reports etc. on the fly any more.  The basic communotron 16 breaks when i extend it in the air, unless i fly the plane  into a stall.

Ya, with the introduction of Comms to the game, they changed it so any of the extendable antennae (iow. all of them) will break at almost any viable speeds, leaving only the fixed Communotron 16-S as the single option for science planes. Apparently that wasn't handicap enough, so they also made that one single option (and only that one) non-stackable, which means planes are still screwed for range when playing with some of the harder Comms settings. Adding insult to injury, they then also made the default orientation of that antennae perpendicular to prograde, making it more draggy when placed in its visually most aerodynamic orientation.

I got tired of this nonsense pretty quick and edited the cfgs to make the extendable Communotron-16 safe to use again in my career game, like it was before (windResistance = 500 in ModuleDeployableAntenna, default is 1 - kPa dynamic pressure), and the 16-S to be stackable (antennaCombinable = True in ModuleDataTransmitter, default is False). The kPa value can probably be tweaked down to a more 'realistic' breakage point - you need to go close to Mach 3 at sea level to make even 300 kPa - but at this point it had irritated me enough that I didn't care to do anything more than just make it workable again.

Edited January 29, 2017 by swjr-swis
test results trump expectations of consistency

[Aegolius13]

I've sometimes put the RA-2 in service bays as well.  It's overkill for a lot of missions, but it gets the job done if you want more antenna than the 16-S.  

[GoSlash27]

I've only ever tried to transmit once while flying in 1.2.2. I used the Communitron 16S and it worked just fine.

 A+++++++. Would transmit again.

Best,
-Slashy

[Snark]

4 hours ago, swjr-swis said:

Adding insult to injury, they then also made the default orientation of that antennae perpendicular to prograde, making it more draggy when placed in its visually most aerodynamic orientation.

Wait... you're saying that it's actually more draggy when placed so that the antenna extends longitudinally along the direction of travel, and less draggy when it's crosswise?

That's... just nutty, if true. 

How is this known?  i.e. where does that information come from?

[bewing]

39 minutes ago, Snark said:

Wait... you're saying that it's actually more draggy when placed so that the antenna extends longitudinally along the direction of travel, and less draggy when it's crosswise?

That's... just nutty, if true. 

How is this known?  i.e. where does that information come from?

I totally agree, Snark -- so I did the test.

And ha! Disproven!

104 Antennas crosswise, 203 m/s, 114kN drag.

 

same craft, 104 Antennas lengthwise, 205 m/s, 78kN drag.

[Snark]

15 minutes ago, bewing said:

I totally agree, Snark -- so I did the test.

And ha! Disproven!

Woot! Score one for SCIENCE!

My own idea for testing would be to make a vertical-launch rocket that's symmetric except for having longitudinal antennas on the left side and crossways antennas on the right, then launch it straight up with SAS turned off and see which way it veers. (Would have to put the antennas on outriggers or something, since they're physicsless and their drag therefore goes to the parent part.)

I like your way better, though... actual numbers FTW.

[swjr-swis]

6 hours ago, Snark said:

How is this known?  i.e. where does that information come from?

I deduced this from the part's dragModelType (in DirectAntennas\C16S.cfg) being 'default', which as far as I know means drag is minimal when flying in its default/prograde direction, and increases when the part is angled away from it. By default, the game places the 16-S antenna rods perpendicular to the craft's prograde vector, requiring one to rotate it to make the rods point along the prograde. Hence my assumption.

 

6 hours ago, bewing said:

104 Antennas crosswise, 203 m/s, 114kN drag.

6 hours ago, bewing said:

same craft, 104 Antennas lengthwise, 205 m/s, 78kN drag.

Well, there you go; so it's merely a visual issue and an inconvenience of having to perform an extra action to correct it being placed in the wrong orientation by default. Extra lesson learned: the default orientation of parts apparently has no direct link with the 'prograde' vector of their drag cubes. Good to know, thanks for testing.

As far as I know, all other parts that use dragModelType = default are least draggy in their default placement and most draggy in either of the perpendicular rotations. My mistake was assuming consistency. Well, assuming consistency, and distrusting visual clues when it comes to drag.

My two mistakes were assuming consistency, distrusting visual clues, and posting about something before exhaustively testing it. My three mistakes were assuming consistency, distrusting visual clues, posting before testing, and an almost fanatical devotion to cfg parameters. Argh. My four mistakes... ... amongst my mistakes were such diverse things as ahh.. let me come back to this in another thread.

[Snark]

52 minutes ago, swjr-swis said:

as far as I know means drag is minimal when flying in its default/prograde direction, and increases when the part is angled away from it.

Right, and where did this information come from?  How do you know this?

I mean, in the absence of any other information, I would have assumed that drag would depend on the orientation of the drag cube (i.e. does it have a wide side or a narrow side facing prograde), and that the shape of the drag cube would generally conform to the visual dimensions of the part.  Regardless of what the "default" orientation is.

I certainly don't know that, I just assume it.  It just seems like the simple, obvious, common-sense implementation, and my default mindset is generally "assume common-sense behavior unless there's evidence to the contrary".

So... where/how did you get that information?  i.e. why do you think that "default orientation" matters at all, ever?  Documentation somewhere?  Experimental evidence?  Something else?

[AeroGav]

@bewing beat me to it

Adding an Antenna the wrong way increases drag by 1%, adding it the right way increases drag by 0.5%.

A service bay has as much drag as two antennas orientated incorrectly, but a service bay can obviously be used to hide other (draggier ) stuff.   And yes , the radial antenna transmits just fine from inside the service bay, when it's status shows "shielded = true" and therefore drag of 0.

What is the point of the other antenna then, if you'll forgive the pun?    Since it has no better rating, only works when deployed, and unshielded, and breaks too easily to be used on an aircraft.       Since it's not radial (though it can be attached radially as well), i take it the part can be used on a 0.5m attach node to avoid an open node drag penalty.   So you could put it on the top of a mk1 command pod to lower drag if you weren't needing a mk16 parachute or small nose cone or small intake there ?     

[bewing]

17 minutes ago, AeroGav said:

What is the point of the other antenna then, if you'll forgive the pun?

Ha, no forgiveness here. The pointy antenna is infinitely stackable. So 10 whip antennas give you 10 times the range of 1 surface mount antenna (which is not stackable at all). And it's 1/3rd the weight.

And it works just fine on airless CBs -- which is most of the CBs in the Kerbol System.

[swjr-swis]

32 minutes ago, Snark said:

Right, and where did this information come from?  How do you know this?

From forum discussions on the matter of drag of stock/mod parts, and from other people's attempts at documenting the undocumented, and from my own experiments from back some time ago trying to make sense of how drag works.

Unfortunately off the bat all I can find right now is the knowingly unreliable wiki section of CFG parameters (see in particular the descriptions of maximum_drag and minimum_drag).

 

38 minutes ago, Snark said:

I mean, in the absence of any other information, I would have assumed that drag would depend on the orientation of the drag cube (i.e. does it have a wide side or a narrow side facing prograde), and that the shape of the drag cube would generally conform to the visual dimensions of the part.  Regardless of what the "default" orientation is.

I've learned that when it comes to drag in KSP, using 'visual dimensions' can be very misleading, so I stopped trusting my eyes on that regard completely:

• Angled nosecones on radial stacks look (and should be) more aerodynamic than straight cones, but are more draggy instead.
• 'Aerodynamically' angling solar panels or radiators parallel to a surface that is sloped away from the pure prograde direction actually causes more drag than if you place them in the pure prograde direction, which visually makes them look like open airbrakes... but KSP drag physics minimizes drag in that position.
• The tail connector visually looks like it should easily be the most aerodynamic nosecone, and it is.... as long as you can make the craft stay perfectly prograde, because even the tiniest (and visually insignificant) deviation quickly transforms it into the most draggy cone of all.
• Control/lifting surfaces are 'drag-agnostic' in two directions... as long as the surface stays (mostly) parallel to the air-flow, those parts can be rotated with the wide or the narrow end 'into' the wind with absolutely zero effect on drag, despite what your eyes might tell you.
• Not to mention there are parts that effect their drag away from where you would visually expect it (eg. all 'physicsless' parts, struts and fuel lines, mk1/2/3 cockpits)
• And perhaps the most obvious example: KSP drag goes through everything, affecting parts that visually and intuitively should be shielded from it.

So I've learned to distrust my eyes when it comes to KSP drag.

 

1 hour ago, Snark said:

my default mindset is generally "assume common-sense behavior unless there's evidence to the contrary".

Mine too, generally. Hence why I assumed that like pretty much every other part in KSP, the 16-S would also default to being placed in its most KSP-aerodynamic position. Instead, it defaults to the most un-aerodynamic, and requires an extra rotation step to correct it; not exactly common-sense behaviour.