How do we incorporate new parts and directions for using those parts into the
spaceship core? The answer is that we need to have drivers that can hook into
the central spaceship logic. We need components to provide (through their drivers)
several things
Things drivers need to do
Register with the spaceship OS, request a driver ID, and record the ID when it is
given.
Explain what resources this component provides and what commands to send to
directly set the resource output. Possibly how to increase or decrease power
relatively.
i.e. The power supply provides "power" send "power-set n" to set the power
or "power change n" to increase or decrease relative to current power.
Explain what resources this component requires and how to set absolutely or
relatively the amount that it consumes.
Receive client components that receive resources from it and a number of
tickets for that client that give its relative proportion of resources.
Receive messages that change the number of tickets that a component has,
this includes both absolute (e.g. "tickets set id 1234 to 10") and relative
multipliers (e.g. "tickets mul id 1234 by 1.5") Multipliers can be useful
when inflating or deflating tickets.
Receive supplier components that will be providing resources to it. It
requests resources directly from these suppliers and receives resources from
them.
Give the ability to receive human readable documentation on each
command. This involves both a short description (e.g."This command increases
power output of the Mk IV power supply by N") and a longer more in depth
description that describes all considerations (e.g. "... decreasing the
emissions output drastically decreases the power output on this model. It is
not recommended to limit this unit by emissions... ")
Provide safety tolerance levels for each input and output (which can either
send a warning or error) as well as the ability to adjust these tolerance
levels.(e.g. "power tolerance 10MW. If output is increased above 10MW
emissions will increase exponentially and a warning will be sent to the OS
log. command to change: set power-tol 11MW.") Note that changing tolerance
is just disabling the safety settings, not actually affecting the way the
component behaves. One would expect the factory tolerances to be set wisely,
but conservatively.
Handle the multivariate function relating inputs to outputs. This might
unfortunately include the inverse functions when the outputs are set to
particular levels, requiring the inputs to be decreased
proportionally. Because of this, the functions should probably combine
inputs linearly and apply a transformation function to keep things
simple. Inputs and outputs should be weighted, not by tickets, but by how
the component uses the resource, (e.g. "Increasing power increases the CPU
output dramatically, but increasing cooling only improves CPU output
marginally.")
\ Note:
If the component provides "information" resources (e.g. sensor data etc), it
needs more commands to be able to change attributes of the information stream
(e.g. "Shift to blue wavelength"). The spaceship OS is the only client for
information resources and generally the information streams are binary in
terms of their tolerances (off if below it, on and fully functional if
above). There could be exceptions to this that alter things like sensor range
etc.
Ideas
Since components are linked directly to their clients and suppliers, it
makes sense to have "network" components that don't provide anything but
simply distribute the resources from several inputs. So for example, a power
distribution network could take power from 8 different small power supplies
and appear to the rest of the system as a single power supply. This would be
useful in situations where a single large item requires too much power for
any one power supply, but can only be the client of one power
supply. (components aren't necessarily limited to having only one supplier,
but each will have some finite limit). These distribution networks could
exact some efficiency cost, (e.g. turning 5% of aggregate power into heat).
How do we incorporate new parts and directions for using those parts into the spaceship core? The answer is that we need to have drivers that can hook into the central spaceship logic. We need components to provide (through their drivers) several things
\ Note: If the component provides "information" resources (e.g. sensor data etc), it needs more commands to be able to change attributes of the information stream (e.g. "Shift to blue wavelength"). The spaceship OS is the only client for information resources and generally the information streams are binary in terms of their tolerances (off if below it, on and fully functional if above). There could be exceptions to this that alter things like sensor range etc.