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

[Qwarkk]

Using the SC-E more today and I'm finding a few issues when docking:

1) When controlling from the SC-E docking adapters, distance to target is incorrectly shown. Even when i was touching the target docking port, the game showed a distance to target of around 10m. I was trying to dock to a ST-DOS module, so this might be an explanation if this distance calculation is done by COM as neither docking ports were individual parts?

2) When controlling from the SC-E docking adapters, the SAS could not lock to target. I know this is a stock bug, but it was definitely amplified using SC-E parts as i was consistently pointing about 45° away from the target docking port. Again, I know this is an issue with stock, so its more of a heads-up.

3) *this one isn't specific to SC-E* There are certain orientations in which SSTU docking ports wont dock together. I have it set to a max capture roll angle of 90°. But I'm finding that SSTU docking ports wont dock if the 2 bars in the center of the port are the same orientation - they have to be 90° from each other in order to dock. (< let me know if this doesn't make any sense, I'll grab some screenshots to explain better)

Edited December 9, 2016 by Qwarkk

[snekposter]

57 minutes ago, Qwarkk said:

There are certain orientations in which SSTU docking ports wont dock together. I have it set to a max capture roll angle of 90°. But I'm finding that SSTU docking ports wont dock if the 2 bars in the center of the port are the same orientation - they have to be 90° from each other in order to dock. (< let me know if this doesn't make any sense, I'll grab some screenshots to explain better)

I had this issue myself, found that it was an optional part of stock bug fixes(I think, it was a few months ago), the problem you're probably having is that it has to be within 90 degrees of the 'top' of the docking port, based on how it was attached to the craft in the editor. 

I didn't like the feature since the rotation of docking ports in the editor can be a bit haphazard at times, which made some ships hard/impossible to properly assemble in orbit. I deleted the module that introduced the 90 degree lock thing and everything worked normally. 

[TheRag]

Has anyone tried playing in Sandbox? I cannot for the life of me get the procedural tank to expand its diameter, which restricts me to 1.25m rocket tanks. I remember this mod have procedural tanks for every standard diameter (eg 1.25m 2.5m. 3.75m) but it seems it's been compacted into one procedural tank.

 

It works fine in Career though.   

[tater]

1 hour ago, TheRag said:

Has anyone tried playing in Sandbox? I cannot for the life of me get the procedural tank to expand its diameter, which restricts me to 1.25m rocket tanks. I remember this mod have procedural tanks for every standard diameter (eg 1.25m 2.5m. 3.75m) but it seems it's been compacted into one procedural tank.

 

It works fine in Career though.   

 

Posted nearly every page because @SQUAD needs to change the sandbox default behavior:

 

On 12/7/2016 at 4:45 PM, tater said:

I'm going to go out on a limb and say that you are in sandbox mode. In that case, you need to go into Settings from the KSC view, and at the very top is "Difficulty Settings." Select that. Under "Advanced" select All Part Upgrades Applied in Sandbox.

Now the diameter is a right click in the VAB.

Edited December 10, 2016 by tater

[Shadowmage]

15 hours ago, tater said:

 

Posted nearly every page because @SQUAD needs to change the sandbox default behavior:

 

Yeah, I'm looking to add some code to force-set that config setting on game-load.  Will probably result in it being impossible to disable it.

Thanks, btw, for playing tech-support on those questions.  Has been, and still is, very much appreciated.

On Friday, December 09, 2016 at 7:10 AM, Qwarkk said:

Using the SC-E more today and I'm finding a few issues when docking:

1) When controlling from the SC-E docking adapters, distance to target is incorrectly shown. Even when i was touching the target docking port, the game showed a distance to target of around 10m. I was trying to dock to a ST-DOS module, so this might be an explanation if this distance calculation is done by COM as neither docking ports were individual parts?

2) When controlling from the SC-E docking adapters, the SAS could not lock to target. I know this is a stock bug, but it was definitely amplified using SC-E parts as i was consistently pointing about 45° away from the target docking port. Again, I know this is an issue with stock, so its more of a heads-up.

3) *this one isn't specific to SC-E* There are certain orientations in which SSTU docking ports wont dock together. I have it set to a max capture roll angle of 90°. But I'm finding that SSTU docking ports wont dock if the 2 bars in the center of the port are the same orientation - they have to be 90° from each other in order to dock. (< let me know if this doesn't make any sense, I'll grab some screenshots to explain better)

Thanks for the report.

1.) Hmm... yeah, it is probably calculating distance from the 'control-from-here' parts COM, or vessel COM, and/or target's COM.  Will take a look at it, but likely nothing I can do without splitting those parts into separate parts.

2.) I've noticed the stock code has problems with a few of the SSTU integrated parts/pods as far as the SAS features are concerned.  Will do some testing to see if I can narrow down the cause, but it is likely due to stock quirks with complex parts.

3.) As far as I'm aware that is not caused by SSTU -- I don't do anything with docking port alignment except on the welding docking port.

[Shadowmage]

On Monday, December 05, 2016 at 8:42 PM, JoseEduardo said:

the CFG-D is around the same size as the Von Braun's wheel would be at 64% scale, and in his plans it would have 50 crew aboard

maybe 60 kerbals cap? 50 like Von Braun's plan plus 10 for tourists or people waiting for the next "moon shuttle service"

My mostly final crew balance for the COS/HAB/CFG parts is:

	crew	mass (t)	mass per crew(kg)	m3 per crew
h-xs	1	1.4	1400	4.970097753
h-s	2	2.8	1400	4.970097753
h-m	3	3.1	1033.333333	4.638757903
h-l	5	3.4	680	3.976078202
l-s	1	2.8	2800	9.940195505
l-m	2	3.1	1550	6.958136854
l-s	3	3.4	1133.333333	6.626797004
a1	2	1.325359401	662.6797004	3.926990817
a2	3	1.988039101	662.6797004	3.926990817
b1	10	5.595961914	559.5961914	7.952156404
b2	15	8.393942871	559.5961914	7.952156404
c1	24	12.81180754	533.8253142	12.02640938
c2	36	19.21771131	533.8253142	12.02640938
cfg-a	12	12.49121807	1040.934839	6.168502751
cfg-b	24	35.91225195	1496.343831	11.95448604
cfg-c	40	80.9615986	2024.039965	20.36087822
cfg-d	60	158.2220956	2637.034926	37.47365421

Still doing a little bit of debate on the HAB parts.  They have vastly better mass-per-crew compared to an of the others.  But, I suppose, that was the entire point of inflatables to begin with.

The centrifuges actually get worse on the mass-per-crew as they increase in size; but they will also be getting increasingly capable life-support / habitation time with increase in size.  Not as balanced for purely stock use... but that was never the intention.

 

Hoping to have a release available here in a few hours, but might be tomorrow depending on how deep I dig into the bugfixing.

 

 

[tater]

Helping field support questions is the least I can do.

[Wh1plash2]

Most likey a dumb question, But, on The Inflatable Station Cores, it says need x amount of rocket parts to inflate. Can you please point me in the right direction of a how to get and install those. got one in orbit and i cant figure out how to inflate it. Not sure how to make, or how to use them to make the core inflate. Thanks 

[tater]

You can have a SSTU tank, then in the right click there is "configure containers." Then add rocket parts, either as part of the mix of stuff, or a smaller tank with just rocket parts. As long as that is attached to the station with the inflatable, they can use the parts.

The parts are kept track of, so if it takes a few trips to load it with parts that's OK (the parts are much of the "stuff" inside the inflatable, like floors, walls, equipment, etc).

So you can either attach a tank of parts to the thing when you launch it, or make sure your rocket parts tank has a docking port on it, then add them later.

Edited December 11, 2016 by tater

[Shadowmage]

Have hopefully fixed both of those issues.

'Apply Upgrades in Sandbox' stock setting is now overridden by an SSTU difficulty option, which defaults to true.  So..yeah.  If for some reason you don't want upgrades in sandbox, you have to disable the SSTU option, and then go back in and disable the stock option.  But as I can't think of a use for having them disabled (at least as far as SSTU is concerned), I'd rather it be this way.

Have also added a 'RocketParts' fuel preset to the MFT tanks, so that rocket parts can be selected without needing to use the configure containers button.  Also added one for XenonGas, because... why not.

Swapped the SC-E over to use hypergolics for fuels, upped the dV of it a little bit (it was falling short when a payload was included).  It seems to be working fairly well, even if it can be a handful to fly.

Doing a bit more general cleanup, should probably have an updated release available a bit later this afternoon.

[Shadowmage]

Updated release is available:

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

Several bugfixes, couple general cleanups, and a major balance and cleanup pass over all of the station core parts.  Also re-introduces the SC-E with working wheels; still has a few quirks but is quite usable.

[Pappystein]

@Shadowmage   First, thanks for the help offline on my CFG questions!  I think I have it all sorted.   Eventually I will have all the mods I use converted off from interstellar fuel switch to SSTU....

Second, I have been playing your latest update in a new career on my test rig (an old core2-duo laptop with 8gb ram.)  If anything, and I freely admit I could be imagining this, 1.2.2 with your latest update seems to run smoother with less scene change lag.  I have not gotten it installed on my main PCs yet so I have not been able to launch a large space station to test the Docking port fix so lots of playing  to go yet.

Third, to clarify; the Wheel enhancements are only applied to the SC-E's wheels yes?

[Shadowmage]

1 hour ago, Pappystein said:

@Shadowmage   First, thanks for the help offline on my CFG questions!  I think I have it all sorted.   Eventually I will have all the mods I use converted off from interstellar fuel switch to SSTU....

Second, I have been playing your latest update in a new career on my test rig (an old core2-duo laptop with 8gb ram.)  If anything, and I freely admit I could be imagining this, 1.2.2 with your latest update seems to run smoother with less scene change lag.  I have not gotten it installed on my main PCs yet so I have not been able to launch a large space station to test the Docking port fix so lots of playing  to go yet.

Third, to clarify; the Wheel enhancements are only applied to the SC-E's wheels yes?

Good to hear on your conversions.  Yeah, after you get the basics of the config down it should go fairly fast; copy, paste, update volume, done.

Can't say as I noticed any performance improvements.  I did some minor cleanup of the code (remove some garbage generation in animation stuff), but the stuff that I did shouldn't really have a visible impact aside from less garbage generation/less stuttering.

Docking ports -- I actually disabled the 'fix' that I was working on for this release.  I was unable to duplicate the problem, so was unable to test the fix to see if it spawned GUI buttons properly, or actually fixed the problem.  IF you do run into any docking port bugs please upload the persistence file to the GitHub issue regarding docking ports; even if you have a few other mods in play, just having a peek at a few of the persistence files should let me know what is going on a bit better.  Bonus points if you can include a persistence file from before+after the bug occurs, and triple bonus points if the problem can reliably be duplicated with the 'before' persistence file.

Wheels -- yes, they are only in use on the SC-E; I have removed all other patches while I clean up some stuff in the PartModules and decide if I even want to have them available as a mod.  Don't worry, the SC-E won't be going anywhere, but KSPWheels is becoming more of an API for the collider and less of a mod/config/patch set.

[Pappystein]

58 minutes ago, Shadowmage said:

Good to hear on your conversions.  Yeah, after you get the basics of the config down it should go fairly fast; copy, paste, update volume, done.

 

Yes, I have everything I have kept from FASA (all except Apollo CSM/LM and Saturn Tanks) and all I have kept from Bluedog DB (mostly Agena and Titan parts currently) converted already.  The BDB parts scaled to sizes I prefer.  Both Transtages (FASA and BDB) are successfully setup as multi-tanked sharing a maximum volume limit and restricted by percentages.  I bumped the tankage percentage size to imply two tanks for a reduced fuel fraction as well. 

RE Docking ports, On my main laptop (i7 with 16gb)  I will just run the FASA Titan based tug I developed with SSTU station parts until I can find/confirm a docking port bug.  That way it is only a few parts not SSTU involved and easy to send a list of parts needed and MM cfgs if you need them.

 

[Shadowmage]

General development update:

Yesterday saw the first large balance pass across the station core parts.  They should all now have at least some semblance of balanced cost/entry-cost/tech-node placement.  Tech nodes are still a bit... off... but the choices on the stock tree are so limited, and the parts have to go -somewhere-, so they were put where the closest stock equivalent parts are located.

On the note of 'tech-tree placement' -- Several of the SSTU modular parts have compound capabilities that cannot be easily placed into a single tech-node.  For instance the integrated solar panels and docking ports, and to a lesser extent the integrated RCS, probe-cores, and antenna.  Currently they assume that you have already unlocked those capabilities in the tree before unlocking/using some of the SSTU parts.  While I'm mostly okay playing with the honor system, I also think it would be nice to have those capabilities properly unlock when their respective tech-nodes are unlocked.

To that end I'm working on integrating the part-upgrade system a bit more into the ModularStationCore module, and creating additional 'upgrade parts' that will unlock solar panels and docking ports for the StationCore parts.  The solar panel and docking port tech nodes will each get additional part(s) added to them that will enable the use of those features on the station-core modules.  So if you grab a ST-DOS-LAB it will not have solar panels or docking ports (or even the options for them) until you have unlocked the respective tech nodes.

Will probably also be adding the probe core upgrades as additional tech-node unlocks;  the parts will start with very basic probe cores (no SAS), which will be upgraded through tech-node unlocks to have better capabilities.  Integrated antennas may see range upgrades as higher level tech is unlocked.

There are a few other areas that I'de like to make use of the upgrade system, but going to take things one bit at a time and get the station-core bits sorted out first.

[Pappystein]

44 minutes ago, Shadowmage said:

General development update:

To that end I'm working on integrating the part-upgrade system a bit more into the ModularStationCore module, and creating additional 'upgrade parts' that will unlock solar panels and docking ports for the StationCore parts.  The solar panel and docking port tech nodes will each get additional part(s) added to them that will enable the use of those features on the station-core modules.  So if you grab a ST-DOS-LAB it will not have solar panels or docking ports (or even the options for them) until you have unlocked the respective tech nodes.

If I may be so bold as to suggest this is AWESOME for the Station core parts!  Also it is probably an easier way to unlock various part cfgs for tanks and the like yes?

One request on the engine upgrade subject.  Please don't use this for engine major variants.  In my opinion, using the part upgrade to delineate minor upgrades to engines, like F-1 baseline to F-1 Late production for the Saturn V for example, would be great... however having the Upgrade path change from a F-1 Baseline to an F-1A or a F-1B would be career/craft breaking in many situations, I have instances where I am using multiple sister engines (J-2 and J-2S on the same craft for example.) 

[Shadowmage]

19 minutes ago, Pappystein said:

If I may be so bold as to suggest this is AWESOME for the Station core parts!  Also it is probably an easier way to unlock various part cfgs for tanks and the like yes?

One request on the engine upgrade subject.  Please don't use this for engine major variants.  In my opinion, using the part upgrade to delineate minor upgrades to engines, like F-1 baseline to F-1 Late production for the Saturn V for example, would be great... however having the Upgrade path change from a F-1 Baseline to an F-1A or a F-1B would be career/craft breaking in many situations, I have instances where I am using multiple sister engines (J-2 and J-2S on the same craft for example.) 

I handle major engine variants by making new models.  Hence the RL10 series, and the distinct F1 vs F1B, and the entire Merlin engine line. 

That is as far as I'm taking it though;  I won't be making any F-1A, or J-2S, neither as distinct parts nor as upgrades.  This isn't RO; I don't need a multitude of 'similar yet slightly different' engines; even a few of those that I've made distinct variants of really don't need to exist as they are so close to others.

With that said, I might offer some upgrade mechanics for some of the engines, but they won't be based on variant stats.  Will be more intended to allow some of the lower-tier engines and parts to remain competitive and useful towards the end game without being OP in the very early game.  More precisely, their base stats will be nerfed and it will require upgrades to some of them to achieve their 'current' stats -- for instance the Merlin engine line will probably have a bit lower stats initially than they currently do, with their full potential being unlockable one or more tech nodes later than the base engine is unlocked.  Might also put the SRB gimbals behind an upgrade, or at least have their gimbal range be upgrade/upgrade-able.  The goal would be to make SSTU parts a bit less overpowered in the very-early career, but allow it to keep the current balancing by mid-to-late career.

That is all just thought/idea/speculation though.  Haven't quite worked out how it will all come together, or if it will even accomplish what I'm looking for.  Going to have to do a bit of early-career playtesting to see how it all feels currently and what all might be in need of adjustment and how to best adjust it.

[tater]

I tested a little last night, but I will start a new career play through and see if I can manage some docking nightmares for you, lol. 

Regarding persistent files, those are more important than quick saves, right? So start a play session, and save the old persistence file... I can manage that. Saving it multiple times I might space out doing, but I will try and remember to do so.

Edited December 12, 2016 by tater

[Shadowmage]

2 minutes ago, tater said:

I tested a little last night, but I will start a new career play through and see if I can manage some docking nightmares for you, lol. 

Regarding persistent files, those are more important than quick saves, right? So start a play session, and save the old persistence file... I can manage that. Saving it multiple times I might space out doing, but I will try and remember to do so.

Quick-save and persistence all use the same internal format (both are .sfs); so either works.  If you do a named quick-save prior to docking problems, and a named/unnamed/persistence save after the docking problems, that should be enough.

You can, in most cases, replace your persistence.sfs with one of your quicksaves and most things will work.  Might need to edit the active scene to place you back in the space-center, but I'm pretty sure I've loaded quicksave-renamed-as-persistence files that put me directly in control of loaded craft.

 

Don't go too far out of your way though just for testing things, unless you really want to.  Any testing you appreciated though

If you do start a new career please let me know of any feedback related to the very-early SSTU progression as it would relate to the PartUpgrade system (e.g. things that can be initially nerfed to unlock the full potential later in the tree).  I know you've brought up a few points in the past on the very-early-progression, which I might still implement, but would like to go with a method that keeps the SSTU parts available fairly early in the tech tree (one or two tiers past 'start').

[tater]

Yeah, career using the stock tree might be so broken as to not be worth making stock career satisfying in SSTU, the time might be better spent making it work well with CTT/ETT, etc.

If a quick save will do, I'll happily make loads of saves for you, that's easy enough. Intermittent problems are the worst in all things (like my DSL at home... water in the buried lines, probably, but frustrating).

[Shadowmage]

4 hours ago, tater said:

Yeah, career using the stock tree might be so broken as to not be worth making stock career satisfying in SSTU, the time might be better spent making it work well with CTT/ETT, etc.

If a quick save will do, I'll happily make loads of saves for you, that's easy enough. Intermittent problems are the worst in all things (like my DSL at home... water in the buried lines, probably, but frustrating).

Yeah, I'll probably be working on CTT and USI-LS/UKS integration later this week/weekend.  Still need something resembling usable for stock, but I don't think I'm going to spend too much time worrying about it anymore.

 

Good news is that the part-upgrades for unlocking solar panels and docking ports seems like it will work out.  Initial tests reveal that I can properly limit the selection of available solar panels and/or docking ports in the editor based on what tech has been unlocked.  Need to do a lot more config work to implement it in all of the StationCore parts, and decide how I want to handle the 'default' setup (for icon/etc) and if/how the default will change with upgrades/unlocks.  But so far so good.

Expanding on that, I added the support for part-upgrades-as-unlocks at the lowest level of model-definitions, so that the same features might be applied in general to adapters / nosecones / mounts / nozzles / tank variants.  Currently the code only supports it at the PartModule level for solar and dock options on the StationCore parts, but it would only be a few lines of changes to the other modules/etc to enable it more generically.  This would for example be used to limit the multi-coupler adapters to only unlock with the stock multi-couplers, or unlock other adapters or mounts in a more gradual and gated fashion.  Not saying that I will be using it in those areas, merely pointing out some examples.  None of this would be coming anytime soon either.  It will take quite a while to decide if and how I would want to set it up, and I'm not in any huge rush for it as it doesn't really add much to the gameplay.

A bit even further down the road I could see the upgrade-unlock system being used for engine layouts (limit cluster numbers in early career), fuel-tank modifier types (e.g. ZBO requires an unlock), and even some integration into the life-support capabilities for the station/base modules (start lower quality, unlock better scrubbers/etc).  Quite a bit down the road though...

[Shadowmage]

Took a look over CTT today.  Sadly it is not a solution to my problems with the stock tech-tree, so it doesn't look like I'll be doing any CTT configs.

My problems aren't with the number or placement of the tech nodes, but of the placement of parts within those nodes.

I'm not sure why I thought that CTT re-organized the parts; that was the impression I had originally, but looking over the source and config files it is apparent that all it does is add new nodes and re-link them into the stock tech tree.  Nothing against CTT, I'm sure it functions fine and serves the needs of the mods that use it, but it is not the tech-tree overhaul that I thought it was / that I am looking for. 

 

I'm looking for something that places parts into a logical technical progression.  Simple things would be already unlocked at the start (lights, ladders, all purely structural parts), and more complex technology would be unlocked progressively based on the complexity of the underlying technology and the unlocking of any prerequisite technologies.

Sadly none of the other tech-tree overhauls that I've looked at quite fit the bill either.  The ETT is a bit overcomplicated for my needs.  The SETI/unmaned tech trees are a bit too focused on historical progression.  And I lack the motivation to do support if I were to release my own tech tree (I can just see a flood of 'why is the tech-tree re-arranged' questions).

So it looks like I will be 'doing nothing' in regards to the stock tech-tree setup.  I'll try to place parts into stock nodes that look appropriate; but the stock tree is far too limited and backwards to allow for logical progression with the  placement of most parts.

 

(KSP -really- needs a career and science overhaul...)

Edit:  I'm still going to take a closer look at CTT and possibly ETT this weekend to see what kind of improvements could be made through using them.  Might be that they are not exactly what I'm looking for, but I'm willing to go with 'close' if it would be an improvement.  At the least they would offer a better range to distribute some of the parts that are currently clumped up, such as engines.  I can always put together an optional/personal patch to redistribute the stock parts a bit if I still see the need.

Edited December 14, 2016 by Shadowmage

[Pappystein]

41 minutes ago, Shadowmage said:

Sadly none of the other tech-tree overhauls that I've looked at quite fit the bill either.  The ETT is a bit overcomplicated for my needs.  The SETI/unmaned tech trees are a bit too focused on historical progression.  And I lack the motivation to do support if I were to release my own tech tree (I can just see a flood of 'why is the tech-tree re-arranged' questions).

(KSP -really- needs a career and science overhaul...)

I don't know if this will help but I was involved with some conversations a few years ago around Tech trees when careers first started.   A Historical progression is fine, if you keep things historical.   However, If you are not careful it will really bog down the game.   In some ways, I think @frizzank did it right when he set up FASA in the stock tech tree.  he brought the 2.5m size forward and focused on Maned missions. 

So my suggestion is move the 1.875 and 2.5m unlocks to earlier in the tree, This includes the non inflatable station parts (being available earlier.)   Doing so frees up more nodes for later in the game that you need to achieve "balance."

 

Edited December 13, 2016 by Pappystein

[JoseEduardo]

I really liked RP-0, but unfortunately it is a RO tech tree, it doesn't play well on stock, it CAN be played, but shouldn't play well, mainly because RO changes the name or clones parts and RP-0 needs them

a stock RP-0 would be cool though, but it would need more people involved

[Akira_R]

18 hours ago, Shadowmage said:

*snip*

I'm not sure why I thought that CTT re-organized the parts; that was the impression I had originally, but looking over the source and config files it is apparent that all it does is add new nodes and re-link them into the stock tech tree.  Nothing against CTT, I'm sure it functions fine and serves the needs of the mods that use it, but it is not the tech-tree overhaul that I thought it was / that I am looking for. 

 

I'm looking for something that places parts into a logical technical progression.  Simple things would be already unlocked at the start (lights, ladders, all purely structural parts), and more complex technology would be unlocked progressively based on the complexity of the underlying technology and the unlocking of any prerequisite technologies.

Sadly none of the other tech-tree overhauls that I've looked at quite fit the bill either.  The ETT is a bit overcomplicated for my needs.  The SETI/unmaned tech trees are a bit too focused on historical progression.  And I lack the motivation to do support if I were to release my own tech tree (I can just see a flood of 'why is the tech-tree re-arranged' questions).

*snip*

This is the exact problem I always face when trying to set up a career game, from the sound of it what you want out of a tech tree is exactly what I want, ETT is way to much, stock is well stock, CTT just extends the tree and SETI is to restrictive/focused. I usually settle with CTT and spend weeks rearranging things until I get it in a state that I am ok with playing.

This annoying process is why I proposed this:

 

Edited December 14, 2016 by Akira_R
snippy snip snip