Procedural Avionics

[rsparkyc]

I'm working on procedural avionics for RP-0, and figured I should open up an issue to get some feedback on what I'm trying to implement.

1. As controllable mass (M_C) goes up, part mass (M_P) should go up.
   1. I'm thinking at a rate of M_C=aM_P², where a higher value of a (mass efficiency coefficient) means a more efficient curve.
   2. Using a formula of M_C=aM_P² means that it's more efficient (mass-wise) to use one procedural avionics unit per vessel (or at least per stage).
   3. Maximum M_C, as well as values of a could be limited per tech level.
2. As M_C goes up, part cost should go up.
   1. For now, I think a directly proportional relationship to M_P would be realistic.
   2. Cost coefficient would go down as tech level goes up.
3. As M_C goes up, electric consumption (E_C) goes up
   1. Should this also follow the same rule as part mass, and thus be directly proportional to M_P?
   2. If so, as technology increases, M_P:E_C ratio gets better.
4. At some point, being able to put avionics in standby mode becomes available, and standby E_C rates get better as technology increases.
5. Should we have several "classes" of procedural parts (ones optimized for small probes vs. booster/sustainer sections of rockets)?
   1. Perhaps booster avionics cannot be shut down, have horrible E_C rates, but better mass and cost ratios?

Let me know if your thoughts. Here's what I have already (https://github.com/rsparkyc/RP-0/tree/proceduralAvionics):

• [x] A Procedural Avionics Part
• [x] M_P increases proportionally to M_C
  • [x] M_C increases exponentially to M_P
• [x] Part cost increases as M_C increases
• [x] E_C increases as M_C increases
• [x] As technology gets better:
  • [x] Cost ratio gets better
  • [x] Maximum M_C increases
  • [x] M_C:M_P ratio gets better
• [x] Different "classes" of procedural parts
• [ ] Tech balancing (spreadsheet here: https://docs.google.com/spreadsheets/d/1lpuszH_nUbWlTXZzfOMzsy-uhUNh016eNu0WL8x6qvU/edit?usp=sharing)

[stratochief66]

@NathanKell probably has some feelings on this idea, hopefully he'll poke up his head to voice what he things should and shouldn't change.

I think that pad limits rocket/controllable size sufficiently, so I don't think M sub C needs to be controlled through avionics.

I personally like the linear structure we have now, but I can understand that can be argued against on grounds of gameplay as well as reality. IIRC, if you put all the existing fixed size avionics units, I think you find that there are 'tiers' of avionics, like Start, Early, Advanced. In each tier, there is a set "avionics per avionics mass" and "avionics per EC/s". That makes it illogical to try and throw an unmanned lander at the Moon before you have a certain tier of avionics, because of the mass and EC penalties associated.

If possible, having different tiers of avionics class, selected through the RF interface would be ideal. That way, the user could choose which tier/efficiency they wanted to use, appropriate to what they want to do with it. Even late game, I'd use lower class avionics for strap-ons/lower stage boosters, because low cost is more important than EC or mass efficiency there.

[rsparkyc]

One thing I was planning on doing was graph out the current avionics units to see if I could spot trends in them, as procedural avionics should follow a similar trend.

[NathanKell]

Quick hit cuz night before movers arrive and on phone ATM.

First, this is awesome! Second, it's 2d rather than linear. Tech and controllable mass. We currently have something like 3-5 generations each for booster, upper, and probe guidance. Third, exponential, yeah. But generally however the exponent is < 1.0, see the early guidance rings for example. If you want >1 exponentiation I'd suggest having a mass limit per tech level beyond which you get, instead of economy of scale, the 'at any cost' custom sort component issue (and, uh, balance ^_^ )

Cheers!

On Mar 3, 2017 11:38 PM, "Ryan" notifications@github.com wrote:

One thing I was planning on doing was graph out the current avionics units to see if I could spot trends in them, as procedural avionics should follow a similar trend.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KSP-RO/RP-0/issues/623#issuecomment-284126899, or mute the thread https://github.com/notifications/unsubscribe-auth/AE5-IkihPUYh7Kl1qNHAB58tKakgniYrks5riOq5gaJpZM4MS8CO .

[leudaimon]

That's very awesome! You are going to use tech levels in a similar way it works for RCS thrusters, with the mass, cost and EC efficiency increasing based on tech level the same way ISP increases for the thrusters, right? I really like the idea of having three different types of avionics: Probe core, Upper stage and booster, with different capabilities and progressions. This is already the way things work right now, so I guess it would be easy to get a basic progression from the current parts. This way, probe cores could start at Tech 0 totally unable to provide control (like in the current implementation for the sounding rocket core and the sputnik, vanguard, etc.) and with a base mass and EC. With progression, they should prioritize EC efficiency over mass, as probes are never too massive, and avionics shut-down should be always present once control is possible. Upper stages could provide only basic control in the beginning, and attain turn-off capability later on. Also, for the progression, I think they would be a middle ground between probes and boosters. For boosters, I guess the progression is only on the efficiency as I don't see much more that could be easily implemented. Progression should prioritize mass efficiency, and the cost should be lower than the others.

[rsparkyc]

Coding Question: As controllable tonnage goes up, the mass of the part goes up. I wanted to keep it somewhat realistic so you couldn't have a tiny part with a huge mass, so I figured I should have a (configurable) maximum avionics density. The problem is, I need to know the volume of the part. Since this is based off of procedural parts, should I just reference the ProceduralParts.dll, and use the functions in there to compute part size?

[stratochief66]

That seems sensible. I ways things if it just like a ProcPart RealFuel tank. So, if someone wants a ProcAvionics part of a certain size, they could adjust the "Utilization" slider down to get the amount of avionics/mass of avionics unit that they wanted. Is that reasonable or possible, the route you're going?

[rsparkyc]

A similar route. I wasn't going to have M_C be an actual resource, but rather just a property on the part, so it wouldn't be the utilization slider that would affect it, but a separate slider.

[leudaimon]

I guess if it worked as a resource, you would be able to add EC and maybe even propellant into the part along with the avionics, making it easier to build a satellite bus or upper stage guiding unit. @NathanKell called this "avionics juice" in some discussion about procedural avionics. Of course, even if avionics is not a resource, the part could have a service module tank built-in.

[rsparkyc]

As it is, the part is juts a copy of the Procedural Battery, so it's already pretty much set up for RF integration. The reason I didn't want to add "avionics juice" is because it's not really a consumable resource.

[leudaimon]

Good point. I guess the only thing to take into account then is that the part dry mass is what should determine Mp, and then it could have a given tankage, maybe even given by this separate slider you will use.

[rsparkyc]

By implementing the IPartMassModifier interface, all I need to do is specify how much more mass the avionics module uses, and all the masses seem to work out properly.

[NathanKell]

Probably the easiest way to do this is add a new resource, Avionics. Then put a ModuleFuelTank on the part and have that tank type support the Avionics resource. Then have a module that checks how much of that resource there is, checks the tech level, checks the avionics type (booster/upper/probe) to determine wattage and controllable mass. That should be fairly easy to write as an extension to ModuleAvionics in the RP-0 dll.

Well, that's how I was going to do it at any rate, the cheapest approach I could think of. :)

[rsparkyc]

Yeah, that would work, however I've already implemented an avionics slider which seems to work pretty well without the need for a new resource. To me, it just seems weird to have a non-consumable resource. Plus, this way prevents you from dumping excess "avionics juice" when you no longer need it (because I would totally cheat and do that...)

[NathanKell]

Hah! Yeah, true.

Ok, in that case then yeah you'll need to either reflectively grab volume from the proc parts module or hard-bind to it and grab volume.

[rsparkyc]

oOo, I could use reflection, then I wouldn't need to reference the procedural parts assembly... might be worth it since I literally need like one field.

[NathanKell]

Yep, that seems the best bet.

[rsparkyc]

Reflection FTW:

private float GetCurrentVolume()
{
    float currentShapeVolume = float.MaxValue;
    foreach (var module in part.Modules)
    {
        var moduleType = module.GetType();
        if (moduleType.FullName == "ProceduralParts.ProceduralPart")
        {
            var reflectedShape = moduleType.GetProperty("CurrentShape").GetValue(module, null);
            currentShapeVolume = (float)reflectedShape.GetType().GetProperty("Volume").GetValue(reflectedShape, null);
        }
    }
    return currentShapeVolume;
}

[jwvanderbeck]

I always felt the "Avionics Juice" way to do it was a rather silly abstraction that doesn't do the system justice. Then again I never stepped up to make vision reality so who am I to judge :)

[rsparkyc]

For anyone following along, today was a good day, as I was able to implement my mass:controllable mass ratio code. The remaining stuff should be pretty straight forward, and pretty soon I'll have some example complete tech nodes setup, so perhaps people could help me build those out. I can provide more details for anyone interested.

[rsparkyc]

Ok, I actually pushed my ProceduralAvionics branch to the RP-0 repo. There's a readme that talks all about how to configure tech nodes.

[stratochief66]

When I change the 'Tonnage' or 'Configuration' options, the Mass: Dry: xx.xxkg reading doesn't update, but if I open the display again, it does show the new value. In contrast, hanging diameter and length show immediate changes to the new values.

[rsparkyc]

@stratochief66, yeah, those values are from Procedural Parts, and are only looking at the mass of the batteries, and not the avionics portion. I don't know how to go about causing those to update without changes to Procedural Parts.

[rsparkyc]

Could use more tech nodes, but PR is here: https://github.com/KSP-RO/RP-0/pull/624. Closing this, we can move the conversation over there.