Jump to content

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


Shadowmage

Recommended Posts

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.... :wink: 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Starwaster
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :wink: 

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 by Starwaster
Link to comment
Share on other sites

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 by Jimbodiah
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...