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

[blowfish]

37 minutes ago, CorBlimey said:

Part proliferation is a real issue - my build times have snowballed just because I spend so much time trying to find the part I want!! (and performance reasons - but hoepfully 64 bit KSP does away with those worries)

Unlikely that 64 bit will have any impact on load times or overall performance.  The benefit will really just be in available memory.

[CorBlimey]

24 minutes ago, blowfish said:

Unlikely that 64 bit will have any impact on load times or overall performance.  The benefit will really just be in available memory.

I agree but parts loaded by KSP take up memory, even if not in flight. So 64 bit should eliminate these issues (e.g. I have to run in OpenGL currently, as 3.2GB memory is used in D3D and there is a memory leak which leads to crashes after a few scene transitions :()

I am expecting some other performance tweaks in 1.10 (related to Unity 5 rather than 32 vs 64 bit) but that wasn't my point. Simply loading the parts for use in teh VAB/SPH is an issue. MRS + FTP + SpaceY adds a lot of parts. Then toss in MKS and some others and it is a serious issue.

[NecroBones]

Yeah, I'll have to give it some thought. Parts proliferation is the main reason I haven't added a ton of additional adapters so far. I'm starting to pull away from the super-cool and creative use of shrouds and adaptive parts, because various KSP bugs keep interfering with it (such as pieces going missing after quicksaves, etc). I really want to see how things behave in KSP 1.1.

 

[PickledTripod]

3 hours ago, NecroBones said:

Yeah, I'll have to give it some thought. Parts proliferation is the main reason I haven't added a ton of additional adapters so far.

That kind of structural adapters can really clutter the part catalog, especially if you have multiple mods adding them like Near Future Construction. And they're less and less useful as surface-attachable engines have become all the rage with Cryo Engines, SpaceY and the stock Vector and Aerospike, now you can just make your own clusters.

If you want to discontinue all those multi adapters you could just enable surface attach on the bottom of those larger-to-smaller adapters with shrouds, and maybe prettify them a little bit. And reinforce the bottom node joint connection, right now they don't really like having an heavy rocket stage on top of them and attaching struts is nearly impossible.

Or... You could go procedural. That would be an entirely new mod I guess, but here's the idea: thrust plates of a set diameter top on which you can toggle the smaller bottom nodes. Here's an example with a SLS-like adapter:

It's just an idea I had a while ago. It would probably be hard to do something like that, require writing a plugin but I think it'd be cool. Kind of like the Procedural Fairings thrust plate, but better looking. They could come in various size like 2.5m to 1.25m, 3.75m to 1.25m, 5m to 2.5m, etc. There could be flat variants, while larger adapter could hold fuel...

[NecroBones]

Yeah, it would definitely need to be a plugin if it's changing actual attachment nodes. The good news is that you can more or less ignore existing nodes and put engines where ever you want when they're "attach anywhere" (and you can do it anyway with additional parts). It's a cool idea, but I don;t make plugins unfortunately.

[blowfish]

8 minutes ago, NecroBones said:

Yeah, it would definitely need to be a plugin if it's changing actual attachment nodes.

I actually have a plugin that enables toggling of attachment nodes along with models and resources (and some other stuff), but it might be a bit heavyweight if you're just using it for just a few parts.  Here's some more info, if you're interested:

Spoiler

This plugin (B9PartSwitch) provides mesh, resource, and node switching (plus a couple of other things).  Here are a few of the features it provides:

• Everything done via named nodes and separate values, which are easier to read than Firespitter's comma separated lists (and easier to patch with MM)
• Any number of models and nodes can be switched by the same subtype
• Tank definitions are universal, so you only have to specify a volume and a tank type and the plugin will fill in the resources and add mass and cost for the tank (stockish tank definitions are included but no reason you can't make your own).  So e.g. you create a tank definition that specifies 45% LiquidFuel and 55% Oxidizer with some mass and cost per volume that are added to the base cost/volume of the part, then specify that tank in a part subtype.
• Additional mass, cost, or tank volume can be specified per subtype
• Drag cubes are recalculated, and FAR is appropriately triggered so that mesh switching affects drag as it should
• Any number of switcher modules can exist on the same part, provided they don't manage the same things (resources, meshes, nodes, etc)
• Max temp, max skin temp, and surface attach node can also be different between variants.  Temperature switching allows pseudo-shielded variants
• Easy enough to add additional things to switch.  I was considering adding CoM offset for instance.

Here is an example part config using this plugin.  I will be releasing the first official version with the next release of B9.

Oh, and credit to bac9, this is really an iteration of his work.

 

[NecroBones]

Yeah that is pretty cool. I think if I were to work with that, it would need to be a separate pack, rather than adding another dependency to the mainline SpaceY.

 

[NecroBones]

On 1/16/2016 at 1:09 AM, PickledTripod said:

 And reinforce the bottom node joint connection, right now they don't really like having an heavy rocket stage on top of them and attaching struts is nearly impossible.

 

Forgot to mention this part. Right now there's not a lot I can do about that. I've set some pretty strong breaking strengths on most of the SpaceY parts already. But aside from that, how bendy or stiff a joint is comes almost entirely from the part's mass. Any parts that are thin and lightweight will suffer accordingly, so the solution that KSP gives us is to increase the mass of these parts considerably.

 

I've been asking for a joint-stiffness multiplier that we can use. I'm really hoping they add that or something similar.

[danfarnsy]

On 1/15/2016 at 0:18 PM, blowfish said:

Unlikely that 64 bit will have any impact on load times or overall performance.  The benefit will really just be in available memory.

I've been using the 64-bit Linux version for a while now. If anything, 64-bit takes longer, because there's no point in having so much memory if you aren't cramming it full of mods and high-res textures which makes loading the game take ages. The growth is greater-than-linear, too, as a number of mods have module manager patches which get applied to each other's parts. Currently I'm sitting at ~17k MM patches during load. It sure is pretty, though!

[maculator]

I noticed that the really huge boosters in the normal SpaceY pack have some texture "flittering" on the "skirtlike" thing at the bottom.

Sorry but I'm missing some vocabulary here :/

[NecroBones]

1 hour ago, maculator said:

I noticed that the really huge boosters in the normal SpaceY pack have some texture "flittering" on the "skirtlike" thing at the bottom.

Sorry but I'm missing some vocabulary here :/

Do you mean z-fighting? Or do you have a screenshot?

 

If it's a z-fighting problem, here's the troubleshooting section from the OP:

 

Problem: Fuel tanks or SRBs flash different colors, with glitchy "z-fighting":

Usually it boils down to one of a few different things. Now that I've seen probably most of them, I can give you a good list:

1. Everything is installed correctly, but ModuleManager's cache hasn't noticed the changes yet.

   Fix: This is a great one to try first. Delete the file called "ModuleManager.ConfigCache" in GameData. ModuleManager recreates it on the next KSP start.

2. ModuleManager isn't installed.

   Fix: Install it.

3. This mod is installed incorrectly, or you've deleted the color-change ModuleManager configs.

   Fix: Reinstall the mod correctly, and in its entirety. The MM config files include rules for what to do when color-changing isn't available, so please don't delete those.

4. ModuleManager thinks color-changing is available via Firespitter or InterstellarFuelSwitch, but neither is installed.

   Fix: This is a little trickier to pinpoint. Either another mod has bad rules in it (for instance using "FOR[Firespitter]" instead of "NEEDS[Firespitter]") and is therefore tricking ModuleManager, or one of these two mods is only partially installed. That could happen if you removed them via CKAN but the directories still exist, which ModuleManager will see as having them installed. To fix, either make sure both of those mods are completely uninstalled, or install one (or both) of them. Only the DLL from one of them is needed, you don't need the entire mod. But it needs to be running if ModuleManager thinks its there.

5. It's possible that another mod may be confused that changes how VAB/SPH tweakables or engine shrouds work.

   This is an odd case, but not impossible. When you don't have Firespitter or InterstellarFuelSwitch installed, the alternate paint jobs are disabled by turning them into "engine shrouds" that correspond to an attachment node that is a kilometer outside the VAB. If another mod interferes with this, such as defaulting all shrouds to "on" even when detached, then you might also see z-fighting. Sadly, the solution might be to simply not use the mods together.

[maculator]

Thanks I deleted the modulemanager files and it worked again. And yes the word I was looking for was z-fighting.

[NecroBones]

42 minutes ago, maculator said:

Thanks I deleted the modulemanager files and it worked again. And yes the word I was looking for was z-fighting.

 

Awesome, glad it was easy.

[PickledTripod]

Quick suggestion for the next update: color switching for decouplers and separators.

[NecroBones]

1 hour ago, PickledTripod said:

Quick suggestion for the next update: color switching for decouplers and separators.

Good idea. We have that in FTP but not here.

 

[Motokid600]

Do you have any landing kegs other then the radial 3.75m ones and the stacked 5m ones? The smaller radial attatch legs worked really good, but there too small for my 5m rocket. I'm having issues with the stackable 5m ones on the fixed ring. They... Dance lol.  Best way I can think to describe it. Upon landing the legs will not stabilise and shimmy all over the place.

So is there a way I can get larger radial legs? They seemed to be much more solid. 

Also the travel is a bit much. I got too much clearance between the engines and ground. If they didn't fold out as far they'd be wider and provide more stability. That's not much of an issue though compared to the dancing legs.

[NecroBones]

19 minutes ago, Motokid600 said:

Do you have any landing kegs other then the radial 3.75m ones and the stacked 5m ones? The smaller radial attatch legs worked really good, but there too small for my 5m rocket. I'm having issues with the stackable 5m ones on the fixed ring. They... Dance lol.  Best way I can think to describe it. Upon landing the legs will not stabilise and shimmy all over the place.

So is there a way I can get larger radial legs? They seemed to be much more solid. 

Also the travel is a bit much. I got too much clearance between the engines and ground. If they didn't fold out as far they'd be wider and provide more stability. That's not much of an issue though compared to the dancing legs.

The only other gigantic legs I have are in the Lithobrake Exploration pack. I'll probably rework the SpaceY legs at some point, but for some time now I've been avoiding legs just because the way landing gear of all kinds works will be completely redesigned in KSP 1.1. I don't know yet what's involved with that or how hard they will be to convert, so for now they're just continuing as-is. The travel and deployment height was sort of an artifact of trying to get them to work well with all of the SpaceY engines, but the wobbly aspect of all of them (including the stackable one) never really sat well with me. The only thing I was able to do was set a really high breaking strength so that they could wobble without tearing the ship apart, but we don't have much control over joint stiffness other than to just crank up the mass of the parts.

 

 

[Motokid600]

I see. Thanks for the quick response. The legs in the lithobrake pack are nice, but they're profile is too large. Perhaps I'll look into a tweakscale config for the smaller radial legs. 

For the future post 1.1 maybe it'd be possible to edit the leg travel like you can with cargo bays?

[PickledTripod]

Smaller legs indeed would be cool. They could also be angled higher when deployed, like Motokid6000 said there's too much ground clearance even on 3.75m launchers, and on 2.5m ones it seriously affects the CoM, the rocket tips over very easily.

If you plan to completely remodel them you should try to make them more aerodynamic like the actual Falcon 9 legs, that huge hinge looks pretty weird.

[NecroBones]

A deploy limit would be cool, but I don't think that works in conjunction with the suspension system (shock absorber). Completely rigid legs are still possible of course, but at this size scale all of these things don't behave as nicely as the smaller parts, in terms of the physics. It's all going to be a balancing act, so to speak.

 

[vans0051]

@NecroBones, I've been happily using your lifer pack for a while now, but I've always had z-fighting problems.  I only have your pack and MechJeb installed.  I didn't see anywhere that ModuleManager was required, and I'd like to keep my mods to a minimum so I haven't installed it.  I just deleted the whole SpaceY folder and replaced it with the latest version and the problem remains.  None of the other issues presented apply to me.  What else could be going wrong?

Edited January 28, 2016 by vans0051

[NecroBones]

46 minutes ago, vans0051 said:

@NecroBones, I've been happily using your lifer pack for a while now, but I've always had z-fighting problems.  I only have your pack and MechJeb installed.  I didn't see anywhere that ModuleManager was required, and I'd like to keep my mods to a minimum so I haven't installed it.  I just deleted the whole SpaceY folder and replaced it with the latest version and the problem remains.  None of the other issues presented apply to me.  What else could be going wrong?

Yep, that's the problem right there. ModuleManager is considered a requirement. It has rules for how to handle both cases of enabling, or disabling the color-switching on the tanks. If MM is not installed, you'll see all of the color options at once.

 

[vans0051]

8 hours ago, NecroBones said:

Yep, that's the problem right there. ModuleManager is considered a requirement. It has rules for how to handle both cases of enabling, or disabling the color-switching on the tanks. If MM is not installed, you'll see all of the color options at once.

 

I ended up putting it in there last night after I posted and the tanks are all prettied up now.  Thanks for your reply, and thanks for creating!

[NecroBones]

5 hours ago, vans0051 said:

I ended up putting it in there last night after I posted and the tanks are all prettied up now.  Thanks for your reply, and thanks for creating!

Awesome. I also added a note in the OP about it being required. Originally it wasn't, but as time went on, everything became more dependent on it, so it became more of a requirement. Thanks!

[jmbailey2000]

Necro,

Quick question......for some reason I have a bunch of ships that that won't load because they require SYengine5mF5 part. Yet, I cannot find that part in your pack anymore. I know this part existed when I transitioned to 1.02 because I loaded every ship and re-saved it in 1.02 to make sure they would work. I just don't know when/where the part went and was wondering if you maybe point me to where I can find this part?

Greatly appreciated!