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

[Urelyn Hazelwood]

33 minutes ago, Shadowmage said:

Thanks for the info;

From your log file, there is a mod with improper real-plumes config definitions, not exactly sure which mod as it is not one I'm familliar with.   Whatever mod this is needs to fix their real-plumes patches; it is not anything that I can fix on this end, and is a problem with that mods' patches.  It appears that the mod is 'WarpPlugin', but not exactly sure what mod it is.

[LOG 18:31:29.035] Config(@PART[FNSmallAugmentedArcjet]:FOR[RealPlume]:NEEDS[SmokeScreen]) WarpPlugin/RealPlume/Attila/@PART[FNSmallAugmentedArcjet]:FOR[RealPlume]:NEEDS[SmokeScreen]
[LOG 18:31:29.039] Config(@PART[TweakableMagneticNozzle]:FOR[RealPlume]:NEEDS[SmokeScreen]) WarpPlugin/RealPlume/Magnetic Nozzle/@PART[TweakableMagneticNozzle]:FOR[RealPlume]:NEEDS[SmokeScreen]
[LOG 18:31:29.041] Config(@PART[FNMethaneEngine]:FOR[RealPlume]:NEEDS[SmokeScreen]) WarpPlugin/RealPlume/Methane Rocket/@PART[FNMethaneEngine]:FOR[RealPlume]:NEEDS[SmokeScreen]
[LOG 18:31:29.044] Config(@PART[InterstellarPlasmaThrusterUpgraded]:FOR[RealPlume]:NEEDS[SmokeScreen]) WarpPlugin/RealPlume/Plasma/@PART[InterstellarPlasmaThrusterUpgraded]:FOR[RealPlume]:NEEDS[SmokeScreen]
[LOG 18:31:29.048] Config(@PART[InterstellarPlasmaThrusterUpgraded]:FOR[RealPlume]:NEEDS[SmokeScreen]) WarpPlugin/RealPlume/Quantum Vacuum/@PART[InterstellarPlasmaThrusterUpgraded]:FOR[RealPlume]:NEEDS[SmokeScreen]

That's

So, I deleted all RealPlume references in all mods, just to be safe. I am just not sure how it affected your, and only your engines. Strange.

Also, SSTU is amazing!!!!! I love how sleek and perfect everything looks. It's very professionally made. except for the ugly shade of orange

Thank you for all your help.

[RedParadize]

@Urelyn HazelwoodThat ugly shade of orange have its NASA certification. Personatly I like it.

Edited July 8, 2016 by RedParadize

[EndeavourCmdr]

On 6/30/2016 at 7:42 AM, Shadowmage said:

They were there and working last I checked.  You need to right click the pod and then press the 'Deploy Parachutes' button; they do not work through staging (space-bar) and must be deployed through action group or right-click menu.

 

Having this same issue. Using the "Reentry" command pod, there is no option to "Deploy Parachutes". This is with ModuleManager 2.6.25 and KSP 1.1.3.

[Shadowmage]

32 minutes ago, EndeavourCmdr said:

Having this same issue. Using the "Reentry" command pod, there is no option to "Deploy Parachutes". This is with ModuleManager 2.6.25 and KSP 1.1.3.

I have confirmed that this function is working properly with the current SSTU release.  So, there is either a mod or patch/config conflicting that is removing that option from the pods.

Proof; note the 'Deploy Parachute' button near the top of the right-click context menu:

 

 

So, as was replied to the other user with this problem, and as it is stated in the OP, logs must accompany -all- support requests.

I will need the KSP.log file in order to even begin investigating.  Without that info all I can do is... well, nothing.  There is literally nothing that I can do without at least a log or somehow knowing precisely which single mod is causing the problem.

You can upload your logs to pastebin, dropbox, sky-drive, lots of options.  Please do not include the output_log.txt as that file is mostly useless and filled with garbage.  The KSP.log file is the one you want, it can be found in your main KSP folder (alongside the KSP executables).

 

The -real- solution would be for you to double check on an SSTU+dependencies only installation, verify that the parachute is present and working, and then begin re-adding your mods one at a time testing after adding each mod.  As soon as the parachute option disappears, the last mod you installed is your culprit.

[EndeavourCmdr]

7 hours ago, Shadowmage said:

I have confirmed that this function is working properly with the current SSTU release.  So, there is either a mod or patch/config conflicting that is removing that option from the pods.

Proof; note the 'Deploy Parachute' button near the top of the right-click context menu:

 

 

So, as was replied to the other user with this problem, and as it is stated in the OP, logs must accompany -all- support requests.

I will need the KSP.log file in order to even begin investigating.  Without that info all I can do is... well, nothing.  There is literally nothing that I can do without at least a log or somehow knowing precisely which single mod is causing the problem.

You can upload your logs to pastebin, dropbox, sky-drive, lots of options.  Please do not include the output_log.txt as that file is mostly useless and filled with garbage.  The KSP.log file is the one you want, it can be found in your main KSP folder (alongside the KSP executables).

 

The -real- solution would be for you to double check on an SSTU+dependencies only installation, verify that the parachute is present and working, and then begin re-adding your mods one at a time testing after adding each mod.  As soon as the parachute option disappears, the last mod you installed is your culprit.

Sounds good. Thanks for the great information. I'm not home right now, but I'll check on this a bit later and (if I dont get it fixed on my own) get those logs posted for ya.

[EndeavourCmdr]

Good news. I got it all working. I had originally installed the mod from the CURSE mod link provided in the OP, but this version seems severely outdated (SSTU-0.3.30-pre-6.zip) where the current correct version was obtained from Github (SSTU-0.4.31.113.zip). All is fine now. Thanks.

[Shadowmage]

3 hours ago, EndeavourCmdr said:

Good news. I got it all working. I had originally installed the mod from the CURSE mod link provided in the OP, but this version seems severely outdated (SSTU-0.3.30-pre-6.zip) where the current correct version was obtained from Github (SSTU-0.4.31.113.zip). All is fine now. Thanks.

Ahh, that could explain it.

For some reason (probably the beta status), Curse refuses to display the 1.1 releases on the main page / with the main download links.  I'll see about archiving the 1.05 download which should force the 1.1 downloads into the 'newest release' slot.

[Kerbal01]

Is there a way to get this working with RSS/RO for 1.1.3?

[RedParadize]

23 hours ago, blowfish said:

Note though, that the Super Draco is designed for sea level operation, and on top of that is very under-expanded to allow for deep throttling.  So even without technological advances, you're looking at a lot less nozzle mass.

 

Make me wonder how they would use them in the Red Dragon. I suspect its mostly a PR thing anyway. I wonder how much delta V could be squeezed out of that tiny thing with a longer bell.

[RedParadize]

I have a request/suggestion, and for once I think it might interest many. 

Would it be possible to create a MM config that convert all fuel tanks in the game to your container system? just a trought...

[Theysen]

1 hour ago, DarthVader said:

Is there a way to get this working with RSS/RO for 1.1.3?

Uhm, just download and install RO, there are configs supplied and it works out of the box then. If you have issues and can isolate them to be caused by RO seek for support in the Realism Overhaul thread as Shadowmage does not actively support those configs.

 

- given you're using the latest GitHub version.

Edited July 9, 2016 by Theysen

[Shadowmage]

31 minutes ago, DarthVader said:

Is there a way to get this working with RSS/RO for 1.1.3?

I don't use or support RO, so have no idea personally.  @JoseEduardo or @stratochief66, or other RO users in the thread might have a better idea.  Generally though, I believe RO questions/support requests should be posed in the RO thread.

 

23 minutes ago, RedParadize said:

 

Make me wonder how they would use them in the Red Dragon. I suspect its mostly a PR thing anyway. I wonder how much delta V could be squeezed out of that tiny thing with a longer bell.

I actually did a bit of reading on this today, and it sounds like you only need ~500m/s for a mars propulsive landing, which is not far off from the ~400m/s supposedly available for the crewed d2 capsule.  As the RD won't need all of the crew or life-support stuff, they can likely save a substantial amount of weight there, which would increase the available dV and free up some room.  At that point you could fill up the free area with science packages and/or more fuel/larger tanks.  That is all speculation/rumor though, and I have no idea how reliable any of that information is.  Most sounded plausible, though 500m/s for mars-entry sounds a bit low.

As to the other point, a longer/larger bell on the engine could increase the ISP substantially.  They already have an insane chamber pressure (1000psi), so all they really need to do to increase the ISP is to increase the nozzle exit area ratio (expansion ratio), which most sources I see put to be ~2.5 - 4 range.  Increasing that to something like 50, or 80 would substantially increase the ISP, likely up towards the 280-300 range.  With a really large nozzle, ~250:1, you could probably see 330+ ISP. 

However the tradeoff for that larger nozzle is a substantial increase in mass.  As blowfish stated, it currently has a very tiny nozzle on it, so there is almost no nozzle mass.  The engine also isn't designed for any nozzle cooling, so your options are radiative or ablative nozzle cooling which would limit your max single burn time or max total burn time respectively.

I'm actually toying with the idea of making a more vacuum optimized SuperDraco as a replacement for the old LC engines.  The scaled super-draco is fairly small compared to the old LC engines, so a nozzle length and diameter increase might make for a good variant of the engine.  Going to have to do some number crunching though to figure out if it is a good candidate; ideally I would like to have 330+ ISP for a lander engine, which would require a fairly substantial nozzle size increase and likely resulting in an engine similar in size to the AJ10-190.

 

2 minutes ago, RedParadize said:

I have a request/suggestion, and for once I think it might interest many. 

Would it be possible to create a MM config that convert all fuel tanks in the game to your container system? just a trought...

Yes.  You would need to know the volume for each part, but you might be able to calculate that with MM from the existing resources.  It gets more complicated if you want to add it generically to every fuel-containing part as opposed to manually patching single parts, but should be doable either way.

I generally try and stay away from modifying existing parts / other mods parts though as it can quickly lead to a support nightmare with every other mod that modifies those parts.  So at most if I were to include it, it would be as an optional patch set that would have to be manually installed; not a huge deal as its only one file to copy over, and could reside in a separate directory for persistence sake.

I've actually been working on a set of 'personal' patches, one of which is converting the Near-Future / CryoTanks over to an MFT-enabled single tank setup.  I might be willing to release these as optional patches after I get them all cleaned up and working.  While not exactly what you were looking for it does clean up the parts-list substantially as each line of tank models gets compressed down to a single part in the editor, and adds the editable fuel-containers to them.  I'm also working on patches for the engines in Cryo-Engines to enable clustering on them, USI-containers as an MFT, and will be investigating a method to enable MFT-izing the Near-Future truss segments (for better compatibility with the upcoming station part series)(will also need code side changes to allow for new methods of model handling before this one is done).

[blowfish]

1 hour ago, DarthVader said:

Is there a way to get this working with RSS/RO for 1.1.3?

Is there a reason it wouldn't work?  If you're having a specific issue, I suggest stating the issue (with appropriate information such as logs) - cryptic questions like this aren't going to get you anywhere.  Note however, that SSTU-RO compatibility is managed by RO so you should report it over there.

1 hour ago, RedParadize said:

Make me wonder how they would use them in the Red Dragon. I suspect its mostly a PR thing anyway. I wonder how much delta V could be squeezed out of that tiny thing with a longer bell.

Well the engines will still work in a vacuum (or thin atmosphere), they're just not as efficient as they could be.  Not exactly sure how much delta-v is required to land on mars, or how much delta-v the Dragon V2 even has...

E: Apparently Shadowmage answered this question above.

Edited July 9, 2016 by blowfish

[rasta013]

35 minutes ago, Shadowmage said:

I actually did a bit of reading on this today, and it sounds like you only need ~500m/s for a mars propulsive landing, which is not far off from the ~400m/s supposedly available for the crewed d2 capsule.*snip*

So this got me thinking hard about my rusty math skills which I had to dust off and do some calculations because that sounded awfully low to me.  The math doesn't lie though.  That is roughly true.  It mainly has to do with the typical orbital calculations forgetting the Oberth effect when doing hyperbola velocity calculations.  I found a fantastic blog post that explains this and labels it the most common delta-V calculation error made although I'm in no position to make a call on whether it is or isn't.  Regardless, his math matched mine as well once I finally remembered how to do all this. LOL

Here's the post and it's a very interesting read if you're into the math behind orbital transfers.

[123nick]

56 minutes ago, RedParadize said:

I have a request/suggestion, and for once I think it might interest many. 

Would it be possible to create a MM config that convert all fuel tanks in the game to your container system? just a trought...

i once had a similiar suggestion, i think, too convert all fueltanks too use MFS , modular fuel system, it allows you too choose exactly how much of any fuel or etc, too be in a tank, and with any number of fuels or resource types. im not sure it caught on.

[RedParadize]

On my side, its not realy for stock rocket tank. its for spaceplane part. I always feel feel their balance are a little bit off. And being eable to chose whats inside is much desired.

[RedParadize]

@Shadowmage Sorry to bug you again. I am trying to add a Shielded tank as a container type, 

I added  a "SSTU_CONTAINERTYPE" and added  "modifier = shielded" to "SSTUVolumeContainer" in every part and I still don't see it ingame. Do I need to do anything else?

[Shadowmage]

30 minutes ago, RedParadize said:

@Shadowmage Sorry to bug you again. I am trying to add a Shielded tank as a container type, 

I added  a "SSTU_CONTAINERTYPE" and added  "modifier = shielded" to "SSTUVolumeContainer" in every part and I still don't see it ingame. Do I need to do anything else?

The 'modifier = shielded' needs to be added to each CONTAINER sub-node of the SSTUVolumeContainer, e.g.:

MODULE
{
	name = SSTUVolumeContainer
	//default placeholder volume; set by MFT module below
	volume = 100000
	enableContainerEdit = true
	enableFuelTypeChange = true
	baseContainerIndex = 0
	CONTAINER
	{
		name = Main Tank
		percent = 100
		tankageVolume = 0.15
		tankageMass = 0.15
		defaultModifier = standard
		defaultFuelPreset = LFO
		resource = LiquidFuel
		resource = LqdHydrogen
		resource = Oxidizer
		resource = MonoPropellant
		resource = Aerozine50
		resource = NTO
		resource = ElectricCharge
		modifier = standard
		modifier = lbo
		modifier = zbo
		modifier = light
		modifier = structural
		modifier = shielded
	}
}

 

So your patch would then become:

@PART[XXXPartNameXXX]
{
	@MODULE[SSTUVolumeContainer]
	{
		//apply to all containers in the part
		@CONTAINER[*]
		{
			modifier = shielded
		}
	}
}

 

[RedParadize]

Humm, thats what I have, I think.

 

No MM yet, but VolumeContainerData looks like this:

Spoiler

SSTU_CONTAINERTYPE
{
    name = shielded
    title = Shielded Tank
    description = Heat resistant but not so-strong.  Shielding render the tank more susceptible to impact.  May crumple, rupture, and/or explode if subject to too much strain.
    tankageModifier = 1.0
    massModifier = 1.10
    impactModifier = 0.5
    heatModifier = 1.5
    boiloffModifier = 1.1
    activeInsulationPercent = 0
    activeECCost = 1
    activeInsulationPrevention = 1
    inactiveInsulationPrevention = 0
    passiveInsulationPrevention = 0
}

And parts module looks like this:

 

Spoiler

MODULE
{
    name = SSTUVolumeContainer
    volume = 100000
    CONTAINER
    {
        name = Main Tank
        percent = 100
        tankageVolume = 0.15
        tankageMass = 0.15
        defaultModifier = standard
        defaultFuelPreset = LFO
        resource = LiquidFuel
        resource = LqdHydrogen
        resource = Oxidizer
        resource = MonoPropellant
        resource = Aerozine50
        resource = NTO
        resource = ElectricCharge
        modifier = standard
        modifier = lbo
        modifier = zbo
        modifier = light
        modifier = shielded
        modifier = structural
    }
}

 

Anything wrong with this?

[Shadowmage]

1 hour ago, RedParadize said:

Humm, thats what I have, I think.

 

No MM yet, but VolumeContainerData looks like this:

And parts module looks like this:

 

 

Anything wrong with this?

Those look about right;  I'll have to take a look at the code / run some tests when I have some time and see whats going on.

[RedParadize]

@Shadowmage Thanks. I will keep looking on my side. I Replaced the Zero boil off with Heat resistant for now. BTW, these pointy tanks looks realy nice on my SSTU STO Cylon!

[rasta013]

@Shadowmage An update for you but it's mostly info not a solution...

I accidentally corrupted my last save game where I reported that the size limits were not working in career mode.  They weren't and I could never actually figure out why nor saw any errors indicating that something was wrong.  However, with that said, I had to restart my career and I swapped a number of mods around when I did so.  Unfortunately I didn't keep track of what I replaced exactly but whatever I did, the limits are back and working perfectly so far.  I'm barely into the tech tree at all but just got my first SSTU tank opened and it's locked @ 1.25m so it's working again.  I'll keep poking around on my testing install and to try and figure out what conflicted but it appears that another mod was stepping on something somewhere.  Just wanted to let you know in case you're banging your head trying to figure out where the problem was...

[Shadowmage]

11 hours ago, rasta013 said:

@Shadowmage An update for you but it's mostly info not a solution...

I accidentally corrupted my last save game where I reported that the size limits were not working in career mode.  They weren't and I could never actually figure out why nor saw any errors indicating that something was wrong.  However, with that said, I had to restart my career and I swapped a number of mods around when I did so.  Unfortunately I didn't keep track of what I replaced exactly but whatever I did, the limits are back and working perfectly so far.  I'm barely into the tech tree at all but just got my first SSTU tank opened and it's locked @ 1.25m so it's working again.  I'll keep poking around on my testing install and to try and figure out what conflicted but it appears that another mod was stepping on something somewhere.  Just wanted to let you know in case you're banging your head trying to figure out where the problem was...

Interesting.... thanks for the information.

I was able to duplicate the lack of limitations in my career testing games, so it seems like it might be a common problem / mod conflict.

Either way, I have a fix in place that seems to restore the limitation functionality even on my testing setup, so crossing my fingers that it will be a robust solution and fix the problem all around.

 

16 hours ago, RedParadize said:

@Shadowmage Thanks. I will keep looking on my side. I Replaced the Zero boil off with Heat resistant for now. BTW, these pointy tanks looks realy nice on my SSTU STO Cylon!

Looking into it now.  I didn't hard-code the modifiers, so there is likely something incorrect in your patches or configs (though, they looked correct from what you posted).

The following patch produced the screenshot below; you may adapt/alter to suit your needs:
 

SSTU_CONTAINERTYPE
{
	name = standard2
	title = Standard Tank2
	description = Standard lightly insulated container type applicable for most uses.
	tankageModifier = 1
	massModifier = 1
	impactModifier = 1
	heatModifier = 1
	boiloffModifier = 1
	activeInsulationPercent = 0
	activeECCost = 1
	activeInsulationPrevention = 1
	inactiveInsulationPrevention = 0
	passiveInsulationPrevention = 0
}
@PART[SSTU-SC-TANK-MFT-A]
{
	@MODULE[SSTUVolumeContainer]
	{
		@CONTAINER[*]
		{
			modifier = standard2
		}
	}
}

 

[Shadowmage]

22 hours ago, RedParadize said:

I have a request/suggestion, and for once I think it might interest many. 

Would it be possible to create a MM config that convert all fuel tanks in the game to your container system? just a trought...

 

Here is a very rough, very hacky, and mostly untested patch to add SSTUVolumeContainer to all other resource-containing parts.  It has to run in multiple passes because of how ModuleManager references variables and its lack of IF statements... (with an IF statement I could run it all in a single blanket patch).  There is also a notable lack of OR handling in the HAS blocks, so each 'pass' consists of multiple sub-patches (e.g. HAS[#lfVolume[*] | #oVolume[*]] does not seem to work).

//first pass - tally up resource volumes, add the mftVolume variable as a usable test-flag for next pass
@PART[*]:HAS[@RESOURCE[LiquidFuel]]:FOR[SSTU]
{
	%lfVolume = #$RESOURCE[LiquidFuel]/maxAmount$
	@lfVolume *= 5
	%mftVolume = 0
}
@PART[*]:HAS[@RESOURCE[Oxidizer]]:FOR[SSTU]
{
	%oVolume = #$RESOURCE[Oxidizer]/maxAmount$
	@oVolume *= 5
	%mftVolume = 0
}
@PART[*]:HAS[@RESOURCE[MonoPropellant]]:FOR[SSTU]
{
	%mVolume = #$RESOURCE[MonoPropellant]/maxAmount$
	@mVolume *= 5
	%mftVolume = 0
}
@PART[*]:HAS[@RESOURCE[XenonGas]]:FOR[SSTU]
{
	%xVolume = #$RESOURCE[XenonGas]/maxAmount$
	@xVolume *= 0.1
	%mftVolume = 0
}

//second pass - add resource volumes onto the mftVolume variable
@PART[*]:HAS[#lfVolume[*]]:FOR[SSTU]
{
	@mftVolume += #$lfVolume$
}
@PART[*]:HAS[#oVolume[*]]:FOR[SSTU]
{
	@mftVolume += #$oVolume$
}
@PART[*]:HAS[#mVolume[*]]:FOR[SSTU]
{
	@mftVolume += #$mVolume$
}
@PART[*]:HAS[#xVolume[*]]:FOR[SSTU]
{
	@mftVolume += #$xVolume$
}

//third/final pass - set mft volume into description for debug purposes
@PART[*]:HAS[#mftVolume[*]]:FOR[SSTU]
{	
	//remove all existing resources
	!RESOURCE,*{}
	
	//adjust volume to account for tankage
	@mftVolume *= 1.20	
	
	//add volume container with the specified volume	
	MODULE
	{
		name = SSTUVolumeContainer
		volume = #$../mftVolume$
		enableContainerEdit = true
		enableFuelTypeChange = true
		baseContainerIndex = 0
		CONTAINER
		{
			name = Main Tank
			percent = 100
			tankageVolume = 0.15
			tankageMass = 0.15
			defaultModifier = standard
			defaultFuelPreset = LFO
			resource = LiquidFuel
			resource = LqdHydrogen
			resource = Oxidizer
			resource = MonoPropellant
			resource = XenonGas
			resource = Aerozine50
			resource = NTO
			resource = ElectricCharge
			modifier = standard
			modifier = lbo
			modifier = zbo
			modifier = light
			modifier = structural
		}
	}
}

Notably it makes no attempt to distinguish between stock/mod added parts, only checks for stock resources, and it completely ignores any other fuel-switch setups.  This is -not- the route that I will be going with my personal/optional patch setup; merely posting it here because you asked of the possibility.  Yes, it is possible.  No, I will not be including any such patch with the mod.  Hopefully this example provides you with enough information that you can clean it up for your own personal use if you decide to go this route.

For the optional patch setup I will be converting other tanks (stock/modded) into MFT-styled tanks.  It cleans up the part list substantially, and allows for resizing of the tanks and adding nose/mount options for them.  The downside is that it requires substantially more work and must be done on a part-by-part and model-by-model basis; however it will be a much more robust solution in the end and would not 'break' random parts and still allows for some specialization and differentiation on a per-part basis.

[123nick]

hey, just something you might want too change or fix:

  

it says it supports 1.0.5 when it supports 1.1.3