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

[Shadowmage]

15 minutes ago, drhay53 said:

Is this not there on the welding ports? I don't see it. I could take a screenshot but take my word for it....

No, that is not present on the welded docking ports.  AFAIK they don't have the same bug as the regular ones.  What you are encountering is likely their normal behaviour involving 'soft-dock'.

1.) Create and launch two craft with welded docking ports on them.  Make sure both ports are set to 'Extended'.
2.) RV the two craft.  When the ports are extended, they will not dock (only soft-dock).  Use this to position your craft/line up rotation/whatever while the magnet holds you in place.
3.) Press the 'Enable' (or 'Retract', or 'Arm' or W/E I called it) button on BOTH docking ports.  They will now hard-dock, and your two craft should merge into one.
4.) Once the ports have docked to each-other, right click on one of them (either one, doesn't matter), and press the 'Weld' button.  Both docking ports will disappear/be removed from the craft, leaving the parts that were attached to the ports being attached to eachother ('welded' as it were).

If the above is not working -- you have likely installed one or both ports on the craft backwards.  Please show screenshots if that is the case.

15 minutes ago, drhay53 said:

But the user above says they won't dock if either is extended.

Yes -- in order to dock they need to be RETRACTED.  The extension ring and action is to force a 'soft-dock' to allow the player to position/orient things before it all becomes permanent.  As the ring is RETRACTED, the docking ports come closer together until they eventually dock.

(don't be fooled by the name 'RETRACT' as compared to other KSP animations -- the 'RETRACT' animation is in fact part of a 'deploy sequence' is it were; but as it is visibly retracting something, I named it as such)

Edited September 20, 2018 by Shadowmage

[drhay53]

8 minutes ago, Shadowmage said:

No, that is not present on the welded docking ports.  AFAIK they don't have the same bug as the regular ones.  What you are encountering is likely their normal behaviour involving 'soft-dock'.

1.) Create and launch two craft with welded docking ports on them.  Make sure both ports are set to 'Extended'.
2.) RV the two craft.  When the ports are extended, they will not dock (only soft-dock).  Use this to position your craft/line up rotation/whatever while the magnet holds you in place.
3.) Press the 'Enable' (or 'Retract', or 'Arm' or W/E I called it) button on BOTH docking ports.  They will now hard-dock, and your two craft should merge into one.
4.) Once the ports have docked to each-other, right click on one of them (either one, doesn't matter), and press the 'Weld' button.  Both docking ports will disappear/be removed from the craft, leaving the parts that were attached to the ports being attached to eachother ('welded' as it were).

If the above is not working -- you have likely installed one or both ports on the craft backwards.  Please show screenshots if that is the case.

Yes -- in order to dock they need to be RETRACTED.  The extension ring and action is to force a 'soft-dock' to allow the player to position/orient things before it all becomes permanent.  As the ring is RETRACTED, the docking ports come closer together until they eventually dock.

(don't be fooled by the name 'RETRACT' as compared to other KSP animations -- the 'RETRACT' animation is in fact part of a 'deploy sequence' is it were; but as it is visibly retracting something, I named it as such)

Ok, this was how I initially did it. They never "attach" and the weld button never shows up. I will try to capture video of the process.

[Starwaster]

56 minutes ago, drhay53 said:

Is this not there on the welding ports? I don't see it. I could take a screenshot but take my word for it....

All I see is a SnapAngle slider.

Just to clarify; for the welding ports are you supposed to dock with them extended and disarmed or retracted and armed? The part description says "Dock two of these together, retract the push-rings, and press the 'Weld' button for a permanent station construction alternative." But the user above says they won't dock if either is extended.

They HAVE to be retracted before they dock. Either because you retract them after they have been magnetically pulled together or because you keep them retracted while docking. (I prefer to just leave them retracted)

Edited September 20, 2018 by Starwaster

[drhay53]

Here's a video: sorry the quality is a little crappy, my GeForce experience isn't working for some reason and I had to capture with windows game mode

 

Edited September 20, 2018 by drhay53

[Starwaster]

24 minutes ago, drhay53 said:

Here's a video: sorry the quality is a little crappy, my GeForce experience isn't working for some reason and I had to capture with windows game mode

 

They're not making proper physical contact. What it LOOKS like (I could be wrong, it's hard to see) is that the other four ports are in the way. Either way though, it looks like there is a significant gap.

[drhay53]

4 minutes ago, Starwaster said:

They're not making proper physical contact. What it LOOKS like (I could be wrong, it's hard to see) is that the other four ports are in the way. Either way though, it looks like there is a significant gap.

Ok I guess I will try to get rid of the side ports. I was hoping to build the whole station modularly with the welding ports around the little hub at the end of that DOS module. I do see now that the second retracting port kind of stops pulling them together at some point. 

I can perhaps add them back after welding with kas/kis if that works. Will work on it tonight after the kid goes to bed.

Edited September 20, 2018 by drhay53

[Starwaster]

16 minutes ago, drhay53 said:

Ok I guess I will try to get rid of the side ports. I was hoping to build the whole station modularly with the welding ports around the little hub at the end of that DOS module. I do see now that the second retracting port kind of stops pulling them together at some point. 

I can perhaps add them back after welding with kas/kis if that works. Will work on it tonight after the kid goes to bed.

The welding ports can be resized, even lower than their default. I'm working on reproducing this AND solving it via resizing. I think that should work. Going to try 1m instead of 1.25m

[Starwaster]

@drhay53 I resized the welding ports to 1m and successfully achieved docking. One caveat there is that the ports are recessed so far into the station part that you have to shift the camera inside to be able to access the port for welding after docking. Not a big deal though IMO

Also, I had to test under KSP 1.3.1 with the corresponding version of SSTU but that shouldn't really matter since it was just a collision issue. It should work exactly the same for 1.4.5

Edited September 21, 2018 by Starwaster

[drhay53]

Just now, Starwaster said:

@drhay53 I resized the welding ports to 1m and successfully achieved docking. One caveat there is that the ports are recessed so far into the station part that you have to shift the camera inside to be able to access the port for welding after docking. Not a big deal though IMO

Ok thanks. Chalk this one up to "user error" and not an addition to the other bug with docking ports then

Based on how I'm trying to manage this career, I'm going to try to fix it in-place by removing the ports on EVA and getting it put back together. If that fails, I know that I can fall back on rebuilding with smaller ports.

[Starwaster]

5 minutes ago, drhay53 said:

Ok thanks. Chalk this one up to "user error" and not an addition to the other bug with docking ports then

Based on how I'm trying to manage this career, I'm going to try to fix it in-place by removing the ports on EVA and getting it put back together. If that fails, I know that I can fall back on rebuilding with smaller ports.

If you're up for it, you could edit the craft in the save file and change the port diameter there. If you're comfortable doing such a thing...

[drhay53]

Just now, Starwaster said:

If you're up for it, you could edit the craft in the save file and change the port diameter there. If you're comfortable doing such a thing...

I usually don't muck around in the save file anyway, but I'm trying to play this save by fixing things I mess up instead of reverting or hyperediting or otherwise hacking. I always tend to get bored in my saves more quickly than I'd like so I'm just trying to do something a little different. I also tend to get annoyed with KSP performance issues after getting a few stations/bases out and then I just quit. Don't think I've ever managed to play long enough to fully colonize another planet outside of Kerbin's SOI. 

Anyway, I'll figure it out some way. Thanks for taking the time to help debug and offer solutions.

[drhay53]

Ok, I have successfully docked, but now there's no 'weld' button. Any ideas? Is this a 'root part' issue that I remember used to show up with the USI Konstruction welding ports?

[drhay53]

53 minutes ago, drhay53 said:

Ok, I have successfully docked, but now there's no 'weld' button. Any ideas? Is this a 'root part' issue that I remember used to show up with the USI Konstruction welding ports?

Ok, I undocked and then docked with snap enabled and then the weld button showed up. Weird.

[drhay53]

Ok I don't know if this will help you debug the reverting of settings or not; I have a launch vehicle that's an SC-B re-entry capsule, an MUS with an RL10A-3, an MFT-A and an RD-181, with some SSTU-GEN-MRCS on the MFT-A for attitude control on ascent. I added some hypergolic to the MFT-A. 

I would like to add monoprop to the MUS so I can use the fuel cell. I click configure containers, I go to the secondary tank, I replace hypergolic with monoprop , and when I go to the launch pad, the MUS is back to hypergolic. If I right click on the MUS in the editor and change the RCS fuel via the slider in the right-click menu,  I have my desired monoprop in the MUS; it is not reset to hypergolic when entering the flight scene.

I am seeing this error in the logs in both cases; not sure if related. Otherwise I see nothing suspicious in the log.

Quote

[LOG 22:57:09.141] ERROR: Config is for part: SSTU-GEN-MRCS (Part) is set to use RF/MFT, but neither RF nor MFT is installed, cannot update part volumes through them.  Please check your configs and/or patches for errors.
[LOG 22:57:09.141] ERROR: Config is for part: SSTU-GEN-MRCS (Part) is set to use RF/MFT, but neither RF nor MFT is installed, cannot update part volumes through them.  Please check your configs and/or patches for errors.
[LOG 22:57:09.142] ERROR: Config is for part: SSTU-GEN-MRCS (Part) is set to use RF/MFT, but neither RF nor MFT is installed, cannot update part volumes through them.  Please check your configs and/or patches for errors.
[LOG 22:57:09.142] ERROR: Config is for part: SSTU-GEN-MRCS (Part) is set to use RF/MFT, but neither RF nor MFT is installed, cannot update part volumes through them.  Please check your configs and/or patches for errors.
[LOG 22:57:09.142] ERROR: Config is for part: SSTU-GEN-MRCS (Part) is set to use RF/MFT, but neither RF nor MFT is installed, cannot update part volumes through them.  Please check your configs and/or patches for errors.
[LOG 22:57:09.142] ERROR: Config is for part: SSTU-GEN-MRCS (Part) is set to use RF/MFT, but neither RF nor MFT is installed, cannot update part volumes through them.  Please check your configs and/or patches for errors.
[LOG 22:57:09.142] ERROR: Config is for part: SSTU-GEN-MRCS (Part) is set to use RF/MFT, but neither RF nor MFT is installed, cannot update part volumes through them.  Please check your configs and/or patches for errors.
[LOG 22:57:09.143] ERROR: Config is for part: SSTU-GEN-MRCS (Part) is set to use RF/MFT, but neither RF nor MFT is installed, cannot update part volumes through them.  Please check your configs and/or patches for errors.

 

Edited September 21, 2018 by drhay53
clarity

[Shadowmage]

10 hours ago, drhay53 said:

I am seeing this error in the logs in both cases; not sure if related. Otherwise I see nothing suspicious in the log.

Do you have either RealFuels or ModularFuelTanks (the mod) installed?  Or patches that might make it look as if it were installed?

[drhay53]

2 hours ago, Shadowmage said:

Do you have either RealFuels or ModularFuelTanks (the mod) installed?  Or patches that might make it look as if it were installed?

I don’t have either of those installed unless MFT is a dependency for something... It’s also possible there’s a patch in there somewhere but I’m not sure what to even look for. I have a moderate-sized modlist installed. I will check for you tonight.

I just thought it was weird that the behavior of the monoprop was different depending on which way I  put it in the tank. Since you were asking for help in identifying issues related to settings reverting, I wanted to include this in case it was helpful. I’ll do my due diligence in investigating your question.... hope it’s not a mod conflict issue, I really hate bugging busy people when it turns out to be something like that. 

[drhay53]

9 hours ago, Shadowmage said:

Do you have either RealFuels or ModularFuelTanks (the mod) installed?  Or patches that might make it look as if it were installed?

In Kerbal Planetary Base Systems there is a Configs folder where individual MM patches are in individual folders, one of which is called ModularFuelTanks. Do you think that could be causing it? I can remove the folder and try testing things but I won't be able to get to that for an hour or two.

[Shadowmage]

48 minutes ago, drhay53 said:

In Kerbal Planetary Base Systems there is a Configs folder where individual MM patches are in individual folders, one of which is called ModularFuelTanks. Do you think that could be causing it? I can remove the folder and try testing things but I won't be able to get to that for an hour or two.

It might if they had some strange errors in them; though I would think the chance is minimal.  Probably worth a quick try though.

I seem to remember having some questions on SSTU's legacy MFT/RF integration code last time I looked at it, so it may be that there was something wrong with it that didn't get fixed at the time (occasionally I'll spot a problem while fixing something else, and fail to take note of it properly).  I'll have to take a look at the MRCS part in particular and how it is using the fuel updating code, as there may be something strange going on there.... (why is MRCS even calling code that would need MFT/RF installed?  IDK... but I'll be taking a look at it soon).

I've opened an issue ticket on this so it doesn't get forgotten about (again): https://github.com/shadowmage45/SSTULabs/issues/741    Will take a look at it before I wrap things up for this weekends' release (yes, I finally have enough progress done to warrant one ).

[drhay53]

35 minutes ago, Shadowmage said:

It might if they had some strange errors in them; though I would think the chance is minimal.  Probably worth a quick try though.

I seem to remember having some questions on SSTU's legacy MFT/RF integration code last time I looked at it, so it may be that there was something wrong with it that didn't get fixed at the time (occasionally I'll spot a problem while fixing something else, and fail to take note of it properly).  I'll have to take a look at the MRCS part in particular and how it is using the fuel updating code, as there may be something strange going on there.... (why is MRCS even calling code that would need MFT/RF installed?  IDK... but I'll be taking a look at it soon).

I've opened an issue ticket on this so it doesn't get forgotten about (again): https://github.com/shadowmage45/SSTULabs/issues/741    Will take a look at it before I wrap things up for this weekends' release (yes, I finally have enough progress done to warrant one ).

Renamed the folder and still see the error...technically it looks like an info message that starts with ERROR, but who's paying attention

[RedParadize]

Hi @Shadowmage 

I have been thinking about adding subcooled type of tank. Its mainly for aesthetical reason, but I trough that I could implement it trough SSTU_CONTAINERTYPE. Basically what I would like to do is to artificially increase the volume (and raise activeECCost and boiloffModifier like crazy). There is no volumeModifier field in the other container... Is there any way to do that?

edit: If thats not possible, I could still add a subcooled type (SubcooledHydrogen etc...) and add a always on converter that change it back to non-subcooled...

Edited September 22, 2018 by RedParadize

[Shadowmage]

10 hours ago, RedParadize said:

There is no volumeModifier field in the other container... Is there any way to do that?

Actually... there is.  Named exactly that.... I've just never used it like that because volume is one of those hard to get around physical properties.  The only place I use it is to zero out the available volume on the 'structural' tank type; but it will happily accept other values.  See below for a quick patch that should do about what you are looking for:

@PART[partNameHere]:FOR[yourPatchFakeModName]
{
	@MODULE[SSTUVolumeContainer]
	{
		@CONTAINER,0
		{
			//add the new modifier type to the target container
			//this should make it selectable in the container configuration GUI
			modifier = superChilled
		}
	}
}

//define the new container type, referenced above by the type's 'name' field
SSTU_CONTAINERTYPE
{
	name = superChilled
	title = Super Chilled Tank
	description = Cool your fuel to extreme temps to enable slightly higher densities in storage
	// acts as a direct multiplier onto the 'usable volume' after all 'tankageVolume' has been subtracted and use for tankage mass
	// supports floating point values, so anything from 0 -> 3.402e37 is within its valid multiplier range
	// a value of '2' DOUBLES the usable volume
	volumeModifier = 1.2
	tankageModifier = 1
	massModifier = 1.5
	impactModifier = 0.8
	heatModifier = 0.6
    costModifier = 2
	boiloffModifier = 1
	activeInsulationPercent = 1
	//triple the active cooling cost compared to standard ZBO?  maybe only 2x is needed...
	activeECCost = 3
	activeInsulationPrevention = 1
	inactiveInsulationPrevention = 0
	passiveInsulationPrevention = 0
	//unlockName = //leaving blank so as to always have it available
}

 

[RedParadize]

Thanks @Shadowmage I even like the description! 

Edit: looks like available volume wont go over total volume. It make sense I guess. Is there a totalVolumeModifier too? 

Edited September 22, 2018 by RedParadize

[drhay53]

I've been trying for the last 2 hours to get the "Weld" button to show up on two welding ports that I've been docking over and over. Is there anyone who has insight into how to get it to actually show up?

[T-10a]

On a side note @Shadowmage (pinging here while my Github account is having issues), I've noticed that the issue for custom tanks not saving properly happens only when I do "unusual" diameters (say, 0.9375m) that aren't selectable with the arrow buttons, while "normal" diameters (like 1.25m) save properly without issues. Strangely enough, this also happens in a similar manner with the procedural upper stages, but for those it inexplicably switches the tank mode back to split tanks without adjusting diameter or length modifiers.

Edited September 23, 2018 by T-10a

[Shadowmage]

17 hours ago, drhay53 said:

I've been trying for the last 2 hours to get the "Weld" button to show up on two welding ports that I've been docking over and over. Is there anyone who has insight into how to get it to actually show up?

The only requirement in the plugin code for the weld button to show up is that there are two welded docking ports, docked to each-other.  It does not check the size, animation state, or anything else.

However, I just did some in-game testing, and the button was not showing up for me after docking, so obviously there is a bug regarding these that has popped up in one of the recent KSP versions, that has as-of-yet gone unreported.

I have opened an issue ticket regarding the problem, and you can track its status towards being fixed from there:  https://github.com/shadowmage45/SSTULabs/issues/742