[1.4] SpaceY Heavy-Lifter Parts Pack v1.17.1 (2018-04-02)

[toadicus]

NecroBones, please forgive the stupid question... but I'm trying to test my TweakableEngineFairings fix, and I'm not sure I get how your parts are supposed to work.

Considering your part SYplate2m1mX0. You've got four stack nodes:

node_stack_bottom = 0.0, -0.2, 0.0, 0.0, -1.0, 0.0, 1
node_stack_bottom1 = 0.0, -2.0, 0.0, 0.0, -1.0, 0.0, 2
node_stack_bottom2 = 0.0, -1004.3, 0.0, 0.0, -1.0, 0.0, 2
node_stack_top = 0.0, 0.2, 0.0, 0.0, 1.0, 0.0, 2

In the editor, I see three of these, which I am interpreting as follows: "top", on top as expected; "bottom", flush against the bottom of the part; "bottom1", 2 meters below the part. I think I do not see "bottom2" at all, which makes sense since it's a good kilometer away.

You have two ModuleJettison definitions:

MODULE
{
       name = ModuleJettison
       jettisonName = SYplate2m1mX1shroud0
       bottomNodeName = bottom1
       isFairing = True
       jettisonedObjectMass = 0.1
       jettisonForce = 5
       jettisonDirection = 0 0 1

}

MODULE
{
       name = ModuleJettison
       jettisonName = SYplate2m1mX1shroud1
       bottomNodeName = bottom2
       isFairing = True
       jettisonedObjectMass = 0.1
       jettisonForce = 5
       jettisonDirection = 0 0 1

}

As far as I know, that means the first module will have a fairing when there is a part on "bottom1". The second module will have a fairing when there is a part on "bottom2". Things are working correctly for me in the former case, but I can't figure out how to test the latter case.

TIA!

[NecroBones]

NecroBones, please forgive the stupid question... but I'm trying to test my TweakableEngineFairings fix, and I'm not sure I get how your parts are supposed to work.

Considering your part SYplate2m1mX0. You've got four stack nodes:

node_stack_bottom = 0.0, -0.2, 0.0, 0.0, -1.0, 0.0, 1
node_stack_bottom1 = 0.0, -2.0, 0.0, 0.0, -1.0, 0.0, 2
node_stack_bottom2 = 0.0, -1004.3, 0.0, 0.0, -1.0, 0.0, 2
node_stack_top = 0.0, 0.2, 0.0, 0.0, 1.0, 0.0, 2

In the editor, I see three of these, which I am interpreting as follows: "top", on top as expected; "bottom", flush against the bottom of the part; "bottom1", 2 meters below the part. I think I do not see "bottom2" at all, which makes sense since it's a good kilometer away.

https://imgrush.com/PPY2jkv_8cat.png

You have two ModuleJettison definitions:

-snip-

As far as I know, that means the first module will have a fairing when there is a part on "bottom1". The second module will have a fairing when there is a part on "bottom2". Things are working correctly for me in the former case, but I can't figure out how to test the latter case.

TIA!

Yep, I know it looks confusing, but there's a good reason for it. It's just model-sharing. Both the "A2-1" (SYplate2m1mX0, short fairing) and "A2-1X" (SYplate2m1mX1, long fairing) parts use the same model file. The nodes that are kilometer away are set up that way so that they're unusable for that part, but exists for the other part that shares that model. So basically, to test the other node, you just need to grab the other part.

I forget why this one is split out like that, where others are shared. I think at the time I was trying to add another length without breaking people's saves. KSP 1.0.4's "bug fix" fixed the issue with save-breaking from adding new nodes. But now I'm stuck with two separate part IDs in people's saves, so consolidating them might not be possible now. EDIT: I remember now. They're split & shared because the existence of the other node was making it impossible to use engines of certain lengths, since the engine would want to stick to the bottom nodes in the VAB instead of attaching correctly.

For an example of a part with lots of nodes that are all accessible, you can also look at "A5-123" (SYadapter4-2-1), which has three different top nodes to choose from, none of which are disabled via distance.

Edited June 26, 2015 by NecroBones

[toadicus]

So to clarify, the SYplate2m1mX0 is not intended to display variably-configured shrouds? Will check on the A5-123 shortly.

[toadicus]

For the interested; I've got a TweakableEverything dev build available that adds proper support for parts built like this.

[NecroBones]

So to clarify, the SYplate2m1mX0 is not intended to display variably-configured shrouds? Will check on the A5-123 shortly.

yes, that's right. That one only uses one at a time, but two are built into the model to support two different "parts", rather than variable length shrouds on the same part.

The A5-123 is a good example of one that has variable lengths.

[NecroBones]

I figured I'd go ahead and get this out for the weekend:

0.17.3 (2015-06-26) - M1 update.
 - Added a middle-length, 2.5m "straight" cylindrical fairing to the M1 Moa engine. (requires KSP 1.0.4 to not be save-breaking)

[mikegarrison]

Hey, I decided to try this Moa fairing for myself tonight. (I don't usually use the Moa engine.) I could put the 3.75m fuel tank onto the Moa attach node and it would make a 2.5m to 3.75m fairing. Nice. But that was mounting a fuel tank directly to the engine.

When I grabbed the 3.75m decoupler, though, it wouldn't work. The fairing wouldn't form. I don't know if I was doing something wrong or what. So I grabbed the 3.75m separator from the SpaceY pack, and it worked just fine. Why didn't the stock decoupler work? Is this intended behavior, a known bug, or just something I did wrong?

[NecroBones]

Hey, I decided to try this Moa fairing for myself tonight. (I don't usually use the Moa engine.) I could put the 3.75m fuel tank onto the Moa attach node and it would make a 2.5m to 3.75m fairing. Nice. But that was mounting a fuel tank directly to the engine.

When I grabbed the 3.75m decoupler, though, it wouldn't work. The fairing wouldn't form. I don't know if I was doing something wrong or what. So I grabbed the 3.75m separator from the SpaceY pack, and it worked just fine. Why didn't the stock decoupler work? Is this intended behavior, a known bug, or just something I did wrong?

That's what happens when I don't test it with EVERYTHING... Grrr.

What's happening is that the decoupler has just the right height, that it's trying to attach with the lower node even when the upper node is in the right place, which it can't do. KSP still has a bug where it will still attempt to snap to nodes that are pointed in the wrong way, even though it now enforces the direction and won't actually attach.

The problem is really that I have the nodes too close together. What I should do is simply remove the 5m cone (I doubt anyone uses this anyway), and make the 2.5m straight fairing go to that length.

I'll try to get a hot fix out.

- - - Updated - - -

OK, I've pushed out a fix.

This is strictly affecting the M1 Moa engine:

For anyone who grabbed 0.17.3 (in the last 12 hours), anything you flew with the straight fairing, will have an invisible fairing now. Also, things saved in the VAB will require detaching and reattaching the engine, and probably the part above it.

For anyone who skipped over 0.17.3 (most people), the only change you should see is if you used the 3.75-5m conical fairing, that's been replaced with the straight fairing, which is what you'll see on your rockets. The 3.75-5m conical fairing is deprecated.

0.17.4 (2015-06-27) - M1 update, continued/hotfix
 - Addressed a problem with new straight fairing in M1 Moa engine:
    - Removed middle attachment node that was added.
    - Replaced the 3.75m->5m cone fairing with the 2.5m straight fairing. (doubtful many people use that one anyway).
    - KNOWN ISSUE: If you used the new fairing in 0.17.3 (during the 12 hours or so it was available), the fairing will be invisible on ships already constructed.
    - requires KSP 1.0.4 to not be save-breaking

Edited June 27, 2015 by NecroBones

[NecroBones]

Oh, forgot to mention-- Part of the reason that particular decoupler (stock size 3 decoupler) was so problematic, is that it defines the attachment nodes in the opposite order of all of the other "flat" stock parts, and gives preferential attachment to its bottom node... so trying to use the middle or upper nodes on the M1 in SpaceY-0.17.3 resulted in it snapping in place but unable to attach.

All of this would clear up if Squad would stop letting things snap to nodes that it can't attach to.

But for now, my easy fix was to just get rid of the 5m conical fairing and replace it with the new 2.5m cylindrical one.

[cipherpunks]

Dibamus engine/RCS block has slanted RCS transforms, despite model shows that RCS nozzles are straight. This implies cosine losses (and -25% RCS dV!). Please fix.

Also, for some reason, the amount I put into ModuleRCS thrusterPower is doubled - are RCStransforms doubled too?...

Edited June 29, 2015 by cipherpunks

[NecroBones]

Dibamus engine/RCS block has slanted RCS transforms, despite model shows that RCS nozzles are straight. This implies cosine losses. Please fix.

Also, for some reason, the amount I put into ModuleRCS thrusterPower is doubled - are RCStransforms doubled too?...

Actually, the thrust transforms match the orientation of the nozzles in the model. They're offset by 5 degrees, with the idea of being slightly more "realistic" (since on a real vessel, you'd want it offset to limit the effect of the exhaust interacting with the hull). KSP doesn't have such a drawback of course, so there wouldn't be any harm in "correcting" it. Maybe I'll do that and leave the model alone. It won't line up precisely anymore, but probably no one will look that closely.

And no, the transforms are not doubled up. Or are you talking about the "super dibamous"? That has two transforms in each direction due to having two nozzles pointed each way. But everything else I said above applies to both engines.

[cipherpunks]

No, I'm not talking about "Super Dibamus" - that one indeed has slanted RCS nozzles on its model, I have no problems with its usage pattern and its realism (but I doubt that in reality slanted RCS thrusters are used like in KSP - that is, even if the nozzle is 89.9 degrees from needed vector, it will fire anyway, and waste precious propellant...)

Now that You said the model indeed has canting, I can see it too - on a first glance I thought those were straight; bad sight, or maybe it's just miniscule canting amount :-D

Do as You please.

Me, I just googled some, and then rescaled both to be like SpaceX-SuperDraco-and-a-bunch-of-Aerojet-R-40B-combos, one with shell and one without. I play (or try to play) only RSS, though.

//8 SuperDracos will consume around 250 kg/s of propellant at full throttle. We've been told that the DragonFly will contain 400 gallons of propellant which works out to be ~1500 kg or 6 seconds of 8 engine, full-throttle fun.
//Musk mentioned once that these things could take a Dragon from 0 through the sound barrier in about 3 seconds. Given the 120 klb figure EchoLogic posted above, if a Dragon V2 weighs 6000 kg (a guess. Do we know?), then the maximum acceleration is about 9 g's.
@PART[SYoms1] { // SpaceY "Dibamus" RCS/OMS Thrust Block
@title = SuperDraco twin rocket engine and RCS (Deep Space version)
@manufacturer = SpaceX
@rescaleFactor = 0.7 // Nozzle Exit Diameter 20 cm (8 in)
@mass = 0.12
} // PART

@PART[SYoms2] { // SpaceY "Super Dibamus" RCS/OMS Thrust Block
@title = SuperDraco twin rocket engine and RCS (Aerodynamic version)
@manufacturer = SpaceX
@rescaleFactor = 0.53 // Nozzle Exit Diameter 20 cm (8 in); at 1 nozzle is 38 cm
@mass = 0.15 // has 8 4kN thrusters (~6kg each) + 2 SuperDracos + shell
} // PART

@PART[SYoms1,SYoms2]:FINAL { // SpaceY "Dibamus" RCS/OMS Thrust Block, "Super Dibamus" RCS/OMS Thrust Block
@manufacturer = SpaceX
@MODULE[ModuleEngines] {
@maxThrust = 174.5 // 145.9 at SL; IRL it is programmatically limited to around 136.336 for a pair at SL
@atmosphereCurve {
@key,0 = 0 281
@key,1 = 1 235 // official
} // atmosphereCurve
} // ModuleEngines
@MODULE[ModuleRCS] {
@thrusterPower = 2 // let's say it's Aerojet's R-40B
@atmosphereCurve {
@key,0 = 0 293
@key,1 = 1 170
} // atmosphereCurve
} // ModuleRCS
%MODULE[TweakScale]:NEEDS[TweakScale] { %type = surface }
} // PART

//8 Superdracos will have an axial thrust of 570kN. The current dragon has a dry mass of 4200kg, propellant mass of 1290kg, and maximum cargo mass of 7200kg, totalling 12690kg. Let's just leave that figure at that because if it were carrying people, I doubt cargo and added life support and people would total 7200kg, but Dragon 2 will likely be heavier. That gives us an acceleration of about 44m/s2 or about 4.5G's

Note that @thrusterPower = 2 makes it 4kN according to RCSBuildAid, as that R-40B should be.

Edited June 30, 2015 by cipherpunks
add MM cfg

[mikegarrison]

Oh, forgot to mention-- Part of the reason that particular decoupler (stock size 3 decoupler) was so problematic, is that it defines the attachment nodes in the opposite order of all of the other "flat" stock parts, and gives preferential attachment to its bottom node... so trying to use the middle or upper nodes on the M1 in SpaceY-0.17.3 resulted in it snapping in place but unable to attach.

All of this would clear up if Squad would stop letting things snap to nodes that it can't attach to.

But for now, my easy fix was to just get rid of the 5m conical fairing and replace it with the new 2.5m cylindrical one.

I should report back. I tried this again and what happens now is that the stock decoupler sort of snaps into what looks like the right place, but is still grayed out. However, a little nudge up on the mouse now convinces it to attach to the correct node. So it's fiddly, but it works. Unfortunately, people who don't try fiddling with it may still come back reporting that it doesn't work. But it does work now.

[cipherpunks]

For me, great many parts are like so - hesitant to attach at first. Many simple parts from many mods. For example 2.5m BOMP.

[NecroBones]

I should report back. I tried this again and what happens now is that the stock decoupler sort of snaps into what looks like the right place, but is still grayed out. However, a little nudge up on the mouse now convinces it to attach to the correct node. So it's fiddly, but it works. Unfortunately, people who don't try fiddling with it may still come back reporting that it doesn't work. But it does work now.

For me, great many parts are like so - hesitant to attach at first. Many simple parts from many mods. For example 2.5m BOMP.

Yeah, most of the time it's just KSP snapping things to nodes that are disallowed. Squad really needs to add a check for that before snapping.

[passman]

seems there's a bug with the 10R radial booster

double stacking them with the TT38k decoupler causes massive overheating

this illustrates it

http://i.imgur.com/uW6UBpY.jpg

- - - Updated - - -

oh also 10/10 mod never play without it

[damerell]

seems there's a bug with the 10R radial booster; double stacking them with the TT38k decoupler causes massive overheating

It seems to me that 1.0.3/4 heat is a bit buggy. Mods seem often to have curious consequences. But turning on thermal debug and seeing in the right-click menu where heat comes from would be useful?

[NecroBones]

seems there's a bug with the 10R radial booster

double stacking them with the TT38k decoupler causes massive overheating

this illustrates it

http://i.imgur.com/uW6UBpY.jpg

- - - Updated - - -

oh also 10/10 mod never play without it

It seems to me that 1.0.3/4 heat is a bit buggy. Mods seem often to have curious consequences. But turning on thermal debug and seeing in the right-click menu where heat comes from would be useful?

Yep, I'm pretty sure it's a KSP bug. I've seen it demonstrated with stock parts too. It has something to do with parts connected through smaller parts, with phantom heat being generated. This particular SRB has nothing special about it, and it has the same thermal settings as my other SRBs, and the stock SRBs. I think something that influences it is the relative sizes of the object and the small part that it's attached to.

[ick98]

Some liquid fuel engines and SRB are muted. I do not know what happened, because all other versions of Space Y always worked normally. Let me know what happened?

[NecroBones]

Some liquid fuel engines and SRB are muted. I do not know what happened, because all other versions of Space Y always worked normally. Let me know what happened?

Muted, you mean the sounds aren't working? I added some custom sounds a few releases back. They're just in WAV format. It might be useful to see if your game log shows these files not being found or something.

Maybe also try completely deleting and then re-installing SpaceY. As long as everything goes in the right folder, the sounds should work.

[ick98]

I uninstalled and installed again the Space Y, I downloaded an older version and so I changed the sound folder, I downloaded again and still not worked. I did not understand until now what's going on.

[NecroBones]

I uninstalled and installed again the Space Y, I downloaded an older version and so I changed the sound folder, I downloaded again and still not worked. I did not understand until now what's going on.

I'm still curious to see what your log shows. Did you rename the folder or anything? It expects to find the sounds in "GameData/SpaceY-Lifters/Sounds"

I'm working on moving the custom sound definitions to a separate MM config file, so that you can just disable the custom sounds by deleting that one file. I should be able to get that out pretty soon.

[NecroBones]

Alright, I pushed the update out. To disable the custom sounds (and go back to the default KSP sounds), you can just delete the "SpaceY_CustomSounds.cfg" file. I moved the custom sound settings to that.

0.17.5 (2015-07-05) - Tweaks.
 - Added ConductionFactor/convectionflux settings for petal bay.
 - Adjusted OMS/RCS blocks' RCS thrust vectors to remove 5-degree offset (and thus minimize cosine losses).
 - Moved custom engine sounds to separate "SpaceY_CustomSounds.cfg" ModuleManager file, for easy removal.

[mikegarrison]

Alright, I pushed the update out. To disable the custom sounds (and go back to the default KSP sounds), you can just delete the "SpaceY_CustomSounds.cfg" file. I moved the custom sound settings to that.

0.17.5 (2015-07-05) - Tweaks.
 - Added ConductionFactor/convectionflux settings for petal bay.
 - Adjusted OMS/RCS blocks' RCS thrust vectors to remove 5-degree offset (and thus minimize cosine losses).
 - Moved custom engine sounds to separate "SpaceY_CustomSounds.cfg" ModuleManager file, for easy removal.

For the record, I didn't mind the 5 degree cosine losses, but I don't mind this change either.

[NecroBones]

For the record, I didn't mind the 5 degree cosine losses, but I don't mind this change either.

Yeah, it's subtle enough that most people don't notice one way or the other.