sumghai

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

Recommended Posts

I'm not running EVE or Scatterer, Here is a screen of what's happening and my video settings:

7GRf1Le.png

l5vmkOI.png

 

 

 

 

Edited by mostlydave

Share this post


Link to post
Share on other sites
35 minutes ago, mostlydave said:

I'm not running EVE or Scatterer, Here is a screen of what's happening and my video settings: 

That's exactly what I'm seeing on my end for both stock and SDHI heat shields - the waterline actually does pass through the geometric center of the heat shield model, and so the bottom half of the dish is actually underwater.

I double-checked the part origins for the heat shields from both the 1.3 and the V4 revamp, and they're more or less the same.

I suspect this has to do with changes in stock buoyancy, although I can't really think of a solution.

Share this post


Link to post
Share on other sites

OK, I haven't really played 1.4 too much and just assumed the heat shields would sink the same way they used to in older versions

 

Share this post


Link to post
Share on other sites

Progress Report, 19 September 2018

Sorry for the late update, folks - I recently moved overseas to start a new job, and have limited access to the internet.

Now that things are a little less crazy, I've managed to finish the textures for the Crew Module Adapter and Service Module.

GZbU9g7.png

zGALZhU.png

Note that the slightly-wider ribs every 60 degrees along the surface of the SM trunk was a deliberate design choice.

Getting the specular and normal maps to match the stock 2.5m Rockomax tanks was painstaking work, but I'm quite pleased with the result:

uOuJWhp.png

The CMA and SM textures did end up coming out lighter than the Mk1-3 Pod, but given the design intent of matching the Rockomax tank aesthetics, this is acceptable.

6avPKlN.png

Current WIP Download - https://github.com/sumghai/SDHI_ServiceModuleSystem/archive/e8d286d0a654ab7b3558e1eac2d36fb9d043edef.zip

Edited by sumghai
Stealth fix - bumped specular shaders now have correct settings :P
  • Like 5

Share this post


Link to post
Share on other sites

Progress Report, 20 September 2018

I finished texturing the Spacecraft Adapter this afternoon.

For consistency with the "design language" established by stock parts, I combined elements from both the Rockomax TD-series decouplers and the FLOOYD fairing inner walls. I really liked how the ribbing on the inner skirt surface turned out.

e8MVcFy.png

As always, the outer white base ring matches the Rockomax fuel tanks:

ihD2jwV.png

Here's how the Service Module sits on the Adapter - note the little decoupling "kickers" that fit into the notches on the SM trunk. This is purely a cosmetic detail, but one that would break up the monotony of a plain decoupler ring without making the part model too complicated:

gCpd6Iy.png

Current WIP Download - https://github.com/sumghai/SDHI_ServiceModuleSystem/archive/656f711326e5d804968812b8073953babaf4da34.zip

  • Like 6

Share this post


Link to post
Share on other sites

Progress Report, 23 September 2018

Just finished texturing the final part - the Launch Abort System:

tTkxPAI.png

74zE1a1.png

I also overhauled all of the MM patches that add third party mod support, mostly updating part name references and consolidating patches via the pipe ( | ) operator.

SDHI SMS V4 will support the following:

  • Connected Living Space
  • Deadly Reentry
  • MechJeb
  • PEBKAC Industries Launch Escape Systems
  • RemoteTech
  • TAC Life Support
  • USI Life Support

Support for the following have been dropped due to lack of updates / incompatibility with KSP 1.4.5:

  • FusTek Station Parts (I know, I know...:/)
  • Kerbal Optical Alignment System (KOAS)
  • OLDD / KURS Docking Camera
  • Ven's Stock Revamp (compatibility patch no longer needed as SDHI SMS V4 no longer reuses stock Clamp-O-Tron model)

I'm aware that someone submitted a PR for Kerbalism support, but the submitter didn't follow the same life support strategy as I did for TAC / USI LS, and I couldn't make heads or tails out of what their patch was trying to do. Therefore, I'm probably going to ignore that issue / PR until someone actively works with me on setting up a patch that better meets my intentions for LS in SDHI SMS.

The only outstanding tasks that remain are:

  • Documentation
    • How-to guide and screenshots on the GitHub wiki
    • A nicer brochure / picture gallery
  • RealChutes - @stupid_chris is quietly working on RC2, and we've been discussing a small feature that would make the SDHI SMS drogue-mains chute system work better at abort altitudes; for now, though, RC1 works just fine, so I might leave this minor improvement as an update patch for when RC2 comes out

Download the Experimental Build for KSP 1.4.5

Edited by sumghai
Remove horrifying all-caps text
  • Like 2

Share this post


Link to post
Share on other sites
On 8/26/2018 at 6:42 PM, sumghai said:

I suspect this has to do with changes in stock buoyancy, although I can't really think of a solution.

In the config file there's a field "buoyancy" that you can adjust, default is 1.0

It's a pain to adjust - change the cfg, reload, test, change the cfg..... so I created a very simple plugin to help - Add the module to your part's cfg and then in game adjust to the desired buoyancy (then copy that value back into your part's cfg and remove the test module). You're welcome to use it if you'd like (MIT license) code included in the zip. Dropbox link here if you care to use it.

Thanks for sharing sharing your creations!

Edit: this worked in 1.4.3 and a brief test in 1.4.5 worked.

Edited by wasml
  • Like 1

Share this post


Link to post
Share on other sites

Hi, i loved your Service Module System and used it alot in my last save. I was  happy to see, that you working on a refresh. So i give it a well deserved place in my current save.
Unfortany i have a little problem with the abort sequence. If i triger the LAS engine and the decuple of the Service module with the abort action group, the LAS engine start fireing and a few miliseconds later the decouple happen. So the engines fuel is half burnd befor the capsule is seperated and so have not enough distance to the rocket to be save.

EDIT: Ok, seems that i found my mistake. I also have to add 'toggle mode' in the AG's

Edited by DianonForce

Share this post


Link to post
Share on other sites
6 hours ago, DianonForce said:

Hi, i loved your Service Module System and used it alot in my last save. I was  happy to see, that you working on a refresh. So i give it a well deserved place in my current save.
Unfortany i have a little problem with the abort sequence. If i triger the LAS engine and the decuple of the Service module with the abort action group, the LAS engine start fireing and a few miliseconds later the decouple happen. So the engines fuel is half burnd befor the capsule is seperated and so have not enough distance to the rocket to be save.

EDIT: Ok, seems that i found my mistake. I also have to add 'toggle mode' in the AG's

Yes, the dual-mode LAS engine is a new design feature that I previously described in a previous post:

On 8/19/2018 at 1:40 PM, sumghai said:

As for the Launch Abort System, I took a page out of Shadowmage's SSTULabs mod and implemented a dual-mode solid fuel rocket motor system using the stock MultiModeEngine PartModule :

  • The default staging action fires the Jettison Motors to pull the BPC away from the Mk1-3 Pod during normal staging
  • Assuming the user sets up their Action Groups correctly, triggering the Abort AG would instead fire the Abort Motors to pull the pod away from the rest of the disintegrating rocket; another AG would then be used to switch the motor back to fire the Jettison Motor and discard the BPC

Both rocket motors and the Attitude Control Motor RCS thrusters have independent solid fuel reserves, so that activating one does not prevent the use of the other(s) later.

I'll document its proper usage on the GitHub wiki when the V4 revamp is fully released.

Share this post


Link to post
Share on other sites

Progress Report, 29 September 2018

I've haven't had a lot of feedback from my public experimental build, but a few issues came to light:

  • MechJeb currently does not display the delta-V of the Service Module, because it gets confused when a part combines an engine, fuel tank and decoupler. Sarbian is currently working on a fix to MechJeb's logic, as a few other low-part-count part mods also combine decouplers with engines in the same part.
  • A beta tester noted that the Service Module has unusually high delta-V capability - 1000~2000 m/s, or even 4000 m/s in some cases. I'd be happy to reduce the amount of LF/LOX carried in the SM tanks to values similar to NASA's real-life Orion SM (i.e. 1800~2000 m/s), but I think it would be best to wait until MechJeb has been updated before I tackle this issue.
  • The same beta tester also noted that the SM overheats after prolonged engine operation. Since the real-life Orion SM has conformal heat radiators built into the propulsion trunk, do you guys reckon I should add a radiator PartModule to the SDHI SM?
  • Like 2

Share this post


Link to post
Share on other sites

Question...

 

Is there a fairing that is meant to disappear to show the interior of the parachute bay when the parachutes deploy? 

Just asking since that was something that occurred on the previous parachutes and does not seem to occur with the new one...

Share this post


Link to post
Share on other sites
28 minutes ago, adm-frb said:

Is there a fairing that is meant to disappear to show the interior of the parachute bay when the parachutes deploy? 

Just asking since that was something that occurred on the previous parachutes and does not seem to occur with the new one... 

It depends on what altitude you're deploying your parachutes at.

The V4 revamp features nested parachute covers - the outermost casing disappears when drogues are deployed, while the inner parachute bag meshes disappear when the mains are deployed. If you deploy your chutes far too low (i.e. <2000m), then only the mains deploy, while the outermost casing remains because the drogues were supposed to be triggered from 12500m upwards.

@stupid_chris is working on a new version of RealChutes, which will support nested parachute covers.

  • Like 1

Share this post


Link to post
Share on other sites
3 minutes ago, sumghai said:

It depends on what altitude you're deploying your parachutes at.

The V4 revamp features nested parachute covers - the outermost casing disappears when drogues are deployed, while the inner parachute bag meshes disappear when the mains are deployed. If you deploy your chutes far too low (i.e. <2000m), then only the mains deploy, while the outermost casing remains because the drogues were supposed to be triggered from 12500m upwards.

@stupid_chris is working on a new version of RealChutes, which will support nested parachute covers.

Thanks... wasn't sure if that was a bug or not. I noticed it during a LAS test of a rocket I was putting together

Share this post


Link to post
Share on other sites
7 minutes ago, sumghai said:

It depends on what altitude you're deploying your parachutes at.

The V4 revamp features nested parachute covers - the outermost casing disappears when drogues are deployed, while the inner parachute bag meshes disappear when the mains are deployed. If you deploy your chutes far too low (i.e. <2000m), then only the mains deploy, while the outermost casing remains because the drogues were supposed to be triggered from 12500m upwards.

1 minute ago, adm-frb said:

Thanks... wasn't sure if that was a bug or not. I noticed it during a LAS test of a rocket I was putting together

I noticed it myself as well during my own LAS tests - this is what led me to ask Chris if he could look into this feature request for me.

  • Like 1

Share this post


Link to post
Share on other sites

:0.0: Jeb and Val are really looking forward to that improvement

Jeb said it was a fun ride not knowing if the chutes are deployed or not while Val was quoted as saying "Really glad they managed to squeeze though the gaps in the fairing! Otherwise I might be dead or have a broken back...

 

Share this post


Link to post
Share on other sites
On 9/28/2018 at 6:13 PM, sumghai said:

Progress Report, 29 September 2018

I've haven't had a lot of feedback from my public experimental build, but a few issues came to light:

  • MechJeb currently does not display the delta-V of the Service Module, because it gets confused when a part combines an engine, fuel tank and decoupler. Sarbian is currently working on a fix to MechJeb's logic, as a few other low-part-count part mods also combine decouplers with engines in the same part.
  • A beta tester noted that the Service Module has unusually high delta-V capability - 1000~2000 m/s, or even 4000 m/s in some cases. I'd be happy to reduce the amount of LF/LOX carried in the SM tanks to values similar to NASA's real-life Orion SM (i.e. 1800~2000 m/s), but I think it would be best to wait until MechJeb has been updated before I tackle this issue.
  • The same beta tester also noted that the SM overheats after prolonged engine operation. Since the real-life Orion SM has conformal heat radiators built into the propulsion trunk, do you guys reckon I should add a radiator PartModule to the SDHI SM?

Happy to hear that a mechjeb fix is being worked on.

I think adding the radiator would probably be good, since it's built into the Orion SM anyways. Maybe add it into the textures to reflect this change as well?

Share this post


Link to post
Share on other sites
28 minutes ago, Spartan_MiniMe said:

I think adding the radiator would probably be good, since it's built into the Orion SM anyways.

Noted - just waiting to hear from a few more people.

28 minutes ago, Spartan_MiniMe said:

Maybe add it into the textures to reflect this change as well?

No change to the texture is needed - I've already put ribbing textures and normal maps on the propulsion trunk segment of the Service Module, just like on the Orion SM.

  • Like 2

Share this post


Link to post
Share on other sites
On 9/30/2018 at 12:42 AM, sumghai said:

Noted - just waiting to hear from a few more people

ok for the radiator, everything else works well

Share this post


Link to post
Share on other sites

Progress Report, 17 October 2018

Sorry for the radio silence, guys - I was waiting to hear back regarding the MechJeb fixes.

After playing around with the new KSP 1.5 update, I came to realize that there was no way the new stock stage burn indicator would ever cater for combined decoupler/fuel tank/engine parts. This, and the delays in the proposed MechJeb fixes, ultimately forced me to (very reluctantly) concede to splitting up the Service Module into the Crew Module Adapter (decoupler only) and the Service Module (fuel tank and engine).

Thankfully, this was a relatively easy task, since the .MU model files for the CMA and the SM were already separate. All I needed to do was to patch up the missing faces from the top of the Service Module, which I (also conveniently) did by reusing part of the bulkhead ring mesh from the CMA:

Qh6jkQn.png

Therefore, the new craft-building workflow would now be:

  • Attach SDHI Heatshield and ParaDock to Mk1-3 Pod
  • Add the Crew Module Adapter underneath the Heatshield
  • Add the Service Module -OR- build your own custom Service Module underneath the Crew Module Adapter

As a result of this change, MechJeb now finally and consistently displays delta-V information for the Service Module, so I can now look into tuning its delta-V capabilities.

On its own, the SM has a whopping ~4300 m/s of vacuum delta-V:

GTWapDp.png

However, just by adding the CMA, Heatshield, Pod and Paradock, the vacuum delta-V gets bought down to ~1600 m/s:

h4Hi4MF.png

Now, recall that the real-life NASA Orion SM has a rated vacuum delta-V of 1800~2000 m/s - therefore, far from having too much delta-V, the SDHI SM actually has less comparable delta-V. Given the smaller size of the Kerbol star system, I think we can leave the fuel capacity and resulting delta-V as-is.

Finally, the "overheating" issue.

As previously established, the overheat warning is displayed after running the SM engine continuously until fuel depletion. This warning actually comes from the fuel cell built into the SM, which usually displays an overheat warning whenever it reaches 50% of its max-rated temperature - in our case, this is happening because the integrated LF/LOX O-10 "Puff" means the SM is essentially a rocket engine, and the heat from the engine is affecting the fuel cell.

The solution, in this case, was to simply increase the fuel cell PartModule's DefaultShutoffTemp to 95% of the max-rated temperature, and I have confirmed that I can now run the SM engine continuously without ever overheating the fuel cell. This also means I won't need to add the radiator PartModule to the SM.

So, what happens now?

Because of these changes, I'm going have to completely redo the (new) tutorial that I originally planned on uploading to the GitHub wiki this evening.

Consequently, the revamped SDHI SMS month probably won't be out for another month, while I also work on updating optional mod support MM patches, better documentation, nicer brochures etc. But hey, c'est la vie.

 

  • Like 5

Share this post


Link to post
Share on other sites

No worries, and no rush. It's more important to get it done tight, than to get it done quickly, if you ask me. ;) 

Share this post


Link to post
Share on other sites

We did it, guys! I managed to release the V4 revamp well ahead of schedule!

As always, you can find the download links over in the release thread.

  • Like 4

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now