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

[T-10a]

A trick I've found is to use 2 engine clusters (a ring of 8 on the outside, and singular on the inside), with the inner engine attached to the interstage node of the outer engine, so for the cost of one extra part you get the flexibility of 2 different modes (9 engine FT mode and 1 engine landing mode)

Goes to show how even something like the interstage nodes can be flexible (interstages, toggleable engines, even Atlas/Saturn 1-D style stage-and-a-half systems)

Edited February 21, 2018 by T-10a

[drhay53]

Does anyone have a custom MM patch that adds Hydrolox and Hypergolic to ISRU converters? I can manage to modify individual parts, I'm sure, but I'm not quite good enough to just modify every converter. 

I don't really care about balance, I just want to be able to do it; usually I just copy electric charge and resource rates for LFO -> Hydrolox, and MonoProp -> Hypergolic. 

[RedParadize]

1 hour ago, Starwaster said:

I'm using the Kerbal Reusability mod which has some decent looking Falcon legs. Of course, I seldom actually LAND the stages myself, electing instead to let Stage Recovery deal with it, making the legs are superfluous, though sometimes I do manage to intercept it before it's destroyed and try to land it myself.

Though there's an unfortunate problem in that Stage Recovery can't really deal with SSTU's cluster engines and treats them as having the thrust of a single engine since it operates at a time when the part and its part module don't exist. I've actually tried hacking SR's code to deal with the problem but snapshot parts and partmodules are apparently highly resistant to reflection. Very frustrating and a solution may not be possible  

I use FMRS. But for stuff like a Falcon Heavy it quickly become laborious and boring. So I use Kerbal Space Transport System, it record the launch and after that you can use recorded profile to instantly spawn something of equal weight in orbit. The thing is it doesn't support FMRS. So I use KSTS in a... unintended way:

What I do is I test the recovery of every reusable stage separately (or using FMRS). I then  calculate the value of recovered part manually. Then I start KSTS and do the full launch and save the game. I then edit my savegame and change the cost value (look for KSTSScenarioModule). 

Its might sound like a long process but its not. Its fun

Edited February 22, 2018 by RedParadize

[RedParadize]

@Shadowmage Is there any way to change SSTU_CONTAINERTYPE using a MM patch? Also, if I want to reduce tank dry mass fraction without changing its usable volume, do I need to change massModifier alone or do I need to also change tankageModifier?

[Jimbodiah]

19 hours ago, Starwaster said:

Though there's an unfortunate problem in that Stage Recovery can't really deal with SSTU's cluster engines and treats them as having the thrust of a single engine since it operates at a time when the part and its part module don't exist. I've actually tried hacking SR's code to deal with the problem but snapshot parts and partmodules are apparently highly resistant to reflection. Very frustrating and a solution may not be possible  

I use SR and have changed the parameters in the cfg as I tend to play rss. No issues with boosters being recoverd, even ones that almost circularized (ie 500x20 orbit). I raised the terminal velocities to around 30 and the reentry one to 7000m/s (originally 2200 iirc). I also cloned the radial drogue chute part to contain a probe core and a large parachute, this way SR picks it up and the chutes module makes sure the stage is recoverable.

18 hours ago, drhay53 said:

Does anyone have a custom MM patch that adds Hydrolox and Hypergolic to ISRU converters? I can manage to modify individual parts, I'm sure, but I'm not quite good enough to just modify every converter. 

I could check if there isn't a patch already, or otherwise add it to SSTU if Mage approves. I think they used to be added in older versions, but I don't really use the stock one myself. Let me know...

Edited February 22, 2018 by Jimbodiah

[drhay53]

45 minutes ago, Jimbodiah said:

I could check if there isn't a patch already, or otherwise add it to SSTU if Mage approves. I think they used to be added in older versions, but I don't really use the stock one myself. Let me know...

I have a couple of mods that add ISRU equivalent parts, but I think they use stock ISRU modules. So I guess I need something that finds everything with the stock ISRU module on it, clones the LFO converter and changes it to Hydrolox, and clones the MonoProp converter and changes to Hypergolic. 

[Starwaster]

40 minutes ago, Jimbodiah said:

I use SR and have changed the parameters in the cfg as I tend to play rss. No issues with boosters being recoverd, even ones that almost circularized (ie 500x20 orbit). I raised the terminal velocities to around 30 and the reentry one to 7000m/s (originally 2200 iirc). I also cloned the radial drogue chute part to contain a probe core and a large parachute, this way SR picks it up and the chutes module makes sure the stage is recoverable.

If that's what floats your boat then have at it, but setting the reentry velocity limit so high is too unrealistic for my tastes  

I'll design my way around the problem and/or hack in the necessary functionality so that things work in a reasonable manner

Not quite understanding why you'd have to put probe control on the chute part though, I routinely put chutes on boosters and as long as they're coming in at a low enough velocity they recover just fine? 

 

[Jimbodiah]

Red, you can just add them instead of replacing them.

Edited February 22, 2018 by Jimbodiah

[Shadowmage]

18 hours ago, RedParadize said:

@Shadowmage Is there any way to change SSTU_CONTAINERTYPE using a MM patch? Also, if I want to reduce tank dry mass fraction without changing its usable volume, do I need to change massModifier alone or do I need to also change tankageModifier?

Yes.  They are defined through config files/nodes, so are a valid target for MM patching.  You can also add entirely new types, as long as you then add them to the specific parts (e.g. modifier=XXXX in the CONTAINER block...)

Dry tank mass fraction -- this is a decimal percentage of the mass of the resource that the container is configured to hold.  It is specified in the following line of the VolumeContainer configs:

MODULE
{
	//standard module setup
	name = SSTUVolumeContainer
	volume = 100000
	enableContainerEdit = true
	enableFuelTypeChange = true
	baseContainerIndex = 0
	//sub-container setup
	CONTAINER
	{
		name = Main Tank
		percent = 100
		tankageVolume = 0.15
		// this is the line you want to adjust - larger values = more dry mass
		tankageMass = 0.15
		// ^^^
		defaultModifier = standard
		defaultFuelPreset = LFO
		//...other stuff
	}
}

You can simply change the 'tankageMass = XXXX' field, and it will -only- adjust the dry mass.  Volume is adjusted separately (through the 'tankageVolume = XXXX' field).

[RedParadize]

@Shadowmage 

Thanks, pretty much always played with 6.4x scale. So far your default tanks weight were fine but I can't do anything like the two stage Falcon. I will probably teak mass fraction mid way from what you have and real life.

[Shadowmage]

Quick question regarding fuel tank model setups -- which would be the preferred method for fuel tank model composition?

1.) Lower, Intertank, and Upper sections all configurable independently.  Select the intertank you want to use, then select the length of the upper and lower tank segments -- basically a 'build your own ratio' type setup.  Potentially requires a few more button clicks to get to the desired tank configuration, but might offer more overall options/combinations.  Also uses more of the 'module' slots for fuel tank models, leaving only the basic 'nose/mount' slots for adapter options.
2.) Single 'tank' model with pre-built ratios (defined in config files).  Select your tank variant (hydro, cryo, kero, etc..) to specify the ratio, then select the tank length.  This is basically how the tanks are setup in current releases (but here will likely be a few more ratio options due to how easy they will be to create).  Potentially requires fewer clicks to select your tank setup.  Also leaves two more 'module' slots for extra adapter/etc model options.

For awhile I was leaning towards #1 for the greater level of configurability.  But even I am not sure I want to do a bunch of extra configuration when I just want 'a fuel tank'.  The setups are not mutually exclusive either -- it is simply a method for how the configs would be structured and how the UI would be used, and both methods could actually be used in a single part (though I will likely stick to one or the other for consistency).  Perhaps going with the simpler setup (#2) in the beginning, but offer an optional 'advanced' mode patch sometime down the road?

 

Anyhow, wrapping up the new fuel tank modeling bits now -- working on the AO bakes, and will likely be running the new models through PartTools over the weekend and creating the initial texture sheets.  Might actually be able to get them in-game and start doing some real testing on the new plugin code over the weekend.

One other thing that I'm going to be investigating, is any 'official' support needed for KS3P - the KSP Post Processing project.  I haven't gotten a chance to try it out yet, but from the screenshots that I've seen -- absolutely beautiful.  Combine all of the fun post-processing with good support for PBR shaders, and it really does look like an entirely new game.  I don't think there is much that I'll need to work out, or really any incompatibilities to fix, but I do want to take some time to see if I can enable HDR rendering for a more realistic bloom effect when post-processing is enabled (the current bloom effects look to be some form of exponential ramp applied to standard-range lighting values to 'fake' the bloom producing sources)

If you haven't already seen it -- check out some of the in-game screenshots from the thread.  Simply stunning (can't wait to see what they look like with all of the TU fancy shaders...).

 

[Jimbodiah]

Meh, it seems to add a dirty cheap lens effect, only blurring the image and overexposing the highlights. I've not seen anything I would want to be honest, and I also noticed they have several issues like every other graphics "improvement" mod out there at the moment. Getting scatterer flashbacks already; improve one thing, break 15 others while dropping frame rate 50% in the process. 

 

Re tanks: I think there will be people wanting option 1, but personally I would go for #2.  Maybe MFT-A and MFT-B?

[tater]

@ seems OK. Will the type variants change the relative size on the tanks on things like MUS? (ie: ker vs OX ratio, H2 vs O2, etc).

[Shadowmage]

1 minute ago, tater said:

@ seems OK. Will the type variants change the relative size on the tanks on things like MUS? (ie: ker vs OX ratio, H2 vs O2, etc).

MUS functionality is not intended to change much from the current setup.  Unlike the regular fuel tanks, it probably will use the #1 setup from above (so the user can manually create whatever ratio setup they want) (the variant option will likely switch between split and common-bulkhead tank types).  Mostly because I really don't feel like doing the math to figure out the ratios   (last time I had to go all the way down that rabbit hole, ended up calculating things in silly metrics, like mols/cubic meter or other weird stuff; don't really remember, other than it was no fun and far too much research for a visual-only thing)

[drhay53]

My vote on the tanks is for #2), but I do like that the MUS come as #1), because it's nice to have a small amount of monoprop in there for time where I'm forgetful

[DocRockwell]

I'm trying to rescale some of the habitat/station core parts for my game, but not having much luck. I've tried making a MM patch to change the rescaleFactor, but that doesn't seem to do anything. Do I need to change something with the modeldata scales or dimensions instead?

[tater]

cfg rescalling works (directly, or via MM patch)

[Shadowmage]

13 hours ago, DocRockwell said:

I'm trying to rescale some of the habitat/station core parts for my game, but not having much luck. I've tried making a MM patch to change the rescaleFactor, but that doesn't seem to do anything. Do I need to change something with the modeldata scales or dimensions instead?

Which part(s)?

SSTU parts use custom plugins for... well, everything.  So quite a few stock methods for stuff like rescaling doesn't work the same.

It can be done, but it is likely going to be a bit complex.  Your best bet might be to look at the RO patches to see how they do it, learn what they have adjusted, and then fine-tune it for your own scaling setup.

(Just as I don't support RO, I don't really support rescaling either -- the option exists, but you are on your own to figure it out and deal with any problems you have)

 

10 hours ago, tater said:

cfg rescalling works (directly, or via MM patch)

Yes, and no.  Yes, you can rescale the parts through patch, but not using the stock 'rescaleFactor'.

[DocRockwell]

5 hours ago, Shadowmage said:

Which part(s)?

SSTU parts use custom plugins for... well, everything.  So quite a few stock methods for stuff like rescaling doesn't work the same.

It can be done, but it is likely going to be a bit complex.  Your best bet might be to look at the RO patches to see how they do it, learn what they have adjusted, and then fine-tune it for your own scaling setup.

(Just as I don't support RO, I don't really support rescaling either -- the option exists, but you are on your own to figure it out and deal with any problems you have)

 

Yes, and no.  Yes, you can rescale the parts through patch, but not using the stock 'rescaleFactor'.

I'm looking to rescale SSTU-ST-HAB-C1, but if the RCS jets and solar panels need to be manually repositioned, I'd just go for SSTU-ST-HAB-C3 which lacks those features. I've checked the RO patches, but these parts were never patched. I've gotten the end caps resized by changing the SSTU_Model height and diameter, but can't figure out how to rescale the inflatable portion.

 

[Shadowmage]

1 hour ago, DocRockwell said:

I'm looking to rescale SSTU-ST-HAB-C1, but if the RCS jets and solar panels need to be manually repositioned, I'd just go for SSTU-ST-HAB-C3 which lacks those features. I've checked the RO patches, but these parts were never patched. I've gotten the end caps resized by changing the SSTU_Model height and diameter, but can't figure out how to rescale the inflatable portion.

 

 

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/StationCore/ST-HAB/ST-HAB-C3.cfg#L53-L55

Change those lines in the config to your new desired size.  The rest of the system should auto-scale things to match the specified diameter (main models, adapters, etc).  Yes, if you wanted RCS/Solar, those need to be manually positioned and scaled in the config file.

Note that will only change the visual size -- you'll still have more adjustments to do in order to get the mass and volume to line up with the new size.  (These lines in the config adjust mass/volume/etc, and are not multiplied for scaling IIRC -- https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/StationCore/ST-HAB/ST-HAB-C3.cfg#L67-L73 )

[RedParadize]

18 hours ago, Shadowmage said:

Change those lines in the config to your new desired size.  The rest of the system should auto-scale things to match the specified diameter (main models, adapters, etc).  Yes, if you wanted RCS/Solar, those need to be manually positioned and scaled in the config file.

I did that before and its easy. You just have to multiply the position value by your rescale and they will line up with the rest.

(It probably sound obvious, and if you often work with 3d stuff like me it is. I sometimes find it funny when someone do not know what I consider to be basic, but for non initiated it is not)

[Shadowmage]

General development update:

Managed to spend a bit of time over the weekend working on the new fuel tank models + configs.  New models have been UV'd, run through part-tools, and are now loading in-game.  Configs are going to take a bit longer to finish, as I'm still figuring out precisely how to 'construct' the fuel tanks with the new segmented models while avoiding texture seams in the 'seamless' textures (gold/foam).  Also noted some oddities with the new plugin code that I'll need to investigate and cleanup, but I have some fair ideas on where the problems exist and how to solve them (UI interaction / validation stuff), so should just be a matter of time to get it cleaned up.  If all goes well, I should likely have the first in-game screenshots of the new system+models+textures sometime this weekend.

And then I got the news... that I'm getting a promotion at work.  So the rest of this week and likely the next few will unfortunately be very busy -- moving to a new office, getting computer(s) setup, and most of the other fun that would come with starting a new job.  Thankfully I think that after the craziness during the transitional period that I should end up with more a bit more freedom in daily scheduling and likely more free time in general.  The generality of it is that I'm moving from a full-time production position with part-time development work, into a full-time software development position.  Less time spent cleaning up other peoples messes/mistakes every day, and more time spent coding/developing -- should likely be a much less stressful work day on average (which will mean more brain-power that I can devote to modding after work).

What this means for upcoming releases is that they might be delayed longer than I would desire.  Depending on time constraints in the next few weeks, I may end up needing an extra week or three to get SSTU usable once KSP 1.4 drops.  Not really the way I had wanted things to go... but it is what it is.

[T-10a]

No worries Shadowmage. Most mods will also take their time to update to 1.4, and many others will be waiting as well as their 1.3.1 games finish.

[Temeter]

Just went back to KSP once again, and those new systems sound interesting

Also, KSP 1.4? Does that mean the historic expansion and mission editor thing is finally geetting? Neat, I don't mind a bit more stock-dabbling.

 

Also gratz on the promotion!

[Jimbodiah]

That is awesome news, Mage. Congratulations on the promotion!!!!!