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

[tater]

Well, the ports on the DOS-LAB are both occupied by fully docked modules (a lander, and a science experiment module). The DOS only has the 2 ports, top, and bottom. I have an SSTU port on the lander as well (I used the stock lander car in this case because career limited me, but it has an SSTU port on top).

 

 

[Shadowmage]

Have created a thread specifically for discussion of the KSPWheel mod/system:

Please bring any conversation regarding the wheels over to that thread, to help keep things organized and cleaned up.  It is the proper place to discuss features, balance, or other general discussion about the mod.

[blowfish]

2 hours ago, Shadowmage said:

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).

Huh, looks like you're right.  I hadn't noticed that before.  I guess they use the coefficients for induced drag, but regular drag cubes for regular parasitic drag.  Oh well.

[tater]

From aviation week... thought it relevant. 

[Jimbodiah]

How do you counterbalance for a person moving inside the smaller tori in the real world?

[APlayer]

6 minutes ago, Jimbodiah said:

How do you counterbalance for a person moving inside the smaller tori in the real world?

I am quite sure they have shifting weights installed, like pumping water between compartments. At least it would be be a viable solution.

Also, reaction wheels help with it.

Edited December 1, 2016 by APlayer
Typo

[mechanicH]

9 minutes ago, Jimbodiah said:

 

How do you counterbalance for a person moving inside the smaller tori in the real world?

 

I would assume reaction wheels, or some kind of Gyroscope system would be in place for such a thing

maybe even a smaller weight wheel spinning at variable speeds to counter such effect. 

Edited December 1, 2016 by mechanicH

[tater]

6 minutes ago, Jimbodiah said:

How do you counterbalance for a person moving inside the smaller tori in the real world?

I would imagine the mass of the occupants is fairly trivial compared to the mass of the structure.I supposed you could run a continuous water tank around it that has ullage in it roughly equal to the mass (same as volume for water) of the crew. If all the crew are on one side, the water will naturally pool at the other. 

[JoseEduardo]

for those interested in the extra textures, I made a github repo of SSTU Expansion, it contains all the previous extra SSTU textures and a few new ones, just download the repo and you're good to try them: https://github.com/FFCJoseEduardo/SSTU-Expansion

keep in mind though, that not only the textures are still in development, but some patches as well, hence why this isn't a release yet

feedback is also appreciated

Edited December 1, 2016 by JoseEduardo

[Shadowmage]

Current plans are to continue working on the wheels for the next couple of days.  Things there are in a fairly good state.  Few more things to clean up, finish up, or fix up, but most everything is working as intended (as far as the physics integration will allow anyhow..).

Hoping to get the wheels mostly finished and be able to start work on the SSTU bugfix and balance pass over this weekend.  May or not be an updated release depending on how far I make it (on both the wheels and the balance updates).  Have a bit of work to do on cleaning up the SC-E GUI -- apparently some of the recent stock code changes completely broke the module I was using to hide the GUI fields, so the SC-E-FS GUI is about two screens tall (mostly the RCS toggles =\).

Semi-long-term plans are to have the majority of the balancing and bugfixing done on SSTU by the end of December, and move into a bit of a maintenance mode for a few months while I do a couple things; 1.) Actually play some KSP, and 2.) Figure out what other series of parts I want to make (tied closely with playing...).  I'm sure there will be some ongoing balance changes during the play period, but I don't anticipate adding any new major features or creating any more parts/models for a few months.  (May or may not finish up the SC-D parts in the short term; will probably remove them from distribution from upcoming releases either way)

[tater]

Last night I was doing tons of experimentation with docking... I have yet to replicate my mun station issue. Very frustrating.

Regarding the GUI... is there any way to do something similar to "Configure Containers," but ideally smaller (thin like standard right click), and perhaps not transparent---like a daughter version of the current right click? Then certain rarely used stuff gets chucked in there, leaving the right click to the normal stuff, with all the other in a daughter pane. So deploying solar panels, extending antennas, disabling crossfeed, reaction wheels, etc only show in this daughter menu. Maybe for mod integration, much of the LS stuff goes in there as well, or perhaps a single button for LS, the brings up a LS sub-pane? If that is possible, perhaps another called Control" or something, and the RCS, SAS, etc all goes in there (stuff I rarely touch in flight, though maybe I'm just clueless).

Edited December 1, 2016 by tater

[Shadowmage]

3 minutes ago, tater said:

Last night I was doing tons of experimentation with docking... I have yet to replicate my mun station issue. Very frustrating.

Regarding the GUI... is there any way to do something similar to "Configure Containers," but ideally smaller (thin like standard right click), and perhaps not transparent---like a daughter version of the current right click? Then certain rarely used stuff gets chucked in there, leaving the right click to the normal stuff, with all the other in a daughter pane. So deploying solar panels, extending antennas, disabling crossfeed, reaction wheels, etc only show in this daughter menu. Maybe for mod integration, much of the LS stuff goes in there as well, or perhaps a single button for LS, the brings up a LS sub-pane? If that is possible, perhaps another called Control" or something, and the RCS, SAS, etc all goes in there (stuff I rarely touch in flight, though maybe I'm just clueless).

Yea, I spent a few hours trying to replicate the docking bugs, and only managed to a few times... and inconsistent at that.  Not easy to debug, and no way to even know what needs to be fixed (or if it can be fixed).  I'll hopefully make some headway eventually.

GUIs -- I like your idea, sadly it won't work with KSP.  All of the GUI controls are hard-coded to function how they do, down to the code that controls them is compiled into the plugins they are from, and the stock right-click menu GUI is not extensible in any meaningful fashion.  The most I can do is hide some of the existing buttons, there is no way to move them to a different window that I'm aware of.  (Might be some very hacky methods that involve moving around the GUI objects into different containers; but I have a feeling it would cause the rest of the KSP code to explode, as it expects the GUI controls to be in specific places)

[tater]

Yeah, at first with the updates I was playing with a clean SSTU, and had not seen the issue. The station in question contains almost entirely SSTU parts, however (a few stock parts, and some dmagic science parts). It also happened after adding USILS, but there were no USILS parts on the station, just the LS module I was delivering to make up for that fact, lol.

Claw's stock bug fixes are stuck on 1.1.3 (possibly forever), otherwise I'd throw that in there. If it's infrequent enough, I can always cheat---warp replacement craft to rendezvous using the new F12 capability, then EVA the crew across, and deorbit the broken craft (always fun!).

BTW, one of the container options is a structural container... is that one that might b someday configured as a pressurized container? Ie: has a high dry mad compared to other tank forms, and the contents are limited to KIS/LS/Rocketparts/etc?

[Jimbodiah]

Mage, any chance of wheels/tracks making it into a RoverCore expansion? I noticed you used the Foundries parts... would be cool to have some parts started for that parts core, and seeing as you are working on it already, might indirectly be a bonus for SSTU?

[Shadowmage]

19 hours ago, tater said:

Yeah, at first with the updates I was playing with a clean SSTU, and had not seen the issue. The station in question contains almost entirely SSTU parts, however (a few stock parts, and some dmagic science parts). It also happened after adding USILS, but there were no USILS parts on the station, just the LS module I was delivering to make up for that fact, lol.

Claw's stock bug fixes are stuck on 1.1.3 (possibly forever), otherwise I'd throw that in there. If it's infrequent enough, I can always cheat---warp replacement craft to rendezvous using the new F12 capability, then EVA the crew across, and deorbit the broken craft (always fun!).

BTW, one of the container options is a structural container... is that one that might b someday configured as a pressurized container? Ie: has a high dry mad compared to other tank forms, and the contents are limited to KIS/LS/Rocketparts/etc?

Looking into the docking ports is one of the first things I'll be doing during the upcoming bugfix pass.  If nothing else I'll be adding a 'force undock' option that would function as a decoupler + custom code to clear the docking port states.

Structural container -- was intended to allow for use of the fuel tanks (and more NF-trusses) as pure structural elements, bypassing all of the mass and cost calculations based on resources and instead using a flat specified volume->mass ratio.  It also increases the impact tolerance and max heat of the part to represent its use as a structural element.  Generally should cost less, weigh less, and have better stats for use as structural elements.

 

19 hours ago, Jimbodiah said:

Mage, any chance of wheels/tracks making it into a RoverCore expansion? I noticed you used the Foundries parts... would be cool to have some parts started for that parts core, and seeing as you are working on it already, might indirectly be a bonus for SSTU?

Yes!  But not for awhile I'm afraid.  Getting the wheel stuff working was obviously the first step.  Next will be fixing/reworking the LanderCore stuff so that it can once again have some fuel tanks with integrated landing legs.  This is all -after- the balance/bugfix/stability work that I'll be doing over the next month or so.  You might see the LanderCore stuff return sometime in the early spring, and initial work on the ProbeCore and RoverCore series of parts might begin late spring / early summer.

However I likely won't be using the KF models/parts, but will be making my own set of models for wheels.  I may use some of the tracks if I find I have use for them, but the KF parts still belong to KF, and I have no intention to supersede that use;  I only created patches for testing of the KF parts with KSPWheel to make sure that the models would in fact work with the new wheel collider; as soon as the KF plugin is working, I'll be removing those patches.

[tater]

31 minutes ago, Shadowmage said:

Structural container -- was intended to allow for use of the fuel tanks (and more NF-trusses) as pure structural elements, bypassing all of the mass and cost calculations based on resources and instead using a flat specified volume->mass ratio.  It also increases the impact tolerance and max heat of the part to represent its use as a structural element.  Generally should cost less, weigh less, and have better stats for use as structural elements.

Gotcha. I've used them as pressurized segments, which is what got me thinking about them.

[Jimbodiah]

21 hours ago, Shadowmage said:

However I likely won't be using the KF models/parts, but will be making my own set of models for wheels.  I may use some of the tracks if I find I have use for them, but the KF parts still belong to KF, and I have no intention to supersede that use;

I would really love to see some tracks. Only KF had these for some reason, no one else made any to my knowledge. Wheels are so 1970s

You have lots of work planned by the sound of it.

[AlphaKerman]

Please also add TAC LS in the hab module . Or is there any way manually adding it?

Sorry, I forgot that i had ask the question before. My fault 

Edited December 4, 2016 by AlphaKerman

[Pappystein]

So, a few delayed posts here... Busiest work year for me by far...

1) Semi Truck, I know that was for wheels but wasn't there a early 1990s TV show that featured a Semi-Truck that turned into a 7 passenger "Attack" Helicopter?    Future path of SSTU?!

2) @tater et-al.  Centrifugal Stations have such a huge mass that the mass of a person on the "ring" is so minuscule in comparison to the overall mass and inertia of the station itself that they are not an issue balance wise.   Get all 200 kerbals at the same side however.... and you might get a small bump.    This is part of the reason I don't think large inflatable Centrifuge stations are viable in Real-world or should be in KSP.   The Sheer loss of mass from the inflatable to the solid "tinker-toy" style station makes them (the inflatables) un-weildly at best.  Because sure, your HAB is light weight, but you have to launch literally tons of counter weights and Gryoscopic balance devices just to get it to rotate safely.  A "Tinker-Toy" style would be more massive, and thus overcome the key issue.   On top of that, have you ever seen an inflated Baloon that was a MOVING part in a device, A) stay the same shape, and more importantly B) survive?

3) @Shadowmage and Tater,  I too am having issues with the docking ports again.   I really wish someone could/would fork and update @Claw's work around.  Shadowmage, I don't think this is something you are going to be able to fix inside SSTU without replicating Claw's work in your DLLs.

 

---

UPDATED!   An Idea, I was floating around in space and realized that the "Universal" Docking ports from @CaptainKipard seemed to not have issues in my game.  The only real difference that I can see is they use a different way to delineate the Nodes.   Might be worth looking at?

As in Universal Docking ports:

NODE
{
    name = top
    transform = n_top
    size = 3
    method = FIXED_JOINT
}
NODE
{
    name = bottom
    transform = n_bottom
    size = 3
    method = FIXED_JOINT
}

 

VS

SSTU:

node_stack_top =    0,  0.08796, 0, 0,  1, 0, 2
node_stack_bottom = 0, -0.05,    0, 0, -1, 0, 2
node_attach =       0, -0.05,    0, 0, -1, 0

 

---

4) a Question,  in the CFG files what are the other Defaults can I set a Fuel tank to?  I did not see a list of them in this thread.  Maybe this info could be add it to the Wiki for people implementing SSTU tank process to non SSTU tanks?   I am attempting to make a bunch of older mods parts work with the SSTU configurable tanks.  The two I am most concerned with are H2/O2 and NTO/AZ50.   THANKS!

Edited December 4, 2016 by Pappystein
Idea on Docking ports

[APlayer]

17 hours ago, Pappystein said:

On top of that, have you ever seen an inflated Baloon that was a MOVING part in a device, A) stay the same shape, and more importantly B) survive?

I did not, but neither it is an inflated baloon. Look at the BEAM, it does not inflate like "inflate" and it does not have the same properties a baloon has.

It is not moving, but making a similar thing rotate wouldn't be too big a deal, I guess...

[Pappystein]

2 minutes ago, APlayer said:

I did not, but neither it is an inflated baloon. Look at the BEAM, it does not inflate like "inflate" and it does not have the same properties a baloon has.

It is not moving, but making a similar thing rotate wouldn't be too big a deal, I guess...

@APlayer you are correct in that this is more than just a balloon.  There is some structure underneath, I was speaking in hyperbole to point out the fact that this is a skin that will contain atmosphere.  The more you move it the more likely it is to fail.  

The Whole point of Inflatables is so NASA won't have to "design" a Saturn V class rocket....   NASA already has one designed.  It is called Saturn V

 

[Shadowmage]

17 hours ago, Pappystein said:

So, a few delayed posts here... Busiest work year for me by far...

[...]

3) @Shadowmage and Tater,  I too am having issues with the docking ports again.   I really wish someone could/would fork and update @Claw's work around.  Shadowmage, I don't think this is something you are going to be able to fix inside SSTU without replicating Claw's work in your DLLs.

 

---

UPDATED!   An Idea, I was floating around in space and realized that the "Universal" Docking ports from @CaptainKipard seemed to not have issues in my game.  The only real difference that I can see is they use a different way to delineate the Nodes.   Might be worth looking at?

 

---

4) a Question,  in the CFG files what are the other Defaults can I set a Fuel tank to?  I did not see a list of them in this thread.  Maybe this info could be add it to the Wiki for people implementing SSTU tank process to non SSTU tanks?   I am attempting to make a bunch of older mods parts work with the SSTU configurable tanks.  The two I am most concerned with are H2/O2 and NTO/AZ50.   THANKS!

3.)  Hmm.. I'll work on putting something generic together for inclusion in the next release(s).  Since Claw's fixes no longer work, I'll look into making it a truly generic solution/replacement.  Will likely be a simple Module that can be added to any/all docking port enabled parts that will add a 'force-undock' button to that part for the port specified in the config.  Will be interesting figuring out how to incude it on the StationCore parts, as there is no docking-port module in the config....  (may be making two solutions; a generic replacement for Claw's fix, and one specially setup for the station-core parts with swappable ports).

3a) -- Sadly that would make no difference to how the ports work.  That merely is a different way for it to load the node data, and should have zero effect on their use after the data is loaded.  I'm pretty sure the differences are caused by my parts having multiple docking ports in a single part, which I've not seen anywhere else (other than a single one of PJ's inflatables).

4.)  Which 'defaults'?  There are... lots.. of different things in there that have defaults.  Default resources available?  Default resources assigned to the tank?  Default modifier types?  Default fuel type?  Default tankage volume?  Default tankage mass?  (I'm guessing you are referring to resources;  but which parts are you having problems setting up?  The available resources, the ones the part starts with, or other?

[Pappystein]

3 minutes ago, Shadowmage said:

4.)  Which 'defaults'?  There are... lots.. of different things in there that have defaults.  Default resources available?  Default resources assigned to the tank?  Default modifier types?  Default fuel type?  Default tankage volume?  Default tankage mass?  (I'm guessing you are referring to resources;  but which parts are you having problems setting up?  The available resources, the ones the part starts with, or other?

Sorry the Default Fuel on tank placement.   Your tank is Default Fuel Type LFO.  Was wondering the abbreviations or names for the other fuel types So I can place say, an Agena tank from FASA and have it already filled with NTO and AZ50 instead of LFO.

 

Edited December 5, 2016 by Pappystein

[Shadowmage]

5 minutes ago, Pappystein said:

Sorry the Default Fuel on tank placement.   Your tank is Default Fuel Type LFO.  Was wondering the abbreviations or names for the other fuel types So I can place say, an Agena tank from FASA and have it already filled with NTO and AZ50 instead of LFO.

 

Ahh; I've referred to those as 'FuelTypes', and the available list can be found in the file 'GameData/SSTU/Data/FuelTypes.cfg'.

The currently available types are LFO, LF, MP, EC, Hydrolox, LiquidHydrogen, and Hypergolic. 

You should be able to set the 'defaultFuelPreset' in the CONTAINER node to one of those values -- IF those resources are valid for the container, it will set that 'fueltype' as the default selection. 
The total available 'fuel presets' are calculated based on the resources that are available in the part; if it has LF+O in it, then LFO will be available as a preset; if it has LqdHydrogen but no Oxidizer, then LiquidHydrogen will be available, but not Hydrolox; -- you must make sure that the resources are available before the fuel type will show up; this is done with the 'resource=XXX' in the CONTAINER definitions.

[Shadowmage]

Did a little bit of calculation / math work over the weekend on figuring out the balance for the StationCore parts, mostly as it relates to crew capacity.  I'm fairly happy with the general mass balancing of the inflatables -- they use a consistent phsyics based balance for their mass and end up within the range that I would expect for a part of their size and capabilities, so it is mostly the crew capacity that needs balancing

If I try and maintain a relatively constant mass-per-kerbal across the parts, I end up with some pretty insane values for crew capacity (CFG-D would have ~180 crew capacity, based on 0.6t/kerbal from hitch-hiker module).  If I try and use constant volume-per-kerbal its even worse.  Now, one of the main problems I had with such large crew capacities is that I did not want so see four-page-long blank lists of crew slots in the editor.  Since none of these parts have crew slots in the editor, it is not as large of a concern.

	rad	h or r2	usable volume	crew	mass per crew	m3 per crew	mass (t)
cos-hab-xs	1.25	1.25	4.970097753	1	1400	4.970097753	1.4
cos-hab-s	1.25	2.5	9.940195505	2	1400	4.970097753	2.8
cos-hab-m	1.25	3.5	13.91627371	3	1033.333333	4.638757903	3.1
cos-hab-l	1.25	5	19.88039101	5	680	3.976078202	3.4
cos-lab-s	1.25	2.5	9.940195505	1	2800	9.940195505	2.8
cos-lab-m	1.25	3.5	13.91627371	2	1550	6.958136854	3.1
cos-lab-l	1.25	5	19.88039101	3	1133.333333	6.626797004	3.4
a1	1.25	2.5	7.853981634	2	662.6797004	3.926990817	1.325359401
a2	1.25	3.75	11.78097245	3	662.6797004	3.926990817	1.988039101
b1	2.5	5	79.52156404	10	559.5961914	7.952156404	5.595961914
b2	2.5	7.5	119.2823461	15	559.5961914	7.952156404	8.393942871
c1	3.75	7.5	288.633825	24	533.8253142	12.02640938	12.81180754
c2	3.75	11.25	432.9507376	36	533.8253142	12.02640938	19.21771131
cfg-a	3.75	1.25	74.02203301	12	1040.934839	6.168502751	12.49121807
cfg-b	8.4375	1.5625	286.907665	36	997.5625542	7.969657362	35.91225195
cfg-c	15.625	1.875	814.4351288	85	952.4893953	9.581589751	80.9615986
cfg-d	22.5	2.5	2248.419253	175	904.1262603	12.84811001	158.2220956

Yes, it is intentional that the CFG parts have higher mass-per-kerbal; all that rotational hardware and internal structure comes at a cost.  They also have slightly less m^3 per kerbal, as a torus is a less efficient use of volume compared to a cylinder (more of the raw volume is used up by the skin and supporting structure, thus a higher average density across the part if taken as a whole).

Doing a bit more thought on it; still don't like having such absurdly large crew capacities, but it does give a mostly unified balance scheme across the parts, and allows for freedom-of-use of the part however the user would like (long term hab vs. space-hotel/airliner style transport). 

However even if I went with these large raw crew capacities I would likely still tailor the included life-support to a much smaller / more reasonable value (such as 20 crew max).  Further LS facilities can be added by using the stand-alone parts if needed; I don't think it is reasonable to expect 170 crew to fit into the same torus as all of their life-support equipment, at least not without vastly upping the mass of the part, or reducing the number of crew.  Anyone have an idea on the m^3 (and mass) per crew needed for life-support equipment on the ISS (storage, recyclers, scrubbers, etc)?