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

[Callmedave]

Thanks for the update! 

I would like to make  suggestion. When you add a maneuver and program it in to the flight computer, this adds an alert in to KAC which is brilliant, but the alarm in not linked to the ship, i.e. the alert comes up and i only have the 'close alarm details' option, whearas if i manually add the alarm i can 'jump to ship' (hope that makes sense!)

If this could be added, that would be lovely!

 

[Kondensator]

14 hours ago, symmeclept said:

Kerbalism disables its own signal mechanic so RT can do its thing. How much more do you want?

In my opinion RT works better ( better UI and overall visualisation ) but I would love to see blackouts of singnals etc.

[WarrenSchultz]

So, I was on a hiatus from KSP for a while, but followed along on updates to mods periodically.

I know on previous versions, there was an issue with transmitting science from the MPL, but I thought that was resolved.

Edit: The antenna reports that it is uploading data after the transmission is reported complete, and the MPL reports that it is already transmitting data if I try to send again.

Before I enter in a bug report, I just wanted to make sure this wasn't a PEBKAC error/known limitation/etc.

This is what the output log is giving me:

ArgumentException: '' is not a valid CelestialBody.
  at ContractConfigurator.ConfigNodeUtil.ParseCelestialBodyValue (System.String celestialName) [0x00000] in <filename unknown>:0
  at ContractConfigurator.Util.Science.GetCelestialBody (.ScienceSubject subject) [0x00000] in <filename unknown>:0
  at Strategia.ScienceBooster.OnScienceReceived (Single amount, .ScienceSubject subject, .ProtoVessel vessel, Boolean reverseEngineered) [0x00000] in <filename unknown>:0
  at EventData`4[System.Single,ScienceSubject,ProtoVessel,System.Boolean].Fire (Single data0, .ScienceSubject data1, .ProtoVessel data2, Boolean data3) [0x00000] in <filename unknown>:0
  at ResearchAndDevelopment.SubmitScienceData (Single dataAmount, .ScienceSubject subject, Single xmitScalar, .ProtoVessel source, Boolean reverseEngineered) [0x00000] in <filename unknown>:0
  at RnDCommsStream.submitStreamData (.ProtoVessel source) [0x00000] in <filename unknown>:0
  at RnDCommsStream.StreamData (Single dataAmount, .ProtoVessel source) [0x00000] in <filename unknown>:0
  at RemoteTech.Modules.ModuleRTDataTransmitter+<Transmit>c__Iterator0.MoveNext () [0x00000] in <filename unknown>:0 

KSP log:

[WRN 10:39:26.441] Updating
[LOG 10:39:26.444] RemoteTech: [Transmitter]: Uploading Data... (Research results) - 6.67 Mits/sec. Packets to go: 0 - Files to Go: 0
[LOG 10:39:26.447] [Research & Development]: +20 data on . Subject value is NaN
[EXC 10:39:26.450] ArgumentException: '' is not a valid CelestialBody.
	ContractConfigurator.ConfigNodeUtil.ParseCelestialBodyValue (System.String celestialName)
	ContractConfigurator.Util.Science.GetCelestialBody (.ScienceSubject subject)
	Strategia.ScienceBooster.OnScienceReceived (Single amount, .ScienceSubject subject, .ProtoVessel vessel, Boolean reverseEngineered)
	EventData`4[System.Single,ScienceSubject,ProtoVessel,System.Boolean].Fire (Single data0, .ScienceSubject data1, .ProtoVessel data2, Boolean data3)
	ResearchAndDevelopment.SubmitScienceData (Single dataAmount, .ScienceSubject subject, Single xmitScalar, .ProtoVessel source, Boolean reverseEngineered)
	RnDCommsStream.submitStreamData (.ProtoVessel source)
	RnDCommsStream.StreamData (Single dataAmount, .ProtoVessel source)
	RemoteTech.Modules.ModuleRTDataTransmitter+<Transmit>c__Iterator0.MoveNext ()
[WRN 10:39:26.503] Updating

 This *could* be a Strategia bug, as I started collecting science in Kerbin orbit, then moved it to Minmus, and the mix of celestial bodies might be causing that exception in Strategia and breaking RT also... but my coding skills are way too rusty to sort through the code and figure that out.

					EXPERIMENT_DATA
					{
						experiment = temperatureScan@KerbinInSpaceLow
						experiment = magScan@KerbinInSpaceLow
						experiment = mysteryGoo@KerbinInSpaceLow
						experiment = mobileMaterialsLab@KerbinInSpaceLow
						experiment = scopeScan@KerbinInSpaceLowGrasslands
						experiment = rpwsScan@KerbinInSpaceLow
						experiment = scopeScan@KerbinInSpaceLowHighlands
						experiment = barometerScan@KerbinInSpaceLow
						experiment = crewReport@MinmusInSpaceHigh
						experiment = evaReport@MinmusInSpaceHigh
						experiment = temperatureScan@MinmusInSpaceHigh
						experiment = barometerScan@MinmusInSpaceHigh
						experiment = mysteryGoo@MinmusInSpaceHigh
						experiment = mobileMaterialsLab@MinmusInSpaceHigh
						experiment = crewReport@MinmusInSpaceLow
						experiment = mysteryGoo@MinmusInSpaceLow
						experiment = mobileMaterialsLab@MinmusInSpaceLow
						experiment = magScan@MinmusInSpaceLow
						experiment = scopeScan@MinmusInSpaceLowSlopes
						experiment = scopeScan@MinmusInSpaceLowLowlands
						experiment = rpwsScan@MinmusInSpaceLow
						experiment = scopeScan@MinmusInSpaceLowLesserFlats
						experiment = barometerScan@MinmusInSpaceLow
						experiment = temperatureScan@MinmusInSpaceLow
					}

Thoughts? Bug report for RT or Strategia, or just a plain old end-user error?

Edit 2: Removing Strategia has no effect. I disabled RemoteTech, and renamed the RemoteTech_Squad_Antennas.cfg to .bak, and I was able to transmit science correctly from the MPL. Thoughts?

Thanks!

Edited May 10, 2016 by WarrenSchultz

[Sarai]

I'm trying to send a comm satellite to the Mun, but it loses connection as soon as it gets out of omni range. I have four commsats around Kerbin, with every dish on them set to target active vessel:

Spoiler

I also have a dish on my satellite, set to target Kerbin:

Spoiler

Do the commsats in orbit around Kerbin have to be oriented towards the Mun satellite? Could it be because the dish on the Mun satellite has such a narrow cone (.1 I believe) that it doesn't "see" any of the other commsats? I'm completely lost here.

Edited May 10, 2016 by Sarai

[dlrk]

What does it mean when the flight computer stops responding, and says "status:slave"?

[symmeclept]

10 hours ago, Kondensator said:

In my opinion RT works better ( better UI and overall visualisation ) but I would love to see blackouts of singnals etc.

Yeah, that would be cool.

[dannway]

3 hours ago, Sarai said:

I'm trying to send a comm satellite to the Mun, but it loses connection as soon as it gets out of omni range. I have four commsats around Kerbin, with every dish on them set to target active vessel:

  Hide contents

I also have a dish on my satellite, set to target Kerbin:

  Hide contents

Do the commsats in orbit around Kerbin have to be oriented towards the Mun satellite? Could it be because the dish on the Mun satellite has such a narrow cone (.1 I believe) that it doesn't "see" any of the other commsats? I'm completely lost here.

1. Comsat around Kerbin should have at least 2 dish, 1 pointing at mission control, and the other pointing at active vessel.

2. I think you're a little bit overkill with the Dish . You should avoid using CommTech-1 in cone mode the satellites pass the orbit of Dres. Try using Comms DTS-M1 for Kerbin-Mun/Minmus Connection

[Zhetaan]

@Sarai, to expand on what dannway said, the CommTech-1 (which you're using on your probe) is too long-range to be used so close to Kerbin.  Your supposition was correct:  the cone diameter is just .006 degrees; at the limit of Omni range, that is still such a narrow cone that it may as well be a line.  That line points directly to Kerbin's centre and will only connect with your orbital sats or Mission Control for the approximately tenth-second that they pass directly through the beam--if they do at all.  In fact, the cone is so narrow that it won't spread to cover Kerbin until you're eleven billion metres away--which is the distance to about halfway between the Sun and Moho.

Since I see Communotrons on your orbital sats, you don't need to point a dish at Mission Control, provided that they are in a standard equatorial relay network.  The only thing I can say about them is that they really are overkill on the long-range stuff, and you certainly do not need to point more than one, if any, of those dishes to 'active vessel'.  If you intend to use them as one-size-for-all comm relays, then I can add that you also lack any good mid-range coverage; you have Kerbin orbit covered, and you have Jool covered, but aside from the one KR-14 that can reach the inner planets, you have nothing that is really good for the space between the Mun and Dres.

You can save the probe by pointing its dish directly at one of your Kerbin comsats. but you'll have to keep switching the target as each sat passes behind Kerbin.  Your best chance is to do what dannway says and use a short-range dish with a wide cone.  The Comms DTS-M1 has a cone angle of 45 degrees and will reach to the far side of Minmus's sphere of influence (but not very much further, so don't go for solar science without something more potent).  The KR-7 has an angle of 25 degrees, will cover anything in Kerbin's sphere of influence, and will preserve the current aesthetic of your probe.

Also, no, the comsats do not need to be oriented towards the Mun or your probe; they simply need a clear line of sight.  That means that every time either the probe or the comsats pass behind something (as the Mun or Kerbin), they will lose the link.  This also means that if your capture burn is on the far side of the Mun where you will have no link, you will need to program the burn into the flight computer and hope that you have enough power to run the probe core when you get there:  dead probe cores light no engines.  Since you mention being totally lost, I'll throw in a free hint:  make sure your orientation will feed your solar panels before you lose your link.  Even two Gigantors will not be enough if their axes point through the sun.  I always design my probes so the solar panels extend at right angles to one another; that way, one of them can always rotate to face the sun.

Edited May 11, 2016 by Zhetaan

[speedwaystar]

15 hours ago, Kondensator said:

In my opinion RT works better ( better UI and overall visualisation ) but I would love to see blackouts of singnals etc.

it's up to ShotgunNinja to tell RemoteTech to disable communication for the duration of his blackout. it's not RemoteTech's job, nor is it possible since RT has no way of telling when another mod has decided that a coronal ejection is occurring unless that mod tells it. Luckily, RemoteTech provides a software API for other mods to easily do this.

for instance, Kerbalism (or any other mod) could set RemoteTech.API.HasAnyConnection for the vessel to false, and RemoteTech would dutifully disable the vessel's communication channel; then set it to true again after the blackout has run its course.

Edited May 11, 2016 by speedwaystar

[slate6715]

First off, one of my favorite mods!  So glad the project has fresh energy.

Also, it looks like TechRequired was removed from the part.cfg files.  Subsequently, the parts are not in the tech tree and can't be acquired.  When I manually insert the TechRequired line, it reappears in the tree.  Was removing that line deliberate?  

[Sarai]

17 hours ago, Zhetaan said:

@Sarai, to expand on what dannway said, the CommTech-1 (which you're using on your probe) is too long-range to be used so close to Kerbin.  Your supposition was correct:  the cone diameter is just .006 degrees; at the limit of Omni range, that is still such a narrow cone that it may as well be a line.  That line points directly to Kerbin's centre and will only connect with your orbital sats or Mission Control for the approximately tenth-second that they pass directly through the beam--if they do at all.  In fact, the cone is so narrow that it won't spread to cover Kerbin until you're eleven billion metres away--which is the distance to about halfway between the Sun and Moho.

Since I see Communotrons on your orbital sats, you don't need to point a dish at Mission Control, provided that they are in a standard equatorial relay network.  The only thing I can say about them is that they really are overkill on the long-range stuff, and you certainly do not need to point more than one, if any, of those dishes to 'active vessel'.  If you intend to use them as one-size-for-all comm relays, then I can add that you also lack any good mid-range coverage; you have Kerbin orbit covered, and you have Jool covered, but aside from the one KR-14 that can reach the inner planets, you have nothing that is really good for the space between the Mun and Dres.

You can save the probe by pointing its dish directly at one of your Kerbin comsats. but you'll have to keep switching the target as each sat passes behind Kerbin.  Your best chance is to do what dannway says and use a short-range dish with a wide cone.  The Comms DTS-M1 has a cone angle of 45 degrees and will reach to the far side of Minmus's sphere of influence (but not very much further, so don't go for solar science without something more potent).  The KR-7 has an angle of 25 degrees, will cover anything in Kerbin's sphere of influence, and will preserve the current aesthetic of your probe.

Also, no, the comsats do not need to be oriented towards the Mun or your probe; they simply need a clear line of sight.  That means that every time either the probe or the comsats pass behind something (as the Mun or Kerbin), they will lose the link.  This also means that if your capture burn is on the far side of the Mun where you will have no link, you will need to program the burn into the flight computer and hope that you have enough power to run the probe core when you get there:  dead probe cores light no engines.  Since you mention being totally lost, I'll throw in a free hint:  make sure your orientation will feed your solar panels before you lose your link.  Even two Gigantors will not be enough if their axes point through the sun.  I always design my probes so the solar panels extend at right angles to one another; that way, one of them can always rotate to face the sun.

Ok. Just to clarify though, do the commsats in Kerbin orbit need to physically point at the target satellite? Also that Mun probe has plenty of battery life, I've been using that design since before I started using RemoteTech, it has battery to last the dark side of anything but a gas giant. I intended it to be a one-size-fits-all design, but I guess such a powerful dish is a little more than overkill for Kerbin's SOI. Thanks!

EDIT: I wasn't able to save the existing probe, but a new one of exactly the same design was launched and worked out just fine using the two Communotron DTS-M1's that were originally the only antennas on the craft. I just slapped on the Communotron 32's and the CommTech 1 after installing RemoteTech.

Edited May 11, 2016 by Sarai

[Beechnutk Jr.]

A recommendation-

One if my com. satellites has big antennas that are turned on. I did not think I needed very many solar panels, so I did not put enough to sustain the five big dishes. I turned them all on, so I can not control the satellite because I do not have enough power. Maybe have the dishes turn off once the power runs out, then not turn back on unless you change the settings in the RT menu. 

Edited May 11, 2016 by Beechnutk Jr.

[Kerbart]

11 minutes ago, Beechnutk Jr. said:

A recommendation-

One if my com. satellites has big antennas that are turned on. I did not think I needed very many solar panels, so I did not put enough to sustain the five big dishes. I turned them all on, so I can not control the satellite because I do not have enough panels. Maybe have the dishes turn off once the power runs out, then not turn back on unless you change the settings in the RT menu. 

But once they're powered off you can no longer control your satellite when the power comes back on (at least in the harder setting you cannot remotely control an antenna if there is no remote connection). So to make that scenario more playable (anytime you hit the nighttime side of a satellite longer than your batteries provide for you lose control) you'd also need to be able to define an emergency mode on the craft where the antennas tagged as emergency will then go back online.

(“And what if I tagged all my antennas as emergency so I run out of power again?” “Well, don't do that!!”)

[Zhetaan]

46 minutes ago, Sarai said:

Ok. Just to clarify though, do the commsats in Kerbin orbit need to physically point at the target satellite?

They do not.  Nothing needs to physically point towards anything else; the only requirement is that no planet or moon be in the way of the signal line.

By the bye, if you have two dish antennas on a probe, then you can set one to look at a specific comsat in Kerbin orbit, and set the second to look at the comsat in orbit directly opposite that one.  Then you'll never lose your signal so long as you can see Kerbin.  That's not a problem with the DTS's wide cone but when you send interplanetary probes you can make use of it when they're still too close for their beams to cover all of low Kerbin orbit.

[Beechnutk Jr.]

1 hour ago, Kerbart said:

So to make that scenario more playable (anytime you hit the nighttime side of a satellite longer than your batteries provide for you lose control) you'd also need to be able to define an emergency mode on the craft where the antennas tagged as emergency will then go back online.

Ok, so do that. Or have new probe cores that are higher up on the tech tree that are able to tell when there is enough power to deploy/retract antennas without player input or something. Like I said, just a suggestion.

[N_Molson]

Quote

That's not a problem with the DTS's wide cone but when you send interplanetary probes you can make use of it when they're still too close for their beams to cover all of low Kerbin orbit.

Actually, the very long range antennas have an extremely thin (focused) beam, so in the extreme cases you might need a secondary "medium-long range" antenna to perform MCCs.

In any case, it is critical to have your antennas all set BEFORE you perform the transplanetary injection. If you forget to do it, once you're too far for the "short range antennas" like the Omni-25, the probe is lost.

Edited May 11, 2016 by N_Molson

[Tfin]

8 minutes ago, N_Molson said:

Actually, the very long range antennas have an extremely thin (focused) beam, so in the extreme cases you might need a secondary "medium-long range" antenna to perform MCCs.

In any case, it is critical to have your antennas all set BEFORE you perform the transplanetary injection. If you forget to do it, once you're too far for the "short range antennas" like the Omni-25, the probe is lost.

This, with the preceding several posts, approaches the realm of requiring a probe programming mod. I like RT, but this is getting to where it's too involved for me.

[Galenmacil]

Thanks for taking over the project. I have a few suggestions to improve the "user experience" with RT:

1 - Make RT remember it's in-flight "computer" interface window position from session to session.

2 - Add a keyboard shortcut to toggle the "computer" interface.

3 - I never figured out a way to do this: Say you have 3 maneuvers node setup. The active probe is going to enter "antenna range" for a short period. It would be great to be able to queue all 3 maneuvers easily...

[Kerbart]

4 hours ago, WildLynx said:

- Add RT manual to in-game manual, like SCANSat did. This mod is complicated, and online manual is incomplete and outdated. [A lot of work]

While I know a thing or two about coding I don't know a lot about C# and wouldn't dare to suggest my services there. However, if you want I can take a stab at the manual, if that needs to be updated or rewritten.

[Sandworm]

I've been playing around with RemoteTech for a few days now and am butting my head against a problem.  The flight computer simply won't hold orientation.  It looks like it throws the craft in the general direction that it should, but is unable to hole the direction once there.  Sometimes it will hold for a few seconds, but most of the time it just wont' engage. 

 

Does this mean anything?  It sounds familiar, like a problem I ran into with remotetech over a year ago, but I am not sure.

[LOG 18:43:14.506] RemoteTech: Loading Flightcomputer from persistent!
[WRN 18:43:14.543] [Part]: PartModule ModuleRTDataTransmitter at longAntenna, index 6: index exceeds module count as defined in cfg.

Edited May 13, 2016 by Sandworm

[Garlik]

Hi all,

First of, thanks for the current dev(s) and previous one(s) for developting this great mod. Absolute NEED for me (unlike future kind of RT feature that KSP will have).

Next. I've never been able to solve this problem (without 'cheating' my way out of the problem)

The problem: Send a manned mission to drop an unmanned lander with RT with only 1 antenna that needs to be desactivated during re-entry (ie: to land on Eve)

I must temporarly deactivate my antenna (ie: Communotron 88-88) so it does not break and would like to use the flight computer to re-activate it say 5-10minutes later. But I can only ask the computer to add the "Open antenna in 10min" when the antenna is closed, and... if it is closed... I cant ask the computer to add this command...

Is their a known solution for this? Exept adding a second antenna that is turned on while the first is off so I still have signal to tell the first to reopen 10min later

 

If not, I understant the dev(s) can't add more options now, and gladly offer my small help. I have basic knowledge in C#, Monobehavior and Unity 5. If you show me the way, I could try to dev this (if I end up beeing able to)

[FancyMouse]

Seems at least there are active devs around - shall we talk about some small design changes? I have the design change proposal along with the code below, but before that I'd just like to hear if the design change makes sense at the first place.

Basically my complaint is that command stations can't even control itself, which results in a weird situation that any vessel nearby gets instant signal but the command station itself has a delay like hell. It doesn't make sense, at least to me, that a command station can control anything but itself. Command station should have local control of itself.

Code change is simple - VesselExtension.cs just needs this change and it at least worked for me back in 1.0.5 (haven't yet tried in 1.1.* but I don't see why it shouldn't). Forget about the private function name - I suck at coming up with a name. Also, I don't know how efficient is the FindModulesImplementing call, but we probably don't need to worry about perf improvement at this point, and it's not relevant to my design change proposal anyway.

    public static class VesselExtension
    {
        private static bool HasNonSignalProcessor(System.Collections.Generic.List<ISignalProcessor> list)
        {
            return !list.Any() || list.First().IsCommandStation;
        }
        public static bool HasLocalControl(this Vessel vessel)
        {
            return vessel.parts.Any(p => p.isControlSource && (p.protoModuleCrew.Any() || HasNonSignalProcessor(p.FindModulesImplementing<ISignalProcessor>())));
        }
    }

 

[Rodger]

On 13/05/2016 at 0:07 PM, Sandworm said:

I've been playing around with RemoteTech for a few days now and am butting my head against a problem.  The flight computer simply won't hold orientation.  It looks like it throws the craft in the general direction that it should, but is unable to hole the direction once there.  Sometimes it will hold for a few seconds, but most of the time it just wont' engage.

If you have MJ, double check you don't have MJ's autopilot also trying to hold orientation.

[Gryphon]

10 hours ago, Garlik said:

Is their a known solution for this? Exept adding a second antenna that is turned on while the first is off so I still have signal to tell the first to reopen 10min later

Well, one simple thing you can do is have a backup antenna that also is also capable of providing a backlink. With your backup antenna open, you can shut down your primary antenna and create the Flight Computer command to open the primary antenna at the appropriate time.

[Andem]

10 hours ago, Garlik said:

Hi all,

First of, thanks for the current dev(s) and previous one(s) for developting this great mod. Absolute NEED for me (unlike future kind of RT feature that KSP will have).

Next. I've never been able to solve this problem (without 'cheating' my way out of the problem)

The problem: Send a manned mission to drop an unmanned lander with RT with only 1 antenna that needs to be desactivated during re-entry (ie: to land on Eve)

I must temporarly deactivate my antenna (ie: Communotron 88-88) so it does not break and would like to use the flight computer to re-activate it say 5-10minutes later. But I can only ask the computer to add the "Open antenna in 10min" when the antenna is closed, and... if it is closed... I cant ask the computer to add this command...

Is their a known solution for this? Exept adding a second antenna that is turned on while the first is off so I still have signal to tell the first to reopen 10min later

 

If not, I understant the dev(s) can't add more options now, and gladly offer my small help. I have basic knowledge in C#, Monobehavior and Unity 5. If you show me the way, I could try to dev this (if I end up beeing able to)

Well, you can use another plugin called kOS that adds in programmable scripts into the game, or you could alter the startup settings so you don't need a connection to open antennae.