Original Design

RealScience Design

Note: This is the original design for RealScience, from which the actual plugin was built. While the end result is close, it isn't an exact match. The actual documentation is in a different place and more accurate.

Core Design Goals

1. Remove the "Whack-a-Mole" style science of stock KSP
2. Replace the generic science point based unlock system with something more logical using research from various schools of science

Scientific Experiments

In stock KSP science is a very arcadey "whack-a-mole" system whereby the user basically mounts some specific part, then goes to the proper situation and clicks a button, and boom gets science points. Even worse, you often get into this style of drifting in an orbit time warping hoping to catch a biome you don't already have so you can quickly hit the button and get more points. The system has even spawned mods like ScienceHelper which while a great mod is just a band-aid on top of a bad system.

In RealScience, experiments are things that actually take time to be done. The core tenet of any RealScience experiment is that you gather data over time while your craft meets the experiment's conditions, and then once you have enough data, you can analyze that data to complete the experiment and gain completion points. These points can be either stock KSP science points, or points in a specific science discipline if using the RealScience tech tree replacement.

To give the authors of KSP gameplay mods the most control over defining experiments, RealScience uses a somewhat complex but very powerful system to define how a science experiment works, under what conditions data can be gathered, etc.

Defining an Experiment

At its most basic, an experiment definition is composed of several pieces.

Like parts, an experiment has a name, title, and description. In addition there is an amount of research data required for the experiment, and lastly one or more conditions that indicate when data can be gathered.

Research Data

As long as the experiment is activated and the required conditions are met, research data is gathered at over time at a configured amount per second of operation. Once enough research data has been acquired, the player can analyze the data to complete the experiment. While the analysis can optionally take time, the experiment conditions are not required to be met during analysis.

Conditions

Conditions are the meat of the system, and while complex, allow for an extremely large amount of flexibility in defining an experiment. Many properties are exposed to use as parameters. A very simple experiment might have only a single condition to be met, but more complex experiments can define multiple conditions using a very powerful grouping system, along with both required and optional conditions.

Conditions can be specified individually, in which case all the conditions must be met unless any are marked as optional. However groups and sets can be used for more complex condition setups allowing OR and AND conditions.

The exact properties of a Condition will depend on the individual condition type being used, but may look something like this:

condition
{
    type = orbit
    name = orbitCondition1
    eccentricityMin = 0
    eccentricityMax = 0.05
    ApoapsisMin = 150000000
}

Condition Groups

Condition Groups contain one or more individual conditions, but the group is evaluated as a whole, meaning that only the group has to evaluate to true. For example, you can have a group with multiple conditions where only one of those conditions needs to be true for the group as a whole to be true.

Groups specify multiple conditions, and can be one of two types, either requiring all of the conditions in the group be met, or requiring only one of the conditions in the group be met.

group
{
    type = and
    name = group1
    conditions = orbitCondition1,myCondition2
}

group
{
    type = or
    name = group1
    conditions = orbitCondition1,myCondition2
}

In addition to allowing more complex conditions, groups can also be used to allow for varying rates of research data for example you may want a range of orbits to be satisfactory for an experiment, but want certain altitudes to give a faster research rate, you might do something like this:

MODULE
{
    type = RealScienceExperiment
    condition
    {
        type = orbit
        name = IdealOrbit
        apoapsisMin = 200000000
        apoapsisMax = 250000000
        eccentricityMin = 0
        eccentricityMax = 0.05
        dataRate = 100
    }
    condition
    {
        type = orbit
        name = AcceptableOrbit
        apoapsisMin = 150000000
        apoapsisMax = 300000000
        eccentricityMin = 0
        eccentricityMax = 0.05
        dataRate = 50
    }
    group
    {
        type = or
        conditions = IdealOrbit,AcceptableOrbit
    }
}

Condition Types

RealScience allows for using many different properties for defining conditions, with more being added all the time. More extensive documentation on individual condition types will come later. Some of the available types include:

• Orbital parameters such as Apoapsis, Periapsis, Eccentricity, etc
• Altitude
• Air pressure (Static or Dynamic)
• G-Load
• Parts present on craft
• Resources available, as well as resources used over time or one shot
• Velocity
• Biome, Situation masks
• Planetary Body
• Craft orientation. A weather or mapping satellite that isn't pointing at the planet is pretty useless. Probably better to do this by part orientation (and make it part of the Part condition?) but I am unsure at the moment if that is possible.

Unorganized Thoughts

Conditions can be set as restriction which effectively inverts it to say this condition must not be met. Additionally an exclusion can be set to cause the experiment to fail if met. This would cause the entire experiment to be aborted and could not be tried again. Alternatively an exclusion could be set to simply invalidate research data, which would wipe all accumulated data, but the experiment could be tried again.

There are a few ways that "collection and analysis" can be handled. A traditional way would be that the craft collects the research data, then analyzes it, and then either transmits the final results or they have to be recovered. This can be shaken up a bit in a couple ways. One way would be to require the raw research data be transmitted, and then analyzed by mission control. This could also be an optional choice. It might require more power to transmit the raw data, but it might take less time than doing the analysis on board the craft. Another fun twist would be where an experiment is fun in conjunction with mission control. In this scenario, research data is transmitted to mission control as it is acquired. The experiment can only collect data while a connection is valid. With this the player can get several advantages. One advantage would be that you know mission control always has the latest data. This can be very useful in the case of experiments with data gathered over multiple flights. If the craft is suddenly lost, at least mission control has the latest data and you can continue gathering with a new flight. Another possible advantage is allowing mission control to assist with the research, which might give a bonus to data rate. Again the downside to this choice though would be that the experiment can only collect data while a valid connection exists. To mitigate gaming the system, the choice to to do joint research would be made at the start of the experiment and could not be changed without fully resetting the experiment.

There should be a persistent UI that allows easy interaction with the system rather than the cumbersome system of right clicking parts. This UI would also expand the power of the system to allow manipulation of things like multi-flight experiments, on-rails experiments, etc.