ksp-ro / rp-0 Goto Github PK

In #35 Felger mentioned KCT, and also in magico13/KCT#17 @magico13 asked what we're looking for. Thus I'm opening this issue so we can brainstorm what additions/changes/etc to KCT we're looking for.

We've tossed around the idea of manufacturing cost being different from launch cost. That's something to consider, with perhaps multipliers for "payload has never flown", "crewed mission," etc. Further, KCT can handle integration costs, and per-launch infrastructure costs (per-pad infrastructure costs would, I guess, wait for 0.90).

@magico13 has already (thanks so much!) added support for RSS's multiple launch sites, and for configurable time per science point (to unlock nodes).

Other thoughts:

• Time to unlock parts (Development, as well as research, takes time).
• Deep integration with PP (the idea of stretches and propellant changes requiring very little money and time, whereas diameter changes need new tooling)
• Recognizing subassemblies (an oft-used upper stage is far cheaper and faster than a hand-built one)
• Manufacturing lines (say you want to pay a sum in time and money to set up a manufacturing line for a sub-assembly; you then get, say, one stage [subassembly] every few months). You can expand the line, or freeze it, as time goes on costs go down, minor changes don't require new lines, etc.

Further thoughts?

Just installed the latest RO + RP-0 from CKAN, and started a new career. Noticed that the procedural parts (fuel tank, SRB, decoupler, etc.) were marked as non RP-0, unlike previous versions (as far as I know). Is this intended? I thought the size limits from earlier worked ok...

If the player has FASA installed, the Mercury capsule is available for 3,730, a decent chunk less than the Mk 1 at 4,400. The Mercury also weighs less (by about 100kg), and can withstand higher temperatures, although it's less crash tolerant.

This is mainly an "are we sure?" check. It seems more fair for the Mercury and Mk 1 to be the same cost and weight.

Some of the strategies are game-breakingly over-powered, like outsourced R&D. This Mod balances them out well, I think:

http://forum.kerbalspaceprogram.com/threads/96230-0-90-Sane-Strategies-0-42-1-Dec-18

What it says in the title. :)

Also, it shouldn't cost 300k for a radial case.

Year in parentheses is date cost was taken; cost unless stated otherwise is in 1965 dollars.

Atlas (1960): 2.69m per LV
Redstone (1960): 1.076m per LV.
Little Joe (Mercury, 1959): 200k per LV (unclear, this may just be for the construction work, not including the 4x Castor in it) in 1959 dollars.
Vanguard (1958): 1.48m per launch (not per LV).

Please add anything else you know of!

Steps to reproduce:

• Start a new game
• Go to mission control
• Observe the lack of contracts
• Time warp forward two weeks
• Still no contracts
• Sucks to be a space agency. :)

I know there's a setting to fix this, we just need to find it. ;)

Right now Real Solar System only ships with a custom biome for Earth. It would be really nice to have custom biomes for other bodies. I have this map which I seem to recall SpacedInvader made for the moon, but I don't have a license for it, nor have I tested it at all.

Any extra biomes would probably best be backed up in the RSS distribution (or as their own stand-alone distro), but I'm raising this because lunar biomes are fun, and increases the amount of early-game science and exploration players can do.

It would be great to have tree.yml serve not just for placing parts but for modifying (via MM) nodes in the CTT. In particular, it would be great to give nodes new titles and descriptions.

Long term, that might be where we want to do any node swapping, or changing position / requirements.

Here is a very useful little bit of help from DMagic.
http://forum.kerbalspaceprogram.com/threads/90974-WIN-SCRIPT-EXTERNAL-PMCSE-Poor-Man-s-Contract-Science-Eraser?p=1525346&viewfull=1#post1525346

Here is the list of probes launched 1957-1962, with their experiments, kindly catalogued off Gunter's Space Page by forumer JRA.

It should provide a great base for a discussion of what experiments we should add or re-target, not least because adding different experiments to different probe cores is a great way of dealing with #42.

What are our core dependencies for RP-0? Those things which we require the user to have installed in order for things to work. Ideally, as a lightweight RO experience, these should be as few as possible.

Since we require RealismOverhaul, that already gives us a list of things which we know will be installed:

• AJE
• DeadlyReentry
• EngineIgnitor
• FerramAerospaceResearch
• ModuleManager
• ModuleRCSFX
• RealChute
• RealFuels
• RealSolarSystem
• TACLS

In addition, we require:

• SXT
• ProceduralFairings
• KerbalJointReinforcement

Stock KSP simply does not offer sufficient engines for RO, especially given the choices RO makes about what to assign each engine to be (while the LMDE and LMAE could work as upper stage engines, because they have been scaled such that the nozzle is the correct size, the tankbutt is gigantic). The tankbutt issue might be solved by switching RO to using Ven's Stock Parts Revamp, which has sane-looking (indeed, quite pretty and reasonable), no-tankbutt engines, but we still have the issue of engine choice and limited supply.

Given that all (AFAIK) of the US engines stock parts are turned into are also in FASA, it might be worth considering changing what the stock engines are made into; but even were that to be done, it does seem the case that we need more engines than stock provides, especially because we have needs that stock KSP does not have (verniers, 5ton to 2500ton LVs, etc).

I am opening this so we can brainstorm what engines are actually needed. I have been tossing around the idea of Start tech as sounding rockets, Basic Rocketry as Vanguard/R-5, General as Atlas/R-7 level. That means at minimum we would need:
*A sounding rocket engine, either 30kN for small or ~300 for large (see below)
*A Vanguard lower stage in the 140-300kN range (perhaps combined with the sounding rocket engine if the V-2 or Jupiter C is our sounding rocket example), or if we go the Jupiter C / R-5 route, 400kN.
*A Vanguard liquid upper stage in the 30kN range (perhaps combined with the sounding rocket engine if the WAC Corporal / Aerobee, on a solid booster, is our sounding rocket example).
*the LR-89/LR-105 combo, or the RD-107/RD-108 combo: For Atlas, that means 350kN core, 750kN boosters; for R-7, 900-1000kN for each.

If we are willing to treat the H-1/RS-27 as an outgrowth of the LR-89, we can have the LR-89 be our H-1 and RS-27/RS-27A as well.

Moving on, we will need enough "oomph" to launch crewed BLEO missions. That means that the RS-27A is not sufficient. The options here are F-1 and J-2, or NK-15 and -15V (later developed to -33 and -43).

What do you all think?

Right now it's possible to pick up a lot of money by putting
"sounding rockets" into orbit, waiting until they pass a contract
height, picking up the next contract, and repeating. The same
vessel can pick up many, many contracts, especially if it's going
some ways out.

I don't know if we can have the contract code only ask for an
altitude higher than the current apoasis in game; but that would
be nice to make sure the player has to do at least some work for
their efforts; even if it's just burning some fuel in an existing
ship.

Also, a lot of the altitude records seem to be very close together.
The difference between 14Mn and 15Mn isn't that much once you're getting
to those altitudes. I'd try to have each record be somewhere between 25%
and 100% higher than the previous one. (Also, it's 0420 and I haven't
really looked at the source, so maybe we're already doing that and
I'm just getting really lucky.)

During load, as NyanCat merrily dances across the screen, we get oodles of **RP0 error messages with caught NREs. I'm guessing those parts aren't fully loaded yet.

These are harmless, but I'm wondering if we could activate ShowModuleInfo only when in the VAB/SPH?

As I was thinking about the early space race, I had a thought. This is a longer-term thought, since we should get things up and running "normally" first, but what if...

At the start of the space program, contracts don't give you money. They might give you science, but what really matters is reputation. You get funding from the government based on your reputation (perhaps we should integrate Punish The Lazy, so it goes down over time...or perhaps reputation stays constant but the budget per unit of reputation goes down over time?). Ideally, you would get most of your funding at the start of the fiscal year.
As you do more and more prestigious things, you get more and more funding. As time goes on, commercial contracts start appearing to supplement your income (sounding rocket launches, FP orbital contracts, science from body x contracts, etc). You can, however, ignore them and go only for the prestige, err, reputation contracts.

Thoughts?

But starting engines get as large as 2m. I think we should remove the limitations on interstage size.

Proc nosecones (and presumably other proc parts) are also too expensive.

When parts don't say "non-RO", people tend to think that means RP-0 supports them. We should at the very least tag unsupported parts, IMO, and consider hiding them.

In KSP, the default is crewed space missions. Contracts, with the exception of flag-planting contracts and altitude records, are written under the assumption that they will be flown by kerballed craft, though they can also be completed by probes (though probes do not unlock until late).

RP-0, however, presumably has a sharper delineation; in particular, we should I think have a separate set of Human Spaceflight contracts which have considerably higher rewards (and penalties), and we should assume that all contracts are meant for probes unless they obviously are not (i..e "build a base").

What are everyone's thoughts on how to deal with a sharper contrast between uncrewed spaceflight and HSF? First, should there be one? Second, if so, how do we create it?

I seem to get wildly varying SRM costs. I think we should assume, on 'nautix, that an un-yeared cost is in 1985 dollars, though I am not positive. I think that means that the Castor 1 (the motor used in the Sergeant missile, 4x in Little Joe, as strapons for early Delta / Thorad, etc) is about $270k and the UA1205 is about $5m (with costs projected to fall to $2.4 in the 1970s after cost saving measures for Apollo Applications Program use, per a Bellcomm report). This means that costs do not appear to be linear, which is bad news for Proc Parts. Need more info...

For now I have gone with:
SF costs $62.3/liter ($35/kg).
Proc parts SRB costs $40/liter empty + $(thrust_in_kN * 0.25).
So in total ~$102/liter + $0.25/kN thrust.

This idea is possibly crazy.

Last night I was thinking a lot about biomes. For me, they make the game more fun, because I've got motivation to try and land in a crater, or fly over a certain region. #2 discusses how they'd give players motivations to do things like analyse the Great Red Spot on Jupiter, or land on Olympus Mons on Mars.

However RSS is impoverished for biomes; we have them for Earth, and maybe for the moon. We don't have them for anywhere else.

I'm wondering about thoughts of either having RP-0 set in the 6.4x system, or making it 6.4x compatible. Advantages would include:

• Full CustomBiomes support.
• Full OpenResourceSystem support.

For players going the resource exploration route, this is a big win. It means that we have resources and biome information for all planetary bodies for free.

What I would love even more is CustomBiome and ORS support for the whole of RSS, but that involves someone doing the hard work of producing all the maps.

I have no idea if this is easy or hard. I know that @NathanKell has been playing 6.4x, and so may have additional insights. :)

~ Paul

The LR-79/89 has no vernier making it much less useful. Could the stock part be moved to the same node as it? Also maybe launch clamps moved to the first node as it makes launching much easier?

I have no idea why. All the code looks like it should. The probe reports are just fine, but I can absolutely, 100% confirm that for me the temperature sensor treats all of low space as a single biome.

This is mostly a reminder for me to investigate more.

A common issue complained about in Stock is the preponderence of science points you can gain by farming Mun, Minmus, and Kerbin, to the point where you can complete the entire tech tree by farming science in-system only, without venturing out into the solar system.

Obviously, we don't want to encourage that behavior in RP-0, and I would like to include a game-mechanic means of promoting that behavior.

Suggestion - Each time you collect science from a particular body, the science reward for that experiment for that body goes down by a factor, with a maximum amount of science (based on biome number) possible. Example:

• Luna has 8 Biomes, and there are 4 conditions available giving a total possible number of combinations of 32.
• By default, let's say our experiment would grant 50 science per biome, which comes out to 1600 science for just the one experiment. Way too much without leaving the local system, not even considering science bonuses for contracts and the like.
• Instead, we reduce the science per-biome and condition for each time the experiment is run on the body, or perhaps in the body-condition pair.
  • Say, twice the science value - 2*50 science per Body/Condition pair: 400 science for our example.
  • Then, each time you collect science the amount you gain from that experiment goes down, since some of your data is redundant.
  • I've tinkered with the scaling in excel, and found a decent curve that never returns negligible results, but hits the cap after ~10 experiments:
    
  • Equation that produces this:
    
  • Where S_0 is the previously returned value, S_Total is the total available science (400 in this case)

Obviously this isn't the only way to do this, but I like the idea of artificially limiting the total gains you can get from science in one particular area, encouraging you to branch out in the rest of the solar system, without making the game feel like a grind, grabbing biomes and the like.

But somehow I don't think it's going to be that easy for us to get there. :)

I said I was going to open an issue on this; must have forgotten.

What do we think about rescue missions? Some ideas:

1. Remove them completely.
2. Assume that there are other space agencies, and thus merely correct any weird orbits.
3. Only enable them when craft are in orbit, and remove the kerbal from a random craft.
4. Only enable them when craft are in orbit, and remove all kerbals from the craft and destroy the craft.

After making a comment on the RP-0 IRC channel about goals, I've realised that I have an idea of what I'd like to see:

RP-0 is a consistent, minimal requirements base career in the Realism Overhaul universe onto which players can add feature modules as they wish.

This means if someone just wants to download and play with RP-0, they can. It's easy for people to get started.

But it also means that if people want to add extra features (colonisation with MKS/OKS, resource exploration with Karbonite/Kethane, economy adjustments with Kerbal Construction Time, etc) then that's possible.

In many cases, we can use ModuleManager to detect what's installed and have it just work. If someone installs MKS or a part pack, then that should have placement in the tech tree and other tweaks as required. But it also means we may have additional feature modules designed specifically for RP-0, such as difficulty (easier/harder), economy changes (such as parts getting cheaper more often you build them), part reduction (I like to hide all the fairings if I have procedural fairings installed), or otherwise. These additional features might be additional downloads, but we provide the base to make them happen.

Of course, it's my hope that players will install RealismOverhaul and RP-0 using the CKAN, as this reduces the install down to ticking a box and hitting "go". Consequently, it will be easy to provide players with a set of recommended and suggested feature packs on install. That makes for a wonderfully customisable game.

I'm mentioning this now because I'd love for third-party extensibility to be one of our goals, as I believe that will greatly increase the robustness and playability of the game.

A Z-200 scaled to 1.25m costs 2881, holds 164k of charge, and weighs ~ 0.6t

A proc parts service module of the same dimensons (1.25m x 0.4m) and utilisation
dropped to hold the same charge (33%) costs 1622 and weighs 0.473t.

Consequently, it looks like it's much cheaper and weighs less to use a service
module rather than a stock battery for holding charge.

Also, procedural batteries seem to be limited in width. I'm not sure they should be. :)

I've already begun this work, since I'm feeling like the biggest gap in RP-0 as being a career component is the lack of realistic contracts. The only additional contract types that RP-0 currently adds is the sounding missions and a person-in-orbit mission, both of which are trivial to implement using configurable contracts.
Benefits of using Contract Configurator instead of coded contracts include:

• More accessible to create and modify, since it does not require a development environment
• A rich variety of contract parameters that can include scientific research, docking, sequences of steps to be completed, generated ships with crews, multiple involved ships, built-in support for RemoteTech and ScanSat.
• Includes an extensibility API that can be used if additional capabilities are needed.
• Contracts can be added, removed and changed without having to restart KSP.
• Upcoming (in a week or two) debug window that graphically shows the state of the different requirements and parameters of your contracts.

I've already written config files that could replace the two built-in contract types, but I'm even more interested in hearing some ideas for some contracts that could be used as proofs-of-concept for the idea of using Contract Configurator.

Universal storage is pretty cool. It makes ships which look awesome, and combined with DMagic Orbital Science addresses this addresses the problem of stock parts looking less than awesome, because experiments like the Science Jr and Goo are available in wedge form.

However we currently have the US parts costing more than their stand-alone counterparts. This encourages players to build cruddy looking ships rather than AWESOME ones. We don't want players to be penalised because their ships are functionally equivalent, but look much cooler.

I think it's reasonable to charge the players extra for the US cores (it's a one-off cost for a structural part), but I'm planning on making the part costs the same for US and non-US parts.

FASA introduces the geiger counter, which is awesome, and doesn't appear in stock. It would seem reasonable for balance to give the (non sounding-rocket) cores an integrated geiger counter, if and only if FASA is not installed.

Can likely be done by MM code: add to all cores, remove form the sounding rocket avionics, but only if FASA is not present.

So I tried to put some goo into orbit today and found it to be a real challenge, which is good, though it might be a bit too hard? That might be me though and the fact that i'm trying to do it at Early Orbital rather than later.

One thing I noticed though is that the Stack version of the goo masses twice that of the Radial version. Now at first this might seem logical. If someone uses the Radial Goo then they have to place two of them for W&B right? So let's make the Stack Goo, of which you would only place one, weigh the same as those two Radial Goos.

Problem with that reasoning, in my mind, is this. What do you get for the mass? If you carry two Radial Goos, you get two different science experiments. If you carry one Stack Goo you only get a single experiment. So for the same mass, you get less science. Unless you absolutely positively have to have that Stack Goo, there really is no reason to use it due to the mass cost. If you are like me, and considered using it just because of looks, and you don't want an oversized fairing, then it is a really hard choice to make because you are intentionally gimping yourself, which isn't fun.

I would argue that the Stack Goo should mass the same as a single Radial Goo, so that the Mass:Science ratio is the same. If that isn't acceptable then at most 1.5 times the Radial Goo, though if a 1:1 ratio isn't acceptable I would prefer something like 1:1.25 maybe.

Thoughts?

RO players are going to be using a lot more unmanned probes than stock players, so let's map out the progression of probes. You can edit this top-post if you're an RP-0 contributor.

We can have a separate ticket for HSF pods.

I figure we can start off by determing the order in which probes should unlock, we can figre out where to place them later.

Right now the first three probes the player unlocks are (with cost, weight and energy consumption rates):

• Sounding rockets avionics (2, 0.06, 6/min)
• Dontstayputnik (300, 0.0836, 3.6/hr)
• Okto2 (1,000 0.05, 3.6/hr)

Unsorted probes include:

• QBE (600, 0.512, 3/min)
• Ranger MkIII Core (450, 0.18, 36/hr)
• OKTO (450, 0.75, 4.5/min)
• RC-L01 (2000, 0.85, 3.6/min, remote command)
• RC-001S (750, 0.4, 1.8/min)
• Stayputnik Mk1 (300, 0.0836, 3.6/hr)
• MK2 Drone Core (1,500, 0.5, 30/min)

Things to note:

• Right now, there's no real compelling reason to use any other "supported" probe aside from the Okto2 or Dontstayputnik. They have a lower power usage than any other probe, and in most cases a lower weight as well.
• The Okto2 weighs a little less than the Dontstayputnik, and comes with integrated batteries, but it doesn't feel very compelling to use given its significantly higher price tag, especially since I still have to pay for the integrated batteries.
• I would suggest many of our probes can be either removed from the tree entirely, or can be given identical stats to the okto2 (same probe, different shape).
• The RC-L01 does need to be placed in the tech tree, as it's the only core that provides remote command capabilities for RemoteTech (as long as the station has at least six kerbals on board).

NON RO probes that show up (from SXT and MKS/UKS) include:

• SXT375mProbe
• SXTHECSRanger
• SXT-TMA1 (easter egg)
• LprobeFoil
• MKS.LogisticsHub
• MKS.Outfitter

Some of these look quite cool, so it would be nice to support them simply so we can build cool looking craft. :)

Fix 'em.
Should cost about 700 funds for an F-4C's worth of wing area.

• Have Lack fix RemoteTech support for SXT. (Bug reported on forum; parts need RemoteTech2, which is now just RemoteTech).
• Boost range of Stayputnik antenna. It's currently 3k, which means it doesn't even get signal from my tracking station next to (but apparently more than 3k) from my launch site. I'm thinking 200k feels right.
• The DP-10 is super expensive for what it does. Drop the price down, maybe with a reduction in range. It's mainly intended to make sure you can launch, not actually give you a signal from orbit. 100k feels right.
• Make the AJ10 restartable with Engine Ignitor (description implies this)
• Make the Blok E restartable (ditto)
• Nerf separation motors; they give a huge kick for their price.
• Lower the cost of the more compact I-beams. They cost more than the expensive ones.

I noticed in tree.yml that some parts have periods in their names. @pjf when you have a chance can you verify the Universal Storage parts you added (e.g. US.c.Hub.QuadCore ) -- do they really have periods in their partnames, or do they have underscores in part.cfg and a period ingame? (KSP replaces _ with . when loading parts, so you must double check in the cfg). I'm fixing the FASA ones I notice...

I have no idea if RealismOverhaul supports the Orbital Science mod, but I'd love it if we did. It expands sensors, contracts, and science options. Orbital Science + SCANsat gives a very realistic feel to the game, and encourages the building of craft to perform specific missions.

This will almost certainly result in extra science being generated, but I'm okay with that. :)

http://forum.kerbalspaceprogram.com/threads/64972-0-25-DMagic-Orbital-Science-New-Science-Parts-V0-8-6-1-(10-20-14)

It'd be dead easy for our build scripts to multiple all costs by five, meaning that players who start with default settings will have the right prices and rewards for everything. We can still work in 1960s dollars, but players don't have to remember to use special settings with starting a game.

The downside is that things which aren't costed by us (anything from RO, pfairings, ptanks, etc) will have the wrong prices.

This is me thinking about if this would be easy or impossible.

Should we aim to have our vehicles cost what they should to purchase them, or should they cost their final launch cost (quite higher than the cost of the equipment)?

From discussions in #57 , it's clear we want to place/price some parts. Here's a list of things we can do to help that:

• Figure out how much wings are. We've got heaps in the starting node, and they're all 500 spacebucks each.
• Sweep parts from modified nodes (eg: hydrolox engines) to new nodes, before the RP-0 parts are placed.
• Make the orphans node visible, similar to how it was in RPL. This gives us a visual indicator of parts in-game that we know we need to place or remove.
• . (Controversial) If we've got a rough idea of the exchange rate between kerbobucks and 1950s dollars, run a final pricing pass over non-RP0/RO parts which adjust their prices. They're still going to be wrong, but on average they'll be less wrong.

At first I thought it was just a TweakScale thing but even w/o it, I won't get any charge. I believe Bev was getting the same problem (similar?) recently as well. Right-clicking will show that the panel has .99 exposure to the sun but .00 flow.

.

The OKTO2 core comes with 15,840 worth of EC, and a "tank" that can hold
50,000 EC. Consequently it's possible to have the whole thing weigh

50kg, for a part that has a "mass" of 0.05.

I'd be happy removing the tank entirely, but in any case it doesn't look
like it's got enough space to support 50kg worth of batteries.

This may be a bug in RealismOverhaul, so attn @Felger as well.

R-7 Parts list

Will keep this updated with any changes

His latest update add's Molniya-M rocket.

Engines + Verniers

1. RD-108
   • r7_blok_a_engine + r7_vernier_engine_v_fg x4
2. RD-107
   • r7_bvgd_engine + r7_vernier_engine_v_fg x2
3. RD-0110 - Blok I for Soyuz
   • r7_blok_i + r7_vernier_blok_i_s_fg x4

Engine Config's

• 1. name = RD-107 8D74PS
• 1. name = RD-108 8D75PS
• 2. name = RD-107-8D74-1959
• 2. name = RD-108-8D75-1959
• 3. name = RD-107A
• 3. name = RD-108A

Sputnik PS1 - Fairing Base - Nose Cone - Probe

sputnik1_base
sputnik1_nosecone
sputnik1

Sputnik PS2 - Nose Cone - Probe

sputnik2_nosecone
sputnik2

Sputnik3/Object D - Fairing Base - Nose Cone - Probe

sputnik3_base
sputnik3_nosecone
sputnik3

Luna - Payload Base - Nose Cone - Probe/s

luna_base
luna_fairing
luna2 - Description = Soviet Luna E-1A Series Probe.
luna3 - Description = Soviet Luna E-2A Series Probe.

                                Molyina Parts Coming Soon

r7_adapter_blok_e - Decoupler for Vostok & Soyuz
r7_vostok_blok_e - Blok E for Luna Probes Untested with Vostok SpaceCrafts

                             ****** Others ******

Descriptions for these parts will be added/changed as I integrate more part packs.

Fairings for Soyuz Spacecraft or Fregat Payload

• r7_les
• r7_soyuz_fairing - Fairing for RN Soyuz 7K / BobcatTMA
• r7_adapter_blok_iv2 - Payload base for third stage of the R7 rocket
• r7_blok_i_fairing_s - Standard
• r7_blok_i_fairing - Fregat r7_adapter_blok_i

Fairings for Vostok Spacecraft

• r7_vostok_fairing_r -
• r7_vostok_fairing_l -

Price Considerations

r7_vernier_engine_v_fg x12 on each LV

• http://www.foia.cia.gov/sites/default/files/document_conversions/89801/DOC_0000316262.pdf

  • Last few pages has info on cost estimation

                                     **Issues & To Do**
    

• Yet to add Descriptions & Titles to most parts suggestions welcome here
• Blok E for Vostok/Luna Probes is undergoing rework to its control ability. Should be done soon.
• Testing needed for most parts. RT settings and Battery Supply especially.
• Rework/Fix of gimbal / verniers may be needed.
• Proper designation's for Rockets & Probes Eg Sputnik: Rocket - 8K71PS; Probe - PS1
• Clean up Fairings on this list

These are my notes from my first RP-0 play-through. Obviously we're in an incomplete state, but by collecting user experiences (including mine) I hope we can spot things we may have otherwise missed.

Play log

• Tu-122 .. wha? that's huge
• UA-1205 .. even moar huge!
• 30B .. also too large
• Everything is too big for the sounding rocket package
• OKTO2 is available. It uses way less EC, has a big battery... why would I use the sounding rocket package?
• Exterior thermal fin in science, needs "2F/h" charge? What's an F?
• KummunikoTronski antenna NON RO!!!!
• Where's my basic DP-10 or whatever RemoteTech2 antenna? This communitron-16 looks like it'll snap right off.
• No contracts. Am I supposed to have contracts? I have no contracts.
• I can do science on the launchpad? No thanks.
• Oh, I can't do science on the launchpad, because I have no comms devices on this vessel? What about the antenna I have on the side?
• KummunikoTronski works fine, why doesn't the Comm-16 work?
• Electric Charge goes down while I'm on the launchpad? Is there a fix for that?
• Without leaving the pad I've got 6 science from pressure/temperature. So I can advance a node. Surely I should do at least one flight?
• The Ignitor box has some description which has nothing to do with ignition.
• Yup, that antenna ripped clean off. So did my barometer.
• Huh. I got to stage without an antenna while using RemoteTech. Is there an integrated one in sounding rockets packet? I don't remember seeing that in the description.
• It's very dark at night.
• That explosion, whatever it was, killed my frame-rate. What's responsible for that, so I can turn it off?
• Fark! Those parachutes are huge. I probably could have recovered the whole rocket, not just the instruments.
• I have contracts now! Hooray! They want me to test things! Cool!
• Okay, I need to package ScienceAlert for 0.25. ;)
• Hmm, all the batteries are in stability. I can not select that node; I wonder if it will screw me up at all?
• Why is it Gene Kerman and not Jeanne Kerman? I know an awesome palentologist named Jeanne.
• Dude, they want me to test those HELLA BIG PARACHUTES, THE ONES BIG ENOUGH FOR THAT SHIP ON INDEPENDENCE DAY!
• We probably shouldn't have 16-XL and -32 parachutes in the first node.
• Vanguard X-405 wants to pay out WAY more than any other contract. Guess I want to do a sub-orbital test.
• ERMERGERD! DONTSTAYPUTNIK ISN"T SUPPORT BY RO! OH NOES
• Dontstayputnik has a reaction wheel, sweet! Also, a decoupler? Uh, okay. I guess it just breaks off?
• The X-405 doesn't have a tank butt. It just hangs underneath the T400 tank. That doesn't look right.
• I can get it to look okay by clipping a torus tank up into (and around) a procedural tank, and popping the engine on that. I don't think that's a feature, though.
• Why doesn't MechJeb show me my delta-v or TWR? Everything's N/A.
• Oh. My game has corrupted itself. I guess KSP still does that. I'm going to get some sleep.

Installation details

KSP Version: 0.25.0

Installed Modules:

• AerodynamicModel provided by FerramAerospaceResearch
• AJE 1.6.4
• AlternateResourcePanel 2.6.1.0
• CIT-Util 1.0.4-unofficial
• CommunityResourcePack 0.2.3
• CommunityTechTree 1.0
• CrossFeedEnabler 3.1
• CustomBiomes 1.6.8
• CustomBiomes-Data provided by CustomBiomes-Data-RSS
• CustomBiomes-Data-RSS v8.2.1
• DeadlyReentry v6.2.1
• DMagicOrbitalScience 0.8.6.1
• DogeCoinFlag 1.02
• EngineIgnitor provided by EngineIgnitor-Unofficial-Repack
• EngineIgnitor-Unofficial-Repack 3.4.1.1
• FAR provided by FerramAerospaceResearch
• FerramAerospaceResearch v0.14.3.2
• FinePrint 0.59
• FirespitterCore 7.0.5398.27328
• HotRockets 7.25
• Karbonite 0.4.4
• KerbalJointReinforcement v2.4.4
• MechJeb2 2.4.0
• MKS provided by UKS
• ModuleManager 2.5.1
• ModuleRCSFX 3.1
• OKS provided by UKS
• ORSX 0.1.3
• PlanetShine 0.2.2
• PreciseNode 1.1.1
• ProceduralDynamics 0.9.1
• ProceduralFairings v3.10
• ProceduralParts v0.9.19
• RealChute 1.2.5.3
• RealFuels rf-v8.1
• RealFuels-Engine-Configs provided by RealismOverhaul
• RealismOverhaul v7.0.0a
• RealSolarSystem v8.2.1
• RemoteTech v1.5.1
• RP-0 v0.02
• RSSTextures provided by RSSTextures4096
• RSSTextures4096 1.0
• SCANsat v8.0
• ScienceAlert 1.8rc1
• ShipManifest 0.25.0_3.3.2b
• SXT 18.6
• TACLS v0.10.1
• TACLS-Config provided by TACLS-Config-RealismOverhaul
• TACLS-Config-RealismOverhaul v7.0.0a
• TechManager 1.4
• TextureReplacer 1.9.2
• Toolbar 1.7.7
• TweakScale v1.44
• UKS 0.21.3
• USITools 0.2.4

(Nothing via git, because our users can't install things via git.)

Right now we have RCS parts, but they're not at all balanced. Let's look at some lower-tech examples. All thrust and Isp ratings are for HTP:

RCS Block (1/4): $ 15 (0.06, 47-137, 2 axis)
RCS Block (1/2): $ 20 (0.13, 47-137, 2 axis)
Mercury Roll Pack: $ 50 (0.11, 47-137, 1 axis)
1kN Thruster: $100 (1.00, 47-137, ½ axis)
Vernor Engine: $150 (0.26, 47-137, ½ axis)

Note that even though the roll-pack costs wice as much as the 1/2 RCS block, it provides less thrust, and in fewer directions. The Vernor engine costs an order of magnitude more, provides only twice as much thrust, and can only be used in a single direction. Indeed, there's not much reason to ever use anything other than the 1/2 RCS block.

There are ways we can balance this. The roll-pack can be dropped in price to ~ $15, where it becomes a better deal than the RCS blocks if you want single-axis control.

The Vernor engine claims it can use fuel+oxidiser mixes, and it can. With fuel+NTO it gives an impressive 0.45 thrust. However the RCS blocks can also use fuel+NTO, so it doesn't have a real advantage here.

If the RCS blocks were restricted to monopropellant only, and the Vernor was cut in price or boosted in power, it would then be more competitive. But right now, it's a terrible deal for everyone.

Alernatively, if we put the Vernor at the $20 price point it now has a real purpose. It provides double the thrust for the same cost, but only in one direction.

The 1kN thruster seems to be properly priced in the scheme of things, although the LR-101 feels like a better deal. The LR-101 is half the price, can gimbal, provides 5 times the thrust, and has comparble Isp. It's only downside is boil-off. At the very least I feel the 1kN thruster should allow throttling.

TL;DR: There's no reason to use anything other than the 1/2 RCS block

So I have been trying to think of ways that the pre-IGY gameplay could be made a bit more interesting. I know Nathan loves the sounding rockets (and they are cool!) but perhaps a bit more gameplay could be added to that early game rather than just "reach 10/22/32/... kms."

• Sounding Rockets: These are a lot of fun, but can get quite repetitive. Is it possible to add more conditions to the contracts? Say to require x experiment at 22kms and y experiment at 55 km and so on. Gameplay wise it isn't adding much, but a little extra context to why it is being launched could mix things up. (oh, a request... some sort of low mass small fins for these. Been using tweek scale but running into issues on the launchpad where the mass/strenght portion of it reverts to full even though I have the slider empty in the VAB. After starting to use KCT, the tweekscale issue on fins mass can be super annoying.)
• ICBM research. Now of course the idea of testing ICBM sounds fun/scarry! But w/o an actual space race or cold war it is a bit weird and seems out of place in KSP. Although mission that were to say reach 250km alt and impact near an area might be interesting, and a good early introduction to deadly reentry. However, I don't think I really like the idea of introducing war into the game. Seems out of place in KSP even though it was such a large part of RL space development.

Anyway thats all I can think of for pre-IGY ideas right now. If I think of any more I'll add them here.

We're not doing science on the surface of Earth, so this is a checklist of things we've missed (from my latest playthrough):

• Mystery Goo (in-line, probably from DMagic)
• Probe Situation report