rsparkyc

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

43 posts in this topic

17 hours ago, rsparkyc said:

One thing that the probe core has that the upper stage does not (at least in some configurations) is a sample return container.  Still, it looks like it could use some balancing (perhaps raising the minimum tonnage of the upper stage?)

I've not had time to look at it in more detail yet, but what I've realised is that the parts don't scale linearly, so probe cores are very effective at small sizes.  I was just using a probe core for "too big a size".  What I want to do is look up (or reverse engineer) the formulae so I can graph out where the tipping points / envelope boundaries are.  It might be perfect, just a matter of expectations vs reality...  Will be a few days before I do that though

Share this post


Link to post
Share on other sites

Posted (edited)

edit: No, still not getting any science, even after updating everything to make sure correct versions are installed.

----

Hey, I've just installed RP-0 again atop my RSS install, and I've got a weird new issue: Transmitting science does not give any science points. IE, my unmanned early rocket (using two reflectrons) is transmitting temperature/pressure/telemetry data, which works fine, goes to 100%, says Done!, but there is no confirmation message telling me the actual report is unlocked at R&D. I'm not getting science points, and there is also no entry in the science archieves.

Only science points I've gotten was by recovering a craft that was in flight/in space. Contract rewards itself work.

---

output.log, if it helps: https://www.file-upload.net/download-12561483/output_log.txt.html

 

Has a whole bunch of nullrefs (most annoying FAR ones), but they don't seem to affect science. (also tried without kerbokatz science sampler, same result)

Edited by Temeter

Share this post


Link to post
Share on other sites
On 6/18/2017 at 9:25 AM, MatBailie said:

I've not had time to look at it in more detail yet, but what I've realised is that the parts don't scale linearly, so probe cores are very effective at small sizes.  I was just using a probe core for "too big a size".  What I want to do is look up (or reverse engineer) the formulae so I can graph out where the tipping points / envelope boundaries are.  It might be perfect, just a matter of expectations vs reality...  Will be a few days before I do that though

All the formulas I use should be in the RP-0 readme

2 hours ago, Temeter said:

edit: No, still not getting any science, even after updating everything to make sure correct versions are installed.

----

Hey, I've just installed RP-0 again atop my RSS install, and I've got a weird new issue: Transmitting science does not give any science points. IE, my unmanned early rocket (using two reflectrons) is transmitting temperature/pressure/telemetry data, which works fine, goes to 100%, says Done!, but there is no confirmation message telling me the actual report is unlocked at R&D. I'm not getting science points, and there is also no entry in the science archieves.

Only science points I've gotten was by recovering a craft that was in flight/in space. Contract rewards itself work.

---

output.log, if it helps: https://www.file-upload.net/download-12561483/output_log.txt.html

 

Has a whole bunch of nullrefs (most annoying FAR ones), but they don't seem to affect science. (also tried without kerbokatz science sampler, same result)

what version of remote tech are you using? There was a bug that dealt with that that I fixed a while ago: https://github.com/RemoteTechnologiesGroup/RemoteTech/pull/715

1 person likes this

Share this post


Link to post
Share on other sites

Posted (edited)

28 minutes ago, rsparkyc said:

what version of remote tech are you using? There was a bug that dealt with that that I fixed a while ago: https://github.com/RemoteTechnologiesGroup/RemoteTech/pull/715

Thanks, that's probably it!

1.8.4 for some reason, which is two weeks before you made that report. Strange, I only recently downloaded remotetech. Not sure why I've gotten an outdated version.

edit: Yep, that was it.

Edited by Temeter
1 person likes this

Share this post


Link to post
Share on other sites

Posted (edited)

3 hours ago, rsparkyc said:

All the formulas I use should be in the RP-0 readme

Most of what I wanted seems to be in the spreadsheet, thanks :)

How do you arrive at the figures for PartVolume, EmptyWeight and EmptyCost?

Without really understanding those figures all I can notice for now is that the values for EarlyProbeCore(Stability) appear to be an order of magnitude smaller than the others...

 

EDIT:

It appears that the spreadsheet is editable publicly, I thought I was editing a copy, but it appears to be the "master".  This may mean other people have also accidentally made changes?

As it stands, I can also see that:

  • Agena's empty weight is higher than its desired mass?
  • Same goes for Saturn 1 IU
  • GuidanceUnit's (Starting) and (Early) have very low Empty Weight (< 10% of desired mass)
  • Early Probe Core has even lower Empty Weight (< 2.5% of desired Mass)
Edited by MatBailie

Share this post


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

Most of what I wanted seems to be in the spreadsheet, thanks :)

How do you arrive at the figures for PartVolume, EmptyWeight and EmptyCost?

Without really understanding those figures all I can notice for now is that the values for EarlyProbeCore(Stability) appear to be an order of magnitude smaller than the others...

 

EDIT:

It appears that the spreadsheet is editable publicly, I thought I was editing a copy, but it appears to be the "master".  This may mean other people have also accidentally made changes?

As it stands, I can also see that:

  • Agena's empty weight is higher than its desired mass?
  • Same goes for Saturn 1 IU
  • GuidanceUnit's (Starting) and (Early) have very low Empty Weight (< 10% of desired mass)
  • Early Probe Core has even lower Empty Weight (< 2.5% of desired Mass)

Yeah, everything was based off of the non-procedural versions, which don't always correlate well to a procedural counterpart.  The version for 1.3 will have a re-worked tech tree, and with that, re-worked procedural avionics configs that hopefully make more sense.

Share this post


Link to post
Share on other sites
1 minute ago, rsparkyc said:

Yeah, everything was based off of the non-procedural versions, which don't always correlate well to a procedural counterpart.  The version for 1.3 will have a re-worked tech tree, and with that, re-worked procedural avionics configs that hopefully make more sense.

But still, how were these three figures worked out?  Is there a formula, or lookup or something?

  • PartVolume
  • EmptyWeight
  • EmptyCost

 

Share this post


Link to post
Share on other sites
Just now, MatBailie said:

But still, how were these three figures worked out?  Is there a formula, or lookup or something?

  • PartVolume
  • EmptyWeight
  • EmptyCost

 

So this is in the readme:

  • Create a part roughly the same size and shape of an existing avionics module unlocked in that tech node.
    • Take note of its volume. Enter this in column G of the spreadsheet. (Note: the KSP UI normally shows liters, but in the spreadsheets it's kiloliters.)
    • Slide the utilization slider down to 0, and take note of its empty weight and empty cost. Put those in columns H and I respectively.
1 person likes this

Share this post


Link to post
Share on other sites
Just now, rsparkyc said:

So this is in the readme:

  • Create a part roughly the same size and shape of an existing avionics module unlocked in that tech node.
    • Take note of its volume. Enter this in column G of the spreadsheet. (Note: the KSP UI normally shows liters, but in the spreadsheets it's kiloliters.)
    • Slide the utilization slider down to 0, and take note of its empty weight and empty cost. Put those in columns H and I respectively.

Apologies and thanks, I didn't see that :)

Share this post


Link to post
Share on other sites
1 minute ago, MatBailie said:

Apologies and thanks, I didn't see that :)

haha, no problem, it's tucked way down at the end, and I couldn't even remember how i got some of those values, so I had to look them up.

One thing that needs to change is the ability to configure the battery in the part.  that would change the empty weight and cost

Share this post


Link to post
Share on other sites

Posted (edited)

16 hours ago, rsparkyc said:

haha, no problem, it's tucked way down at the end, and I couldn't even remember how i got some of those values, so I had to look them up.

One thing that needs to change is the ability to configure the battery in the part.  that would change the empty weight and cost

Here's the start of my fiddlings...  https://docs.google.com/spreadsheets/d/1DwuBP1sBmWVDATh5VL8kTTNqM34D5hZoQu0eM6KWjrU/edit#gid=276131757

 

I've re-arranged all the formulae until I can work out "If I want to control Mass X with Utilisation Y, then what would the avionics mass and cost be?"

I haven't looked at power consumption yet.  Or a clean way to compare different Avionics parts at different utilisation levels (When does "Upper(Stability) @ 200%" become more mass or cost effective than "Probe(Stability) @ 100%"), they're for another day.

 

Changing the Controllable Mass or Utilisation values will change the pink area.  But that's not very interesting.

Changing the Utilisation value also changes the charts, which do show some useful things already, but I'm still working on stuff.

 

I work out the %Avionics and AvionicsCostPerTon as follow...

  • I make a a vehicle of X tons
  • I then add avionics and tweak it's setting to be "just enough" to control the vehicle (nothing extra / wasted)
  • The avionics is now showing a that its mass is Y and its cost is Z
    • MassPerPayloadTon = Y / X     (Is effectively, the % increase in mass due to adding the avionics)
    • CostPerPayloadTon = Z / X

 

For now this is what I've found...

  • Probe(Stability) and Probe(Science) are very close to each other
    • @ 50% Utilisation
      • Probe(Stability) : 59.10% mass increase due to avionics @ 2,232 kredits per ton of payload
      • Probe(Science) : 62.75% mass increase due to avionics 2,341 kredits per ton of payload
    • @ 100% Utilisation
      • Probe(Stability) : 40.34% mass increase due to avionics @ 7,109 kredits per ton of payload
      • Probe(Science) : 36.05% mass increase due to avionics @ 6,209 kredits per ton of payload
    • @ 200% Utilisation
      • Probe(Stability) : 22.61% mass increase due to avionics @ 24,549 kredits per ton of payload
      • Probe(Science) : 19.24% mass increase due to avionics @ 21,179 kredits per ton of payload
  • Upper(Early) and Upper(Stability) are similarly matched
    • @ 50% Utilisation
      • Upper(Early) :      4.60% mass increase due to avionics @ 34.66 kredits per ton of payload
      • Upper(Stability) :  5.46% mass increase due to avionics @ 60.13 kredits per ton of payload
    • @ 100% Utilisation
      • Upper(Early) :      2.87% mass increase due to avionics @ 21.09 kredits per ton of payload
      • Upper(Stability) :  2.96% mass increase due to avionics @ 49.45 kredits per ton of payload
    • @ 200% Utilisation
      • Upper(Early) :      1.66% mass increase due to avionics @ 27.41 kredits per ton of payload
      • Upper(Stability) :  1.58% mass increase due to avionics @ 105.99 kredits per ton of payload

I suppose the rational there would be that the UpperStage(Stability) has more SAS controls and so is usually slightly heavier, and always more expensive.

Another observation is that the Maximum Tonnage doesn't really achieve anything as far as I can tell?  Although UpperStage(Early) is limited to 10 tons, what stops me from stacking two avionics parts?

Regarding the template parts these procedural avionics are derived from; often have very varying amounts of electrical charge in them.  The probe cores having impossibly large amounts of charge (surely wouldn't fit based on the corresponding tech for batteries).  You've already mentioned that the battery component is to be improved, I think at that time it would be good to consider the mass and cost of the battery component of the original template.

  • Currently the Probe avionics are artificially heavy and expensive because the mass and cost essentially assumes the equivalent battery is present as would be in the Early Probe Core.
  • This means that we're paying for a battery (in kredits and in mass), then getting a Much smaller battery and so having to add more mass and cost to include that battery...
  • When basing Probe(Stability) on an Early Probe Core, for example, perhaps work out the equivalent battery mass and cost for that Early Probe Core's electrical capacity and deduct them from the resultant avionics part mass and costs?
Edited by MatBailie

Share this post


Link to post
Share on other sites

Posted (edited)

Looking at the spreadsheet more closely, and playing around a bit, I can see one particular "unusual property" of the Procedural Avionics...

If I make a Procedural Avionics Part 1.5m diameter and 1.0m tall, it has a mass of 0.3888 tons @ 0% utilisation.  It includes a battery with 7775 ECs, which equates to a procedural battery of 0.0293 tons.  This leaves 0.3595 tons that "do nothing" / "structural mass".  That's 92.45% of the Avionics package...

  • Is that "structural mass" intended?
  • Can it me amended to a lower value?

The reason I ask is that when coming to replicate pre-existing avionics more accurately, I find the following example:

  • Agena is also 1.5m diameter and 1.0m tall, with a mass of 0.228 tons
  • It includes 42,480 ECs, equivalent to a 0.1603 ton procedural battery
  • That leaves 0.0677 tons for the avionics and "structural mass"
  • But the Procedural Avionics already uses 0.3595 tons for "structural mass"

My suggestion would be that the mass of an Empty Procedural Avionics Part shouldn't be much more than a "Structure [Procedural]" of the same dimensions plus a "Battery [Procedural]" with the same number of ECs.

Such an example would allow Agena to be replicated as...

  • 0.08836 tons of "Structure [Procedural]"
  • 0.0293 tons of "Battery [Procedural]"
  • 0.0118 tons of "dead space / other stuff" (10% of the above two combined)
  • 0.09854 tons of "Active Avionics"  (About 43% of the part)
    • After checking these figures I realise this would only give 7775 ECs
    • Correcting that would still make the avionics mass go negative
    • The principle of my question still holds though:
      • Is reducing part density an option?

Would such a scheme be possible?

  • Looking in proceduralAvionics.cfg, change @dryDensity to 0.0733?
  • And then rework all of the other mass values too, which I am fiddling with at present...

 

EDIT : Added part in purple...

Edited by MatBailie

Share this post


Link to post
Share on other sites

Hey @MatBailie!

Nice points you raise here. I'm trying to build new configs for procedural avionics for the future version of RP-0, that will use a new tree.

I went for a different approach, building a tech progression more independent of non-procedural parts, aiming for a more constant improvement in all avionics types throughout tech levels. If you want to have a look at it, it's in this PR: https://github.com/KSP-RO/RP-0/pull/703 Suggestions and balance issues are very welcome.

Also, about this relationship between part size and utilization, I made a suggestion for @rsparkyc here: https://github.com/KSP-RO/RP-0/issues/702 More input is very welcome.

Share this post


Link to post
Share on other sites
2 hours ago, leudaimon said:

Hey @MatBailie!

Nice points you raise here. I'm trying to build new configs for procedural avionics for the future version of RP-0, that will use a new tree.

I went for a different approach, building a tech progression more independent of non-procedural parts, aiming for a more constant improvement in all avionics types throughout tech levels. If you want to have a look at it, it's in this PR: https://github.com/KSP-RO/RP-0/pull/703 Suggestions and balance issues are very welcome.

Also, about this relationship between part size and utilization, I made a suggestion for @rsparkyc here: https://github.com/KSP-RO/RP-0/issues/702 More input is very welcome.

Thanks, will have a look shortly :)

In terms of my own learning; what should I be reading if I want to lower the cost of an empty Procedural Avionics part?  I've tried changing "@costPerkL = 50" to "@costPerkL = 1", but no change.  When I mess around with "@dryDensity = 0.22" to reduce the ECs in the part, that works.  I just can't seem to also change the cost...

Share this post


Link to post
Share on other sites

Posted in old thread before I saw new one was up- 

Have a weird bug to report, I don't necessarily need a fix for it but wanted to post it to let you all know in case it helps with development. 

Steps to reproduce- 

Launched probe (all RP-0 approved parts) to Jupiter flyby.  Collected all science in high orbit and low orbit.  Once I entered Jupiter SOI, probe behaved oddly, spinning wildly on a random axis.  I was able to wrestle control enough to burn radially to lower periapsis into low orbit zone.  Once I got with in 2m mi or so, the overheat gauge on the procedural avionics core almost maxed out but didn't burn or explode.  Shortly after burning to capture, the probe got to about 1.8m mi and suddenly exploded.  Mission recap didn't show anything about overheating or anything else.  Came back to KSC, all contracts were reset back to start.  

Output log- 

https://drive.google.com/open?id=0B6AubkMOT5rrdWJ5Zk8yVDc4UWs

Share this post


Link to post
Share on other sites
On 2017-6-15 at 2:01 PM, KroShan said:

Is it possible for a Mod ( @DuoDex ) to merge the threads.

Possible, yes. Desirable, no. Threads always list their posts in chronological order, and the whole point of this thread is to keep the first post updated with current information about the mod, which @rsparkyc volunteered to do :)

The old thread has been locked, tho, and points here now.

2 people like this

Share this post


Link to post
Share on other sites

Ported from the old RP-0 thread:

Quote

Hello. Could someone who knows a bit more about MM write a patch for me that sets the RP0config setting that gets placed in every part to true? It is quite annoying having 'non rp0/ro part' on every second part that I have. I have this so far:


@PART[*]:Final
{

%RP0conf = true

}

@Benji13 This is a really bad way to handle non RP-0 parts. If you do so, you will end up making all parts compatible with RP-0, even those you are not supposed to be using (not having RO support, not placed correctly in the tech tree, not costed correctly). Using the parts in that state will lead to major game-play imbalances, ending up paying a lot more funds that you are supposed to. TL;DR you will not enjoy the end result.

If you do not wish for these parts to appear then:

  • Create an empty folder inside your GameData folder named "NoNonRP0" (this will hide the parts from the editor list)
  • Install FilterExtensions (this will move all non-RO and non-RP0 parts into their own part categories)

Now, if you just want to make some of the parts compatible with RP-0 then you will have to follow the excellent instructions that @Bornholio gave you over to the RO thread.

2 people like this

Share this post


Link to post
Share on other sites

For some reason I can't seem to locate the parts pack that has the LEO heatshields that are configured for RP-0.  There are a few in DR parts, but in Tree.cfg it seems there are quite a few more configured.  The ones I am interested in are Heatshield-4M, Heatshield-5M, and SoyuzHeatshieldLEO .  Can anyone point me in the right direction?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now