Now-defunct-thread-that-should-not-appear-in-google-search.

[DerekL1963]

I believe the theory behind this is that it places the limitation on the hardware rather than the media. That is, while the mechanics behind antennae transmission/reception can be measured by the quality and design, placing a limitation on the range does not mean the signal stops at this point. The radio waves (or whatever medium is being used) continue to travel after they have reached the limits of the operating range. They will suffer from signal degradation as they travel away from the origin, but the signal doesn't simply vanish. This presents a more realistic scenario when dealing with transmission distances rather than basing it on an imposed distance range.

TL;DR A stronger antenna can do more with less. It can provide a "cleaner" signal to a lesser antenna; It can "hear" a weaker signal farther than it was originally rated to travel.

Thank you! Is this mode permanently active or does it have to be selected/set in the config.

Wait --is that right? I was(am?) sure that the devices doing the transmitting/receiving would need to be within 500k of each other (or whatever the shortest range is). Otherwise, for instance, the built in 3k probe antenna would never lose connection with KSP (as long as line of sight was maintained) since the operating range of Mission Control extends far beyond that.

The Mission Control antenna and the built in probe antenna are both omni's - they use different range determination rules.

[asmi]

I had that ghosting issue the first or second time I used RemoteTech and it went away on its own. Now I just have CTD with another problem making Remote completely unusable.

After reloading KSP it had all vessels duplicated, I had to manually edit save file to get rid of them.

[JIMEDIAH]

log file for space port crash: https://dl.dropboxusercontent.com/u/40108353/output_log.txt

[BigD145]

After reloading KSP it had all vessels duplicated, I had to manually edit save file to get rid of them.

I got that problem as well and it stopped doing it after a bit i.e. a couple restarts.

Edited December 28, 2013 by BigD145

[Beetlecat]

The Mission Control antenna and the built in probe antenna are both omni's - they use different range determination rules.

Aha! Cheers for that. I hadn't realized they behaved differently aside from simply longer range and narrower field of "vision."

[louiz347]

You have to take the cone angles into account. The 88-88 has a cone angle of only 0.06 deg. When being at the distance of Mun and pointing on Kerbin it is highly unlikely that a satellite is within this cone. For such small distances the KR-7 is absolutely sufficient in terms of range and has a cone of 25 deg which means for short distances the area which the dishes cone is covering is sufficiently large.

EDIT: Of course you also have to make sure some dish within the cone is pointing back to your probe.

Thanks, that makes total sense.

[Cilph]

Just got weird behaviour: http://i.imgur.com/YZ8dg2P.png

After I've checked the log, it's filled with this:

full log file is here.

It seems there is an issue that causes a satellite and its associated data to not be properly cleaned, most likely caused by a much earlier exception which could've been caused by any other plugin. I'll do a thorough check though. Do you have something that accurately reproduces the situation? Like a persistence file that spams the error consistently.

I can make a workaround that acts whenever the issue pops up, but I'd rather find the root cause.

Edited December 28, 2013 by Cilph

[NovaSilisko]

I want to put forward that after installing RemoteTech I don't think I can ever go back to a version of KSP that lacks it... it just adds so much substance to the game, and succulent complexity - requiring planning, forethought, proper execution. Missions have meanings and restraints now. I have stepped out of the darkness and into the light. This is a new age!

[Cilph]

I want to put forward that after installing RemoteTech I don't think I can ever go back to a version of KSP that lacks it... it just adds so much substance to the game, and succulent complexity - requiring planning, forethought, proper execution. Missions have meanings and restraints now. I have stepped out of the darkness and into the light. This is a new age!

Likewise, your release thread of Alternis Kerbol has impressed me greatly.

EDIT: Planned updates

• Fix all bugs reported, where possible. Please send persistence/logs/screenshot without having me ask for it. It puts me 'out of the zone'.
  
• Dish multi-targeting. This will break compatibility.
  
• Better debug features that allow you to manually override/set that can be used by regular joe for fixing compatibility problems.
  
• Optional setting to allow dish reconfiguration in the tracking station even when out of contact. (Punishment by inconvenience instead of sending out a recovery mission or coding in a failsafe)
  
• EVA Radio (okay, there, you win.)
  
• Maybe finally do proper kOS integration if the kOS main dev comes back from absence.
  

EDIT2: Actually, on second thought, no compatibility breaking.

Edited December 28, 2013 by Cilph

[Thobewill10]

Likewise, your release thread of Alternis Kerbol has impressed me greatly.

EDIT: Planned updates

• Fix all bugs reported, where possible. Please send persistence/logs/screenshot without having me ask for it. It puts me 'out of the zone'.
  
• Dish multi-targeting. This will break compatibility.
  
• Better debug features that allow you to manually override/set that can be used by regular joe for fixing compatibility problems.
  
• Optional setting to allow dish reconfiguration in the tracking station even when out of contact. (Punishment by inconvenience instead of sending out a recovery mission or coding in a failsafe)
  
• EVA Radio (okay, there, you win.)
  
• Maybe finally do proper kOS integration if the kOS main dev comes back from absence.
  

EDIT2: Actually, on second thought, no compatibility breaking.

What does dish multitargeting mean, practically? How would that work?

[Cilph]

What does dish multitargeting mean, practically? How would that work?

Dishes will be allowed a set number of targets (3-5), and you can choose a target for each slot. It will then use either the first available target or the shortest-distance target. I have yet to choose.

[FITorion]

Dishes will be allowed a set number of targets (3-5), and you can choose a target for each slot. It will then use either the first available target or the shortest-distance target. I have yet to choose.

Cool. That could work as a bit of a fail safe having a few targets it can cycle through to find a link.

[AndreyATGB]

This would be excellent for instances when my targeted satellite is behind the planet.

In the 1.3.3 change log it says something about easy changing focus via map view, does that mean it's possible to target a sat from a ship and make that sat target it without having to switch vessels? If I got it right, how do I use it, if not what does it mean then?

[Cilph]

This would be excellent for instances when my targeted satellite is behind the planet.

In the 1.3.3 change log it says something about easy changing focus via map view, does that mean it's possible to target a sat from a ship and make that sat target it without having to switch vessels? If I got it right, how do I use it, if not what does it mean then?

Yes. Use the third button on the middle-right of the map view, under the two existing ones. Select the satellite, and open the target menu as normal.

[asmi]

EDIT: Planned updates

If I may suggest a feature, that would be improvements in flight computer, specifically better integration with maneuver nodes. For example it would be great if FC would take burn duration into account when executing a node (right now I've screwed up quite a few orbital insertion burns because of that, and the longer burn is, the bigger the difference between planned vs actually achieved results), also I'd like to be able to set up a series of maneuver nodes and have FC execute them in order even when I'm LOS (for example, parking orbit insertion burn, and then transfer orbit insertion - both of these burns tend to happen outside of MCCs visibility, and that makes certain missions impossible or much-harder-than-it-should-be).

[Cilph]

If I may suggest a feature, that would be improvements in flight computer, specifically better integration with maneuver nodes. For example it would be great if FC would take burn duration into account when executing a node (right now I've screwed up quite a few orbital insertion burns because of that, and the longer burn is, the bigger the difference between planned vs actually achieved results), also I'd like to be able to set up a series of maneuver nodes and have FC execute them in order even when I'm LOS (for example, parking orbit insertion burn, and then transfer orbit insertion - both of these burns tend to happen outside of MCCs visibility, and that makes certain missions impossible or much-harder-than-it-should-be).

Well, you can do the single node burn out of line of sight as well, and I take it you can wait a single rotation to send the command for your transfer burn. Taking burn duration into account was a consideration but it's actually quite complicated to examine the craft's thrust capability in advance.

[krenshala]

Well, you can do the single node burn out of line of sight as well, and I take it you can wait a single rotation to send the command for your transfer burn. Taking burn duration into account was a consideration but it's actually quite complicated to examine the craft's thrust capability in advance.

Would it be possible to give us a field to have the burn start at a certain time before the node? e.g., We know from the node that the burn is 1m36s long, so we tell the FC to start the burn 48s before it reaches the maneuver node. It is slightly more work for the user, but at the same time, it meets the request with minimal programming requirements.

[rottielover]

"EVA Radio (okay, there, you win.)"

-and there was much rejoicing and dancing in the streets!

[match]

I thoroughly enjoy throwing time at this game when I can make a guess at behavior and be able to test it out. Most importantly, I can expect the results to be somewhat in line with my original hypothesis.

So I sat down this afternoon and made a test run with a very simple setup to test accuracy and give some feedback on the Multiple Antenna modifier and the Root Range model. Below are the results if you care to review. My original maths did not account for the DP-10 I had originally intended to discard with the ascent package (oops, over-engineered once again!), nor did it account for a tiny variable that led to much head scratching on my part, but finally resolved.

Multiple Antenna Multiplier and Root Range model

Testing: Omni Range= Max range + (sum of additional ranges * Multiple Antenna Multiplier)
Root Range model: Min + sqrt[Min * Max]

Config alteration: 
RangeMultiplier = 0.5
MultipleAntennaMultiplier = 0.25
RangeModelType = Additive 

The config I originally loaded had "RangeModelType = Root". Apparently it modifies it to "Additive" during the load.

Initial testbed: 

3 Orbital Relays @ 776km, equally spaced
Deployment:
(1) Stayputnik; Operational Range= .0015 Mm
(1) DP-10; Operational Range= .25 Mm
(1) Communitron 32; Operational Range= 2.5 Mm
(3) Communitron 16; Operational Range= 1.25 Mm
(3) CommTech EXP-VR-2T; Operational Range= 1.5 Mm
Power to maintain sustained operation.

1 Orbital Variable @ 11,481 x 762 km 
Identical build as the Relays

All tests are done with DP-10 and Stayputnik active.

Single Comm-16 active on all birds.
Relays maintain connection @ 2.3 - 2.4 Mm (outside of listed range; within expected parameters per Range Model)
(F5)
Begin test:
Submit: Orbital Variable on heading away from Kerbal, increasing distance to closest relay bird as the test progresses. Failure of communication is expected at distinct intervals depending on the activated devices. QuickSave/Reload will be utilized to attempt to record accurate time capture. Three passes will be made and recorded as "Result" (first pass to localize the event at higher warp, subsequent passes at 1:1 time).
Math included so you can check my work 

*****
Orbital Variable: Expected comm failure @ 2.625750 Mm
	Result: 2.6 Mm; 2.62 Mm; 2.625 Mm

MultipleAntenna Multiplier| 1.25 + .25[.25 + .0015] = 1.312875
Range Model| 1.312875 Mm + sqrt[1.312875 Mm * 1.312875 Mm] = 2.625750 Mm

*****
(F9)
Activate (1) additional Comm16 on Relays (Stay + DP + 2x C16)
Orbital Variable: Expected comm failure @ 2.773667 Mm
	Result: 2.7 Mm, 2.77 Mm, 2.773 Mm

1.25 + .25 * [1.25 + .25 + .0015] = 1.625375
1.312875 Mm + sqrt[1.312875 * 1.625375] = 2.773667

*****
(F9)
Activate (1) EXP-VR-2T on Relays (Stay + DP + 2x C16 + EXP)
Orbital Variable: Expected comm failure @ 3.007693 Mm
	Result: 3.0 Mm, 3.00 Mm, 3.009 Mm

1.5 + .25[1.25 + 1.25 + .25 + .0015] = 2.187875
1.312875 + sqrt[1.312875 * 2.187875]

*****
(F9)
Activate (1) EXP-VR-2T and (1) Comm16 on Variable (Stay + DP + 2x C16 + EXP)//(Stay + DP + C16 + EXP)
Orbital Variable: Expected comm failure @ 3.900983 Mm
	Result: 3.9 Mm, 3.90 Mm, 3.902 Mm

Relay: 2.187875
Variable: 1.5 + .25[1.25 + .25 + .0015] = 1.875375
1.875375 + sqrt[1.875375 * 2.187875]

*****
(F9)
Deactivate all but Comm16, DP and Stay on Relay; Activate all on Variable (3x Comm16, 3x EXP-VR-2T, Comm32, DP, Stay)
Orbital Variable: Expected comm failure @ 3.777127 Mm
	Result: 3.7 Mm, 3.77 Mm, 3.777 Mm

2.5 + .25[1.5 * 3 + 1.25 * 3 + .25 + .0015]
1.312875 + sqrt[1.312875 * 4.625375]

*****
(F9)
Activate one of each type on both Relay and Variable.
Orbital Variable: Expected comm failure @ 6.500750 Mm
	Result: 6.5 Mm, 6.51 Mm, 6.501 Mm

2.5 + .25[1.5 + 1.25 + .25 + .0015]
3.250375 + sqrt[3.250375 * 3.250375]

*****
(F9)
Activate all on both Relay and Variable.
Orbital Variable: Expected comm failure @ 9.25075 Mm
	Result: 9.2, ...This is getting silly, this mod is balls-on accurate

2.5 + .25[1.5 * 3 + 1.25 *3 + .25 + .0015]
4.625375 + sqrt[ 4.625375 * 4.625375]

I am simply flabbergasted that everything came out so exact. Actually, my first review of the results did not and left me somewhat puzzled until I realized I had an extra antenna on board (the dipole did a good Jeb impression and sneaked on board while I was getting coffee!). I also did not originally account for the probe core. Once properly accounted for, the maths matched up to the objectives almost precisely. I never doubted that they would... it's just weird to come across something so exact in this world.

I'm no expert in these forums, but I do like what this does for local exploration. This allows so many more choices when developing your communication network without needing an ultimate antenna. The only issue I have is more of a balancing issue on the Root Range model: For long distance communication (interplanetary), it "feels" a bit out of whack by allowing short range antennae to operate so far outside of their capability.

Thanks to Cilph and NathanKell, and all the others that work(ed) on this mod. It provided me something that I normally don't expect to acquire... Satisfaction through Perfection.

[FITorion]

Well in reality... The transmitters we have here on Earth are much more sensitive and can transmit at much greater powers than anything in orbit. Landers often have a low power transmitter to transmit back up to an orbiter and have that relay the info back to Earth... But it's happened several times that the Earth receivers could pick up the landers transmission directly. Even stuff really far out and low powered. Sending info the other way is a different story.

You can get situations where you can hear the spacecraft but the spacecraft can't hear you.

[rottielover]

I thoroughly enjoy throwing time at this game when I can make a guess at behavior and be able to test it out. Most importantly, I can expect the results to be somewhat in line with my original hypothesis.

So I sat down this afternoon and made a test run with a very simple setup to test accuracy and give some feedback on the Multiple Antenna modifier and the Root Range model. Below are the results if you care to review. My original maths did not account for the DP-10 I had originally intended to discard with the ascent package (oops, over-engineered once again!), nor did it account for a tiny variable that led to much head scratching on my part, but finally resolved.

Multiple Antenna Multiplier and Root Range model

Testing: Omni Range= Max range + (sum of additional ranges * Multiple Antenna Multiplier)
Root Range model: Min + sqrt[Min * Max]

Config alteration: 
RangeMultiplier = 0.5
MultipleAntennaMultiplier = 0.25
RangeModelType = Additive 

The config I originally loaded had "RangeModelType = Root". Apparently it modifies it to "Additive" during the load.

Initial testbed: 

3 Orbital Relays @ 776km, equally spaced
Deployment:
(1) Stayputnik; Operational Range= .0015 Mm
(1) DP-10; Operational Range= .25 Mm
(1) Communitron 32; Operational Range= 2.5 Mm
(3) Communitron 16; Operational Range= 1.25 Mm
(3) CommTech EXP-VR-2T; Operational Range= 1.5 Mm
Power to maintain sustained operation.

1 Orbital Variable @ 11,481 x 762 km 
Identical build as the Relays

All tests are done with DP-10 and Stayputnik active.

Single Comm-16 active on all birds.
Relays maintain connection @ 2.3 - 2.4 Mm (outside of listed range; within expected parameters per Range Model)
(F5)
Begin test:
Submit: Orbital Variable on heading away from Kerbal, increasing distance to closest relay bird as the test progresses. Failure of communication is expected at distinct intervals depending on the activated devices. QuickSave/Reload will be utilized to attempt to record accurate time capture. Three passes will be made and recorded as "Result" (first pass to localize the event at higher warp, subsequent passes at 1:1 time).
Math included so you can check my work 

*****
Orbital Variable: Expected comm failure @ 2.625750 Mm
	Result: 2.6 Mm; 2.62 Mm; 2.625 Mm

MultipleAntenna Multiplier| 1.25 + .25[.25 + .0015] = 1.312875
Range Model| 1.312875 Mm + sqrt[1.312875 Mm * 1.312875 Mm] = 2.625750 Mm

*****
(F9)
Activate (1) additional Comm16 on Relays (Stay + DP + 2x C16)
Orbital Variable: Expected comm failure @ 2.773667 Mm
	Result: 2.7 Mm, 2.77 Mm, 2.773 Mm

1.25 + .25 * [1.25 + .25 + .0015] = 1.625375
1.312875 Mm + sqrt[1.312875 * 1.625375] = 2.773667

*****
(F9)
Activate (1) EXP-VR-2T on Relays (Stay + DP + 2x C16 + EXP)
Orbital Variable: Expected comm failure @ 3.007693 Mm
	Result: 3.0 Mm, 3.00 Mm, 3.009 Mm

1.5 + .25[1.25 + 1.25 + .25 + .0015] = 2.187875
1.312875 + sqrt[1.312875 * 2.187875]

*****
(F9)
Activate (1) EXP-VR-2T and (1) Comm16 on Variable (Stay + DP + 2x C16 + EXP)//(Stay + DP + C16 + EXP)
Orbital Variable: Expected comm failure @ 3.900983 Mm
	Result: 3.9 Mm, 3.90 Mm, 3.902 Mm

Relay: 2.187875
Variable: 1.5 + .25[1.25 + .25 + .0015] = 1.875375
1.875375 + sqrt[1.875375 * 2.187875]

*****
(F9)
Deactivate all but Comm16, DP and Stay on Relay; Activate all on Variable (3x Comm16, 3x EXP-VR-2T, Comm32, DP, Stay)
Orbital Variable: Expected comm failure @ 3.777127 Mm
	Result: 3.7 Mm, 3.77 Mm, 3.777 Mm

2.5 + .25[1.5 * 3 + 1.25 * 3 + .25 + .0015]
1.312875 + sqrt[1.312875 * 4.625375]

*****
(F9)
Activate one of each type on both Relay and Variable.
Orbital Variable: Expected comm failure @ 6.500750 Mm
	Result: 6.5 Mm, 6.51 Mm, 6.501 Mm

2.5 + .25[1.5 + 1.25 + .25 + .0015]
3.250375 + sqrt[3.250375 * 3.250375]

*****
(F9)
Activate all on both Relay and Variable.
Orbital Variable: Expected comm failure @ 9.25075 Mm
	Result: 9.2, ...This is getting silly, this mod is balls-on accurate

2.5 + .25[1.5 * 3 + 1.25 *3 + .25 + .0015]
4.625375 + sqrt[ 4.625375 * 4.625375]

I am simply flabbergasted that everything came out so exact. Actually, my first review of the results did not and left me somewhat puzzled until I realized I had an extra antenna on board (the dipole did a good Jeb impression and sneaked on board while I was getting coffee!). I also did not originally account for the probe core. Once properly accounted for, the maths matched up to the objectives almost precisely. I never doubted that they would... it's just weird to come across something so exact in this world.

I'm no expert in these forums, but I do like what this does for local exploration. This allows so many more choices when developing your communication network without needing an ultimate antenna. The only issue I have is more of a balancing issue on the Root Range model: For long distance communication (interplanetary), it "feels" a bit out of whack by allowing short range antennae to operate so far outside of their capability.

Thanks to Cilph and NathanKell, and all the others that work(ed) on this mod. It provided me something that I normally don't expect to acquire... Satisfaction through Perfection.

Nice work!!

[asmi]

Well, you can do the single node burn out of line of sight as well, and I take it you can wait a single rotation to send the command for your transfer burn.

I had cases which made extra orbit ruin the mission As example - consider building station unmanned Russian-style, most of my modules don't have solar arrays, and single revolution means a difference between mission success and one more piece of debris in orbit. Another one is interplanetary probes which don't have powerful antenna themselves as they are supposed to rely on pre-positioned relay sat already in orbit around target planet. This approach can save quite a mass, which is crucial for ion-powered craft (I use ion engines a lot for their efficiency). And that's the way I do things anyways - I'd like to plan trajectory ahead (all course correction burns via multiple nodes) and then watch events unfold to see if I was accurate enough with my planning Currently I use MJ's "Execute all nodes" feature, but I'd like to get rid of having to carry large dish and lots of extra power assets (batteries/solar arrays/radiators to keep them cool).

Taking burn duration into account was a consideration but it's actually quite complicated to examine the craft's thrust capability in advance.

If far as I understand, the biggest problem is staging. Well I'd be ok if FC wouldn't work with burns that require staging. Once staging is out, it's actually pretty simple. You can try using Tsiolkovsky rocket equation for estimating burn time. Advantage of this method is it's exact (and pretty fast too), and not simulation-based like the one MJ uses.

Edited December 29, 2013 by asmi

[NoMrBond]

Perhaps have a reception multiplier as another stat/attribute, so a weaker antenna can transmit further than it can receive, as long as there is a better receiver at the other end to catch the attenuated signal

[Edit] You could even have specialized high-gain "listening" antenna which have no transmission capability (and vice-versa with powerful transmitters)

Edited December 29, 2013 by NoMrBond

[Kimberly]

You could even have specialized high-gain "listening" antenna which have no transmission capability (and vice-versa with powerful transmitters)

I've been checking many real satellites for inspiration for Kerbal designs, and it seems most modern communication satellites actually do have dedicated receiving antennae for signals from earth, often only one or two small ones, while the main array of antennae is for broadcasting.

[Garek]

• Maybe finally do proper kOS integration if the kOS main dev comes back from absence.
  

This is basically what I'm waiting for. I like the concept of remote tech, and used it a little bit in .22, but if I use it, I want to be able to run stuff like a landing program on a probe itself so it's after the signal delay.

Sadly, it doesn't seem like Kevin is coming back soon, and a fork propably needs some more time to get started and working.