Realism Overhaul Career Mode Discussion

[pjf]

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.

Yeah, this bothered me too, so I went and wrote a spec on how to solve mod installation problems with decades worth of packaging experience, and then went and wrote software to implement it as a single download, cross platform, statically linked, no dependencies client. As of last night we ticked the last box what was required for a RealismOverhaul install. We're still in pre-release, but the following on the command-line should fetch and install everything required to have RealismOverhaul work:

ckan update

ckan install RealismOverhaul RSSTextures2048

(The client won't pick an RSS texture pack for you, so you have to choose one).

While users *can* install things by hand, I'm hoping that once we go live (which means sorting out some issues), we'll see widespread adoption of the CKAN. That means installing the CTT and other dependencies will simply mean including them in our mod's package descriptor. Our list of supported modules is increasing every day.

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

Yes, and it's already packaged for CKAN.

~ Paul

[OtherBarry]

Yeah, this bothered me too, so I went and wrote a spec on how to solve mod installation problems with decades worth of packaging experience, and then went and wrote software to implement it as a single download, cross platform, statically linked, no dependencies client

I've been following this a bit (great plug there by the way), and it seems awesome. The issue is, getting your average user to install and use it. I mean, if they're having trouble installing mods by themselves, I can't imagine command line stuff would go down too well with them. I know you've got a fair bit of work to do in order to release it as is, but I'd suggest some kind of UI in which you can customise your bundle, like the old java mod bundler did.

[pjf]

I've been following this a bit (great plug there by the way), and it seems awesome. The issue is, getting your average user to install and use it. I mean, if they're having trouble installing mods by themselves, I can't imagine command line stuff would go down too well with them. I know you've got a fair bit of work to do in order to release it as is, but I'd suggest some kind of UI

Like this?

Run the ckan client without any arguments, and that's what you get. (With many thanks to nlight for all his hard work!)

in which you can customise your bundle

Just to be clear, the CKAN is absolutely not a bundler. It's a package management tool similar to apt for Debian.

But I fear this may de-rail the thread, so back to talking about tech trees...

~ Paul

[OtherBarry]

Just to be clear, the CKAN is absolutely not a bundler. It's a package management tool similar to apt for Debian.

But I fear this may de-rail the thread, so back to talking about tech trees...

I should have done my research before complaining. This looks great. Many thanks for your hard work. Back to tech trees then...

[OtherBarry]

Updated OP with the points that I understand us to be in 'argumentative agreement' with. Let me know if any of that's wrong.

[NathanKell]

After thinking about it a good bit more, and some brainstorming with pjf, I do think it makes sense to move/reorder the nodes themselves (of the CTT) rather than move parts from node to node. So long as the node IDs are kept, then any mod that (say) adds batteries to the Electricity node will have those batteries end up in the right place, rather than "oh oops, Stability is now where the first batteries go."

The one wrinkle I am seeing in the CTT (and I posted on the thread about this) is that there does not seem to be a subtree for crewed-space exploration; the tree goes straight from Survivability (presumably where Vostok would be) to recyclers.

For anyone else looking at the current CTT on gliffy, do you see any other holes?

[OtherBarry]

@ NathanKell (and pjf)

Yup, makes sense to rearrange the nodes rather than the parts in as many cases as possible.

I think unless we're willing to change Node IDs, we're always going to end up with suboptimal node types and names. Assuming we can change the node descriptions without editing the node ID, I think it'll be fine to have people look at the parts within the node and it's description in order to get a sense of what the node is.

Eg, recyclers could be the upgrade from vostok/mercury to gemini/soyuz (based on the assumption that at least the early vostok/mercury missions were to short to require recyclers).

I'm sure there are some other holes, i'll have a look now.

Edit - Does anyone know of a way to print out a Gliffy? It's to hard to visualise how all the parts would fit in when constantly scrolling. Plus pen and paper is always better for planning.

Edit 2 - Nevermind, worked it out. Have to edit it then print from there.

Edited November 4, 2014 by OtherBarry

[pjf]

I should have done my research before complaining.

Hehe. I didn't think you were complaining; and yes a GUI *is* a good idea.

• Follows a logical and realistic tech progression
  
• Trunk of the tech tree to follow general history. Eg. Sounding rockets --> Early Planes --> ICBM --> Early probes and launchers --> First branches
  

While I'm happy for plane technology to unlock early, I don't think players should be required to do anything with them to advance in the tech tree. I've always felt silly building purely atmospheric craft for science, because it's Kerbal *space* programme. That's a long way of me saying that I feel that early plane tech should be integrated into the starting nodes that folks unlock, rather than being a separate node that requires science. (Later, space-plane tech, absolutely can have its own nodes.)

I also have no requirement for a "realistic" tech progression. Logical is nice, so players don't get surprised. I'm always disappointed when I unlock a new node, and it contains tech that's not as good as a previous node.

I think unless we're willing to change Node IDs, we're always going to end up with suboptimal node types and names.

I don't think this is going to be a problem. I've used ModuleManager to move all tech from one node to another before, so one of the possibilities that came up chatting with Nathan is to have everything place its parts as per normal (batteries go in electronics or whatever), and then as a final pass we swap everything to where it needs to be. That means part authors and tree maintainers still use the labels they expect (from stock/CTT), but the end result is functionally identical to us having swapped the nodes about. This can include renaming the user visible elements, so it's indistinguishable from the users.

We could also swap the actual nodes using MM, but that feels a little more fraught with danger.

As an example, here's what part sweeping looks like (from RPL)

@PART
[*]:HAS[#TechRequired[actuators]]:Final
{
    %TechRequired = OutCast
}

In our case, we'd move A to TMP, B to A, and then TMP to B in order to swap A and B. We can easily write a code generator to write out all the MM stanzas for us if we need to.

As for the CTT, my main concern too is that the bottom life-support line seems too simple (not enough nodes and interconnects). Unfortunately, I haven't played KSP in months (eep!), so I no longer have a good feel for which nodes we should have there.

~ Paul

[Felger]

Excellent stuff all around. I'm continuing to work on part packs for Realism Overhaul (Currently bogging through Near Future Propulsion, figure it's about time for a gamut of realistic ions.) We should probably come to an agreement on node names soon so we can start rolling those into the config files.

[pjf]

Excellent stuff all around. I'm continuing to work on part packs for Realism Overhaul (Currently bogging through Near Future Propulsion, figure it's about time for a gamut of realistic ions.)

Do you have a github repo where you're doing your work anywhere? Having one would make it about a million times easier for me to contribute. I practically live on github, so I'm happy to do initial organisation and repo set-up if you like. A github repo also means we can have a really nifty issues tracker (example from CKAN).

On that topic, we should pick a license for the tech tree and contributions made to it. I'd suggest CC-BY. Yes, I'm fond of permissive licensing.

We should probably come to an agreement on node names soon so we can start rolling those into the config files.

You mean the TechRequired / techID identifiers? They'll be exactly the same as stock/CTT. The early nodes may end up with different human readable descriptors, but I imagine we'd use the same underlying techIDs. In in doubt, I'd suggest you make executive decisions and document them.

~ Paul

[Felger]

Sounds good, and yes I've got one, same username - linky. Quick question, how do I update my fork to the master? I'm still getting used to github on a coordinated project.

And yes, I do mean the techRequired techID identifiers, sorry for my imprecision. I guess what I meant was, if I'm going to start adding things to tech nodes, I need to know which ones we're choosing to represent what realms of spaceflight development.

Edited November 5, 2014 by Felger

[pjf]

Sounds good, and yes I've got one, same username - linky. Quick question, how do I update my fork to the master? I'm still getting used to github on a coordinated project.

Oh! You're making contributions to RealismOverhaul directly? Neat! I don't think we want those contributions to assume the user is running with CTT/RPx; we should have a separate repo for our tech tree, but adding support for new parts definitely goes to RO.

If you want to pull in everything from master to your fork then the safest way is a merge:

git fetch --all
git merge origin/master

Based upon what you're named your remote, you may need `upstream/master` or `NathanKell/master` instead of `origin/master`.

To send changes back to RealismOverhaul to be integrated into the main project, you'd make a pull request. If you're used to working from the command line, then the hub extensions to git can make it easier to open pull requests from the command-line.

For work on RPx, I'd suggest we use an organisation repo rather than a personal one. These make it much easier to find the authoritative repo, work together, spin off side projects, and the like. Otherwise it becomes a major pain when maintainers change and issues don't transfer across easily.

[Felger]

Yeah, offered to help out, been submitting the pull requests and whatnot. Figure for my RO work, that's still the place I want to submit it.

For tech tree attachments, won't we want to put those attachments in the RO config files? It can't hurt if they have the same names as the stock tree nodes. Otherwise we may find ourselves with two config files per part to maintain (Granted, I'd hope updates to the tech tree file shouldn't have to be changed frequently).

[pjf]

For tech tree attachments, won't we want to put those attachments in the RO config files? It can't hurt if they have the same names as the stock tree nodes. Otherwise we may find ourselves with two config files per part to maintain (Granted, I'd hope updates to the tech tree file shouldn't have to be changed frequently).

Oh no! If we do that, then everyone who installs RO will end up with the RPx tech tree by default. Given that RPx is likely to depend upon other mods to be playable, this then blows up the dependency graph for RealismOverhaul even more. It also means that we totally screw up any other RealismOverhaul tech trees which may not expect parts to change positions, and we're not able to make releases without new copies of RealismOverhaul being released. The result is a project with high coupling, where it's hard to update one component independently of the others.

Instead, RPx should have its own files which run :AFTER[RealismOverhaul], (and probably after many other things, too). This means we can make new releases whenever we like, and we're not altering the tech tree for anyone who doesn't have RPx installed. We can be sure that we're installed with whatever dependencies we need (because we either bundle them, or CKAN depend on them), and we can have files which make it very easy to see what's going where.

I'm a big fan of code generation for MM configs, so I'd personally write tech descriptors in YAML or JSON and have code (which I am happy to write) which generates the MM configs from that. For example, our config which places parts might look like this:

SpecializedScience:
  - SCANsat_Scanner24
  - MachineThatGoesPing

Survivability:
  - TacCarbonExtractor
  - CuteBearShapedAirbag

After running that through code-gen, we'd get:

@PART[SCANsat_Scanner24]:AFTER[RealismOverhaul]
{
    %TechRequired = SpecializedScience
}

@PART[MachineThatGoesPing]:AFTER[RealismOverhaul]
{
    %TechRequired = SpecializedScience
}

...

This means that humans with no knowledge of MM can easily place and adjust tech locations, and it's very easy to see what's in each node at a glance.

If we're using something similar to the above, I'm also happy to use my Gitomancy to make it so that creating a release simply makes hitting the "new release" button on github, and a bot will check out our config files, run the code generator over them, create AVC files if we want them, bundle them all into a zip, and upload that to github.

I'm happy to provide serious automation work, I just don't want to place the nodes.

~ Paul

[NathanKell]

I don't think we have to sacrifice realism for fun. I agree wholeheartedly with pjf, but I am willing to cite history. In particular, here is how tech *actually progressed, and how I think it should work over the first few nodes:

1. Sounding rockets and pre-1950 jets (start)

2. Vanguard, where it's possible to either launch very small (uncontrollable-once-in-orbit) probes, or very large sounding rockets (basic rocketry)

3. Ton-class LVs like R-7, Atlas (General Rocketry), controllable probes in orbit like Agena (Stability taken as "3 axis stabilization"), RVs / pods (Survivability).

Thus far we can sbsolutely maintain the stock node positions and even names.

Supersonic flight should appear around #2 above, maybe as a branch from Basic Rocketry.

Actually, I have a Modest Proposal : remove Kerbin surface science entirely. I always find it paradoxical, unintuitive, and simply unfun to grind by taking surface samples around KSC or elsewhere on the planet. I think that would solve a lot of problems.

As for moving nodes: the big, big advantage here is that then we will not collide with any mods that move *parts*. If we, too, move parts, we need to run after everything else.

[pjf]

Actually, I have a Modest Proposal : remove Kerbin surface science entirely. I always find it paradoxical, unintuitive, and simply unfun to grind by taking surface samples around KSC or elsewhere on the planet. I think that would solve a lot of problems.

Please. This is one of the first changes I make whenever I play career. Likewise, science from sensor readings (pressure, temperature, fun, etc) should yield 100% science, none of this multiple samples rubbish. I don't know if this sort of functionality exists as a stand-alone mod, but it strikes me as something that would be a good re-usable component for others.

At Nathan's nudging I've also gone and made a github organisation and repo, to which you should all have an invite to. I've populated the repository with the usual starting files; a readme (which directs to this thread) a license (which species CC-BY-4.0, unless anyone objects), and a code of conduct (which people will get a link to when opening issues or pull requests).

The repo is yours, and you should use it as you will. Enjoy!

~ Paul

[OtherBarry]

Firstly - Im in agreement with practically everything mentioned in the last 6ish hours.

Had an idea, seeing as there seem to be several fairly separate issues that we have differing opinions on, might it be easier to start issues on github, so that we could discuss things per issue rather than addressing several different issues all at the same time?

Obviously we'd still post stuff on here, it would just make things less cluttered and easier to understand, particularly if anyone new joins the discussion. Which by the way, if you are lurking on this thread, please do contribute. I'm sure there are more opinions on career mode than just the four of us have.

Also, now that I have access to a proper desktop, is there an IRC channel that we should use (or are already using)? Or some other way to communicate 'live'?

[Ival70]

Which by the way, if you are lurking on this thread, please do contribute. I'm sure there are more opinions on career mode than just the four of us have.

Well since you asked. I really like the ideas floating around here. One thing I think should be considered is scaling time/progression to game-play. For instance, let's say that players are not likely to play a particular save for more than ~1000 hours (a bit high there, but it's an example), then the progression in-game should be scaled with that in mind, so that most people don't get sick of it before they finish most of the tech progression. Of course, it's not nearly that simple, there are many different personalities and even more play styles, but it may be something to eventually think about.

[pjf]

Had an idea, seeing as there seem to be several fairly separate issues that we have differing opinions on, might it be easier to start issues on github, so that we could discuss things per issue rather than addressing several different issues all at the same time?

I would love nothing more than this.

Also, now that I have access to a proper desktop, is there an IRC channel that we should use (or are already using)? Or some other way to communicate 'live'?

I've registered #rp0 on irc.esper.net in case we want to use let. Pop in and say hi and I'll give you ops.

Also, the first CTT download is out, and it has extra habitation nodes which should make our life easier.

[OtherBarry]

@Ival70

Totally know what you mean. I usually give up on the stock tech tree before I've reached the latter parts of it, but then again, I'm much more of a sandbox person. I think it'll be important to think of how much 'grinding' will be needed to advance up the tech tree. RSS is hard enough as is, let alone having to send mission after mission to land on the moon purely to unlock the ability communicate outside of earth's SOI. And that's not even considering the amount of time that would take.

I would love nothing more than this.

Awesome. It'll also make it easy to keep track of commits by referencing the relevant 'issues'. I'll get started on this once I get home, unless anyone would rather keep stuff on the forums. Also for reference, what timezones are you guys in? I'm AEST, and I know NathanKell likes to ignore sleep at logical hours and possibly time itself.

I've registered #rp0 on irc.esper.net in case we want to use let. Pop in and say hi and I'll give you ops.

Will do, happy to leave my computer on constantly if I need to keep the channel open for whatever reason.

Also, the first CTT download is out, and it has extra habitation nodes which should make our life easier.

I'll have to try it out then. Has the gliffy been updated?

[pjf]

Just a short note that the git repo has some examples of code generation tools added; the YAML I posted earlier works with them. I'm also on AEST. The gliffy has been updated.

As for difficulty, I suspect the easiest way is to modify either science returns, tech node unlocks costs, or provide additional sources of science. Mods like SCANsat, KSPI, and orbital science are all possible sources of additional science (and I *really* like them, but I think they should be "supported" rather than core mods).

I suspect the best solution to deal with wanting different difficulties is to provide configs which do difficulty scaling, probably as an additional pass which changes existing values. We'll also have a much better idea once we start playing as to what needs rebalancing (both part costs and science).

[Felger]

On different difficulties, the new-game sliders already catch that for us. Players can already choose multipliers (all the way down 0.1) for their science and monetary gains.

I agree that we should support the SCANsat / KSPI / Orbital Science mods. In fact, I was looking at making a pass at 'compatibilizing' KSPI to Realism Overhaul / RealFuels (Not necessarily balancing to realism, since very nearly every part in that pack does not exist except as a pipe dream in a physicist's or engineer's brain). Personally, I love the extension into the future that KSPI offers, allowing you to not only build the ships of the past and present, but also the future (If our guesses of today work out).

So, moving forward, I plan on continuing to update part packs for Realism Overhaul. I intend to try to add as much non-intrusive support into my updates for RP-0, what needs to happen on the part end of things, if anything? Perhaps the best solution is to take notes in parallel to my edits, and submit pull requests on the github project for node placements. Or, alternatively, as we add part packs to the supported list, we then go through and place the parts on the tech tree. That'd be a good sequential way to do it. Eat the elephant one bite at a time.

I suggest once CTT is up and running, load up all the currently supported mods (or as many as won't crash the game) and see how well it all fits into the "default" tree. (I'm sure we're all aware that you can edit your science total in the persistent.cfg, easy to unlock and see the whole tree that way). Past that, I suppose it'll be a mod-by-mod process, attempting to mirror the supported list in RO itself.

[ThorBeorn]

Been following this thread for a couple of days now. I have few questions regarding gameplay.

1.Will you add any science experiments at all like RPL did, or are you going to use stock experiments?

2. Great to see propellers, early jets and p-wings in the start node! But will you promote experimental aircraft building (Bell X1+X2, Douglas Skyrocket, X-15 etc) somehow? After all these span over three decades.

The latter is something I think career always has left out along with space stations, both by squad and by other mods/tech trees. Perhaps X-planes could be promoted via contracts later on?

[NathanKell]

Part testing contracts will often enough require something like the X-15. In addition, it might make sense to have (a subset of) speed and altitude records only settable when under thrust.

Our plan is not to add custom-tailored science experiments like RPL.

[metaphor]

This sounds pretty cool.

I would suggest looking at the BTSM (Better Than Starting Manned) mod, it has a robust career mode with some major improvements over stock. For example, using electrical energy as a resource: the first tech nodes rely on batteries which have substantial mass, so only shorter missions are possible, and the batteries get more efficient as you progress. Solar panels start out relatively heavy in order for the player to be able to trade spacecraft mass for energy production, and get lighter and more efficient later in the tech tree. Probes start out large and power-hungry, but as you progress they get smaller and more efficient. Science experiments can either return 100% science on transmission, or 0% on transmission and 100% on return to Kerbin/Earth; even without adding any new kinds of experiments, the existing ones can be made to work much better than currently. Launchpads start out being able to support smaller rockets and are upgradeable to launching bigger rockets. All of these things are pretty realistic in addition to improving the gameplay.

I do think there should be two versions of this mod, one which focuses more on historical accuracy and one which focuses more on gameplay.