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

[chrisl]

When using a space station part (like SSTU-ST-DOS-COM), you can specify a top and bottom docking port.  How does SSTUModularStationCore know how to set each docking ports nodeType?

[Shadowmage]

9 minutes ago, chrisl said:

When using a space station part (like SSTU-ST-DOS-COM), you can specify a top and bottom docking port.  How does SSTUModularStationCore know how to set each docking ports nodeType?

Not anymore.  That function was removed in recent versions.

(for reference, the docking nodeType was hard-coded by the plugin for 'size0,size1')

[chrisl]

1 hour ago, Shadowmage said:

Not anymore.  That function was removed in recent versions.

(for reference, the docking nodeType was hard-coded by the plugin for 'size0,size1')

I'm still using an older version since I'm still on KSP 1.2.2 but that explains that.    Thank you.

[chrisl]

I'm playing RO/RSS/RP-0 with SSTU so SSTUVolumeContainer is replaced by ModuleFuelTanks from RealFuels.  So that may explain what I'm running into.  Alternatively, it could be because I'm still using SSTU 0.5.34.134 (which I think is the last one compatible with KSP 1.2.2).  But I've noticed something.  If I use SSTU-SC-TANK-MFT-A to create a tank, the dry mass and total volume change if I add a nose or mount.  But if I use a space station part and change the top or bottom of it, the dry mass and total volume doesn't seem to be effected

[Shadowmage]

3 minutes ago, chrisl said:

But if I use a space station part and change the top or bottom of it, the dry mass and total volume doesn't seem to be effected

Yep, that is intentional.  It was deemed more important that the station core parts be of a consistent dry mass than it was to have minor mass/volume changes with different adapters.  It allows for much easier (and more precise) balancing of delta-v (both needed from launchers, and in the parts themselves) and of life-support configurations.

You can change that in the configs to specify that the station-core parts also gain volume/mass with adapter changes.  Add 'useAdapterMass = true', 'useAdapterVolume = true', and 'useAdapterCost = true' somewhere to the SSTUModularStationCore part-module configs in order to enable using of the mass/volume/etc from the adapters.

 

16 minutes ago, chrisl said:

I'm playing RO/RSS/RP-0 with SSTU so SSTUVolumeContainer is replaced by ModuleFuelTanks from RealFuels. 

Yep, that'll mess with things.  I cannot offer any support when RO or RealFuels is in use.  You are on your own.

3 hours ago, Jiraiyah said:

if you guide me which log file should i send i will provide it

 

[Jimbodiah]

I don't drink alcohol, so I can't use that as an excuse.... but...  colorable rcs effects? Just sayin'

[Shadowmage]

Just now, Jimbodiah said:

I don't drink alcohol, so I can't use that as an excuse.... but...  colorable rcs effects?

Nope, not as far as I'm aware.

RCS use the stock EFFECTS blocks.  Not really something that can be manipulated at run-time very easily, and I'm 99% certain that they don't support color manipulation anyhow.

[chrisl]

6 minutes ago, Shadowmage said:

Yep, that is intentional.  It was deemed more important that the station core parts be of a consistent dry mass than it was to have minor mass/volume changes with different adapters.  It allows for much easier (and more precise) balancing of delta-v (both needed from launchers, and in the parts themselves) and of life-support configurations.

You can change that in the configs to specify that the station-core parts also gain volume/mass with adapter changes.  Add 'useAdapterMass = true', 'useAdapterVolume = true', and 'useAdapterCost = true' somewhere to the SSTUModularStationCore part-module configs in order to enable using of the mass/volume/etc from the adapters.

Oh, cool.  I may give this a try even if it messes with delta-v and life support configurations.  I'll just have to pay attention to those when I change things around.  Now I just need to understand how mass and volume are being calculated.  I know it has something to do with topDiameter, coreDiameter & bottomDiameter (or maybe just one) multiplied by the core mass and core volume.  I'm just not sure how exactly the diameters are being used to generate mass and volume.

 

7 minutes ago, Shadowmage said:

Yep, that'll mess with things.  I cannot offer any support when RO or RealFuels is in use.  You are on your own.

No worries.  I'm expecting that.   

[Shadowmage]

Just now, chrisl said:

I know it has something to do with topDiameter, coreDiameter & bottomDiameter (or maybe just one) multiplied by the core mass and core volume.  I'm just not sure how exactly the diameters are being used to generate mass and volume.

        private void updateMassAndCost()
        {
            modifiedMass = coreModule.moduleMass;
            modifiedMass += solarModule.moduleMass;
            if (useAdapterMass)
            {
                modifiedMass += topModule.moduleMass;
                modifiedMass += bottomModule.moduleMass;
            }

            modifiedCost = coreModule.moduleCost;
            modifiedCost += solarModule.moduleCost;
            if (useAdapterCost)
            {
                modifiedCost += topModule.moduleCost;
                modifiedCost += bottomModule.moduleCost;
            }
		}

It is based on the value specified in the SSTU_MODEL, multiplied by the current model scale, using cubic scaling  (e.g.  actualMass = modelMass * scale * scale * scale).  (in the station core parts, I think these masses are overridden/specified directly in the part-module, so those would be the values to adjust).

Model scale is calculated by the current visible diameter and the diameter specified in the SSTU_MODEL for that part.  (e.g. if the model specifies 'diameter = 2.5', and it is currently being used at a diameter of 5m, then the scale would be '2').

 

Technically -- you should just need to adjust the 'topDiameter', 'bottomDiamter', and 'coreDiameter' values appropriately in the part-config, and everything else should automatically scale to the proper scaled values.

Caveat -- the cubic scaling is probably not what you would expect if trying to scale them back up to 'real world' stats, so you might need to adjust the mass specified in the module config downwards to account for it.  How far to adjust will depend on how much you are scaling up the parts...  (the parts were reverse-balanced using square scaling of the real-world mass and a ton of math).

So -- to know how what the mass-scaling factor is that you will need to use, I would need to know what your desired diameter / scale is for those parts.

If your chosen scale is 1.6x  (4m diameter for the COS/DOS) parts, you would want a mass-correction factor of 0.625.

E.G (completely untested, written off the cuff, likely contains syntax errors/improper field names... just intended as an example for you to make your own patch... if you copy-paste it and expect it to work, prepare to get slapped):

@PART[randomStationCorePart]
{
    @MODULE[SSTUModularStationCore]
    {
        @topDiameter *= 1.6
        @coreDiameter *= 1.6
        @bottomDiameter *= 1.6
        @CORE,0
        {
            @mass *= 0.625
        }
    }
}

 

You might also apply that same 0.625 scale factor to the volume (add '@volume *= 0.625' on the line below the mass adjustment), as it by default uses cubic scaling which will throw off the available volume/fuel compared to the new dry mass (would end up with massive fuel volume and dV if not adjusted).

On 1/5/2018 at 7:54 PM, RedParadize said:

That or reducing maximum_drag, minimum_drag and angularDrag to 0

Those values do absolutely zero since the change to the new aero model.  Everything is based on drag-cubes now.

On 1/5/2018 at 7:54 PM, RedParadize said:

The radial booster decoupler generate way too much drag, it is particularly true and annoying when scaled down to 0.625 as it will inevitably make the booster crash into the rocket.

I've not had any issues with it.  You simply need to offset the booster that is being attached to it to make sure that the COM of the booster is below the COM of the decoupler.  This should ensure a clean 'nose out' decoupling.

(not saying that the drag cubes are calculated properly, only saying that I've not had any problems that couldn't be solved by proper COM setup).

 

If you turn on the debug menu and check the drag listed during normal flight, how does it compare with stock radial decouplers?  (keep in mind that the SSTU one will have more drag because it is physically seen as being much, much, larger than the stock decouplers, due to having a mesh that spans the entire length of the booster).

If you can provide information that proves the drag is way out of balance, I will gladly take action to correct it to be more inline with other equivalent stock parts.

[Jiraiyah]

@Shadowmage

here are the two log files : KSP.LOG and OUTPUT_LOG

[Shadowmage]

7 minutes ago, Jiraiyah said:

@Shadowmage

here are the two log files : KSP.LOG and OUTPUT_LOG

Looks like you are using the wrong SSTU version for the KSP version you are running.

[LOG 00:05:55.710] ADDON BINDER: Create binding redirect: aaa_Toolbar, Version=1.7.14.0, Culture=neutral, PublicKeyToken=null => aaa_Toolbar, Version=1.7.15.0, Culture=neutral, PublicKeyToken=null
[ERR 00:05:55.763] AssemblyLoader: Exception loading 'SSTUTools': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 

Additional information about this exception:

 System.TypeLoadException: Could not load type 'SSTUTools.SSTUGameSettings' from assembly 'SSTUTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

That error is caused by changes in the KSP-API that happened between KSP 1.3 and KSP 1.3.1.  It is causing the entire SSTU plugin to fail loading, which then causes all of the parts to not load properly (as they need the plugin code to load).

As the log states that you are using KSP 1.3.1 -- you should be using the most recent SSTU release -- https://github.com/shadowmage45/SSTULabs/releases/tag/0.7.39.148

(sadly, it looks like you have deleted AVC, so I cannot check what SSTU version you are running from the log alone)

Can you confirm you are using the SSTU release posted above?

[Jiraiyah]

3 minutes ago, Shadowmage said:

Looks like you are using the wrong SSTU version for the KSP version you are running.

[LOG 00:05:55.710] ADDON BINDER: Create binding redirect: aaa_Toolbar, Version=1.7.14.0, Culture=neutral, PublicKeyToken=null => aaa_Toolbar, Version=1.7.15.0, Culture=neutral, PublicKeyToken=null
[ERR 00:05:55.763] AssemblyLoader: Exception loading 'SSTUTools': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 

Additional information about this exception:

 System.TypeLoadException: Could not load type 'SSTUTools.SSTUGameSettings' from assembly 'SSTUTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

That error is caused by changes in the KSP-API that happened between KSP 1.3 and KSP 1.3.1.  It is causing the entire SSTU plugin to fail loading, which then causes all of the parts to not load properly (as they need the plugin code to load).

As the log states that you are using KSP 1.3.1 -- you should be using the most recent SSTU release -- https://github.com/shadowmage45/SSTULabs/releases/tag/0.7.39.148

(sadly, it looks like you have deleted AVC, so I cannot check what SSTU version you are running from the log alone)

Can you confirm you are using the SSTU release posted above?

I don't know, last night i stupidly shift deleted the zip file archive, will download it now and do a fresh install (deleting the SSTU folder and replacing with this one) I'll inform you. but i think i downloaded SSTU from this link : http://www.curse.com/ksp-mods/kerbal/241283-sstu-shadow-space-technologies-unlimited

are they different versions?

[Shadowmage]

1 minute ago, Jiraiyah said:

are they different versions?

Looks like the proper version from the filename when I download it.  Can't guarantee that it was correct whenever you downloaded it, as I sometimes forget to update Curse with the latest (and even when I do, there is often a day or two delay until they finally post the new versions).

Please let me know if the download that I linked from GitHub works for you or not.  (if it still doesn't work... then you will need to clean up your KSP install and try out using just SSTU+dependencies with zero other mods present)

[chrisl]

58 minutes ago, Shadowmage said:

It is based on the value specified in the SSTU_MODEL, multiplied by the current model scale, using cubic scaling  (e.g.  actualMass = modelMass * scale * scale * scale).  (in the station core parts, I think these masses are overridden/specified directly in the part-module, so those would be the values to adjust).

Model scale is calculated by the current visible diameter and the diameter specified in the SSTU_MODEL for that part.  (e.g. if the model specifies 'diameter = 2.5', and it is currently being used at a diameter of 5m, then the scale would be '2').

 

Technically -- you should just need to adjust the 'topDiameter', 'bottomDiamter', and 'coreDiameter' values appropriately in the part-config, and everything else should automatically scale to the proper scaled values.

Caveat -- the cubic scaling is probably not what you would expect if trying to scale them back up to 'real world' stats, so you might need to adjust the mass specified in the module config downwards to account for it.  How far to adjust will depend on how much you are scaling up the parts...  (the parts were reverse-balanced using square scaling of the real-world mass and a ton of math).

So -- to know how what the mass-scaling factor is that you will need to use, I would need to know what your desired diameter / scale is for those parts.

If your chosen scale is 1.6x  (4m diameter for the COS/DOS) parts, you would want a mass-correction factor of 0.625.

E.G (completely untested, written off the cuff, likely contains syntax errors/improper field names... just intended as an example for you to make your own patch... if you copy-paste it and expect it to work, prepare to get slapped):

Looking at Mir, all the TKS derived components look to have a diameter of around 4.35m, a launch mass of around 19.5t and dry mass ranging from 17t-18.5t depending on the module (according to astronautix.com).  Right now I'm basically just trying to setup the DOS parts as "generic" for use as Mir components.  So I'm shooting for 4.35m diameter, 17t dry mass and 19.5t launch mass (though I know the solar panel I use will slightly alter the masses).  I'm using the following to setup the size:

    @MODULE[SSTUModularStationCore]
    {
        @currentTopDock = Mount-None
        @currentBottomDock = Mount-None
        @topDiameter *= 1.74
        @coreDiameter *= 1.74
        @bottomDiameter *= 1.74
        %useAdapterMass = false
        %useAdapterVolume = false
        %useAdapterCost = false
        @CORE[*]
            {
                @volume = 1.74
                @mass = 1.74
            }
        @SOLAR,*
        {
            @POSITION,0
            {
                @position[*] *= 1.74
                //rotation = 0, 180, 0
                &scale = 1, 1, 1
                @scale[*] *= 1.74
            }
            @POSITION,1
            {
                @position[*] *= 1.74
                //rotation = 0, 0, 0
                &scale = 1, 1, 1
                @scale[*] *= 1.74
            }
        }
    }

From what I can see, this is resulting in the SSTU-ST-DOS-TKS (which I've just been using to test with) to have a topDiameter = 3.2625 and a core and bottomDiameter = 4.35.  So the size is right.  Setting the Core mass to 1.74 only results in a dry mass of 9.603t.  And setting Core volume to 1.74 results in an available volume of 7.88kL.  So it looks like I need to use Core mass = ~3.0 and Core volume = <1.0.

 

As a separate question, if I use the useAdapterMass, useAdapterVolume, and useAdapterCost flags as you mentioned earlier, is there any way to adjust the mass and/or volume of the top and bottom components without altering the actual SSTU_MODEL?

Edited January 9, 2018 by chrisl

[Shadowmage]

@chrisl

You don't want to explicitly specify the mass of the models.  You want to multiply the existing mass by a correction factor.

For your chosen scale (1.74x), you want to use a correction factor of 0.574713.  ( (1.74 * 1.74 * 1.74)  / (1.74 * 1.74) = 0.574713 ) (conversion function between cubic and square scaling)

So this would be the section of the patch for the core model adjustment:

@CORE[*]
            {
                @volume *= 0.574713
                @mass *= 0.574713
            }

Which -should- give correct mass/volumes/dV for the default configurations.  (~20t total mass, ~800dV worth of propellant).

 

7 minutes ago, chrisl said:

is there any way to adjust the mass and/or volume of the top and bottom components without altering the actual SSTU_MODEL?

You can adjust it in the SSTU_MODEL through patches (preferred), or explicitly override it in the SSTUModularStationCore config the same way that the CORE has explicitly overridden values.

But why would you need/want to?  Cubic scaling is the proper scaling method for adjusting volume with model scale changes, and you should not need any further adjustments to those adapter model volumes specified in their definitions.

(e.g.  while you do need a correction factor for the COREs, you do not need to apply correction factors to the adapters).

 

Again though, as you are using RO/RF -- all bets are off.  I cannot guarantee that they handle fuel volumes or tank dry masses properly; all that careful math I posted above is probably useless in that situation.  In fact, I can guarantee that RF will screw up the part masses (unless you can somehow tell the RF module to have zero dry mass for that part, and let SSTU manage the mass as it should be doing).

Edited January 9, 2018 by Shadowmage

[Jiraiyah]

56 minutes ago, Shadowmage said:

Looks like the proper version from the filename when I download it.  Can't guarantee that it was correct whenever you downloaded it, as I sometimes forget to update Curse with the latest (and even when I do, there is often a day or two delay until they finally post the new versions).

Please let me know if the download that I linked from GitHub works for you or not.  (if it still doesn't work... then you will need to clean up your KSP install and try out using just SSTU+dependencies with zero other mods present)

confirmed, what ever the problem was in the link on curse, downloading the one from github fixed it, thanks ,and sorry for bothering you a lot

[chrisl]

10 minutes ago, Shadowmage said:

@chrisl

You don't want to explicitly specify the mass of the models.  You want to multiply the existing mass by a correction factor.

For your chosen scale (1.74x), you want to use a correction factor of 0.574713.  ( (1.74 * 1.74 * 1.74)  / (1.74 * 1.74) = 0.574713 ) (conversion function between cubic and square scaling)

So this would be the section of the patch for the core model adjustment:

@CORE[*]
            {
                @volume *= 0.574713
                @mass *= 0.574713
            }

Which -should- give correct mass/volumes/dV for the default configurations.  (~20t total mass, ~800dV worth of propellant).

Using that I get volume of 8.36kL and 9.446t dry mass.  Admittedly, that does add up to about 19.6t launch mass with just fuel but that's closer to 1890dV and leaves no room for life support.  With 150 days of life support (50 days for three crew), I end up with about 1056dV and a launch mass of 17.67t (just shy of 5.5t of fuel).  But if the dry mass of the Mir modules is supposed to be around 17t, and launch mass is around 19.5t, I should only have 2.5t of fuel and life support.

If I remove ModuleFuelTanks and put SSTUVolumeContainer back in, the volume and mass still don't add up.  Dry mass results in 10.674 (15.471 with fuel) and volume results in 9720L which seems like a lot of space for life support.  But at least this helps me figure out what I need to do. 

 

27 minutes ago, Shadowmage said:

You can adjust it in the SSTU_MODEL through patches (preferred), or explicitly override it in the SSTUModularStationCore config the same way that the CORE has explicitly overridden values.

But why would you need/want to?  Cubic scaling is the proper scaling method for adjusting volume with model scale changes, and you should not need any further adjustments to those adapter model volumes specified in their definitions.

(e.g.  while you do need a correction factor for the COREs, you do not need to apply correction factors to the adapters).

So, for example, I could add something like:

@CAP[Adapter-2-1-Short]
{
@volume *= .5
}

That would reduce the volume of that adapter by half?

The reason I'd want to do this is, I'm assuming that the top and bottom adapters are adding all of their available volume.  For example, in an earlier set of tests, I found that the Adapter-2-1-Short was adding around 17.8kL (with SSTUVolumeContainer) to my available volume.  Considering the core gives 9.72kL (with SSTUVolumeContainer), that seemed like an excessive increase.

[Shadowmage]

4 minutes ago, Jiraiyah said:

confirmed, what ever the problem was in the link on curse, downloading the one from github fixed it, thanks ,and sorry for bothering you a lot

Glad that could get it working for you.  And no worries -- doing support is just part of doing modding.  At least you were willing to provide logs with minimal input; far too many others its like puling teeth trying to get simple information.

 

2 minutes ago, chrisl said:

That would reduce the volume of that adapter by half?

As those caps don't currently have a volume specified, your options are to:

• Use a patch that targets the SSTU_MODELs directly (will effect any/all parts using those adapters)
• Manually calculate and specify a volume for each adapter in every StationCore part.  Example below...  (keep in mind you are specifying the volume at its default scale as specified in the model definition, which then gets scaled according to the current model scale)

@CAP[Adapter-2-1-Short]
{
	%volume = 17.8
	//replace the 17.8 with your desired pre-scale volume, which will be different for every adapter
}

 

5 minutes ago, chrisl said:

For example, in an earlier set of tests, I found that the Adapter-2-1-Short was adding around 17.8kL (with SSTUVolumeContainer) to my available volume.

And that is exactly why the 'useAdapterVolume' is set to false on the StationCore parts.  Even small/simple adapters add so much additional volume, it was making it impossible to balance the parts with any sort of consistency.  Not a problem for a fuel tank where it is all supposed to be usable resource volume, but becomes highly imbalanced when used on a crewed part that would mostly be habitable volume.

 

(and all of this is why I won't touch RO, even with someone else's 10ft pole)

[chrisl]

28 minutes ago, Shadowmage said:

As those caps don't currently have a volume specified, your options are to:

• Use a patch that targets the SSTU_MODELs directly (will effect any/all parts using those adapters)
• Manually calculate and specify a volume for each adapter in every StationCore part.  Example below...  (keep in mind you are specifying the volume at its default scale as specified in the model definition, which then gets scaled according to the current model scale)

There is a Volume listed in the SSTU_MODEL for Adapter-2-1-Short (in \SSTU\Data\ModelData\ModelData-MFT-Adapters.cfg).  It's currently set to 27. 

 

EDIT:  Oh.  You can't adjust the SSTU_MODEL volume for a CAP like you can for a CORE (inside SSTUModularStationCore).  You can only specify a new volume, right?

 

28 minutes ago, Shadowmage said:

(and all of this is why I won't touch RO, even with someone else's 10ft pole)

I should point out, I do have a KSP test install with just SSTU.  I get the same values there for mass and volume as I do with my RO test install when leave SSTUVolumeContainer instead of replacing it with ModuleFuelTanks.  But I do understand what you're saying.    It's too bad though.  RO is awesome and SSTU is awesome.

Edited January 9, 2018 by chrisl

[Shadowmage]

5 minutes ago, chrisl said:

I get the same values there for mass and volume as I do with my RO test install when leave SSTUVolumeContainer instead of replacing it with ModuleFuelTanks. 

Interesting....

What is your target total / wet / dry mass / delta-V for the rescaled part? (really I just need to know target total mass and ISP, the rest can be derived...)

(the least I can do is figure out how to get it working properly with just SSTU -- I know it should be possible, and fairly certain I've done the calculations before)

 

6 minutes ago, chrisl said:

There is a Volume listed in the SSTU_MODEL for Adapter-2-1-Short (in \SSTU\Data\ModelData\ModelData-MFT-Adapters.cfg).  It's currently set to 27. 

Yep, that would be the volume for that adapter when used at its default scale (which for that model, and most, is 5m).  So its raw volume when scaled down to 4.35m would be:  27 * ((4.3 / 5) ^ 3)  =  17.173512 m3

From there you should be able to figure out what kind of conversion factor you need to apply.  Then, specify that new pre-scaled volume in the CAP setup in the part config.  Yes, there is a lot of math involved.  I generally go for spreadsheets whenever I'm doing balancing work like that, as it allows for much easier time adjusting variables and seeing results directly (so many spreadsheets...).

I would strongly suggest leaving the 'useAdapterVolume = false' in the configs.  While you certainly could patch the models/modules/etc for the volume you desire on the station-core parts -- its going to be hours and hours of work.

[chrisl]

19 minutes ago, Shadowmage said:

Interesting....

What is your target total / wet / dry mass / delta-V for the rescaled part? (really I just need to know target total mass and ISP, the rest can be derived...)

(the least I can do is figure out how to get it working properly with just SSTU -- I know it should be possible, and fairly certain I've done the calculations before)

Since I'm basing it off real life parts (Kvant-2, Kristall, Spektr & Priroda) I'm not exactly sure how much dV they should have.  Considering the numbers I can find only allow for about 2.5t worth of supplies and fuel (35% of which would be used for 90 days worth of life support), I'm guessing they won't have much dV.  Maybe around 250.  The dry mass I'm aiming for would be 17t with a launch mass of around 19.5t.

[StickyScissors]

Test of new TEL concept finally going somewhere after 100 billion revisions. Ignore the rocket plummeting in the background, i had to make sure the rocket could clear the tower without exploding something

[Jimbodiah]

Rockets are supposed to launch up, not sideways.

[Jimbodiah]

So, I am trying to build a tug that lets me leverage modules while building a station. Anyone have a better suggestion for those arms, they look kind of clunky, but I would like to keep them in style.

Infernal Roborics?

 

 

Edited January 11, 2018 by Jimbodiah

[tater]

I see what you're going for--getting the RCS out by the CM of the station modules to make maneuver a little better than just the tug at the back...