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

[Shadowmage]

1 hour ago, Starwaster said:

When the part is loaded in the editor or in flight mode, the controlling module will remove everything that's not designated as being installed by default.

Yep, have tried that as well.  The problem is you need to remove the modules -before- they have their OnLoad() method called, which is not possible (the module is added to the part, and OnLoad() called immediately afterwards).  If you don't remove the module before it tries to load, any error during loading of the module-to-be-removed cascades through the rest of the part.

E.G. -- You have a ModuleEngines in the part config, but the engine-thrust transform for the engine is not present in the model in the prefab (as the model is configured through a ModelSwitch/etc).  The ModuleEngines will null-ref during loading (from the missing transform), which then causes the rest of the modules in the part to fail/not load.  (and/or similar problems with other modules regarding transforms not present in the prefab part)  (that is if they even load in the prefab properly; half of them will null-ref in the prefab on missing transforms, making them entirely unusable in the editor as they were not initialized properly (propellants/etc))

 

At least that is how it went down last time I tried that method, back in 1.1 or so.  Perhaps stock code has improved by now to where it would handle the error gracefully, but it certainly didn't at the time.  I've spent so many hours trying to get it working, everything from 'proper implementation' to 'terribly ugly hack', and haven't found a system that solves all of the problems.

[StickyScissors]

Is there a way to color every part of a tank (body/nose/mount) a single color at once? There's the load/save pattern thing, but that has to be manually created and saved, and it doesnt seem to save on game reload anyways. Im thinking just a small check box that toggles a mode where you click a color and it's applied to the entire part, not just a specific section

[Jimbodiah]

Select Cryo for tank type and Silver for the texture, then the whole tank will be one color.

[Starwaster]

3 hours ago, Shadowmage said:

At least that is how it went down last time I tried that method, back in 1.1 or so.  Perhaps stock code has improved by now to where it would handle the error gracefully, but it certainly didn't at the time.  I've spent so many hours trying to get it working, everything from 'proper implementation' to 'terribly ugly hack', and haven't found a system that solves all of the problems.

Maybe, but I doubt it  

Would one of the terribly ugly hacks have involved leaving the model enabled until after loading and then disable as needed along with removal of modules needing removing?

[T-10a]

8 hours ago, Shadowmage said:

Should be possible.  That is the entire reason for the module.

Log file?  (nothing I can do without logs but... guess...... I guess there is a problem somewhere?)

A clean reinstall of my game fixed the issue. Strange...

[Starwaster]

@Shadowmage Just curious, is there a reason the stock clampotron (aside from the Sr) isn't on the list of docking ports that station parts can be fitted with? Was it just a case of the similar sized SSTU ports being compatible and leaving it at that?

[Shadowmage]

On 1/26/2018 at 5:27 PM, Starwaster said:

Just curious, is there a reason the stock clampotron (aside from the Sr) isn't on the list of docking ports that station parts can be fitted with?

I'm guessing you are talking about the KSP 1.2+ versions of SSTU?  (As that feature has been removed entirely in recent versions)

Basically it was a time constraint (and I hate stock part graphics).  Why spend time adding support for parts/models that I actively dislike?  (also, in my games, the stock parts are often deleted entirely, so there isn't even an option to use the stock parts/models).

[Starwaster]

6 minutes ago, Shadowmage said:

I'm guessing you are talking about the KSP 1.2+ versions of SSTU?  (As that feature has been removed entirely in recent versions)

Basically it was a time constraint (and I hate stock part graphics).  Why spend time adding support for parts/models that I actively dislike?  (also, in my games, the stock parts are often deleted entirely, so there isn't even an option to use the stock parts/models).

I hadn't noticed it was absent from the 1.3.* versions... probably because when I'm running 1.3 It's usually for developmental purposes

[chrisl]

Have you ever considered adding a slider or something that would allow a fuel tank to have it's center of mass adjusted?  I'm working on a Space Shuttle using the Series-E parts and got around to the external tank.  If I used a single tank of the appropriate height and diameter, and set it to have the appropriate amount of LOX/LH2 (or LiquidFuel + Oxidizer), the CoM of just the tank is about halfway up the tank.  But on the actual space shuttle external tank, the CoM was actually closer to 3/4ths of the way up because the LOX was held in the top third of the tank.  Only way I can recreate that is to actually use two different tanks: one for the LOX and one for the LH2. 

[Cheesecake]

1 hour ago, chrisl said:

Have you ever considered adding a slider or something that would allow a fuel tank to have it's center of mass adjusted?  I'm working on a Space Shuttle using the Series-E parts and got around to the external tank.  If I used a single tank of the appropriate height and diameter, and set it to have the appropriate amount of LOX/LH2 (or LiquidFuel + Oxidizer), the CoM of just the tank is about halfway up the tank.  But on the actual space shuttle external tank, the CoM was actually closer to 3/4ths of the way up because the LOX was held in the top third of the tank.  Only way I can recreate that is to actually use two different tanks: one for the LOX and one for the LH2. 

I think the center of mass results of the masses of the tank and fuel. Have you ever seen a slider in real rockets? You can use two tanks like in real, one LOX and one LH2 or two LOX/LH2 tanks. That should work.

[Starwaster]

19 hours ago, Cheesecake said:

I think the center of mass results of the masses of the tank and fuel. Have you ever seen a slider in real rockets? You can use two tanks like in real, one LOX and one LH2 or two LOX/LH2 tanks. That should work.

His point is that he's trying to avoid using multiple parts....  

[OverlordMorgoth]

I have been using for a while now but have been looking into the logs for some other issues and noticed something: There seems to be a lot of 'Textures Not Found' with this mod, nothing critical and only adds a second or so to the loading process, but have the heads up.
Something more applied: I have built a big ship using using the a Re-Entry capsule just to notice a few days into the flight (when mechjeb ran out of electricity) that the capsule has no control capability and that my pilot was a bit useless.

[Shadowmage]

5 minutes ago, OverlordMorgoth said:

I have been using for a while now but have been looking into the logs for some other issues and noticed something: There seems to be a lot of 'Textures Not Found' with this mod, nothing critical and only adds a second or so to the loading process, but have the heads up.

Yep.  KSP PartTools embeds the path and name of the texture into the model (.mu) file that were present when the model was exported.  I have long since updated/changed most of the textures in the mod, but cannot 'fix' the existing model files (binary file, very difficult to fix).  There is no option without using the Unity Editor to re-export the models; but as most of those models don't exist in my current Unity project, it would be hours  of work to find the original .blend files, re-export .fbx, and re-setup all the stuff in the Unity Editor.  Worse yet, some of those original .blend files simply don't exist anymore, so for some of the models... there is zero option to fix them.

And really, it doesn't matter.  I just go and replace all of those textures/materials/shaders anyway as soon as the models are loaded.  Recent models are exported without any textures just to prevent those exact error messages.  Sadly, nothing can be done about the existing/legacy models.  Those 'error' messages will continue to exist probably until the end of time (or until such a time as there is a tool to allow for editing of existing .mu model files).

 

9 minutes ago, OverlordMorgoth said:

Something more applied: I have built a big ship using using the a Re-Entry capsule just to notice a few days into the flight (when mechjeb ran out of electricity) that the capsule has no control capability and that my pilot was a bit useless.

Which part are you referring to?  I don't have any 'Re-Entry' capsule parts that I'm aware of... (but you are likely referring to one of the ShipCore pod parts?)

[OverlordMorgoth]

18 minutes ago, Shadowmage said:

Which part are you referring to?  I don't have any 'Re-Entry' capsule parts that I'm aware of...

SSTU - SC - B - CM Re-Entry Module is its full name.

[Shadowmage]

1 minute ago, OverlordMorgoth said:

SSTU - SC - B - CM Re-Entry Module is its full name.

Thanks for the confirmation/clarification on the part name.

I think this is one of those cases where I can have an either and an or but not both (a limitation of the stock modules/code).  You can have either the part be allowed to be controlled without a pilot (remotely piloted probe core).  Or you can mandate that a pilot is needed for control.  I don' think you can have it both ways....

So basically, in order to allow it to function unmanned, it has to have an 'unmanned' probe core setup.  No EC = no control.  If I change it to allow manual control (without EC), it will always require a crew, and thus be unusable in an uncrewed capacity.

 

Actually, I think it comes down to this block (more precisely, the RESOURCE subnode):

MODULE
{
	name = ModuleCommand
	minimumCrew = 0
	hasHibernation = True
	RESOURCE
	{
		name = ElectricCharge
		rate = 0.0275
	}
}

 

Basically I can have it use EC, or not.  There is no 'don't require EC if crew is present' flag in the stock ModuleCommand.  Now, this is unfortunate in the case of the SC-A and SC-B parts, as they were, to at least some degree, controllable directly by the pilot (whether or not the analog controls would function without electricity is another debate).

But it is also logical.  What would happen if the Apollo CM completely lost electricity?  Probably complete loss of mission.  And on the more recent craft (Orion), the entire system is computerized.  No electricity = no control.

 

If anyone knows of other mods' command pods that allow both unmanned (with EC) and unmanned (without EC) use, please advise and I'll take a look over their configs to see if this is a problem I can solve.  Currently I'm pretty sure this is a limitation of the stock modules that is out of my control.

[Starwaster]

3 hours ago, Shadowmage said:

If anyone knows of other mods' command pods that allow both unmanned (with EC) and unmanned (without EC) use, please advise and I'll take a look over their configs to see if this is a problem I can solve.  Currently I'm pretty sure this is a limitation of the stock modules that is out of my control.

Essentially correct, except that it's minimumCrew that determines whether the control state is probe or crew. (not sure if pilot skill is counted or not... yeah it is)

If resource is specified then the part can't be used for control if the resource is exhausted no matter whether it is set to be crew controlled or probe controlled. (which as you say is really how it should be anyway. No electricity = dead in the water)

Edited January 31, 2018 by Starwaster

[Dermeister]

WHat does hollow collider do on the custom decoupler in this mod? I tried it off and on but the game still seems to think that it's colliding with something. Is it suppose to simulate  a hollow donut when you make it in a donut shape? Should I turn it off or on if I want objects to sit through it?

[OverlordMorgoth]

12 hours ago, Starwaster said:

which as you say is really how it should be anyway. No electricity = dead in the water

That makes sense but no comms+skilled pilot != dead in the water.

[Shadowmage]

1 hour ago, OverlordMorgoth said:

That makes sense but no comms+skilled pilot != dead in the water.

Sadly, the stock code/modules have limitations.  I don't think I can make it so that it works properly in both situations (manned + unmanned) in all full and partial failure situations.

 

Basically I can set it up as per the stock crewed capsules -- entirely crew controlled, zero ability to use unmanned or I can set it up with an unmanned probe core (requires EC, commnet) to allow for uncrewed flights.

I personally would much rather have proper probe-core / unmanned control.  Now, if someone else is aware of a method to setup that module such that it works both ways -- please let me know. 

 

About the only thing that I might be able to change is to make it so the probe core doesn't require commnet.  But I don't think that is a valid solution, because then commnet is essentially useless; might as well disable the feature entirely as you'll never need antennas/connection outside of science transmission.

 

My personal setup?  Probe core + pilot + use mechjeb when out of commnet range.  Sure, you can't manually spin the ship around... but 95% of what I need to do can be accomplished through the MJ prograde/radial/normal/target hold modes.  A bit more difficult to overcome is the inability to use RCS/engine throttle, but I think I've only been in that situation like maybe once (which was by accident/poor planning) -- good mission design and planning (relay sats...) entirely eliminates the possibility of losing commnet connection.

[Starwaster]

4 hours ago, OverlordMorgoth said:

That makes sense but no comms+skilled pilot != dead in the water.

Not an issue of comms, the part either requires resources to be usable as a control point or it doesn't. Or... do you mean IRL? Because IRL, it would definitely be dead in the water  

3 hours ago, Shadowmage said:

Sadly, the stock code/modules have limitations.  I don't think I can make it so that it works properly in both situations (manned + unmanned) in all full and partial failure situations.

Basically I can set it up as per the stock crewed capsules -- entirely crew controlled, zero ability to use unmanned or I can set it up with an unmanned probe core (requires EC, commnet) to allow for uncrewed flights.

I personally would much rather have proper probe-core / unmanned control.  Now, if someone else is aware of a method to setup that module such that it works both ways -- please let me know. 

Add two ModuleCommand modules. One configured the way you would configure a command module (crew req, no power req) and the other as a probe (no crew req, power req)

It will work. I can't say for sure it might not cause some weird issue but no moreso than having MJ on a command part alongside the stock command code.

You MIGHT have to add the crewed portion after the probe portion... but I think it will work the same regardless. But probe section then crewed section in the config did work. I tried it.

Edited January 31, 2018 by Starwaster

[Shadowmage]

2 hours ago, Starwaster said:

But probe section then crewed section in the config did work. I tried it.

Does it have any side effects?  E.g. multiple 'control from here' buttons or 'rename craft' buttons?

[Starwaster]

4 hours ago, Shadowmage said:

Does it have any side effects?  E.g. multiple 'control from here' buttons or 'rename craft' buttons?

It does duplicate those buttons.

[Jimbodiah]

If you add a seperate radial or inline probe core to the pod, the problem is gone.

Maybe the pods could be reverted to need a crew member (SAS level 2)  and add a small radially attached probecore part to SSTU that will add the autonomous functionality (SAS 3). Best of both worlds, but at the cost of one extra part. If you make it small and non obtrusive, you can make it look like it belongs on the pod, especially with the recoloring now. i.e. You could use a 50% scaled down stock radial drogue chute as the model for the time being.

Edited February 1, 2018 by Jimbodiah

[Starwaster]

1 hour ago, Jimbodiah said:

If you add a seperate radial or inline probe core to the pod, the problem is gone.

Maybe the pods could be reverted to need a crew member (SAS level 2)  and add a small radially attached probecore part to SSTU that will add the autonomous functionality (SAS 3). Best of both worlds, but at the cost of one extra part. If you make it small and non obtrusive, you can make it look like it belongs on the pod, especially with the recoloring now. i.e. You could use a 50% scaled down stock radial drogue chute as the model for the time being.

That's what I do with my rescue ship for those rescue contracts you get spammed with in early Career. Except that I used the SSTU stackable probe core, wafer thin, between my Mk1 pod's decoupler and the engine. Made it nice and shiny (finally switched over to 1.3.1), send it up empty and rendezvous with the stranded Kerbal. (love how they get up to orbit before I even get done launching the first space traveler. 

[Jimbodiah]

I use those as well, but when you use the service modules it's not really an option.