[1.1] RemoteTech v1.6.10 [2016-04-12]

[erendrake]

Most importantly, the dish is the receiver. When beaming a signal, you don't need to bounce it off a reflector, you just beam it.

This is incorrect, an antenna's gain is useful for both Rx and Tx. I have never seen a practical application of a parabolic antenna that did not use the parabola for both if it was designed for bi-directional communication.

Edited June 27, 2014 by erendrake

[Sandworm]

This mod is going through the same cycle it did last time. Everyone jumps onboard as they try to turn KSP into the game they want through a single mod. Everyone who wants realism picks something they think they've seen at nasa (time delays, flight computers) and insists that RT is irrelevant without that feature. I say, as I said last time: Keep it simple. Forget the infernal flight computer. Forget the time delays. Keep the core requirement of a link from KSC to the controlled sat. Then get some proper antenna models/cfgs (AIES). Worry about the fancy control stuff only once the mod is solidly used by thousands.

What I would like to see from the community, however, and I've asked this before, is examples of how your networks are set up at the moment. How many satellites do you use? How many dishes? Where are those dishes pointed? Most importantly, which part requires ongoing management? Knowing how RemoteTech actually gets used by the average player will help us improve the game rules much more than merely saying "RemoteTech requires juggling" as if it were obvious.!

You want examples, here are some instructional posts I made a while back... (reblogged by pizzamore)

http://forum.kerbalspaceprogram.com/entries/1490-Building-a-Remote-Tech-Relay-Constellation-Network-by-Sandworm

http://forum.kerbalspaceprogram.com/threads/56399-Now-defunct-thread-that-should-not-appear-in-google-search?p=782970&viewfull=1#post782970

And some RT pics from my imgur folder:

I never had any real issue with RT previously. It always worked. They few bugs I observed always had to do with other mods.

[AdmiralTigerclaw]

This is incorrect, an antenna's gain is useful for both Rx and Tx. I have never seen a practical application of a parabolic antenna that did not use the parabola for both if it was designed for bi-directional communication.

Yeah, that's my mistake. Like I mentioned, I haven't gone over antenna theory in three years or so. But it's an easy mistake to mitigate. The Dish is still primarily an ear, even if it does provide passive gain boost by directing the leftover Xmit lobes forward. Primarily though, most of your power is going to be in the HPA.

Anyway, I'll bite the bullet later and get on Github after I get some work around the house done.

But right now, my primary suggestion would be to start by building the code needed for power and attenuation behavior. I believe once that works, it's a simple process to incorporate passive gain based on dish size (just a set value) and power-based gain, then making the latter a tweakable.

[diomedea]

What I would like to see from the community, however, and I've asked this before, is examples of how your networks are set up at the moment. How many satellites do you use? How many dishes? Where are those dishes pointed? Most importantly, which part requires ongoing management? Knowing how RemoteTech actually gets used by the average player will help us improve the game rules much more than merely saying "RemoteTech requires juggling" as if it were obvious.

First off, RT2 is a mandatory mod in all my career games. Being career games, it requires to climb the tech tree to unlock some essential parts so to build my network properly. Early communication is handled with probes I consider temporary, to be replaced as soon as proper communication relay satellites are buildable.

My typical "proper" communication relay satellite is what I place in KSO, each of them with one Communotron 32 Omni, two DTS-M1, two Communotron 88-88, one GFX-128 dish.

The minimum configuration I use is three such satellites at 120° angles in KSO, and ideally covering longitudes 60°, 180°, 300° more than KSC, or 014°W, 106°E, 134°W. The Comm 32's provide continuous and redundant coverage for all crafts on Kerbin (poles excluded) and orbiting up to altitudes of 5100 Km; the DTS-M1's are pointed at Mun and Minmus; one Comm 88-88 is used to keep contact with another of the relays; the other 88-88 and the GFX-128 used to follow deep space vessels or for interplanetary coverage.

As soon as needed I put another similar relay in KSO and tweak orbits to make a square configuration (that way, distances among the relays are just below the range of the Comm 32, and they don't need any dish to link them). The DTS-M1's are then paired between opposite satellites, so two DTS-M1 (from opposite satellites) are pointed at Mun, and two at Minmus. That leaves a total of 4 DTS-M1, 8 Comm 88-88 and 4 GFX-128 available, to be used in pairs (again, coupled from opposite satellites) for each deep space craft or planet I need to connect to (total 8 such connections available).

Poles on Kerbin are covered by other probes with just a single Comm 32 in a high-inclined orbit, their primary mission of a different nature (e.g. SCANsat or Kethane scanning).

When I start making interplanetary missions, I send probes with communications capability early on, at least two to orbit each body (often on the same orbit, their anomalies at 180° distance, inclination at 90° from the ecliptic). These satellites must have one long-range dish (to connect back to Kerbin), one Comm 32, one DTS-M1 for each moon to be covered.

What parts require management? Assigning dishes (in couples from different relays) to cover each specific craft moving between planets or in deep space.

[Roastduck]

How would I go about finding the target IDs for different bodies? Like, say I wanted to manually edit my config file to change an antenna's target. How would I find the target ID to do that?

[erendrake]

But right now, my primary suggestion would be to start by building the code needed for power and attenuation behavior. I believe once that works, it's a simple process to incorporate passive gain based on dish size (just a set value) and power-based gain, then making the latter a tweakable.

I think these are great ideas and could be a cool use of the tweakable system. being able to amp up an antenna at the cost of power is a neat idea.

This idea not only models a real life principle of how RF works but could open up all kinds of additional features. Good Idea!

[JeffreyCor]

I concur, the ideas presented for this sound fantastic and add even more richness and dimension to this already amazing mod with added user flexibility.

[AdmiralTigerclaw]

Just sent a PM to StarStrider in response to one he sent me, but I think I know what it is about Dish aiming that's the biggest problem.

It's how it handles the targeting modes.

Field of View cones have some kind of limitation in the coding or math when they were created that caused them to only work if the object you want to talk to was inside the SoI of the planet you aimed the cone at. If you aim a wide-beam antenna at Duna, even if a the probe was in range and inside the cone, if it wasn't in Duna's SoI, it was ignored.

To get around that, direct connection is the second targeting mode. In which the dish is 'aimed' directly at a specific spacecraft. It's FoV cone is ignored, and it can ONLY connect to what it's aimed at. All other logically possible connections that would be in its field of view are ignored and rejected.

The problem for players is the shuffling between these connection types more than anything. So really, the problem is that the Field of View cone, ISN'T. It's an ad-hoc that doesn't work as it should. Does okay if you're running everything all inside the same SoI, but the moment you start going interplanetary, it goes down the toilet and players start having to shuffle their connections.

If dish FoV cones can be fixed, then so can targetting. Aim it at a planet? The planet is the center of your aim cone. Aim it at a probe, the probe is the center of your aim cone. Either way, anything in the aim cone can talk. You don't need to shuffle.

The only other issue to deal with is finding ways to 'call' a spacecraft that isn't aiming a dish in the right direction. I still think a ready standby like the idea I had in the old thread would be good to have. If the dish is in RS mode, any other dish that directly targets it as the cone center automatically sets its aim mode to it in return.

Edited June 27, 2014 by AdmiralTigerclaw

[Drew Kerman]

Thank you RT2 devs for never requiring the use of MechJeb.

How would I go about finding the target IDs for different bodies? Like, say I wanted to manually edit my config file to change an antenna's target. How would I find the target ID to do that?

it's the ID of the object, identified by the pid property at the top of the VESSEL structure for the craft in your persistent.sfs file. Then, you want to set this ID to the RTAntennaTarget property of the ModuleRTAntenna in the dish PART structure for the craft you are targeting from

[kragon]

is there a reason that omni directional transmitters cant connect to each other?

[Drew Kerman]

is there a reason that omni directional transmitters cant connect to each other?

plenty of reasons. Most likely because you're doing something wrong. Are they both activated? Are they in range (if they aren't the same type, shortest range only will work)? Do they have line of sight? We'll need to know exactly what you have setup if anyone is to help you out

[BigD145]

is there a reason that omni directional transmitters cant connect to each other?

http://forum.kerbalspaceprogram.com/threads/56399-Now-defunct-thread-that-should-not-appear-in-google-search?p=866915&viewfull=1#post866915

[Sentmassen]

I was wondering if there could be an exemption made for renaming/reclassifying vessels. Right now you need a connection to the probe in order to do so. It strikes me as something that mission control should be able to do.

The problem I have is that I have space debris that's stuck on "probe" or "capsule" when its just cast offs from a previous mission floating about. I Know I can go into the persistence file and change it i was hoping there was a way to get it back into the game.

[DerekL1963]

Now, if this change were to occur, omnis would require reworks as well. Transmission and reception are independent functions. You don't actually transmit on the same antenna you receive on. Otherwise, your Xmit signal would burn up your receive channel right at the electrical connection. So any given commsat would require two omnis for full comms. One to transmit, and one set to receive. (In real life, Xmit and receive occur on two different frequencies so the having an Xmitter next to a Rcvr doesn't result in the Rcvr just being jammed.)

Huh? In real life, radios *routinely* transmit on the same antenna they receive on. (You stop the transmitter from burning out the receiver with the appropriate switching network. Bog standard radio engineering running back a century.) In the same vein, transmitting on the same frequency you receive on is pretty much routine. You can engineer things to use two separate antenna or frequencies, but it's generally avoided unless there is a very good reason to as doing so pushes up the cost and complexity of the radio.

[Pyromaniacal]

KSP version? OS?

I'm using Windows 8.1, KSP version 0.23.5.

[OminousPenguin]

I've been on a break from KSP since starting a new job in April. What a delight to return to the forum and find what's happened in the last few months!

Massive thanks to Cilph and to Warrenseymour, Starstrider42, Erendrake and all contributors.

I may start to familiarise myself with the codebase and contribute at some point.

[agent 902]

i have a problem,i cant get probes to recuier a signal,the signal delay clock says N/A and is red,and i can controle a probe on duna without eny relay network

Do i miss some step to activate the mod

Eny help is welcome

[diomedea]

Now, if this change were to occur, omnis would require reworks as well. Transmission and reception are independent functions. You don't actually transmit on the same antenna you receive on. Otherwise, your Xmit signal would burn up your receive channel right at the electrical connection. So any given commsat would require two omnis for full comms. One to transmit, and one set to receive. (In real life, Xmit and receive occur on two different frequencies so the having an Xmitter next to a Rcvr doesn't result in the Rcvr just being jammed.)

Huh? In real life, radios *routinely* transmit on the same antenna they receive on. (You stop the transmitter from burning out the receiver with the appropriate switching network. Bog standard radio engineering running back a century.) In the same vein, transmitting on the same frequency you receive on is pretty much routine. You can engineer things to use two separate antenna or frequencies, but it's generally avoided unless there is a very good reason to as doing so pushes up the cost and complexity of the radio.

There is something right in both the posts quoted above. Hope not to fuel disagreement, but rather to help put things correctly (I worked IRL on radio/radar systems, so believe to know something here).

AdmiralTigerclaw is correct trasmission and reception are two different functions. When both functions are to be performed at the same time, you can't use the same antenna.

Radio systems IRL are classified into Transmitters (TX), Receivers (RX) and Receiver-Transmitters (RTX). Most of the high power systems use totally independent channels (TX + RX), unless your system is designed to transmit only in time bursts, and to receive between bursts. Same for radar systems.

But, most used and popular radio sets are RTX. They certainly always use the same antenna for both functions. In radar technology, a couple of internal devices (the TR and ATR switches) protect the receiver when the transmitter is "On Air", and avoid losses of the received radio energy closing the way to the trasmitter. With older RTX radio sets, users had to wait for the frequency to be free before transmitting, or they would not receive anything in the meantime. More modern radio sets (professional ones) use time bursts, so their trasmission cycle is very short and may not be noticed from the user. They receive bursts from other RTX devices, decompress them and the user experiences an almost continuous signal on the receiving end. Some radio networks even sync the timings for each transmitter to send its data (Roll-Call mode) so to ensure no data are lost in a transmission cycle for any of the radio systems in the network (while the normal broadcast mode could leave two or more radio sets transmitting at the same time).

[Jivaii]

http://forum.kerbalspaceprogram.com/threads/56399-Now-defunct-thread-that-should-not-appear-in-google-search?p=866915&viewfull=1#post866915

A Comm16 antenna isn't going to reach from stationary orbit....you'll want 32s for that.

[BigD145]

A Comm16 antenna isn't going to reach from stationary orbit....you'll want 32s for that.

Yes, I said that.

[Starstrider42]

This mod is going through the same cycle it did last time. Everyone jumps onboard as they try to turn KSP into the game they want through a single mod. Everyone who wants realism picks something they think they've seen at nasa (time delays, flight computers) and insists that RT is irrelevant without that feature. I say, as I said last time: Keep it simple. Forget the infernal flight computer. Forget the time delays. Keep the core requirement of a link from KSC to the controlled sat. Then get some proper antenna models/cfgs (AIES). Worry about the fancy control stuff only once the mod is solidly used by thousands.

Wait... you're saying time delay is not a fundamental feature?

If dish FoV cones can be fixed, then so can targetting. Aim it at a planet? The planet is the center of your aim cone. Aim it at a probe, the probe is the center of your aim cone. Either way, anything in the aim cone can talk. You don't need to shuffle.

This is essentially this suggestion: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/13. I agree that the current system is far too unintuitive, and I'll let the rest of the group know that it should be a priority.

The only other issue to deal with is finding ways to 'call' a spacecraft that isn't aiming a dish in the right direction. I still think a ready standby like the idea I had in the old thread would be good to have. If the dish is in RS mode, any other dish that directly targets it as the cone center automatically sets its aim mode to it in return.

MOARdV suggested something similar here: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/107. Since you told me you were planning to post to GitHub anyway, feel free to chip in.

I was wondering if there could be an exemption made for renaming/reclassifying vessels. Right now you need a connection to the probe in order to do so. It strikes me as something that mission control should be able to do.

A fix for this bug is already in review.

i have a problem,i cant get probes to recuier a signal,the signal delay clock says N/A and is red,and i can controle a probe on duna without eny relay network

Do i miss some step to activate the mod

Do you have ModuleManager installed (should have been included in the download)? Is the RemoteTech2 folder in GameData? Are you using a non-stock probe core? Those are the most likely culprits.

--------------------------------------

Thanks to everybody who posted or PM'd their network strategies. I'll post a more intelligent response than that once I've had time to read through them.

Also, starting next week through the end of July I won't have much time for KSP stuff, so expect my appearances on this thread to be much shorter and terser. Hopefully the other RT devs can answer any questions that come up.

[Starstrider42]

And some RT pics from my imgur folder:

http://i.imgur.com/IrZPrc0.png http://i.imgur.com/0gKupl3.png

I never had any real issue with RT previously. It always worked. They few bugs I observed always had to do with other mods.

From the screenshots, it looks like you're mostly doing what we expected players to do. I'm a little curious about the interplanetary relays, though -- in the first screenshot, it looks like you have a cone pointing from Dres(?) to Duna, and in the second you have one between Eve and Duna. What was your reasoning for doing that in addition to direct links to Kerbin?

What parts require management? Assigning dishes (in couples from different relays) to cover each specific craft moving between planets or in deep space.

Hmm, I hadn't thought of assigning antennas in pairs. Very clever.

Would making antennas configurable from the map screen reduce the workload for your network style? Would reassigning Kerbin comsat dishes still be the biggest chore if that were implemented?

As for reassigning antennas to point to targets in deep space, this is the situation Cilph developed active vessel for. However, both of the players who sent me text descriptions implied they don't use it. I know AV has a bit of a bad rep because of how it interacts with planetary relays (image below), but are there other reasons it's not popular?

[Grays]

Hi,

I've posted about this before and messaged before, but still am not really getting a response.

I'd like to get involved with the official documentation. Who would I contact about that?

I'm the author of the reddit guide, I'm drafting a new update to that guide, and I'm creating some diagrams for new users to get a better visual idea of what's going on. All of this will be in the reddit guide, but I've tried contacting people (Cliph a few months ago, woogoose recently) about helping with the official documentation and haven't gotten any replies.

Edited June 28, 2014 by Grays

[Sandworm]

From the screenshots, it looks like you're mostly doing what we expected players to do. I'm a little curious about the interplanetary relays, though -- in the first screenshot, it looks like you have a cone pointing from Dres(?) to Duna, and in the second you have one between Eve and Duna. What was your reasoning for doing that in addition to direct links to Kerbin?

The theory with those is to create multiple possible paths from different perspectives. This solves a couple problems. (1) The lower the orbit, the more likely a probe will loose LOS with the relay. Bouncing the signal off another planet, in a radically different part of the sky, greatly reduces this dark time. (2) Sometimes the distance between Kerbin and the target is too great for whatever antenna you are using (career mode here). Relays on inner planets (eve) make possible longer connections.

I'm not a fan of exacting orbits. They aren't realistic imho. Every realworld communication sat does some degree of station keeping but KSP's "on rails" model doesn't allow for this. So I try to create systems that accommodate drift.

[diomedea]

Hmm, I hadn't thought of assigning antennas in pairs. Very clever.

Would making antennas configurable from the map screen reduce the workload for your network style? Would reassigning Kerbin comsat dishes still be the biggest chore if that were implemented?

As for reassigning antennas to point to targets in deep space, this is the situation Cilph developed active vessel for. However, both of the players who sent me text descriptions implied they don't use it. I know AV has a bit of a bad rep because of how it interacts with planetary relays (image below), but are there other reasons it's not popular? http://remotetechnologiesgroup.github.io/RemoteTech/guide/overview/activerelaybug.png

First, let me thank you for even considering that suggestion .

I tend to have the map screen quite clogged in the vicinity of Kerbin, while doing a career game. So, if I have to reach for any craft by clicking on it on the map screen, that action is far less easy than it should be, due to all the other crafts close by. But, the target selection menu accessible from the map view (to assign an antenna) is absolutely fine. I would imagine however to have another menu available (possibly with Mission Control, as those Github comments suggest) where all available antennae from all communication sats in orbit around a body can be controlled together. Multiple antennae may be assigned to specific groups, and then may be activated and assigned targets with a single group command. Like on a spreadsheet, with rows for available antennae (or groups) and columns for possible targets, and the user may select a specific target for each antenna (or group), all in a single place.

Have to say, the above is not actually an original idea from me. It is how complex comms network assets are managed in real life (the "spreadsheet" is implemented in a real device, in my local reality it is called the "matrix").

About Active Vessel. I am not fond of it, and almost never use it (or, could say I never use it unless for testing purposes). My personal reason is I don't feel it enough realistic, while its logic also makes nasty troubles (I'm sure you don't need hints about those, you sure know very well). Actually, ActiveVessel works, and well, if what I need is just a temporary two-way link to any deep-space probe I sent. I would never allow a manned (kerbaled) mission to be out of good continuous comms however. And when a ship or probe is close to a body or any maneuver node, I want to have comms links firmly established (realism indeed, as my feel is Mission Control would want to in reality).

Anyway, I am definitely not among those who wanted to see ActiveVessel removed (reference to the previous RT2 thread). It works for some users. But, my realism need also requires something else.

If at all possible, I would like to see some automatic search and linking algorithm implemented, for any antenna that loses its primary (defined) link, as a way to re-establish comms whenever needed. My feel is it would be far more realistic than the current system (with or without ActiveVessel). But, this proposal got a lot of dissent when discussed in the previous RT2 thread, so it will have to be examined again here. And, in the end, that is something that requires some serious work to implement: I am happy if you keep RemoteTech working and possibly implement new things a bit at a time, rather than risk to block everything with a very ambitious rework .