[1.3.x] SETI, Unmanned before Manned [Patreon]

[Yemo]

Ok, I was specifically thinking of grabbing just the SETI-Science.cfg file.

I modify my game pretty heavily (41KB of personal CFG files) and have pulled various edits from your mod, but somehow I must of missed the really nice science changes you made.

Reading your files has been great for honing my MM skills.

Ah, ok. You might want to take a look at the SETI-PartMod-SQUAD-Science.cfg file as well then (but keep in mind that I have to give the thermo and baro some mass again in the next version, due to the heating system changes and squads ignorance of the physicsSignificance flag for that).

Apropos science, I forgot something when answering this earlier:

This tree is excellent, especially when coupled with RemoteTech and a Life Support mod to further reinforce the "unmanned first" principle. However, this bit:

doesn't really seem to fit the scope of the mod. Or at least there needs to be more advanced versions later in the tree (non-Jr versions?), as otherwise there is really no point taking them even as far as Duna, especially since all the others transmit at 100% (and so having a scientist just for these 2 poor experiments is pointless). What is even the logic behind it? If the scientist can reset it, he must be removing/replacing the active ingredients, so he must be able to Take the data as well.

There are in fact more advanced versions for the MysteryGoo and MaterialsBay. They are provided by DMagicOrbitalScience. Afair, they have only half the mass and provide 2 charges each.

[SSGFouts31]

Yemo,

Outstanding work on this mod! I have been playing/following SETI from the start. Out of curiosity, do you have any plans to flesh out the rest of the contracts below the red line? And if not can you recommend a contract mod that would fulfill some lategame mechanics and not interfere with SETI contract progression?

[Yemo]

Yemo,

Outstanding work on this mod! I have been playing/following SETI from the start. Out of curiosity, do you have any plans to flesh out the rest of the contracts below the red line? And if not can you recommend a contract mod that would fulfill some lategame mechanics and not interfere with SETI contract progression?

Thank you!

If I remember correctly, I made the contracts cancellable/declineable based on one of your posts ;-).

About the contract progression, I planned to flesh them out before the BalanceMod got axed by squad.

Currently my main priority is, to get back to the old BalanceMod gameplay standard, especially since so many more contract packs are available now.

I have not tested them yet (I rarely play full careers now) in concert with SETIcontracts, but there are packs for base and station building.

If I would try out a full career game, I guess my contract list for testing it would look like this:

Anomaly Surveyor

Base Construction

Field Research

Kerbal Aircraft Builders

Kerbin Space Station

RemoteTech Contract Pack

SETI-Contracts

SCANsat Contract Pack

Tourism Plus

[SSGFouts31]

Cool, thanks for the reply. I eagerly look forward to the return of the Balance Mod. I find that I really don't enjoy the game much without it.

[Tahvohck]

For the current SETIctt I m not sure if it is time efficient, since I ll have to learn "the github way" and maintain it. It also heavily relies on internet access while working on the mod, which is not a given for me during the next couple of weeks.

Just want to point out that that's not quite true. GitHub relies on git for its backend (thus "git"hub) and git doesn't require internet access unless you're pushing to a remote (which is what github is). In the end, GitHub is really just a specialized hosting site with a nice interface and some useability elements. If you'd like I can give you a crash course in how to use it, since I've been doing that somewhat regularly recently.

If you don't want that but do start using GitHub, do yourself a favor and use SourceTree locally instead of the GitHub GUI/git command line... the GitHub one, frankly, is just not nearly robust enough for what it's supposed to be doing, and the git command line--while super powerful--is horribly non-user-friendly until you learn how to use it (and I say this as someone who learned the CL first ).

Edit: Oh, but skimming back through the thread it looks like you might use Linux? Unless you have WINE you can't use SourceTree then, which is a shame. Point stands though, get a better GUI than the GitHub one.

Edited July 10, 2015 by Tahvohck

[nobodyhasthis]

I dearly love what you have done for the game. Seriously, I just can't play stock KSP. Not after using your mods. However you have recently lost your way with the last update.

UniversalStorage is not yet officially supported for SETIctt (because it has quite some balancing issues, especially the converters), but I m trying to at least keep an eye on the part locations in the tech tree.

You have already started to move the Universal Storage parts already and have messed them up. They contain a TAC LS system split over two tech levels. The lower tech radial tanks take up half a service bay. The tank wedges are higher tech replacements. If your not supporting Universal Storage or don't understand how it affects progression then stop moving the parts.

0.9.0.2 was only planned to be the first part of the TAC Life Support rearrangement.

So it is indeed half finished and totally unplayable now. However as they say Rome was not built in a day. I just wished you had figured out the moves before changing things.

Eg in USI LifeSupport, kerbals can last 15 days without supplies (enough for LKO, the 72hour manned mission and missions to the Mun). So the supply containers are available at the Life Support node. In TAC LifeSupport, kerbals can last 360 hours (60days) without food, but only 36 hours without water, and even less without oxygen and electricity.

Not exactly. They are designed with diffrent game concequences. In USI the Kerbals don't just last 15 days. They last forever. When supplies run out they just get upset. The game mechanic is they go on strike and become tourits. USI Kolonisation lets them replace supplies and gets them back to work. Jeb and Valentinai are are totally immune to the effect and can last forever with no support. Kerbals on EVA are also not affected. The consequence of failure is just lazy kerbals and lost productivity.

On the other hand. In TAC LS the Kerbals needs a constant supply of three resources otherwise they just die. End of story. Hows that for balance?

TAC LS was built to be more realistic. The Kerbals can ration out the last of the food. 60 days in KSP is actually only 15 real world days. If they don't get help by then they are doomed. Running out of potable water is worst. In a survival situation lack of fresh water will them quicker. As will lack or oxygen. The environment is also assumed to be using Co2 scrubbers and heating which drains power.

The problem with TAC LS is once you get a three man pod. The weight of a large supply container is not a lot to add on. You can get a frequently get a Kerbin years worth of suppliers on board. The calculations based on real world survival factors don't scale with the tiny Kerbol System over a long time period. This lessens the need for recycling and for carrying the excellent SETI green house around with TAC LS whilst in Kerbins SOI at least. Although for permanent colonization bases or trips further out the greenhouse is required.

But now that I plan to include procedural parts again, I do not know where to place the PP life support. If I place it at earlyCommandModules, it enables food over there. If I place it at LifeSupport, then oxygen and water is only available that late....

Your primary problem seems to be that you don't like the endurance numbers. You are not following a proper technological development because of this. There is absolutely no reason to separate food out into a different node. Remember all the capsules have life support built in anyway using a basic TAC LS module.

All life support resources come should together in the same node. What your failing to see is the size and weights change through technological development and not availability. Higher technology does not affect the basic endurance numbers at all. What changes is the size, weight and ease of use of the containers. For example. If you throw in FAR aerodynamics into the mix you see that the radial tanks are a total pain to use. They need to be mounted in a service bay. It is all extra weight for just 10 points of each supply. Later on once passed basic survival. There is more sophisticated equipment. The stuff just gets easier to carry but the endurance calculations don't still don't change.

So, new proposal: HeatShields to Command Modules line (1.25m to earlyCommandModules together with Mk1 Pod, 0.625m heat shield from VenStockRevamp stays at survivability).

Why would the heat shields need to be in with command pods when it makes no sense. Heat resistant materials don't need manned flight as a perquisite. It is other way round. Moving them to manned flight messes up early probe design.

All LifeSupport (USI and TAC) to enhancedSurvivability (the TAC clutter parts get their extra 0 science node, available from enhancedSurvivability, the TAC PP and US parts stay at enhancedSurvivability). The retitlement of the recycling node is reverted.

Except that still gets screwed up by not supporting Universal Storage TAC LS correctly. It also mixes up different tech levels. You seem to be motivated more by reducing clutter that balancing out the tech tree. Why the hell would anyone use heavy equipment when the light stuff is available?

I have a better solution put things in order of technology. Let us worry about the clutter.

Edited July 11, 2015 by nobodyhasthis

[Yemo]

Just want to point out that that's not quite true. GitHub relies on git for its backend (thus "git"hub) and git doesn't require internet access unless you're pushing to a remote (which is what github is). In the end, GitHub is really just a specialized hosting site with a nice interface and some useability elements. If you'd like I can give you a crash course in how to use it, since I've been doing that somewhat regularly recently.

If you don't want that but do start using GitHub, do yourself a favor and use SourceTree locally instead of the GitHub GUI/git command line... the GitHub one, frankly, is just not nearly robust enough for what it's supposed to be doing, and the git command line--while super powerful--is horribly non-user-friendly until you learn how to use it (and I say this as someone who learned the CL first ).

Edit: Oh, but skimming back through the thread it looks like you might use Linux? Unless you have WINE you can't use SourceTree then, which is a shame. Point stands though, get a better GUI than the GitHub one.

Thank you very much for your offer!

About the "online" aspect, it is more like without github I can work without internet for a week without having to worry, about doing double work and reintegration, because the stuff on github is worked upon.

Until KSP 1.1/BalanceMod reboot, I just feel more comfortable with the current way.

But if I may, I would gladly come back to your offer once I m ready to fully start again.

I m switching between linux and windows, though I tend to use the former for actual playing and the latter for modding.

I dearly love what you have done for the game. Seriously, I just can't play stock KSP. Not after using your mods. However you have recently lost your way with the last update.

You have already started to move the Universal Storage parts already and have messed them up. They contain a TAC LS system split over two tech levels. The lower tech radial tanks take up half a service bay. The tank wedges are higher tech replacements. If your not supporting Universal Storage or don't understand how it affects progression then stop moving the parts.

So it is indeed half finished and totally unplayable now. However as they say Rome was not built in a day. I just wished you had figured out the moves before changing things.

Not exactly. They are designed with diffrent game concequences. In USI the Kerbals don't just last 15 days. They last forever. When supplies run out they just get upset. The game mechanic is they go on strike and become tourits. USI Kolonisation lets them replace supplies and gets them back to work. Jeb and Valentinai are are totally immune to the effect and can last forever with no support. Kerbals on EVA are also not affected. The consequence of failure is just lazy kerbals and lost productivity.

On the other hand. In TAC LS the Kerbals needs a constant supply of three resources otherwise they just die. End of story. Hows that for balance?

TAC LS was built to be more realistic. The Kerbals can ration out the last of the food. 60 days in KSP is actually only 15 real world days. If they don't get help by then they are doomed. Running out of potable water is worst. In a survival situation lack of fresh water will them quicker. As will lack or oxygen. The environment is also assumed to be using Co2 scrubbers and heating which drains power.

The problem with TAC LS is once you get a three man pod. The weight of a large supply container is not a lot to add on. You can get a frequently get a Kerbin years worth of suppliers on board. The calculations based on real world survival factors don't scale with the tiny Kerbol System over a long time period. This lessens the need for recycling and for carrying the excellent SETI green house around with TAC LS whilst in Kerbins SOI at least. Although for permanent colonization bases or trips further out the greenhouse is required.

Your primary problem seems to be that you don't like the endurance numbers. You are not following a proper technological development because of this. There is absolutely no reason to separate food out into a different node. Remember all the capsules have life support built in anyway using a basic TAC LS module.

All life support resources come should together in the same node. What your failing to see is the size and weights change through technological development and not availability. Higher technology does not affect the basic endurance numbers at all. What changes is the size, weight and ease of use of the containers. For example. If you throw in FAR aerodynamics into the mix you see that the radial tanks are a total pain to use. They need to be mounted in a service bay. It is all extra weight for just 10 points of each supply. Later on once passed basic survival. There is more sophisticated equipment. The stuff just gets easier to carry but the endurance calculations don't still don't change.

First of all, thank you for your detailed feedback.

There seem to be some misunderstandings:

1. In 0.9.0.2, TAC life support is split between 2 nodes, enhancedSurvivability for oxygen and water, and recycling/LifeSupport for food. US is not fully supported, so I m not responsible for the location of the parts. I just saw no need to move water and oxygen, only to move them again in the next version. The other parts were intended to stay at LifeSupport node.

2. I see food not primarily as "food", but as the resource which extends life support beyond 360 days (+ the stuff in the pods). At least it would have avoided the possibility to send a kerbal to Duna with only 45 science nodes researched...

3. The US radial tanks are imho intended for rovers and landers and so on.

Anyway, that plan is scrapped now.

All Life support containers (TAC and USI) go into enhancedSurvivability. Except the TAC Life Support clutter parts, which go into their own special 1 science node (cant make it 0 science), directly attached to enhancedSurvivability. So PP users can just avoid this node and everyone else just have to spend 1 more science and 2 more clicks. Which imho is not too much to ask for, from people who play with TAC LifeSupport...

Why would the heat shields need to be in with command pods when it makes no sense. Heat resistant materials don't need manned flight as a perquisite. It is other way round. Moving them to manned flight messes up early probe design.

Because there is a strong link between the historic development of larger heat shields and crew pods.

It also has the nice side effect of discouraging some players from using a Mk1 Inline Cockpit as a space capsule, since the Mk1 Pod comes with the 1.25m heat shield anyway.

Small probes still have access to the 0.625m heat shield from VenStockRevamp, which stays at the survivability node.

Mun and Minmus do not need shielded probes anyway and the Orbit+Recovery contract can easily be done with a 0.625m heat shield.

Except that still gets screwed up by not supporting Universal Storage TAC LS. It also mixes up different tech levels. You seem to be motivated more by reducing clutter that balancing out the tech tree. Why the hell would anyone use heavy equipment when the light stuff is available?

I have a better solution put things in order of technology. Let us worry about the clutter.

Have you looked at the US TAC LifeSupport recyclers? They are so out of whack, I would have to either hide or rebalance them (I did the latter for the old SETI-BalanceMod, but at the moment I just want to focus on mod support, so if a mod provides such imbalanced parts, I just reserve the right to not officially support it).

Well, reducing clutter was one of the main reasons why I started this whole SETI thing. It is just an additional 2 clicks + 1 science point for clutter users, which is imho very reasonable compared to the advantages for non-clutter users.

Oh, and it is totally playable right now.

[kingoftheinternet]

v0.9.0.2 TechTree changes

• ...
  
• FuelLines much later @highPerformanceFuelSystems
  
• ...
  

This had me confused for a while; the fuel line (which I'd already unlocked) still appears as unlocked under Advanced Fuel Systems.

[Yemo]

This had me confused for a while; the fuel line (which I'd already unlocked) still appears as unlocked under Advanced Fuel Systems.

(In this case: Unfortunately,) Already unlocked parts stay unlocked, if they are shifted around in the tech tree. The part will be shown in its old and in its new place, but there is no gameplay effect.

Will happen to a lot of parts once 0.9.1 is released. With such important parts like fuelLines, you could only roleplay it (like with so many things in ksp) and refrain from using them until unlocking their new position.

[kingoftheinternet]

(In this case: Unfortunately,) Already unlocked parts stay unlocked, if they are shifted around in the tech tree. The part will be shown in its old and in its new place, but there is no gameplay effect.

Will happen to a lot of parts once 0.9.1 is released. With such important parts like fuelLines, you could only roleplay it (like with so many things in ksp) and refrain from using them until unlocking their new position.

In this case at least, the part is actually re-locked. It doesn't show up in the VAB part list anymore, and my saved ships that used it say they contain experimental parts now and it won't let me launch them. (The confusing thing was that I couldn't use them despite them appearing to still be unlocked in the tech tree.)

[Yemo]

In this case at least, the part is actually re-locked. It doesn't show up in the VAB part list anymore, and my saved ships that used it say they contain experimental parts now and it won't let me launch them. (The confusing thing was that I couldn't use them despite them appearing to still be unlocked in the tech tree.)

Whoa, did they change the mechanic?

That is news to me, will investigate tomorrow.

That would be a real problem for tech tree updates in general.

[nobodyhasthis]

US is not fully supported, so I m not responsible for the location of the parts.

//------\\

//---SETI-CTT---\\

//------\\

//---Tech Tree changes for UniversalStorage---\\

//------\\

//---US Food/Supply Parts

@PART[uS_1R320_Wedge_Food|US_Radial_R40_Food]:NEEDS[universalStorage]:AFTER[universalStorage]:FOR[sETIctt]

{

@TechRequired = recycling

}

.....Lets delete all of that then before we go on then

The radial tanks stay can stay put where they are. I see them as ugly and clumsy early attempts at live support. Before you get the more compact official TAC LS containers. The rest of it is of course different. The US TAC recyclers are indeed totally out of whack. I totally agree with you on that one. To be honest a lot of US should be after miniaturization and development of bigger stuff.

I have already fixed my game by putting all the resources back into the same nodes. I now understand why you pulled the food out as a separate case but my real life experience is telling me to put it back now before the next update. I have lived in a closed system and the freeze dried food is terrible but there is always enough.

You are however right about the resources themselves not reflecting progression. When developing life support systems the problem is the water supply. To get more of that that you need a big power supply and or a big RO filtration system. It runs into the cube root problem. A system twice as wide and tall as another will have eight times the weight, and require a far stronger support structure. The only way to combat this by increasing the efficiency. We should indeed be forced into developing better technology before going passed Minmus.

[Tahvohck]

Thank you very much for your offer!

About the "online" aspect, it is more like without github I can work without internet for a week without having to worry, about doing double work and reintegration, because the stuff on github is worked upon.

Until KSP 1.1/BalanceMod reboot, I just feel more comfortable with the current way.

But if I may, I would gladly come back to your offer once I m ready to fully start again.

I m switching between linux and windows, though I tend to use the former for actual playing and the latter for modding.

Ah, okay, I see! So you know, you'd only have to do reintegration any time you accepted a pull request since only you have push access to your own repositories (unless you set it up differently, of course!). But it would probably be best to wait until you're rebooting the code anyway, yeah.

Dual booting, huh? How well does that work for you? Honestly, I don't shut down my computer often enough for that to be a viable option for me, despite how much I'd like to.

- - - Updated - - -

//---US Food/Supply Parts

@PART[uS_1R320_Wedge_Food|US_Radial_R40_Food]:NEEDS[universalStorage]:AFTER[universalStorage]:FOR[sETIctt]

{

@TechRequired = recycling

}

Not just directed at nobodyhasthis, but can anyone tell me what that makes the MM bootup section of the log look like? Both the :AFTER[] and :FOR[] tags are positional loaders, although FOR also creates an index if it didn't exist already, and I didn't think you could combine them (and if it's just being done to make a SETICTT mountpoint, you might be best defining it once as a dummy node).

[Daishi]

Have you looked at the US TAC LifeSupport recyclers? They are so out of whack, I would have to either hide or rebalance them (I did the latter for the old SETI-BalanceMod, but at the moment I just want to focus on mod support, so if a mod provides such imbalanced parts, I just reserve the right to not officially support it).

Sorry to butt in, but could you elaborate as to why our parts are so "out of whack"? My co-author Paul has put a ton of work into making those conversion rates as accurate as possible, alongside Roverdude and TaranisElsu. Any constructive feedback would be appreciated.

[Yemo]

In this case at least, the part is actually re-locked. It doesn't show up in the VAB part list anymore, and my saved ships that used it say they contain experimental parts now and it won't let me launch them. (The confusing thing was that I couldn't use them despite them appearing to still be unlocked in the tech tree.)

Just checked. It indeed locks the fuelLines again.

I could go on a rant again, how it complicates tech tree modding if saves are affected in such a way.

And how it makes no sense whats-o-ever to relock them but have them still clutter up the tech tree in 2 places.

But I guess it is like fighting windmills. If they want to make their game mechanics worse, so be it.

I m sorry for the inconvinience, it was not intentional. Unfortunately I do not know how to fix it for future updates.

If you really want to use the fuel lines, you could go to the SETIctt\MM-TechTree\SETI-TechTree-SQUAD.cfg file and replace this section

//---FTX-2 External Fuel Duct
@PART[fuelLine]:FOR[SETIctt]
{
    @TechRequired = highPerformanceFuelSystems
}

with that one

//---FTX-2 External Fuel Duct
@PART[fuelLine]:FOR[SETIctt]
{
    @TechRequired = advFuelSystems
}

//------\\

//---SETI-CTT---\\

//------\\

//---Tech Tree changes for UniversalStorage---\\

//------\\

//---US Food/Supply Parts

@PART[uS_1R320_Wedge_Food|US_Radial_R40_Food]:NEEDS[universalStorage]:AFTER[universalStorage]:FOR[sETIctt]

{

@TechRequired = recycling

}

.....Lets delete all of that then before we go on then

The radial tanks stay can stay put where they are. I see them as ugly and clumsy early attempts at live support. Before you get the more compact official TAC LS containers. The rest of it is of course different. The US TAC recyclers are indeed totally out of whack. I totally agree with you on that one. To be honest a lot of US should be after miniaturization and development of bigger stuff.

I have already fixed my game by putting all the resources back into the same nodes. I now understand why you pulled the food out as a separate case but my real life experience is telling me to put it back now before the next update. I have lived in a closed system and the freeze dried food is terrible but there is always enough.

You are however right about the resources themselves not reflecting progression. When developing life support systems the problem is the water supply. To get more of that that you need a big power supply and or a big RO filtration system. It runs into the cube root problem. A system twice as wide and tall as another will have eight times the weight, and require a far stronger support structure. The only way to combat this by increasing the efficiency. We should indeed be forced into developing better technology before going passed Minmus.

Well, not fully supported. But that section will be shut down anyway, when life support moves to enhancedSurvivability again.

I see the radial tanks mainly as parts for landers and rovers, on which they look great, imho. I ll just move them to enhanced Survivability as well, to concentrate life support parts there.

Yep, it was not about the food as a resource, it was about enabling beyond kerbin SoI missions, food containers were just the means to achieve that.

Anyway, with PP it is not practical, so it will be left to roleplaying.

Ah, okay, I see! So you know, you'd only have to do reintegration any time you accepted a pull request since only you have push access to your own repositories (unless you set it up differently, of course!). But it would probably be best to wait until you're rebooting the code anyway, yeah.

Dual booting, huh? How well does that work for you? Honestly, I don't shut down my computer often enough for that to be a viable option for me, despite how much I'd like to.

Not just directed at nobodyhasthis, but can anyone tell me what that makes the MM bootup section of the log look like? Both the :AFTER[] and :FOR[] tags are positional loaders, although FOR also creates an index if it didn't exist already, and I didn't think you could combine them (and if it's just being done to make a SETICTT mountpoint, you might be best defining it once as a dummy node).

Well, it depends on boot times. But I rarely play full campaign KSP these days, mainly specific missions and modding, so windows is ok for that.

I m no expert on module manager. But here is my reasoning behind it:

Since MM goes through the folders alphabetically and some mods already have CTT module manager patches, the :AFTER[xy] should ensure that my MM patch comes later, even if the mods GameData folder comes after SETIctt.

The :FOR[sETIctt] is for applying general patches (I often forget it now, but it was very important in the old SETI-BalanceMod).

For example I want to double all probe core EC values. But I also want to change a mod specific probe cores absolute base EC value.

So I would try a specific patch using :AFTER[mod] and :FOR[sETIctt]. The problem is, if my "double-EC" patch is in the SETIctt folder, it might get applied before the specific one, since that one would only come :AFTER[mod]. So I add :AFTER[sETIctt] to the general patch to ensure that it gets applied after the specific patches...

I essentially want to avoid the :FINAL statement whereever possible, because that one is a massive compatibility headache without end.

Sorry to butt in, but could you elaborate as to why our parts are so "out of whack"? My co-author Paul has put a ton of work into making those conversion rates as accurate as possible, alongside Roverdude and TaranisElsu. Any constructive feedback would be appreciated.

My main beef with Universal Storage is, that the US TAC Life Support recyclers are so imbalanced.

Imho there is but one gameplay reason to use TAC Life Support over other, simpler life support mods:

Recycler diversity

You have to really think about recyclers, if you want to use them.

I do not like the mass-balancing of TAC LifeSupport recyclers (I changed it for SETIctt and SETI-BalanceMod), but at least there is a progression. The large recyclers are heavier, but provide for more kerbals.

But here come the US TAC LifeSuppport recyclers. They weigh a lot less, but provide for far, far more kerbals than the original TAC Life Support ones...

Essentially you stick one US TAC LifeSupport recycler on a massive space station/base, and you are set. No need to think, one small wedge can support about 19 kerbals (water purifier or so)...

My proposal (what I implemented for the old SETI-BalanceMod):

One wedge supports 1.02 kerbals, based on the values from the big TAC LifeSupport converters, which support 9.18 kerbals.

On the mass side, I like the 0.155 tons (I would prefer 0.16tons for modular balancing, but that is nitpicking and I can easily set it myself).

For the conversion values, just take the big TAC LifeSupport converters as reference, but set a conversion factor of 1.02 (not 1.0, the extra 0.02 is a safety net for calculations and temporary inactivity - no power, kerbal on EVA and so on).

Also the EC definition for the converter parts:

1EC/s = 1kW = 1kJ/s

Currently the US Alkaline Fuel Cell has a mass of 0.155 tons, capable of producing 16EC/s, using Hydrogen and Oxygen.

Compared to the stock Fuel Cell, which has a mass of 50kg, capable of producing 1.5EC/s, using LiquidFuel and Oxidizer.

1EC/s = 1kW = 1kJ/s !

Everything else is a compatibility nightmare. And if the stock solar panels do not follow that, so be it. I do not use fuel cells instead of solar panels. A fuel cell using Hydrogen and Oxygen should be in line with other converters using hydrogen and oxygen. And hydrogen and oxygen are (to my knowledge) used by mods which follow the 1EC/s = 1kW = 1kJ/s convention, except for UniversalStorage.

I really like Universal Storage! It is an amazing mod, but I like at least somewhat balanced, fully modded (TAC, KSPI Extended, RemoteTech...) gameplay more.

edit: Stock is imbalanced enough, if I choose a life support mod, I really do not want it to become imbalanced due to another mod adding totally OP parts (recyclers).

Edited July 11, 2015 by Yemo

[Tahvohck]

I m no expert on module manager. But here is my reasoning behind it:

Since MM goes through the folders alphabetically and some mods already have CTT module manager patches, the :AFTER[xy] should ensure that my MM patch comes later, even if the mods GameData folder comes after SETIctt.

The :FOR[sETIctt] is for applying general patches (I often forget it now, but it was very important in the old SETI-BalanceMod).

For example I want to double all probe core EC values. But I also want to change a mod specific probe cores absolute base EC value.

So I would try a specific patch using :AFTER[mod] and :FOR[sETIctt]. The problem is, if my "double-EC" patch is in the SETIctt folder, it might get applied before the specific one, since that one would only come :AFTER[mod]. So I add :AFTER[sETIctt] to the general patch to ensure that it gets applied after the specific patches...

I essentially want to avoid the :FINAL statement whereever possible, because that one is a massive compatibility headache without end.

Hmm. I think I'll look into that once I finish up my own mod (of a mod). If I'm following you right, it might be better to do :NEEDS[mod]:FOR[sETICTT] (MM capitalizes all mod names), which will only run the patch if the mod exists, then run it during the SETIctt pass of MM.

If I understand the MM-ized load order right, first KSP loads up all the nodes it can read, including MM "patch" nodes, and then MM walks the tree and parses those nodes out (in order FIRST -> LEGACY -> BEFORE/FOR/AFTER per mod -> FINAL). That means you can modify nodes that have a "later" GameData folder even if you run in the FIRST pass. Of course any patches applied after that can modify it again, but specific to you, that's why you have initial things (i.e. tweaks to another specific mod) in the FOR[sETICTT] pass (or BEFORE, even) then things like "double-EC" in the AFTER[sETICTT] pass.

[Yemo]

Hmm. I think I'll look into that once I finish up my own mod (of a mod). If I'm following you right, it might be better to do :NEEDS[mod]:FOR[sETICTT] (MM capitalizes all mod names), which will only run the patch if the mod exists, then run it during the SETIctt pass of MM.

If I understand the MM-ized load order right, first KSP loads up all the nodes it can read, including MM "patch" nodes, and then MM walks the tree and parses those nodes out (in order FIRST -> LEGACY -> BEFORE/FOR/AFTER per mod -> FINAL). That means you can modify nodes that have a "later" GameData folder even if you run in the FIRST pass. Of course any patches applied after that can modify it again, but specific to you, that's why you have initial things (i.e. tweaks to another specific mod) in the FOR[sETICTT] pass (or BEFORE, even) then things like "double-EC" in the AFTER[sETICTT] pass.

Yep, but the problem is, I do not only want to modify nodes from a later GameData folder, i even have to modify MM patches from later folders.

So the later GameData folder has a patch like :NEEDS[CommunityTechTree]:FOR[universalStorage],

then my specific patch goes in with :NEEDS[universalStorage]:AFTER[universalStorage]:FOR[sETIctt],

followed by my general patch with :AFTER[sETIctt].

And I wish it was always that simple .

- - - Updated - - -

Oh, and regarding the update.

It is bigger as expected (as usual), but work is progressing nicely.

The main issue so far is, that the new ProceduralFairings seems to be incompatible with tech tree modding. At least I can not make it work.

Which is a shame.

[tim959]

I've got a question about the contracts pack.

Is it substituting the default contracts (all of theme) or just add a "new branch/series" of contracts to the standard ones?

I just started an heavily modded game (65 mods) with interstellar, tac, near future, far, CTT, etc. and was wondering if it'll remove the contracts I already have or just add some more balanced ones ?

I'd like to keep both to have more choices.

Thank you in advance

[Yemo]

I've got a question about the contracts pack.

Is it substituting the default contracts (all of theme) or just add a "new branch/series" of contracts to the standard ones?

I just started an heavily modded game (65 mods) with interstellar, tac, near future, far, CTT, etc. and was wondering if it'll remove the contracts I already have or just add some more balanced ones ?

I'd like to keep both to have more choices.

Thank you in advance

It deactivates those stock contract sets:

CONTRACT_CONFIGURATOR
{
    disabledContractType = RecordTrackContract
    disabledContractType = ExploreBody
    disabledContractType = WorldFirstContract
}

The record contracts were totally OP, the ExploreBody contracts followed a horrible progression curve and were non-declineable and the WorldFirstContracts (iirc) were buggy for probes.

As far as I know, it only influences newly offered contracts, though given recent experiences, I would not put it beyond squad to disimprove in that area as well.

Of course you could go SETIcontracts\CC-contracts\SETI-Contract-General.cfg and delete some of those lines or the whole bracket. But I would not recommend it.

Also, there is a list of contract packs I would try, if I would start a new career:

Anomaly Surveyor

Base Construction

Field Research

Kerbal Aircraft Builders

Kerbin Space Station

RemoteTech Contract Pack

SETI-Contracts

SCANsat Contract Pack

Tourism Plus

[Svm420]

The main issue so far is, that the new ProceduralFairings seems to be incompatible with tech tree modding. At least I can not make it work.

Which is a shame.

What do you mean?

[Landwalker]

@Yemo, and I apologize if this information is already available elsewhere (I couldn't find it in the 60 seconds my attention span lasted), but I just have a quick hit-and-run question re: the future fleshing out of SETI:

Are there any plans (or desires) to incorporate/fully support HGR and KW Rocketry?

I really like both mods, especially their additional engines. (I'm a parts-hound. Love me some parts. Especially engines.) I also really like the "bridge role" of the 1.875m HGR parts as an intermediate/pre-Rockomax lifter stage, so I would love to see these get properly assigned around the tech tree.

Yeah, that's my whole question.

I love what SETI is trying to do and am really looking forward to it, particularly with the contracts and tech tree.

[Yemo]

What do you mean?

The ability to resize the procedural fairing bases is now limited to tech node unlocks by the common.cfg.

Unfortunately I seem to be unable to alter those values using module manager. And I really do not want to start distributing custom config files again.

For example, this is an excerpt from that common.cfg:

PROCFAIRINGS_MINDIAMETER
{
  start = 1.00
  miniaturization = 0.400
  sandbox = 0.1
}

PROCFAIRINGS_MAXDIAMETER
{
  start = 1.50
  advAerodynamics = 4
  heavyAerodynamics = 12
  experimentalAerodynamics = 30
  sandbox = 50
}

If it is not my error in understanding, I hope they fix this shortcoming (especially for those tech tree which do not use the stock nodes as a basis.

It works for SETIctt at the moment, but some of the unlocks are just too late or in the wrong place.

@Yemo, and I apologize if this information is already available elsewhere (I couldn't find it in the 60 seconds my attention span lasted), but I just have a quick hit-and-run question re: the future fleshing out of SETI:

Are there any plans (or desires) to incorporate/fully support HGR and KW Rocketry?

I really like both mods, especially their additional engines. (I'm a parts-hound. Love me some parts. Especially engines.) I also really like the "bridge role" of the 1.875m HGR parts as an intermediate/pre-Rockomax lifter stage, so I would love to see these get properly assigned around the tech tree.

Yeah, that's my whole question.

I love what SETI is trying to do and am really looking forward to it, particularly with the contracts and tech tree.

Actually I m working on HGR at the moment, the 1.875m size would nicely fit into the new rocket/propulsion progression planned for the next update. Though I can not guarantee that I can finish those HGR configs for 0.9.1. That update will be massive anyway.

KW Rocketry is pretty low on my mod support list.

Together with Tantares and B9Aerospace, which are also nice but just very big. If someone is interested in contributing a config for those for addition to the SETIctt download, that would be great.

Though I strongly recommend waiting for 0.9.1, as there are quite some changes to the tech tree and the additional mod support should give a good indication for the intended progression.

edit: Also KW seems to need an update.

Edited July 11, 2015 by Yemo

[Landwalker]

Actually I m working on HGR at the moment, the 1.875m size would nicely fit into the new rocket/propulsion progression planned for the next update. Though I can not guarantee that I can finish those HGR configs for 0.9.1. That update will be massive anyway.

Great to hear!

KW Rocketry is pretty low on my mod support list.

Together with Tantares and B9Aerospace, which are also nice but just very big. If someone is interested in contributing a config for those for addition to the SETIctt download, that would be great.

Though I strongly recommend waiting for 0.9.1, as there are quite some changes to the tech tree and the additional mod support should give a good indication for the intended progression.

Yeah, I hear that... I like KW Rocketry, but it's a lot of parts. I briefly entertained the thought of doing it myself, and immediately concluded "Naaaaaaa." I'm unfortunately considering removing it entirely just to save some space, and because I don't like having KW LFO tanks popping up in Basic Rocketry when I don't even have LFO engines yet.

Also good to know that 0.9.1 is going to be a pretty significant update... I'm hoping to start a Mission Report log once I get all my mods settled in, and I'd love to use SETI, but obviously I don't want to start using something that's going to have a massive change two weeks later. I'm sure you're ready to kill everyone who asks this, but is there an ETA on 0.9.1? Just so I can decide to either wait, or wing it.

[Yemo]

Great to hear!

Yeah, I hear that... I like KW Rocketry, but it's a lot of parts. I briefly entertained the thought of doing it myself, and immediately concluded "Naaaaaaa." I'm unfortunately considering removing it entirely just to save some space, and because I don't like having KW LFO tanks popping up in Basic Rocketry when I don't even have LFO engines yet.

Also good to know that 0.9.1 is going to be a pretty significant update... I'm hoping to start a Mission Report log once I get all my mods settled in, and I'd love to use SETI, but obviously I don't want to start using something that's going to have a massive change two weeks later. I'm sure you're ready to kill everyone who asks this, but is there an ETA on 0.9.1? Just so I can decide to either wait, or wing it.

At the moment (if I do not encounter any more unforeseen issues), I plan for a release within the next 36 hours...

- - - Updated - - -

If you make a screenshot/imgur mission report blog, you could post it here, it would really spice up all the recent text walls.

Or at least link it here. That would be awesome.

[Landwalker]

At the moment (if I do not encounter any more unforeseen issues), I plan for a release within the next 36 hours...

- - - Updated - - -

If you make a screenshot/imgur mission report blog, you could post it here, it would really spice up all the recent text walls.

Or at least link it here. That would be awesome.

Awesome news, and I will definitely link it here (perhaps with occasional pictoral updates just to keep things interesting).