Procedural avionics

[dgfl-gh]

This is just here to remind me that procedural avionics will need custom code for their hard disk. Their tier progression probably won't work well with MM patches.

Vague guidelines for how it should end up working:

• Only probe avionics (and maybe deep space?) will have an HDD
• HDD size will depend on the tech level and the size of the probe. To expand an interesting mechanic, available memory should depend on avionics utilization: previously, there were no reasons not to use the smallest possible volume; with this, you'll need a larger and heavier probe to store more data, and mass/cost could be balanced with existing avionics code.
• It is also the simplest way to add customizable hard disks, which will probably need to be added anyway (not actually customizable, only dedicated HDD parts - procedural hard disks would be nice though, and fix the avionics problem entirely)
  • to expand on this, a dedicated "procedural memory" part would actually fix the problem, but I think of it as a less elegant solution: it will add yet another part in the editor, with its own tree placement, cost, mass, and upgrades. It's also not really intuitive that a procedural probe doesn't have an internal memory, but if the other option is too hard to implement, this might be a viable solution.

[dgfl-gh]

From @ockidj 's ideas, a RF resource could also be an interesting idea; it would need research on how mass/volume scales with the amount of memory and the tech level, and a way to upgrade density and cost of the resource.
The easiest implementation of custom HDDs would be the other proposal: configurable options for the stock science capsule (possibly resized) that you could stack to your liking. Might work as a temporary solution.

[pap1723]

This is (I believe) the best approach going forward for Procedural Avionics in general. They should be an RF fuel as well.

…

On Fri, May 17, 2019, 4:28 PM Standecco ***@***.***> wrote: From @ockidj <https://github.com/ockidj> 's ideas, a RF resource could also be an interesting idea; it would need research on how mass/volume scales with the amount of memory and the tech level, and a way to upgrade density and cost of the resource. The easiest implementation of custom HDDs would be the other proposal: configurable options for the stock science capsule (possibly resized) that you could stack to your liking. Might work as a temporary solution. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEUNW73DG2XZT4QOJFXBYU3PV4PP5ANCNFSM4HLCCNJQ> .

[dgfl-gh]

This is (I believe) the best approach going forward for Procedural Avionics
in general. They should be an RF fuel as well.

Why would you think that a RF fuel would be better? How would you handle upgrading and customization? Won't it clutter the already too long list of fuels?

[pap1723]

The main reason is for usefulness and flexibility. As of right now, the stock probe cores are much more flexible. They all come with integrated tanks. So I can decide to use 20,000 EC or I can use RCS fuel, or I can leave it empty.

Proc Avionics currently just have a set percentage of EC in the part and that is it. Ideally, there would be the ability to have them more flexible as an RF fuel. You will easier be able to set the exact amount of avionics control you want, and then resize the part to fit that, or to give you the ability to add additional fuel, EC, or Kerbalism hard drive space.

[Gordon-Dry]

I also suggest to have a PlannerController available for ModuleProceduralAvionics to be able to toggle the power consumption in the planner during vessel construction.