Bacon Labs - Stockalike Ariane & More - Dev Thread

[_Augustus_]

EDIT 5/14/15:

Seriously still no votes? I can't decide, guys.

Edited May 14, 2015 by _Augustus_

[_Augustus_]

Could a moderator please remove the poll as it's irrelevant?

[_Augustus_]

Since Augustus and I had discussed doing a set of lander parts a bit, I thought I should post these up here for further discussion and feedback.

Here are some -very- early concept shots of some of the series of modular lander parts that I'm working on/was working on/have had laying around for awhile. I'm currently in the process of working on dimensions, how it will all fit together, and trying to figure out how to make it work in KSP. They are based off many different recent lander designs, but nothing specific. Probably none of the existing meshes will be used, its all just there for checking fit and layout; existing coloring is just flat material shading and in no way any representation of final coloring. And, as stated, this is all concept stuff; it may never go much further than this, I'm just working through ideas.

I'm going for a stock-like part-based approach with these, but you should be able to construct any number of the recent lander designs floating around. The Altair multi-stage/disposable design, the partially re-useable design, and the fully re-useable lander design (names?) should be achievable with these parts, with some margins. As it is all part based, -many- different lander designs should be possible that are not (easily/cleanly) doable with stock parts.

There is essentially two series of complementing parts; a ~2.4m set (fits in 2.5m fairing), and a ~3.65m set (fits in 3.75m fairing). Each set is hollow, with the 2m stuff fitting inside the 3m stuff (cutout in the 3m parts not shown); so inset designs are possible and fully intended (where the ascent stage is fully surrounded by the descent stage, and its engine(s) can potententially contribute). The 2m series also contains cutouts/hollow middle section for the addition of inset engines or to accomodate the 2m pod ascent hardware set; which should allow for fair simulations of even the Apollo era LM

2.4m parts (in example two-stage design)(pod will sit flush against descent stage when docked, with ascent engine protruding through the bottom of descent stage):

0.625m docking port shown in render, but will likely have a 1.25m top-attach node/docking port for greater compatibility and stronger connections

2.4m lander pod w/ascent hardware (fuel tanks), crew capacity probably 2 or 3 (TBD) (pod is <2.4m in length/width, unsure/undecided on cylinder diameter)

2.4m lander pod ascent engine ~(0.8 engine; may well go with 0.625m for those parts)(possibly used on decent as well (or descent only), depending upon configuration)

2.4m fuel core x2 (0.75m tall each) (descent stage)

2.4m engine quad (descent stage)

2.4m leg set (all 4 legs in a single part, hopefully...)

https://github.com/shadowmage45/KSPMods/raw/master/wiki/SC-B-render-LC2-dev1.png

3.65m parts (2-stage design shown; hollow center in 3m parts now shown; lander pod will sit flush against the top of the 3m parts when in descent configuration, with the ascent engines also available for use during descent)

3.65m lander pod; higher crew capacity than the 2m, whatever it ends up being

2.4m fuel core X 2 (ascent stage)

2.4m engine quad (ascent stage)(also used on descent for additional thrust)

3.65m fuel core X 2 (descent stage)

3.65m engine quad (descent stage)

3.65m leg set (all 4 legs in a single part, hopefully...)

https://github.com/shadowmage45/KSPMods/raw/master/wiki/SC-B-render-LC3-dev1.png

And the full set of example parts, as they currently exist

https://github.com/shadowmage45/KSPMods/raw/master/wiki/SC-B-render-LCFull-dev1.png

Any thoughts or interest in this stuff?

I'm really disappointed with the options available for landers in stock (and even with most of the mods I use), and have been wanting to put together something like this for awhile. I also don't believe that the single-purpose-designed landers (such as if I did a direct Altair modeling) really have a place in KSP; and I say this after having used a single-purpose-designed in my 1.0 career game for awhile (my Series-A lander design) -- it takes a lot of the fun out of actually designing things, removes alot of aspects of mission planning, and due to being uncustomizable generally ends up being overweight (and overpowered) for the majority of uses (and not powerful enough for the rest!). The one upside to the single-purpose-designs is the very-low part count that can be achieved; but the difference between a 2 part lander and a 7 part lander is negligible... neither will lag your game. -- Anyway, that is my rationale behind designing these as a modular set of parts rather than modeling any single lander (or even multiple landers).

Altair, Cargo Altair, and Morpheus are on my list currently.

For Altair, do the 2.4 meter parts but scale them up to use a 1.25m docking port.

[Mecripp]

Well we have SLS and the Ares but haven't seen a Jupiter so you know where my vote went.

[_Augustus_]

Well we have SLS and the Ares but haven't seen a Jupiter so you know where my vote went.

TiberDyne has one

[cipherpunks]

can You please remove a photo of bacon from ESV? Please.

The thing is, for me personally, sliced animal fat is disgusting to the point of vomiting IRL, and seeing the picture of it on otherwise useful part makes me "eek" every time.

Granted I can GIMP it away myself, but with every update I must then remember to put that texture back to not to "eek" one more time... So please.

[liquidhype]

can You please remove a photo of bacon from ESV? Please.

The thing is, for me personally, sliced animal fat is disgusting to the point of vomiting IRL, and seeing the picture of it on otherwise useful part makes me "eek" every time.

Granted I can GIMP it away myself, but with every update I must then remember to put that texture back to not to "eek" one more time... So please.

Or at least give us the option to change the picture/flag to something other than a slice of bacon. I respect the logo, but not everyone wants a slice of bacon on their parts.

[cipherpunks]

Also I think Auriga pod should have command core added - Orion can fly unmanned IRL... Also its protective cover decoupler should be stageable I think (now only LES SRB is stageable AFAIKC)

Edit: too bad not every command pod which has RCS ports drawn, actually has working RCS like Auriga has. Thanks for that.

Edit 2: ESV has that black antenna on its model, so I just...

@PART[ATVCore] {  // BaconLabs ESV Core Module
  @MODULE[ModuleSAS] { %SASServiceLevel = 3 }  // prograde, retrograde, radial, normal, node, target
  %MODULE[ModuleDataTransmitter] {  // copied from longAntenna a.k.a commsAntenna16 a.k.a Communotron 16
    packetInterval = 0.6
    packetSize = 2
    packetResourceCost = 12.0
    requiredResource = ElectricCharge
  }
}

...because it is there. ;-)

And one final thought: for us, PP users*, plain vertical cylindrical tanks do not possess any good value, except of RAM penalty. So for us it might be better to just provide corresponding textures for use with Procedural Parts, and provide fixed-volume tanks as separate download... Just saying.

* at least for me deleting 99% of tanks (except maybe exotic ones like Paloma MP, ROUND-8 and integrated engine+tank combos like ORANGE), "stock" fairings and using PP/PF instead is the only way to play - because of RAM and the need of other mods. So I'm pruning...

Edited June 4, 2015 by cipherpunks

[cipherpunks]

Just tried landing Auriga from Minmus - 13.8 m/s under 3 parachutes, with empty MP tank, is a bit too high descent speed IMO. (I don't have RealChute installed ATM). Also docking module with or without parachute looks absolutely the same, which is kinda strange.

Edit: not that RealChute has any support for that part out-of-the-box...

Edited June 4, 2015 by cipherpunks

[_Augustus_]

can You please remove a photo of bacon from ESV? Please.

The thing is, for me personally, sliced animal fat is disgusting to the point of vomiting IRL, and seeing the picture of it on otherwise useful part makes me "eek" every time.

Granted I can GIMP it away myself, but with every update I must then remember to put that texture back to not to "eek" one more time... So please.

First off thank you for posting this stuff in the dev thread!

It's cartoon bacon, I eat real bacon quite a lot and it tastes delicious. Sorry, but we won't be adding official support for those who hate bacon.

Or at least give us the option to change the picture/flag to something other than a slice of bacon. I respect the logo, but not everyone wants a slice of bacon on their parts.

See above.

Also I think Auriga pod should have command core added - Orion can fly unmanned IRL... Also its protective cover decoupler should be stageable I think (now only LES SRB is stageable AFAIKC)

Edit: too bad not every command pod which has RCS ports drawn, actually has working RCS like Auriga has. Thanks for that.

Edit 2: ESV has that black antenna on its model, so I just...

@PART[ATVCore] {  // BaconLabs ESV Core Module
  @MODULE[ModuleSAS] { %SASServiceLevel = 3 }  // prograde, retrograde, radial, normal, node, target
  %MODULE[ModuleDataTransmitter] {  // copied from longAntenna a.k.a commsAntenna16 a.k.a Communotron 16
    packetInterval = 0.6
    packetSize = 2
    packetResourceCost = 12.0
    requiredResource = ElectricCharge
  }
}

...because it is there. ;-)

And one final thought: for us, PP users*, plain vertical cylindrical tanks do not possess any good value, except of RAM penalty. So for us it might be better to just provide corresponding textures for use with Procedural Parts, and provide fixed-volume tanks as separate download... Just saying.

* at least for me deleting 99% of tanks (except maybe exotic ones like Paloma MP, ROUND-8 and integrated engine+tank combos like ORANGE), "stock" fairings and using PP/PF instead is the only way to play - because of RAM and the need of other mods. So I'm pruning...

I added your ESV patch into the official mod. Sorry but no PP support, we want people to install this as easily as possible.

Just tried landing Auriga from Minmus - 13.8 m/s under 3 parachutes, with empty MP tank, is a bit too high descent speed IMO. (I don't have RealChute installed ATM). Also docking module with or without parachute looks absolutely the same, which is kinda strange.

Edit: not that RealChute has any support for that part out-of-the-box...

I think that's a reasonable descent speed. I get that with stock capsules. Also if you could make a RealChute patch that would be great.

[DuoDex]

can You please remove a photo of bacon from ESV? Please.

The thing is, for me personally, sliced animal fat is disgusting to the point of vomiting IRL, and seeing the picture of it on otherwise useful part makes me "eek" every time.

Granted I can GIMP it away myself, but with every update I must then remember to put that texture back to not to "eek" one more time... So please.

I just did Meatless Industries, removes all mention of "bacon" from the mod

Of course, this is no more than a fork of the original creators' work that I will be updating myself - no new content, just no bacon.

[cipherpunks]

I think that Auriga Service Shroud & Adapter should have the option to jettison service module fairing but not decouple ICPS (moreover, it is Interim, not Interrim).

As for RealChute .cfg - no, seriously, do You expect me to share it after Your answer 2 posts ago?

[_Augustus_]

I think that Auriga Service Shroud & Adapter should have the option to jettison service module fairing but not decouple ICPS (moreover, it is Interim, not Interrim).

As for RealChute .cfg - no, seriously, do You expect me to share it after Your answer 2 posts ago?

You can jettision it

[cipherpunks]

No I can't. I only can decouple :-( Should I try on clean KSP maybe?... (w/o TweakableEverything)

Edit: on "clean" KSP yes I can jettison them; will find conflict maybe; will report.

Edit 2: Yep, TweakableEverything breaks it.

Edit 3: namely, TweakableEngineFairings

Edited June 5, 2015 by cipherpunks

[_Augustus_]

No I can't. I only can decouple :-( Should I try on clean KSP maybe?... (w/o TweakableEverything)

Edit: on "clean" KSP yes I can jettison them; will find conflict maybe; will report.

Edit 2: Yep, TweakableEverything breaks it.

Edit 3: namely, TweakableEngineFairings

I have TweakableEverything and it works fine. Then again I use action groups.

[cipherpunks]

Wasn't working for me (clicking on part in VAB showed no "jettison" buttons at all) untill I changed

@PART
[*]:HAS[@MODULE[ModuleJettison]]:FOR[TweakableEverything]

in TweakableEngineFairings.cfg to

@PART
[*]:HAS[@MODULE[ModuleJettison],!MODULE[ModuleDecoupler]]:FOR[TweakableEverything]

... That's on clean install. YMMV.

[cipherpunks]

Then again I use action groups.

Yes, I concur that, while there's no "jettison" in menu, AGX still sees those 2 "jettison" actions just fine.

OTOH almost always after jettisoning that fairing, (still folded) solar panels on service module are becoming broken :-\

Edited June 6, 2015 by cipherpunks

[NecroBones]

Wasn't working for me (clicking on part in VAB showed no "jettison" buttons at all) untill I changed

@PART
[*]:HAS[@MODULE[ModuleJettison]]:FOR[TweakableEverything]

in TweakableEngineFairings.cfg to

@PART
[*]:HAS[@MODULE[ModuleJettison],!MODULE[ModuleDecoupler]]:FOR[TweakableEverything]

... That's on clean install. YMMV.

Wait, is this a config in this mod, that's saying "FOR"? That's not a conditional. The "FOR" effectively says "I'm called TweakableEverything", which means any other mods checking to see if Tweakable Everything is installed will think that it is, just because this config is present. If the config is meant to execute only if TweakableEverything is present, this should be "NEEDS", not "FOR".

[cipherpunks]

is this a config in this mod, that's saying "FOR"?

This is a config in TweakableEverything, one of many (every one corresponds to a separate Tweakable*.dll)

[NecroBones]

This is a config in TweakableEverything, one of many (every one corresponds to a separate Tweakable*.dll)

OK, nevermind then.

[cipherpunks]

Currently Auriga command pod color depends on the amount of Ablator linearly.

Carrying 2.5t of Ablator every flight is a waste of fuel IMO, when in reality often what's needed is in range of 100 to 200 (FAR+HeatControl here).

Can Auriga CM be made so the color will change exponentially, that is, it will become black when there's like 20 to 50 Ablator left, but starts to darken only after there's less than 100 Ablator left? TIA.

- - - Updated - - -

Oh, almost forgot: yesterday I left one ship that had SM panels deployed on orbit, switched to another almost identical one, and when switching back, here's what I've found:

The panels actually moved in closed state (all three except one) and tried to track the sun. Stats (EC/sec) were as if they were deployed normally ofc.

Edited June 7, 2015 by cipherpunks

[cipherpunks]

Small request: add another botom node (of size 1) to Auriga Service Module to allow it to stack on stock decouplers also.

And I'd like to know how to counter this:

That is, 1st SM panel keeps being pushed to 2nd and 3rd AGs, despite stock AG editor shows single panel for single AG (while AGX shows two for 2nd and next).

[cipherpunks]

Small request: add another botom node (of size 1) to Auriga Service Module to allow it to stack on stock decouplers also.

Anyhow, here's what I use currently:

@PART[OrionBPC] {  // BaconLabs Auriga BPC - may be useful for smaller pods too
  %MODULE[TweakScale]:NEEDS[TweakScale] {
    %type = stack
    %defaultScale = 3.75
  }
}

@PART[Orion] {  // BaconLabs Auriga Multi-Purpose Crew Vehicle - this has flown automated IRL, so...
  %MODULE[ModuleCommand] {
    %minimumCrew = 0
    %RESOURCE[ElectricCharge] { %rate = 0.05 }
  }
  @MODULE[ModuleSAS] { %SASServiceLevel = 3 }  // prograde, retrograde, radial, normal, node, target
  @RESOURCE[Ablator] { @amount = 100 }  // do not need all the 2.5 tons of it generally
}  // TODO even Apollo had 290 RCS Isp; research about Orion RCS and boost it.

@PART[OrionESASvcMod] {  // BaconLabs Auriga Service Module - TODO realistic stats
  @MODULE[ModuleEnginesFX],* { @heatProduction = 220 }  // was 350, exploded in seconds
  %node_stack_bottom2 = 0, -1.9, 0, 0, -1, 0, 1  // befriend with stock decouplers
}

@PART[ICPS]:NEEDS[CryoEngines] {  // BaconLabs Interim Cryogenic Propulsion Stage - realistic stats
  @title = Interim Cryogenic Propulsion Stage
  @manufacturer = Boeing
  @mass = 3.8575  // 32.4t gross
// real dV ~ 3050+, actual dV for Orion = 3551
  @MODULE[ModuleEngines] {
    @maxThrust = 110.1    // RL-10B2
    !atmosphereCurve {}
    %atmosphereCurve {
      key = 0 465.5
      key = 1 373
    }
    !PROPELLANT[LiquidFuel] {}
    !PROPELLANT[Oxidizer] {}
    %PROPELLANT[LqdHydrogen] {
      %ratio = 1.0
      %DrawGauge = False  // ??
    }
    %PROPELLANT[Oxidizer] {
      %ratio = 0.1
      %DrawGauge = True
    }
  }
// 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 = 50000
    %maxAmount = 50000
  }
  @RESOURCE[Oxidizer] {
    @amount = 5000
    @maxAmount = 5000
  }
}

Later I might read up on its (Orion's) antenna and cobble some AntennaRange .cfg, but we'll see.

[Shadowmage]

Currently Auriga command pod color depends on the amount of Ablator linearly.

Carrying 2.5t of Ablator every flight is a waste of fuel IMO, when in reality often what's needed is in range of 100 to 200 (FAR+HeatControl here).

Can Auriga CM be made so the color will change exponentially, that is, it will become black when there's like 20 to 50 Ablator left, but starts to darken only after there's less than 100 Ablator left? TIA.

- - - Updated - - -

Oh, almost forgot: yesterday I left one ship that had SM panels deployed on orbit, switched to another almost identical one, and when switching back, here's what I've found:http://i.piccy.info/i9/f4aebf043add9f3f0c15783966d4a5b6/1433716621/61331/917625/screenshot20_800.jpghttp://i.piccy.info/a3/2015-06-07-22-37/i9-8316823/800x500-r/i.gif

The panels actually moved in closed state (all three except one) and tried to track the sun. Stats (EC/sec) were as if they were deployed normally ofc.

A: Ablator -- the CM was NOT designed to have a HeatShield Module. _Augustus_ added that himself. It does -NOT- need a heat shield for a direct-from-Minmus-return trajectory (3600+ m/s @40k alt on return), even at 120% heating (seriously, try it with the ablator removed/module removed from the .cfg). It is big and wide and has lots of drag and slows down quite quickly. Any issues from ablator/heat shield, please take them up with _Augustus_. (Honestly, it just needs to be removed, as it is _NOT_ supposed to be there).

B: Solar panels -- stock bugs. Nothing can be done about them for now (neither the breaking on fairing jettison, nor the animation problems, nor the action group probems). Seriously, stock was never meant to handle this complex of a part. The problems stem from: Multiple simultaneous animations (stock does not allow for animation layering/separation); mutliple same-named action group keys (because it is using stock solar panel modules, and those do not allow custom group names); and the breaking is caused by stock not respecting the 'breakable=false' flag in regards to collisions (and it also for some reason adds physical colliders to supposedly non-physical fairing debris).

In my personal games I have written a custom plugin (and solar panel module) that handles the solar panels much better (animation, persistence, non-breaking, action groups.... pretty much fixes all the bugs); but it will likely be a few weeks/months before I am willing to release it (if ever)(was a huge PITA to write, and may or may not have some licensing problems preventing it from being released... will need to speak to some others for more info). Lots of testing will need to be done, and probably quite a bit of code cleanup and refactor (still learning the KSP API), but it didn't make my game explode even once last night, so it is off to a good start.

C: Stack nodes -- feel free to add them yourself. Quite simple to do via MM patch or even direct config editing. I will -not- be adding them to the base model as it is meant to be used exclusively with the SCA and MSA adapters at the bottom (which allow it to fit on a 3.75m stack seamlessly).

D: ICPS Stats -- yes they are greatly nerfed compared to real-life. Beacause if I went with the real-life dV stats, you would never need any other upper stage. In reality the ICPS is -just- enough to do a moonshot (and orbital insertion? I think the SM engine actually does that part...); so the ~1200 dV I gave it is still 50-100% more than it should/would have (relatively scaled). It is called an 'Interim' propulsion stage, as it is meant to be replaced by (or combined with) larger and more capable upper stages for missions to more distant destinations (and I believe the ICPS is really only scheduled for one mission before they start using larger upper stages?). So, in those regards, the upper CSM stack is extremely overpowered; it should probably only have 400-600 dV when scaled down to KSP system, but it was the portion that I would prefer be overpowered if given a choice.

But to each his own; if you feel it needs more performance, there is nothing to stop you from doing a patch like you have. That is one of the great things about KSP/modding/mods (I love the fact that I can alter so much about the game with just a text-editor).

In the mean-time; some preview of a very early WIP IVA for the CM (and some other misc stuff) --

Javascript is disabled. View full album

Edited June 8, 2015 by Shadowmage

[_Augustus_]

A: Ablator -- the CM was NOT designed to have a HeatShield Module. _Augustus_ added that himself. It does -NOT- need a heat shield for a direct-from-Minmus-return trajectory (3600+ m/s @40k alt on return), even at 120% heating (seriously, try it with the ablator removed/module removed from the .cfg). It is big and wide and has lots of drag and slows down quite quickly. Any issues from ablator/heat shield, please take them up with _Augustus_. (Honestly, it just needs to be removed, as it is _NOT_ supposed to be there).

B: Solar panels -- stock bugs. Nothing can be done about them for now (neither the breaking on fairing jettison, nor the animation problems, nor the action group probems). Seriously, stock was never meant to handle this complex of a part. The problems stem from: Multiple simultaneous animations (stock does not allow for animation layering/separation); mutliple same-named action group keys (because it is using stock solar panel modules, and those do not allow custom group names); and the breaking is caused by stock not respecting the 'breakable=false' flag in regards to collisions (and it also for some reason adds physical colliders to supposedly non-physical fairing debris).

In my personal games I have written a custom plugin (and solar panel module) that handles the solar panels much better (animation, persistence, non-breaking, action groups.... pretty much fixes all the bugs); but it will likely be a few weeks/months before I am willing to release it (if ever)(was a huge PITA to write, and may or may not have some licensing problems preventing it from being released... will need to speak to some others for more info). Lots of testing will need to be done, and probably quite a bit of code cleanup and refactor (still learning the KSP API), but it didn't make my game explode even once last night, so it is off to a good start.

C: Stack nodes -- feel free to add them yourself. Quite simple to do via MM patch or even direct config editing. I will -not- be adding them to the base model as it is meant to be used exclusively with the SCA and MSA adapters at the bottom (which allow it to fit on a 3.75m stack seamlessly).

D: ICPS Stats -- yes they are greatly nerfed compared to real-life. Beacause if I went with the real-life dV stats, you would never need any other upper stage. In reality the ICPS is -just- enough to do a moonshot (and orbital insertion? I think the SM engine actually does that part...); so the ~1200 dV I gave it is still 50-100% more than it should/would have (relatively scaled). It is called an 'Interim' propulsion stage, as it is meant to be replaced by (or combined with) larger and more capable upper stages for missions to more distant destinations (and I believe the ICPS is really only scheduled for one mission before they start using larger upper stages?). So, in those regards, the upper CSM stack is extremely overpowered; it should probably only have 400-600 dV when scaled down to KSP system, but it was the portion that I would prefer be overpowered if given a choice.

But to each his own; if you feel it needs more performance, there is nothing to stop you from doing a patch like you have. That is one of the great things about KSP/modding/mods (I love the fact that I can alter so much about the game with just a text-editor).

In the mean-time; some preview of a very early WIP IVA for the CM (and some other misc stuff) --

http://imgur.com/a/IZWXH

Wait, you wanted to add a separate heatshield part? The ablator burns, you lose it eventually. Also the ICPS won't even be used on a single manned Orion flight currently, it's scheduled for just the 2018 mission. Also, I'm impressed that you have been able to code 2 complex plugins and make such beautiful models at the same time, very few people can do that.