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

[rbray89]

2 hours ago, Temeter said:

Thanks, but the mod description already says the mod doesn't do anything for DX11 users. Or do you use DX11 and had improvements with it?

No. You misread:

" DX11 and OpenGL use graphics memory first, and system memory for spillover, so if you use these graphics platforms, this will not likely show anything on system memory unless you use LOTS of part mods with big textures, or have small available graphics memory. "

What this basically means is that you have two memory locations in DX11. Textures get loaded into one first (graphics) then system if it gets full. This means if you have a video card with 2GB of memory, you won't notice a positive effect on your system memory until you use more than 2GB worth of textures. Note that this may also depend on your drivers/vendor as I haven't tested personally with ATI systems, but feedback I've seen indicates that it behaves the same. 

[Temeter]

1 hour ago, rbray89 said:

No. You misread:

" DX11 and OpenGL use graphics memory first, and system memory for spillover, so if you use these graphics platforms, this will not likely show anything on system memory unless you use LOTS of part mods with big textures, or have small available graphics memory. "

What this basically means is that you have two memory locations in DX11. Textures get loaded into one first (graphics) then system if it gets full. This means if you have a video card with 2GB of memory, you won't notice a positive effect on your system memory until you use more than 2GB worth of textures. Note that this may also depend on your drivers/vendor as I haven't tested personally with ATI systems, but feedback I've seen indicates that it behaves the same. 

Yeah, was a bit to general as an exclamation, that was pretty much what I was assuming: I've got a 2GB graphics card, which is probably more than enough.

[NathanKell]

v0.46

• Improve Big Gemini support for changes in latest RO (thanks chrisl).
• Fix an issue with TestFlight flight data not starting at medium levels for the WAC sustainer and the A-4 (V-2) engine.
• Fix an issue with the stockparts H-1 (thanks stratochief66).
• Tune pricing of LR89 and LR79.
• Correct LR87/91 placement and pricing.
• Show heights in km with numerical separators for easier reading (on sounding rocket and crewed suborbital contracts).
• Avoid an issue with tier 3 runway max allowed sizes (thanks to Lana Kerman for finding this).
• Tune proc part pricing: tanks cost slightly more now, and the shielded tank costs a lot more than a regular tank.
• Increase Moon's spacelow threshold from 100km to 150km.

Needs RO 10.9.5, RF 10.8.5

[PTNLemay]

I'm encountering a really tenacious problem, and once again I'm not sure if it's a mechanic of the mod I don't understand or a bug.

I'm in a career mode run with RP-0 and I'm still early on in the tech tree, I've built a 2-stage rocket (3 if you count the side-boosters) using the A-4 guidance unit , because it seems that nothing else has an SAS onboard.  Every time it reaches the point where the final stage turns on, the vehicle starts to tumble.  I tried flying straight up so as not to have any forces swaying on the craft at the moment of separation, but the thing still starts spinning.  I even brought the number of engines down to one, in case some of them were burning more than others for some reason (they all showed 7.6 kN of thrust).  Also, shortly after the spin starts I get a warning that pops up and tells me “SAS disengaged”, even though I still have plenty of electrical power and I haven't hit the key to turn it off. The little light indicator on the navball even shows it still running.

 

 

I kept the number of separation engines at 2 or 4 (because obviously bringing that down to 1 would cause more tumble) but I don't think they're responsible.  They burn all right, it's when the Aerobees start burning that the problems start.  Can anyone spot something that I might be doing that's obviously wrong?

[Temeter]

Did you check aerodynamic forces with F12? That one often tells you the culprit if its just the aero. Otherwise, maybe its a lack of avionics on the upper stage, do you still have control?

 

Btw, how do i start the space station contracts?

Edited March 12, 2016 by Temeter

[PTNLemay]

I would have thought that at that altitude it wouldn't matter... (the final stage is kicking in above 100 km) but I'll do another simulation and try it.  It would explain a few things, the final stage has no winglets and the nosecone might be enough to drag it off center.  I included one of the A-4 guidance units on that top stage.  In fact it's the root part for the whole thing, and it's mass limit is 20 tons, so I doubt that would be it.

EDIT:
Hmm, actually I was wrong, the separation happens around 60 - 70 km.    Unfortunately the wings don't seem to be enough.  To clarify, here it's just separated.  It was pointing straight upwards, and is now starting it's tumble.

 

Well...I think I found the culprit.  Isn't an aerodynamic nosecone supposed to help prevent this?  I'm still not sure why the SAS just gives up and shuts itself off.  Can it become overwhelmed and quit if the tumbling is too severe?

 

Edited March 12, 2016 by PTNLemay

[Temeter]

Edit, wait a second. What exactly are you controlling the craft with? Do those upper stage engines have gimbal? Because a lot of the earlier ones havent.

-----------

That's weird, no clue whats up with it... Last guess, do you use that antenna mod? Mb its out of range or so.

Would check the craft for you, but I don't have those fuel tanks.

Edited March 12, 2016 by Temeter

[PTNLemay]

Here's another strange little thing I've noticed.  I built my vehicle using 2 A-4 units, which gives me  enough aerodynamic control to have 40 tons on my craft.  Then I made my vehicle 39.9 tons.   Sometimes... when I launch the mass calculation does a little hickup or something and it shows my vehicle mass at the launchpad at 40.6 tons.  This shouldn't even be possible because the launch pad isn't upgraded, so it wouldn't let me roll one out of it was that heavy.   What's also strange is that I can't just launch and engage the SAS after the mass has dropped.  Even when the erroneous mass drops bellow 40 tons, the SAS still wont' engage.

It's not too serious because I can revert to launch and that usually snaps him out of it, and he sees the real mass is bellow 40T.  It's just... odd.  And I felt like brining it up since it seems to be a recurring thing.

Edited March 12, 2016 by PTNLemay

[Temeter]

I think I can explain that one. Somtime the updated weight lags behind, seen it with procedural tanks, seen it when changing a tanks fuel via the bar. For example, you increase the size of a proc tank by one rate and the VAB/Kerbal Engineer/Mechjeb only registers that change after the next action, which then is delayed until the next one, etc.

Best way to figure it out, when you're close to the limits, is to make a super tiny change to the craft before starting so you are sure the checks are updated.

Edited March 12, 2016 by Temeter

[Temeter]

Small (but weird!) bug: The bigger, 10ft FASA LR91(fasageminilr91) is using an Aerozine/NTO for everything but the first config, small one is ok tho.

Same for AEIS' LR91 (liquidengineorbit2)!

[NathanKell]

@Temeter sorry, "is using an" ?

The LR91 (and LR87) did use kerolox for the -3 variant and NTO/Aerozine for all other variants. Well, there was an LH2 version of the LR87 too.

[Maxsimal]

Hi there.  Trying out RP0, which I love the idea of after watching Scott Manley's youtube with it.

I started installing mods from the suggested list that I bumped into here.  Because I've had trouble with mods, I was pretty careful to install a few and test stability.

Because of that, I've found that installing KAS/KIS causes a repeatable CTD when starting/loading into a game. I tested by uninstalling/reinstalling KIS and testing it. Not sure if this is known.  Do you want error logs of this?  

Actually, may not be those - having other CTD's now. 

Edited March 13, 2016 by Maxsimal

[Temeter]

6 hours ago, NathanKell said:

@Temeter sorry, "is using an" ?

The LR91 (and LR87) did use kerolox for the -3 variant and NTO/Aerozine for all other variants. Well, there was an LH2 version of the LR87 too.

I wasn't sure if I wanted to write 'using AZ/NTO' or 'using an AZ/NTO mix' and went for a compromise. Brain thinks to much. ;D

Interesting. Took another look, seems like AIES' small 8ft LR91 is just bugged. Switching configs doesn't do anything for the engien, so it just stays at the RP1 variant. Also misses any info in the switch GUI.

Edited March 13, 2016 by Temeter

[Phineas Freak]

@Temeterif you follow the steps mentioned in this GitHub issue, can you replicate it?

[Temeter]

EDIT: Quick comparision in pictures of working and bugged LR-91:

http://imgur.com/a/4gUSV

Btw, I find it kinda confusing how the context menu in the part selection shows the vernier stats first. Never got to use the engine in my career because i've only looked at the verniers without scrolling down and was confused why i'd ever use the LR91. But it's actually a very fine engine, that would've been perfect for my moon rockets.

48 minutes ago, Phineas Freak said:

@Temeterif you follow the steps mentioned in this GitHub issue, can you replicate it?

Can't replicate it. Engines works just fine on standard config for me, it's just switching won't actually change the engine. Always stays on Kerolex AJ3 with the same stats.

Noteworthy is, I only have 1 'switch gui' option. All other engine+vernier combos like the vanguard booster, or the working LR91's, have the option 2 times, 1 doing nothing and the other one working normal. Picture above shows the difference!

Edited March 13, 2016 by Temeter

[Phineas Freak]

Hmm, weird. The AIES LR91 has exactly the same problem as the FASA 10 ft version. But in my case all hypergolic configurations work as expected .

Edited March 14, 2016 by Phineas Freak

[chrisl]

So here's a problem I run into a lot.  I'm using RO/RSS/RP-0 with FASA and I tend to run the "1/Moon" contract a lot.  Mostly I run the contract using the Saturn V rocket.  Because of the way the Saturn V is put together, you actually build the LEM from the bottom up (descent engine, then decent stage, etc).  This setup doesn't have any problems where flying, docking and landing are concerned.  But fulfilling the contract is usually a problem.  The 1/Moon contract isn't actually considered complete until you land in the correct biome, spend a certain amount of time landed, then return safely to Earth.  This is all good except that, since the LEM was built from the bottom up, when you separate the ascent module, KSP treats it as a new VESSEL which means the time you've already spent landed on the Moon doesn't count.  And you can't really separate early because you need the electricity from the decent module (especially if you're also using TACLS).  Right now, I basically have to hack my savegame file after launching the ascent stage so that the "new" VESSEL counts as completing the contract.  I suppose I could also hack the savegame to "rebuild" the LEM from the top down prior to landing, but again, it requires hacking the savegame which I don't really like to do.  I'm not sure if 1.1 is going to resolve these kinds of staging problems but I'm wondering if, for the time being at least, we should remove the "return safely to Earth" portion of the contract.  That way the contract would complete after you spend enough time on the Moon and separating the ascent stage wouldn't cause the contract to basically have to start over.

[NathanKell]

@nightingale any insight there?

[nightingale]

@chrisl - It's supposed to work.  How Contract Configurator handles this is that on undocking, it "transfers" the parameter completion to all vessels that were all part of the parent vessel (since they were all there when the parameter got completion).  It gets a lot more complicated when you bring docking into this, but this case should be one of the simpler ones.

I looked at the code for this scenario, and everything *looked* okay at a glance.  I have a feeling this is one of those ones that will elude me if I try to reproduce without more info, so I've added a bit more debugging to the code.  Here's what I'll need from you:

1. Grab the latest dev dll of Contract Configurator from here.
2. Set the log level on VesselParameter to VERBOSE (some instructions here).
3. Run the mission as normal, but provide me screenshots that include the contract window while landed and ascending.
4. Provide me with the resulting KSP.log

Thanks, and greatly appreciated if you're able to provide this.

[chrisl]

1 hour ago, nightingale said:

@chrisl - It's supposed to work.  How Contract Configurator handles this is that on undocking, it "transfers" the parameter completion to all vessels that were all part of the parent vessel (since they were all there when the parameter got completion).  It gets a lot more complicated when you bring docking into this, but this case should be one of the simpler ones.

I looked at the code for this scenario, and everything *looked* okay at a glance.  I have a feeling this is one of those ones that will elude me if I try to reproduce without more info, so I've added a bit more debugging to the code.  Here's what I'll need from you:

1. Grab the latest dev dll of Contract Configurator from here.
2. Set the log level on VesselParameter to VERBOSE (some instructions here).
3. Run the mission as normal, but provide me screenshots that include the contract window while landed and ascending.
4. Provide me with the resulting KSP.log

Thanks, and greatly appreciated if you're able to provide this.

I'm working on this now.  Should be able to post the screen shots and log this evening.

[chrisl]

On an unrelated note, as part of my testing I started a "new" game and noticed a couple things.

1) If you use KCT and spend science on several tech nodes at one time, you only gain them one at a time.  I know that wasn't always the case.  Before, you'd research everything in your queue at one time.  I guess I don't mind researching a single node at a time but it does make late game research take a very long time.  I've got 605 point put into TechUpgrades which gets me 5 sci/day and even at that rate the nodes I'm researching now take over a year each.  Just trying to determine which is the correct setup.

2) I think the rewards for the first lunar landing are off.  I've been earning about 500k-1m per repeatable lunar landing contract but I'm going to get something like 15m for the "first time lunar landing" contract.

3) Now that we have the new "HSFOrbitalMoonGenRepeatable" contract, should we get rid of "HSFOrbitalMoon1Repeatable"?  They both effectively do the same thing.

[chrisl]

On ‎3‎/‎14‎/‎2016 at 1:59 PM, nightingale said:

@chrisl - It's supposed to work.  How Contract Configurator handles this is that on undocking, it "transfers" the parameter completion to all vessels that were all part of the parent vessel (since they were all there when the parameter got completion).  It gets a lot more complicated when you bring docking into this, but this case should be one of the simpler ones.

I looked at the code for this scenario, and everything *looked* okay at a glance.  I have a feeling this is one of those ones that will elude me if I try to reproduce without more info, so I've added a bit more debugging to the code.  Here's what I'll need from you:

1. Grab the latest dev dll of Contract Configurator from here.
2. Set the log level on VesselParameter to VERBOSE (some instructions here).
3. Run the mission as normal, but provide me screenshots that include the contract window while landed and ascending.
4. Provide me with the resulting KSP.log

Thanks, and greatly appreciated if you're able to provide this.

After a lot of testing, I have to assume that the problem I was encountering was related to the contract in the version of RP-0 I had been using (0.43).  After upgrading to 0.46 I've been unable to recreate the problem.

[NathanKell]

@chrisl all that is intended.

1. Without that change, you could double your research rate (in sci/day) by researching two nodes, triple it by researching three, etc. That's nuts. You get a research rate, it shouldn't depend on how many nodes you can queue up. The research rate already allows one to be at 1980 levels of technology by 1963 (on hard mode at that) or so; I really don't think it should be sped up further.

2. No, that's correct. Milestones give much higher advances (and higher rewards) than repeatables. Compare first crewed orbital with the repeatable orbitals.

3. No, the early repeatable is much, much easier to complete--in line with early "just get there and come back" orbital missions. The generic one is much more complex and better for later missions.

[Agathorn]

On March 10, 2016 at 8:55 AM, rbray89 said:

No. You misread:

" DX11 and OpenGL use graphics memory first, and system memory for spillover, so if you use these graphics platforms, this will not likely show anything on system memory unless you use LOTS of part mods with big textures, or have small available graphics memory. "

What this basically means is that you have two memory locations in DX11. Textures get loaded into one first (graphics) then system if it gets full. This means if you have a video card with 2GB of memory, you won't notice a positive effect on your system memory until you use more than 2GB worth of textures. Note that this may also depend on your drivers/vendor as I haven't tested personally with ATI systems, but feedback I've seen indicates that it behaves the same. 

This hasn't really been the case for me.  I have a 6gb card but i've never seen KSP use more than about 3.5gb of the VRAM, regardless of mode and mod count.

[chrisl]

16 hours ago, NathanKell said:

@chrisl all that is intended.

1. Without that change, you could double your research rate (in sci/day) by researching two nodes, triple it by researching three, etc. That's nuts. You get a research rate, it shouldn't depend on how many nodes you can queue up. The research rate already allows one to be at 1980 levels of technology by 1963 (on hard mode at that) or so; I really don't think it should be sped up further.

2. No, that's correct. Milestones give much higher advances (and higher rewards) than repeatables. Compare first crewed orbital with the repeatable orbitals.

3. No, the early repeatable is much, much easier to complete--in line with early "just get there and come back" orbital missions. The generic one is much more complex and better for later missions.

 

The "First Crewed Orbital" contract has "advanceFunds" set to 200,000.  The 1/LEO contract (one-man repeatable orbital contract) has "advanceFunds" set to an average of 120k (10k/orbit with 3-24 orbits required).  The milestone rewards about 2 times as much as the repeatable.
The "Crewed Lunar Landing" contract has "advanceFunds" set to 2,000,000.  The 1/Moon contract (repeatable moon landing) has "advanceFunds" set to an average of 150k (50k/12hr with 12-72hr landed required).  The milestone rewards about 13 times as much as the repeatable.
The "First Space Station" contract has "advanceFunds" set to 500,000.  The "New Space Station" contract (repeatable station contract) has "advanceFunds" set to 20,000.  The milestone rewards about 25 times as much as the repeatable.
I'm going to get 8.24mil up front, plus another 3.55mil on completion, of "Crewed Lunar Landing".  That's 11.8mil.  I got about 2mil for "Crewed Lunar Flyby".  Just not sure you should get nearly 6 times as much for landing on the moon versus simply flying by the moon.  Yes, there's more tech needed to actually land.  But the award just seems excessive to me.

As for the LLO contracts, maybe we should setup the 1/LLO contract as a milestone instead of as a repeatable.  It doesn't look like we have a milestone for actually orbiting the moon so 1/LLO would be a good option.  And it seems wrong to have them both show up repeatedly.