Skip to content

RT 2.0 Proposal

Jump to bottom
Yamori Yuki 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 packages and their classes

  • RTCommandPlanner [package], requires RTCommandManager
    • will provide interface for building planned commands from listed conditions and actions, or by capturing actions from GUI and recieving them through API
    • will provide API for registering condition/action and autopilot providers and pushing actions
    • Significant classes:
      • RTCommandApi will provide the command and autopilot API
      • CommandPlanner will handle building of planned commands (or pass them through when not planning)
      • PlannedCommandManager will handle all planned commands for all vessels including signal delay if present
      • CommanInterceptor will capture stock actions performed through GUI and push then into CommandPlanner
  • RTDelay [package]
    • will handle all the delay calculation and keep CommNetVessels signalDelay updated with current delay to a control source
    • will provide API for reading signal delay between vessels but also for modifying the delay calculations by adding additional rules
      • RTDelayApi will provide the API
      • DelayManager will keep manage the delay information for the CommNet network
  • RTFlightComputer [package], optionally works with RTCommandPlanner
    • will provide the same features as in current RT (maybe limited by what the probe core's SAS can do)
    • will be usable as a standalone mod and serve as an example of using RTCommandApi
  • RTDataTransmitter [package]
    • will provide ModuleRTDataTransmitter a version of stock ModuleDataTransmitter that consumes resources while the antenna is enabled and other improvements
  • RTCommon [package]
    • will provide utilities for the rest of RT code
  • RTAntennas [package]
    • will contain additional antennas and their MM patches
  • ModularCommNetPatcher [package]
    • May or may not be necessary. Requires further CommNet investigation
    • will provide an organized way for multiple mods to modify CommNet network by adding or removing links and other changes
  • RTXDishPointing [package], requires ModularCommNetPatcher
    • will provide a dish pointing feature from current RT

Most packages will not have hard dependencies other than on RTCommon. This means that they can be used as separate mods if desired. Just pick and choose! For example:

  • Using kOS to control far away probes? You probably don't need RTCommandPlanner.
  • You do not want to deal with signal delay? Just don't use RTDelay and RTCommandPlanner will simply work with delay of 0s.
  • Never liked our FlightComputer? Don't include it. You can use regular SAS buttons next to the NavBall.
  • If you're developing a mod that would benefit from signal delay, you can distribute RTDelay with it. No need to include the rest (except RTCommon).

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