[1.2 - 1.4] Modular Rocket Systems v1.13.2 (2018-03-12) - Stock-alike Parts Pack

[billkerbinsky]

[quote name='NecroBones']Something I'm tempted to do is to go back and add solid propellant motors to many of my stack decouplers (MRS and SpaceY), just with it defaulting to zero fuel, so that it's an optional upgrade in the VAB to fuel it up and use it. This would function similarly to the SpaceY rocket-powered radial decouplers.[/QUOTE]
In at least some cases, separation retrorockets are located far from the interstage - for instance, on the Saturn V first stage, they were in the aerodynamic skirts just above the four outside engines. Damage to the upper stage is clearly a concern...

On the other hand, here's a clip of a S-IVB separation (from a Saturn IB first stage during the AS202 test flight) that clearly shows three ullage motors burning before the J-2 lights up - [url]https://vimeo.com/96999455[/url]

[DDay2021]

[quote name='NecroBones']Something I'm tempted to do is to go back and add solid propellant motors to many of my stack decouplers (MRS and SpaceY), just with it defaulting to zero fuel, so that it's an optional upgrade in the VAB to fuel it up and use it. This would function similarly to the SpaceY rocket-powered radial decouplers.[/QUOTE]

I use too many mods to be sure where I've seen it, but I've seen a 2.5M reaction wheel that comes in two parts to strap around a fuel tank. Something like that with either solid rocket or monoprop motors could make for a low part count separator/ullage motor that you could place wherever you feel it should go.

[NecroBones]

[quote name='Vandros']Would be awesome! Right now i fiddle with sepatrons and the editor tools, but this would be great for the part count.

Besides, you would probably make some slick adjustments to the models right? ;)[/QUOTE]

[quote name='billkerbinsky']In at least some cases, separation retrorockets are located far from the interstage - for instance, on the Saturn V first stage, they were in the aerodynamic skirts just above the four outside engines. Damage to the upper stage is clearly a concern...

On the other hand, here's a clip of a S-IVB separation (from a Saturn IB first stage during the AS202 test flight) that clearly shows three ullage motors burning before the J-2 lights up - [url]https://vimeo.com/96999455[/url][/QUOTE]

[quote name='DDay2021']I use too many mods to be sure where I've seen it, but I've seen a 2.5M reaction wheel that comes in two parts to strap around a fuel tank. Something like that with either solid rocket or monoprop motors could make for a low part count separator/ullage motor that you could place wherever you feel it should go.[/QUOTE]

Yeah, we always have to play a balance-game between realism, part count on the vessel, and part count in the menus.

Putting sep-motors in the decoupler:
- Pro: No additional part count, anywhere.
- Con: Not the most realistic arrangement.

Adding them as stick-anywhere "sepratron"-like parts (just prettier and in more sizes):
- Pro: You can put them anywhere, in any orientation.
- Con: Increases vessel part count (possibly by quite a lot).

Adding them as ring-halves, like the KW and SpaceY reaction wheels:
- Pro: Very mild vessel part-count increase, and can be placed anywhere in the stack.
- Con: Only one orientation (two if you count flipping it), and every supported diameter has to be added as menu parts.


For the MRS "low profile" decoupler, I've already added the solid motors, since that seems like a very stock-alike way to do it, which is the flavor of this pack. The nozzles are inside the ring, but exhaust damage is disabled for them. I thought about having external nozzles, but this is the "low profile" decoupler, meaning it shouldn't really have anything visible or protruding from the outside. For other sizes, and in SpaceY, I'll think over those options.

[IMG]http://ksp.necrobones.com/screenshots/2015-11/KSP%202015-11-19%2018-05-54-62.jpg[/IMG]

[billkerbinsky]

[quote name='NecroBones']For the MRS "low profile" decoupler, I've already added the solid motors, since that seems like a very stock-alike way to do it, which is the flavor of this pack. The nozzles are inside the ring, but exhaust damage is disabled for them. I thought about having external nozzles, but this is the "low profile" decoupler, meaning it shouldn't really have anything visible or protruding from the outside. For other sizes, and in SpaceY, I'll think over those options.[/QUOTE]

Just a random idea:

Put the retrorockets around the perimeter, angled out slightly (at 30 degrees, you'll get (1-cos(30)) = about 14% cosine loss); the exhaust doesn't hit the upper stage, you get a nice pyro fountain effect, and if you put blow-off panels over the nozzles, a little confetti, too...

[NecroBones]

[quote name='billkerbinsky']Just a random idea:

Put the retrorockets around the perimeter, angled out slightly (at 30 degrees, you'll get (1-cos(30)) = about 14% cosine loss); the exhaust doesn't hit the upper stage, you get a nice pyro fountain effect, and if you put blow-off panels over the nozzles, a little confetti, too...[/QUOTE]

See above, about why I didn't stick them on the outside. :) The problem with putting them interior at all, but close to the edge, is that they would then fire through whatever fairing sticks to the decoupler from an engine above. No good solution without making the ports completely external (in which case I'd angle them a little as you mentioned). I could still redesign it to do that. We'll see.

[Thourion]

[quote name='NecroBones']....I could still redesign it to do that. We'll see....[/QUOTE]

Nononononono, the MRS LP decoupler is one of my favorite parts, dont mess around with it please hahah!

The one with the solids inside in your picture is super nice though!

[NecroBones]

[quote name='Thourion']Nononononono, the MRS LP decoupler is one of my favorite parts, dont mess around with it please hahah!

The one with the solids inside in your picture is super nice though![/QUOTE]

Hehe, glad you like it. :) Yeah, I think I'm keeping this one as shown in the screenshot. ;)

[NecroBones]

Update posted:

 

1.11 (2015-12-02) - Decoupler pass.
 - Increased heat tolerance of 2.5m stack decouplers by 200 degrees.
 - 2.5m "low profile" stack decoupler updates:
    - Added internal "sepratron" solid motors as optional separation aids (remove propellant to not use).
    - Increased cost and base mass (to balance this against stock decoupler).
    - Added drag-cube to match stock decoupler. 

 

[CorBlimey]

hi, is it safe to mid-game upgrade from the Lite to Full pack? Or conversely to downgrade if I have only used parts also in the Lite pack?

[NecroBones]

22 hours ago, CorBlimey said:

hi, is it safe to mid-game upgrade from the Lite to Full pack? Or conversely to downgrade if I have only used parts also in the Lite pack?

Yep, that should be safe. The Lite and Full versions have identical copies of the parts they share. Just don't try to run them simultaneously.

[CorBlimey]

On 14/12/2015, 14:15:21, NecroBones said:

Yep, that should be safe. The Lite and Full versions have identical copies of the parts they share. Just don't try to run them simultaneously.

great, thanks.

Are you planning to release a version of the full pack that fits in better with your Fuel Tanks Plus? (Redundant fuel tanks gone, to reduce clutter). I like some of the additions of full over light, but have hundreds of parts (not just from this mod :D) that I never use as there are superior version. Let's be honest, everyone who uses MRS should damn well be using FTP too as it is awesomesauce!

[Uthgood]

30 minutes ago, CorBlimey said:

great, thanks.

Are you planning to release a version of the full pack that fits in better with your Fuel Tanks Plus? (Redundant fuel tanks gone, to reduce clutter). I like some of the additions of full over light, but have hundreds of parts (not just from this mod :D) that I never use as there are superior version. Let's be honest, everyone who uses MRS should damn well be using FTP too as it is awesomesauce!

you could always go thru your gamedata folders and delete the specific parts that you dont use, but would have to do that every time you update your mods

[NecroBones]

Yeah, MRS is pretty friendly to deleting parts, as compared to my other mods, since it's more stock-alike in how its organized. Very little in the way of texture sharing or anything like that.

 

I haven't decided what to do, but it's something I've thought about too. Those redundant fuel tanks are some of the first parts I made, so of course back then I had no idea what else I would end up making. I'm not sure if I want to just start trimming things out or not. Something I could probably do is phase some parts out by including them as non-selectable "deprecated" parts, like the old FTP tank variants that are marked as deprecated currently. That allows a grace period where they're still included to avoid breaking saves, but can't be purchased in the VAB.

 

I don't know. There's never a perfect solution.

[WuphonsReach]

I'd say mark them as unselectable, with plans to remove them come 1.1 (which I kind of expect will be game-save-breaking).

[CorBlimey]

19 hours ago, WuphonsReach said:

I'd say mark them as unselectable, with plans to remove them come 1.1 (which I kind of expect will be game-save-breaking).

yeah, this is a good compromise.

In the meantime I might just write a quick batch script to delete them.

Anyway, r.e. the main topic, I can't believe I went so long without FTP and MRS. My rockets have never looked better :)..... now if only I could find something that colours the engine shrouds!!

[NecroBones]

Yeah, the shrouds are a lot more complicated to deal with, when it comes to color-switching. I'm thinking about how to handle it. It would be essentially the same thing as color switching on the fuel tanks I think, except it would be a multi-shroud setup with all of them assigned to the same attachment node. I think that will work, but I'll have to experiment with it. It's not a short-term goal because of that.

[CorBlimey]

On 18/12/2015 at 6:22 PM, NecroBones said:

Yeah, the shrouds are a lot more complicated to deal with, when it comes to color-switching. I'm thinking about how to handle it. It would be essentially the same thing as color switching on the fuel tanks I think, except it would be a multi-shroud setup with all of them assigned to the same attachment node. I think that will work, but I'll have to experiment with it. It's not a short-term goal because of that.

fingers crossed

[WuphonsReach]

A suggesion for the MRS docking port helpers.  I noticed that you added lights (great!) to them as additional little nubs.  My suggestion is to replace the green lights at 3 o'clock and 9 o'clock with the white lights instead.  So you would have red at 12 o'clock and yellow at 6 o'clock, with white at 3 and 9.

[NecroBones]

1 hour ago, WuphonsReach said:

A suggesion for the MRS docking port helpers.  I noticed that you added lights (great!) to them as additional little nubs.  My suggestion is to replace the green lights at 3 o'clock and 9 o'clock with the white lights instead.  So you would have red at 12 o'clock and yellow at 6 o'clock, with white at 3 and 9.

That could work. I've added it to my notes to look into later.

[Randazzo]

On ‎12‎/‎18‎/‎2015 at 0:22 PM, NecroBones said:

Yeah, the shrouds are a lot more complicated to deal with, when it comes to color-switching. I'm thinking about how to handle it. It would be essentially the same thing as color switching on the fuel tanks I think, except it would be a multi-shroud setup with all of them assigned to the same attachment node. I think that will work, but I'll have to experiment with it. It's not a short-term goal because of that.

You'd end up with lots and lots of "Hide Shroud" options in the VAB.

If you're going to use IFS mesh switching on them you could save yourself a headache by creating an empty object to serve as the actual "fairing" object in the config and have it be the parent to the multiple meshes.

• Engine
  • Fairing (empty object)
    • mesh 1
    • mesh 2
    • mesh 3
    • mesh 4

and a single moduleJettison, Instead of

• Engine
  • Fairing1
  • Fairing2
  • Fairing3
  • Fairing4

With 4 moduleJettison. Make sense? Makes sense to me, but I probably belong in a padded room.

edit: and I just noticed that was 10 days old. So. Yeah.

Edited December 30, 2015 by Randazzo

[NecroBones]

8 hours ago, Randazzo said:

You'd end up with lots and lots of "Hide Shroud" options in the VAB.

If you're going to use IFS mesh switching on them you could save yourself a headache by creating an empty object to serve as the actual "fairing" object in the config and have it be the parent to the multiple meshes.

-----

edit: and I just noticed that was 10 days old. So. Yeah.

No worries on the date, it's a good idea! Thanks. I've been doing some testing with it on the SpaceY 5m tanks today, and so far it mostly works. I have one tank that refuses to work with it, and does the Z-fighting thing no matter what I do (and yet works fine when assigning them all individually like I do currently). It's making me nervous to roll it out as a blanket update in any of the mods until I can figure out what's going wrong. But getting rid of all those "Shroud" buttons would be great for the crowd who doesn't enable mesh switching.

 

What would be even better is if Squad would add a stock option to the "MODEL {}" syntax to have an entry that lists meshes to disable or ignore. That would be awesome.

Edited December 31, 2015 by NecroBones

[Bluebottle]

Hi NecroBones. This is one of my favorite mods (in every install since 1.0), so it troubled me when I noticed something with the inline drill. If I build a vessel with the inline drill as the root part, I get a bizarre result when reloading it/refreshing the scene. The initial launchpad load is OK.

On reload, I get this exception:

Spoiler

[LOG 03:57:12.187] [FLIGHT GLOBALS]: Switching To Vessel Untitled Space Craft ---------------------- 
[LOG 03:57:12.187] setting new dominant body: Kerbin
FlightGlobals.mainBody: Kerbin
[LOG 03:57:12.187] Reference Frame: Rotating
[WRN 03:57:12.212] HighlightingSystem : Multiple Highlighter components on a single GameObject is not allowed! Highlighter has been disabled on a GameObject with name 'model'.
[EXC 03:57:12.295] IndexOutOfRangeException: Array index is out of range.
	ModuleAnimationGroup.get_ActiveAnimation ()
	ModuleAnimationGroup.PlayDeployAnimation (Int32 speed, System.Action postAnimate)
	ModuleAnimationGroup.SetRetractedState (Int32 speed)
	ModuleAnimationGroup.CheckAnimationState ()
	ModuleAnimationGroup.OnLoad (.ConfigNode node)
	PartModule.Load (.ConfigNode node)
	Part.LoadModule (.ConfigNode node, System.Int32& moduleIndex)
	ProtoPartModuleSnapshot.Load (.Part hostPart, System.Int32& moduleIndex)
	ProtoPartSnapshot.Load (.Vessel vesselRef, Boolean loadAsRootPart)
	ProtoVessel.LoadObjects ()
	Vessel.Load ()
	Vessel.MakeActive ()
	FlightGlobals.setActiveVessel (.Vessel v, Boolean force)
	FlightGlobals.SetActiveVessel (.Vessel v)
	FlightDriver.Start ()

 

The result is that the entire vessel disappears except for the drill (root part). If it's in orbit, the orbit freezes, along with much of the UI. If it's an on-the-launchpad reload, the drill is suspended in its original location, floating in mid-air and wobbling. FAR joins in by throwing ~100 NREs per second, about missing objects and rebuilding meshes.

If I use any other part as the root, everything is fine on a vessel reload. One thing: the stock drill is not able to be used as a root part, at least without SelectRoot trickery, and since you're using the same animation as the stock drill, a missing or invalid part of that animation wouldn't show up as a problem with the stock drill. That's presuming that a problem with the stock animation is causing your drill to halt the vessel loading process, since it's the root part.

I do have 192 mods installed but a text search reveals that none of them patch your inline drill, not even for tech tree nodes. Linux x64 KSP v1.0.5, MRS Lite v1.10 via CKAN.

Edited January 24, 2016 by Bluebottle
grammar

[NecroBones]

I can't really say I'm surprised. As you say, since the stock drill was never intended to be used as a root part, they would never have tested that. For now, the best workaround will be to use something else as your root parts. We'll chalk this one up to a "known issue, related to a KSP bug".

 

[Bluebottle]

21 minutes ago, NecroBones said:

I can't really say I'm surprised. As you say, since the stock drill was never intended to be used as a root part, they would never have tested that. For now, the best workaround will be to use something else as your root parts. We'll chalk this one up to a "known issue, related to a KSP bug".

 

No problem. May I suggest that you add a note in the drill's description text?

[NecroBones]

6 hours ago, Bluebottle said:

No problem. May I suggest that you add a note in the drill's description text?

Yep, I'll have that in the next update. Thanks!