rsparkyc

[1.2.2] Realistic Progression Zero (RP-0) - Lightweight RealismOverhaul career v0.54 June 15

Recommended Posts

is the community tech tree required to install if using RP-1 (development branch of RP-0) on KSP 1.3.1?
I ask because in the description in github it says that it has its own tech tree or am I interpreting it wrong?

Share this post


Link to post
Share on other sites

@Agustin

RP-1 doesn't use the community tech tree. 

A copy of Bornholios's Golden Spreadsheet (found via a Feb 2018 reddit post, possibly outdated).  https://docs.google.com/spreadsheets/d/1A7gQkIiQKi0VtRecE6p86KCKuoawZPdzk7NlaxssRJ4/edit#gid=1353744027 .  Also see https://www.youtube.com/watch?v=lm884sCLRhw which shows some of the changes between the 1.2.2 version of RP-0 and RP-1.  (Also from the early this year).  

 

 

Share this post


Link to post
Share on other sites


Now I have anther question.
Do I need Kerbal Construction Time?
 I have already been playing around a bit with it while installing every dependency and... I just don't like it. It takes forever to pass like eternity, days and months to get done a SINGLE PART. And that takes for ever in my principia install maybe because of it being so CPU demanding. Also I tried to change the settings to be only 2 days of constructino time for everything, but it doesn't work, it still wants to pass months to get ONE PART in the runway. and I hit warp until launch and it takes TOO LONG, it is unplayable. So... Do I NEED to have it installed and... Can I change the settings in some manner that it works? 
THANKS IN ADVANCED FOR YOUR HELP!

Edited by Agustin

Share this post


Link to post
Share on other sites

RP-1 is the nickname someone gave to the new version of RP-0 that is in the development branch.   Hence when I said RP-1, I meant the new version.

Share this post


Link to post
Share on other sites
3 minutes ago, AVaughan said:

RP-1 is the nickname someone gave to the new version of RP-0 that is in the development branch.   Hence when I said RP-1, I meant the new version.

Yeah, I understood after writing, Now I have a new question. Edited my last post. Please read it to see if you can help me!

Edited by Agustin

Share this post


Link to post
Share on other sites

I've never had problems with KCT but I also don't use principia.  Is it possible that principia (or something else) is slowing down timewarp, and that is causing your problems?  Or are you just not investing enough in KCT's build rates and research rates?   

To play RP-0/RP-1 as designed, then KCT is pretty much required, otherwise research and rocket would be completed instantly.

Share this post


Link to post
Share on other sites

I didn't understand what sounding rockets were and I found this video which is very nice. Thought of sharing with you:

 

Share this post


Link to post
Share on other sites
On 11/3/2018 at 1:40 AM, winged said:

Part II - https://imgur.com/a/Zjvow

YKQJ8gi.png

Approaching Ganymede - February 2004.

 

Where did you get all the parts? I have been looking for capsules and rings etc that will work with RO/RP-0. None of the "supported" mods I've seen here or on the RO thread have these.

Share this post


Link to post
Share on other sites
6 hours ago, Antstar said:

Where did you get all the parts? I have been looking for capsules and rings etc that will work with RO/RP-0. None of the "supported" mods I've seen here or on the RO thread have these.

Most of the parts you see here is just Procedural Parts mixed with Procedural Fairings. Other than that I've used: SSTU for Orion,  FASA for landing legs, Baha Constellation and ChakaMonkey for engines, SSTU for habitats (with my own RP-0 configs). Antenna is probably from Remote Tech or AIES. Radiators, RCS ports, structural parts and everything else on this picture is stock. Full list:

iArBuuF.jpg

Share this post


Link to post
Share on other sites
15 hours ago, winged said:

Most of the parts you see here is just Procedural Parts mixed with Procedural Fairings. Other than that I've used: SSTU for Orion,  FASA for landing legs, Baha Constellation and ChakaMonkey for engines, SSTU for habitats (with my own RP-0 configs). Antenna is probably from Remote Tech or AIES. Radiators, RCS ports, structural parts and everything else on this picture is stock. Full list:

 

Is it legit if you give me your SSTU habbitat's configs? I am using ksp 1.3.1...

Share this post


Link to post
Share on other sites

RP-0/1 removes the kOS parts (they are not "costed") and instead replaces them with a ModuleManager config that adds kOS to probe cores.  But it does has always done it wrong and presents a limited crippled version of kOS to the player.   kOS is supposed to have 4 different parts in the tech tree to represent 4 different levels of disk size, like so:

  • kOSMachine0m part has: diskSpace = 5000 bytes
  • kOSMachine1m part has: diskSpace = 10000 bytes
  • kOSMachineRad part has: diskSpace = 60000 bytes
  • kal900 part has:  diskSpace = 255000 bytes

But when playing with RO/RP-0, This is what kOS looks like to the player, because of the bad ModuleManager config:

  • Is it the 1960's? Then you have 5000 bytes.
  • Is it the 1970's? Then you still only have 5000 bytes.
  • Is it the year 2020?  Then you still only have 5000 bytes.

It's always 5000 (which was only ever intended as the minimum).  No matter the tech tree progression.  All the time.  Unconditionally.

Granted, you can pick 2x or 4x multipliers in the VAB for a bit more weight and cost, but that still only lets your 5000byte unit become a max of 20000bytes, which is *still* far less than was intended, as you can see by the first list above.

The problem is that the ModuleManger confg unconditionally says "diskSpace = 5000" no matter what, for ALL avionics cores, all the time.  And since this *replaces* the mod's intended parts, it kind of wrecks how kOS was supposed to be.

Is fixing this on the roadmap for "RP-1"?  All it takes to fix it is to vary that "diskSpace = " value for different kinds of avionics cores as you go up the tech tree, rather than making them all the same.  I get that in realism overhaul you might want to change this number and make it more limiting than in stock kOS, but it still shouldn't be the exact same fixed value at all tech levels like this.

(Before anyone comments about how limited the memory on the Apollo Guidance Computer was - keep in mid that half its programming didn't count toward that number as it was hardcoded programming literally weaved into the system, and for that which was not, it was machine language, whereas kOS is counting the Unicode source text since it's using a script language.  There's not really a proper 1:1 comparison between the meanings of those values.)

 

Share this post


Link to post
Share on other sites

I think that it could be possible for the capacity to increase over time, based on tech node unlocks.  Doing it via specific probe cores isn't ideal, since many people use the procedural avionics instead.

What does (non-RP0) kOS do if you install multiple kOS parts with different storage capacities?  Does it add them, or just use the highest value?  If it just takes the highest, it might be simplest to bring back the 10k, 60k and 255k parts as storage upgrades further down the tech tree...  leaving the 5k config in all probes and avionics by default.

I'd suggest opening this as an issue on the RP-0 Github for discussion...  especially before devoting time to actually implementing possible fixes.  They may have some ideas.

 

Edited by RoboRay

Share this post


Link to post
Share on other sites
43 minutes ago, RoboRay said:

What does (non-RP0) kOS do if you install multiple kOS parts with different storage capacities?  Does it add them, or just use the highest value?  If it just takes the highest, it might be simplest to bring back the 10k, 60k and 255k parts as storage upgrades further down the tech tree...  leaving the 5k config in all probes and avionics by default.

Neither.  They're separate disks that can be accessed by drive number or name.  Each kOS part is a different CPU which can run its own code and also has a local storage volume.  Different kOS cores on the same ship can see each other's local volumes, but they don't merge together into one logical drive in a raid array or anything like that.  They're just separate volumes with filenames like "1:/this_file" on drive 1,  or "2:/that_file_over_there" on drive 2, etc.

Quote

I'd suggest opening this as an issue on the RP-0 Github for discussion...  especially before devoting time to actually implementing possible fixes.  They may have some ideas.

I made an issue over there that's over a year old that didn't seem to really go anywhere: https://github.com/KSP-RO/RP-0/issues/758

Part of why I posted here was to see if there is somewhere else that work had been done on things as RP-1 comes closer to happening.  Based on that issue, I haven't seen any movement.  I don't really want to tell people in RP how to scale things - that's kind of up to them to decide how they think it's best balanced.  But to choose to *never* scale anything at *all* in any way whatsoever does sort of break kOS and it's always been a slight annoyance with me.

Edited by Steven Mading

Share this post


Link to post
Share on other sites

Then it would seem it was an error to not include the kOS parts.  Adding the baseline functionality to probe pods still makes sense, but the separate parts are still needed. 

It may also be that the parts were not deliberately removed...  they may just have never been placed in the tech tree to begin with, and hasn't been a priority for anyone to do because the pods have the basic functionality.

RP-0 is mostly community-driven, and its often the people who raise an issue that have the best understanding of the issue.   It's also often the people who raise an issue who have the most motivation to get it fixed,  since it's impacting them.  You may want to just dive in and try to work out how to fix it yourself.  It might save a lot of waiting,  and you can be a contributor to the project. 

I'll look at the issue you raised.

 

Edit:  It seems likely that nobody has any idea where they belong on the tech tree, or what they should cost so they simply haven't been included.  They don't seem to be listed in the spreadsheet that generates the tech tree configuration at all.  I don't think that it is intended for kOS storage capacity to not improve over time...  it's just that implementing it has been neglected.

Not being a kOS user, I have no idea... but if you suggest a year in which those parts might logically be available, and a reasonable price (converted to 1965 US dollars), that might help.  The key thing to remember about balancing in RO/RP-0 is that it's supposed to be realistic...  so, balancing parts for gameplay reasons isn't really a thing.  If you can equate the kOS capabilities to real-world computer capabilities historically (or projected into the future), that will indicate about where they belong in the tech tree.  And likewise with costs.

Edited by RoboRay

Share this post


Link to post
Share on other sites
3 hours ago, Steven Mading said:

Neither.  They're separate disks that can be accessed by drive number or name.  Each kOS part is a different CPU which can run its own code and also has a local storage volume.  Different kOS cores on the same ship can see each other's local volumes, but they don't merge together into one logical drive in a raid array or anything like that.  They're just separate volumes with filenames like "1:/this_file" on drive 1,  or "2:/that_file_over_there" on drive 2, etc.

I made an issue over there that's over a year old that didn't seem to really go anywhere: https://github.com/KSP-RO/RP-0/issues/758

Part of why I posted here was to see if there is somewhere else that work had been done on things as RP-1 comes closer to happening.  Based on that issue, I haven't seen any movement.  I don't really want to tell people in RP how to scale things - that's kind of up to them to decide how they think it's best balanced.  But to choose to *never* scale anything at *all* in any way whatsoever does sort of break kOS and it's always been a slight annoyance with me.

make a patch that does

@PART["partname"]:FOR[zzzRP-0]
{
	%category = -1
	%techRequired = <pick a node>
	%RSSROConfig = True
	RP0conf = true
     

Also add an entry cost and viola done.

Share this post


Link to post
Share on other sites
8 hours ago, Bornholio said:

make a patch that does


@PART["partname"]:FOR[zzzRP-0]
{
	%category = -1
	%techRequired = <pick a node>
	%RSSROConfig = True
	RP0conf = true
     

Also add an entry cost and viola done.

The parts also have a small battery, do varying power drain based on how much code is being run, and one of them has a tiny solar panel on it.  I know RO has a totally different set of rules about what one "electric charge" unit means.  I think that's part of why I didn't suggest that before.  I've got no clue how to scale the power of the part.  However, I guess if they're adding the kOS module to avionics cores with ModuleManager, they're getting that probably inappropriate level of power drain *already* right now.

As to the "right" tech level, that's going to be a doozy.  It's very hard to map kOS back to real world hardware because simplifying some of what real software engineers had to do was kind of the point of it (And if you say that's not realistic, keep in mind that you can slap a rocket engine to a tank in RO and never bother contemplating where the fuel lines are running through that tank, or deal with POGO issues, etc.  The game, even in RO, has some simplifications like this to make everything more tolerable as a game.  RO adds *some* extra realism issues to the game.  It doesn't add *all* of them, nor should it, since if it did then one single human being couldn't simulate the work of tens of thousands of engineers that it really took to deal with those problems.)

Real world hardware was more limited, but real world hardware wasn't running high level software either.  It was running very primitive pre-compiled (or even hand-woven) machine language instructions early on.  And at the start it was more like SmartParts, with separate individual systems each just doing one self-contained basic thing.  Those were often analog circuitry instead of programs anyway.  One idea that may be useful to RP is that we were going to limit IPU in kOS (that's Instructions Per Update, a really fuzzy way to emulate the idea of slower or faster CPUs) based on tech tree (right now it's just in the settings options menu and is global and the user has permission to change it when they feel like).  As that isn't available yet, there's not much RP can do with it for now, but in future it could be another way to 'cripple' early-tech kOS and let it get better with time.

Share this post


Link to post
Share on other sites

Actually, SmartParts is something else I'm looking at for integrating into the RP-1 tech tree.  I've been missing some of those things.  :) 

But yeah, I get that there's not a direct correspondence between the kOS functionality and real-world computers.  Just having a vague ballpark idea would help...  something like "Part X might represent late 1960s computers, while Part Y could be early 1980s computers."  I think the future plans to limit IPU by processor part would be a very desirable feature in an RP-0 implementation.

I'm willing to help with addressing this issue, but I'm new to RO/RP-0 and am still learning my way around under the hood.

 

Share this post


Link to post
Share on other sites
17 hours ago, Steven Mading said:

But to choose to *never* scale anything at *all* in any way whatsoever does sort of break kOS and it's always been a slight annoyance with me.

Then why not DO something about it.  Make pull requests and make your case in the pull request comments. Quite likely nobody actually chose anything. They probably just didn't know how it should be configured and just added a token configuration.

YOU decide how it should be configured and then go configure it. Nobody else here seems to know KOS that well or they wouldn't be asking you questions about it. You seem to know something about it so that qualifies you.

(not trying to be harsh here, just saying that you're just as empowered as anyone else here)

Share this post


Link to post
Share on other sites
8 hours ago, Starwaster said:

Then why not DO something about it.  Make pull requests and make your case in the pull request comments. Quite likely nobody actually chose anything. They probably just didn't know how it should be configured and just added a token configuration.

YOU decide how it should be configured and then go configure it. Nobody else here seems to know KOS that well or they wouldn't be asking you questions about it. You seem to know something about it so that qualifies you.

(not trying to be harsh here, just saying that you're just as empowered as anyone else here)

I know kOS.

I do NOT know RO or RP-0.  The development model of "drop a PR on the team from out of the blue, with no discussion ahead of time about what it's trying to do or whether the team even thinks that's a problem worth solving" is not how I'm used to working.  So the pattern I'm used to is "raise issue, team discusses and someone on the team says they like the idea, then make PR, submit PR, team merges it", which is why I was sitting a long time when the issue got no further replies.   I took "lack of response" to mean "there's a good chance if I throw a PR at them un-invited, they won't want it so it won't happen."  So I didn't think it was worth me spending the time to learn their mod well enough to do that.  The time to spend learning a brand new mod's system isn't worth it if the response will be "thanks but no thanks".  The response here in the forum has been very different from on the github issue (which was just silence), so NOW I do feel like it will be worth it to go ahead with that effort.

 

8 hours ago, RoboRay said:

I'm willing to help with addressing this issue, but I'm new to RO/RP-0 and am still learning my way around under the hood.

 

Yes, thank you.  That would be great.  I may be out of contact for a few days though, because of the Thanksgiving holiday.

I don't know what the consequences are of not bothering to change the electric charge scaling as a first pass to getting something done.  How much of a problem would it be to ignore that part of things for now?

We can discuss more in github comments here: https://github.com/KSP-RO/RP-0/issues/758 That way it will be on record with the issue rather than in the forum history that might not remain forever.  That issue was something I wrote up originally in response to NathanKell's request for better information about what can go into the ModuleManager config, but it was just before he sort of fell off the face of the earth for a while (which I hadn't known had happened).

Edited by Steven Mading

Share this post


Link to post
Share on other sites
1 hour ago, Steven Mading said:

... team discusses and someone on the team says they like the idea, then make PR, submit PR, team merges it", wh...

Make PR's and they happen, then it has something to test. Effort is always appreciated.

Share this post


Link to post
Share on other sites
42 minutes ago, Bornholio said:

Make PR's and they happen, then it has something to test. Effort is always appreciated.

I have been burned before where that is not what happened.  It was just wasted effort because the PR wasn't wanted.  Thus why I was more in the habit of discussing first before doing.

Especially if it's the *very first* time I'd be dealing with that particular project, so there's a learning curve to get over before I can make a PR.  That's a bit of "up front" cost of effort that is just thrown away if it's something the team doesn't want.

Edited by Steven Mading

Share this post


Link to post
Share on other sites
16 hours ago, Steven Mading said:

I took "lack of response" to mean "there's a good chance if I throw a PR at them un-invited, they won't want it so it won't happen." 

Improved 3rd-party mod support is pretty much always wanted...  it most likely didn't get a response due to lack of knowledge about kOS due to lack of usage of kOS, meaning improving kOS wasn't a priority for them.  But if it is a priority for someone and they do the legwork (in my short time watching RO/RP-0 development), it gets accepted and incorporated.

16 hours ago, Steven Mading said:

I don't know what the consequences are of not bothering to change the electric charge scaling as a first pass to getting something done.  How much of a problem would it be to ignore that part of things for now?

I think it can safely be ignored for now.  Like you said earlier, the current basic implementation doesn't account for it, so it's either already broken or not actually an issue.  Once the kOS parts are added, actual usage of them should reveal whether or not it's a problem.

I need to improve my own knowledge about some of this, but will follow up later on Github.

Edited by RoboRay

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.