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

[tater]

You've likely seen this, but when I find something like this I think it's a good idea to leave it where it can be seen  . Looks familiar.

 

 

[Pappystein]

18 hours ago, tater said:

OMG, the semi is hilarious.

You need to add the basic whip antenna as a CB antenna  

I don't know,  If you add that and and make the trailer out of the Mk3 cargo bay....   Open the top to reveal the back half of a Helicopter....  Wasn't there a Super car TV show in the early 1990s that had a Semi truck transform into an Attack helicopter with 7 seats?    This is getting dangerously close

 

Edited November 27, 2016 by Pappystein

[tater]

Station Crew capacity, balance, etc...

I think it needs a little tweaking, though it very much depends upon life support assumptions in some sense. Below the capacities, plus images (I did not include the versions with RCS, etc for space).

COS-XS: 2 crew
COS - S: 2 crew

COS- M: 4 crew
Hitchhik: 4 crew
HAB-A1: 4 crew

2-4 crew image:

The COS-M is a real outlier here, unless it has decently higher LS capability (habitation and supplies, etc). The XS, should then have shorter duration LS capability in LS mods. Also, the COS-S is as big as HH or HAB-A, but has half the crew. I think this needs some real tweaking. XS=1? HAB-A = 2, COS-S = 3, HH = 4 and COS-M = 5?

CFG - A: 6 crew
HAB-A2: 6 crew
COS - L: 6 crew
HAB-B1: 6 crew
HAB-B3: 6 crew

This is where it gets more pronounced, IMO. CFG-A need loads of long term capability out of the box to make sense (which is fine). HAB-A2, OTOH, is just grossly smaller. I might be inclined to bump it down to 5 crew. It's actually about the size of COS-M, so maybe HAB-A2 and COS-M go to 5 crew (with the COS having slightly better LS stats)? Then the problem becomes the COS-L. It's substantially smaller than the HAB-b1/3 parts, and the torus. To scale the CFG-A is just like the centrifuge inside Discovery from 2001, so I like the lower crew, better stats there. I might be inclined to keep the COS-L at 6, and bump the HAB-B1/3 to 7 or 8 (it looks to be on the order of 7-8 times the volume of the stock hitchhiker, and is considerably lighter---3.45 tons inflated vs as much as 20t for 8 HH).

HAB-B2: 9 crew
HAB-B4: 9 crew
(no pic)

 

CFG - B: 12 crew
HAB-C1: 12 crew
HAB-C3: 12 crew

Reasonable, with the torus getting a huge LS bump. Frankly I'd like to see the CFG vs HAB different, just to be different, lol. Maybe 13 or 14 for the CFG-B?

CFG - C: 18 crew
HAB-C2: 18 crew
HAB-C4: 18 crew
(no pic)

CFG - D: 24 crew
(no pic)

 

My gut says for gameplay balance, it might be nice to have the COS-L in fact be 7 crew and the COS-M with 5 crew. It gives a wider array of capacities with one unit---2, 4, 5, 6, 7, 8, 9, 12.etc. I also might consider bumping up the tori by even just 1-2 crew to make them different than the larger inflatables that currently have the same capacity. Even though there is no need for larger crew, I'd still likely bump the CFG-D higher (largely to distinguish it more from a couple of smaller inflatables---it's the same as just 2 HAB-C3s!). Note also that a CFG-D is 158 tons, vs 15t for the same crew with 2*HAB-C3. 10 times the mass, same crew. It needn't go 1:1 on crew/ton, but that torus can easily hold 50. I get the lower numbers because we don't need high numbers... but just to make them seem as big as they really are is worth something (the CFG-D is magnificently huge!).

This would alter the following:

(COS-XS: 1) (or keep it 2, but with very little LS)

HAB-A: 2

COS-S: 3

COS-M: 5

HAB-A2: 5

HAB-B1/3: 7

Possibly bump the CFG-B/C by 2/4, respectively, and the CFG-D to 30 or more.

 

 

 

Edited November 27, 2016 by tater

[tater]

The crew per ton (fitted out) of the parts is fairly consistent at about 1.3-1.7 crew per ton. The outliers are COS-HAB-S at about 1/2 that, and the HAB-A1/2 parts that are about 3.75 crew per ton. I like the idea of the A1 in particular needing few (or NO) rocket parts, but then the crew space should be more limited, I think (think if it like a more capable BEAM). The A2 should have the fitted out mass increased, I think---maybe to 2-3 tons, with 5 crew (but lower stats than COS units). The other outliers are all the tori. They go from 0.48 crew/ton, to 0.15. That's 3-10X fewer crew per ton than the rest of the parts.

More capability is obviously required (LS supplies, and modifiers to make them terrific in other words), but even than, possibly more crew. The C and D could double their respective crews and still be in the range of the 2 smaller tori, which would still be 3-5 times fewer crew per unit mass than the other parts.

[tater]

ShipCore idea:

We have the MFT-L tanks that have a hollow option, as well as Decouplers with a hollow option. What about an Half stage engine mount option? I just made an Atlas like LV, where I used the Pyrios mount, attached to a hollow decoupler. Set the interstage on the tank, then put the double engines such that I can stage them away once the TWR gets up towards 2. The mount itself is not visibly hollow, but it can work. The only issue is that there is no crossed option for the decoupler, so I have to add a fuel line---that and if I get the attachments wrong, it blows up.

[Shadowmage]

If anyone is interested in helping to test the custom wheel colliders, please either post here or send me a PM.  It includes patches that duplicate the stock parts using the new wheels, and a second set of patches duplicating all of the KerbalFoundries parts.  Parts are duplicated so that they may be tested alongside the original part for performance comparison.

Will be packing up a release for 'private' testing shortly, should have it available within an hour or so.  Will also have a second download of the SSTU-SC-E parts w/integrated wheels for testing (still has other problems, but the wheels should be working).

Initial testing will be done with a smaller group until the majority of the initial problems are solved and things are looking generally stable.  Hope to expand it into a public release in the next week.  All testing interaction will be done through GitHub; new testing releases will be downloaded from there, issues must be posted there (and must include logs, screenshots, and repro details), and it will otherwise serve as the main point of contact and organization.

 

@tater Sorry i've been a bit busy with the wheels lately; will copy your suggestions to the relevant SSTU repo/issues so that it does not get lost.

Generally, yes, the crew capacity balance is all over the place.  I need to find out a good unified method that I can apply to all of the modules; I have a feeling it will have a 'comfort factor' in it that will generate the differences in m3/crew and tons/crew (some parts will be packed like sardines; others will be much more roomy).

Edited November 28, 2016 by Shadowmage

[mechanicH]

@Shadowmage Would be a pleasure to help out with the testing.  

[tater]

No need to be sorry, I tend to "blog" things when I am testing, because otherwise I forget them. I found myself making a spreadsheet with the capacities and masses to check the differences.

From a gameplay, POV, I think about what part to use for which function in career (because Sandbox is entirely aesthetic, or possibly LS related). Cost of course is another balancing element, but more complex in the case of inflatables---you need to consider the cost of fitting them out.

I used to use 1 hitchhiker per every 1-2 crew for long-duration flights, so the COS-S being 2 is actually not bad. In that case the A1 should probably be the same (seems unlikely it should be better).

It's complex for sure. For people not using LS, it might seem odd, but the best balance will likely include many of the perks possible on some parts, and more spartan accommodations for others.

[APlayer]

Will these parts have mod integration? Meaning things like KeepFit! or Kerbalism, which add crew quality of life.

If not, I already offered my help in the Kerbalism thread (I am indeed particularly interested about this one) and said that I would be glad to give it a try and write some MM patches.

However, since this topic is complex, I ask for some documentation on what modules are activated and deactivated in the inflatables, and similar, non-conventional things.

Thanks a lot in advance.

[Shadowmage]

46 minutes ago, mechanicH said:

@Shadowmage Would be a pleasure to help out with the testing.  

Please check: https://github.com/shadowmage45/KSPWheel/releases/tag/0.9.0  for the download link.  Please read the release notes, as there are important details in there.  Notably I will only be responding to issues posted to GitHub (neither the SSTU nor KF threads are the right place for them, so please don't clutter them up).  There are also some brief instructions/notes in there about how to set things up, and fixes for common problems.  Important stuff...

9 minutes ago, APlayer said:

Will these parts have mod integration? Meaning things like KeepFit! or Kerbalism, which add crew quality of life.

If not, I already offered my help in the Kerbalism thread (I am indeed particularly interested about this one) and said that I would be glad to give it a try and write some MM patches.

However, since this topic is complex, I ask for some documentation on what modules are activated and deactivated in the inflatables, and similar, non-conventional things.

Thanks a lot in advance.

Yes, and maybe.

I'll personally be writing mod-integration configs for stuff like USI-LS, UKS/MKS, EPL, and CTT.  However I do not use TAC, KeepFit, or Kerbalism, so will not be writing any of those configs myself, but have no problem if others submit them for inclusion.

So -- you are more than welcome to submit some configs/patches for other mods.  I can/will offer insight or information when needed.

To answer your current question -- nothing is disabled in the inflatables (or other parts) except for crew capacity.  This may change in the future if I can find some clean way to disable things; but for now removing the crew effectively disables most of those parts' functions.

[tater]

 

[tater]

A part that would be really, really useful would be a novel cupola part. The stock cupola is huge, and massive. In addition, it;s functionally an "end" part. You can stick a docking port on front, but then it looks awful. What if there was a COS-XS that had substantial windows on the side(s)? They'e be multi-paned, with thick mullions. 

I suggest this because many of the contracts require a lab, a cupola, or both, and it's hard to properly add a cupola.

[mechanicH]

@Shadowmage Been playing with the wheels for a solid 3 hours,  So far so good.To anyone trying them just make sure to read the instructions CAREFULLY, but i love the new options. All the wheels and gear are solid after customizing/configuring them to your specific needs. Great work Mage. 

12 hours ago, Shadowmage said:

Will also have a second download of the SSTU-SC-E

Was this in that DL on github, or you gonna add it later for testing? 

[Shadowmage]

10 hours ago, mechanicH said:

@Shadowmage Been playing with the wheels for a solid 3 hours,  So far so good.To anyone trying them just make sure to read the instructions CAREFULLY, but i love the new options. All the wheels and gear are solid after customizing/configuring them to your specific needs. Great work Mage. 

Was this in that DL on github, or you gonna add it later for testing? 

Good to hear on the wheels; yeah, configuration for them is everything.  They'll certainly be more complex to setup than stock wheels; but you can also actually set them up (as opposed to stock wheels that don't really expose any useful settings from an engineering standpoint).

SC-E -- ran into some issues with the wings snapping off, so release was delayed until I can sort those.  Should probably have it available in a few hours; pretty sure I know what the problem is, merely need to add the fix, and do some additional testing to make sure it worked.  Release will contain an updated SSTUTools.dll, and all of the SC-E configs/textures/models; you should be able to merge it in with your existing SSTU install/folder, overwriting anything when prompted.

[tater]

I'll try and test the new stuff for you, I was going to last night, but my wife had been on call since Thursday, and the phone was ringing every couple hours every night since Thursday, and I was too tired to have the will.

Edited November 29, 2016 by tater

[mechanicH]

@Shadowmage Very nice. I also noticed something with the wheels (and im pretty sure it is because its the test model). I see the little white ball's where the wheels touch the ground, something like a white attachment node/collider point. That is supposed to be there right?  

[Shadowmage]

SC-E testing release is available:
https://github.com/shadowmage45/SSTULabs/releases/download/0.5.33.129/SSTU-0.5.33-129-SC-E-Test.zip

It only contains the SC-E files, simply merge it into your GameData/SSTU folders.  It contains an updated .dll that allows linking of animation control to default action groups, so that the bay-doors can be linked to the gear deployment.  It has a few known issues, mostly that the GUI is too long; way too long... and it is still a bit unstable in flight.  But this test is mostly for the wheels; they function great for me... how do they seem to you?

You'll also need to install the KSPWheel release in order for the wheels to function; it can be found at:
https://github.com/shadowmage45/KSPWheel/releases/tag/0.9.0.2

 

4 hours ago, mechanicH said:

@Shadowmage Very nice. I also noticed something with the wheels (and im pretty sure it is because its the test model). I see the little white ball's where the wheels touch the ground, something like a white attachment node/collider point. That is supposed to be there right?  

Yes, that is a debug feature to indicate where the wheel colliders' hit-point was at (or bottom of suspension droop).  Was intended to help me setup the suspension offsets for all of the models properly.

[blowfish]

Revisiting the SC-E reminds me ... I believe there actually is a way to combine multiple wings/control surfaces on the same part.  I haven't tried it myself (I seem to say that a lot, don't I), but I suggested it in this thread and it sounded like it worked.  Didn't even need much code.

This does have some drawbacks ... (1) The UI would be pretty messy with all those control surfaces on the same part (though with reasonable defaults for the control toggles, most probably wouldn't need to touch them), (2) It only removes 3 parts at the expense of some configuration complexity and (3) I'm pretty sure it would break any hope of FAR compatibility, at least as it currently stands (no idea when the wing overhaul is actually going to happen)

[mechanicH]

41 minutes ago, blowfish said:

combine multiple wings/control surfaces on the same part

I believe SXT mod has something like this on 2 of their control surface flaps, But im not 100% sure if that is what you meant @blowfish.

[tater]

Here's that 1/2 stage I made the other night:

You can see the fuel line.the outer 2 engines drop off, the decoupler is actually inside (because of the mount geometry and node). That's the TRAILS Gemini on top, with SM. Need to weld the 5 parts for the CM, and the 5 for the SM.

 

 

A nice addition to the petal adapter would be to be able to entirely disable deployment/decoupling. I use it as intended, but is also an effective "service bay" for some ugly, non-SSTU parts.

Edited November 30, 2016 by tater

[CobaltWolf]

@tater can we get some VAB pictures with + without the booster section? I'm curious what the sustainer looks like and how you resolved the colliders.

[tater]

The bottom that the central engine clips through is apparently non-interactive.

 

Look at the booster 1/2 stage on the right. There are 2 black lines at the top as part of the texture/mount, and one at the bottom. The ring in the MIDDLE is actually the SSTU decoupler. The decoupler is set to "hollow collider" enabled, and I have the interstage node turned on on the tank. 

 

[tater]

@Shadowmage, my Mun station last night got sent a resupply (I threw USILS back in to test it, and realized that my stations were not supplied at all). Resupply got there with a new module, and I could not undock anything' It's a DOS-LAB. I was looking at the persistent trying to figure out what needs to be changed on there. Quick save looks like this:

				MODULE
				{
					name = ModuleDockingNode
					isEnabled = True
					crossfeed = True
					stagingEnabled = False
					state = Disengage
					dockUId = 2698996515
					dockNodeIdx = 1
					EVENTS
					{
					}
					ACTIONS
					{
						UndockAction
						{
							actionGroup = None
						}
						DecoupleAction
						{
							actionGroup = None
						}
						EnableXFeedAction
						{
							actionGroup = None
						}
						DisableXFeedAction
						{
							actionGroup = None
						}
						ToggleXFeedAction
						{
							actionGroup = None
						}
					}
					DOCKEDVESSEL
					{
						vesselName = Muni One
						vesselType = Station
						rootUId = 1669540999
					}
					UPGRADESAPPLIED
					{
					}
				}
				MODULE
				{
					name = ModuleDockingNode
					isEnabled = True
					crossfeed = True
					stagingEnabled = False
					state = Disengage
					dockUId = 1122133151
					dockNodeIdx = 1
					EVENTS
					{
					}
					ACTIONS
					{
						UndockAction
						{
							actionGroup = None
						}
						DecoupleAction
						{
							actionGroup = None
						}
						EnableXFeedAction
						{
							actionGroup = None
						}
						DisableXFeedAction
						{
							actionGroup = None
						}
						ToggleXFeedAction
						{
							actionGroup = None
						}
					}
					UPGRADESAPPLIED
					{
					}
				}

 

[Shadowmage]

21 minutes ago, tater said:

@Shadowmage, my Mun station last night got sent a resupply (I threw USILS back in to test it, and realized that my stations were not supplied at all). Resupply got there with a new module, and I could not undock anything' It's a DOS-LAB. I was looking at the persistent trying to figure out what needs to be changed on there. Quick save looks like this:

 

Pretty sure this is the same stock undocking bug as reported by Jimbodiah;  any docking port that is not fully docked should not have a DOCKEDVESSEL node, nor a dockUId, or anything else.  Search your persistence file for '2698996515' which is the UID of the part, you'll probably find that it points to the other docking port part, and that it also has a DOCKEDVESSEL node and/or dockUId (which it shouldn't). 

TL:DR -- stock docking port code is screwey and has had problems undocking for a long time.  The SSTU parts with multiple ports appear trigger this problem more frequently.  About the only thing I can do for it is to remove the docking ports from the parts, or put in some 'force-undock' code similar to Claw's stock-bug-fix (basically it adds a decoupler feature to the ports, with some code to force-update the docking port modules persistent state).

17 hours ago, blowfish said:

Revisiting the SC-E reminds me ... I believe there actually is a way to combine multiple wings/control surfaces on the same part.  I haven't tried it myself (I seem to say that a lot, don't I), but I suggested it in this thread and it sounded like it worked.  Didn't even need much code.

This does have some drawbacks ... (1) The UI would be pretty messy with all those control surfaces on the same part (though with reasonable defaults for the control toggles, most probably wouldn't need to touch them), (2) It only removes 3 parts at the expense of some configuration complexity and (3) I'm pretty sure it would break any hope of FAR compatibility, at least as it currently stands (no idea when the wing overhaul is actually going to happen)

I don't think that would really allow for the combination of control surfaces.  As the control surface modules use drag-cubes and interpolate between them, the two control modules would interfere with each other and you would get an indeterminate drag state.  (I think they use physics addForce to apply their control forces, but also lerp between drag cubes for deployed and neutral states).

However, it might allow me to fix the orientation problems for the SC-E tail, and clean up how I've setup the wings a bit, and allow for some built-in incidence in the wings (that wing shape should provide some lift even at zero AOA).

[tater]

Yeah, I used to always install the stock bug fixes mod, but Claw is gone, and it's not updated, so I did not install it.