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

[chrisl]

2 minutes ago, Shadowmage said:

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).

Looking at the code you linked we have the following line:

SSTUModInterop.onPartFuelVolumeUpdate(part, calcTotalVolume() * 1000f);

If I then look at the calcTotalVolume() function, the line right before the return reads:

val += baseVolume;

Does "baseVolume" in this function not refer to the baseVolume parameter supplied by SSTUModelSwitch?

Looking at calcTotalVolume() it really seems like we are grabbing the volume value from active SSTU_MODEL (0.9 in the case of the Ascent Tank version of LC2), then adding in the baseVolume from SSTUModelSwitch (250 in the case of LC2), then multiplying the result by 1000. 

Unfortunately, I obviously don't understand the code well enough so even if there is a problem, I don't have the skill to fix it.

[Shadowmage]

7 minutes ago, chrisl said:

Looking at the code you linked we have the following line:

SSTUModInterop.onPartFuelVolumeUpdate(part, calcTotalVolume() * 1000f);

If I then look at the calcTotalVolume() function, the line right before the return reads:

val += baseVolume;

Does "baseVolume" in this function not refer to the baseVolume parameter supplied by SSTUModelSwitch?

Looking at calcTotalVolume() it really seems like we are grabbing the volume value from active SSTU_MODEL (0.9 in the case of the Ascent Tank version of LC2), then adding in the baseVolume from SSTUModelSwitch (250 in the case of LC2), then multiplying the result by 1000. 

Unfortunately, I obviously don't understand the code well enough so even if there is a problem, I don't have the skill to fix it.

Hmm... you may have just found a bug regarding the RF integration for the SSTUModelSwitch module; looking closer at the code, calcTotalVolume() already returns liters, so the *1000 after that is actually multiplying it a second time (which it should not be).

Have fixed up the code side of things, and will (try to) do some testing tomorrow morning; the fix should be available with tomorrows update.

Looking closer at the values you posted a few posts back, that does indeed seem to be the case.  The 'standard' variant should have a raw volume (as seen in the RF/MFT module) of 250l, and the ASCF variant should have a raw volume of 1150l.  Apparently RF-MFT is cutting off some of that volume for tankage loss (no clue how to fix that... one of the reasons I don't use RF-MFT); so your final volumes should be ~200l and ~920l respectively.  So, based on your previously posted values, yes there was an extra multiplier in the code that was causing improbably large volumes.

 

Check back on it tomorrow after the release/update, and it should be fixed.

 

 

[GoldForest]

@Shadowmage Here's a few pics of the problem that I'm having with Contares.

 

[Shadowmage]

1 hour ago, GoldForest said:

@Shadowmage Here's a few pics of the problem that I'm having with Contares.

 

Do you have any logs?  The pictures merely confirm that you have a problem, which I gathered from your original post.  Without logs, all I can do is guess at what it is.

[GoldForest]

36 minutes ago, Shadowmage said:

Do you have any logs?  The pictures merely confirm that you have a problem, which I gathered from your original post.  Without logs, all I can do is guess at what it is.

Sorry. Here it is.

https://www.dropbox.com/s/k9u2nesad4ixdke/KSP.zip?dl=0

[drswagboss]

Love this man, the detail on the engines is supreme, btw you can have this.

[Sudragon]

Does anyone have any idea what takes the cluster small LV-N and the cluster large LV-N and parks them higher up the tech tree in a custom node? 

[Jimbodiah]

Kerbals man, can't trust them with that tech so soon.

They are SSTU engines, so SSTU defines the techlevel for them.

[Sudragon]

Ahem:

From The Book of Configs, Chapter SC-ENG-NRV3

 

name = SSTU-SC-ENG-NRV3
author = Shadowmage

TechRequired = nuclearPropulsion
entryCost = 20000
cost = 5000
category = Engine
subcategory = 0
title = SSTU - SC-ENG-NRV-S
manufacturer = SSTU
description = After converting the intial NRV engines into clusterable models, the engineers at SSTU were tasked with making some probe-sized nuclear motors.  All the radioactivity, 1/4 the thrust!

In my Tech tree they're parked up on the 1000 point tier for  some reason, I'm just see if anyone knows which mod might be doing that.

Edited June 11, 2016 by Sudragon

[Shadowmage]

4 hours ago, Sudragon said:

Does anyone have any idea what takes the cluster small LV-N and the cluster large LV-N and parks them higher up the tech tree in a custom node? 

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Patches/TechTree.cfg#L76-L83

Was intentional; NRV engines are very OP, even more so when you can cluster them.  I also did it for the 'harder to engineer micro and giant things' factor.

[Sudragon]

Just now, Shadowmage said:

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Patches/TechTree.cfg#L76-L83

Was intentional; NRV engines are very OP, even more so when you can cluster them.  I also did it for the 'harder to engineer micro and giant things' factor.

Ah. I was just experimenting, trying to find a replacement for the depreciated lander engines. 

[Shadowmage]

8 hours ago, GoldForest said:

Sorry. Here it is.

https://www.dropbox.com/s/k9u2nesad4ixdke/KSP.zip?dl=0

Taking a look now.  I'm not spotting any null-ref errors in that log file, which is odd; those are usually the cause of such problems.  Was this a log file from when those problems were occuring?

I also downloaded and installed the Contares mod, and I did not encounter any problems with it being installed (no messed up effects, etc).

That is both the SC-C-SM, RCS working fine, and an RS-68, with the effects properly not displaying for the inactive engine.

So honestly, I have no idea what the problem is, as I cannot duplicate it on my end even after installing the mod that you said was conflicting.

I would try it again after today's update/release, and if it is still happening, please let me know.  Going to need more information in order to figure it out though, as if I cannot duplicate it, there is zero chance of fixing it.

7 minutes ago, Sudragon said:

Ah. I was just experimenting, trying to find a replacement for the depreciated lander engines. 

Understood;  I haven't even been able to find a replacement for those engines in real world analogues.  It appears that they were just too powerful for how small the were.  I've a few other options that I haven't fully investigated yet, but they would mostly be end-game tech oriented (Space-X SuperDraco engines might be a decent fit, but are about as 'high tech' as it gets).

[Jimbodiah]

I'm running Contares as well for the ATV, but havent seen any issues. Are you running RealPlumes?

[Shadowmage]

10 hours ago, drswagboss said:

Love this man, the detail on the engines is supreme, btw you can have this.

Very nice

Mind if I 'borrow' that for the front-page header image?  And if so, who should I give credit to (you, or other)?

[Shadowmage]

Updated release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.4.31.116

Fixes up a few bugs and balance problems, adds prototype cargo bay parts.  Not too much else, but check out the link for the full change log and downloads.

 

Yah... not quite there... but close   Sadly I didn't have time to add the gold-foil textures that JoseEduardo made up, nor do I have any inflatables/hab modules yet.

[Jimbodiah]

whaaaaaaah, cool!

But that picture is screaming for gold foil and some station parts

[drswagboss]

2 hours ago, Shadowmage said:

Very nice

Mind if I 'borrow' that for the front-page header image?  And if so, who should I give credit to (you, or other)?

Go ahead, and yeah, this is mine.

[ComatoseJedi]

1 hour ago, Shadowmage said:

nor do I have any inflatables/hab modules yet.

Porkjet's inflatable habs still work, no rush on that. 

[Qwarkk]

1 hour ago, Shadowmage said:

Updated release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.4.31.116

Fixes up a few bugs and balance problems, adds prototype cargo bay parts.  Not too much else, but check out the link for the full change log and downloads.

Just to let you know for the next release, a newer version of module manager (2.6.25) is available to include.

Also, loving the progress on the cargo bays

[Jimbodiah]

brb

Edited June 11, 2016 by Jimbodiah

[JoseEduardo]

1 hour ago, ComatoseJedi said:

Porkjet's inflatable habs still work, no rush on that. 

they do? gotta check that out...

wasn't he working on a v2 of his project and people were asking him to make it stock?

[StickyScissors]

Has anybody had the chance to test a Falcon 9-like, single engine landing with the merlins? Seeing as how the thrust, weight etc. are intentionally fudged with this mod to bring them more in line with stock, i'd be a bit disappointed if i can't land my stages anymore, or would have to completely redesign launchers to do so.

I'd investigate myself, but downloading 1.1.2 and this mod through my slow internet is like watching a snail crawl uphill through thick tar :/

[GoldForest]

9 hours ago, Shadowmage said:

-snip-

Strange. I will update and try it. I'll even try updating contares.

When I have the mod running I get null ref errors in the debug menu...

[Jimbodiah]

I just had the same thing tonight, litterally hundreds of thousands of nullrefs. Only a clean install of KSP solved it, don't know what it is, maybe a silent patch?

[GoldForest]

1 minute ago, Jimbodiah said:

I just had the same thing tonight, litterally hundreds of thousands of nullrefs. Only a clean install of KSP solved it, don't know what it is, maybe a silent patch?

So I'm not the only one having problem with contares?