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

[Kerbal01]

1 minute ago, blowfish said:

They're not in master, different branch (which you may not want to use right now because a lot of the stuff in it is highly experimental)

what do I need to do to get just the RD-191/170?

 

[Temeter]

5 minutes ago, DarthVader said:

what do I need to do to get just the RD-191/170?

Probably a lot more complicated than you might think, considering how complex SSTU's engines are set up. All those features need a lot of interconnections.

[Kerbal01]

I guess I'll wait for it to go to the master branch.

[Shadowmage]

45 minutes ago, DarthVader said:

I dont see the RD-191 or RD-170, im using the latest master off the git repo.

Those are only available in the 'dev' versions from Github.  Careful though, the dev versions are just that.... live development versions.  Lots of stuff is broken, lots more in flux, and nearly everything has had some change compared to the current releases.

If you know what you are doing, you can grab just these files from the dev repo and drop them into your game in the proper folders:

https://github.com/shadowmage45/SSTULabs/blob/dev/GameData/SSTU/Assets/SC-ENG-RD-171.mu
https://github.com/shadowmage45/SSTULabs/blob/dev/GameData/SSTU/Assets/SC-ENG-RD-181.mu
https://github.com/shadowmage45/SSTULabs/blob/dev/GameData/SSTU/Parts/ShipCore/Engines/SC-ENG-RD-181.cfg
https://github.com/shadowmage45/SSTULabs/blob/dev/GameData/SSTU/Parts/ShipCore/Engines/SC-ENG-RD-171.cfg

That is all the instructions I will provide.  If that is not enough, then you will have to wait until they are released for real.  Also, I will offer no support for such hacked installs, so if it doesn't work, or has problems... you are on your own.  One final note -- the textures currently in use in the public versions have not been updated for use with the newer models, so especially the -181 might have some texture errors when used with the older textures (not even the dev version has the fully updated textures, those are still in the hidden and private dev models/assets repository)....

[RedParadize]

@blowfishI love the RD-180 and I think I will love the RD-170 even more. As for the 191, it will be the one that work the best with SSTU so I will probably use it allot.

[Gordon Dry]

The slider for boiloff in game difficulty settings defaults to 50% but when touched I can only switch between 0% - 100% ...

Core game issue or mod issue?

[Shadowmage]

6 hours ago, Gordon Dry said:

The slider for boiloff in game difficulty settings defaults to 50% but when touched I can only switch between 0% - 100% ...

Core game issue or mod issue?

Both:

The stock API defaults to... invalid... settings for most of the in-game settings controls.

As such, I need to find a way to work around their stupidity (and implement said workaround).

 

Open a github issue ticket on it, and that will ensure it gets fixed up for the next set of releases.

[NotTheRealRMS]

A modding question: Is it impossible to change the docking port size options for Modular Station Cores?

I made a patch to switch their dimensions to roughly RL ones, and it didn't really work.

@SSTU_MODEL[Dock-Medium]:AFTER[SSTU] //Apollo Sized Port
{
    %diameter = 1.068
    %cost = 2000
}

@SSTU_MODEL[Dock-Small]:AFTER[SSTU] //Gemini Sized
{
    %diameter = 0.774
    %cost = 700
}
@SSTU_MODEL[Dock-Large]:AFTER[SSTU] // Common Berthing Mechanism
{
    %diameter = 2.347
    %cost = 4500
}

I also tried to edit ModelData-DockingPorts.cfg directly with the same values and no results, they remained stuck to default dimensions. Are the diameters hardcoded to refuse anything that doesn't conform to Stock standards?

[Shadowmage]

3 hours ago, NotTheRealRMS said:

A modding question: Is it impossible to change the docking port size options for Modular Station Cores?

No, it is perfectly possible, however it would not change the adapter sizes, so you would no longer get flush mounting.

The proper way to do it is to adjust the scale in the model definition files for the models (you are about halfway there with your patches).  The easiest way to do that is with the SUBMODEL setup.  You would need to change the docking port model defs to something like:

 

SSTU_MODEL
{
	name = Dock-Large
	modelName = Dock-Large
	invertForTop = false
	invertForBottom = true
	//vOffset needs adjusted by scale 0.05 * 0.938 = 0.0469
	verticalOffset = 0.0469
	//height needs adjusted for scale, old = 0.29 * 0.938 = 0.27202
	height = 0.27202
	//diameter gets adjusted by scale as well
	diameter = 2.347
	mass = 0
	volume = 0
	upgradeUnlock = SSTU-ST-DockUpgradeLarge
	cost = 1000
	fairingDisabled = true
	fairingTopOffset = 0
	defaultTextureSet = none
	//need to adjust node for the scale below
	//old = node = 0, 0.29, 0, 0, 1, 0
	node = 0, 0.272252, 0, 0, 1, 0
	SUBMODEL
	{
		modelName = Squad/Parts/Utility/dockingPortSr/model
		position = 0, 0, 0
		rotation = 0, 0, 0
		//scale is the ratio of the new diamter to the raw unscaled diameter of the model
		//2.347 / 2.5 = 0.938
		scale = 0.938, 0.938, 0.938
	}
}

Note that you need to adjust verticalOffset, height, diameter, and node positions in the model definition for the change in model scale.  What the SUBMODEL block of code does is manipulate the model before the ModelData/ModularParts even see it.  So as far as the other sysetms are concerned, the model is exactly like you specify in the config (the rest of the system still sees the model at its 'new' 100% scale, which is 2.347m in diameter).

Also note that most of the fields in the model definitions don't specify the values that get used in the modular parts; they specify the parameters of the model at 100% scale, which are then used to calculate what scale various bits need to be at when you select '2.5m diamter' on the diameter adjustment sliders.

On the station-core parts, there is no 'diameter adjustment', and the docking port models get used unscaled.  This is why changing the 'diameter' in the model definition did not work (the station-core module does not scale the docking port models; they are not intended to be scale-able).  On other models changing the 'diameter' would not work how you are expecting either.  Basically... don't change the specified diameters, there is no reason to, and it will only break things.

And final note:  The above patch is untested.  If it doesn't work for you, the documentation on how to fix it is all online (source code for the plugins https://github.com/shadowmage45/SSTULabs/tree/master/Source  ).

 

3 hours ago, NotTheRealRMS said:

Are the diameters hardcoded to refuse anything that doesn't conform to Stock standards?

Hehe, I'll let this slide, as you are obviously new here. 

Close to nothing is hard-coded in SSTU, you just need to know the proper way to adjust the configs (which is undocumented outside of the plugin source code; which is actually excellent documentation for me, but might be hard for other to read...).

[ridik58]

 

Hello is anyone able to make a patch to have the ISRUs that produce carburan (lqd Hydrogen, NTO, Aerozine)? THX

[tater]

1 hour ago, ridik58 said:

 

Hello is anyone able to make a patch to have the ISRUs that produce carburan (lqd Hydrogen, NTO, Aerozine)? THX

It's actually on the list of things to do, I believe. So it's certainly possible to do.

Aerozine 50 would be a bit of a stretch for ISRU unless you go someplace with Nitrogen (or bring it with you).

Edited May 13, 2017 by tater

[captinjoehenry]

Never mind 

Edited May 14, 2017 by captinjoehenry

[AliceM]

Hi Shadowmage, is there still a way to reconfigure the tank inflight?

I remember there is a option many many version ago, is still available?

[Shadowmage]

14 hours ago, AliceM said:

Hi Shadowmage, is there still a way to reconfigure the tank inflight?

I remember there is a option many many version ago, is still available?

No, I've never had in-flight tank reconfiguration (at least not in the default SSTU install; some of the back-end code is in place, but completely untested).

[Shadowmage]

If there is anyone else who would like to help test out the new 'recoloring system', please send me a PM.  At this points most parts support recoloring, with the last few expected to be converted within the next couple of weeks.  -Tons- of back-end code/module side changes that need testing, as well as all of the new texture sets/coloring configuration options that need a good looking over.  Would love to have a couple more sets of eyes going over it to make sure that the initial release of the new system is as good as it can be.

 

General Development Updates:

Still working on the recoloring system.  Shaders are done, MFT tanks and engine mounts are done.  MUS, nosecones, and adapter textures are mostly done (need some texture side cleanup).  MSRB parts are WIP, with the StationCore scheduled for a bit later in the week.  Last up is a bit of code-side work to enable recoloring for all of the fairing types used by SSTU (NodeFairing, ISDC, resizable stock fairings); should be some simple changes to get those working, mostly just adding in the persistent fields to track the user-configured colors.

Debating whether to release the recoloring stuff as a final 1.2.2 update, or wait for 1.3 to be officially available.  As there are quite a few potentially craft/save breaking changes, I would prefer to hold off for the KSP update, but things could go either way depending on the timing of the 1.3 release and how quickly the rest of the work (and testing) gets completed.

One highlight of the recent work that I can share is the consolidation of the MSRB parts into a single in-editor part, using the same type of 'variant' system that is in use by the MFT-A tanks.  Not a huge change, but fixes something that has bugged me for awhile on those parts.

[Gordon Dry]

What type are the default docking ports at the station parts?

"Dock medium" is too small for NASA type, but too big for Apollo type.

"Dock small" is too small for Apollo type.

I don't know other common docking parts that have this typical look with the red outline, only the NASA and the Apollo type fit.

[Shadowmage]

8 minutes ago, Gordon Dry said:

What type are the default docking ports at the station parts?

"Dock medium" is too small for NASA type, but too big for Apollo type.

"Dock small" is too small for Apollo type.

I don't know other common docking parts that have this typical look with the red outline, only the NASA and the Apollo type fit.

You are comparing apples and oranges.

The docking ports in SSTU are stock sizes, and have no real-world equivalents.  Dock Medium = 1.25m, Dock Small = 0.625m.  They are not intended to represent any real docking ports, and are simply a docking port model built for game use.

[RedParadize]

@Shadowmage Hi, I would have love to test your new stuff, but I have been quite busy lately... Anyway I do not consider myself as reliable enough to do this. About updating prior to 1.3, you do not have to, the current release is more than ok for anyone that would wish to stick with 1.2.2. Unless you think a release prior to 1.3 does not represent extra work, I would advocate against it. I am sure you could use that time on something more useful (or just relax really).

I have been playing around and trying to make a ship that enter the atmosphere like a space shuttle but landing vertically, like the SpaceX ITS but much smaller. It got me thinking about your plan on doing the aeroshell thingy as it could probably do something similar. What I previously posted about it was way to ambitious to be made, there is definitively something to be done with much more simple mechanics while remaining customizable.

Edited May 15, 2017 by RedParadize

[Pappystein]

9 minutes ago, Shadowmage said:

You are comparing apples and oranges.

The docking ports in SSTU are stock sizes, and have no real-world equivalents.  Dock Medium = 1.25m, Dock Small = 0.625m.  They are not intended to represent any real docking ports, and are simply a docking port model built for game use.

So to be clear, if I want to make a Module Manager file that gives me a DP-0.5 or a DP-1.5 port in addition to the stock DP-0 and DP-1 ports (that is to say a 0.9375m or a 1.5m port in addition to the DP-0 or DP-1) then I would want to replicate the existing SSTU_Model Module in MM with the alterations to nodes and scale? 

PS @Shadowmage not that it matters, but it looks like the node position changes at a slightly different scale than 0.938 as dictated by your scale factor in your example above.  I am guessing you actually used 0.9388 (the exact answer for 2.347/2.5.)  I state this in-case someone is trying to re-create your math since the example and the text don't quite match.   you have got to love Sigfigs!   Well, no, you really don't!

TIA!

[Shadowmage]

3 hours ago, Pappystein said:

So to be clear, if I want to make a Module Manager file that gives me a DP-0.5 or a DP-1.5 port in addition to the stock DP-0 and DP-1 ports (that is to say a 0.9375m or a 1.5m port in addition to the DP-0 or DP-1) then I would want to replicate the existing SSTU_Model Module in MM with the alterations to nodes and scale?

Stand-alone parts, or as docking port options for the station-core parts?   Vastly different setups and systems at play there (and different modules/etc).

 

3 hours ago, Pappystein said:

I am guessing you actually used 0.9388 (the exact answer for 2.347/2.5.)

Ahh, yep, apparently I lost the last digit somewhere in my hasty-typing.  So probably all of the calculations in that above patch/config are a bit off.  Was more intended as an explanation than anything that could be directly used, so hopefully the overall point came across as to what bits needed scaled, and why

[Gordon Dry]

Last session I only was in the VAB and after adding an SSTU tank I wanted to resize it, I got a NaN inside the part's menu above the resize slider and the game became unresponsive, I had to kill the process.

Logs:
https://www.dropbox.com/s/v8hvm4jiv0nz5ip/2017-05-16-1 KSP.log.7z?dl=1

[Shadowmage]

43 minutes ago, Gordon Dry said:

Last session I only was in the VAB and after adding an SSTU tank I wanted to resize it, I got a NaN inside the part's menu above the resize slider and the game became unresponsive, I had to kill the process.

Logs:
https://www.dropbox.com/s/v8hvm4jiv0nz5ip/2017-05-16-1 KSP.log.7z?dl=1

RO is not supported -- you'll need to take any issues you find while playing using RO over to the RO thread.

 

The precise reason for the loss of function is you are missing some model files:

"ERROR: Could not locate model data for name: Adapter-1-1x2-Short"

This means your install is messed up somehow; either a bad actual install, or other things are messing with the SSTU setup/files/configs.

If you can replicate the problem on a clean install, feel free to file a bug report on the SSTULabs tracker, otherwise you'll need to find support through RO.

[Gordon Dry]

Adapter-1-1x2-Short is mentioned inside the

 

[MaxZhao]

On 16/05/2017 at 3:51 PM, Gordon Dry said:

Adapter-1-1x2-Short is mentioned inside the

 

 

Feel free to go to this thread to look for support there.

edit: there

Edited May 17, 2017 by MaxZhao

[Pappystein]

On 5/15/2017 at 9:48 PM, Shadowmage said:

Stand-alone parts, or as docking port options for the station-core parts?   Vastly different setups and systems at play there (and different modules/etc).

 

In the short term I am worried about stand alone but longer term the whole shebang.   So basic +PART for stand alone and the copy paste the module for the complex parts is what you are saying?