Skip to content

RT 2.0 Proposal

Jump to bottom
TaxiService edited this page Dec 1, 2016 · 15 revisions

Introduction

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.

Proposed modules and their classes

The list of modules is outlined as follows.

  • RTCommandPlanner

    • An interface to build a queue of planned commands (timed and passive) from a list of conditions and actions or by catching player's actions on particular parts
    • Provide an interface for third-party parts to register conditions and actions
    • Provide an interface for third-party mods to retrieve the queue of commands for their own uses (autopilot provider)
    • A third-party mod can use this module to obtain a queue of commands for its own use
    • Significant classes:
      • RTCommandAPI provides the third-party parts and mods
      • CommandPlanner handles the 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 to CommandPlanner

  • RTDelay

    • Perform all the delay calculations of every eligible vessel, not just the active vessel at one time
    • Update the signalDelay variable of the stock CommNetVessel class
    • Provide an interface for querying on the signal delay between vessels and modifying the delay calculations through some rules
      • RTDelayAPI supplies the APIs of the said interface
      • DelayManager manages and updates the delay information of vessels on the CommNet network

  • RTFlightComputer

    • Optionally work with RTCommandPlanner by passing commands from the interface
    • Contain the same set of features as RemoteTech 1.x (Execute a maneuver node, SAS buttons, manual aiming eg)
    • Provide an interface for third-party mods, included RT's modules, to obtain some orbital/altitude information of a vessel

  • ModuleRTDataTransmitter

    • An extension of ModuleDataTransmitter found in KSP's stock antennas
    • An antenna consumes resources in an active state, even when a player wraps the time
    • Other improvements are to be determined later

  • RTCommon

    • Supply utilities for RemoteTech modules to consume
    • The utilities include the interface windows, user settings, antenna-range models and internal CommNet interactions

  • RTAntennas

    • Non-coding module of antennas, depending on the Module Manager mod
    • MM patches for KSP's stock antennas
    • Additional RemoteTech antennas of longer ranges and their MM patches

  • 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

  • RTDishPointing

    • Depend on ModularCommNetPatcher
    • Provide the dish aiming feature, as RemoteTech 1.x does so

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.

Feature Requests

Present in RT2.x proposal

  • [#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.

Already covered by CommNet

  • [#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)

Proposed RT extension: DishPointing

  • [#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

Ideas for further RT extensions or third party mods

  • [#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.

Clone this wiki locally