-
Notifications
You must be signed in to change notification settings - Fork 102
RT 2.0 Proposal
This document describes a proposal for future Remote Tech versions built on top of KSP's CommNet feature. Besides RemoteTech running on top of CommNet, the other main goal is to modularize RT in such way that there are self-contained modules within the RemoteTech space. Each module has a public interface to interact with, and has a single functionality/responsibility. This modular architecture enables third-party developers to integrate some of these modules into their mods, and allows players to choose the features of RemoteTech they need or want. To put it simply, think of each RT module as an independent program with a given input and an expected output. Similar to the Unix's pipeline sequence, some of the "programs" work in a cooperating manner to produce an increasingly complex output.
The list of modules is outlined as follows.
-
RemoteTech-CommandHandler
- Ability to build a queue of commands
- An interface to build a queue of planned commands from a list of conditions (including time, velocity and others) and actions or by catching player's actions on particular parts
- Provide an interface for third-party mods to register conditions and actions
- Provide an interface for third-party mods to register their autopilot and receive piloting commands (instead of stock autopilot)
- Significant classes:
-
RTCommandAPI
provides APIs for third-party mods -
CommandPlanner
handles building of planned commands (or pass them through when not planning) -
PlannedCommandManager
executes a queue of planned commands on each eligible vessel, taking the optional signal delay into account -
CommandInterceptor
captures player's actions on parts and passes them toCommandPlanner
-
-
RemoteTech-Delay
- KSP's
CommNetVessel
has an unusedsignalDelay
variable (defaults to 0) for modders to use. - Update the
signalDelay
variable of every eligible vessel based on its connection path to a control source (ground station or command station) - Provide an interface for other mods to do more specific queries (control delay for any vessel, signal delay between arbitrary nodes in the network, etc.)
- Provide an interface for modifying rules of delay calculation
- Significant classes:
-
RTDelayAPI
supplies the APIs as described above -
DelayManager
calculates and updates the delay information of vessels in the CommNet network
-
- KSP's
-
RemoteTech-FlightComputer
- Optionally work with RT-CommandHandler by passing commands into API (instead of directly to stock autopilot)
- Contain the same set of features as RemoteTech 1.x (Execute a maneuver node, SAS buttons, manual aiming etc.)
- Restrict the functions of FlightComputer to a host probe's abilities (like a basic probe shouldn't perform every SAS button)
- Provide an interface for third-party mods, included RT's modules, to obtain some orbital/altitude information of a vessel
-
RemoteTech-Transmitter
- Provide a part module
ModuleRTDataTransmitter
that is an extension ofModuleDataTransmitter
used by stock antennas - An antenna constantly consumes resources when set to active (just like in RT1.x)
- Other improvements are to be determined later
- Provide a part module
-
RemoteTech-Common
- Supply utilities for RemoteTech modules to consume
- The utilities include the interface windows, user settings, antenna-range models(?) and internal CommNet interactions(?)
-
RemoteTech-Antennas
- Non-coding module of antennas, depending on the
Module Manager
mod - MM patches for KSP's stock antennas
- Additional RemoteTech antennas of various ranges and their MM patches
- Non-coding module of antennas, depending on the
-
RemoteTech-DishPointing
- May depend on
ModularCommNetPatcher
- Provide the dish aiming feature, just like in RemoteTech 1.x
- May depend on
-
ModularCommNetPatcher
- An investigation into CommNet is under way to determine how moddability CommNet is and whether this module is required.
- Provide an interface for third-party mods, included RT's modules, to extend or modify CommNet's components such as CommLink, CommNode and CommNetwork classes
Most of the modules are self-contained and reside onto RTCommon. Just choose and install as separate mods! For example:
- Using kOS to automate your probes? You probably don't need RTCommandPlanner.
- Don't like the signal delay? Omit RTDelay and RTCommandPlanner will receive your commands instantly.
- Our FlightComputer is unnecessary? Omit it and press the SAS buttons next to the NavBall.
- If you're developing a mod that would benefit from signal delay, you can include RTDelay and its dependencies into yours.
- [#26] Ability to set up Flight Computer command queue manually
- Set up the command queue in the flight computer before transmitting it to the craft to be executed
- [#42] Execute Planned Maneuver at less than full throttle
- The EXEC instruction should take the throttle slider into account
- Set the throttle to that value when executing the maveuver node
- With consequent increase in time before cutting off the throttle
- [#50] Flight Computer status indicator
- When: actions scheduled in the computer queue; computer is holding attitude; Manual delay is non zero
- [yuki] consider this when developoing GUI for
CommandPlanner
- [#120] In-Game Documentation
- Make RT manual available in KSP
- [yuki] should build RemoteTech entry for KSPedia
- [#195] MechJeb Compatibility
- MechJeb's and RemoteTech's input locks override each other
- no RT signal delay for MechJeb (there should be one)
- [yuki] if MJ is properly working with CommNet there woun't be any issues when combined with RT2.x.
- [yuki] We should invite MJ dev team to comment on our RT2.x proposal once published.
- [#226] Short-Range Interplanetary Dish
- Dish suitable for use outside Kerbin's SoI, but before your probe gets to truly interplanetary distances
- [#358] Adding a way to sanction a change in the stock sas mode
- Issue in kOS where we want to allow users to use the stock sas system in script to handle basic steering
- [yuki] need to consult on this with kOS dev team. We should invite them to comment on RT2.x proposal
- [#366] Execute Maneuver at UT/MET
- Schedule a FC event at a specified UT or MET (see #498)
- [#498] Expanding flight computer: pop conditions, "keep speed" mode, autostage and possibly ignoreRotation for pitch, roll, yaw, orientation
- Various new conditions for popping commands
- [#636] Allow FC to be used with local control
- FC could be used even when vessel has local control
- [#702] KSP's ScenarioModule in place of
RemoteTech_Settings.cfg
in player's save folder- [yuki] RT2.x may not even need this. It should be used as a design guideline for storing per-game settings.
- [#15] Loss of contact during reentry
- craft on reentry could loose contact
- [#436] Signal strength bar
- Signal strength bar (request asks for the first connection on the path to control center)
- [#456] resource other than electriccharge?
- Use a KSPField defaulting as "ElectricCharge"
- [yuki]
ModuleDataTransmitter
has a field listing the name of resource to consume when transmitting, making it ready for MM patches of any electricity mods. Our extension should just use the same resource.
- [#640] Any plans to have more than one default ground station on Kerbin?
- Add default stations (on base game, not through config file)
- [#27] Revised targeting system
- Dishes antennas - target planet; target whoever is in cone view; target a group of sats
- [#107] Dish auto-targeting / Satellite recovery
- Dishes able to automatically select a new target when the ship is out of contact
- [#163] Target search in antenna configuration
- Ability to search for a specific antenna in configuration window
- [#187] Vessel groups
- A handful of satellites can be placed in a named group
- The group appears on the dish target list and can be selected just like any other target
- An antenna that is targeting a group will target a single member of that group (best target in group)
- If the antenna loses contact with its current group member, it will cycle through the group members until it finds one to which it can connect
- [#516] Ability to activate a dish remotely (i.e. map view) if satellite already has a connection
- Also, a "search mode" for unassigned but active dishes that would let them lock onto a signal pointed towards them for receiving commands
- [#705] Antenna animated target tracking, like in original RT1
- In the original RemoteTech, there was an animated, double-jointed dish that could track a connected target
- [yuki] this should be possible, but would require either recovering and updating the original model or creating a new one and figuring out, how to implement this
- [#17] Add a 'frequency' feature to antennas
- Each antenna could have a frequency setting (so it could talk only to antennas on the same freq.)
- [#31] Connection diagnostics
- Mouse-over / click on a satellite in map view to either open the targeting menu or give a summary of distance and connections
- [#35] Beyond horizon comm links on planets with atmosphere
- 2 antennas (up to 30Km?) for atmo only communications; 1 basic and 1 always on (heavier and would require more power)
- [#43] Store Science Transmissions for later Retransmission
- Vessel A transmit science to Vessel B, then when Vessel B can transmit to KSC, it could do the transmission.
- [#108] Building Ground Comm Stations
- Players pay some cash and have a transmission point (Just like the KSC) placed on a designate location on Kerbin
- [yuki] there's a lot that could be done to the CommNet's DSN (sites with different ranges, add sites on DSN upgrades, etc.) but it should stay separate from the main RT
- [#112] Antenna calculator
- In-game calculator for the range between any two antennas under the Root range model
- [yuki] something to build on top of/for CommNet
- [#115] SMA-snapping to counteract satellite drift
- Use the well known trick to Snap the SMA (Semi Major Axis) in RT code to avoid satellite drift (when it is not precisely the same for all satellites at the same altitude).
- [#116] SquareCube Law Transmission model and so on
- [yuki] basically a mod that would alow changing antenna power in editor and/or in flight.
- [yuki] Although separate, RT should provide a way to adjust power consumption of
ModuleDataTransmitter
- [yuki] the rest should be covered by CommNet, more or less
- [#119] Network control
- Control all communications assets from a single place (alternative to what's already in place in RT)
- [#183] Tweakable Relay capability
- Some nodes should not act as relays (similar to #532)
- [#272] Reduce Electricity to Reduce Range
- Slider that lets you reduce power to the dish (in exchange for a corresponding reduction on range)
- [yuki] this covers the base of #116
- [#427] Access to remote vessel resource status when both ends powered and connected
- similar to http://forum.kerbalspaceprogram.com/threads/65769
- [yuki] the linked mod already covers the request, except the connection check.
- [yuki] if the mod works in KSP1.2, there‘s not much for us to do. It does not even need integration with RT as CommNet has all the connection information.
- [#462] Reduce bandwidth when too far away
- Bandwidth for transmission of experiments is full if in range, and 0 if not in range
- Make change to add something in-between.
- [yuki] I think bandwidth in CommNet stays the same, science recovery percentage is affected.
- [yuki] In reality transmitters may have several settings with higher bandwidths needing cleaner signal and vice versa.
- [#532] Request: Non-Relay ModuleSPU
- like #183. Only configurable in editor, once in flight it's too late.