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

[Yemo]

@Yemo

Thanks again for this amazing mod. Looking forwards to trying out the latest update.

One quick thing: on the OP USI Survivability is not listed as being supported, the only place it appears on the page is in the development section.

Forgot to update that in the OP, will do it now, thanks!

what are we supposed to use to store Karbonite with this mod??

Whoops,

I m working on Karbonite support for the next version (with lots of rebalances, especially for the converters/generators), and I must have forgotten to delete the SETI-TechTree-USI-Karbonite-unused.cfg file from the SETI\MM-UnusedParts folder.

You can delete that file to get the normal Karbonite tanks back until 0.9.0, when they will be replaced by procedural tank type options for the liquid fuel tank.

I will make a small update later today, to correct that oversight. Thinking about it, I might introduce the Karbonite tank type option with that update, but I will not remove the normal tanks until 0.9.0.

Edited March 20, 2015 by Yemo

[Svm420]

Is it possible to restrict PP fuel tanks in diameter only and not length? I have found the restriction in career somewhat arbitrary for length as If I can't make it long enough I add another fuel tank. This just mean I now have more parts that I could eliminate if length wasn't restricted. Other than that I have been loving the mod! Thank you for the time and effort you have and continue to put into this!

[Yemo]

Is it possible to restrict PP fuel tanks in diameter only and not length? I have found the restriction in career somewhat arbitrary for length as If I can't make it long enough I add another fuel tank. This just mean I now have more parts that I could eliminate if length wasn't restricted. Other than that I have been loving the mod! Thank you for the time and effort you have and continue to put into this!

The volume restrictions are already much less limiting than stock for that reason.

But I have to say I thought about this limitation problem as well, when I started with procedural parts and then I just forgot about it.

It really appears to be just a restriction for its own sake, like the career action group restriction, which I simply do not understand.

And if the restriction would have been implemented now, without the stock game in the background, I probably would be as bewildered as I am regarding the action groups.

What about removing the restrictions alltogether from procedural parts?

length, volume, diameter

everyhing

The user still has to deal with the launch pad and vab restrictions. Also stack engines do not work well with tweakscale.

However it would be possible to just put 4x1 adapters beneath massive fuel tanks and then use 4 smaller diameter engines before unlocking the bigger ones.

Which would not be far from reality, especially looking at the early soviet rockets (while the us/von braun got a bit lucky with the large engine problems).

I ll think about that radical idea (including diameter restrictions abolishment) a bit more and wait for feedback about the proposal in this thread.

But I will discard the volume and length restrictions in the next update, like you suggested.

[Yemo]

New Version 0.8.5

IMPORTANT

• Update your Ship Manifest version, older versions do not show that they need updates with KSP-AVC
  
• KIS/KAS transition, see patch notes from 0.8.3
  
• KIS still needs the first round of bug fixes, so you might want to hold out until then
  
• New maxMods craft pack, see v0.8.4 patchnotes
  

New SETI-Guide in the second Post of the Forum Thread

Procedural Parts Changes

• Karbonite TankTypeOption added to Procedural Liquid Tank and Procedural Liquid Tank Cone, in preparation for 0.9.0
  
• Procedural Parts only limited by diameter, from now on (except SRBs and HRBs in the beginning)
  
• Changed Diameter upgrade techs
  
• HeavyRocketry: 2.5m, advMetalworks: 3.75m
  
• SRBs and HRBs upgrade to 3.75m diameter at veryheavyRocketry
  

Minor Changes and Fixes

• BugFix: Hiding of normal Karbonite tanks reverted until 0.9.0
  
• ProceduralParts modding file moved to 0ProceduralParts folder and broken up into the different pieces
  

[Errol]

When confronted with such dilemmas, as the author of the SETI-BalanceMod I tend to balance realistic gameplay restrictions (like not having fall back procedures, like energy savings) with realism restrictions (like the ability to turn batteries on and off without connection) to keep the game fun.

(origianly posted in the remote tech XF thread)

Hey there, I don't actually use the SETI mod, but like this idea. Is there a way that I can add this battery on/off without connection functionality to my remote tech install without the use of the seti mod?

[Lord Aurelius]

@Yemo

Doing away with the procedural parts size limits makes sense, I've been frustrated many times in the early game with the size restrictions. It's not like it's hard to work around (8x symmetry around a central core for width, keep stacking tanks for length, just like in stock) but it takes a lot of parts. One thing I would do to balance is to make the larger tanks exponentially more expensive as the volume increases so it's still more cost effective to have a cluster of smaller tanks, in real life the Saturn IB used a cluster of smaller tanks from existing rockets for its first stage and it would be nice to have some advantage in game for using that approach.

[Svm420]

@Aurelius

While from game balance it would be nice and make sense to reward alternative style like use many smaller tank as opposed to one big one, it was my understanding that Yemo was trying to reduce parts needed for many things because of the game's limitations. So I hope he won't incentive running more parts as that just leads to slower gameplay for little benefit IMO.

[Yemo]

(origianly posted in the remote tech XF thread)

Hey there, I don't actually use the SETI mod, but like this idea. Is there a way that I can add this battery on/off without connection functionality to my remote tech install without the use of the seti mod?

As far as I know, that is already possible with RemoteTech without further modding (I certainly did not mod that).

I remember having at least one battery switched off for emergencies (no connection/wrong positioning for solar panels) long before RemoteTech XF and SETI.

@Yemo

Doing away with the procedural parts size limits makes sense, I've been frustrated many times in the early game with the size restrictions. It's not like it's hard to work around (8x symmetry around a central core for width, keep stacking tanks for length, just like in stock) but it takes a lot of parts. One thing I would do to balance is to make the larger tanks exponentially more expensive as the volume increases so it's still more cost effective to have a cluster of smaller tanks, in real life the Saturn IB used a cluster of smaller tanks from existing rockets for its first stage and it would be nice to have some advantage in game for using that approach.

@Aurelius

While from game balance it would be nice and make sense to reward alternative style like use many smaller tank as opposed to one big one, it was my understanding that Yemo was trying to reduce parts needed for many things because of the game's limitations. So I hope he won't incentive running more parts as that just leads to slower gameplay for little benefit IMO.

I really like the no length, no volume restrictions as implemented since 0.8.5.

Though I m still hesitant about the no diameter restrictions. With 0.8.5 they have been changed, so that 3.75m is available at advMetalworks (so earlier than veryheavyRocketry).

If they were to be abolished alltogether (so that 3.75m tanks are available, but only 1.25m engines), I bet many new users would make a giant fuel tank and strap lots of radial engines on it, or many stack engines with the multi-thrust plate...

About SETI development:

While I commented out the Karbonite-unused changes for 0.8.5, this time I forgot to delete the half-done TechTree-Karbonite and PartMod-Karbonite configs...

So if anyone is wondering about changed stats/tech tree locations for Karbonite, that is the reason. Having to watch out for 2 versions is just a pain.

But, most chances are opportunities.

With the problems/changes regarding MCM/MKS/OKS, the half-way released Karbonite and the KSPI extended info from Freethinker, this is the new release plan:

0.8.6: Karbonite

0.9.0: KSPI extended

When in a more suitable state: MCM/MKS/OKS/EPL

Until MCM/MKS/OKS/EPL is "rebalanced" by SETI, I will list them in the "Additional Mods" section in the OP. There will be inconsitencies, especially regarding life support containers/masses. But it is just not time/work-efficient for me to half-way rebalance them and then have to do it again when MKS/OKS is rearranged/changed by RoverDude. And I can not really support/rebalance MCM until the mass calculation bug is fixed by Angel-125.

Maybe I ll release some minor configs for them, to keep the inconsistencies with SETI to a minimum, thus making them "inofficially supported". Nothing drastic or functionality altering.

I will also take a look at USI Exploration and USI FTT after Karbonite is done and add those somewhere in-between, depending on workload. Imho makes sense for base/station building, regardless of whether you use MCM or MKS/OKS or something else.

SETI-Greenhouse

Because of the development/support changes above, SETI is left without an officially supported "food producing life support module" for the near future.

I looked around and found various greenhouse mods, though none of them did exactly what I wanted them to do, providing a simple yet adaptive (to different mod installs) greenhouse.

There were some which came close, but they were not updated/supported for a while.

So I will most likely make a Greenhouse mini-mod, using the model by zzz.

Since zzz released his models into the public domain, that only leaves the config, which I estimate to be very short work (though I want it to not skew the balance if MCM/MKS/OKS is installed).

For the release, there are essentially 4 options:

[TABLE=width: 880]

[TR]

[TD][/TD]

[TD]Pro

[/TD]

[TD]Con[/TD]

[/TR]

[TR]

[TD]1. Included within the SETI download

[/TD]

[TD]No additional download necessary.[/TD]

[TD]Can only be used by SETI players.

Increases SETI minimal RAM usage.[/TD]

[/TR]

[TR]

[TD]2. SETI-download + Separate download,

both within SETI folder

[/TD]

[TD]No additional download necessary.

Can be used by everyone.[/TD]

[TD]Increases SETI minimal RAM usage.

Higher maintenance effort for me.

CKAN incompatibilities (overwrite).[/TD]

[/TR]

[TR]

[TD]3. SETI-download + Separate download,

different folders[/TD]

[TD]No additional download necessary.

Can be used by everyone.[/TD]

[TD]Increases SETI minimal RAM usage.

Higher maintenance effort for me.

Double Installs possible.[/TD]

[/TR]

[TR]

[TD]4. Separate download only[/TD]

[TD]Can be used by everyone.[/TD]

[TD]Additional download necessary for SETI users.[/TD]

[/TR]

[/TABLE]

So, 1 to 3 increase the minimal RAM usage of SETI, regardless of whether players want to use the greenhouse or not (which kind of goes against the SETI clutter reducing maxims).

2 and 3 both increase incompatibilities, possible issues and my maintenance effort (which in turn decreases the time I can spend on supporting other mods).

Also, since I would essentially only write/modify a small config, while the model itself was released to the public domain by zzz, restricting it to SETI users would only feel ok, if there were other maintained, similar Greenhouse only mods around (using this model). Which does not seem to be the case.

Considering the points above, the additional download for SETI users appears to be the smallest con and leaves SETI users with the choice.

Edited March 21, 2015 by Yemo

[Lord Aurelius]

@Yemo

I can see how some diameter restrictions would be beneficial as long as they're not as restricting as they are currently, that would also serve to give a purpose to a Saturn IB style rocket.

Agreed, a greenhouse minimod should be separate from the main SETI install. It sounds like the least work, and it's minimally more effort for someone who is already going for more than the minmods install (which doesn't even have life support anyways).

Also, USI Survivability is in the gameplay/info section on the OP, wouldn't it make more sense to be in the part mods section?

[FreeThinker]

KSPI extended is now SETI ready

[Svm420]

Thought this had been suggested here, but a quick search for the term EVA turned up unrelated results. So i suggest the mod EvaFuel this mod makes it so that a kerbal removes 5 MP from the pod when going eva whatever you return with is added back to the pod. So in all it "converts" evaprop to MP without really changing much and it is 0.90 compatible fully. It is an awesome simple change that make the MP in stock and most mod command pods make sense and have a purpose. I know you purposely removed all MP and for good reason at the time, but with this you may only need to reduce MP available or just switch it to start with 0, what i did in my own game, in CPs with the player having to go in and add the wanted fuel for EVA/RCS. Can not wait for KSPI E now I just have to figure out which solar system resize I want...

[Yemo]

@Yemo

I can see how some diameter restrictions would be beneficial as long as they're not as restricting as they are currently, that would also serve to give a purpose to a Saturn IB style rocket.

Agreed, a greenhouse minimod should be separate from the main SETI install. It sounds like the least work, and it's minimally more effort for someone who is already going for more than the minmods install (which doesn't even have life support anyways).

Also, USI Survivability is in the gameplay/info section on the OP, wouldn't it make more sense to be in the part mods section?

The multiengine rockets were one of the reasons why I changed the 3.75m diameter restrictions to advMetalworks, so they are available before the 3.75m engines at veryHeavyRocketry.

Though I could not fit the 2.5m diameter upgrades before the 2.5m heavyRocketry engines, because it would have been too early after unlocking the basic rocket engines.

But your Saturn IB reference brought me to another idea:

What if it is done the other way around?

The 2.5m procedural unlocks stay at heavyRocketry, while the 2.5m engines are moved to heavierRocketry and thus after the R&D upgrade.

Multi engine rockets are a side effect/possibility at the moment, though they were very common in reality.

With that change, players would routinely have to use the adapters at generalConstruction, to make use of 2.5m rockets before the R&D upgrade.

And it would set a real pattern, reflecting the historcal challenge that larger fuel tanks were available, but sizing up rocket engines proved to be difficult!

The greenhouse mod seems to be really easy to do, only the balancing will take some effort (and maybe some iterations).

Inspired by some requests on the MKS/OKS thread, it will not require life support, if people just want it for "flair".

Corrected the USI Srv placement, thank you!

KSPI extended is now SETI ready

Great! I will wrap up some loose ends in 0.8.6 and then I can fully concentrate on KSPI extended for 0.9.0, thank you very much!

- - - Updated - - -

Thought this had been suggested here, but a quick search for the term EVA turned up unrelated results. So i suggest the mod EvaFuel this mod makes it so that a kerbal removes 5 MP from the pod when going eva whatever you return with is added back to the pod. So in all it "converts" evaprop to MP without really changing much and it is 0.90 compatible fully. It is an awesome simple change that make the MP in stock and most mod command pods make sense and have a purpose. I know you purposely removed all MP and for good reason at the time, but with this you may only need to reduce MP available or just switch it to start with 0, what i did in my own game, in CPs with the player having to go in and add the wanted fuel for EVA/RCS. Can not wait for KSPI E now I just have to figure out which solar system resize I want...

Thank you for the suggestion, I will take a look at it!

While I deleted monoprop from the command pods in earlier versions, most of them got it back.

LanderCans have an especially large amount of monoprop storage at the moment, this mod would further increase it's usefulness.

Though I'm not sure I want to give the Mk1 pod monoprop, it is already very cramped/dense. But maybe that makes sense as well, since in early career (when the Mk1 is first available), you can not EVA. So EVA fuel would not have been a requirement in the Mk1 design and needs to be added separately.

Edited March 21, 2015 by Yemo

[Svm420]

Really like that idea for engines even with a part increase. Sound like a good change as I don't think I've ever really use the adapters except for in science or sandbox mode maybe a few times on uppers stages. That would been a interesting and fun change to try.

[Yemo]

Found another option for the Greenhouse:

SETI-download + SeparateDownload

same folder but outside of SETI

That would fix all cons.

1. CKAN ignores stuff outside of the SETI folder

2. Manual SETI downloaders can still decide if they want to copy the SETI-Greenhouse folder

3. Double install not possible, since you would overwrite

4. I do not have higher maintenance, since I would just select one more folder when making a new SETI update

5. SETI users do not have to do a second download, just drag and drop one more folder into GameData

The greenhouse concept is very intriguing, I really want to add it for 0.8.6...

And the 2.5m engine shift to heavierRocketry.

[Lord Aurelius]

More reason to use the adapters is always good, I enjoy building a good engine cluster. I've resorted to building excessively large rockets (1,000 tons to LKO) to have an excuse to use a cluster.

[Papa_Joe]

Anyone have a game save with Remote Tech antennas? I need one to test out integration with RT. RT antennas are not showing up in the SM control window. I need to see what is persisted to get a handle on what to look for..

Thanks in advance to anyone willing to post a gamesave for me.

Update: Nevermind. I downloaded RemoteTech, created a ship with the appropriate antenna, and tested. Remote Tech antenna support will me coming in the next release.

Edited March 22, 2015 by Papa_Joe

[FreeThinker]

KSPIextended is going even further into 6.4 scale direction, while KSPI NF integration is intended to be more stock compatible in terms of engine/reactor performance.

So it would make much more sense to support KSPI NF integration for SETI.

Unfortunately, KSPIextended is the version which is currently developed and which has the CTT support...

Let me get this clear. KSPI NF is no longer beeing developed, instead KSPI Extended adapts to NFT-E / SETI power level when installed. If you think something is not balanced, contact me and I will make the required changes.

- - - Updated - - -

Can not wait for KSPI E now I just have to figure out which solar system resize I want...

For KSPI Extended I would advice the Paul KingTiger 2k , as this mod only doubles the size of kerbin which makes it perfect for experienced players that want to keep stock/SETI/NFT feel with slightly increased challenge (using FAR/NEAR)

[Graploos]

So i just installed the mod and i'm trying to do the 18KM mission. I can get up there and land with a kerbal, but the mission won't complete.

Weird thing is, the 18KM is not on the objectives list only in the description. Did i get a bugged contract? or am i mission something else?

--edit--

NM. Retook the contract and used one of the provide ships, now it did complete,

Edited March 22, 2015 by Graploos

[Yemo]

So i just installed the mod and i'm trying to do the 18KM mission. I can get up there and land with a kerbal, but the mission won't complete.

Weird thing is, the 18KM is not on the objectives list only in the description. Did i get a bugged contract? or am i mission something else?

That is weird, I did not encounter a problem with the 18km missions.

Maybe a corrupted download for one of the involved mods (SETI, ContractConfigurator 0.7.2)?

Or did you install other contract configurator non-mod specific progression contracts (which you shouldn't)?

[Graploos]

The contract mentions the name of the ships your provide with the install. Does that mean you have to use them to complete the contract?

[Yemo]

The contract mentions the name of the ships your provide with the install. Does that mean you have to use them to complete the contract?

There is no reference in the contract config to the provided vessels.

But, as far as I remember, the manned contract logs the name of the manned vessel which launches/reaches 18km (not sure). It then wants that same vessel to be landed again in order to recognize the contract as completed.

The basic idea behind it was, that you can not just launch a kerbal above 18km and claim the reward while letting the kerbal crash after "fulfilling" the contract.

Basically after accepting the contract, you only have to launch a kerbal beyond 18km and then let at least the kerbal containing part of the vessel land on kerbin again, using parachutes.

If you use the provided SETI High Altitude Rocket, you essentially just have to launch that with SAS activated, then stage when you are at the highest point to decouple the lower part and arm the parachute (right click on the parachute and select "Arm").

Everything else should be automatic.

[Graploos]

Oh well, i got it to work. Maybe i did something weird/wrong or it bugged out. But dropping the contract and retaking it fixed it.

Thanks for replying

Enjoying the mod so far. First time i play with FAR and procedural parts, lots to learn.

[Yemo]

Oh well, i got it to work. Maybe i did something weird/wrong or it bugged out. But dropping the contract and retaking it fixed it.

Thanks for replying

Enjoying the mod so far. First time i play with FAR and procedural parts, lots to learn.

Ah, good to hear.

I m working on something like a SETI-Guide in the second post of this thread, any feedback is appreciated!

Also, for FAR aircraft design, I recommend this guide by keptin: Basic Aircraft Design

[Yemo]

While working on 0.8.6 and the SETI Greenhouse, I once again bumped into the ec definition mess.

So I finally decided to balance/standardize that to the most commonly used 1ec/s = 1kW = 1kJ/s.

The planned EC rebalance will have massive ramifications for all vessels.

I m trying to keep the issues as small as possible, but with the wide variety of definitions used at the moment (1ec = 33J to 1ec = 30kJ or something), that will hardly be possible.

Preliminary findings:

1. Alkaline Fuel Cells

Especially the alkaline fuel cell from universal storage (1ec = 33J) and it's stop gap derivative will have to be broken.

It seems to be 30 times more efficient than it should be, if the formula was set up correctly with the 1ec = 33J definition in mind.

If anyone knows a good realistic formula for the alkaline fuel cell, please tell me (energy output per gram of hydrogen and oxygen input, I will then reconvert that to the volume units used for hydrogen and oxygen).

2. Solar Panels

Solar panels are way too efficient for their size, by a factor of 10.6 or more, but are also much too heavy for their size...

To distort them not too much, I plan to use a 2-way approach:

a) Increase their model size by a factor of about 1.65 or 2.3.

Lower their energy output by a factor of 4 or 2, so that they would either produce only 25% or 50% or their current output.

c) Adjust the mass, somehow. Any input is very welcome!

d) Not sure what to do about the flat solar panel.

Choosing whether to go with the 25% or 50% output (and the corresponding model size increase) is a tough choice.

I think it may depend on whether I can/have to change the values for the RemoteTech antennas and dishes.

So if anyone has input on that, please tell me!

3. Batteries

Batteries are much too weak at the moment in terms of volume and mass.

a) Rebalance their volume and mass.

Adjust their ec capacity.

As a comparison, the rebalanced Z-100 battery (using Ven's Stock Part Revamp models) is planned to have:

a) 2L volume instead of 16L (50% scale), still 5kg mass

2500 ec capacity, instead of 100 ec

4. Probe Cores

Seem to be reather okish with the new ec standardization, a probe core would need about 20W to work

5. Reaction Wheels

I do not know enough to rebalance those

6. RemoteTech Antennas and Dishes

That is a tough one, which will lead to problems with the fuel cell and solar panel rebalance on existing sats...

I do not know what definition of ec was used, when the energy consumption of their antennas and dishes was determined.

If anyone knows how many Watt are used for eg 2500km space omni antennas, please tell me!

And for dishes with the remote tech cones as well!

Edited March 23, 2015 by Yemo

[Papa_Joe]

While working on 0.8.6 and the SETI Greenhouse, I once again bumped into the ec definition mess.

So I finally decided to balance/standardize that to the most commonly used 1ec/s = 1kW = 1kJ/s.

The planned EC rebalance will have massive ramifications for all vessels.

I m trying to keep the issues as small as possible, but with the wide variety of definitions used at the moment (1ec = 33J to 1ec = 30kJ or something), that will hardly be possible.

...

I'm facing the same issue with resource transfers using SM. Already I've been asked how this will scale, how densities / volumes will affect it, and what the impact would be. As I mentioned in my thread, I'm proposing a ModuleResourceXferPump, where we can configure transfer rates, ec consumption, etc. I'll be interested to see what you find out...

Edited March 23, 2015 by Papa_Joe