[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

[Adrianstu98]

8 minutes ago, Shadowmage said:

Going to need logs to figure out what is going on:

95% chance that it is caused by another mod (my plugin doesn't do anything regarding altitude except for parachute enabled parts).

Ok, i will reinstall the ksp, thanks.

 

[Adrianstu98]

15 minutes ago, Adrianstu98 said:

Ok, i will reinstall the ksp, thanks.

 

You were right, thanks!!!

[Sudragon]

At the risk of being told to read the forums, what are the size expansion trigger points for the various decouplers and payload fairings...interstage petal adaptor included. (I've triggered stage 3 fuel tanks (3.75m) but I'm not sure where to aim the tech tree to be able to glue them together.

[Shadowmage]

2 minutes ago, Sudragon said:

At the risk of being told to read the forums, what are the size expansion trigger points for the various decouplers and payload fairings...interstage petal adaptor included. (I've triggered stage 3 fuel tanks (3.75m) but I'm not sure where to aim the tech tree to be able to glue them together.

From GameData/SSTU/Data/TechLimits.cfg

TECHLIMITSET
{
	name = Default	
	TECHLIMIT
	{
		name = start
		diameter = 1.25
	}
	TECHLIMIT
	{
		name = generalRocketry
		diameter = 1.875
	}
	TECHLIMIT
	{
		name = generalConstruction
		diameter = 1.875
	}
	TECHLIMIT
	{
		name = flightControl
		diameter = 1.875
	}
	TECHLIMIT
	{
		name = fuelSystems
		diameter = 2.5
	}
	TECHLIMIT
	{
		name = propulsionSystems
		diameter = 2.5
	}	
	TECHLIMIT
	{
		name = heavyRocketry
		diameter = 2.5
	}
	TECHLIMIT
	{
		name = largeVolumeContainment
		diameter = 3.75
	}
	TECHLIMIT
	{
		name = veryHeavyRocketry
		diameter = 10
	}
}

 

It only requires a single one of those techs to unlock that size; so for some sizes there are multiple techs that will unlock it (as can be seen for 1.875m and 2.5m).  I'll be adding a few more for 3.75m eventually, and likely put in a few more ways to unlock 5m+tanks as well.

[Sudragon]

Perhaps a 3.125m checkpoint as well?

[Jimbodiah]

Why make it so complicated? 3.125 is not even a regular size.

Same thing with tank lengths, you unlock the longer tanks at higher tech levels but this is completely pointless as you can just stack another tank in top to get the longer version anyway, but you are just complicating builds for no reason.

Edited June 7, 2016 by Jimbodiah

[CobaltWolf]

13 minutes ago, Jimbodiah said:

Why make it so complicated? 3.125 is not even a regular size.

Not with that attitude it won't be.

[Sudragon]

49 minutes ago, CobaltWolf said:

Not with that attitude it won't be.

Like 1.5m hey?

But 3.125m is one of the small arrow click stops on the context menu of most SSTU tanks, staging rings and fairings. If it were added on the 160RP band of the Tech tree, it would make a good intermediate, akin to the 1.875 unlock point. 1.875 not being a regular size, but gets a lot of use from people making Atlas and Titan analogs. 

[Jimbodiah]

1 hour ago, CobaltWolf said:

Not with that attitude it won't be.

LOL 

Mage has 0.625m step increments, so that is a LOOOTTT of techtree nodes 

 

btw I think 1.875 should be an regular size, as the step from 1.25m to 2.5m is huge (100%) in comparisson to all the next steps (50% and diminishing after that).

 

Edited June 8, 2016 by Jimbodiah

[Sudragon]

Re: the conversion/tweakage of the Volcano config. I've inserted the module you gave me, seem to be having success with the clustering. just have to cut the switch-able support ring and change the shrouds for the SSTU model. Any  hints on how to fix this: 

It might be hard to see, but the attach nodes are floating above where they should be. Is this partTopY that needs adjustment?

Edited June 8, 2016 by Sudragon

[JoseEduardo]

from what I see you also need to remove the transforms to remove the shrouds...

I won't post everything, but I'll post some stuff that could help you out, this is (part of) a part file I made for a RO Bobcat's RD-0120 converted to SSTU, sometimes my PartTopY is the same as node_stack_top and engineYOffset is usually the negative value for PartTopY/node_stack_top....

I found this to be true on all bobcat's engines and most modded engines, while stock engines seem to behave differently

node_stack_top = 0.0, 2.60529, 0, 0.0, 1.0, 0.0, 2
node_stack_bottom = 0.0, -2.420039, 0, 0.0, -1.0, 0.0, 2
.
bla
bla
bla
.
MODULE
{
	name = SSTUModularEngineCluster
	engineModelName = BobCatind/Sovietengines/RD0120/model
	transformsToRemove = shroud1, shroud2, shroud3, shroud4
	currentEngineLayoutName = Single
	engineSpacing = 2.72
	engineHeight = 5.025329
	engineYOffset = -2.60529
	engineScale = 1
	partTopY = 2.60529
	smokeTransformName = SmokeTransform
	smokeTransformOffset = -1
	diameterIncrement = 0.625
	engineMountDiameter = 1.375
	upperStageMounts = true
	lowerStageMounts = true
}

 

[Shadowmage]

15 hours ago, Sudragon said:

Perhaps a 3.125m checkpoint as well?

I have no problem, in theory, with adding 3.125 (and 4.375?) unlock tiers.  The problem, in reality, is finding the right nodes to use (and finding the time to find said nodes).  This is where PR's help/are useful

 

6 hours ago, Sudragon said:

Re: the conversion/tweakage of the Volcano config. I've inserted the module you gave me, seem to be having success with the clustering. just have to cut the switch-able support ring and change the shrouds for the SSTU model. Any  hints on how to fix this: 

It might be hard to see, but the attach nodes are floating above where they should be. Is this partTopY that needs adjustment?

 

partTopY = determines the height of the top attach node compared to the center-of-mass of the model; it can be set arbitrarily to whatever you want, and only determines where the attach nodes are relative to the COM.  If your attach nodes are not positioned correctly relative to the model, see below.  This can safely be set to zero on all engines, though the center-of-mass may be off a bit (would be towards the top of the engine), which is why I default it to ~0.5m for most engines.

engineYOffset determines where the model is positioned in the model file relative to its origin.  The engine plugin expects model origin (0,0,0) to be at the top-center of the engine.  So, for most engines you need to 'move the model' downward using this value (as the origin is generally at the part center-of-mass, somewhere in the middle of the engine).  For most engines this value will be the negative value of whatever their top-attach-node y-value was set to (e.g. node_stack_top= 0, 1.35, 0, 0, 1, 0, 2 would have a engineYOffset of -1.35 ).

So, your problem with the attach nodes will require setting the engineYOffset properly.

The shrouds -- see Jose's example;  basically you need to fill in the 'transformsToRemove' line properly, and remove the PartModules (generally ModuleJettison) from the part that manage the stock shrouds.  You can find the transform names listed in those modules in the original part.

[NeoFatalis]

Is there a config for engines to work only on stock fuels? (LFO,Monoprop,LF...)

[blowfish]

12 minutes ago, NeoFatalis said:

Is there a config for engines to work only on stock fuels? (LFO,Monoprop,LF...)

I think Shadowmage tried this at the beginning and the consensus was that the balance was completely unworkable.  There's not a huge difference between hypergolics and LF/O but for LH2 engines the craft size/TWR/delta-v ends up being really, really weird.

[Sudragon]

Welp, got rid of the shroud, fixed the spacing. Now working on removing the support ring. If I get it working, do i need to get Nertea's permission to post it here, there, or somewhere?

 

[JoseEduardo]

you mean the top ring structure that attaches to the tanks? if that isn't a separate transform I'm pretty sure you're out of luck....

[Sudragon]

3 minutes ago, JoseEduardo said:

you mean the top ring structure that attaches to the tanks? if that isn't a separate transform I'm pretty sure you're out of luck....

It's a B9partswitch: 

fragment:

 

MODULE
	{
		name = ModuleB9PartSwitch
		moduleID = meshSwitch
		switcherDescription = Subtype
		
		SUBTYPE
		{
			name = Supported
			transform = RingStructure
			transform = Cyl001
			transform = Cyl002
			transform = Cyl003
			transform = Cyl004
			transform = CylSleeve001
			transform = CylSleeve002
			transform = CylSleeve003
			transform = CylSleeve004
			
		}
		
		SUBTYPE
		{
			name = Unmounted
			transform = Structure
			transform = Cyl005
			transform = Cyl006
			transform = Cyl007
			transform = Cyl008
			transform = CylSleeve005
			transform = CylSleeve006
			transform = CylSleeve007
			transform = CylSleeve008
		}
	}

 

[JoseEduardo]

then just keep adding to the transformsToRemove list and you should be fine

[Shadowmage]

5 minutes ago, Sudragon said:

Welp, got rid of the shroud, fixed the spacing. Now working on removing the support ring. If I get it working, do i need to get Nertea's permission to post it here, there, or somewhere?

 

add these to the 'transformsToRemove' line:   RingStructure,Cyl001,Cyl002,Cyl003,Cyl004,CylSleeve001,CylSleeve002,CylSleeve003,CylSleeve004

(No guarantee on that, I'm winging it based on the part config file; the ideal way to do all these is to import the model into blender so that you have precise dimensions and transform names/hierarchy available)

Permissions -- I don't believe permissions are needed for new config files, only if you are (re)distributing the models or art assets  (otherwise everyone would need Squads permission to distribute configs/patches that modified stock parts).  Others might know better on that though; I don't know that I've seen any official answers anywhere.

[Sudragon]

Just now, Shadowmage said:

add these to the 'transformsToRemove' line:   RingStructure,Cyl001,Cyl002,Cyl003,Cyl004,CylSleeve001,CylSleeve002,CylSleeve003,CylSleeve004

(No guarantee on that, I'm winging it based on the part config file; the ideal way to do all these is to import the model into blender so that you have precise dimensions and transform names/hierarchy available)

Permissions -- I don't believe permissions are needed for new config files, only if you are (re)distributing the models or art assets  (otherwise everyone would need Squads permission to distribute configs/patches that modified stock parts).  Others might know better on that though; I don't know that I've seen any official answers anywhere.

Yup. doing that. Also have PM'd Nertea just to be on the safe side.

 

[Sudragon]

Made adjustments as per last posts. Didn't get to see if it worked as it was still loading  when I had to leave for work. Such frustrated. Much annoying. 

Will post results and file in 8 hours from now

[Bob Jub]

I've made awesome things with this mod pack! I love it!

 

 

Edited June 9, 2016 by Bob Jub

[Sudragon]

Awwwllllright. The Volcano-C. The floor is open to comments.

(There appears to be a spot of overlap onto the fueltank. I think I have this corrected in the release)

https://drive.google.com/open?id=0Bz5i94NngLTTVktUX1otT0pVbVE

Created under CC-BY-NC-SA-4. Credit and thanks to @Nertea, @Shadowmage and @JoseEduardo. 

17 hours ago, Shadowmage said:

I have no problem, in theory, with adding 3.125 (and 4.375?) unlock tiers.  The problem, in reality, is finding the right nodes to use (and finding the time to find said nodes).  This is where PR's help/are useful

 

Perhaps Advanced Fuel Systems.

[Shadowmage]

5 hours ago, Sudragon said:

Awwwllllright. The Volcano-C. The floor is open to comments.

 

https://drive.google.com/open?id=0Bz5i94NngLTTVktUX1otT0pVbVE

Created under CC-BY-NC-SA-4. Credit and thanks to @Nertea, @Shadowmage and @JoseEduardo. 

Perhaps Advanced Fuel Systems.

 

Very nice, welcome to the world of modding   Any plans to work on the other cryo-engines?

I'm mostly asking as I'll likely take a look over Cryo-Engines and a few other mods with decent engine models (e.g. no tank-butts) to see about adding built-in support for them before too long.  Would love to expand on engine options without having to do yet-more-modeling.

 

I also verified that (at least the latest) module manager -does- properly detect and use NEEDS blocks on root-level configs (e.g. using a NEEDS block on a base part definition appears to work properly now); so 'patches' like the one for the cryo-engines can be setup to not bork things when the mod is not present (makes it so that they can be included in the base SSTU install and not require manual installation, etc).  This means I can actually include the NearFuture/Cryo-Tanks based MFT tank and radial tank additions with the next update (after a bit more cleanup).

 

In general news, I managed to get the cargo bay animation handling all setup and working.  Learned quite a bit more about Unity animations in the process, mostly while trying to figure out how to clamp an animation to a specific max range (for deploy-limiters for the different door animations), and the use of the Sample() method.  The nose, body, and tail can all be animated independently; the animations are defined in the model definition and pulled in dynamically depending upon the current part setup; not all models need to have animations, so the system will still work with non-animated parts just fine (with proper UI handling, disabling animation controls if not present).  Sorry, no pics; the models I was working with for testing this stuff were very crude.

Now I just need to get all the various models/textures done   (might take a few weeks for this, as I'm still trying to devote most of my time to wheel stuff).  But the plugin end of things is ready.  Which is now two modules that are ready for use but lacking models;  the 'welding docking port' module has also been done for a few months now but I've been unable to find time to figure out and make the models for it.  Ohwell... perhaps I'll start getting caught up sometime this summer (would be much sooner if I can ever get the wheel stuff figured out).

May or may not have any MCB prototype parts available with this weekends' release; if I do it will likely just be the saddle-truss variant; the other variants have not yet been started on the modeling end (aside from the crude prototypes for testing of animation functionality).  We'll see how much I get done in the next day or two.

[JoseEduardo]

speaking of patches, I could try what you said, cleaning up the modules and re-building them in order to add the SSTU Engine Cluster...

idk, maybe make a few test patches out of what I already have, and also add a RO patch bundled with them to handle the RO+SSTU integration to these new engines...

I made some Bobcat soviet engines and Beale's Taerobee A4 out of that (and for RO), I could try making patches for these engines so SSTU modules are added first, then every additional mod could apply their patch (like RO, RealPlues etc..), then have a :FINAL patch in the same file in order to add specific RO stuff for these engines (to avoid trouble with SSTU RO module engine base patch for example)

could serve as an example for other mods/mod integration if it works