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

[Jimbodiah]

2 hours ago, Nightside said:

also delete your MM cache file when you are doing this kind of troubleshooting 

Also delete the PartDatabase.cfg file when installing new mods or updates.

[tater]

Thought this might be interesting for people messing with more historical color schemes.

[Teslamax]

On 7/19/2018 at 5:24 PM, Shadowmage said:

Thanks for the report and confirmation.  If you could please open a GitHub issues ticket with the relevant details, along with the steps necessary to trigger the issue, I will do my best to get it fixed for the next release.

Done!

The negative mass on "SSTU - TANK - MUS" is triggered by enabling the solar panels. Doing so subtracts 2,499 kg from the part.

[Shadowmage]

10 hours ago, Teslamax said:

Done!

The negative mass on "SSTU - TANK - MUS" is triggered by enabling the solar panels. Doing so subtracts 2,499 kg from the part.

Thanks for the report.

Have found and fixed the plugin and config errors for that one, and it should be available with the next release (or if you know how to use Git, it is available in the dev branch now).

[vossiewulf]

Back playing a bit, I of course downloaded the SSTU-PBR but I get no SSTU in game. It's sitting there in my Gamedata folder, SSTU-PBR, but no parts show up in game. This is 1.44 x64, using CKAN this time for basic mod management but I've installed quite a few that they don't have with no issues, just copy into Gamedata, wipe hands. Only SSTU is having a problem as far as I know. What stupid thing am I doing?

[Shadowmage]

16 hours ago, vossiewulf said:

Back playing a bit, I of course downloaded the SSTU-PBR but I get no SSTU in game. It's sitting there in my Gamedata folder, SSTU-PBR, but no parts show up in game. This is 1.44 x64, using CKAN this time for basic mod management but I've installed quite a few that they don't have with no issues, just copy into Gamedata, wipe hands. Only SSTU is having a problem as far as I know. What stupid thing am I doing?

Could I get a screenshot / list of folders within your GameData folder?  Likely culprit is missing dependencies or incorrect installation.

[vossiewulf]

6 hours ago, Shadowmage said:

Could I get a screenshot / list of folders within your GameData folder?  Likely culprit is missing dependencies or incorrect installation.

Thanks. Only dependency I remember seeing was KSPWheel for one of the parts.

[Teslamax]

23 hours ago, vossiewulf said:

Back playing a bit, I of course downloaded the SSTU-PBR but I get no SSTU in game. It's sitting there in my Gamedata folder, SSTU-PBR, but no parts show up in game. This is 1.44 x64, using CKAN this time for basic mod management but I've installed quite a few that they don't have with no issues, just copy into Gamedata, wipe hands. Only SSTU is having a problem as far as I know. What stupid thing am I doing?

Did you install "SSTU" along with "SSTU-PBR"?

SSTU	parts pack	required
SSTU-PBR	implements Textures Unlimited's shaders	optional

 

download link

Edited July 25, 2018 by Teslamax

[vossiewulf]

4 hours ago, Teslamax said:

Did you install "SSTU" along with "SSTU-PBR"?

SSTU	parts pack	required
SSTU-PBR	implements Textures Unlimited's shaders	optional

 

download link

[Firemahn]

I read back in May there was issues with solar panels not being recognized as a stock panel. I wonder if this is still an issue for background processing mods like kerbalism and TAC? I seem to have no perpetual power with panels on a ship, and will have depleted batteries unless focus is on the ship? Is this from the other modder side, or would SSTU need to be implemented into it? Thanks shadowmage- you're still my hero

[Shadowmage]

On 7/25/2018 at 6:00 PM, Firemahn said:

Is this from the other modder side, or would SSTU need to be implemented into it? Thanks shadowmage- you're still my hero

Nothing that I can do regarding incompatibilities in other people's mods.  I.E.  - any fix will have to come from the other mods' side.  I already implement all of the stock interfaces that are available; but everyone feels that it is appropriate to hard-code for specific classes rather than find some generic implementation.  Thus, as my classes are not the ones they have hard-coded for, there is no compatibility.

(The root cause is that the stock API does not have a sufficient attribute/tagging system for PartModules; there is no way to say 'this part-module generates EC' or 'this part-module is an engine')

[vossiewulf]

Mage, this seems unlikely but I'm scratching my head otherwise, is there some problem with the DP-1 docking port? I'm building a station with DOS parts, first part is a DOS COM unit with a 2.5m hub on one end and a separate (so I could have the probe core inline without losing a docking node) HUB DOS 1.25m hub on the other, the latter covered with DP-1s. I put clamp-o-tron senior ports on the 2.5m hub, and first thing added was a 3.75m LFO tank that I docked first try at one of the clamp-o-trons.

Next however is a DOS PWR with an added SSTU 1.25m docking port on a 3-2 long end. I think it's 3-2, whichever is 1.25m. Anyway, I spent an hour bouncing that guy off of all the docking ports on the 1.25m hub, then broke out MJ's docking autopilot and watched him bounce off the 1.25m hub over and over. I went back to the VAB to check the PWR, I see no issue with the 1.25m port I added, and there's no configuration AFAIK of the 1.25m hub.

So I decided maybe it was a problem with the HUB DOS, but I reset the DP-1 port on the PWR to be certain nothing was amiss. Since I'd attached the HUB DOS to the COM with docking ports, I was able to quickly detach it to expose the COM's DP-1. I then spent 30 min bouncing off it, at several extended times the magnet power had them locked face to face, sitting there looking like they were docked but never docking.

I don't remember having this problem with the DP-1 in the past, I used it extensively in the big space station I built (upthread someplace).

Edited August 1, 2018 by vossiewulf

[vossiewulf]

Doesn't appear to be me, I switched over to some Contares andro ports and had no trouble docking. 

[Shadowmage]

@vossiewulf You may need to enable the 'angle snap' on the ports.  IIRC there may be an issue where they refuse to dock unless it is enabled.

(if that is the case, please let me know and/or open an issue ticket so that I can remember to get it cleaned up)

[vossiewulf]

1 hour ago, Shadowmage said:

@vossiewulf You may need to enable the 'angle snap' on the ports.  IIRC there may be an issue where they refuse to dock unless it is enabled.

(if that is the case, please let me know and/or open an issue ticket so that I can remember to get it cleaned up)

Unfortunately I tried it both with it on and off and it seemed to make no difference. I had it on for the entire last round of futile attempts.

[Shadowmage]

5 hours ago, vossiewulf said:

Unfortunately I tried it both with it on and off and it seemed to make no difference. I had it on for the entire last round of futile attempts.

Thanks for the confirmation and info.  I've opened an issue ticket on it, and will investigate a fix for the next release (hopefully this weekend, or next, depending on if some of the craziness at work clears up).

https://github.com/shadowmage45/SSTULabs/issues/729

[vossiewulf]

7 hours ago, Shadowmage said:

Thanks for the confirmation and info.  I've opened an issue ticket on it, and will investigate a fix for the next release (hopefully this weekend, or next, depending on if some of the craziness at work clears up).

https://github.com/shadowmage45/SSTULabs/issues/729

Thanks. While you're at it can you please fix the RCS on the DOS units? They're my favorite-looking station parts but their RCS is pretty wacky on a couple of them such that they cause PIOs (Pilot-Induced Oscillations) in MJ's docking autopilot and so must be docked manually, and they ain't easy to dock manually because of the torque. But we get there eventually.

 

[GabeD416]

On 5/30/2018 at 9:10 PM, Shadowmage said:

Good news/bad news....

The bad is that I could not manage to salvage any sort of particle-effects scaling for stock particle effects.  In fact stock now seems to have some sort of built-in inverse scaling that makes the problem even worse.  Previously they merely scaled poorly; now they look quite terrible on any sort of scaled engine.  Last I looked the stock particle system lacked any sort of 'scale' or 'size' control at the config-node level, so this may be something that I cannot solve.  With the recent change in particle systems, and the upcoming changes in 1.4.4, scale/size may be exposed to some degree; will re-address this issue after 1.4.4 is released.

The good news is that the effect scaling works perhaps better than ever for RealPlume derived effects (or anything using SmokeScreen).

At this point it is only config-level cleanup that needs to happen in order for packaged testing releases.  Will likely be in 'test release' mode for a couple of weeks while bugs are cleaned up and balance issues addressed, but I think we can finally say that releases will be 'Soon'

Hey what mod is that command pod from?

[Shadowmage]

9 minutes ago, GabeD416 said:

Hey what mod is that command pod from?

None; that is the new stock MK-whatever pod (3-kerbal, 2.5m) that was released with the Making History expansion.  I believe it is part of the base game though, so everyone should have it.

[GabeD416]

3 minutes ago, Shadowmage said:

None; that is the new stock MK-whatever pod (3-kerbal, 2.5m) that was released with the Making History expansion.  I believe it is part of the base game though, so everyone should have it.

Ah okay that makes sense, I'm still stuck on 1.3 for mod reasons. 

[Qwarkk]

Has the ability to enable / disable crossfeed on SSTU decouples been removed or am i having some mod conflicts?

 

[Kaa253]

I am building up the Series A (i.e. Soyuz) and I find that the RD-108A configured with the RD-108 mount seems to be fixed at diameter 1.4375 m. Is that how it should be? Using top 3:4 Short on the centre tank does come very close to standard 1.875 m. I don't see the old Soyuz style nose option for tanks so I presume they are deprecated now.

[Shadowmage]

7 hours ago, Kaa253 said:

I am building up the Series A (i.e. Soyuz) and I find that the RD-108A configured with the RD-108 mount seems to be fixed at diameter 1.4375 m. Is that how it should be? Using top 3:4 Short on the centre tank does come very close to standard 1.875 m. I don't see the old Soyuz style nose option for tanks so I presume they are deprecated now.

Yep; the core tank should be 1.4375m -- with the Soyuz style nose adapter present, that should bring the upper diameter of the core to 1.875m.

The nose option should be available for the MFT-A tank, but it might be listed in the UPPER options rather than NOSE....  (if it is not available.... then something went sideways with the recent releases, as I explicitly added it for the last update)

On 8/5/2018 at 12:11 PM, Qwarkk said:

Has the ability to enable / disable crossfeed on SSTU decouples been removed or am i having some mod conflicts?

 

Not removed to my knowledge.... it was a stock feature though.... so who knows what may be going on with it.

Were there any config changes to the parts that you are having issues with in any of the recent SSTU releases?

[Tonas1997]

Quick question: I included this mod on a RSS modpack and the engines seem to be balanced for the stock scale (e.g. the F-1 is heavier and produces about half of the real-life thrust). Are the engines supposed to be accurate to their real-life counterparts, or should I get the appropriate RF/RO configs?

[Shadowmage]

15 minutes ago, Tonas1997 said:

Quick question: I included this mod on a RSS modpack and the engines seem to be balanced for the stock scale (e.g. the F-1 is heavier and produces about half of the real-life thrust). Are the engines supposed to be accurate to their real-life counterparts, or should I get the appropriate RF/RO configs?

All parts in the mods' default configuration are for Stock solar system (scales, thrusts, TWR).

RO used to include a set of patches to adjust the engines for their real-world performance stats, but as I am not involved in RO/etc, I have no idea how up to date or maintained it is.

To answer your question -- yes you will want to find/make some patches to adjust the engines for decent performance in an RSS setup.