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

[hargn]

9 minutes ago, HeartofGold said:

I'm not actually sure. The game stalls in the loading screen (this one, not my picture) when it says loading the part " Taerobee-decoupler" I tried installing Taerobee both from CKAN and from github and it stalled at the same place. 

Maybe when I get home I'll try to delete that part manually. Not sure why I didn't think of that.

Would people recommend deleting non-RP0 parts from their games?

 

Currently, we cannot help you more if you don't provide your ksp.log, and maybe your installed mod list.

For the NonRP0 parts, you can delete them so that will save some memory, or you can use the NoNonRP0 patch as described in the last section of the RP0 wiki : https://github.com/KSP-RO/RP-0/wiki/FAQ

Edited January 30, 2017 by hargn

[Phineas Freak]

@HeartofGold Usually when you see the loading screen stuck on a part it is the previous one that has a problem. In this case it is the "taerobee_control" part. But, without seeing a log file we cannot be sure what the actual problem is.

[HeartofGold]

Okay, here are my logs

v1 was the logs  before I force closed ksp, v2 after. Probably they are the same. 

I'll try deleting  taerobee_control and see if that allows me to open the game. Either way, I'll put those logs as v3

Just realised maybe I'm meant to put all the .log files in there. Anyway, renaming the taerobee_decoupler files to .bak let me into KSP.

Edited January 30, 2017 by HeartofGold

[Phineas Freak]

@HeartofGold You are using a mod compatible only with KSP 1.2 with KSP 1.1.3:

[LOG 18:49:48.699] PartLoader: Compiling Part 'Taerobee/Parts/Aerobee/taerobee_decoupler/taerobee_decoupler'
[EXC 18:49:48.711] ArgumentException: The requested value 'Coupling' was not found.
	System.Enum.Parse (System.Type enumType, System.String value, Boolean ignoreCase)
	System.Enum.Parse (System.Type enumType, System.String value)
	ConfigNode.ParseEnum (System.Type enumType, System.String vectorString)
	ConfigNode.ReadValue (System.Type fieldType, System.String value)
	ConfigNode.ReadObject (System.Object obj, .ConfigNode node)
	ConfigNode.LoadObjectFromConfig (System.Object obj, .ConfigNode node, Int32 pass, Boolean removeAfterUse)
	PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node)
	PartLoader+<CompileParts>c__Iterator4A.MoveNext ()
[EXC 18:49:48.747] NullReferenceException: Object reference not set to an instance of an object
	PartLoader.GetDatabaseConfig (.Part p)
	PartLoader.GetDatabaseConfig (.Part p, System.String nodeName)
	DragCubeSystem.LoadDragCubes (.Part p)
	Part+<Start>c__Iterator25.MoveNext ()

KSP 1.1.3 does not have the new categories (Coupling, Thermal, Electrical etc) so any parts that use them will fail to compile. Taerobee is one of them.

[HeartofGold]

24 minutes ago, Phineas Freak said:

@HeartofGold You are using a mod compatible only with KSP 1.2 with KSP 1.1.3:

[LOG 18:49:48.699] PartLoader: Compiling Part 'Taerobee/Parts/Aerobee/taerobee_decoupler/taerobee_decoupler'
[EXC 18:49:48.711] ArgumentException: The requested value 'Coupling' was not found.
	System.Enum.Parse (System.Type enumType, System.String value, Boolean ignoreCase)
	System.Enum.Parse (System.Type enumType, System.String value)
	ConfigNode.ParseEnum (System.Type enumType, System.String vectorString)
	ConfigNode.ReadValue (System.Type fieldType, System.String value)
	ConfigNode.ReadObject (System.Object obj, .ConfigNode node)
	ConfigNode.LoadObjectFromConfig (System.Object obj, .ConfigNode node, Int32 pass, Boolean removeAfterUse)
	PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node)
	PartLoader+<CompileParts>c__Iterator4A.MoveNext ()
[EXC 18:49:48.747] NullReferenceException: Object reference not set to an instance of an object
	PartLoader.GetDatabaseConfig (.Part p)
	PartLoader.GetDatabaseConfig (.Part p, System.String nodeName)
	DragCubeSystem.LoadDragCubes (.Part p)
	Part+<Start>c__Iterator25.MoveNext ()

KSP 1.1.3 does not have the new categories (Coupling, Thermal, Electrical etc) so any parts that use them will fail to compile. Taerobee is one of them.

Thanks Phineas.

So I'm using a new version of Taerobee! That makes sense. Over on the Taerobee Github I can only see the last two versions. Does anyone know what version of Taerobee was for KSP 1.1.3? Or where to find it? Or shall I ask over in the Taerobee  thread

[hargn]

17 hours ago, HeartofGold said:

Okay, here are my logs

v1 was the logs  before I force closed ksp, v2 after. Probably they are the same. 

I'll try deleting  taerobee_control and see if that allows me to open the game. Either way, I'll put those logs as v3

Just realised maybe I'm meant to put all the .log files in there. Anyway, renaming the taerobee_decoupler files to .bak let me into KSP.

I don't see any errors related to Taerobee, so I don't know what was happening here. Seems that I was not reading the good one 
Did you install your mods in using CKAN?

I also want to suggest you to uninstall all mods that are not recommended or suggested by RO/RP-0 : KRASH, RasterPropMonitor and StageRecovery (your version was a pre-release) for example.

TweakScale is also known as incompatible with RO so you probably want to uninstall it.

Edited January 31, 2017 by hargn

[HeartofGold]

8 minutes ago, hargn said:

I don't see any errors related to Taerobee, so I don't know what was happening here. Did you install your mods in using CKAN?

I also want to suggest you to uninstall all mods that are not recommended or suggested by RO/RP-0 : KRASH, RasterPropMonitor and StageRecovery (your version was a pre-release) for example.

TweakScale is also known as incompatible with RO so you probably want to uninstall it.

Thanks Hargn. Stage Recovery is definitely one I didn't even want, so I'll uninstall that.

I'll remove KRASH and RasterPropMonitor also.

Yeah, I installed everything using CKAN until I started debugging. I was only trying to install RP0 and it's dependencies and suggested mods...  (plus chatterer)

Maybe I'll start again tonight.

Isn't TweakScale rather important for RO?

 

 

 

 

 

 

[hargn]

4 minutes ago, HeartofGold said:

Thanks Hargn. Stage Recovery is definitely one I didn't even want, so I'll uninstall that.

I'll remove KRASH and RasterPropMonitor also.

Yeah, I installed everything using CKAN until I started debugging. I was only trying to install RP0 and it's dependencies and suggested mods...  (plus chatterer)

Maybe I'll start again tonight.

Isn't TweakScale rather important for RO?

Procedural parts, stages, and fairings do the job and are much more usefull than TweakScal.
But it is also incompatible with RO, so don't use it, else you can have parts with negative mass (that happens to me) that will lead to unspecified craft behaviors.

[Phineas Freak]

40 minutes ago, HeartofGold said:

Over on the Taerobee Github I can only see the last two versions. Does anyone know what version of Taerobee was for KSP 1.1.3?

I think the last version for KSP 1.1 works fine: https://github.com/Tantares/Taerobee/releases/tag/v2.3

9 minutes ago, HeartofGold said:

Isn't TweakScale rather important for RO?

Depends. Some of the structural parts do have TweakScale support but the mod usually does more harm than good for everything else. For example, we explicitly remove any TweakScale support from engines.

Edited January 31, 2017 by Phineas Freak

[HeartofGold]

Thanks everyone. Much thanks to the whole community.

I'll get it sorted tonight.

[HeartofGold]

Thanks for your help everyone, seems to be working now.

Quick question, what Procedural parts are compatible? Can I add some of the ones listed in the Procedural Parts page?

Spoiler

Like these

 

[Phineas Freak]

@HeartofGold These are not parts but add-on texture pakcs for the Procedural Parts. You can install any pack(s) that you like, no limitations apply.

[gemini4]

Is there a way RP-0 could incorporate contracts to orbit satellites of specific masses, and adjust rewards accordingly? There doesn't seem to be a point to using the larger probe cores, or building heavy-lift rockets, for this reason. As a result, I don't find myself using a lot of larger, more expensive engines or probe cores, when lighter, smaller rockets and probes can fulfill all satellite contracts at lower cost. I'm sorry to bother you when you're working on a new release. It's just been a consistent annoyance for me in RP-0.

[hargn]

12 hours ago, gemini4 said:

Is there a way RP-0 could incorporate contracts to orbit satellites of specific masses, and adjust rewards accordingly? There doesn't seem to be a point to using the larger probe cores, or building heavy-lift rockets, for this reason. As a result, I don't find myself using a lot of larger, more expensive engines or probe cores, when lighter, smaller rockets and probes can fulfill all satellite contracts at lower cost. I'm sorry to bother you when you're working on a new release. It's just been a consistent annoyance for me in RP-0.

Hi @gemini4,

I'm working on these kind of contracts since I've raised this issue on github : https://github.com/KSP-RO/RP-0/issues/562

One of the constraints I want to implement for these contracts is to require a minimum mass of monopropellant that your satellite must have to validate the contract.

But when I started to work on these contracts, I've found a lot of bugs in contract configurator and these bugs have been fixed in the CC releases that run on KSP 1.2.
So I add no way to continue to works on these new contracts until the next RP-0 release for KSP 1.2

(In fact, since a pre-release of RO is available, I should now be able to work on it. I've planned to rework on from next two weeks when I would have the time)

[stratochief66]

For anybody interested, there is a new RO forum page, since the forum ate our old one. Thanks to @Theysen for putting it together again.

 

@hargn yeah, I believe the contracts in RP-0 will need some serious updates in order to be compatible with the new version of CC and ultimately work in 1.2.2. Any fixes to make those contracts work would be much appreciated on the RP-0 Github

[hargn]

9 hours ago, stratochief66 said:

For anybody interested, there is a new RO forum page, since the forum ate our old one. Thanks to @Theysen for putting it together again.

 

@hargn yeah, I believe the contracts in RP-0 will need some serious updates in order to be compatible with the new version of CC and ultimately work in 1.2.2. Any fixes to make those contracts work would be much appreciated on the RP-0 Github

The updates done by @rsparkyc to fix all errors and warnings that come with the last CC versions should also be merged with the master branch : https://github.com/KSP-RO/RP-0/pull/606

I prefer to start from a working base before to modify the Groups.cfg and other existant contracts, because I'm really too much lazy to solve conflicts that I could bring

[stratochief66]

@hargn done! I haven't been spending any time looking at the RP-0 repo, since RO isn't updated yet. But if I can help to help someone help, I'll take a look when I'm pinged

[winged]

On 31.01.2017 at 11:11 AM, hargn said:

Procedural parts, stages, and fairings do the job and are much more usefull than TweakScale.

Tweakscale is very useful for rescaling landing legs. Legs we have currently in RO are way too small for any good LM or MAV.

[EliasDanger]

It'd be nice to have some of the deadlines extended just a little bit in the new version...maybe a lot bit in some cases... That's my two cents at least. I don't like feeling under the gun so much.

[leudaimon]

@EliasDanger When I started RP-0 I also tought some of the contracts looked to be too tight when you consider launching windows and tech development. When I was explained that contracts are meant to be accepted only when you are ready to launch the mission (or at least start rocket construction), I noticed they are quite comfortable in general. Do you have any examples of contracts you believe to have too short deadlines?

[EliasDanger]

1 hour ago, leudaimon said:

@EliasDanger When I started RP-0 I also tought some of the contracts looked to be too tight when you consider launching windows and tech development. When I was explained that contracts are meant to be accepted only when you are ready to launch the mission (or at least start rocket construction), I noticed they are quite comfortable in general. Do you have any examples of contracts you believe to have too short deadlines?

 

A lot of them give you enough time if you get it right on the transfer window you're planning on making...but if your craft or crafts dont succeed on that transfer window and you have to try again on the next one....you've pretty much failed and take a pretty big penalty. I would prefer at least two or three transfer windows worth of leeway including transit time. Lotta pressure to hit your target on the first try on those early venus and Mars flybys. It adds difficulty, sure, but it kinda discourages you from trying until you are practically sure you'll hit it on the first try.

And when you look at the real space programs...they failed a bunch of times before they started getting things right. 

Also, not a big fan of building the rocket first and then accepting the contract for its mission. Seems unnecessary. 

The generic satellite contracts give you so much time, it's silly that the more important progression contracts would be so strict.

But that's just my opinion. Don't have to change it for me if no one else feels the same.

Edited February 5, 2017 by EliasDanger

[nanomage]

On 05/02/2017 at 1:43 PM, leudaimon said:

@EliasDanger When I started RP-0 I also tought some of the contracts looked to be too tight when you consider launching windows and tech development. When I was explained that contracts are meant to be accepted only when you are ready to launch the mission (or at least start rocket construction), I noticed they are quite comfortable in general. Do you have any examples of contracts you believe to have too short deadlines?

flybys of neptune and pluto (and uranus to a lesser extent) come with 15-year contract deadlines, necessitating highly (or in case of uranus, slightly) non-hohmann transfers or complicated gravity assists to get there in time. might be argued it's intentional though?

[leudaimon]

@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.

[nanomage]

28 minutes 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.

yeah i agree noone in real life goes there without a jupiter assist, just because it's big and it's there to save you money. KSP is different though because it's easier to build a bigger rocket than chain up two non-hohman transfers to and from Jupiter. But then again, in order to beat the contract deadline, it's easier to make an even bigger rocket and just fly to pluto in a straight line. I really don't know what's the best way to go about those contracts.

To me personally, they discourage Voyager type missions because of 'send new probe' checkbox, tight schedules (i'm not as good as nasa so can't be sure to make do in 15 years, or 12 like Voyager 2), and 20000km height limit (quite tight for gas giants), barring you from a large portion of gravity assist trajectories. btw even voyager two was originally only 'contracted' to visit Jupiter and Saturn, yet the game requires a new probe after accepting contract. But again, this is just rambling, i don't have solutions to how make them better

 

EDIT: that last bit got me thinking that by RP-0 terms, flyby of Uranus is still up for grabs because Voyager-2 didn't tick the height criterion. If something has to be changed about flyby contracts, i'd say first to go is scaling height with target size

Edited February 6, 2017 by nanomage

[leudaimon]

3 hours ago, nanomage said:

yeah i agree noone in real life goes there without a jupiter assist, just because it's big and it's there to save you money. KSP is different though because it's easier to build a bigger rocket than chain up two non-hohman transfers to and from Jupiter. But then again, in order to beat the contract deadline, it's easier to make an even bigger rocket and just fly to pluto in a straight line. I really don't know what's the best way to go about those contracts.

I haven't done much into the outer planets, so I don't have the numbers, but I would guess that just slightly non-hohmann transfers for them would quite reduce your travel time - after all, scape trajectory takes almost the same delta-v than hohmann transfer to pluto. A tool that greatly helps in planning these gravity assists (even though it's not very simple to use to set up exact launch orbits) is the RSSFlybyFinder, it allows to set a launch window for gravity assists.

 

3 hours ago, nanomage said:

To me personally, they discourage Voyager type missions because of 'send new probe' checkbox, tight schedules (i'm not as good as nasa so can't be sure to make do in 15 years, or 12 like Voyager 2), and 20000km height limit (quite tight for gas giants), barring you from a large portion of gravity assist trajectories. btw even voyager two was originally only 'contracted' to visit Jupiter and Saturn, yet the game requires a new probe after accepting contract. But again, this is just rambling, i don't have solutions to how make them better

This "new probe" issue is a problem for several stuff. You can't also trigger both flyby and orbit contracts with the same probe, because the orbit one only shows up after the flyby is complete. And it really discourages tour-like missions. However, I do believe this requirement is necessary to avoid some exploits. Thus, I don't know what would be the proper solution for that, even though I would love to see this requirement relaxed for some kinds of contracts.

 

3 hours ago, nanomage said:

EDIT: that last bit got me thinking that by RP-0 terms, flyby of Uranus is still up for grabs because Voyager-2 didn't tick the height criterion. If something has to be changed about flyby contracts, i'd say first to go is scaling height with target size

It does to an extent. The rocky planets and the moon require 5000km flybys, while the gas giants require 20000km. Besides that, I may be mistaken, but I believe the main issue with close flybys for the gas giants in real life is not related to maneuver difficulty, but magnetic radiation and other kinds of problems not present in KSP. It's quite cheap delta-v wise to adjust a flyby height if you are still far away from your target. Unless you have a probe without any maneuverability (or is planning a gravity assist with a high altitude in said planet) this shouldn't be an issue.

Edited February 7, 2017 by leudaimon