Realism Overhaul Career Mode Discussion

[OtherBarry]

Release Thread Here

Intro

This thread is a discussion forum and pre-release development thread for Realistic Progression Zero (RP-0), a lightweight realistic career mode mod, designed for RSS/RO.

Major Contributors:

Myself

Felger

e_14159

pjf

and NathanKell

Places of note:

The GitHub Repository

#RP0 on espernet (our IRC channel)

Latest Pre-release

FAQ

Edited December 18, 2014 by OtherBarry
Release

[OtherBarry]

So, I have some thoughts about career mode, and it's my dream that someone else will run with these. My working name has been "Realistic Progression Zero¹", and the goals in a nutshell would be:

- Targets either the stock tree, or more likely, the community tech tree (CTT).

- Has no requirements other than the RealismOverhaul core.

- Is smart enough to detect new installs and place them in the tech tree appropriately, but does not require any other mods.

In other words, it's something which can be *very* easily picked and played with, with minimal barriers to entry.

My reasons for favouring the CTT is because it seems to be getting a lot of support from many mods which I wish to use, which will hopefully reduce the friction of integrating those into RP-0. In some cases, that might just mean adding RO support for the mods, and they work in RP-0 out of the box.

In other news, I've working pretty darn hard on the Comprehensive Kerbal Archive Network, and we're almost at the point where you can get the entire RO core with ckan install RealismOverhaul. We've got a couple of sticking points, but nothing which we can't work around. Help on the CKAN is very much appreciated; we're not short on things to do or mods to package.

All the best,

~ Paul

¹ Mainly so we can make puns about RP-0 being a precursor to RP-1.

Just bringing across this post to give a start.

[Felger]

I'm definitely willing to help out as I can. Currently working on NearFuture Propulsion, getting that all configured for Realism (Fun stuff, half the engines are still just test articles). But NearFuture plays right into career mode, it would work exceedingly well with advancement and the like.

I think one of the first things to talk about is scope. How far do we want to take career mode for RO? Proposal:

• Start simple, at first we only support science mode.
  
• Realism as much as possible. Have Historical engines from early on in space programs be available low in the tech tree, with advanced engines available higher up.
  
• Probably start unmanned, but unlock manned flight at a historically appropriate point.
  

Once we have a mostly-configured tree, the real fun begins.

• Money - will probably need lots of rebalancing.
  
• Contracts - Might be able to co-opt Fine Print to fix some contracts, I expect to run into problems such as the 'rescue a kerbal' spawning inside the atmosphere. Or getting missions out of order because of the re-ordering of planets.
  

Honestly, contracts / full career sounds a bit difficult to implement successfully. Doable perhaps, but difficult.

Anyway, this is just throwing ideas down on electrons, absolutely put out other ideas so we can discuss!

[OtherBarry]

For your proposal points:

1. Totally agree

2. Totally agree

3. Interesting part here. There's only a 3.5 year gap between Sputnik 1 and Vostok 1, which when your career mode spans from 1950s to 2030ish, isn't really a big gap. There's also only a 1 month gap between the first man-made object in orbit and the first living creature in orbit. I'd be considering maybe having basic flight, then very basic probe tech, then onto manned flight. probably in the first three (preferably un-branch-able) nodes.

Another thing to think about is how much we're willing to lock to history. As it severely limits a player's ability to choose anything in the tech tree other than to advance in time.

Also totally agree that we should wait until we have a fully working 'science' mode before moving onto money and contracts.

Edited November 3, 2014 by OtherBarry
Forgot Laika

[pjf]

I'm going to suggest quite the opposite. While I want realistic physics and bodies in my game, I don't care at all for historical accuracy. What I want is a career progression which is fun, challenging, lets me progress towards cool tech that I want (orbital colonies, resource exploration, science labs, etc), and has nothing to do with historical governments trying to muscle each other because if they're trying not to escalate into nuclear warfare.

As someone who wants to be able to play with RO + Vanilla resources, we don't necessarily have historical engines. If we do, it's because the player has installed them. I don't want them being unlocked in a historically relevant fashion, I want them unlocked in a fashion that is *fun*. RPL felt like it had a lot of engines with duplicate functions, and I'm completely fine with MM code that detects and removes engines that have similar specs to keep things relatively simple.

Why do I want this so much? Because it means I can pick up the game, with realistic physics, and play it for fun. I don't have to worry about it being unbalanced in certain points because it was "historically accurate", I don't have to worry about needing sixteen different part packs which I'll never get working correctly with each other, I only have to care about how I can have fun and achieve my in-game goals.

We may have entirely different goals here, and that's okay, it's totally cool to have multiple different tech trees for RO. But I'd be silly not to try and nudge you towards the tech tree that I want to play.

~ Paul

[OtherBarry]

I was thinking along the lines of having 2 tech trees. In the same way that RO has Real Engines or RFTS engines, "RP-0" could have two tech tree branches, one that follows history as precisely as possible, and a 'stockalike' tech tree, that would still have availiable hardware develop in a logical and realistic way, but allowing the player to go at the pace or direction they choose.

Or (i'm just typing as i think here), we could have the 'historical' tech tree advance with time rather than science, and then your limiting factor be money and contracts, and then have option 2 be the stock way of doing things, with the above mentioned stockalike tree values.

[NathanKell]

Other than "test parts in orbit" and "test parts suborbital", and possibly the kerbal-rescue code, all of which could be fixed by a plugin that changes contract stats after they are generated, AFAIK all contracts should work fine with RSS.

Prices for RO should not be terrribly hard; what is mostly needed is research on how much various things (in particular RCS thrusters, capsules, heat shields, engines, and rocket stages minus engines [aka KSP's "tank" parts) cost. Note that fuels already have correct costs; there, I am using the standard of one fund = $1000USD in 1965 dollars. In addition, last I checked, the engine prices calculated by my Calcs sheet are surprisingly close to that standard. :]

That should, in fact, lead to a decently balanced career, actually, so long as we have recommended slider settings for all the sliders, to account for needing larger payouts, and *probably* adding some "crewed space" contracts with large payouts because KSP assumes kerbals will not be more expensive to fly than probes.

What we will need, however, is a way to have a partmodule that locks flight controls but allows right-clicking (I had one back in the days of RT1, but...). That would allow unguided probes, and let us make *guidance* quite heavy.

I think an RP0 is quite doable on that basis, with historical parts but without the historical missions of RPL, and using the stock tree's nodes or CTT's (although perhaps reorganized).

[OtherBarry]

@NathanKell

I agree that most contracts should work already, or at least be easily fixed, though it depends on wether things like minimum/maximum orbit altitudes are hardcoded or based on speed or atmosphere height or something. I'd suggest leaving contracts alone until 0.90/0.26, as a lot of FinePrint stuff will be added, which will probably result in an at least minor rewrite of contract codes. Also on the contracts front, I wonder if we could make a (optional) plugin that requires the 'test part in x conditions' contract to be completed in order to be able to be unlocked in the tech tree, as that would add an interesting element of realism.

Costs should also be fairly easy in most cases, assuming documentation is relatively easy to come across. I imagine with a few prices from different agencies we should be able to extrapolate prices for less documented parts. Though I think our priorities should be tech tree --> costs --> contracts.

Your right about probe tech. Definitely need a way of being able to return science without necessarily being able to control the craft. Maybe a remote tech modification where science can be transmitted at any distance as long as there is line of sight, and then have the range of the ground stations grow as you progress on the tech tree, allowing you to send controlled probes further and further.

As to which tech tree we use, I think we should either stick with stock and just redefine the different nodes based on logical tech advancement not the stock tree categories. I guess starting with basic plane tech and early srb's and probes, then unlocking better probes, antennas, early liquid rockets in node 2, then having the option to branch towards further probe tech, manned spaceflight or further plane tech, then continuing on those basic lines to fit the stock tree shape. Or, we use one of the tech tree editing mods to just completely re-arrange the tech tree in whichever way we choose.

@Everyone - Is there anyone willing to work on the plugins necessary for this? I imagine NathanKell will be swamped enough as it is.

[NathanKell]

I've asked Arsonide to fix that stuff for 0.90, we'll see if s/he is allowed to. I've also posted an issue on the RT2 repo about the right-click-only SPU/command module, shouldn't be too hard to make.

I would not advise spending time on the test part / tech unlock thing; instead, I would suggest relying on Dangit (or whatever) to handle part failure chances, and giving bonuses to reliability on "test contract completed."

Tech-based groundstations was the original plan (or rather, you could buy upgrades for them, themselves limited by tech), it's worth posting an issue inquiring about that. Sounds good.

I actually have mixed feelings about plane tech. IMO pwings etc should unlock at the start, as should old-timey jets, but the rest of it not so much. Let's recall the F100 is 1970s kit, and the J58 mid-sixties; the spaceplane parts with integrated heat shielding should not be unlocking until after you have regular moon flights. I actually *don't* think having spaceplanes at the end of the tree is unrealistic. Same for rovers; the rovers and planes that are unlocked late are *space-capable* rovers and planes, and it makes sense that they would not be available until roughly the late 60s.

Other than shuffling the unmanned and RCS-related nodes earlier, and placing the first capsules in survivability, I don't think the stock (or CTT) tree needs *that* much rearrangement of nodes. Of the parts *in* the nodes, sure, but the node order isn't totally nuts.

[OtherBarry]

I'd forgot about Dangit, that'd be great. Though a real b**ch if you were playing hard mode career.

Totally agree with the planes stuff. Pwing's plus propellers plus say the stock mk1 parts. Then maybe have the small stock turbojet in there if and only if you have no other plane related mods installed. I think the stock tree shape is fine, it's just the nodes are in the wrong order. So in the beginning we could just use the pure stock tech tree, and just have the node icons/descriptions be irrelevant to the parts within it, until we decide upon a way to reorganise it.

I see what you mean about planes and rovers. It's really a decision as to how much choice you want in the tech tree. I imagine we could have had Space Shuttles or Curiosity-esque rovers a lot earlier had we focused more on them. Same way we could have been sending manned missions to mars last century if the space race had gone that way.

Optimally you'd have a way of decreasing node science costs based on what nodes you've unlocked. Eg sabre engines should be cheaper (science wise) to unlock if you have advanced atmospheric rocket engines or other hybrid engines.

[NathanKell]

Well, we had sounding rockets in the 1930s...

We'd need some *really* early engines for RO, I think: the early Aggregat engines, the WAC Corporal sustainer (which became Vanguard-Able / Able/ Delta), Vanguard itself, the R-5's engines (Russia), etc.

We most certainly could not have had a shuttle, let alone STS, before the late 60s if not 70s; we could have had DynaSoar hot-structure RVs, but only by the mid-late 60s and they sure as heck weren't very reusable. See also ASSET / PRIME. As for rovers, you'll note that Lunokhod, the first rover, was at the same time as Apollo 11. Wheels in space are...not so easy. Neither one was really viable until the late 60s, even for wonky prototypes.

Looking at the tree itself, I would suggest:

Start for sounding rockets

Basic rocketry for Vanguard level stuff, or Thor / Jupiter / R-5

General Rocketry for R-7 / Atlas

Stability for 3-axis stabilization via RCS and controllable probe cores (Agena/CORONA), also maybe stick Electrics here?

Survivability for Voskhod / Mercury capsules (landing legs for way later).

Flight control allows the first actual probe-sized probe cores.

[Felger]

Excellent proposals all around. I feel like for some of what you're proposing (Sounding rockets, for example) the lack of ability to return data at low tech levels is problematic. It almost feels like it'll require some basic contract system.

An example:

Launch a sounding rocket to an altitude of 150km.

Rewards enough science to develop the next tier of parts.

Is there a way to keep unwanted contracts from spawning? Perhaps this sort of simplified early career mode can be exploited, and even potentially form the basis for funds and full contracts.

[pjf]

I was thinking along the lines of having 2 tech trees. In the same way that RO has Real Engines or RFTS engines, "RP-0" could have two tech tree branches, one that follows history as precisely as possible, and a 'stockalike' tech tree, that would still have availiable hardware develop in a logical and realistic way, but allowing the player to go at the pace or direction they choose.

This sounds like two different projects. And as I said, that's cool, but I think they're different enough they shouldn't be conflated into the same name. (In which case I'd *really* love to keep RP-0 as stock with real physics and gameplay balance.) Having two completely unrelated branches in the same tree doesn't feel at all right at all.

Or (i'm just typing as i think here), we could have the 'historical' tech tree advance with time rather than science, and then your limiting factor be money and contracts, and then have option 2 be the stock way of doing things, with the above mentioned stockalike tree values.

Being able to time warp to the point where the tech one wants is available sounds like a less friendly version of sandbox, so I'm personally not taken by this idea.

~ Paul

[pjf]

Using the stock tree's nodes or CTT's (although perhaps reorganized).

No no no no no no no. The whole point of the CTT is that we don't have every tree re-organising the nodes and making it harder to integrate with new mods. This is what the tech tree looks like right now; if we need that changed at all, we should hop in the thread and ask for it, and I'm quite sure it will happen. Re-organisation of parts inside the nodes is absolutely fine.

I am interested in what we consider "core mods" for the experience. I'd love it to be possible for players to enter an RO career game with as little work doing mod installs as possible. For me, that means having all mods being installable via the CKAN. (The RealismOverhaul core already is.) I'd also really love to have a required mods list that's shorter than that of RPL.

~ Paul

[OtherBarry]

@Felger

The communication thing was just the opposite, one would have the ability to return data (within a range that would increase as tech increased) from the beginning, but would not necessarily be able to control the vessel at all until further communications technology was researched.

@PJF previous post

Yeah I definitely think that RP-0 should be the non-historical version of the tech tree. My point was more that many people (not me though) like their RSS/RO to be completely realistic and would want a 'historical' tree. I think we should make sure RP-0 is up and running to it's full extent before work starts on the historical tree.

@NathanKell

Your knowledge of spaceflight and history is much greater than mine, so I'll agree with you on the rover spaceplane and rover stuff. Maybe the small rover wheels and the apollo wheels could be unlocked at the same time as heavier duty landing legs, with the larger wheels coming out far later in the tech tree. No idea about the spaceplane stuff though, never been very interested in them in game.

If earlier stuff does become a thing in RO, then sounding rockets would definitely be useful to have in the tech tree. The issue here is that there's not much early rocketry tech in the core part mods, which would mean you'd need a sort of pre-node that would only appear if you had the appropriate mods installed. Or maybe just rearrange the first two nodes a bit so that you condense early planes/sputnik/explorer into the second node and have sounding rockets/wright brothers planes as the start node.

@PJF more recent post

Totally agree, I don't think we want to rearrange anything at all if necessary, except maybe for changing the order or descriptions without changing the default shape.

[Felger]

My expectation for mod support is to add every mod to the tech tree in the 'supported' list on the Realism Overhaul OP. Many things, I imagine, will not require much updating. Like solar panel placement in the tree. Others (especially engines) will require a lot of moving around to get it to somewhere close to a reasonable progression.

I am of the opinion that we should keep whatever we do as simple as possible to make long-term maintenance a non-gargantuan task.

[Felger]

@Felger

The communication thing was just the opposite, one would have the ability to return data (within a range that would increase as tech increased) from the beginning, but would not necessarily be able to control the vessel at all until further communications technology was researched.

Sorry, I suppose I wasn't clear. My goal is to require as little modification of other mods beyond config file modifications as possible. I was thinking about how this could be accomplished in the current game framework. Now, if we wanted to, RemoteTech's API does give information on whether a connection is available or not. If someone wants to build a plugin to do exactly what you're suggesting, it's certainly possible. But I think a simpler solution exists.

On which note, I think one of the core decisions we have yet to make is what method we plan on using to change the tech tree. In line with my goal of keeping things simple where possible, I'm a fan of using the stock tech tree, with parts moved around to fit. However, I am very open to other perspectives.

[NathanKell]

A plugin could be written that locks out flight controls but allows right-clicking but that doesn't require RT2. So that could work. Further, most early sounding rockets were parachute-recovery, and that is simple enough to do at low tech levels. Recovery of data shouldn't be an issue/

I am very, very strongly against mission-based progression in this case. While RPL is awesome (and was awesome and will be awesome), what we should be talking about here, IMO, is not RPL. It should leverage stock mechanics as much as possible. We need to make an uncrewed variant of the altitude record contract, but we should let it give some science in addition to what the player collects via science mechanics, not be the only way to proceed to the next mission.

As to the CTT, the problem here is this. I don't think you can shoehorn Squad's "tech tree as tutorial" / "kerbals are cheap and easy, batteries and probes are hard and expensive, and let's not talk about (gasp) smaller parts, those are super-hard!" approach into working for RO. And that approach is by and large what the CTT does, since it's for mods that add to KSP, rather than change KSP.

Edited November 4, 2014 by NathanKell

[pjf]

As to the CTT, the problem here is this. I don't think you can shoehorn Squad's "tech tree as tutorial" / "kerbals are cheap and easy, batteries and probes are hard and expensive, and let's not talk about (gasp) smaller parts, those are super-hard!" approach into working for RO. And that approach is by and large what the CTT does, since it's for mods that add to KSP, rather than change KSP.

The fact that CTT favours parts which add to KSP, rather than change KSP, is one of its appeals to me. It means that mods which do things on the right hand side of the tree (KSPI, MKS, etc) are likely to "just fit", rather than needing to have all their tech redistributed. It also saves having to make Yet Another Tech Tree, where everything has to be placed by hand and from scratch. If the CTT is unsuitable, then I imagine the stock tree is as well.

With regards to tree management, TechManager seems to be the most promising right now (and `ckan install TechManager` just works).

With regards to dependencies, while I'd love us to support everything that RO does, I think career should be playable with a much smaller core. The full RO support list is quite large, and is a serious amount of work to install.

[Felger]

@NathanKell - I concur with everything you've said. I expect the first few nodes to contain the parts necessary to create many of the iconic early missions. Basic sounding rockets, Sputnik, Explorer 1, and eventually Vostok / Mercury. How the player decides to do these things should be their own choice.

@pjf - Good point. I figure once we start configuring tech nodes we'll figure out pretty quick what our 'core' mods are. Likely it'll be the required RO mods + one of the parts mods, like KW or Nova.

I'm curious what the group's stance is on retaining the current nodes in the stock tree, but re-arranging the parts significantly to match a realistic progression? This would match the 'leverage stock mechanics' part, though doesn't allow as much fluidity. It also doesn't create a conflict if someone then wants to unsupported mods that add parts to the tree. Minimum restriction to gameplay, and minimizing the maintenance work required.

On Procedural Parts, we should also consider what we should do with the tech restrictions on tank size, since materials technology plays a large role in the size tank you can build, and the percent mass its fuel contents represent. Probably one of the easier configs to do in the end.

[OtherBarry]

@Felger

I think it's totally possible to use the stock tech tree, as long as we're willing to ignore the icons/descriptions of the stock nodes. As you said, it also allows unsupported mods to still appear and at least somewhat work within the tech tree. Honestly, the stock tree node names aren't that far off realistic, it's just the parts they contain that aren't realistic.

Procedural Parts would definitely need to be thought about. Really, apart from the very beginning of rocketry, there's not much of a limit on the sizes or shapes of a tank, as really all tanks are just many 'pill shaped' tanks within a larger 'shell'. Really an improvement in wet - dry mass ratio is all that happens. Loose restrictions on size should be there though, say a max size of like 2*10m at first, then going up to say 25% bigger than say Saturn V first stage tanks around the middle, then hitting unlimited around modern times.

[Felger]

@Felger

I think it's totally possible to use the stock tech tree, as long as we're willing to ignore the icons/descriptions of the stock nodes. As you said, it also allows unsupported mods to still appear and at least somewhat work within the tech tree. Honestly, the stock tree node names aren't that far off realistic, it's just the parts they contain that aren't realistic.

Procedural Parts would definitely need to be thought about. Really, apart from the very beginning of rocketry, there's not much of a limit on the sizes or shapes of a tank, as really all tanks are just many 'pill shaped' tanks within a larger 'shell'. Really an improvement in wet - dry mass ratio is all that happens. Loose restrictions on size should be there though, say a max size of like 2*10m at first, then going up to say 25% bigger than say Saturn V first stage tanks around the middle, then hitting unlimited around modern times.

Unfortunately, the better way to do it won't work with the way PP's configs work. The better way to do it is to change the dry mass of the tank. As tech improves, the dry mass fraction will improve to a limit. Ah well, size will have to do.

[pjf]

Having spoken to Nathan on IRC, I suspect we're actually in argumentative agreement on a number of points. I believe we should:

* Adopt the Community Tech Tree, as a "better than stock" tree, which is already gaining wide support from other mods (including all of RoverDude's mods, and KSPI).

* Alter the titles, descriptions, and science costs on the CTT nodes as required (eg: stability -> early probes), and move a bunch of parts around to fit with RealismOverhaul. I understand this is one of the intended uses of the CTT.

* Comment on the CTT thread if we need any new nodes added *now*. If capsules are a later game addition, we may need nodes to support that. (Or we might not, but asking for new nodes now is really good.)

My hope is that this will minimise the work required overall, and maximise compatibility with future mod development by:

* Not requiring a new tech tree to be developed from scratch.

* Easing the support transitions for new mods which already support the CTT, as we only need to code the changes in part placement.

I believe that the CTT is a super-set of the stock tree, so many mod that places its parts in stock will place its parts somewhere in the Realism Tree by default. This means if the user installs any unsupported mods (and they will), then they at least have those parts available via career mode, even if they're not balanced. I believe this view is compatible with Felger's view that we should "retain the current nodes, but re-arrange parts to match a realistic progression". It also means that if we aim for a stock-tree re-arrangement, we are CTT compatible going forward. (Although I think the CTT gives us more flexibility by providing new nodes.)

I'm happy with us requiring one parts pack as core, but I'm hesitant to *require* more than that. If we can get away with requiring only stock parts, that would make me happy.

~ Paul

[Felger]

Having spoken to Nathan on IRC, I suspect we're actually in argumentative agreement on a number of points. I believe we should:

* Adopt the Community Tech Tree, as a "better than stock" tree, which is already gaining wide support from other mods (including all of RoverDude's mods, and KSPI).

* Alter the titles, descriptions, and science costs on the CTT nodes as required (eg: stability -> early probes), and move a bunch of parts around to fit with RealismOverhaul. I understand this is one of the intended uses of the CTT.

* Comment on the CTT thread if we need any new nodes added *now*. If capsules are a later game addition, we may need nodes to support that. (Or we might not, but asking for new nodes now is really good.)

My hope is that this will minimise the work required overall, and maximise compatibility with future mod development by:

* Not requiring a new tech tree to be developed from scratch.

* Easing the support transitions for new mods which already support the CTT, as we only need to code the changes in part placement.

I believe that the CTT is a super-set of the stock tree, so many mod that places its parts in stock will place its parts somewhere in the Realism Tree by default. This means if the user installs any unsupported mods (and they will), then they at least have those parts available via career mode, even if they're not balanced. I believe this view is compatible with Felger's view that we should "retain the current nodes, but re-arrange parts to match a realistic progression". It also means that if we aim for a stock-tree re-arrangement, we are CTT compatible going forward. (Although I think the CTT gives us more flexibility by providing new nodes.)

I'm happy with us requiring one parts pack as core, but I'm hesitant to *require* more than that. If we can get away with requiring only stock parts, that would make me happy.

~ Paul

I'm liking the sound of this. On the 'core parts' I'd recommend instead of listing a required mod, figure out which mod(s) gives enough parts early on to have a successful space program. If we can manage it, just the required mods for RO + Stock would be awesome. If not, it'd be nice to have required mods + stock + Highly recommended. I'd rather not create undue dependencies.

[OtherBarry]

Yup, Yup and Yup. I agree with practically everything there.

My only concern is, with the current required mods, even with KW/NovaPunch/AIES as well, we're going to very rarely use the added nodes of the CTT, and if we're not really using it, is it worth the extra effort for the user to install?

Installing RSS+RO+Required mod's seems to be hard enough based on the number of people who manage to stuff it up so far. Though personally I do think it would be a good idea to use it. I't looks great.

Also the NFT forum OP seems to suggest that as at (11/10/14), there's no functioning tech tree editor. Is this still the case?

Edit; Nevermind. Is this what you were thinking of using? http://forum.kerbalspaceprogram.com/threads/98293