[WIP] Sum Dum Heavy Industries Service Module System (Stockalike)

[StevieC]

@sumghai Re: the flotation collar, have you seen this?

 

[theJesuit]

10 minutes ago, sumghai said:

Unlocking this thread so that we can discuss the revamp here, without cluttering the release thread.

Progress Report, 7 April 2018

After quickly familiarizing myself with the latest features of KSP 1.4.2, I think it would be best to remake all the parts from the ground up, with updated stockalike aesthetics to match the new Mk1-3 command pod. This update would also be a clean break, so I won't strive for craft or savegame compatibility.

I'm currently debating these major changes:

• Deprecating the FusTek IACBM-compatible parachute-equipped docking port - This part was originally made for compatibility with my (constantly-backburnered) FusTek Station Parts pack, and I suspect it would be easier for players to just add a docking port adapter to their space stations anyway, just like how the real ISS uses different types of ports for docking of visiting spacecraft and berthing of station modules.
   
• Deprecating the Avionics Ring - This part was originally made for people who wanted to build their own "custom" Service Modules, while still using the SDHI Heat Shield, Aeroshell and LES. Looking back, I feel it's such a niche use case that it doesn't justify the trouble of trying to fix/maintain the part, especially with the shenanigans regarding different decoupling behaviours between the Avionics Ring and Service Module
   
• Change the standard docking port to the Clamp-O-Tron Jr - Apparently, this is now the smallest docking port that allows crew transfers, and if I switch over to this size, I can probably make the parachute ring a nice frustrum (truncated cone) with the same slope as the rest of the Mk1-3 Pod, instead of compensating for the bulkier standard Clamp-O-Tron with the current lumpy-looking abomination.
   
• Native Plugin for Inflatable Flotation Collar / Landing Airbag - After considering various third-party solutions, I think the best bet would be to work with @Starwaster to modify and natively integrate his SplashdownHandler plugin to fit SDHI SMS's specific needs. I'm also dropping the idea of spinning off SplashdownHandler as the basis of a standalone "inflatables" parts pack, to keep plugin development and maintenance focused on the bare essentials.

Thoughts, guys?

Sounds like a massive project! 

Here is two percentage points of a single Funds.

Change the standard docking port to the Clamp-O-Tron Jr

Yea, I'm not a fan of the Clamp-O-Tron Jr being a crew passable docking port.  It doesn't make much sense - the sizing might be right for a kerbal without helmet, but in the movie Apollo 13, there was quite a lot more room.  Ith ink for consitancy though stick with the 1.25 model, but you could shrink the passable model within it slightly to allow for parachutes to be stacked.

Also, I'm not sure how kerbals are supose to pass through the new SM-6A Service Module, with the docking clamp on top.  I don't think Squad really though that through, but rather went with something that looked cool.

Native Plugin for Inflatable Flotation Collar / Landing Airbag

Does Comfortable Landing cover this already for you?  Might save on work!

Thanks for the hard work you do.

Peace.

[Santi]

I like your ideas and I hope to see them done!

Edited April 7, 2018 by Santi

[Capt. Hunt]

3 hours ago, StevieC said:

@sumghai Re: the flotation collar, have you seen this?

 

@sumghai already mentioned in the release thread that it doesn't quite do everything he was looking for.  Although, it's worth noting that by default CL already adds flotation bags to the capsule.

12 hours ago, sumghai said:

Unlocking this thread so that we can discuss the revamp here, without cluttering the release thread.

Progress Report, 7 April 2018

After quickly familiarizing myself with the latest features of KSP 1.4.2, I think it would be best to remake all the parts from the ground up, with updated stockalike aesthetics to match the new Mk1-3 command pod. This update would also be a clean break, so I won't strive for craft or savegame compatibility.

I'm currently debating these major changes:

• Deprecating the FusTek IACBM-compatible parachute-equipped docking port - This part was originally made for compatibility with my (constantly-backburnered) FusTek Station Parts pack, and I suspect it would be easier for players to just add a docking port adapter to their space stations anyway, just like how the real ISS uses different types of ports for docking of visiting spacecraft and berthing of station modules.
   
• Deprecating the Avionics Ring - This part was originally made for people who wanted to build their own "custom" Service Modules, while still using the SDHI Heat Shield, Aeroshell and LES. Looking back, I feel it's such a niche use case that it doesn't justify the trouble of trying to fix/maintain the part, especially with the shenanigans regarding different decoupling behaviours between the Avionics Ring and Service Module
   
• Change the standard docking port to the Clamp-O-Tron Jr - Apparently, this is now the smallest docking port that allows crew transfers, and if I switch over to this size, I can probably make the parachute ring a nice frustrum (truncated cone) with the same slope as the rest of the Mk1-3 Pod, instead of compensating for the bulkier standard Clamp-O-Tron with the current lumpy-looking abomination.
   
• Native Plugin for Inflatable Flotation Collar / Landing Airbag - After considering various third-party solutions, I think the best bet would be to work with @Starwaster to modify and natively integrate his SplashdownHandler plugin to fit SDHI SMS's specific needs. I'm also dropping the idea of spinning off SplashdownHandler as the basis of a standalone "inflatables" parts pack, to keep plugin development and maintenance focused on the bare essentials.

Thoughts, guys?

I understand depreciating the parachute-IACBM, but it looks so cool.  Maybe you could drop it for now and roll it in with FusTek whenever you get back to that.

TBH, I like the idea of the avionics ring, but it does kinda have limited use since the SM has everything you could need anyway.  On the other hand, the ring looks pretty good with the new Apollo SM. I'd love to see a version of either the ring or the whole SM without the umbilical, or maybe with the umbilical in a more vertical position, so we could use them with Lander cans or cygnus like resupply modules, but that's probably something else that can be rolled in with FusTek.

Maybe, since we're discussing dropping the IACBM, we could have both the standard clamp-o-tron and the jr. as options.  I think the standard port fits the current Orion aesthetic better, but I like the idea of the parachute equipped junior port, which would also be useful with apollo style designs.  I agree the current stock solution, an SM-6 with a jr. on top just doesn't look right.

 

[Starwaster]

13 hours ago, sumghai said:

• Deprecating the Avionics Ring - This part was originally made for people who wanted to build their own "custom" Service Modules, while still using the SDHI Heat Shield, Aeroshell and LES. Looking back, I feel it's such a niche use case that it doesn't justify the trouble of trying to fix/maintain the part, especially with the shenanigans regarding different decoupling behaviours between the Avionics Ring and Service Module

I'm curious, what sort of Avionics Ring shenanigans are we talking about? I haven't seen any myself and just tried it out in KSP 1.4.2 and it behaves just fine. I'll be sorry to see it go  as I use it all the time  

Edit: sometimes the  Orion style SM just doesn't the propellant capacity that is needed for long missions. Especially with scaled up star systems where Minmus is way out in the boondocks

Edit #2: The only reason the small port is given any official change in lore as to passability is so that they can fit it on top of that bay part thing in the DLC. It never had any functional limitation as to crew transfer seeing as how the stock crew transfer function does no passability checking anyway. I can't speak for anyone but myself of course but I never use the Jr unless it's for small satellite craft or some EMU part for Kerbals to dock onto. In short, it's a niche piece for me. Making this change is essentially forcing everyone not to use the standard size clampotron on any of their craft or stations because it immediately makes it incompatible with everything else unless you're planning to make the new port cross compatible.

 

Edited April 7, 2018 by Starwaster

[Capt. Hunt]

1 hour ago, Starwaster said:

I'm curious, what sort of Avionics Ring shenanigans are we talking about? I haven't seen any myself and just tried it out in KSP 1.4.2 and it behaves just fine. I'll be sorry to see it go  as I use it all the time  

Edit: sometimes the  Orion style SM just doesn't the propellant capacity that is needed for long missions. Especially with scaled up star systems where Minmus is way out in the boondocks

Edit #2: The only reason the small port is given any official change in lore as to passability is so that they can fit it on top of that bay part thing in the DLC. It never had any functional limitation as to crew transfer seeing as how the stock crew transfer function does no passability checking anyway. I can't speak for anyone but myself of course but I never use the Jr unless it's for small satellite craft or some EMU part for Kerbals to dock onto. In short, it's a niche piece for me. Making this change is essentially forcing everyone not to use the standard size clampotron on any of their craft or stations because it immediately makes it incompatible with everything else unless you're planning to make the new port cross compatible.

 

The new MEM does have a small node on top, making jr. useful for docking to that.  I still think we should have both.

Edited April 7, 2018 by Capt. Hunt

[sumghai]

Thanks for the feedback and compliments, everyone!

• I've decided to drop the idea of the Clamp-O-Tron Jr. docking port variant completely, and just refine/retexture the current Clamp-O-Tron part. @Starwaster made an excellent point that there are far more use cases for the standard-sized docking port than the one use case with Making History's Munar Excursion Module. Besides, SDHI SMS is intended to be a stockalike Orion MPCV (and not an Apollo-Saturn) parts pack.
   
• I have already evaluated and rejected Comfortable Landing, as the plugin in its current state does not meet my needs. Icecovery has also explicitly stated he was not interested in my use case, so there's that.
   
• Yes, I will most likely bring the FusTek IACBM version back when FusTek Station Parts itself is ready - in fact, a MM patch could be used to only make the part available if both SDHI SMS and FusTek are installed.
   
• @Starwaster - the Avionics Ring shenanigans were a series of user reports complaining that the decoupling behavior between the AR and SM were inconsistent (i.e. one decouples the pod straight up as expected, the other pulls the decoupled pod slightly to the side). It was a transient issue reported by a handful of persistent users that I've forgotten the usernames of, and despite spending hours examining the visual and collider meshes, I couldn't figure out what the differences were.
  
  But if it sounds like there is a significant number of use cases for the AR, then I'll keep it.

Apologies for the scare, folks. My modding time is now limited due to other projects and commitments, so I have been trying to simplify/consolidate the number of parts in my mods (quality over quantity, yada yada).

[StevieC]

Re: the "Comfortable Landings" plugin, I hadn't known of this previous decision. Fair enough.

And I add my voice to those calling for the retention of the Avionics Ring.

[mostlydave]

I do use the AR, and I haven't ever noticed any issues with it. Sometimes you need a nuclear, or monoprop SM! I also like the regular docking port, even though a kerbal would fit through the small one I think it just looks to small.

[Barzon]

Please keep the regular size docking ports and he avionics ring!

[Delbrutis]

On 4/9/2018 at 1:05 AM, sumghai said:

I have already evaluated and rejected Comfortable Landing, as the plugin in its current state does not meet my needs. Icecovery has also explicitly stated he was not interested in my use case, so there's that.

So I posted this comment last Friday and missed you reopened this thread I’m going to re-paste it and delete the old one.

Glad to hear this is being updated. I always liked using this mod " And the new SM from MH is not really so great" I was messing around with the old SDHI heat shield with the Klockheed Martin  air-bags to see if I could get the animation working with the stock ModuleAnimateGeneric ? Got it on my second guess inflate with lower case i . Knowing that the animation still worked I started with a clean config file and was going to respec the heat shield using the new stock shields as a copy past example. On splashdown I was getting all sorts of strange weirdness and bouncing like the heat shield was repelled by the water ? So I restored your original config file with KMbuoyancy and added  ModuleAnimateGeneric . Don't know what version of Unity fixed it but as of 1.3+ KMbuoyancy is working perfectly. I went back and checked the old Klockheed Martin bags and shields they all work fine after adding the stock animation module. No need for the old KM.dll file. So just thought you would like to know you might want to add back some Airbag love to the new release.

If you don't mind my complete butchery of your original file this is what my configuration looks like. I have not fixed the sound yet I need to figure out how to play the sound clips with Inflate and deflate animation? 

Spoiler

PART
{
    name = SDHI_2.5_Heatshield
    module = Part
    author = sumghai
    
    mesh = model.mu
    scale = 1
    rescaleFactor = 1.25
    
    // --- node definitions ---
    // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z, Node Size    
    node_stack_top = 0.0, 0.125, 0.0, 0.0, 1.0, 0.0, 2
    node_stack_bottom = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 2
    CoPOffset = 0, 0.125, 0
    CoLOffset = 0, -0.1, 0

    fx_gasBurst_white = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, decouple
    sound_vent_large = decouple
    TechRequired = landing
    entryCost = 1200
    cost = 600
    category = Thermal
    subcategory = 0
    title = #autoLOC_500184 //#autoLOC_500184 = SDHI 2.5m Heat Shield
    manufacturer = #autoLOC_501629 //#autoLOC_501629 = Sum Dum Heavy Industries Co., Ltd
    description = #autoLOC_500185 //#autoLOC_500185 =  Designed for use with Kerlington's Mk1-2 Command Pod, this aftermarket heat shield consists of several ablative PICA-X tiles mounted on a conformal carbon fibre carrier and an internal metal skeleton support, permitting multiple uses before replacement.
    attachRules = 1,0,1,0,1
    mass = 0.45
    dragModelType = default
    maximum_drag = 0.2
    minimum_drag = 0.2
    angularDrag = 2
    crashTolerance = 10
    breakingForce = 280
    breakingTorque = 280
    maxTemp = 3400
    fuelCrossFeed = False
    PhysicsSignificance = 0
    stageOffset = 1
    childStageOffset = 1
    bulkheadProfiles = size2
    thermalMassModifier = 1.0
    tags = #autoLOC_500186 //#autoLOC_500186 = ablat drag entry insulate protect re- rocket therm
//    CenterOfBuoyancy = 0.0, 2, 0.0
//      CenterOfDisplacement = 0.0, 2.3, 0.0
//      buoyancy = 100

MODULE
    {
        name = ModuleJettison
        jettisonName = fairing
        bottomNodeName = bottom
        isFairing = True
        jettisonedObjectMass = 0.5
        jettisonForce = 15
        jettisonDirection = 0 0 1
        stagingEnabled = False
        checkBottomNode = True
    }    

    MODULE
    {
        name = ModuleDecouple
        ejectionForce = 100
        isOmniDecoupler = true
        menuName = #autoLOC_502004 //#autoLOC_502004 = Jettison Heat Shield
        stagingEnabled = False
        stagingEnableText = #autoLOC_502005 //#autoLOC_502005 = HS Jettison Not Staged
        stagingDisableText = #autoLOC_502006 //#autoLOC_502006 = HS Jettison Staged
    }
MODULE
    {
        name = ModuleAblator
        ablativeResource = Ablator
        lossExp = -7500
        lossConst = 0.1
        pyrolysisLossFactor = 6000
        reentryConductivity = 0.01
        ablationTempThresh = 500
        
        useChar =False
    }
    RESOURCE
    {
        name = Ablator
        amount = 800
        maxAmount = 800
    }
    MODULE
    {
        name = ModuleLiftingSurface
        useInternalDragModel = False
        deflectionLiftCoeff = 1.5
        liftingSurfaceCurve = CapsuleBottom
        disableBodyLift = False
        omnidirectional = False
        perpendicularOnly = True
        transformDir = Y
        transformSign = -1
        nodeEnabled = True
        attachNodeName = bottom
    }
    MODULE {
                name = ModuleAnimateGeneric
        animationName = inflate
        isOneShot = True
        startEventGUIName =Inflate
        endEventGUIName = Deflate
        actionGUIName = InflateHeatShield
        allowAnimationWhileShielded = True
        disableAfterPlaying = False
        
    }
    MODULE {
        name = KMbuoyancy
        buoyancyForceInflated = 100
        forcePointName = buoy1
        isMaster = True
        sound_inflate = SDHI/Service Module System/Sounds/inflateshort
        sound_deflate = SDHI/Service Module System/Sounds/inflatelong
    }
    MODULE {
        name = KMbuoyancy
        isMaster = False
        buoyancyForceInflated = 100
        forcePointName = buoy2
    }
    MODULE {
        name = KMbuoyancy
        isMaster = False
        buoyancyForceInflated = 100
        forcePointName = buoy3
    }
    MODULE {
        name = KMbuoyancy
        isMaster = False
        buoyancyForceInflated = 100
        forcePointName = buoy4
}

 

Edited May 1, 2018 by Delbrutis

[Sokol_323]

Please do not remove the avionics ring! My current version of Apollo is flying with him. If it will not collapse the whole career and the ability to create different ships. For the convenience of the users fashion AlphaMensae''s Modular LaunchPad s 1.2 are asked to consider the location of the hatch on the fairing for the crew capsule in accordance with the hatch on the MK 1-3.

[Capt. Hunt]

I am pretty sure @sumghai is already moving the hatch cover to fit the new pod, since the new version will be redesigned to accept it.

[adm-frb]

Just noticed a small bug appear with the LES tower.

As soon as I go to the launch pad, the launch escape motors appear to be firing even when they are not.

I think this might be a compatibility issue between the current version of 'Real Plume - Stock' which has a config file for the SDHI LES tower and the tower config file in this mod, since when I remove real plume. Everything appears normal.

With Real Plume installed...

Without Real Plume

I'm pretty sure sumghai didn't create the 'Real Plume - Stock' config file, he did part config for LES tower (I think), so am posting here since I can find nothing wrong on the Real Plume side so I'm posting here...

https://www.dropbox.com/s/tqg4jk3e29fa41l/part.cfg?dl=0

https://www.dropbox.com/s/a8qm7jjktv37ak7/SDHI_LES.cfg?dl=0

Edited July 5, 2018 by adm-frb
bad formatting

[sumghai]

Progress Report, 25 July 2018

Had a bit of a rough patch IRL in the last few months, but I'm slowly easing back into working on the V4 revamp.

First up is the heat shield, with an optimized mesh, nicer AO bake and better stockalike textures:

The other part I'm working on right now is the parachute-equipped docking port.

I decided I wanted a design that more closely resembles the Forward Bay Cover (FBC) design on the real Orion MPCV, so I ended up recreating part of the stock Clamp-O-Tron model, and built the rest of the docking port around that to match the slope of the stock Mk1-3 pod's conical frustum. Internally, there are now six structural ribs instead of four, and three docking LED lamps instead of four.

The six little cutouts in the upper part of the docking port case were inspired by similar features on the real FBC, and represent bolt-down points for attaching the complete Mk1-3 pod to the Boost Protect Cover (BPC) / Aeroshell. But in terms of KSP, they're just decorative elements.

I've also decided that there will no longer be an IACBM version, partly because I have no idea when I'll ever get back to working on FusTek Station Parts again, and partly because the larger diameter of the IACBM doesn't work as nicely with the slope of the new docking port casing. I still shudder at the thought of the lumpy abomination I made in the previous version.

The new docking port and heat shield conforms perfectly with the Mk1-3 pod.

The SDHI heat shield is intended to be a superior version of the stock heat shield, with the in-universe reason that it uses a more durable PICA-X ablative material. To that effect, I tuned ModuleAblator so that it consumes much less Ablator for similar re-entry profiles from LKO, while tweaking the RGBA curves for ModuleColorChanger to turn the heat shield black when the amount of Ablator drops below 798 units.

I deliberately Hyperedit'd the pod to a landing so that you can see the charred heat shield with plenty of Ablator left:

I'm currently in the progress of fine-tuning the drogue and main combo parachute deployment sequence in RealChutes, to more closely resemble the real Orion spacecraft's landing profile at KSP scaling, as well as cater for pad aborts to low-altitude parachute deployment.

Edited September 23, 2018 by sumghai
V4, not V2!

[Capt. Hunt]

looking awesome @sumghai

[StevieC]

Progress is looking good, though I will admit that I plan to cling to the old SDHI mod until there's an IVA for the Mk 1-3 pod on par with the ASET Mk1-2 pod IVA.

[sumghai]

Progress Report, 30 July 2018

I finished texturing the parachute-equipped docking port, which practically seamlessly blends in with the stock Mk1-3 pod:

Another screenshot, showing the new main parachute bags while the drogues (offscreen) are deployed:

For the most part, the drogue and mains parachute appear to be the same as the previous version, although I did improve the parachute risers. I also haven't finished tuning the drogue-mains behaviour, as I'm waiting to hear back on an unusual feature request, but I'm going to put this aside for now.

In the meantime, I've started work on the rest of the parts - because their dimensions and proportions are dependent on the Mk1-3 pod (and each other), my plan is to model everything in one Blender file, and then split them up into individual files for refining, UV mapping and texturing. Many dimensions have changed since the original version, such as the overall diameter now being strictly 2.5m to match the new stock fuel tanks.

The standalone Avionics Ring has been renamed as the Crew Module Adapter, as that is the name NASA and ESA have standardized on.

The Service Module will use MODEL{} nodes to combine the CMA with a separate propulsion trunk model. Reusing a single CMA model should make it easier to maintain the mod and resolve any shenanigans regarding different decoupling behaviour between the standalone CMA and the combined SM.

I'm also thinking about modelling the engine directly into the Service Module. This is because the SM adapter and fairings are dimensioned to only work with the stock LV-909 engine, and I figured one might as well eliminate the extra step in building a SDHI SMS stack. Also, I'm not too happy with the LV-909 model, so instead I'll be adapting the nozzle from the stock O-10 "Puff" as a LF/LOX engine - this parallels NASA/ESA using an AJ10-190 from the Space Shuttle's OMS for the real-life Orion SM's main engine.

On the other hand, I won't be adding auxiliary engines, RCS thrusters or solar panels, as my intention as always has been to let players customize their SM.

[sumghai]

Progress Report, 1 August 2018

While blocking out the rest of the parts, I explored the possibility of making the Service Module Fairings a stack-mounted part much like the stock fairings, to make it more intuitive when a player builds a SDHI SMS stack - basically, during normal staging, the side fairings would get ejected first, followed by the LAS/BPC, before the Service Module finally separates from the SM Adapter - this more closely resembles the real-life Orion MPCV's mission profile.

Another advantage would be that the fairing panels would, like their stock counter parts, float and "ghost" away to allow players to continue surface-attaching parts to the Service Module.

My main concern, however, is that I'm not sure if it is even technically possible to define fixed-sized fairings with stock PartModules. Considering how generous Starwaster was in developing the AnimatedDecouplers plugin, I don't fancy the notion of asking him for yet another bespoke PartModule.

The other issue I'm having is the umbilical interface that goes between the Crew Module Adapter and Mk1-3 pod:

• In SDHI SMS V1, the umbilical was located on the dorsal (top) side of the Mk1-2 pod, but this would interfere with the new Mk1-3 pod's airlock and ladder.
• The real-life Orion MPCV's umbilical is actually offset on an angle from the dorsal side of the Orion crew pod, but this would interfere with the new Mk1-3 pod's RCS thrusters
• The only other location I can think of to keep the entire SMS stack visually symmetrical would be the ventral (bottom/belly) side of the Mk1-3 pod; this is the least accurate option

So yeah, I'm kinda stuck here. Thoughts and feedback on both these issues would be greatly appreciated!

[Drew Kerman]

4 hours ago, sumghai said:

this is the least accurate option

accurate to what? Seems accurate to the design of the pod as far as I'm concerned

[sumghai]

11 hours ago, sumghai said:

this is the least accurate option

6 hours ago, Drew Kerman said:

accurate to what? Seems accurate to the design of the pod as far as I'm concerned

Least accurate compared to the real-life Orion MPCV design, since it's on the opposite side of the pod.

Although SDHI SMS was never intended to be an Orion/SLS replica, I would preferably like to make it have a recognizable resemblance as much as possible.

I suppose right now, it really boils down to whether people are okay with the umbilical clipping into the pod's ladder or not.

[Drew Kerman]

wait, couldn't this part just be rotated to let the user put the umbilical anywhere they want? Or will there be a visible attachment point on the shroud that it has to match up with?

My vote is to match the pod design and put it where it makes sense for the model, which is in the rear

[sumghai]

8 minutes ago, Drew Kerman said:

wait, couldn't this part just be rotated to let the user put the umbilical anywhere they want? Or will there be a visible attachment point on the shroud that it has to match up with?

There will be a slot cut into the Boost Protect Cover, as well as a slot in the Crew Module Adapter that the umbilical will pivot from, and a toggleable submesh umbilical socket that will be added to the stock Mk1-3 pod.

For reference, here's how it was implemented in the older version of SDHI SMS:

Spoiler

 

8 minutes ago, Drew Kerman said:

My vote is to match the pod design and put it where it makes sense for the model, which is in the rear

Noted

 

Edited August 1, 2018 by sumghai
Fixed spacing

[Drew Kerman]

2 hours ago, sumghai said:

For reference, here's how it was implemented in the older version of SDHI SMS:

gotcha. That detail is definitely nice. I think the fact that it can be toggled on/off though makes the point of where the umbilical hookup goes a bit moot, since anyone who would want to put it over the ladder could just rotate the adapter there and hide the port mesh while anyone who wanted a visible interface could show the port mesh and rotate the adapter over to that

Edited August 1, 2018 by Drew Kerman

[Drakenex]

agreed! Just match the pod design.