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

[Starstrider42]

Running RemoteTech 1.4.0

I have a constellation of comms satellites around Kerbin, using a mix of 88-88 (40 Gm) and KR-14 (60Gm) dishes. Call them C1,C2,C3,C4. And all is well. I have 100% coverage out to MinMus

I have a relay sat at the edge of Kerbin Space, running several GX-128 (400 Gm) dishes. Call it R1. And all is well, and reach this sat from anywhere in Kerbin SOI.

All sats are linked to KSC, their closest neighbors, my outer relay sat R1, and "active vessel"

I have another relay sat of very similar design, also with GX-128's, that has just exited Kerbin SOI. Call it R2.

It is linked to KSC, and R1. R1 is also linked to R2.

Seen from R1, all vessels are linked. (second picture)

However, seen from R2, It shows link to R1, and THEN NOTHING. It is disconnected!

This same connection lasted until the exact moment when it left Kerbin SOI.

All vessels are powered, connected, functional and have ample power. Except R2 now has gone disconnected..

Just to be sure I understand things correctly, is this your network:

Satellite C# 
Antenna 1: KSC
Antenna 2: Left neighbor
Antenna 3: Right neighbor
Antenna 4: R1
Antenna 5: Active Vessel

Satellite R1
Antenna 1: KSC
Antenna 2: One of the C-series satellites
Antenna 3: R2

Satellite R2
Antenna 1: KSC
Antenna 2: R1

That sounds like it should work. C# has a permanent, non-active connection to R1, and R1 has a permanent, non-active connection to R2. Sounds like bug report material.

To my knowledge (including successful interplanetary missions), Active Vessel does work outside Kerbin's SoI. In fact, that's the main place where it's worth using. MeCripp, if you have a bug report we'd be happy to take it, but please don't state speculation as facts. You've confused quite a few other players.

I'm not yet aware of any changes that are already coming in that respect, but can I suggest adding consistency to Active Vessel a priority?

Most problems with RT2 posted here (or anywhere else) have to do with this feature. I agree with those that say it has it's uses, but at the moment the actual use cases are extremely limited due to its limits, which are neither obvious nor explained (or warned about) in the UI.

You'll have to be more specific. What about it is inconsistent? I know cones are inconsistent (as you outline below), and that's scheduled for fixing...

Part of the problem is also that it's not very obvious why a certain link is (or is not) active when looking at the map, the/only primary tool to diagnose a network. A player controlling a probe/sat currently above the Mün - intended as a relay for crafts in it's shadow - can see the connection to their main network around Kerbin, because those satellites have AV as a target. As far as I know there is no way to see why the connection is made (is it targeted? inside a cone? due to active vessel?). Once he switches to the vessel behind the Mün - which would now need that relay - he get's no connection and doesn't know why. He's not told "Active Vessel: no line of sight", "Out of range" or anything else along those lines. All this could be in a tooltip (if KSP allows that) or drawn as text next to satellites (with a new button in the lower-right corner to toggle this). As a more minimalist and less intrusive alternative, color-coding the relay-satellite-icons (and potentially the lines to the target) could also work. Preferably with a key at the side to explain what it all means, like so:

• Green (normal line): Connect/Targeted'
  
• Green (dashed line): 'Connected/Active Vessel'
  
• Green (dotted line): 'Connectec/In target Cone'
  
• Yellow (normal line): 'LoS Obstruction'
  
• Yellow (dashed line): 'LoS Obstruction/Active Vessel'
  
• Yellow (dotted line): 'Connectec/In target Cone'
  
• Red: same as above, meaning 'Out of Range'
  

There was an old feature request (https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/31) for something very much like this. I think RemoteTech does need to give more feedback, but specific suggestions like this one will help make the idea much more focused and useful. Would you mind posting this on the thread I've linked?

Disclaimer: I can't promise that all the specific errors you mention can actually be checked for and isolated. But I'll leave that call to people more familiar with the network code than I am.

Forgive me if I missed anyone going into any more detail on this, but I noticed mention of efforts to make future versions of RT2 more compatible with kOS with regards to the flight computer. And I was wondering if there are plans, even if they're far off, to improve the flight computer to the point where using kOS wouldn't be necessary for more advanced planned piloting, or if it's going to be left as is for now.

I ask because I've looked into kOS and it's not really my cup of tea, but on the other hand, l'd like to be able to play with signal delay enabled as well.

The intent of the flight computer was to make RemoteTech playable without forcing players to download an autopilot mod. The idea was that players who do want fully-featured autopilot would have installed kOS or MechJeb anyway. I would very much like to see support for both, although apparently there are some fundamental conflicts between how RemoteTech and MechJeb do things, so that may be a while off.

So to answer your question, no. We're planning to make the current features more reliable (which I agree is badly needed), but we're not currently planning to add anything as complex as, say, automated landings. We may change that stance in the future if MechJeb integration really seems impossible.

Any chance for modular dishes at some point? Where you can tweak the FoV of it, like make it wider but you lose distance, narrower and you gain it, etc.

Old suggestion, shot down by Cilph: https://github.com/Cilph/RemoteTech2/issues/225

So my answer is "not soon". (Also, I suspect AdmiralTigerclaw would never forgive us for something so unrealistic. )

Edited July 6, 2014 by Starstrider42

[lepla]

Ah...

Thanx.

how do you do to see the lines that represent remote communication?

[Creat]

... long text about active vessel, mentioning it has inconsistencies ...

You'll have to be more specific. What about it is inconsistent? I know cones are inconsistent (as you outline below), and that's scheduled for fixing...

My first issue is that 'Active vessel' works like a targeted connection, not like a cone. Take the example from my last post, if the probe is behind the Mün, it should automatically route via the relay-satellite because it's inside a cone. I have told the sats around Kerbin to connect to whatever I'm trying to control, so trying a little harder would seem reasonable. This would allow relays to use 'Active Vessel' instead of always having to manually target cones at wherever I'm operating at. This is not a big deal, I'm just explaining it in more detail as I remember that I was really surprised when I learned that active vessel would only establish a direct connection and not just act as if the dish was just aimed at the active vessel (i.e. cone targeting).

As a side note: I'd love to have even directly targeted connections work with a cone, because in reality they would. You just point the dish in some direction, if a signal comes from that direction it'll be received (provided it's the right frequency and stuff, but we don't model that [yet?] ). But I can understand how that would probably start causing performance problems on large or huge networks, especially with the fixed cone behavior giving more potential targets. Finding connections and routes for signals should stay relatively cheap, the game has enough stuff to do after all...

My second issue isn't one: On the page before my post someone said it didn't work outside SoI, so I took their word for it (as I haven't used it since the 1.x days and thought it might've been changed since then). Sorry for that... I did try to look this stuff up, but the wiki is still under construction it seems and I didn't find anything about it...

There was an old feature request (https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/31) for something very much like this. I think RemoteTech does need to give more feedback, but specific suggestions like this one will help make the idea much more focused and useful. Would you mind posting this on the thread I've linked?

Disclaimer: I can't promise that all the specific errors you mention can actually be checked for and isolated. But I'll leave that call to people more familiar with the network code than I am.

Sure thing. I've corrected and refined the text a bit and posted it to that thread. I really hope it'll find some use or at least provide some inspiration, as we do need a way to actually diagnose a problem. It might also be helpful having access to target lists (or a visualization of targets) set for any satellite from the map. I've added a paragraph to the end detailing that idea a bit more.

@Everyone: please do go to that thread and add your ideas, a bit more attention from users might make the devs take a look at it sooner

[MrWizerd]

Hi, I don't want to throw a wrench in these conversations but I had an idea, in the LLL part set there is a rotating fish, and while I have been learning to make new parts I found out how the sun trace code makes the solar panels track the sun. I thought to myself that out would be neat if other things could be pointed and tracked in a similar way. I realize this is sort of an affectation but could something like this work within a mod like remote tech or is it fundamentally a no go because it would have to be added to the core game?

[diomedea]

Hi, I don't want to throw a wrench in these conversations but I had an idea, in the LLL part set there is a rotating fish, and while I have been learning to make new parts I found out how the sun trace code makes the solar panels track the sun. I thought to myself that out would be neat if other things could be pointed and tracked in a similar way. I realize this is sort of an affectation but could something like this work within a mod like remote tech or is it fundamentally a no go because it would have to be added to the core game?

If I get this correctly, you could be able to make antennae track the angular position of their target. Would be an extremely cool effect .

But then, I will have to change how vessels are built, so to allow more space for those big dishes to rotate. Communication masts may become essential to make enough space, and probably some new parts (deployable/extensible masts) may be required.

Then, antennae should be coded to have some hard limit (at least, by a couple of tweakables) on the horizontal and vertical rotation they can assume IRT the mounting node.

And if really this takes ground, I can foresee (for those really loving realism) a future version of RT2 that checks the orientation of the dishes with all other conditions for successful connection.

Yes, I love this idea...

[JDP]

Hi, I don't want to throw a wrench in these conversations but I had an idea, in the LLL part set there is a rotating dish, and while I have been learning to make new parts I found out how the sun trace code makes the solar panels track the sun. I thought to myself that out would be neat if other things could be pointed and tracked in a similar way. I realize this is sort of an affectation but could something like this work within a mod like remote tech or is it fundamentally a no go because it would have to be added to the core game?

Tracking dishes where implemented in RT1 and ever since RT2 started development it has been one of the most often suggested features. I did in fact implement tracking dishes in the old RT2 repo under Cilph, and adding them here would be no problem. The main issue is with the part models themselves: none of the dishes added by RT2 or already present in stock have the needed joints to rotate.

So in short; it would be easy to code but would necessitate all new dish models and maybe some custom code for each of the stock dishes. Since RT2 is in short supply on modelers skilled in making stockalike models I sadly don't see tracking dishes being implemented anytime soon. I could reimplement tracking dishes in the code though, so prospective RT modelers have something to work with.

[diomedea]

Tracking dishes where implemented in RT1 and ever since RT2 started development it has been one of the most often suggested features. I did in fact implement tracking dishes in the old RT2 repo under Cilph, and adding them here would be no problem. The main issue is with the part models themselves: none of the dishes added by RT2 or already present in stock have the needed joints to rotate.

So in short; it would be easy to code but would necessitate all new dish models and maybe some custom code for each of the stock dishes. Since RT2 is in short supply on modelers skilled in making stockalike models I sadly don't see tracking dishes being implemented anytime soon. I could reimplement tracking dishes in the code though, so prospective RT modelers have something to work with.

Could the joints be separate parts, connecting to an antenna and a base structure, so that existing antennae are not directly affected? Would be possible with your code to actually define the orientation of such joints instead of the antennae mounted on them?

I guess modeling a rotary joint is somewhat easier than a rotating antenna (and probably some parts in other mods, e.g. Infernal Robotics, are already good to use as joints).

[Rayder]

IMO it would make dish placement even more complicated as sometimes even the very large dishes can be tricky to mount on some satellites - especially if you're using FAR. You would have to make sure that the dish doesn't collide with the satellite / craft.

[AdmiralTigerclaw]

I don't think the larger dishes would be mounted on any special joints anyway. Beyond a certain point, it probably just becomes a case of 'just turn the satellite'.

[JDP]

Could the joints be separate parts, connecting to an antenna and a base structure, so that existing antennae are not directly affected? Would be possible with your code to actually define the orientation of such joints instead of the antennae mounted on them?

I guess modeling a rotary joint is somewhat easier than a rotating antenna (and probably some parts in other mods, e.g. Infernal Robotics, are already good to use as joints).

That's actually a very good idea. Of course I'd have to take a look at infernal robotics to see how to properly move attached parts with the joints. All in all it shouldn't be too hard to write up. I do believe that I'd have to restrict attachment of dishes to only attach nodes, since only one dish should be placed on the joint and the direction vector of any attached dish should be constant.

Of course this still is in need of a model. I could make it myself, but I've never been good at anything but the minimalistic look of RT1. I'll make a mockup once I get to a computer (I'm currently on a tablet) and any part modelers will be welcome to contact me with their designs.

And of course this would only be a visual enhancement, just like it was in RT1.

Edited July 7, 2014 by JDP

[sharpspoonful]

Why not just have the whole satellite rotate? There are few positions a sat with 2 to 4 panels can be in where the sun wouldn't hit a solar panel, people won't make requests for multiple part update, nor would there be any modeling issues. Alternatively one could just use the powered rotator and 90 pivotron from IR to make it move in specified directions.

[JDP]

Why not just have the whole satellite rotate...

That would only work if the sat had only one dish. A relay sat can typically need at least two.

[SkipSpikowski]

I'm having an issue with an interplanetary probe. When it leaves the SOI of Kerbin I lose coms with it.

Here's how I have my network configured:

Probe (Untitled Space Craft <- because I forgot to change the name):Kr-14 targeting Kerbin

Relay Station in Geostat: targets Mission Control with a DTS and KR-14's targetting Duna and Sun.

I assume I am doing something wrong but I'm not sure what.

[Yellowsign]

i had an idea for this mod but didnt know where to post it, so here you go.

I would love something that could tell me when my satellites are going to go in and out of connection with KSC or a command center. It could be just a simple count down timer by the delay clock, telling you (T- Hours,Minutes,Seconds till signal loss) and (T- Hours,Minutes,Seconds till signal up-link). Would that be possible?

[Yemo]

I'm having an issue with an interplanetary probe. When it leaves the SOI of Kerbin I lose coms with it.

Here's how I have my network configured:

Probe (Untitled Space Craft <- because I forgot to change the name):Kr-14 targeting Kerbin

Relay Station in Geostat: targets Mission Control with a DTS and KR-14's targetting Duna and Sun.

I assume I am doing something wrong but I'm not sure what.

Afaik the Kr-14 only has a 0.04 degree targeting cone. So at 90Mm (outside Kerbins SoI) your Probe targets a cone of about 31km radius on Kerbin and almost all the time, your Relay Station is somewhere else.

Afaik with such mini cones you must target the Relay Station itself.

Of course you lose connection when your Relay Station is behind Kerbin, Mün or Minmus...

For a nearly 100% uptime at that distance you need 3 dishes. 2 Pointed at Kerbin com sats and 1 pointed at a comsat in front of or behind the Mün (or a relay station on the Mün surface opposite to Kerbin).

edit: Of course the relay stations need KR-14s set to "active vessel", so they establish connection once you take command of the probe again. Permanent connection from relays to probe is unnecessary imho.

Edited July 7, 2014 by Yemo

[BigD145]

I'm having an issue with an interplanetary probe. When it leaves the SOI of Kerbin I lose coms with it.

Here's how I have my network configured:

Probe (Untitled Space Craft <- because I forgot to change the name):Kr-14 targeting Kerbin

Relay Station in Geostat: targets Mission Control with a DTS and KR-14's targetting Duna and Sun.

I assume I am doing something wrong but I'm not sure what.

Your probe is targetting Kerbin? Which has nothing to receive transmission from your probe except in a very narrow window of time when Mission Control has line of sight to your probe? Mission Control also only has the ability to reach inside its own SOI for communication.

You have no network with everything you've built and aimed. You just have a thing in space attempting to talk to the Sun and Duna and a probe trying to talk to the planet Kerbin. Nothing is connected. Communication is a two-way street and you don't even have one way.

[JDP]

i had an idea for this mod but didnt know where to post it, so here you go.

I would love something that could tell me when my satellites are going to go in and out of connection with KSC or a command center. It could be just a simple count down timer by the delay clock, telling you (T- Hours,Minutes,Seconds till signal loss) and (T- Hours,Minutes,Seconds till signal up-link). Would that be possible?

Possible, yes. But somewhat complicated and possibly very laggy to implement. The way the plugin currently finds a valid connection is roughly looking for the closest approximation to a straight line between each command station and the satellite, then choosing the shortest resulting path. Doing this takes a bit of toll on your computer and if done inefficiently or excessively will cause lag.

Let's say you want to the system to predict just 1 hour in the future and want a resolution of 1 second. That would mean that your computer suddenly has to find 3600 connections where it would normally only have to find one.

[SkipSpikowski]

I figured it was something I was doing, but didn't know what because inside the Kerbin SOI I can just target the Mun or Minmus and have the Sats around the moons target Kerbin and it works. But I see what you're saying. I need to actually target the probe and the proble needs to target the relay station.

Your probe is targetting Kerbin? Which has nothing to receive transmission from your probe except in a very narrow window of time when Mission Control has line of sight to your probe? Mission Control also only has the ability to reach inside its own SOI for communication.

You have no network with everything you've built and aimed. You just have a thing in space attempting to talk to the Sun and Duna and a probe trying to talk to the planet Kerbin. Nothing is connected. Communication is a two-way street and you don't even have one way.

[Mecripp]

Tracking dishes where implemented in RT1 and ever since RT2 started development it has been one of the most often suggested features. I did in fact implement tracking dishes in the old RT2 repo under Cilph, and adding them here would be no problem. The main issue is with the part models themselves: none of the dishes added by RT2 or already present in stock have the needed joints to rotate.

So in short; it would be easy to code but would necessitate all new dish models and maybe some custom code for each of the stock dishes. Since RT2 is in short supply on modelers skilled in making stockalike models I sadly don't see tracking dishes being implemented anytime soon. I could reimplement tracking dishes in the code though, so prospective RT modelers have something to work with.

Coulded we just use the old dishes ?

[SkipSpikowski]

Question:

When and why would I ever use the SOI targeting? I'm not really sure how this works, so can someone point me in the right direction?

[Creat]

Question:

When and why would I ever use the SOI targeting? I'm not really sure how this works, so can someone point me in the right direction?

What do you mean by "SOI targeting"? Do you mean targeting a celestial body in the target list?

[SkipSpikowski]

What do you mean by "SOI targeting"? Do you mean targeting a celestial body in the target list?

Yeah, how in the list you see Kerbin, Duna, etc...

[Drew Kerman]

it's just the closest you can get to having a dish behave like an Omni. Instead of having to specifically tell it what satellite to point at to get a link between two planets, it will auto-connect to any satellite orbiting the planet within its cone to give you a link back to MC on Kerbin

[SkipSpikowski]

So just to clarify: if I have a sat at Duna and it points to Kerbin and one at Kerbin that points at Duna, then they will connect, correct?

it's just the closest you can get to having a dish behave like an Omni. Instead of having to specifically tell it what satellite to point at to get a link between two planets, it will auto-connect to any satellite orbiting the planet within its cone to give you a link back to MC on Kerbin

[Mecripp]

So just to clarify: if I have a sat at Duna and it points to Kerbin and one at Kerbin that points at Duna, then they will connect, correct?

Yes If it as the range and is in the cone and line of sight.