Coatl Aerospace ProbesPlus v0.15RC

[PhineasFreak]

Change log:

General:

• Add RO support for all the new ProbesPlus parts.
• Lower the maximum temperatures of some parts.
• Adjust the fuel cross feeding rules of some parts.
• Adjust the crash tolerances and breaking forces of some parts.

Antenna parts:

• Add CommNet system support to all antenna parts (not dependent on Remote Tech anymore).
• Increase the power consumption of the Pioneer omnidirectional antenna.
• Repurpose the small folding dish antenna to be the Mariner Mars HGA (as it should be in the first place).
• Small tweaks to all generic antenna parts to better fit with each other.

Command parts:

• Remove the upgrades from the SAS modules.
• Patch the Voyager and Pioneer command modules to not have hibernation enabled.
• Fix the RT patches (were missing some NEEDS checks).
• Tweak the inert mass of the Voyager probe core to account for the auxiliary scientific and structural parts.

Control parts:

• Remove the upgrades from the reaction wheel modules.

Electrical parts:

• Revamp the battery stats. They had too small of a capacity (compared to both other batteries and real life battery packs).

Propulsion parts:

• Add back the gimbal module to the generic 0.5 kN thruster (Note 1).
• Remove the engine module configs from the R-40 engine (now has it's own global engine config).
• Fix the typos on the gimbal module of the Fregat-M upper stage.
• Lower the utilization of the generic propellant tanks (might need further tweaking).

Science parts:

• Remove the upgrades from the scientific instruments.
• Fix the scaling of the Voyager Science Boom (was smaller than normal).

Utility parts:

• Repurpose the "Quetzal" service module to be an extra spacecraft bus (LM900).

Notes:

Note 1: There is a missing closing bracket on the base part module that causes MM to fail to patch the part correctly. I have informed raveloda about it and it will be fixed in the next version of ProbesPlus (raveloda/Coatl-Aerospace#56).
Note 2: This PR requires the following global engine configs from the main RO branch:

• R-40 and R-42
• S5.92
• STAR-37E (with the STAR-37E global engine config updates & fixes #1631 bugfixes)

Note 3: This PR requires #1627 in order for the parachute parts to appear without RealChute installed.
Note 4: Due to the way RealPlume removes the stock plume nodes, the Voyager Payload Module will be missing it's RCS plumes: KSP-RO/RealPlume#24. A fix for that is provided by KSP-RO/RealPlume#29.

[pap1723]

I have been playing with these parts, and have had no issues with any of them. I do not have detailed testing reports, but will continue to report back as I continue.

[PhineasFreak]

@pap1723 Thank you for the review! I do want some feedback since not many RO players use these parts (so balancing may be off).

[pap1723]

@PhineasFreak I will continue to play with them for sure. Do you have IRC or use Discord to chat easier? Anyway, I have started messing around with NSS-OctoSat to generate RO configs and wanted to make sure it wasn't something that you were working on?

[PhineasFreak]

I wanted to start hanging out on the RO IRC but most of the time i am at work and it is difficult to do so (time is available but broken into a ton of small "windows").

No, if you want you are free to go ahead and make configs for it (i am working on the Alcentar's R-7 pack - proves to be somewhat on the difficult side).

[stratochief66]

@PhineasFreak IRC is pretty good for the 'small bits of time' state of life. It can be used asynchronously fairly well, where you can ask a question or say something, then look in again later when you have a chance to see if anybody responded, and others can do the same with you. We'd love to see you there, even if you don't talk much (or at all), and just skim the chat log when you have free time, at work, home or otherwise. :)

[stratochief66]

PR Looks good to me.

@pap1723 or @PhineasFreak , did either of you try landing Venera on Venus? Last time someone tried to land something on Venus, it had trouble surviving the G's, so that part/those parts may need very high G tolerance. The heat shield may also be a bit finicky, since IIRC we've never configured a specifically Venus rated shield before.

If either of you have a Venera craft assembled in RO with this config, I'd appreciate it :)

[pap1723]

I haven't tried the venera lander yet, I didn't think it was configured? I only had one with Surveyor and the satellite parts configured?

…

On May 24, 2017 8:01 PM, "stratochief66" ***@***.***> wrote: PR Looks good to me. @pap1723 <https://github.com/pap1723> or @PhineasFreak <https://github.com/phineasfreak> , did either of you try landing Venera on Venus? Last time someone tried to land something on Venus, it had trouble surviving the G's, so that part/those parts may need very high G tolerance. The heat shield may also be a bit finicky, since IIRC we've never configured a specifically Venus rated shield before. If either of you have a Venera craft assembled in RO with this config, I'd appreciate it :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1629 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASjbf3FjHyTGCOCk-Rcng6alqGIlFpsrks5r9NLtgaJpZM4NQiUj> .

[PhineasFreak]

@pap1723 all Coatl Aerospace parts are configured for RO (but not RP-0).

@stratochief66 sorry about the craft files, i always forget to upload some for testing: LINK REMOVED BY USER

Venera is configured properly but some notes:

• The parachute parameters are probably misconfigured for "stock". I really recommend testing with RealChute installed.
• Make sure that the entry velocity is smaller than 12 km/s or the heat load will be too much regardless of the entry periapsis.
• The entry periapsis must be lower than 35 km (or even subterranean) or the heat shield will not be able to handle the heat load.
• In some cases the decoupler forces the lander to rotate upon decoupling it from the bus. This is probably a collider + attaching node position issue and it will be fixed (forgot about it...).
• Make sure that the lander speed is sufficiently low after parachute deployment so that the heat shield can be safely discarded (there were some cases where the higher drag of the heat shield did not allow a clean separation or it even destroyed the lander after flying away and returning back).
• The lander parts can handle 400+ G but they also probably need some DeadlyReentry compatibility patches (does DRE touch the part strengths anymore or is it left up to the stock KSP?).

[stratochief66]

@Starwaster ^^
last bullet point there

[stratochief66]

Yep, confirmed that the lander and bus end up with a rotation after separation. Thankfully, without persistent rotation I could 'fix' that by timewarping the rotation away.

The chute still ends up heating up really high, and exploding for me. My guess would be that the 'shroud' for the chutes catches heat during entry, passing it to the shield. Not sure how best to handle this. Perhaps having some ablator on the chute to absorb that heat and dissipate it?

Chute skin peaked at ~5300K. Even if I hold the chute in reserve until I'm nearly at the ground, it has still overheated (over internal temp) before it reaches the ground. Perhaps the core part needs a radiator or something? IIRC, the actual probe had a cooling system built in, to maximize its life.

Also, the KTDU engine doesn't appear to have a plume. Not a deal breaker for this PR, just something I thought you should be aware of. :)

A Jettison Shroud button still seems to exist, but doesn't do anything.

The decoupler between the bus and landing probe has two Decouple buttons, and if manually triggered in the 'wrong' order, the craft spins into madness.

I'd like to move to a release of RO shortly, would it be possible for you to note down/confirm these issues, and work on them later? The PR as is is certainly still a big improvement.

[PhineasFreak]

• There is an occlusion problem with the parachute "heat shield" (since it is just a fairing) and it allows the heat to traverse freely from inside out. The only way to fix this would be to increase by a ton the heat emissivity of the part and it's maximum temperature to 5773.15. I'd like to avoid and add extra resources to it since the main heat shield also works as a ballast keeping the capsule stable enough for the reentry (the CoM is already high enough with just the lander and the parachute pack).

• From my tests if the capsule reentered with the heat shield first then it was OK. But if it rotated upon decoupling, even by a small amount, then...bad luck. And you cannot shield it effectively since most of the capsule is comprised of dummy fairings (much like the engine fairings), offering absolutely no thermal protection. A similar situation would be to use a lunar-rated heat shield on the bottom of a generic probe core: if you don't reenter with the heat shield on the front then it will be destroyed.

Edit: So, even if i increase the maximum temperature of the parachute, the lander will be destroyed anyway in an abnormal reentry (sideways or upside down). The lander may need some sort of cooling. I'll see if it is possible to "pre-cool" it before separating it (as it was done IRL).

• I might have forgotten to add the KTDU plume config. let me see if i missed something (again...). Edit: seems that i forgot to even create a plume config...

• The shrouds might be problematic from the start (as i do not touch them in the RO configs). Will double check using a stock + CA installation (no RO). Edit: if the heat shield or the parachute is attached to a part then KSP will not jettison the fairings:

Checking bottom node and found an attached part. Unable to jettison.

Seems like it is a stock behavior.

• Not sure about the decoupler but this may be the problem with the decoupling action (and not the node position). Will check. Edit: i forgot to actually add the closing brackets to the ModuleDecouple MM config. I also increased the length of the decoupler so that the 4MV spacecraft bus and the heat shield colliders will not...collide.

[stratochief66]

Alright! Some of these challenges may be worth addressing later, but I'm trying to merge up anything big like this so I can make a release.

Merging!

[Starwaster]

Re: DRE g-forces - yes it still does its own implementation of g-force damage and it's based on the parts crashTolerance. It's something that's been on my mind to revamp for quite awhile. One thing I have in mind to do is adjust the final tolerance by how large/massive the part is. REALLY large parts would be less tolerant for a given value then more compact parts (such as small probes meant for planetary reentry)

the code involved is:
if (is_engine && damageCube.averageDamage < 1) gTolerance = (float)Math.Pow(UnityEngine.Random.Range(11.9f, 12.1f) * part.crashTolerance, 0.5); else gTolerance = (float)Math.Pow(UnityEngine.Random.Range(5.9f, 6.1f) * part.crashTolerance, 0.5);
Which is then used here:
if (gTolerance >= 0 && displayGForce > gTolerance) { // G tolerance is based roughly on crashTolerance AddDamage(TimeWarp.fixedDeltaTime * (float)(displayGForce / gTolerance - 1), Vector3.zero);

[PhineasFreak]

@Starwaster so i guess that we still have to implement custom DRE patches for these parts, right? If so, Tantares has some nice patches for it's Venera. I'll take a look and implement them for the next ProbesPlus update.