Jump to content

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


Shadowmage

Recommended Posts

Yeah, the tech tree paradigm itself is not my favorite. I tend to prefer (since we're stuck with a tech tree) ETT because I think more paths is better, but I'm not totally happy with it, frankly. The reality is that most tech in KSP is nearly coincident in time. The first solar panel flew in 1958 on Vanguard 1. The first RTG flew in 1961.

Until there is enough variation in tech to justify multiple paths, it makes a redo of the tree kind of troublesome.

What I would want for engines as an example, would be to have paths based on the propellant. Want monoprop? Have a path for that. Kerlox path, Hydrolox path? Ditto. Costs would be set so that you'd have to think a little. Given the capability and low part count of SSTU, such a tree could easily make up for anything unbalanced due to the lower part requirements---sure, you get better rockets with a fraction of the tank parts, for example, but at a given point you might be only able to afford kerlox engines. The Soviet crew parts might be along a branch, so that if you invest in those, you might not get the Apollo/COS stuff until you get loads of points to spend...

Really it requires that you think of career play specifically in the SSTU world. Maybe I should try and make an SSTU tech tree...

Link to comment
Share on other sites

The debug menu in 1.1.3 has an R&D section that looks like it allows editing the tree, actually... or is that just for a particular play through?

So the tree is just a cfg file... I might mess around and see if I can make a novel tree in 1.1.3, then just test the cfg in 1.2.2.

Edited by tater
Link to comment
Share on other sites

In SSTU, whenever you deploy a *2-piece clamshell* fairing I get heavy fps drops. With a 3 piece clamshell I get less significant fps drops, and with the non-clamshell no significant fps drops.

Actually this has to do with how many *sections* I put on the fairing. And now that I've tested this with the stock fairing, I can say it is not SSTU's issue, but rather a squad issue.

Well lesson learned: too many sections(not sides) on a fairing cause fps drops.

Thanks for letting me blog this lol. I was trying build a rounded fairing ala Soyuz when I ran into this issue.

Link to comment
Share on other sites

Quote

In SSTU, whenever you deploy a *2-piece clamshell* fairing I get heavy fps drops. With a 3 piece clamshell I get less significant fps drops, and with the non-clamshell no significant fps drops.

Actually this has to do with how many *sections* I put on the fairing. And now that I've tested this with the stock fairing, I can say it is not SSTU's issue, but rather a squad issue.

Well lesson learned: too many sections(not sides) on a fairing cause fps drops.

Thanks for letting me blog this lol. I was trying build a rounded fairing ala Soyuz when I ran into this issue.

This is one of the reasons why Procedural Fairings is the be all end all for fairings, in my opinion.

 

There are a few limited situations where the stock style fairings are more advantageous, but they are very few and far between, again in my opinion.

EDIT: Yesterday it was showing I quoted @tenvelden today I was now quoting @tater's post... what the heck forums....

Edited by Akira_R
Link to comment
Share on other sites

On Wednesday, December 14, 2016 at 9:51 AM, Akira_R said:

This is the exact problem I always face when trying to set up a career game, from the sound of it what you want out of a tech tree is exactly what I want, ETT is way to much, stock is well stock, CTT just extends the tree and SETI is to restrictive/focused. I usually settle with CTT and spend weeks rearranging things until I get it in a state that I am ok with playing.

This annoying process is why I proposed this:

 

Looks like there might be something like that already available.  Was taking a look at the ETT tree / repo, and ran across this:  https://github.com/ProbusThrax/ETT/tree/master/KSPTechtreeEditor

Haven't downloaded it, don't really know what it does, but it appears to be a graphical tech-tree editor based on the libraries it uses and the name of the file :)

 

On Wednesday, December 14, 2016 at 10:10 AM, tater said:

Yeah, the tech tree paradigm itself is not my favorite. I tend to prefer (since we're stuck with a tech tree) ETT because I think more paths is better, but I'm not totally happy with it, frankly. The reality is that most tech in KSP is nearly coincident in time. The first solar panel flew in 1958 on Vanguard 1. The first RTG flew in 1961.

Until there is enough variation in tech to justify multiple paths, it makes a redo of the tree kind of troublesome.

[...]

That first paragraph pretty much sums up my problems with the KSP tech-tree.  Shouldn't need to progress through 1/2 or 2/3 of the tree for technologies that were already in use on some of the very first orbital rockets and probes; I consider those technologies to be prerequisites to even attempting anything beyond sounding rockets.  By the time you are ready to attempt orbit you should already have some form of power generation (not just batteries, or at least really big batteries) and information features (AP, time to AP, craft dV; all the info that is hidden or unavailable in stock).

But yeah, I haven't really been able to come up with a better organization for the tree either; though I haven't really spent too much time looking at it... could probably come up with something if I had to.

 

On Wednesday, December 14, 2016 at 10:25 AM, tater said:

The debug menu in 1.1.3 has an R&D section that looks like it allows editing the tree, actually... or is that just for a particular play through?

So the tree is just a cfg file... I might mess around and see if I can make a novel tree in 1.1.3, then just test the cfg in 1.2.2.

I -think- that debug tool can spit out completely filled-out tech tree config files.  I never actually got to use it, and sadly they removed all of those features in 1.2 with the new debug menu.

If you do come up with something, please let me know.  I would have no problems collaborating on a customized tech tree, though I think that CTT/ETT might be a good place to start from.  I think that ETT is probably closer to what I'm looking for (focused development branches), and seems to be what I'll be investigating this weekend.

 

 

Did a bit of early career playtesting the past few nights, comparing stock-only progression to progression including SSTU parts.  It seems that, for me, regardless of the parts available, the launches generally go (on stock 'normal' difficulty settings):
1.) First launch, grab science from on the pad and low atmo with a basic flea+pod+chute+goos.  Completes some contracts and world firsts.  Unlock tier1 nodes, possibly one of the tier2 as well.  This gets 1-2 more science experiments.
2.) Sub-orbital launch.  Grab science from high-atmo and low-space.  Pod+chute+goos+srbs+decouplers; can be done with 2x hammer and 1x flea.  Unlock tier2 nodes (~20s).
3.) Orbital launch.  Whether limited to stock parts or allowing use of SSTU parts, can make orbit with the third launch.
4.)  Herein lies the problem.  This should be a mun-flyby, but stock locks the maneuver nodes and conics behind some building upgrade.  Should have enough funds for them.  But also, even with science from launch#3, the best you will get here are some batteries; no chance of solar, fuel cell, etc, which I consider requisite for anything beyond very basic LKO missions.  Can be done with batteries alone, but it shouldn't need to be done that way, at least not with 100EC batteries (perhaps a 500 or 1k would be more suitable).  Ohh, good luck getting both the reaction wheel and batteries unlocked that you'll need...  (might be easier to just do it manned; no antenna needed, fewer batteries)
5.)  If you get #4 to work out (likely by using a toss-away probe transmitting a bit of science as it flies past the Mun), you -should- have enough tech and facilities at launch #5 to do a Mun orbit and return.  Barely.  Might need to upgrade the launch-pad.  Minmus is still out of the question due to lack of power generation (and it would require dozens of batteries for a minmus probe).  This mission should net you tons of science and funds, paving the way for unlocking the parts needed for mun landings and to get to minmus.  Somewhere in there you'll need the funds to upgrade the R&D; but worlds-first contracts seem to pay well, so might not be too much of a problem, especially if a few other contracts were done with the previous launches.

# 4 / 5 -- might be better than I remember due to the new 'hibernate' feature on probe cores.  Maybe it doesn't take a dozen small batteries to go to Minmus anymore

With SSTU the #2 launch could potentially be an orbital launch.  The MFTs and MSRBs are a bit overpowered being unlocked at tier1.   Thinking of moving the MFT up to 'advanced rocketry' (tier 3) along with the initial LR-81, and moving the MSRB up to at least general rocketry.  This would enforce the use of stock parts for at least the first two launches, while still letting the initial SSTU parts unlock at about the time where you start needing them.  (A few other things would likely move up a node or two, need to do a bit more early-mid-career testing to see how it all feels).  Going to do a bit more testing/playing/work on it, I think there are a few small changes that could clean up most of the early-career SSTU-being-overpowered problems. 

 

 

Link to comment
Share on other sites

47 minutes ago, Shadowmage said:

Looks like there might be something like that already available.  Was taking a look at the ETT tree / repo, and ran across this:  https://github.com/ProbusThrax/ETT/tree/master/KSPTechtreeEditor

Haven't downloaded it, don't really know what it does, but it appears to be a graphical tech-tree editor based on the libraries it uses and the name of the file :)

 

*snip*

:o Oh man I sure hope this is what it looks like!!! Off to the ETT thread to find out!!! Thank you!!!

Probably wont actually be able to check it out until like next week some time though :( I've got a big chemistry final tomorrow that I should probably study for tonight and my girlfriend is walking for her first degree tomorrow as well so it's gonna be a long weekend hanging out with her parents :/ *sigh*

Edited by Akira_R
Link to comment
Share on other sites

So I want to post an alternate mission sequence because Mods other than SSTU and Stock are out there.  This should highlight the issues with tech trees....

Mods in use are

  • -Mechjeb (with custom altered unlock points to bring them in line with next mod):wink:
  • -FASA (has earlier unlocks as I alluded to in my previous post for larger diameters to allow a full NASA to the early 1980s in a stock tech tree.)
  • -Parts of Bluedog DB (the parts that I prefer over their FASA or SSTU versions, mostly Agena and UA-12xx SRBs.)
  • -DMagic orbital Science/CAPCOM and
  • -Staged Recovery (to save my parts for some extra cash.)

Launch 1 is a Probe on an SRB,  Launch and recover (basically the same as posted above)   This generates ~8 science with the various science parts in BD/FASA and DMagic.

Repeat Launch 1 with more science devices on board.  Total science is close to 35 now Funds should be enough to unlock ONE building upgrade (I choose Tracking center.)

repeat launch 1 with the SRB separating and having a separate parachute,  Probe does science when it lands instead of in the air.   Another 15 to 20 science (depending on where you land it.  Expand the launcher with side saddle SRBs that then stage the central SRB.  Repeat 3 times landing on different surfaces each time.  Unlocking the 45 sci nodes now.

Accept "Test ProductX  on launch pad or in water"   Run those missions, combined into as few missions as possible

Go for Orbit (accepting the Reach Space and Orbit missions.)   I prefer to do this mission with the Pioneer probe in FASA as soon as all the parts are unlocked, but I use a RT-10 as a first stage booster.   I have my FASA Mercury Atlas for the follow up launch..   lets hope Jeb makes it back :)

Should have funds to unlock another building upgrade and should be more than half way through the 45 sci nodes at this point.

 

 

As you can see, I play the game differently than other players.  I use mods other than X or Y single mod (my main machine has 64 mods installed, this laptop has 12 part mods including SSTU.)   This right here is why the Tech tree fails.   I can blitz through the science, where others dwaddle through.

I have an idea for a solution, but it would involve a TON of Mod manager files (and while I have been dabbling in them I am NO EXPERT.)   The MM files would incorporate the upgrade process to all parts in game and everything post the 45pt science unlocks would be to unlock upgrades.  

 

Link to comment
Share on other sites

11 hours ago, Pappystein said:
  • -FASA (has earlier unlocks as I alluded to in my previous post for larger diameters to allow a full NASA to the early 1980s in a stock tech tree.)
  • -Parts of Bluedog DB (the parts that I prefer over their FASA or SSTU versions, mostly Agena and UA-12xx SRBs.)

 

I'd change those two, FASA is dead and I don't even know if it is still being maintained by the RO folks while BDB has what it had and more stuff than it (probes, skylab, Eyes Turned Skywards stuff, Jupiter, Delta, Saturn I...), not to mention that the BDB Saturn V is actually proportional to the RL one (except for the SLA)

and since this is the SSTU thread, let me make a shameless plug by saying that I'm adding SSTU plugin support to BDB parts in the SSTU Expansion pack :)

18 hours ago, Shadowmage said:

Looks like there might be something like that already available.  Was taking a look at the ETT tree / repo, and ran across this:  https://github.com/ProbusThrax/ETT/tree/master/KSPTechtreeEditor

Haven't downloaded it, don't really know what it does, but it appears to be a graphical tech-tree editor based on the libraries it uses and the name of the file :)

 

That first paragraph pretty much sums up my problems with the KSP tech-tree.  Shouldn't need to progress through 1/2 or 2/3 of the tree for technologies that were already in use on some of the very first orbital rockets and probes; I consider those technologies to be prerequisites to even attempting anything beyond sounding rockets.  By the time you are ready to attempt orbit you should already have some form of power generation (not just batteries, or at least really big batteries) and information features (AP, time to AP, craft dV; all the info that is hidden or unavailable in stock).

But yeah, I haven't really been able to come up with a better organization for the tree either; though I haven't really spent too much time looking at it... could probably come up with something if I had to.

 

I -think- that debug tool can spit out completely filled-out tech tree config files.  I never actually got to use it, and sadly they removed all of those features in 1.2 with the new debug menu.

If you do come up with something, please let me know.  I would have no problems collaborating on a customized tech tree, though I think that CTT/ETT might be a good place to start from.  I think that ETT is probably closer to what I'm looking for (focused development branches), and seems to be what I'll be investigating this weekend.

 

 

Did a bit of early career playtesting the past few nights, comparing stock-only progression to progression including SSTU parts.  It seems that, for me, regardless of the parts available, the launches generally go (on stock 'normal' difficulty settings):
1.) First launch, grab science from on the pad and low atmo with a basic flea+pod+chute+goos.  Completes some contracts and world firsts.  Unlock tier1 nodes, possibly one of the tier2 as well.  This gets 1-2 more science experiments.
2.) Sub-orbital launch.  Grab science from high-atmo and low-space.  Pod+chute+goos+srbs+decouplers; can be done with 2x hammer and 1x flea.  Unlock tier2 nodes (~20s).
3.) Orbital launch.  Whether limited to stock parts or allowing use of SSTU parts, can make orbit with the third launch.
4.)  Herein lies the problem.  This should be a mun-flyby, but stock locks the maneuver nodes and conics behind some building upgrade.  Should have enough funds for them.  But also, even with science from launch#3, the best you will get here are some batteries; no chance of solar, fuel cell, etc, which I consider requisite for anything beyond very basic LKO missions.  Can be done with batteries alone, but it shouldn't need to be done that way, at least not with 100EC batteries (perhaps a 500 or 1k would be more suitable).  Ohh, good luck getting both the reaction wheel and batteries unlocked that you'll need...  (might be easier to just do it manned; no antenna needed, fewer batteries)
5.)  If you get #4 to work out (likely by using a toss-away probe transmitting a bit of science as it flies past the Mun), you -should- have enough tech and facilities at launch #5 to do a Mun orbit and return.  Barely.  Might need to upgrade the launch-pad.  Minmus is still out of the question due to lack of power generation (and it would require dozens of batteries for a minmus probe).  This mission should net you tons of science and funds, paving the way for unlocking the parts needed for mun landings and to get to minmus.  Somewhere in there you'll need the funds to upgrade the R&D; but worlds-first contracts seem to pay well, so might not be too much of a problem, especially if a few other contracts were done with the previous launches.

# 4 / 5 -- might be better than I remember due to the new 'hibernate' feature on probe cores.  Maybe it doesn't take a dozen small batteries to go to Minmus anymore

With SSTU the #2 launch could potentially be an orbital launch.  The MFTs and MSRBs are a bit overpowered being unlocked at tier1.   Thinking of moving the MFT up to 'advanced rocketry' (tier 3) along with the initial LR-81, and moving the MSRB up to at least general rocketry.  This would enforce the use of stock parts for at least the first two launches, while still letting the initial SSTU parts unlock at about the time where you start needing them.  (A few other things would likely move up a node or two, need to do a bit more early-mid-career testing to see how it all feels).  Going to do a bit more testing/playing/work on it, I think there are a few small changes that could clean up most of the early-career SSTU-being-overpowered problems. 

that's why I mentioned RP-0, even though it is meant to be an RO tech tree, they changed everything to start with probes, and moved many science parts out of the start, so the first launches are pretty much sub-orbital if you even manage to do that much

Edited by JoseEduardo
Link to comment
Share on other sites

So I am testing out the new Communication feature in 1.2.2  I equipped a satellite with the BKT-A Solar panels to act as a relay anchor for my probes on other planets.   and am in direct line of site to Kerbol at a circular altitude of 20000km above Kerbin.

The BKT-A panels are deployed but not generating any electricity.  my probe died of no ECs right after attaining my circular orbit.   Is there another part needed to get these things to work / Is this a Bug I should report to the Github?

 

Soo... I alt-tabbed back into the game and the panels Rotated 180 Degrees and started to generate EC.   I will run more test launches and see if I can trace this down.

<Edit 2>

So I re-created the issue.   It appears that things like the Mun can completely eclipse the panels even if the Panels can draw a Direct LOS to the Sun.   I am guessing that the LOS calculation point is low on the mast due to the modular nature of the panels?

Edited by Pappystein
Link to comment
Share on other sites

20 hours ago, Pappystein said:

Soo... I alt-tabbed back into the game and the panels Rotated 180 Degrees and started to generate EC.   I will run more test launches and see if I can trace this down.

<Edit 2>

So I re-created the issue.   It appears that things like the Mun can completely eclipse the panels even if the Panels can draw a Direct LOS to the Sun.   I am guessing that the LOS calculation point is low on the mast due to the modular nature of the panels?

Yes, the raycast for most of the panels is roughly half-way along their length.  The larger panels generally have 2 or more raycasts at even intervals along their length (every 1/3 of the panel, so that a small occlusion doesn't completely stop EC generation).  These really only matter for part-to-part based occlusion though (see below).

Planetary occlusion -- I use stock code for that, the bits that determine if a vessel is in sunlight or not (vessel.solarFlux > 0).  So if there are any oddities going on there, they are much deeper rooted than the SSTU solar panel module, and are bugs that need to be fixed in stock code.  To be fair, I have seen a few cases where panels think they are occluded by planets when they really should not be, notably right on the transitions from light-to-dark, and strangely it doesn't happen in time-warp.  Mostly they appeared as edge cases though that had negligible effect in actual use (e.g. occluded for an extra 3 seconds at dawn/dusk, not a big deal), and regardless, they are problems with the stock code that I can do nothing about.

If you do manage to narrow down the cause, or have a particular setup that duplicates the problem reliably, please let me know and post it up as an issue on GitHub.  If nothing else it could give me enough information to file a stock bug report regarding their planetary occlusion code.

 

 

General development news:

Did quite a bit of work on CTT integration, and general tech-tree cleanup, over the weekend.  While CTT doesn't fix the problems that I have with the stock tech tree, it does allow for a decent career experience.  The CTT balance that I've put in is suited to a much longer game than the stock career balance -- many engines are moved into later nodes, and all of the station-core stuff comes later in the habitation node lines.  The next few days will be spent going over the HAB and LS balancing on the StationCore parts and updating the patches for the rest of the ShipCore/LanderCore parts.

That was the other bit that I did this weekend, career playtesting, focused on balance (using CTT+USI-LS, among various NF/USI part mods).   Removed all standard stock LFO tanks and all of the standard stock engines to see how viable SSTU is as a 'stock conversion'.  Very usable, though lacking the stock upper stage engines was notable (although, it is notable merely because those engines are very unrealistically overpowered in their size, not because of their raw performance stats).  Things generally went well.  Didn't run into any new bugs, found and squashed a couple old ones, everything else pretty much worked as expected and intended.

Have also started work on an 'SSTU-OptionalPatches' addon.  Will basically be my 'personal' patch set.  Will be optional as many of the patches are destructive (remove or change parts from stock or other mods).  This will contain things like part-overhauls for other mods (converting things to MEC, MFTs or MSCs), part cleanup for stock and other mods (many parts are redundant / not needed when using SSTU, and can be removed to clean up the editor parts list), and part rebalancing for stock or other mods (mass/cost/tech; not many get rebalanced).  Will be highly recommended, entirely optional, and completely unsupported -- use at your own risk, modify as needed/desired.


Will hopefully have an updated release with the recent balance changes available later this week; still a bit more work to do on balancing of the StationCore parts, both stock and USI-LS balance.

Link to comment
Share on other sites

14 hours ago, SpaceBadger007 said:

Hey I made this mission, and it used a lot of your parts, so I might as well show it!

 http://imgur.com/gallery/UXbks

Very nice station :)  Puts my early career one to absolute shame.

 

 

Last couple days were spent doing config work.  And bugfixing.  And more config work.  Also some work on configs.

All of the outstanding placeholder values in parts have been set appropriately (cost, mass, tech placement).  All of StationCore has USI-LS integration.  Created MFT part config sets for all of the Near-Future Construction truss types (circular, square, hex, octo) and their basic adapters.  Squashed several small bugs relating to model use and ease-of-config setup, and made it so that modular heat shields actually have a cost.  Added mass and costs to the MCB-A parts.  CTT integration is ongoing and nearing completion -- couple minor tweaks to some station part placements are in order, but good aside from that.

 

Heads up -- the next release is going to have quite substantial changes as far as career balancing is concerned.  Shouldn't be game breaking, but can certainly be game-impacting (some things will have mass changed, lots of tech-requirements moved around).

 

Playing with trusses -- all of them use the MFT module to enable resizing and variant changing, octo trusses include resource-holding variants:

EkXRQdJ.png

 

Playtesting is still going well.  Fixing things up as I run into them, but not running into much.  Have not managed to duplicate the docking-port-stuck bug, nor have I had any problems with crew capacities/crew transfer.  Though, I haven't unlocked the station-core parts, so have not been able to test them yet.

Have also been taking a look at RoverDude's Konstruction mod during playtesting, mostly as far as potential use of the Konstruction plugin for some custom parts (e.g. shuttle grapple arm, station manipulator, base construction aids).  Merely looking and playing with it for the moment, any potential use is in the far-future.
Konstruction by itself is pretty entertaining though, and has potential to be game-changing when combined with KAS/KIS and EPL.
 

Link to comment
Share on other sites

18 minutes ago, Shadowmage said:

RoverDude's Konstruction

The Dude has some innovating stuff in Konstruction, He basically took IR and made it a lot better. Heck i even build the robotic suit that Ripely wears in Aliens (you know the one with the clamp arms....GET AWAY FROM HER YOU.......errr   you the rest) :P 

Edited by mechanicH
Link to comment
Share on other sites

EDIT : Turns out I am an idiot and did not realize that the sound I wanted was part of RealPlume. I should have installed that first before complaining about the sound. I will leave my post up in case anyone else is confused.

---------------

Been using this in my latest career save and I have been enjoying it.

However, I have to admit. The sound is not the best. It really breaks immersion when SRBs don't sound like solid rockets and big rockets still sound like the classic engine.

Is there any chance of sound changes in the future? So that big rockets really get you saying "Look at that big rocket GO into the clouds at ten thousand feet!"

Edited by AbhChallenger
Install Error
Link to comment
Share on other sites

Updated release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.5.34.131

Tons of balance changes/fixes/updates.  A few bugfixes.  New set of optional patches (WIP) to add better mod integration for USI and NF mods, as well as a CTT config set.  Colored specular support on the DOS/SMX lines of solar panels.  Also, some basic gray and green textures for DOS parts.

UJmzmtH.png

Link to comment
Share on other sites

Hi Shadowmage,

I've enjoyed SSTU for over a year. Thank you very much for the continued development of this great pack!

With 0.5.34.131, I am no longer seeing the ST-MST-ISS appear in the part list (among other parts), even with a completed tech tree. I think there is a problem with some of the @techRequired settings in GameData/SSTU/ModIntegration/CTT/CTT.cfg.

 

Link to comment
Share on other sites

11 hours ago, Fury1SOG said:

Hi Shadowmage,

I've enjoyed SSTU for over a year. Thank you very much for the continued development of this great pack!

With 0.5.34.131, I am no longer seeing the ST-MST-ISS appear in the part list (among other parts), even with a completed tech tree. I think there is a problem with some of the @techRequired settings in GameData/SSTU/ModIntegration/CTT/CTT.cfg.

 

Seems to be showing up fine for me in stock:

jZJoTqn.png

 

(Will take a look at CTT shortly, but you did not say you were using CTT, so no reason for me to check it...)

Link to comment
Share on other sites

3 minutes ago, Fury1SOG said:

Apologies. I am indeed using CTT.

 

Noted, thanks for the confirmation;

 

Looking over the CTT patch a bit more, and yeah, apparently I had a few incorrect node names in the solar panel stuff (late additions yesterday right before the release, forgot to load game to test...).

The solar panel block in that patch should read as:

// ------------------------- StationCore Solar Panels -------------------------
//ST-GEN-DSP
// med variants - adv solar tech
// lrg variants - cutting edge solar
// MST + ISS - adv photo mat

@PARTUPGRADE[SSTU-ST-SolarUpgrade3]:NEEDS[CommunityTechTree]
{
	@techRequired = advSolarTech
}

@PARTUPGRADE[SSTU-ST-SolarUpgrade4]:NEEDS[CommunityTechTree]
{
	@techRequired = cuttingEdgeSolarTech
}

@PART[SSTU-ST-GEN-DSP-MAX-M|SSTU-ST-GEN-DSP-BKT-A|SSTU-ST-GEN-DSP-BKT-B|SSTU-ST-GEN-DSP-BKT-C|SSTU-ST-GEN-DSP-BKT-D|SSTU-ST-GEN-DSP-BKT-E]:NEEDS[CommunityTechTree]
{
	@TechRequired = advSolarTech
}

@PART[SSTU-ST-GEN-DSP-SMA-L|SSTU-ST-GEN-DSP-SMB-L|SSTU-ST-GEN-DSP-SMC-L|SSTU-ST-GEN-DOS-L|SSTU-ST-GEN-DOS-T]:NEEDS[CommunityTechTree]
{
	@TechRequired = advSolarTech
}

@PART[SSTU-ST-GEN-DSP-MAX-L]:NEEDS[CommunityTechTree]
{
	@TechRequired = cuttingEdgeSolarTech
}
@PART[SSTU-ST-MST-ISS|SSTU-ST-GEN-DSP-ISS]:NEEDS[CommunityTechTree]
{
	@TechRequired = advPVMaterials
}


You can copy/paste that over the existing data in that file, should fix the problem up for now, and let you keep working with it until the next release is available (which might be a week or two).

Alternatively you can grab an updated copy of the file from :  ( https://github.com/shadowmage45/SSTULabs/raw/87ceed4b5441b36ca4bbc726a0fafb4f49f6e080/GameData/SSTU/ModIntegration/CTT/CTT.cfg )    and replace your existing one with it.

 

Sorry about that, and thanks for the bug-report.

Link to comment
Share on other sites

Would it be possible to adjust the module RCS thrusters to 90 degree orientations, instead of the current 45 degree ones, for efficiency purposes.

Or maybe provide an option to eliminate these RCS thrusters so that we can install other ones... for RCS balancing.

Just a thought :)

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