Bacon Labs - Stockalike Ariane & More - Dev Thread

[cipherpunks]

I'm currently trying to rebalance the stack temp-wise, including solving that Ablator depletion (and resulting graying of pod) because of engine heat. ICPS heat problem is solved, now SM engines... Will report later.

Also, the parachute problem turned out to be caused not by FAR itself, but by its interference with some NF pack - investigating.

Will post here later - some important things will need to be changed in distribution, that's for sure, but I hope only cfg-wise (namely, release ICPS has LqdHydrogen, which is unacceptable given it doesn't even check if CryoEngines are installed - KSP will stop loading, and users will be astonished - not everyone knows about output.log or what was it; I'll try to balance it around LF+Ox later).

Edited to add: I'm using BL release, not dev build, and I'm using it on 1.0.2, but intend to test on 1.0.4 later also. Will be adding TAC LS resources too I think, balanced as IRL. Never did RealChute patch before, but will look into that too.

Edit 2: that Ablator-related shader that makes the pod black when there's no Ablator, should really be not linear but exponential, so that if You have around a quarter of Ablator left, the pod is only, say, 20% darker, but when there's none, the pod becomes all charred. I'd modify it but I do not have the dev stack installed ATM, OTH I have Unity dDL'ed and .mu -> Unity -> Blender convertors too... Just don't have a clue yet.

Upd:

%MODULE[TweakScale]:NEEDS[TweakScale] {
%type = stack
%defaultScale = 3.75
} // TweakScale
} // PART

@PART[OrionDPM] { //,NasaDockingSystem] { // BaconLabs Bacon Docking System (Parachute), Bacon Docking System (Standard)
// International Docking Adapter (IDA), a 526-kilogram <- but that's whole pressurized adapter; todo research just the docking node mass
%MODULE[JSIExternalCameraSelector]:NEEDS[RasterPropMonitor] {
%cameraContainer = NodeStackBottom // DockingPort works
%cameraIDPrefix = ExtCam
}
} // PART

@PART[Orion] { // BaconLabs Auriga Multi-Purpose Crew Vehicle
//Capsule mass: 8913 kg (must be 5 t at D=3.75m)
//Gross mass: 9742 kg
@mass += 4.447
//Environmental Control System: 128 kg TODO add TAC LS
%MODULE[ModuleCommand] {
%minimumCrew = 0
%RESOURCE[ElectricCharge] { %rate = 0.05 }
} // ModuleCommand
@MODULE[ModuleSAS] { %SASServiceLevel = 3 } // prograde, retrograde, radial, normal, node, target
//RCS Coarse No x Thrust: 24 x 445 N.TODO re-check ModuleRCS
@MODULE[ModuleRCS] { @atmosphereCurve { @key,0 = 0 290 } }
@RESOURCE[Ablator] { @amount = 100 }
//RCS Propellants: 175 kg
//Spacecraft delta v: 50 m/s
@RESOURCE[MonoPropellant] {
@amount = 44 // was 150
@maxAmount = 44
} // RESOURCE
%thermalMassModifier = 0.35 // it is hollow inside; 1.0 for insulator; 0.35 does the trick for lifting reentry from the Moon at 99.99% Ablator usage
%heatConductivity = 0.001 // 0.0001 for insulator
%skinThicknessFactor = 0.15 // hollow inside, thin walls, scary ....
// %emissiveConstant = 0.30 // trying not to touch it...
} // PART

@PART[OrionESASvcMod] { // BaconLabs Auriga Service Module
// old, pre-ATV: empty mass 3.7 t, fuel 8.3 t; ATV carried 4.7 t of fuel
//Service Module mass: 12337 kg (must be 5.2 t at D=3,75)
//Service module propellant mass: 7907 kg (must be 3.34 t at D=3.75)
@mass = 4.43 //1.86
%node_stack_bottom2 = 0, -1.9, 0, 0, -1, 0, 1
@MODULE[ModuleRCS] { @atmosphereCurve { @key,0 = 0 329 } }
@MODULE[ModuleEnginesFX],* { @heatProduction = 170 } // was 350; 180 overheats after ~950 dV
@MODULE[ModuleEnginesFX],* { @atmosphereCurve { key,9 = 9 0.1 } } // % -> "cannot use index with replace value"
// Isp of R-4D-11 is 312 s; R-4D-15 Isp is 323 s; no more than 343 s for main nozzle
@MODULE[ModuleEnginesFX],0 { @atmosphereCurve { @key,0 = 0 340 } } // suppose it's Aestus II / RS-72
@MODULE[ModuleEnginesFX],1 { @atmosphereCurve { @key,0 = 0 333.5 } }
@MODULE[ModuleEnginesFX],0 { @maxThrust = 55.5 } // was 120; suppose it's Aestus II / RS-72
@MODULE[ModuleEnginesFX],1 { @maxThrust = 7.5 } // was 60; suppose it's AMBR at 0.935 kN
@MODULE[SSTUSolarPanel] { @resourceAmount *= 4 } // stock is 12.6 EC/s
// RCS Coarse No x Thrust: 16 x 445 N
// Spacecraft delta v: 1855 m/s
//CM+SM Gross mass: 21500 kg
//CM+SM Unfuelled mass: 11750 kg
//Gross mass: 9819 kg
//Unfuelled mass: 69 kg ?? ... this source lies
//Thrust: 33.40 kN ?? no info on engines yet, except ATV ones, but they do play with RS-72
//Total delta-v: ~1340 m/s
@RESOURCE[MonoPropellant] {
@amount = 1976 //1925 // was 1050 = 4.2t
@maxAmount = 1976
} // RESOURCE
@RESOURCE[ElectricCharge] {
@amount = 400
@maxAmount = 400
} // RESOURCE
%heatConductivity = 0.01 // 0.0001 for insulator
%skinThicknessFactor = 0.1 // ?? unsure
%emissiveConstant = 0.4 // SM is ribbed and has panels; 1 for radiators
} // PART

@PART[ICPS]:NEEDS[CryoEngines] { // BaconLabs Interim Cryogenic Propulsion Stage
@title = Interim Cryogenic Propulsion Stage
@manufacturer = Boeing
@mass = 4.1 // 32.4t gross
// real Orion stack dV ~= 3050+, actual dV for Auriga stack = 3299
@MODULE[ModuleEngines] {
@maxThrust = 110.1 // RL-10B2
@heatProduction = 42 // was 35.0
@atmosphereCurve {
@key,0 = 0 465.5
@key,1 = 1 373
key,9 = 9 0.1
} // atmosphereCurve
!PROPELLANT[LiquidFuel] {}
!PROPELLANT[Oxidizer] {}
%PROPELLANT[LqdHydrogen] {
%ratio = 1.0
%DrawGauge = False // ??
} // PROPELLANT
%PROPELLANT[Oxidizer] {
%ratio = 0.1
%DrawGauge = True
} // PROPELLANT
} // ModuleEngines
// min 28.3t HydroLOx ~= 3.75x5.625m PP tank ~= 5000 LOx+50k LH2
// for the record, there is 16.92t of HydroLOx in DCSS
-RESOURCE[LiquidFuel] {}
%RESOURCE[LqdHydrogen] {
%amount = 49570
%maxAmount = 49570
} // RESOURCE
@RESOURCE[Oxidizer] {
@amount = 4957
@maxAmount = 4957
} // RESOURCE
} // PART

// SA 581 kg total
@PART[OrionShroud1] { // BaconLabs Auriga Service Shroud & Adapter
@mass *=0.16 // was 1.75
%thermalMassModifier = 0.9 // 1.0 for insulator
%emissiveConstant = 0.30
%heatConductivity = 0.02 // 0.0001 for insulator
} // PART

@PART[OrionShroud2] { // BaconLabs Auriga Service Adapter
@mass *= 0.15 // no way it weights 1.75 tons!
@node_stack_bottom = 0, -0.5, 0, 0, -1, 0, 1 // size was 2
%thermalMassModifier = 0.9 // 1.0 for insulator; 0.9 = 189 m(t)
%emissiveConstant = 0.30
%heatConductivity = 0.02 // 0.0001 for insulator
} // PART

@PART[BLSLSSRBNose] { // BaconLabs 5-Segment SRB Nose Cone (2.25m)
@mass *= 0.5
@node_stack_bottom = 0.0, -1.48, 0.0, 0.0, -1, 0.0, 2 // y was -1.37; -1.5 is just too much; -1.46 almost, but clips
%MODULE[TweakScale]:NEEDS[TweakScale] {
%type = stack
%defaultScale = 2.25
} // TweakScale
} // PART

@PART[OrionBPC] {  // BaconLabs Auriga BPC

makes it leave Ablator alone while engine works (note SINGLE MAIN SM engine, or ICPS RL-10, but not both SM engine blocks - e.g. not small nozzles plus main nozzle for long burns! Burns up to 500 dV work with both engines, though.), but makes it eat 99% of Ablator upon actual reentry from Moon orbit (RSS; target periapsis 32km, lifting reentry w/pitch at 15 degrees). Tomorrow I'll fiddle more - I intend to make "direct return" from Mars and maybe Venus doable, as the real thing must.

TODO:

- try to balance stock ICPS on LF+Ox to remove user astonishment and LqdHydrogen dependency from base release

- add TAC LS to CM (masses are known; check NASA docs for intended endurance)

- test on 1.0.4

- look into RealChute MM patch

- google if (where; distance; mass) Orion has antenna

- test direct lifting reentry from Mars

- (maybe) test direct reentry from Venus

- work out why FAR+ModularFlightIntegrator nullify chute drag

Edited June 30, 2015 by cipherpunks
add alpha thermo patch, update patch for Moon direct reentry

[Shadowmage]

So... I -can- confirm the decoupling collision bug. It is strange though, as it only takes effect once the SM is nearly free of the adapter and the engine bell would be clearing the end of the SCA. Stranger still, that adapter does not have any solid colliders near the top (it is flagged as a non-convex mesh collider, so it -shouldn't- collide with anything except for mouse-over highlighting). Will see if I can track down the precise issue, but as it will require work in Unity / reworking the parts, it may take me a few weeks to get it cleaned up. I'm not sure why I haven't noticed it before... but honestly I haven't had much time to play in a few weeks/month or so.

Have not been able to confirm any black-rendering issues, at least not on my dev-versions. Which makes the ablator even more of a suspect; I cannot think of anything else that would be messing with shading rendering. If anyone can try removing the ablator module and let me know if the issue persists, that should at least give me a starting point to begin investigating.

Edit/Update:

Did a quick hack/test regarding the SM/ICPS collision. Removing the upper (non-convex) collider from the SCA adapter seems to solve the problem. Which is -really- weird, as non-convex colliders should not actually collide with ... well... anything (or all of the documentation I have read is horribly incorrect).

Not sure if/when I'll be able to issue a proper fix for it. I'm not fond of not having colliders on a piece, and the game can do some strange things when they are not present. So... I'll probably have to go with the worst-case scenario and create a complex 24 object collider for that piece (GDI, why can't KSP/Unity support hollow parts properly?).

Edited June 30, 2015 by Shadowmage

[cipherpunks]

Shadowmage , unless You know how to make that Ablator-related effect not linear but exponential, please postpone Ablator-related investigations while I'll try to rebalanse thermo. TIA.

Users: if You see darker or black Auriga CM, that means You must've removed some (or all) Ablator from it. If that's the case, then CM shader works as designed.

Edited June 30, 2015 by cipherpunks

[Shadowmage]

Better yet... what I should _really_ do, is create a selective ablator shader module, that only affects the specified parts of the mesh / specified mesh objects. I'll try to take a look at the stock ablator module code today to see if I can hack something out quickly; -might- be a fairly simple affair...might not... I guess we'll see

And btw, cipherpunks, thanks for helping sort this stuff out / track down these issues. Saves my sanity, and helps with my time constraints

Edit/Update:

The stock ModuleAblator looks like it will be super easy to rework for a mesh-object-specific module. This should allow for only the heat-shield part of the CM to darken as ablator is consumed; as it should be. Might also add in code to only allow depletion of ablator when nothing is attached to the bottom node (or rather a node specified in the config) -- would work as an occlusion 'fix'. I'll also see about doing an expo curve on the depletion shading, as that sounds very reasonable.

So... expect to see that with the next update, along with a fix for the SM/ICPS decoupling (still working on figuring out a good solution for that one...).

Edited July 1, 2015 by Shadowmage

[cipherpunks]

Fiddling with 1.0.4 now, and guess what... RSS reentry became so hard, that it is impossible so far :-) So far everything explodes despite there's still some Ablator left. I guess I have to tweak skin-to-internals conductivity somehow... Will try to find some info on forum on just what to put in .cfg - I'm not familiar with newly introduced keys, if any. Any pointers to fresh docs are appreciated.

[Shadowmage]

Yah, I have not yet attempted updating or testing on 1.04. From the sounds of the change log it appears that they have fixed most of the re-entry problems (such as a steep reentry used to generate less heat than a shallow one). Which... could be bad news for some of the parts. This is the main reason that I am/will be working on the custom ablator module -- so that the CM can properly have ablator resource and shading, as it might now be actually needed (a direct from minmus return to a 30k Kerbin re-entry periapsis used to see the the CM only hit ~400 temp; not even enough to trigger ablator use...).

I have not yet looked at the new config fields to know what they are/what they do, but will likely be investigating and testing a bit of 1.04 over the weekend.

[cipherpunks]

I'm still fiddling with 1.0.4; here's what I know I can fiddle with:

  @maxTemp = 2500 // = 3400 (?)
  %thermalMassModifier = 2  // 1.0 for insulator; Squad uses 4 often; 6 for nose cones
  %heatConductivity = 0.005  // 0.0001 for insulator; default = 0.12; Squad uses 0.04 for panels
  %emissiveConstant = 0.7  // ?? dunno what it is; Squad uses 0.9 for radiators
  %skinThicknessFactor = 0.85  // skin:internals proportion; around 1 for panels, around 0.1 or less for tanks
  %skinInternalConductionMult = 4.0  // skin -> intestines flux
  %radiatorMax = 0.35  // ?? dunno what it is; default = 0.25
  %radiatorHeadroom = 0.75  // ?? I don't give a damn; Squad uses 0.75 or 0.5 for radiators
  %MODULE[ModuleConductionMultiplier] {
    %modifiedConductionFactor = 0.003
    %convectionFluxThreshold = 3000
  }  // ModuleConductionMultiplier
  @MODULE[ModuleAblator] {
    @lossExp = -6000  // was -9000
    @lossConst = 1  // was 20
    @pyrolysisLossFactor = 600  // was 10000
    @reentryConductivity = 0.01
    @ablationTempThresh = 500
  }  // ModuleAblator

...but overall 1.0.3 heat model seems lame, that is, it is impossible to reentry without using completely unrealistic values for, say, thermalMassModifier and emissiveConstant. That is, the pod, which is empty inside, just can't have thermal mass of 100 000 tonnes, can it? Squad seems lamers to me.

How wrong were those that were touting the end of DeadlyReentry mod... Now we kinda need it to be able to set different ablation processes as they are IRL - say, ablation process of PICA-X is much different than ablation of AVCOAT which Apollo (and Orion) uses...

Edited July 3, 2015 by cipherpunks

[Mecripp]

I'm still fiddling with 1.0.4; here's what I know I can fiddle with:

  @maxTemp = 2500 // = 3400 (?)
  %thermalMassModifier = 2  // 1.0 for insulator; Squad uses 4 often; 6 for nose cones
  %heatConductivity = 0.005  // 0.0001 for insulator; default = 0.12; Squad uses 0.04 for panels
  %emissiveConstant = 0.7  // ?? dunno what it is; Squad uses 0.9 for radiators
  %skinThicknessFactor = 0.85  // skin:internals proportion; around 1 for panels, around 0.1 or less for tanks
  %skinInternalConductionMult = 4.0  // skin -> intestines flux
  %radiatorMax = 0.35  // ?? dunno what it is; default = 0.25
  %radiatorHeadroom = 0.75  // ?? I don't give a damn; Squad uses 0.75 or 0.5 for radiators
  %MODULE[ModuleConductionMultiplier] {
    %modifiedConductionFactor = 0.003
    %convectionFluxThreshold = 3000
  }  // ModuleConductionMultiplier

...but overall 1.0.3 heat model seems lame, that is, it is impossible to reentry without using completely unrealistic values for, say, thermalMassModifier and emissiveConstant. That is, the pod, which is empty inside, just can't have thermal mass of 100 000 tonnes, can it? Squad seems lamers to me.

How wrong were those that were touting the end of DeadlyReentry mod... Now we kinda need it to be able to set different ablation processes as they are IRL - say, ablation of PICA-X is much different than ablation of AVCOAT which Apollo (and Orion) uses...

Why would you put that on a pod ? There is no stock pod with all that on it just

	MODULE
	{
		name = ModuleConductionMultiplier
		modifiedConductionFactor = 0.003
		convectionFluxThreshold = 3000
	}

Some of what you have you really wouldn't want on your pod.

EDIT- What you have is alittle crazy you are boosting heat with some and then you have some trying to cut the heat

Edited July 3, 2015 by Mecripp2

[cipherpunks]

You got me wrong. I just dumped here all the thermo values that can be fiddled with, that is all.

Also, for example Squad\Parts\Command\Mk1-2Pod\mk1-2CommandPod.cfg does not have heat shield - the heat shield is separate part; while Auriga CM tries to be all in one part and so....

Hope You got it now.

[Mecripp]

My bad lol, I was like what lol sorry.

[Shadowmage]

Just setup 1.04 for some testing / verification of dev version stuff.

So far, everything is looking good. Parts seem to function properly still, no random explosions.

Tried a direct-from-Mun return/re-entry with the Orion CM (no ablator/heat-shield) @ 30k Kerbin periapsis. Hit atmo at around 3200 m/s, as normal for a Mun return. Things got a bit hotter than they used to, but still nothing to worry about. Used to hit ~400k on the CM, now peaks at about 615k for the same re-entry vector. So, they definitely cranked up the re-entry heating, but still not enough that you actually need a heat-shield (ablator module) on the CM, at least on normal heating levels. I would imagine that with some minor vector tweaking / shallower angle, the heat could be minimized even further, allowing direct-from-Minmus (3400 m/s) returns without any concern for overheating.

On higher heat levels, the heat-shielding -might- be a good idea. If I can get the math for the ablator module worked out, should be able to add it in officially with the next release/update for those parts.

[Shadowmage]

Question regarding the upcoming lander parts.

1.) Any want/need for a 'Service Module'? It would be intended for use on the descent stage (or re-usable lander), and would include larger folding solar panels, all science experiments that are currently unlocked in the tech tree, and KAS/KIS storage for inclusion of a small payload (on-lander rover delivery, such as the later Apollo LM missions). Would likely also include a secondary set of RCS ports in the SM for help in balancing the RCS while the descent stage is attached. This is something that could be added later, does not necessarily have to be created/included immediately. I'm thinking this would be a 1/2m tall section, positioned directly below the CM/pod, with one SM for each LC-pod size (2.4, 3.65, 4.9m), and include the hollow cutout center section to still allow for use of an ascent stage/embedded ascent engines. If there is any interest I'll see about putting together a mockup and check on the functionality.

Preview Images:

Javascript is disabled. View full album

Edited July 10, 2015 by Shadowmage

[cipherpunks]

Had no time for KSP lately, besides, while fiddling with 1.0.4/FAR/RSS, I had the gut feeling that something's wrong with stock reentry physics, and from what I see now (RealHeat released, latest RSS changelog, latest RO_Physics.cfg) that was indeed the case. So I do plan to return to my fiddling with RSS Orion direct reentry some time later.

'Service Module'? It would be intended for use on the descent stage (or re-usable lander), and would include larger folding solar panels, all science experiments that are currently unlocked in the tech tree, and KAS/KIS storage for inclusion of a small payload (on-lander rover delivery, such as the later Apollo LM missions). Would likely also include a secondary set of RCS ports in the SM for help in balancing the RCS while the descent stage is attached.

Yes, I, for one, do want that.

This is something that could be added later

That's fair. :-)

Also saw peculiar (old?) Orion model on the Gerstenmaier's table in today's SpaceNews article:

Note the nozzle:

I for some reason thought they'll go pump-fed and use Aestus II / RS-72 but it turned out that EM-1 will use safer, pressure-fed OME a.k.a AJ10-190.

As a side note I also thought that smaller engines will be R-4D-15 HiPAT, and credible source says that those I guessed right:

The Auxiliary engines are 110-pound-thrust bipropellant thrusters, designated as R-4D with a 164:1 area ratio.

I also see this similar thing here ( "20111200 Orion Quick Facts--JSC.pdf" ).

Or is it not ESM?...

p.s. lander parts look great ! TBH they look really promising as to be really useful IME (incl. 5m concept - hope it'll have jettisonable side fairings to cover those tanks while still on LV, and maybe (just maybe) even top docking port under retractable nose cover... ;-)

I think that the point deploying such panels is solar tracker should be active only on deployed panels, and undeployed panels shouldn't have solar tracker (but should still produce electricity). Is this possible? Maybe deploying animation itself can be bound to "enable solar tracking" instead?... (unsure)

p.p.s. what's "AO bakes" ? Any link/video?

p.p.p.s . I wonder just where this one came from...

Edited July 11, 2015 by cipherpunks

[cipherpunks]

Whoa, with newest RSS, RealHeat and some fixes the reentry is indeed survivable! Just "splashed down hard" (at 17.5 m/s cause the parachute/docking combo doesn't do the right thing in FAR/RSS yet) with my slightly modified 1.0.2 tweaks, and still had 69.7 out of 420 ablator left! Will un-tweak, tweak the parachute (namely @MODULE[RealChuteFAR] cause tweaking ModuleParachute & ModuleDragModifier nas no effect), and re-test.

Edit: un-tweaked, aside from ICPS compatibility, CM barely eats ablator at all (on shallow LEO reentry, though) :-) Last time it was left with 350/420 of it. Tweaking RealChuteFAR also does nothing; I need to come up with RealChute config. SM now overheats real quick while main engine is running, though. I wonder how to make it so the smaller eight nozzles can be staged separately, prior to main nozzle (like the real thing).

Wasn't able to maintain Apollo-like 25 degree pitch angle (needed for lifting reentry), though - at ~80km with realistic RCS thrusters only and w/o RWs it went to 8, then at 70 to 4, and then stayed at around 5 thru most 50s, dropping to 2.3 degrees while at max Q.

Edit 2: that might be because Aerojet PR said in 2010 that the real thing will use 12 Aerojet RCS engines of unspecified model, of 0.71 kN thrust each (and maybe it does), but I had config for 16 Airbus 0.27 kN ones - one credible source said that those must be 200N from AD&S... Hm. Finding up-to-date info on Orion is not easy, given that program stutters for how many years now?... I only know fresh photo, but I don't know for sure which engine this is:

source

right-roll thruster pod with two rocket engines [snip]

two pitch-up thruster pods with a single rocket engine;

two pitch-down thruster pods, each with a single rocket engine;

two right- and left-yaw pods, each with a single rocket engine,

and a left roll thruster pod with two rocket engines.

that indeed makes for 8 pods (and 10 engines; and that means that Bacon Labs Auriga CM has a couple RCS ports too much). Go figure.

Edit 3: must be AJ MR-104G

source

Also, interesting fact there:

Orion’s solar arrays include a canting function in addition to the rotation of the arrays. This feature is exercised during the operation of the main engine to reduce loads on the arrays. During posigrade maneuvers (acceleration, positive delta-v), the arrays enter a –60-degree position to the inner axis which would be the case for Trans-Lunar Injection. For retrograde burns (deceleration, negative delta-v), the arrays are canted +55 degrees to the opposite direction (e.g. Lunar Orbit Insertion).

Edited July 11, 2015 by cipherpunks

[Shadowmage]

Had no time for KSP lately, besides, while fiddling with 1.0.4/FAR/RSS, I had the gut feeling that something's wrong with stock reentry physics, and from what I see now (RealHeat released, latest RSS changelog, latest RO_Physics.cfg) that was indeed the case. So I do plan to return to my fiddling with RSS Orion direct reentry some time later.Yes, I, for one, do want that.That's fair. :-)

Also saw peculiar (old?) Orion model on the Gerstenmaier's table in today's SpaceNews article:

Note the nozzle:

http://i.piccy.info/i9/19910ddf420aec26e073e7a10e3489d6/1436601362/25371/917625/Orion_old_model.jpg

I for some reason thought they'll go pump-fed and use Aestus II / RS-72 but it turned out that EM-1 will use safer, pressure-fed OME a.k.a AJ10-190.

As a side note I also thought that smaller engines will be R-4D-15 HiPAT, and credible source says that those I guessed right:

http://www.nasaspaceflight.com/wp-content/uploads/2013/04/Z322.jpg

I also see this similar thing here ( "20111200 Orion Quick Facts--JSC.pdf" ).

Or is it not ESM?...

Not sure what you are referring to on the engine stuff? My Orion inspired design is based from a ton of different resources, but not necessarily any particular reference drawing, or from any particular time. Many features were averaged from the various sources; others were adapted to stuff that would suit KSP better, or completely altered just to make it be able to at all work in KSP.

p.s. lander parts look great ! TBH they look really promising as to be really useful IME (incl. 5m concept - hope it'll have jettisonable side fairings to cover those tanks while still on LV, and maybe (just maybe) even top docking port under retractable nose cover... ;-)

I think that the point deploying such panels is solar tracker should be active only on deployed panels, and undeployed panels shouldn't have solar tracker (but should still produce electricity). Is this possible? Maybe deploying animation itself can be bound to "enable solar tracking" instead?... (unsure)

p.p.s. what's "AO bakes" ? Any link/video?

p.p.p.s . I wonder just where this one came from...

AO bakes = Ambient Occlusion, a way to add basic shading through a pre-rendered texture. Can add a lot of depth and detail to a model without too much effort as long as everything is setup properly for it.

Will probably have more complete previews of all of the lander parts soon, most stuff is down to just texturing left. I've gone with smaller fixed solar panels on the 2m and 3m lander pods; still undecided on the 5m pod, it may get deployable panels. Would be nice to allow electricity on a deployable panel while undeployed, but is a bit more complicated than I want to tackle at the moment. I'll give it some thought, but pretty sure it would at least require some pretty hefty plugin code changes to make it work. Perhaps -after- I've finished the parts I can look into it.

Whoa, with newest RSS, RealHeat and some fixes the reentry is indeed survivable! Just "splashed down hard" (at 17.5 m/s cause the parachute/docking combo doesn't do the right thing in FAR/RSS yet) with my slightly modified 1.0.2 tweaks, and still had 69.7 out of 420 ablator left! Will un-tweak, tweak the parachute (namely @MODULE[RealChuteFAR] cause tweaking ModuleParachute & ModuleDragModifier nas no effect), and re-test.

Edit: un-tweaked, aside from ICPS compatibility, CM barely eats ablator at all (on shallow LEO reentry, though) :-) Last time it was left with 350/420 of it. Tweaking RealChuteFAR also does nothing; I need to come up with RealChute config. SM now overheats real quick while main engine is running, though. I wonder how to make it so the smaller eight nozzles can be staged separately, prior to main nozzle (like the real thing).

Wasn't able to maintain Apollo-like 25 degree pitch angle (needed for lifting reentry), though - at ~80km with realistic RCS thrusters only and w/o RWs it went to 8, then at 70 to 4, and then stayed at around 5 thru most 50s, dropping to 2.3 degrees while at max Q.

Edit 2: that might be because Aerojet PR said in 2010 that the real thing will use 12 Aerojet RCS engines of unspecified model, of 0.71 kN thrust each (and maybe it does), but I had config for 16 Airbus 0.27 kN ones - one credible source said that those must be 200N from AD&S... Hm. Finding up-to-date info on Orion is not easy, given that program stutters for how many years now?... I only know fresh photo, but I don't know for sure which engine this is:

https://www.nasa.gov/sites/default/files/orion_rcs_pod-full.jpg

source

that indeed makes for 8 pods (and 10 engines; and that means that Bacon Labs Auriga CM has a couple RCS ports too much). Go figure.

Edit 3: must be AJ MR-104G

source

Also, interesting fact there:

I'm pretty sure I need to rebalance the heat on the ICPS. I'm pretty sure I had originally based it on the 'full' tank weight, so as you drain the tank it produces far too much heat. Could likely also use a conductivity decrease to limit the heat spread, and an emissive/radiative/convective increase to help it disippate heat a bit better.

SM Engine nozzles - nothing I can do about those at the moment, it is a stock limitation of having multiple engine modules on the same part, and a further stock limitation on the staging system (a part can only have a single staging icon). You can add in an engine-switch module (used by the stock Rapier engine), but then you can only toggle between one engine or the other and lose the ability to use both at the same time.

CM Re-entry angle - you can try tweaking the COP / COL offsets that are in the config; lower the value closer to zero and it should reduce the re-entry stability enough that you can re-enter at a different angle. The current values are probably a bit too much as they make it very hard to change capsule angle at all as you point out.

RCS Ports - yes, I added extra ports to help with RCS balance as it is represented in KSP. I believe the positions and angles that I have used are also off a bit from the real thing, but were needed to make it usable with stock KSP RCS mechanics (lack of proportional thruster control, and individual thruster control).

I hear you on the out-of-date info bit - the more stuff you read on Orion, the more conflicting information you have about it. About the only thing I've seem remain semi consistent was the overall size and shape of the CM. The SM has had at least 3 major revisions that I've seen. And the configuration of the upper stages seems to change daily, or at least is different in nearly every resource I've run across.

SM Solar panel angle - would be nice from a realism perspective, but unecessary for my KSP gameplay. I might look into it if I'm bored some day -however it would require a bit of plugin code changing/additions, as well as adding more buttons and controls onto the SM right-click panel (which I was trying to avoid).

[cipherpunks]

CM Re-entry angle - you can try tweaking the COP / COL offsets that are in the config; lower the value closer to zero and it should reduce the re-entry stability enough that you can re-enter at a different angle.

Tried that yesterday (CoM/CoL actually, no CoP changes attempted) but so far no luck; will play with it some more and will report later if something good emerges.

[cipherpunks]

adding more buttons and controls onto the SM right-click panel (which I was trying to avoid).

I'm sure that I'm mistaken and You (and everyone else) know it, but nevertheless there were times when I didn't and bloated menus made me curse.

The solution turned out to be sooo simple:

If part right-click menu is too big, press mouse3 (a.k.a press mousewheel) and drag the mouse down, and slightly to the left.

To restore, press V (or even C if You still have the crew) a couple of times.

This should be in some major FAQ I guess.

[DuoDex]

Thread locked by request, as development has ceased permanently.