Let's map probe progression!

[ksp-ro]

Let's map probe progression!

[NathanKell]

While I don't think RP-0 should go the entire distance RPL did regarding historical probes and experiments, I do think something like that is a way they can be differentiated.

There are really only two ways we can differentiate probes (other than just making one better than another): what control functionality they offer, and what science functionality they offer.

• Control functionality. Here we would be reliant on RemoteTech implementing my request for a "science core" -- a "half-modulecommand" if you will, where you can do science (or anything else you can do by right-click) but flight controls are locked. That is what every probe payload available until Stability should be, and we should move the large stack probes to the second node, give them very high electricity drain rates, and make them guidance rings. This will allow for rockets to have flight control, but only in a form too heavy (and thirsty) to place into orbit itself, leaving room for small, 1-10kg (or 83kg if you're Russian, beep beep) "science cores" that one does place into orbit or on lunar flyby trajectories.
• Science functionality. Different probe cores should offer different experiments. Guidance rings should not offer science, that's not their job; science cores, by contrast, and later controllable probes, should. JRA has kindly table-formatted a list of all probes launched (successfully or not) 1957-1962, which will give us lots of room for adding new experiments. Even the Earth alone is a fascinating place, and one should have cause to launch many different payloads to explore it--especially since we're removing surface science.

A longer term, more complex way to differentiate probes, of course, is to deal with lifetime and radiation hardening, but that's not really in scope right now.

[pjf]

Different probe cores should offer different experiments.

I think I like this, but I'll need to have it float around in my head for a bit. My initial reaction to have per-probe specific experiments is that I'd just load them all up on my vessel, since they're all relatively light. If that's the case, then they're no different from having science parts themselves.

However I think a real difference would be that certain cores limit the science that you can do. Without the appropriate core, instruments simply can't be used. Imagine that you're building a satellite to watch for variations in pulsar timings to detect gravity waves. You need to have not only the telescope, but some pretty smart electronics to drive it.

By having cores which are specialised towards mapping, or sensor reading, or ground science, or communications, one would need to pick the core (or cores) which are most suitable for the mission being performed. That does differentiate them somewhat.

Unfortunately, that's all going to require code, and I'm still not sure what I think of it in terms of added complexity.

A longer term, more complex way to differentiate probes, of course, is to deal with lifetime and radiation hardening, but that's not really in scope right now.

Do probes in DangIt have an operational lifespan? Because lifespan feels like a relatively simply thing to implement. I mean, it can get complex (being outside the magnetosphere is going to fry you faster than being inside it), but as a first pass a simple mean-time-between-failures and variance model would go a long way to distinguish the probes.

[NathanKell]

I think I like this, but I'll need to have it float around in my head for a bit. My initial reaction to have per-probe specific experiments is that I'd just load them all up on my vessel, since they're all relatively light. If that's the case, then they're no different from having science parts themselves.

And that's exactly what the Soviets did with Objekt D (Sputnik 3 in the West). You can do that if you have an LV capable of that kind of payload (in that case, ~2 tons counting fairings). If you can send up 10kg at a time, that doesn't work so well--heck, even at 100kg at a time! In the US, only Atlas could manage a tonne to orbit, and Atlas was too expensive (and too failure-prone, early on) to use for that kind of thing. Besides, if you do that you're locked in one orbit, and the ideal orbit for detecting the Van Allen belts is very different from the orbit needed for geodetics or cloud coverage...

However I think a real difference would be that certain cores limit the science that you can do. Without the appropriate core, instruments simply can't be used.

That is very intriguing, though I'm not sure how it's functionally different from what you worry about above: doesn't matter if the instruments are inside the probe core (my proposal) or outside, but requiring a certain core...

Do probes in DangIt have an operational lifespan? Because lifespan feels like a relatively simply thing to implement.

That is an excellent point, and not hard to add if it doesn't (woo open licenses). Well, ok, other than calling part.Explode() when the lifespan ends, maybe hard to implement exactly how end-of-life works...@Ippo343 ???

[Ippo343]

Hey Nathan, I am at work now, I'll get in touch later after I read the whole thing :)

---

Da: NathanKellmailto:[email protected]
Inviato: ‎02/‎12/‎2014 08:53
A: KSP-RO/RP-0mailto:[email protected]
Cc: Michelemailto:[email protected]
Oggetto: Re: [RP-0] Let's map probe progression! (#42)

I think I like this, but I'll need to have it float around in my head for a bit. My initial reaction to have per-probe specific experiments is that I'd just load them all up on my vessel, since they're all relatively light. If that's the case, then they're no different from having science parts themselves.
And that's exactly what the Soviets did with Objekt D (Sputnik 3 in the West). You can do that if you have an LV capable of that kind of payload (in that case, ~2 tons counting fairings). If you can send up 10kg at a time, that doesn't work so well--heck, even at 100kg at a time! In the US, only Atlas could manage a tonne to orbit, and Atlas was too expensive (and too failure-prone, early on) to use for that kind of thing. Besides, if you do that you're locked in one orbit, and the ideal orbit for detecting the Van Allen belts is very different from the orbit needed for geodetics or cloud coverage...

However I think a real difference would be that certain cores limit the science that you can do. Without the appropriate core, instruments simply can't be used.
That is very intriguing, though I'm not sure how it's functionally different from what you worry about above: doesn't matter if the instruments are inside the probe core (my proposal) or outside, but requiring a certain core...

Do probes in DangIt have an operational lifespan? Because lifespan feels like a relatively simply thing to implement.
That is an excellent point, and not hard to add if it doesn't (woo open licenses). Well, ok, other than calling part.Explode() when the lifespan ends, maybe hard to implement exactly how end-of-life works...@Ippo343 ???

---

Reply to this email directly or view it on GitHub:
#42 (comment)

[Ippo343]

Okay, finally home and free-ish :)

So, right now in Dang it the probe itself doesn't have a lifespan, but the components in it do (usually, battery and reaction wheel).

However, writing a new failure behaviour is just a matter of overriding some methods and properties (example), so it should be very easy to write additional modules. This way the base class automatically tracks the age, the temperature and generates the events at random.

Keep in mind that unloaded vessels are not currently covered by Dang It: of course, our beautiful community has already devised a solution, but I haven't had time to look into it yet.

I'm afraid I don't have the time right now to work on it (I've abandoned the mod, if you have been following the thread), but I'll be happy to help if you need any help in modifying it. :)

[Felger]

Personally I'm not a giant fan of limiting usage by part failure, even if it is life-like. I'd rather come up with a better game-like reason to encourage the use of larger or later probes.

Potential alternate ideas:

• Probe bodies are just that, the bodies. When you go up a tech level, your engineers can re-outfit with up-to-date electronics.
• In real life, there are several advantages to upgraded electronics:
  • Data processing speed
  • Power usage per data processed
  • Weight
  • Types of Control (How good your GNC software is, how many sensors you can use, etc)

I would not expect lifetime to be a significant factor in upgraded vs non-upgraded electronics. At any point, lifetime is something you design into the system. If you need a longer lifetime, you use more robust components, which have lower performance values. If you need more performance, you sacrifice lifetime. This tradespace exists at all tech levels, so it doesn't make sense to me to limit probe life by tech level.

I had an idea for encouraging big probe cores: control input. I think RemoteTech has a flight computer: we could set it up so that it can only queue up a certain number of control inputs (come to a heading, fire engines for X seconds, use experiment Y), and those slots only fill back up with light-speed communication to Kerbin (or a manned mission). This could also be a very nice way to account for the size of experimental data: complex experiments and high-res images take more space on the flight computer.

You might also try limiting accuracy (engine might burn for X time +/- 0.5%).

This was partially inspired by thinking about just how complex the programming was for something like Rosetta/Philae or the Opportunity rover landing, and trying to rationalize real-time maneuvering in the presence of light-speed communications to mission control.

[pjf]

However I think a real difference would be that certain cores limit the science that you can do.
That is very intriguing, though I'm not sure how it's functionally different from what you worry about above: doesn't matter if the instruments are inside the probe core (my proposal) or outside, but requiring a certain core...

Under a capabilities model, parts may be "locked" unless the vessel contains another part which unlocks it. For example, dish communications may require "Long Range Comms", RCS ports may require "Precise Manoeuvring", and high-gain telescopes may require "High-speed data processing". Optionally, instead of simple unlocks, a core may provide a certain quantity of processing capacity (eg: "Communications: 12"), and fitted parts would consume it (a basic omni requires 1 unit of communications processing, a dish requires 5).

While latter cores can and should obsolete earlier ones, it now makes sense for players to choose lighter, cheaper cores if their craft does not require the additional capabilities. A specialised comms satellite would choose a core high in communications capacity; a specialised science probe would need a core providing lots of science capacity to support all the fitted sensors.

Because most cores would both include and obsolete the capabilities of earlier cores, a player may include two cores for a very wide-ranging mission, but rarely more than that. More advanced probes would contain generous provisions for long range comms, advanced manoeuvring, and other capabilities by default.

Under this model, the choice between different probes becomes much more clear. If you want a sounding rocket, you can get away with something basic. If you want to load your vessel up with a great many sensors, you'll need an expensive (or multiple) cores to support that.

Having said all that, I'm not convinced this is a good idea for RP-0. It's extra complexity, it requires coding, we'd need to make it very clear at build-time if players have exceeded their core capabilities, and it requires going through even more parts and adding even more information to them which humans have to maintain.

[NathanKell]

@pjf Ah, I see what you mean. By contrast, given how, with the exception of the Ranger probes that were repurposed for Mariner (but to do the same task, just farther away) probes are pretty-much custom built for their intended missions. I definitely like @Starman-4308 's idea regarding capabilities, and that fits well with @Felger and your ideas regarding upgrading capability. But we have far more probes than would justify even a number of generations' of upgrades, and we have far more experiments to do than we have, as yet, scientific instruments for them. For that reason I strongly support, at least early on (where next to none of the mod insturments look right anyway), giving different probes different experiment sets.

[Felger]

That's fine by me, as long as in later stages we can unlock all probe core shapes with all experiments. If I want to make a spherical space program with nothing but don't-stayputniks, then I'm going to make a spherical space program!

[pjf]

For that reason I strongly support, at least early on (where next to none of the mod instruments look right anyway), giving different probes different experiment sets.

I am concerned that we're conflating cores and science equipment. From a gameplay standpoint, these have two very different purposes:

• A core is what an un-crewed vessel must have in order to be operational.
• Science is equipment is what any vessel may have if it wishes to conduct science.

This is reflected in the user interface; when players go looking for science experiments, they look in the science tab, and when they're looking for something to control their vessel, they look in the pod tab.

From a gameplay standpoint, I don't like having cores which contain integrated experiments that can't also be performed by stand-alone parts. If you want a core with integrated pressure and temperature sensors, that's great, we're lowering the part count and maybe saving some space, mass, or cost on the vessel overall. But if the core is the only way that an experiment can be done, then I'm against it; that should be a piece of science equipment, and it should go in the science tab.

If we're going to have cores which contain integrated experiments, then I'd suggest such experiments:

1. Be only available on the larger, more expensive cores (the equipment has to fit somewhere).
2. Contain fully repeatable/transmissible experiments whenever possible.
3. Have science-part versions that do the same thing.

We do seem to be ignoring the obvious way of differentiating cores using existing and familiar game mechanics by having later ones use less power and weigh less. For non-science craft, we've essentially given the player the ultimate core almost immediately; the okto2 is lighter and uses less power than anything else that gets developed.

We have far more experiments to do than we have, as yet, scientific instruments for them.

This gives me a terrible feeling you're going to try and add more experiments over what we already have. But as this is something I feel belongs in #43, I'll post my commentary there.

[NathanKell]

A problem here is that for many early probes, the instrumentation is very much built into the probe structure itself. Not always, but often enough. Further, given how much RO itself (and RSS too) upset stock mechanics, it seems a bit of an appeal to nature to claim that we shouldn't change a mechanic because the mechanic exists. What I would suggest, by contrast, is to stop thinking of probes as monolithic.
Instead, I would suggest we consider, as I've mentioned above, three different kinds of "probe core":

1. "Science" (fixme better name?) cores. You can right-click, but that's it. It's very light and it uses next to no electricity, Available from the start, with a 1kg model in Early Orbital (node 2), aka Vanguard's 6.5in Satellite.
2. Guidance rings. (At least) your final controllable stage needs one of these. It's somewhat heavy, it uses a lot of electricity, but it lets you fly. Available from the start (V-2 guidance), efficiency increases over time.
3. Probes. These are light, moderately electricity-frugal parts that let you control uncrewed orbital craft, but they make up for it by being expensive and by being unlocked later (i.e. not until Stability), and by being much heavier (at least early on) than type 1.

It is types 1 and 3 only that should contain any experiments at all.

I agree with you in principal that it's good to have any experiment be available in its own instrument. However, there are numerous problems with this:

1. Many experiments should not be doable on many spacecraft; for instance, there's a ton of stuff you can't do from a crewed craft simply because of the vibrations!
2. Some experiments will conflict with other experiments; some rely on generating magnetic fields and some rely on detecting them, and often you can't just turn off one and use the other.
3. Some experiments really do have to be "designed into" the spacecraft's structure (see my first sentence) and thus you can't attach them to any old spacecraft, even if it doesn't suffer vibrations or its own excess magnetic fields or $foo. For example, the entire surface of the spacecraft may be used as an instrument.

Now, as to differentiation, the problem here is that's not differentiation. That's obsolescence. While we do have enough parts, even in our limited modset, to obsolete a number of probes, that seems quite wasteful to me. Instead, it would make more sense to actually make some probe cores good at some things, and others at others. Upgrade the electronics, sure (and perhaps decrease the mass over time, also needing a plugin), but there's still sense in segregating earth-science stuff from interplanetary (/moonetary) probes from guidance rings from commsats so we have a reason other than "x is better than y, always" to use x.

[NathanKell]

I think we're mostly done with this, discussion has moved to #130. Reopen as desired.