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

[Shadowmage]

39 minutes ago, JoseEduardo said:

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

Would love to be able to make these as simpler patches; e.g. just insert the SSTUModularEngineCluster module at the end and have it all work.

Hmm.... will see what I can do about enabling such functionality on the plugin side; I know a bit more about the loading sequence than I did last time I attempted it, so I might be able to figure/work something out.  If I remember right the biggest problem I ran into was making sure that at least -some- model (with the right transform names) was present when the external modules were initialized (engine, gimbal, animations), as they will not load properly if the transforms they expect are not present.

I honestly haven't tried it since I first started on these parts; it might 'just work' at this point...

Please let me know what you find out / any problems you run into...

[Shadowmage]

Testing out various cargo-bay types and deployment mechanisms:

Will likely end up with 3 variants of animated cargo bays; floor-drop (#1), rotate (#2), and fold (#4).  The basic 'hinged' variant (#3) really doesn't sit well with me; would much rather have the hinge+fold variant.  The floor-drop variant is also kind of undecided; it won't work well with 'round' cargo bays without also creating an animated ramp (which is doable I think), and even flat-bottomed bays (as shown) could benefit from said ramp.  Haven't given any thought yet to the various adapters/nose/tail parts either; the geometry for some of those will be... fun.... to figure out.

Anyhow... still quite a ways out from actually doing anything with these; merely put together some quick example geometry to see how the various animations would look.

[ComatoseJedi]

If you can't get the drop ramp to work, people would just use #2, turn it upside down, use decouplers to release the cargo and let gravity to the work. But, having a drop ramp would be pretty cool, though. And it should be do-able since LLL has a drop floor cargo container for those square shaped ship hulls. I'm not sure about a -round- hull, though, but I don't see why not?

[rasta013]

2 minutes ago, ComatoseJedi said:

If you can't get the drop ramp to work, people would just use #2, turn it upside down, use decouplers to release the cargo and let gravity to the work. But, having a drop ramp would be pretty cool, though. And it should be do-able since LLL has a drop floor cargo container for those square shaped ship hulls. I'm not sure about a -round- hull, though, but I don't see why not?

Nertea pulled off a pretty nice mostly round floor ramp for the MKIV Spaceplane.  Looked and worked very similar to the rear ramp of a C5A Galaxy...

[Sudragon]

8 hours ago, Shadowmage said:

 

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.

Moar cryoengines? If people want. I like the Volcano because it's a right place/right size hydrolox engine, good for 'Mercury' and 'Gemini' programs. 

 

[Jimbodiah]

Something between the RL10A and J2 is always welcome.

BTW, Mage...  would something like the Dream Chaser be an option for SSTU?

[JoseEduardo]

For anyone wanting 10 to 19 engine cluster layouts or a max of 20m tanks and procedural parts in general:

Ah, there's a M-1 in the pack too, it's a cloned and rescaled J-2

this add-on is for stock, not RO (but it also works in RO, I'll make a patch later on to remove the 18 and 14 engine clusters in RO and hide the M-1 engine if RO is present, as RO has a custom M-1)

[EleSigma]

Will there be a replacement for the Mk. 1-2 pod that is based on the Mercury capsule and early (late 1950's-early 1960's) rocketry? Not only would it work for early tech but also offer a cheaper, economic solution for when you want to just put a satellite into low or high Kerbin orbit or do some manned low orbital work.

[Sudragon]

39 minutes ago, EleSigma said:

Will there be a replacement for the Mk. 1-2 pod that is based on the Mercury capsule and early (late 1950's-early 1960's) rocketry? Not only would it work for early tech but also offer a cheaper, economic solution for when you want to just put a satellite into low or high Kerbin orbit or do some manned low orbital work.

MOLE, part of @Angel-125's collection contains the Appaloosa, a multipurpose pod that can connect beneath the Mk-1, making a 1 or 2 kerbal craft. It also has the Gemini-analogue Brumby, also in the 1.875m form factor.

[GoldForest]

@Shadowmage I have a suggestion to make for a part. Resizable probe core. Preferable the Saturn V third stage avionics core as the model.

Also, I have played around and found out that Contares does not like your mod. Any idea why? There are no plugins for Contares, or Tantares, that I know of.

[ComatoseJedi]

@GoldForest Can you be a bit more specific? I've used all these mods in conjunction with one another and haven't seen any misbehaving. As @Shadowmage would say, "I need logs or something other than a vague description". 

 

[GoldForest]

@ComatoseJedi I'll have to wait till I get home to show it, but as stated in a post a page or two back, the Orion RCS fires and won't stop firing, the plumes for the engines show up.

I tracked the problem down to Contares or SSTUL. I only had those two mods installed while trying to confirm the problem. Well, I did have Tantares installed as well, but I tested Tantares with SSTUL alone, no problem. As soon as I load up with SSTUL, Tantares, Tantares LV, and Contares, bam, rcs pushing the craft into an endless turn and the plumes on the RS-68(? The delta heavy engines) were showing full thrust plumes even though they are at zero thrust. They don't produce thrust, but the plumes are still there.

[Jimbodiah]

10 hours ago, JoseEduardo said:

 

Oh, SNAP!!!

[ComatoseJedi]

13 hours ago, JoseEduardo said:

3 hours ago, Jimbodiah said:

 

Oh, SNAP!!!

[Shadowmage]

Heads up, some of you may be interested in this:

 

[ComatoseJedi]

5 minutes ago, Shadowmage said:

Heads up, some of you may be interested in this:

 

Yeah, I seen that mod. Too bad I don't do contracts on my career.

[Jimbodiah]

Euhm, how do you make money then?

[chrisl]

I'm trying to work up a RO config for the Lander Pods.  I know most of the lander stuff has been removed because of compatibility issues but I really like the models and want to make use of them in my advanced landers in my RO career game.  Anyway, my real question comes down to how does SSTUModelSwitch alter the available volume and is there any way to make it work with Real Fuels ModularFuelTanks module?

[Shadowmage]

3 minutes ago, chrisl said:

I'm trying to work up a RO config for the Lander Pods.  I know most of the lander stuff has been removed because of compatibility issues but I really like the models and want to make use of them in my advanced landers in my RO career game.  Anyway, my real question comes down to how does SSTUModelSwitch alter the available volume and is there any way to make it work with Real Fuels ModularFuelTanks module?

A: Very carefully....  ( https://github.com/shadowmage45/SSTULabs/blob/master/Source/Module/SSTUModelSwitch.cs#L242-L261 )

B: Simply remove the SSTUVolumeContainer module from the part, and add in the RF-MFT module, and it should 'just work'.  Basically if the VolumeContainer is present it will use that first and ignore MFT, elsewise it will -attempt- to use MFT if it present; if neither are present the volume updates/resource changes are ignored.

C: No idea how that will work from a mass and cost adjustment standpoint; I do not use use or offer any support for RealFuels/ModularFuelTanks.  If there are any problems you'll have to submit a PR with the solutions as I will not be developing them personally.

[Theysen]

@Shadowmage
 would there be any way to shutdown single engines inside of a cluster? Currently building Saturn's with SSTU in RO and I wondered if I overlooked something or if this is just not possible. Thanks in advance

[Shadowmage]

12 minutes ago, Theysen said:

@Shadowmage
 would there be any way to shutdown single engines inside of a cluster? Currently building Saturn's with SSTU in RO and I wondered if I overlooked something or if this is just not possible. Thanks in advance

Nope; it is all-or-nothing at this point.

I had considered adding an option for it... but it would require a ton of work in order to implement satisfactorily.  It would need a whole new GUI that could display the layout and let you choose which engines to enable/disable, would require new code to manage dynamically altering the thrust transform layout and thrust for the engine, and a few hacks to workaround the assumptions that stock code makes about such things (e.g. I'm unsure if stock will properly support a thrust transform set to zero thrust, or if it will still display effects for it).  Additionally it would cause major headaches trying to make it function with the existing heat-animation code (as it is currently set to animate the heat for all engine models with no way to tell it to ignore just a specific model/models).

So... maybe in the distant future, but certainly not anytime soon.

If you really need to be able to shutoff specific engines, your only option at this time is to build it with multiple individual engine parts using the surface attach functionality and radial symmetry.

[Jimbodiah]

You could have the circular mount and leave an empty node in the center where the use could add his own extra engine?

[JoseEduardo]

1 minute ago, Jimbodiah said:

You could have the circular mount and leave an empty node in the center where the use could add his own extra engine?

this should solve your problem

you can make a 4 engine cluster, add spacing to them, remove the mount, add a interstage node, and add a new engine in the middle

I used that method to try out how I could adapt more engines to make new massive engine clusters

[chrisl]

2 hours ago, Shadowmage said:

A: Very carefully....  ( https://github.com/shadowmage45/SSTULabs/blob/master/Source/Module/SSTUModelSwitch.cs#L242-L261 )

B: Simply remove the SSTUVolumeContainer module from the part, and add in the RF-MFT module, and it should 'just work'.  Basically if the VolumeContainer is present it will use that first and ignore MFT, elsewise it will -attempt- to use MFT if it present; if neither are present the volume updates/resource changes are ignored.

C: No idea how that will work from a mass and cost adjustment standpoint; I do not use use or offer any support for RealFuels/ModularFuelTanks.  If there are any problems you'll have to submit a PR with the solutions as I will not be developing them personally.

Unfortunately, just looking at the link you post, I can't really see how the volume calculation is being made.  I can see that if no SSTUVolumeContainer is found, then we call SSTUModInterop.onPartFuelVolumeUpdate.  It looks like that call is passing the current part as one parameter.  As another parameter, you pass a value that appears to be based on the volume of all models associated with the part (modelData.volume) plus the baseVolume that's supplied by SSTUModelSwitch, all multiplied by 1000.  I'm just not exactly sure where the modelData.volume is coming from (the textures?).  Nor can I see exactly what SSTUModInterop.onPartFuelVolumeUpdate is doing with the information (it's not part of the link you provided from what I can see).  Of course, my coding skills are limited so I might be misinterpreting what I'm seeing.

The in game results are:
I have the LC2 setup with an MFT module with a volume of 1000.  When I use the LC2 with it's default "LC2-ASCF" model active, the available volume is 989000.  If I switch to the "standard" variant I have an available volume of 215000.  That's with the existing baseVolume=250 setting.
If I change to baseVolume=0 then my available volumes become 774000 and 0, respectively.
If I leave baseVolume=0 and set MFT volume=1, my available volumes remain 774000 and 0, respectively.
If I change baseVolume=100 and leave MFT volume = 1, my available volumes become 860000 and 86000 respectively.

In other words, it really seems like the MFT volume is being ignored and some other value (being pulled from a location I don't currently understand) is being used.  I'm looking at the source code but I'm not really proficient in coding so I'm not really sure how the new volume is being generated.

 

EDIT: I think I see where modelData.volume is coming from.  It's from the configs found in  /SSTU/Data/ModelData, right?  So for landers, the "LC2-ASCF" variant has volume=0.9 while the "standard" variant has volume=0.  So if baseVolume=250, then when calcTotalVolume() is called, it should return a result of 250 for the "standard" variant and 250.9 for the "LC2-ASCF" variant.  That returned value is then multiplied by 1000 resulting in either 250900 or 250000.  I'm looking in the source code that's part of SSTU-0.4.31.115 (the version I currently have installed) and was able to find the SSTUModInterop.onPartFuelVolumeUpdate() function.  Unfortunately, I hit my limit of understanding at about this point because I don't fully understand what this function is doing.  It's obviously checking whether we have Real Fuels, MFT or neither installed.  I have Real Fuels so it's then locating the ModuleFuelTanks module but at that point I'm not sure what it's doing.

Edited June 10, 2016 by chrisl

[Shadowmage]

1 hour ago, chrisl said:

EDIT: I think I see where modelData.volume is coming from.  It's from the configs found in  /SSTU/Data/ModelData, right?  So for landers, the "LC2-ASCF" variant has volume=0.9 while the "standard" variant has volume=0.  So if baseVolume=250, then when calcTotalVolume() is called, it should return a result of 250 for the "standard" variant and 250.9 for the "LC2-ASCF" variant.  That returned value is then multiplied by 1000 resulting in either 250900 or 250000.  I'm looking in the source code that's part of SSTU-0.4.31.115 (the version I currently have installed) and was able to find the SSTUModInterop.onPartFuelVolumeUpdate() function.  Unfortunately, I hit my limit of understanding at about this point because I don't fully understand what this function is doing.  It's obviously checking whether we have Real Fuels, MFT or neither installed.  I have Real Fuels so it's then locating the ModuleFuelTanks module but at that point I'm not sure what it's doing.

ModelSwitch calculates volume from that specified in the model-definition config files, and then uses that volume to update whatever fuel-switch module is currently on the part (if any). 
In the SSTUModelSwitch config the 'baseVolume' is in liters, and specifies the volume of the base model, if any.  The *1000 multiplier you see is because the model-definition uses cubic-meters, whereas RF-MFT and SSTUVolumeContainer use liters.

So, the total volume for the current model/variant setup will be baseVolume + ( variantModelDefinitionVolume * 1000 ), in liters.  This value is then passed into the RealFuels-MFT module to set the total available volume (no clue if it is pre-tankage loss, or post-tankage loss; I don't use the mod).  Volume parameters that are specified in the ModuleFuelTanks module are/should be ignored; they are overwritten by the volume value calculated from the models/model-switch module.

So, as far as I know, the extent of what you should have to do is to write your patch to:
1.) Remove SSTUVolumeContainer module
2.) Add the RealFuels ModuleFuelTank module; it really shouldn't need much/any configuration as all the data is passed in at run-time.

E.g. the body of your patch should basically be:

	!MODULE[SSTUResourceBoiloff]{}
	!MODULE[SSTUVolumeContainer]{}
	MODULE
	{
		name = ModuleFuelTanks
		volume = 2000
		type = Default
		typeAvailable = Default
		typeAvailable = Cryogenic
		typeAvailable = ServiceModule
		typeAvailable = Fuselage
		typeAvailable = Balloon
		typeAvailable = BalloonCryo
		typeAvailable = Structural
	}

That's it... if it doesn't work with that... then someone will have to put together a PR to fix whatever code (or wait until I get around to it, which will likely be a few months).