sumghai

I concur with @The Aziz and @Gargamel's sentiments. As per the title of the game, this is Kerbal Space Program, not Kerbal Vehicle Simulator, so naturally, the default Vessel type designations available in the stock game would be ones most commonly associated with contemporary space exploration (i.e. no boats or submarines). I definitely like the idea of reworking the Vessel type designations to be defined via CFGs and icon images, so that modders and players can customize and extend the available options as desired.

Ayup, that was the consensus. Apologies, I should have been a bit more clearer - at the time, I was asking if the stock procedural fairings could be made to be of fixed size, diameter, length and shape, so that I can implement the Service Module side fairings in a similar manner to the stock fairings (float-away ghosting and all). Given what I've learn now, it looks like it won't do what I'm looking for. In the meantime, no progress report just yet, but I'm currently investigating how to revamp the Boost Protect Cover and Launch Abort system - I've been quite impressed with how SSTU uses switch-mode engines to control both the LAS Abort and Jettison motors, although I'm not sure if this would be too complicated for most users.

@dogeGAMr, sal_vager has retired from moderation duties. KSP uses Unity 5.

I don't think the old Avionics Ring, the new CMA or any iteration of the Service Module actually had a probe core or ModuleCommand. To clarify, are you instead suggesting I keep the SAS feature and not the Reaction Wheels? Noted!

Progress Report, 12 August 2018 I refined the model for the toggleable umbilical interface on the Mk1-3 Pod, with actual meshes instead of normal maps for faux data and fluid connectors. Both the pod and umbilical arm interfaces share the same UV mapping, which ensures both will have consistent textures. Over the next couple of days, I began splitting the models out into individual parts, starting with the CMA and SM Trunk. As explained previously, the CMA part can be used on its own as a decoupler compatible with the SDHI Heat Shield, or combined with the Trunk model to make the Service Module part. Toggling the umbilical interface on the Mk1-3 Pod still works the same as in earlier versions: As always, the decoupler for the CMA and full SM is not stageable, primarily to prevent users accidentally decoupling their crew pod without executing a proper re-entry burn first. The LF/LOX variant O-10 engine built into the SM can be staged and activated normally. It uses the same FX as the original stock monoprop O-10, but has thrust characteristics equivalent to the LV-909. The decoupler behaviour is perfectly consistent across both the CMA and full SM, with the pod now ejecting straight out without the dreaded lurching-to-the-side shenanigans reported by users in earlier versions. Opinions and Feedback Needed! I'm thinking of revising the featureset for the CMA and SM, with the intention of the CMA being strictly a decoupler due to its unusual shape and low internal volume. I also would like to encourage the use of RCS instead of Reaction Wheels for attitude control. What do you guys think of the following?: Crew Module Adapter (CMA) (Animated) Decoupler Battery SAS ? Reaction Wheel Fuel Cell Service Module (Animated) Decoupler Monoprop (100 units) Battery (200 EC) LF/LOX (360/440 units) SAS ? Reaction Wheel Fuel Cell Engine (LF/LOX variant of O-10)

[MOD - Some inflammatory posts have been snipped from this thread. Please refrain from personal attacks, and instead focus on the technical issues of the discussion.]

Did this happen in a modded game? If so, what mods do you have loaded?

[MOD - Thread locked and download links removed, as the KSP Profile Manager application requires third-party source code not included in GitHub repo. We're sorry that we had to disallow posting it here, and did not arrive at this decision easily. Clearly you've put a lot of work into this to try to improve the lives of your fellow KSP players, and we absolutely want to encourage that sort of thing, in general. We really appreciate the contributions of public-spirited people like you. Unfortunately, the source code and licensing provisions require us to disallow it in this case-- regretfully. We hope this doesn't discourage you from further efforts. Thank you for your understanding, and our sincere apologies for the inconvenience. ]

[MOD - Moved to Add-on Discussions]

Was MechJeb the only mod you have in your game install? Did you try reproducing the issue without mods? (i.e exiting time warp using the time control functions in the stock vanilla game) Was your spacecraft transitioning into an atmosphere at the time of exiting time warp?

@Sir LaYz, I've moved the log file snippet into a code block to keep your post to a comfortable size. If you want to post a full log, my recommendation is to upload the entire text file to Pastebin, then link to it in your forum post.

[MOD - Moved to Add-on Discussions, as this is a question regarding an add-on/mod rather than the stock game.]

@Katten, I have restored your download link. Just wondering, why does the compiled version of DLL contain references to the ChronoReader class, even though the source code on your GitHub repo doesn't have a definition for it?

Well, neither umbilical nor CMA are supposed to be axially rotated, so it's an either/or decision. If I rotated it further to under the viewport, that would actually put the umbilical on the port (left) side of the pod, which would end up looking asymmetrical. Progress Report, 3 August 2018 I finally decided to put the umbilical on the ventral (bottom) side of the pod. I managed to slim the umbilical swing arm down to make the whole stack more aerodynamic like the real Orion MPCV, although I wasn't able to make it completely flush due to the thin wall of the Crew Module Adapter (and a desire to keep the thickness of the umbilical plausible to accommodate the imaginary plumbing and wiring). I also still need to refine the umbilical interface model on the pod.

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: Noted

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.

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!

The Imgur album option has been broken for a very long time, and there is no estimate on when it will be fixed. Most people here right-click on the image in Imgur to copy its the location/URL, then copy and paste it directly in the posting area to embed it.

@TheMiningTeamYT, I suggest rehosting your image onto Imgur instead, as that way you'll be able to embed the image properly on these forums.

[MOD - Moved to Modelling and Texturing subforums] As per preceding posts, while it's technically possible to make parts in SketchUp and install third-party plugins to allow UV-mapping, the fact of the matter is one would still need additional software like 3DS Max and Blender to prior to configuring shaders, animations, colliders and PartTools in Unity. Blender does have a fairly steep learning curve, but is exceptionally powerful, comes with native UV-mapping tools and integrates extremely well with Unity via Prefabs. There are plenty of good tutorials on the internet, which is how I self-taught myself from an engineering parametric CAD-based background to a reasonably competent (if amateur) Blender modeller. As for Zbrush, I personally feel it is more geared towards organic forms like detailed character and car models/sculptures, and thus less optimal for the simpler mechanical/cylindrical profiles of most rocket parts that newbie modders would start making.

[MOD - Just a friendly reminder, folks. Please focus your discussions on the technical aspects of the proposal at hand, rather than trying to determine each other's motives. Thanks!] Here's an interesting StackExchange discussion on balloon-launched rockets: https://space.stackexchange.com/questions/1635/could-it-be-possible-to-launch-a-rocket-from-a-balloon Essentially, while it is technically possible to launch a rocket from a balloon, the fact of the matter is such a system would not provide enough savings in fuel and delta-V to be financially viable. In the context of KSP, this would mean balloon-assisted launch systems would only be viable for very small sounding rockets (i.e. much smaller than the smallest 0.625m diameter rocket parts in-game). And since gameplay would very quickly advance into spaceflight beyond Kerbin, it makes little sense for development time to be invested in a feature that the vast majority of players would very quickly outstrip.

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.

@Airomod, as you have posted in the modded installs support section, could you please list the mods you are using? Have you also tried running the game without any mods to see if it crashes?

[MOD - Moved to Modelling and Texturing Discussion, as the proposal is to do with add-on authoring rather than the base game]

Looking at your models, you probably want to smooth out your meshes in Blender/Wings3D, and add (but not apply) Split Edge modifiers to the cutouts in the sphere.