[1.11] RemoteTech v1.9.9 [2020-12-19]

[billybob579]

I've only just learned about the probe control point system that's part of CommNet, and I'm wondering, do those serve any purpose if RemoteTech is installed? It sounds like the same idea behind RT's command stations, but I tested it out and they don't appear to work.

[TheRagingIrishman]

32 minutes ago, billybob579 said:

I've only just learned about the probe control point system that's part of CommNet, and I'm wondering, do those serve any purpose if RemoteTech is installed? It sounds like the same idea behind RT's command stations, but I tested it out and they don't appear to work.

 

The current version of RT is 1.8.3. The 1.8.x series uses only RT stuff as it is a continuation of pre-CommNet stuff. The RT devs are working on starting the 2.x series of RT which will use and extend CommNet but it is a large project and will take some time.

[Benji13]

Hello. I was just wondering, what are the benifits/changes of using this over the stock commnet?

 

On 12/19/2016 at 0:31 AM, neitsa said:

Nope, not a silly question, especially if you never used RemoteTech (RT) before CommNet was introduced. 

As of 1.8.x version of RT: 

• Different antennas
• Harder rules for controlling probes (if you have no connection your probe is just an expensive flying brick... it wont respond to any commands)
• Delay (speed of light effect): if you probe is around duna (without any in between relay) you get approximately a 1 minute delay for each command (i.e. if you press a key or a button the effect is seen only after 1 minute has elapsed in the game)
• Different range models: CommNet use a easier range model than RT (how far you can be from any other connection point to get a signal); RT has two range models.
• A flight computer to enter command ahead of time (due to the connection delay you have to make a flight plan ahead of time)

RT version 2.x - currently in the making - will add other (completely optional) options.

Nevermind, I found this.

[SmarterThanMe]

On 01/01/2017 at 5:37 AM, maja said:

 

Thanks for linking that.. Doesn't seem to add the other ground stations though?

--edit Oh right. Have to start a new game.

Edited January 3, 2017 by SmarterThanMe

[TaxiService]

4 hours ago, SmarterThanMe said:

Thanks for linking that.. Doesn't seem to add the other ground stations though?

--edit Oh right. Have to start a new game.

Psst. You can edit the extra stations into your existing save's RemoteTech_Settings.cfg.

[Errol]

6 hours ago, SmarterThanMe said:

Thanks for linking that.. Doesn't seem to add the other ground stations though?

--edit Oh right. Have to start a new game.

 

Psst. You can edit the extra stations into your existing save's RemoteTech_Settings.cfg.

You have to re-click the button to select the default .cfg in the RT settings screen after you make changes to the .cfg, not just reload the game. 

EDIT: What are the chances that the flight computer functionality could be tied to a part like with mech jeb? I want to have it locked in the tech tree, and I want Dangit! (or bad piloting/craft design) to be able to disable it. And electricity consumption too..

 

Edited January 3, 2017 by Errol

[TaxiService]

2 hours ago, Errol said:

EDIT: What are the chances that the flight computer functionality could be tied to a part like with mech jeb? I want to have it locked in the tech tree, and I want Dangit! (or bad piloting/craft design) to be able to disable it. And electricity consumption too..

For RT 2.x or RT 1.8.x?

For RT 1.8.x, I don't think the flight computer was designed for such scenario as it is too deeply wired to everything.

For RT 2.x, it could be accomplished once the flight computer is remade into independent and isolated component.  

[Errol]

I was talking about for RT 2. Just a suggestion since I know you guys are looking into all that stuff now. 

Just feels wrong to have full access to the flight computer at the start of a career when my prodes don't even have SAS yet...

Edited January 3, 2017 by Errol

[Guest]

[KSP 1.2.2][RT 1.8.3]

Strange behavior:

Controlling core is autonomous core and also there is also 2 crewed and 1 empty crew cabins on the vessel, all looking at some direction.

Vessel have a node planned and RT is set to "Hold node" and execute node in future.

Sent Kerbonaut to EVA - from habitation module , not from any crew cabins.

What happened: Immediately after Kerbonaut left vessel, vessel started to rotate to prograde and stopped here. After returning from EVA vessel immediately returned to Node.

[Sumu]

Hey All, wondering if anyone can help me, I'm trying to play with remote tech but I can't seem to get it to start. Whenever I play none of the features are enabled. If I review my "KSP.log" File I have the following error.

I went as far as completely uninstalling and reinstalling the game with ONLY remote tech loaded and same issue.

I'm using the version from the first post in this thread and I'm running this via Steam, I'm "installing" by placing the files into the gamedata folder, is that correct?. Any tips on what I might be doing wrong or how to correct the error would be greatly appreciated.

This is the error:

[ERR 18:41:54.438] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null

[ERR 18:41:54.445] AssemblyLoader: Exception loading 'RemoteTech': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 

Additional information about this exception:

 System.TypeLoadException: Could not load type 'RemoteTech.RTSettings' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.Settings' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.VesselSatellite' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.Modules.ModuleRTAntennaPassive' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.Modules.ModuleRTAntenna' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.Modules.ModuleRTDataTransmitter' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.Modules.ModuleSPU' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.FlightComputer.EventCommand' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.FlightComputer.FlightComputer' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.SatelliteManager+<>c' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.UI.DebugWindow+<>c__DisplayClass20_0' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.UI.FocusFragment+<>c__DisplayClass3_0' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.UI.FlightUIPatcher+<>c' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.API.API+<>c' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.IO.FileNotFoundException: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'

 System.IO.FileNotFoundException: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'

 System.TypeLoadException: Could not load type 'RemoteTech.FlightComputer.Commands.AbstractCommand' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.FlightComputer.Commands.AbstractCommand' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.FlightComputer.Commands.AbstractCommand' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.FlightComputer.Commands.AbstractCommand' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.FlightComputer.Commands.AbstractCommand' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.FlightComputer.Commands.AbstractCommand' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.FlightComputer.Commands.AbstractCommand' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.FlightComputer.Commands.AbstractCommand' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'RemoteTech.FlightComputer.Commands.AbstractCommand' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c__DisplayClass34_0' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c__DisplayClass36_0' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'State' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<SetFXModules_Coroutine>d__112' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c__DisplayClass9_0' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<Transmit>d__17' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'State' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'State' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c__DisplayClass74_0' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c__DisplayClass83_0' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c__DisplayClass13_0' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'DriveMode' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c' from assembly 'RemoteTech, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null'.

Thanks!

 

[garwel]

On 1/3/2017 at 7:56 PM, Errol said:

I was talking about for RT 2. Just a suggestion since I know you guys are looking into all that stuff now. 

Just feels wrong to have full access to the flight computer at the start of a career when my prodes don't even have SAS yet...

It's been discussed earlier and, in fact, this feature is in the announcement for RT 2.0.

[neitsa]

@Errol : As @garwel hinted, we'll restrict the flight computer capabilities to the probe capabilities (by default; this will be probably customizable in settings if you want to override it.).

@WildLynx: Looks like a bug, yep. We'll see if we can repro (with only KSP + RT) & find the root cause.

@Sumu : Try RemoteTech 1.7.2 (it seems you are still on 1.7.0 although it shouldn't have given this problem whatsoever) if you are still on KSP 1.1.3. I can't get what's wrong though if you have only KSP + RT... That sounds strange...

From the root folder of your KSP install, it should look like this:

Spoiler

Neitsa@Falcon /KSP/KSP_113
$ tree ./GameData/RemoteTech/ -L 1
./GameData/RemoteTech/
├── Default_Settings.cfg
├── Parts
├── Plugins
├── RemoteTech.version
├── RemoteTech_AIES_Antennas.cfg
├── RemoteTech_AIES_Probes.cfg
├── RemoteTech_Antennas.cfg
├── RemoteTech_B9_Probes.cfg
├── RemoteTech_CactEye_Probes.cfg
├── RemoteTech_FASA_Antennas.cfg
├── RemoteTech_FASA_Probes.cfg
├── RemoteTech_LLL_Antennas.cfg
├── RemoteTech_LLL_Probes.cfg
├── RemoteTech_MechJeb.cfg
├── RemoteTech_NearFuture_Probes.cfg
├── RemoteTech_NovaPunch_Antennas.cfg
├── RemoteTech_NovaPunch_Probes.cfg
├── RemoteTech_SoundingRockets_Probes.cfg
├── RemoteTech_Squad_Antennas.cfg
├── RemoteTech_Squad_Probes.cfg
├── RemoteTech_Tech_Node.cfg
└── Textures

3 directories, 19 files

 

The RemoteTech assembly (*.dll) must be located in "/Plugins" folder.

[TaxiService]

9 hours ago, WildLynx said:

[KSP 1.2.2][RT 1.8.3]

Strange behavior:

Controlling core is autonomous core and also there is also 2 crewed and 1 empty crew cabins on the vessel, all looking at some direction.

Vessel have a node planned and RT is set to "Hold node" and execute node in future.

Sent Kerbonaut to EVA - from habitation module , not from any crew cabins.

What happened: Immediately after Kerbonaut left vessel, vessel started to rotate to prograde and stopped here. After returning from EVA vessel immediately returned to Node.

Thanks for the report on this behaviour, which I can reproduce in KSP 1.2.2 with latest RT develop branch. However, this behaviour (relevant codes) is intended in this way because a vessel uses the patched conic solver (trajectories) to get the node information. When your kerbal goes EVA, the active vessel flag moves to this kerbal from the vessel. Therefore, the previous vessel loses the patched conic solver and falls back to the prograde target until the vessel becomes active again.

It doesn't seem to be possible to get the patched conic info outside the active vessel.

7 hours ago, Sumu said:

Hey All, wondering if anyone can help me, I'm trying to play with remote tech but I can't seem to get it to start. Whenever I play none of the features are enabled. If I review my "KSP.log" File I have the following error.

I went as far as completely uninstalling and reinstalling the game with ONLY remote tech loaded and same issue.

I'm using the version from the first post in this thread and I'm running this via Steam, I'm "installing" by placing the files into the gamedata folder, is that correct?. Any tips on what I might be doing wrong or how to correct the error would be greatly appreciated.

This is the error:
<deleted>

Thanks!

Yes, I believe you installed the mod incorrectly. Your whole RemoteTech folder (contained Parts, Plugins, Textures etc) and ModuleManager.xxxxx should be inside the GameData.

By the way, you are using the old RemoteTech version, 1.7.2, which is for KSP 1.1.3. Our latest version is 1.8.3 for KSP 1.2.2 at this moment. The latest release page in the first post will be automatically updated when we push a next release of RemoteTech for minor fix.

Edit: Oops. Neitsa posted his at same time

Edited January 7, 2017 by TaxiService

[Guest]

3 minutes ago, TaxiService said:

Thanks for the report on this behaviour, which I can reproduce in KSP 1.2.2 with latest RT develop branch. However, this behaviour (relevant codes) is intended in this way because a vessel uses the patched conic solver (trajectories) to get the node information. When your kerbal goes EVA, the active vessel flag moves to this kerbal from the vessel. Therefore, the previous vessel loses the patched conic solver and falls back to the prograde target until the vessel becomes active again.

It doesn't seem to be possible to get the patched conic info outside the active vessel.

I was suspecting something like this. May be fallback action should be this: while solver is available, last good angular coordinates are saved on every tick. When solver is deleted, the onscreen warning is issued and RT reverts to those last good coordinates, without resorting to uncommanded  switch to Kill mode? Reverting back to solver is performed when solver is available. RT already have fallback mechanism, may be it can just use backup variable instead of pre-set constant?

I have zero knowledge in C-dull, so I might be missing a hidden hurdle...

 

[CarnageINC]

I was having Remote Tech problems, found out that the GitHub link on the first post for the downloads of the latest version is actually wrong.  Its linked to 1.7.2 version instead of the 1.8.3.

SpaceDock link works correctly.

[neitsa]

On 1/8/2017 at 3:45 AM, CarnageINC said:

I was having Remote Tech problems, found out that the GitHub link on the first post for the downloads of the latest version is actually wrong.  Its linked to 1.7.2 version instead of the 1.8.3.

SpaceDock link works correctly.

We have 2 rolling releases that are developed in parallel:

• One that targets KSP 1.1.3, which is RT 1.7.2
• One that targets the lastest KSP version (KSP 1.2.2 as I'm writing this) which is RT 1.8.3 as of now

The RT branch for KSP 1.1.x is meant as a support branch for people that haven't migrated yet to the latest KSP, mostly because their mods aren't updated.

Sadly, GitHub doesn't allow for multiple "latest release", so the latest published release is the one tagged as such: we can't do anything about that...

It's just a matter of checking carefully which KSP version is targeted by the RT release (it's written at the top of the release notes) if you go through Github though. It might be confusing but yeah, really nothing we can do...

Edited January 9, 2017 by neitsa

[Sumu]

On 1/8/2017 at 1:57 AM, neitsa said:

 

@Sumu : Try RemoteTech 1.7.2 (it seems you are still on 1.7.0 although it shouldn't have given this problem whatsoever) if you are still on KSP 1.1.3. I can't get what's wrong though if you have only KSP + RT... That sounds

strange...

From the root folder of your KSP install, it should look like this:

  Reveal hidden contents

Neitsa@Falcon /KSP/KSP_113
$ tree ./GameData/RemoteTech/ -L 1
./GameData/RemoteTech/
├── Default_Settings.cfg
├── Parts
├── Plugins
├── RemoteTech.version
├── RemoteTech_AIES_Antennas.cfg
├── RemoteTech_AIES_Probes.cfg
├── RemoteTech_Antennas.cfg
├── RemoteTech_B9_Probes.cfg
├── RemoteTech_CactEye_Probes.cfg
├── RemoteTech_FASA_Antennas.cfg
├── RemoteTech_FASA_Probes.cfg
├── RemoteTech_LLL_Antennas.cfg
├── RemoteTech_LLL_Probes.cfg
├── RemoteTech_MechJeb.cfg
├── RemoteTech_NearFuture_Probes.cfg
├── RemoteTech_NovaPunch_Antennas.cfg
├── RemoteTech_NovaPunch_Probes.cfg
├── RemoteTech_SoundingRockets_Probes.cfg
├── RemoteTech_Squad_Antennas.cfg
├── RemoteTech_Squad_Probes.cfg
├── RemoteTech_Tech_Node.cfg
└── Textures

3 directories, 19 files

 

The RemoteTech assembly (*.dll) must be located in "/Plugins" folder.

Thanks Neitsa that was the problem. All fixed up now. Only problem I have now is my network I had previously set up is no longer functional in RT. My antennas don't have the right range! ah well the fun begins again

[TaxiService]

RemoteTech 1.8.4 for KSP 1.2.2 released

This release 1.8.4 is minor, containing two bug fixes.

What are fixed:
The retracted/extended state of an antenna in VAB/SPH works properly
The flight computer now aims to a target-designated celestial body

Complete changelog is below:

Spoiler

What's New?
==========

* Fix conflict for the extend / retract state of an antenna in editor. [#698]
* Fix for flight computer keeps pointing to the orbital prograde when targeting a celestial body. [#710]

Detailed Changelog
==========

Fixed Issues
--------------

* Issue #698: Conflict of the extend/retract state of an antenna in editor. [requested by: sviat9440] [dev: YamoriYuki]
* Issue #710: Flight Computer on a target-designated celestial body. [requested by: TaxiService ] [dev: TaxiService ]

Pull Requests
--------------

* PR #679: Config for Ven's Stock Part Revamp Antennas [issuer: icedown]
              Status: closed due to duplicate #662.

Future
--------------

We are already moving to make the next RT major release.

Issues and feedbacks are still welcome!

If you find any bug, please report them on our github (as it is hard to keep track of bugs here). Feedback is also welcome for the next release, here or on this github post.

We are continuing the 2.x development. We, however, will fix any nasty issue found in RT 1.x branch.

(P.S. Our Github's latest release page should show the RT 1.8.4 (KSP 1.2.2) instead of the RT 1.7.2 (KSP 1.1.3) now)

Edited January 9, 2017 by TaxiService

[ctbram]

Bugs: No EC reported in VAB for antenna's.  No antennas listed in ampyear parts list with RT installed.  See my post and logs and an screenshot showing the problem at this link in the ampyear thread - 

 

[doktorstick]

Howdy.

Is there are trick to prevent the flight computer from chasing a maneuver node? This happens as much as it doesn't, so much so that I cannot rely on the flight computer. What happens is that as delta-V approaches 0 m/s for the maneuver burn, but cannot get into the magic cutoff range (for whatever reason) and delta-V starts increasing, the flight computer will happily chase it spinning your ship, causing mayhem to your attitudes, and burn all the fuel in the stage.

I'm running RT 1.8.4. If this is a bug and not a failure on my part, I'll open an issue in the repo.

[Nathair]

3 minutes ago, doktorstick said:

What happens is that as delta-V approaches 0 m/s for the maneuver burn, but cannot get into the magic cutoff range (for whatever reason) and delta-V starts increasing, the flight computer will happily chase it spinning your ship, causing mayhem to your attitudes, and burn all the fuel in the stage.

 

Try cutting your TWR. Drag your engine thrust limiter down and see if a longer, lighter burn makes it easier to hit the cut-off mark properly.

[cyberpunkdreams]

2 hours ago, Nathair said:

Try cutting your TWR. Drag your engine thrust limiter down and see if a longer, lighter burn makes it easier to hit the cut-off mark properly.

This is also my trick to deal with this problem, but it would be nice if it could be addressed.

[doktorstick]

OK, I'll give it a try. It still reads as a finicky solution. Right now I'm playing in custom harder mode and have resorted to save scumming and then turning on the cheat of allowing me to control probes out of comms and disabling it again once past the problem.

A very naive solution would be to turn off thrusters if the maneuver "needed" delta-V increases, even if it was a configuration option.

Edited January 16, 2017 by doktorstick

[Ginlucks]

Hi all,  I would report some problems:

1- sometimes flight computer execute a wrong manouvre,  it starts to alternate prograde and retrograde directions or executes a burn in prograde direction for a longer time than I setted up.  

2- when I set a burn it happens that the  timer for starting that is not more sync with time of the game,  so  it starts to burn later than I planned

3- question: is it possible to queue a second node? 

Edited January 17, 2017 by Ginlucks

[Garlik]

Hi guys,

Haven't tested RT since some time, is the old 'bug' of RT flight computer not being able to hold prograde/retrograde/... correctly finally solved? Last time I was using RT I remember it beeing almost impossible for me to control a probe because of that. Love RT though and would love to come back to it