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

[chrisl]

18 hours ago, leudaimon said:

@nanomage Those are extreme examples, and getting to those planets without a gravity assist from Jupiter is not very realistic TBH (both because of mission length and delta-v), but maybe they could be extended. Although, remember that New Horizons got to Pluto in 9 years, with one single (and almost mandatory to make this type of mission feasible) gravity assist from Jupiter.

One of the main reasons we use gravity assist from Jupiter (or other planets) has less to do with cost and more to do with what kinds of launch vehicles we have available.  Voyager 1 and 2 were launched with the most powerful launch vehicles the US produced at their time of launch: Titan IIIE.  New Horizons was launched on the Atlas V which was, again, one of the most powerful launch vehicles at that time.  But while the Titan IIIE and Atlas V are both powerful launch vehicles, both pail compared to the Saturn V and it's proposed derivatives.  I'd have to try it out (and likely will when I get that far) but I'm fairly confidant that a Voyager launched on a Saturn V could easily reach Pluto in less time than New Horizons did without the need for a gravity assist.  Sure, Titan IIIE and Atlas V were less expensive than a Saturn V, but neither was selected because of cost. 

 

EDIT: Not that I don't disagree that some of the mission times are a little tight or that always having to launch a new satellite isn't annoying. 

Edited February 7, 2017 by chrisl

[linuxgurugamer]

Hi,

what would it take to get the K2 Command Pod supported here?

Or, if a cfg can be added to K2, I can do that.

Thanks

[Phineas Freak]

@linuxgurugamer The first step would be to make it compatible with RO. Then, after it is compatible with RO, we add the tech tree support that is RP-0. It is not something that a modder should include with a mod but it is taken care by the KSP-RO team.

I will make a proper PR to include support for your mod for both RO and RP-0.

Edited February 7, 2017 by Phineas Freak

[leudaimon]

1 hour ago, linuxgurugamer said:

what would it take to get the K2 Command Pod supported here?

\O/ That is a really nice addition to RP-0! I really really miss a simple mod that adds a 2-crew pod, instead of the behemoths like FASA that include one. It's very helpful in early manned missions. Btw @Phineas Freak, it should be pretty simple to copy all configs from the FASA Gemini, right? It's already placed in the tree and has all the RO configs.

Edited February 7, 2017 by leudaimon

[Phineas Freak]

@leudaimon Yep, that's what i am doing right now. With some fudge factors of course, like the Mk1/Mercury pod comparison.

[linuxgurugamer]

1 hour ago, Phineas Freak said:

@linuxgurugamer The first step would be to make it compatible with RO. Then, after it is compatible with RO, we add the tech tree support that is RP-0. It is not something that a modder should include with a mod but it is taken care by the KSP-RO team.

I will make a proper PR to include support for your mod for both RO and RP-0.

Ah.

Thank you !!!!!

[gemini4]

Is there a way to reopen previously completed contracts? I had an issue (this was several months ago) where, when attempting the "first space station" contract, docking and undocking from the station would reset the "crew required" and time duration parameters. As a result, I was unable to complete the contract fairly and had to manually force it to complete through a text editor. After I was done, I destroyed the station to make sure I never tried another station mission, to avoid the hassle I went through the first time. Now, this issue has been fixed, and I'd like to start doing station contracts again. However, the only ones available are "station crew rotation," which tell me to rendezvous with a non-existent space station. Is there a way I can reset the "first space station" contract, so I can complete it properly this time? 

[leudaimon]

@gemini4Probably not what you are looking for, but AFAIK if you launch another space station to orbit, you will start receiving these crew rotation contracts for the new space station too. Regardless, I think it is a bug that the game offers a contract for a station that is not in orbit anymore.

Edited February 7, 2017 by leudaimon

[gemini4]

@leudaimon I actually tried doing exactly that, but the game saved the vessel ID of the original station, and so didn't recognize the new station as the one for the contract. I think there's a contract in RP-0 for a "new space station," but I can't get that one to trigger. The contract configurator window for it says "unknown: not met."

Edited February 7, 2017 by gemini4
Forgot to include the name of user I was responding to in original post.

[leudaimon]

That's weird. I had a look at the contract files, and the new space station contract should become eligible once you have completed the first space station contract and also have no space station in orbit.

Thus, I would guess it is probably supposing you still have your old station in orbit.

[hargn]

 

@gemini4 If I correctly remember, CC has a VesselParameterGroup parameter. I don't know where it saves the list of the vessels included into the groups defined by the contracts, but I would search into your career file for the groups spaceStation and spaceStationsEarth and the name (and/or id) of your deleted station.
EDITED : in fact, that is the spaceStation vessel group as you can see in the crew rotation contract file.

For the flyby contracts, the minimum altitude parameter is the same for all the extern planets (or gaz giants). It should be adjusted for the sphere of influence (in KSP) of the planet to reach.

As the flyby contracts are meant as milestone contracts, they have to be reached before to have contracts that satellite contracts are offered. That's is the way of these contracts are implemented yet, I don't know the reasons, but it seems right because you should demonstrate that your space program were able to reach a planet before to send other probes, satellites or more.

For the NewVessel parameter, I think again that it is right like this : the available tools we have help us to know the planets we can reach for a given amount of dV for a specified window, so we can select all the flyby contracts we can fill by launching a new probe. But maybe we could add contracts that offer a new destination for a probe that has visited an external planet. I believe that it won't be so hard to implement.

Edited February 8, 2017 by hargn

[gemini4]

I solved the problem by just deleting the old contract from the save file. I thought that would lead to save corruption, but everything seems to be working. The "First Space Station" contract is now available from the mission control building. 

[Sol Invictus]

It would be awesome if someone could add this mod to RP-0 configs:

 

[gemini4]

Okay, so I thought the issue regarding space station contracts had been fixed. I launched a new space station, docked to it, then waited for the specified time. However, upon undocking, the contract parameter for "return the crew home" continued to track the station, not my crew capsule, as the return vessel. Another parameter, however, called "keep the station in orbit" also tracked the station. So, there are two problems I face. One, I didn't equip the station with a heatshield or parachutes, so I can't possibly return the crew in it. (Even if I did include those, it wouldn't be aerodynamically stable, and would probably tumble and burn up). Two, I can't keep the station in orbit and return crew in it! Is there a way I can get the contract to recognize my crew capsule as the return vessel? I though Contract Configurator had fixed this particular issue. Maybe it's an issue with the RP-0 contract itself. Does anyone have any advice on how to resolve this issue?

[MarvinCZ]

23 minutes ago, gemini4 said:

Okay, so I thought the issue regarding space station contracts had been fixed. I launched a new space station, docked to it, then waited for the specified time. However, upon undocking, the contract parameter for "return the crew home" continued to track the station, not my crew capsule, as the return vessel. Another parameter, however, called "keep the station in orbit" also tracked the station. So, there are two problems I face. One, I didn't equip the station with a heatshield or parachutes, so I can't possibly return the crew in it. (Even if I did include those, it wouldn't be aerodynamically stable, and would probably tumble and burn up). Two, I can't keep the station in orbit and return crew in it! Is there a way I can get the contract to recognize my crew capsule as the return vessel? I though Contract Configurator had fixed this particular issue. Maybe it's an issue with the RP-0 contract itself. Does anyone have any advice on how to resolve this issue?

I had a similar problem to yours but in my case the game told me to return the crew in my Space station and keep the capsule in space I think in my case it may have been caused by me changing the control point ("Control from here") when the two were joined.
Unfortunately, I didn't figure out a way to fix it. I manually marked the contract as completed like you and it's been broken ever since.

[JuxuR]

I just noticed that people have got RO already working with 1.2.2. I was wondering if anyone has managed the same with RP-0? I started a stock career and it just isn't the same (a minor understatement :D)

[chrisl]

On ‎2‎/‎9‎/‎2017 at 10:27 AM, gemini4 said:

Okay, so I thought the issue regarding space station contracts had been fixed. I launched a new space station, docked to it, then waited for the specified time. However, upon undocking, the contract parameter for "return the crew home" continued to track the station, not my crew capsule, as the return vessel. Another parameter, however, called "keep the station in orbit" also tracked the station. So, there are two problems I face. One, I didn't equip the station with a heatshield or parachutes, so I can't possibly return the crew in it. (Even if I did include those, it wouldn't be aerodynamically stable, and would probably tumble and burn up). Two, I can't keep the station in orbit and return crew in it! Is there a way I can get the contract to recognize my crew capsule as the return vessel? I though Contract Configurator had fixed this particular issue. Maybe it's an issue with the RP-0 contract itself. Does anyone have any advice on how to resolve this issue?

I just had the same problem occur.  It seems that when you first dock with your space station, the contract is listing the current vehicle (which is now the combined space station + crew capsule) as "crewCapsule" in the "ContractVesselTracker" portion of the savegame.  When you then undock your actual crew capsule, the ContractVesselTracker information doesn't get updated.  Presumably what needs to happen is the "crewCapsule" key needs to store the id of the actual crew capsule just prior to docking.  Not sure if that's even possible or not.  The only "work around" I have for this is to make a save just after you undock, then edit the save in three places:

1) In the "ContractSystem" SCENARIO, find the "Return the crew home" PARAM in the "First Space Station" CONTRACT and change the ship name in "id = Vessel:" to match the actual name of your crew return vehicle.
2) In the same location at #1, change the ship name in "title = Vessel:" to match the actual name of your crew vehicle as well.
3) In the "ContractVesselTracker" SCENARIO, fine the "crewCapsule" VESSEL field and change the id to match the GUID of your actual crew return vehicle.

I then reloaded my save and the contract appeared correctly.  From there I was able to deorbit my crew capsule and complete the mission.  It may only require the change in #3 to fix the problem but in my play through, I made all three of the above changes just to be safe.

EDIT: After further testing I found that the contact works perfectly if you don't change scenes or load a savegame after docking.  But if you change scenes or load a savegame after docking, then the only way to fix the contract is to hack your savegame file.

Edited February 11, 2017 by chrisl

[Aelfhe1m]

7 hours ago, JuxuR said:

I just noticed that people have got RO already working with 1.2.2. I was wondering if anyone has managed the same with RP-0? I started a stock career and it just isn't the same (a minor understatement :D)

I've just started doing some preliminary testing into porting over my long running (started in 1.0.5 and currently in 1.1.3) RP-0 career into 1.2.2 (I'm basing it off this spreadsheet @rsparkyc published on the RO discussion thread). Initial impressions are:

The good:

• All in-flight vessels loaded safely and appeared to be in the right orbits - I need to do a careful comparison of resources/dV remaining and exact orbit parameters.
• KCT build queues, tech unlocks, techs being researched and build/research rates carried over without problem.
• Accepted contracts appear to have carried over successfully (will need to do a careful case by case examination of each wrt expiry dates, rewards, penalties and vessel tracking to be sure).

Glitches/issues:

• Mk 2 Pod (4m) (the VSR replaced Mk1-2 command pod) has a visual issue with permanent RCS jet exhausts displayed from all ports. This is visual only and does not affect manoeuvring or resource usage as far as I can tell. No other part has shown the same issue yet that I've tried. Image
• In one load of the save a large number of unlocked parts became unpurchased again - easily fixed by re-purchasing them and then "cheating" funds back to original level
• Many parts picking up the "non-RP-0" label that weren't labelled as such in 1.1.3

Untested:

• FAR seems to work fine for rockets but I've read it's not yet ready for high speed jets or spaceplanes but since I don't generally build these I can't comment.
• Still need to check whether individual engine configurations that were unlocked have carried over correctly
• Re-entry tests - I've done some test launches and orbital manoeuvring without issue. I'll be doing at least one re-entry test tonight.
• Atmospheric friction/heating comparisons in general
• Science - the number of points I have to spend is correct but I haven't checked in detail that the science gathered per biome is still correctly listed
• Remote Tech - vessels in flight that are supposed to have connection still do but I haven't checked ranges or signal strengths etc. Or behaviour when signal is lost.
• KJR interaction with IR joints - to be tested tonight
• Not currently running with full suite of mods that I was using in 1.1.3 so will need to gradually add the others (that I still consider necessary/useful) and test again
• Lot's of other things I haven't thought of yet...

Edited February 10, 2017 by Aelfhe1m
added spreadsheet reference and image link

[Phineas Freak]

9 hours ago, Aelfhe1m said:

Mk 2 Pod (4m) (the VSR replaced Mk1-2 command pod) has a visual issue with permanent RCS jet exhausts displayed from all ports.

Did you test it with the latest RO from the repository? AFAIK there is a compatibility patch for the ModuleRCSFX ("RO_RCS_Fixes.cfg").

9 hours ago, Aelfhe1m said:

Many parts picking up the "non-RP-0" label that weren't labelled as such in 1.1.3

You need to either use the tech tree config from the KSP 1.1.3 RP-0 release or compile your own from the RP-0 "tree.yml" database (but requires a Perl interpreter).

BTW, for the reentry tests make sure that you have RealHeat installed. There were some cases of false bug reports regarding the heating model that were caused by the missing RH mod.

[Aelfhe1m]

3 hours ago, Phineas Freak said:

Did you test it with the latest RO from the repository? AFAIK there is a compatibility patch for the ModuleRCSFX ("RO_RCS_Fixes.cfg").

I'm using the 11.4.0 tagged version which includes that file.

3 hours ago, Phineas Freak said:

You need to either use the tech tree config from the KSP 1.1.3 RP-0 release or compile your own from the RP-0 "tree.yml" database (but requires a Perl interpreter).

Doh! I'm blind! Copying in the tree.cfg file fixed the issues with both the number of parts marked non-RP-0 and parts being marked unpurchased.

3 hours ago, Phineas Freak said:

BTW, for the reentry tests make sure that you have RealHeat installed. There were some cases of false bug reports regarding the heating model that were caused by the missing RH mod.

Yes, I've got RealHeat installed (the 1.2.2 recompiled DLL). Nothing definitive to say yet but some light testing last night seemed to have very low ablator usage for reentry from LEO and LVO (Venus).

On a similar note the parachutes (real chutes configured radials) showed the same strong heat warning bars when deployed I'd seen previously in 1.1.3 while no other parts on the lander showed any heat warnings - although this may be more a problem with my design rather than anything systematic.

Didn't see any significant issues during several hours of play testing last night. I test launched several rockets that I had designed during my 1.1.3 play-through and they seemed to behave (very subjective) as expected. Docking a supply drone to my LEO space station worked flawlessly as did undocking the crew transfer vehicle for return to Earth. Jumping to each "in flight" vessel from the tracking station showed no noticeable problems with any missing parts or deviation from expected orbit. Even old landers on Mars, the Moon and Phobos loaded with no problems. Queued up manoeuvre nodes for probes en-route to the outer planets were also still showing the expected post node encounters.

Performance felt similar to 1.1.3 although I think I'll need to add MemGraph to this build as well to reduce the time between GC - it was essential for me in 1.1.3. 

MechJeb was the only noticeable problem - and that minor - with a couple of times where it tried to fire the engine prematurely when asked to execute a manoeuvre (easily solved by manually waiting for the correct time before executing) and some back-and-forward oscillations when using Smart A.S.S. that weren't present when using the stock SAS. Possibly PID tuning?

[Phineas Freak]

3 hours ago, Aelfhe1m said:

I'm using the 11.4.0 tagged version which includes that file.

My mistake, i have fixed it locally and haven't push the fix to the mainline yet...

3 hours ago, Aelfhe1m said:

On a similar note the parachutes (real chutes configured radials) showed the same strong heat warning bars when deployed I'd seen previously in 1.1.3 while no other parts on the lander showed any heat warnings - although this may be more a problem with my design rather than anything systematic.

It is probably because of the low maximum temperature of the parachute materials (the casings themselves have a maxTemp value of 1073.15 K).

3 hours ago, Aelfhe1m said:

Performance felt similar to 1.1.3 although I think I'll need to add MemGraph to this build as well to reduce the time between GC - it was essential for me in 1.1.3.

You won't see a big improvement but you will never have a crash (well, there is that 0.1% chance that something will go wrong).

Nice to see more people helping and i really like the "all-up" testing style that you are managing!

 

[Starwaster]

36 minutes ago, Phineas Freak said:

It is probably because of the low maximum temperature of the parachute materials (the casings themselves have a maxTemp value of 1073.15 K).

Is that skin or internal? SkinMaxTemp should be higher to represent heat resistant coatings. (IRL that would actually be part of the heat shield if one is present or applied as an ablative paint to withstand ascent)

In Deadly Reentry I actually give those parts a skin temp of 2300 until the cap is ejected. (which happens the first time a chute is (pre) deployed from that part) (oops it's just 2300... didn't actually implement a lower temp after deploy...)

Edited February 11, 2017 by Starwaster

[Phineas Freak]

@Starwaster If @Aelfhe1m means the stock "Mk-2R" then it's internal one.

The parachute parts do not have a maximum skin temperature pre-defined so DRE is needed to patch them (neither stock nor RO include these fields).

[Starwaster]

4 hours ago, Aelfhe1m said:

MechJeb was the only noticeable problem - and that minor - with a couple of times where it tried to fire the engine prematurely when asked to execute a manoeuvre (easily solved by manually waiting for the correct time before executing) and some back-and-forward oscillations when using Smart A.S.S. that weren't present when using the stock SAS. Possibly PID tuning?

Reduce engine gimbal authority to 33%-50%

Don't use control surfaces on rockets for ascent. (or if you really want them try using the Dynamic Deflection mod which reduces control surface authority at high speeds) Link here: Plugin Workshop

2 minutes ago, Phineas Freak said:

@Starwaster If @Aelfhe1m means the stock "Mk-2R" then it's internal one.

The parachute parts do not have a maximum skin temperature pre-defined so DRE is needed to patch them (neither stock nor RO include these fields).

If skinMaxTemp isn't defined then it uses maxTemp (so, 1073.15 per your previous example)

[rsparkyc]

5 hours ago, Aelfhe1m said:

MechJeb was the only noticeable problem - and that minor - with a couple of times where it tried to fire the engine prematurely when asked to execute a manoeuvre (easily solved by manually waiting for the correct time before executing) and some back-and-forward oscillations when using Smart A.S.S. that weren't present when using the stock SAS. Possibly PID tuning?

I'm having the same issue with mechjeb executing maneuvers immediately, so glad to know I'm not the only one.  I haven't been able to reproduce it in stock yet, so I don't know what's going on with that one.