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

[Cilph]

Okay, here's the idea for dish targeting:

Mode 1: Target planets. Has the cone of vision (dish parameter), anything in the cone connects as if the dish were an omni.

Mode 2: Target satellites. Currently it's very static and does not use the cone of vision in any way. I intend on changing this to function like above. This way it won't matter what you point at, behaviour is identical.

Mode 3: Groups. You can subscribe a number of satellites to a group, such as "LKO Sats", and you will be able to target everything in that group at once. For performance reasons, this would NOT have a cone of vision.

OPINIONS?

EDIT: Memos of a rambling fool:

• Revise targeting;
  
• Exception-robustness;
  
• Debug menu / configuration menu / satellite fixer
  
• Refactoring
  
• Eggs
  
• Crisps
  
• Find some sort of agile board to track my current issues
  
• Delete half the issues on GitHub.
  

Edited January 24, 2014 by Cilph

[Andon]

I think Mode 1 would be best. It means less haggling with re-targeting things, and makes it easier to target things as well. The only things that you'd have to target individually would be craft between planets

[Cilph]

I think Mode 1 would be best. It means less haggling with re-targeting things, and makes it easier to target things as well. The only things that you'd have to target individually would be craft between planets

They aren't options. All three will be usable. What do you think about the trio? Does it cover all use cases?

[Mecripp]

Mode 1 Sounds great and Cilph is there anyway we can get range to target and max range ?

[DerekL1963]

They aren't options. All three will be usable. What do you think about the trio? Does it cover all use cases?

It certainly seems to... But a question about Mode 2, it reads as if when it can't connect to it's targeted bird(s) it defaults to Mode 1 (but pointed at the targeted bird rather than the planet) and tries to find a bird pointed back at it that is within the cone. Is this correct?

Going forward, it's really important that the connection modes and logic be clear and straightforward... that will make it easier to understand, to teach new users, and to troubleshoot networks.

[Cilph]

It certainly seems to... But a question about Mode 2, it reads as if when it can't connect to it's targeted bird(s) it defaults to Mode 1 (but pointed at the targeted bird rather than the planet) and tries to find a bird pointed back at it that is within the cone. Is this correct?

Going forward, it's really important that the connection modes and logic be clear and straightforward... that will make it easier to understand, to teach new users, and to troubleshoot networks.

It works like Mode 1 (planet targeting), but focused on a satellite instead of a planet. It will form a connection with anything in the cone that is pointing back at it.

[Soda Popinski]

Okay, here's the idea for dish targeting:

Mode 1: Target planets. Has the cone of vision (dish parameter), anything in the cone connects as if the dish were an omni.

Mode 2: Target satellites. Currently it's very static and does not use the cone of vision in any way. I intend on changing this to function like above. This way it won't matter what you point at, behaviour is identical.

Mode 3: Groups. You can subscribe a number of satellites to a group, such as "LKO Sats", and you will be able to target everything in that group at once. For performance reasons, this would NOT have a cone of vision.

Sounds great to me. Will we be able to set a time delay on switching over? I'm thinking about when you launch, you may want it targeted to Mission Control or any LKo satellites, then instead point to an external satellite network (say orbitting the Mun, if you're going to the Mun). If you can set a time delay, it would be useful so you don't have to babysit it.

Oh, is the bug I mentioned, where the craft can't maintain attitude control if you switch "control from here" an acknowledged bug?

[brusura]

Uhm sorry guys, I did not find elsewhere, but I can not terminate flight from tracking center, I got the popup asking if I am sure I click yes but vessel is still there

[Cilph]

Sounds great to me. Will we be able to set a time delay on switching over? I'm thinking about when you launch, you may want it targeted to Mission Control or any LKo satellites, then instead point to an external satellite network (say orbitting the Mun, if you're going to the Mun). If you can set a time delay, it would be useful so you don't have to babysit it.

Oh, is the bug I mentioned, where the craft can't maintain attitude control if you switch "control from here" an acknowledged bug?

https://github.com/Cilph/RemoteTech2/issues?state=open

I stopped paying attention to bug reports on the forums weeks ago. I have enough trouble memorizing what to do as is.

[diomedea]

...All three will be usable. What do you think about the trio? Does it cover all use cases?

I like those modes. IMO, those cover rather realistically most of possible needs.

Mode 3 may be considered able to reestablish a lost connection in emergency, something we were discussing time ago and I consider more realistical than the current "bird lost due to the other vessel it was pointing a dish to for a connection back to KSC eaten by kraken" that somebody finds so enthralling.

However, being mode 3 only limited to same SOI, that feature is not completely achieved, I need to park a couple relays outside of Kerbin's SOI to be safe in keeping contact with a probe sent all the way to Eeloo and beyond.

Therefore, I would have preferred to see another option, "in case of krakens", so to simulate my probe trying to get any signal from anybody in range.

Edited January 24, 2014 by diomedea
corrected typo

[gleedadswell]

I'm really enjoying this mod. It totally changes the game and gives you more reasons to do launches other than gathering science. I'm playing with it in conjunction with a variety of "realism" mods, and it is a great addition to them. But there is an issue that I'm running into: the power demands of antennas! The power demands seem much too high and mean that communication satellites based on real satellites don't work.

For example, the antennas which seem like logical choices for the main antenna on early, low-orbit comm sats (omnidirectional ones with a few thousand km range) requires power to the tune of 0.1-0.2 units per second. The only photoelectric panel available at the start is the ST1 which generates 1.1 units/min. So to power your antenna you need around 10 panels facing the sun. Fitting this much on a single satellite makes for a pretty big satellite. The smallest I've managed able to power an antenna like this had a fueled mass of 5.4 t (admittedly, I could have built it with empty fuel tanks, but as long as it has to be this big I figure it might as well supply a good portion of its own delta v). To make a higher orbit satellite with a dish (say the Comms DTS-M1) the smallest satellite I've managed is 6.1 t and a ridiculous part count of 405 because of all the panels. I'm not convinced this even has enough power (I'm still getting it into orbit).

For comparison, early comm sats like Syncom and Intelsat had fueled masses under 100 kg. They only used surface mounted photoelectric panels, like what the early game panels are trying to model. So it would be good for realism if the power demands were such that we could build satellites in this size range and have them work.

Now of course, if you're not using ECLSS, you can rely on the power not draining when you aren't looking at the satellite, but this feels like cheating and it doesn't solve the problem of how you maneuver the satellite into place without constantly running the batteries dead.

But like I said at the start, this is a great mod!

Cheers!

[Peppe]

Okay, here's the idea for dish targeting:

Mode 1: Target planets. Has the cone of vision (dish parameter), anything in the cone connects as if the dish were an omni.

Mode 2: Target satellites. Currently it's very static and does not use the cone of vision in any way. I intend on changing this to function like above. This way it won't matter what you point at, behaviour is identical.

Mode 3: Groups. You can subscribe a number of satellites to a group, such as "LKO Sats", and you will be able to target everything in that group at once. For performance reasons, this would NOT have a cone of vision.

OPINIONS?

EDIT: Memos of a rambling fool:

• Revise targeting;
  
• Exception-robustness;
  
• Debug menu / configuration menu / satellite fixer
  
• Refactoring
  
• Eggs
  
• Crisps
  
• Find some sort of agile board to track my current issues
  
• Delete half the issues on GitHub.
  

Mode 1 and 2 being similar is a good idea. I think it will encourage using dishes with the right cone size for the job.

Mode 3 sounds cool, but complicated and might make signaling too easy. Without a cone to worry about you could use dishes to relay a signal in much more flexible arrangements. Seems to negate the above, where now you don't have to worry about picking the right dish for the job. Sizing the dish and cone angle I think makes for an interesting game-play element.

My mode 3 would look at a cone mode to fixed points around the body. Like poles and each horizon, so you can target the planet center (current mode) or the sides.

targets (x) around body (o):

-x-

xox

-x-

Maybe enable the multidish range bonus by default. So if you need a cone angle of 25 degrees, but out 200Mm, you can do it with 2-3 dishes depending on how you scale the multidish bonus.

Someone many pages back also thought being able to target the zenith from the surface in cone mode would be good. Not sure if the cone rotating on a surface might not update if the ship is inactive.

If the mode 1 changes don't filter by the target, so truly anything in the cone will connect I think that will give us a way to relay through moons. If the moon can also talk to the ship and the planet, when it crosses the signal path it will not require a re-target to maintain the signal -- assume the ship's cone can see a relay sat around the moon?

Assuming you have relays on all planets and moons, then moons will not block the signal.

Only scenario that leaves to lose signal is something large like the sun/jool, where you might not be far enough away for your cone to hit a relay (planet or sat) without targeting away from kerbin. A dynamic way for the sat in this situation when kerbin goes behind the sun/jool to try to relay to a backup planet or list of backups -- until kerbin is available again might be good. Struggle to find a solution that does not make it too easy.

If that sounds too easy maybe you just make the player bring a backup dish and they have to manually point to alternate relay path around the sun before they lose signal if they are worried about signal loss through the direct path.

[Cilph]

The only photoelectric panel available at the start is the ST1 which generates 1.1 units/min.

You mean 0.75 units/s on the first available solar panel. I've already halved the consumption twice (quartered? quadr-alved?)

Edited January 24, 2014 by Cilph

[TheDude]

Greetings,

Option #1 and #2

These options don't make much sense to me. Dish antennas have very high gain and are meant for point-to-point long range connections and they work very well in that regard. Omni Antennas are meant to cover large areas and talk to anything in those areas. They too work very well in that regard. Having a dish talk to __anything__ that's in range (act as an omni) goes against the very idea of how a dish is suppose to work. To me this just breaks the entire mod. To me it allows for bad design. If that's the case let's just have one omni antenna with rediculous range to connect to everything else.

Option #3

This I can see having some use. If a dish can't connect with its target then it will try another target in the list until a connection is made. This will solve some problems with satellites going behind plantets and will give some redundancy to the communication network. I don't think it should "target everything" but instead go though the list one-at-a-time until a connection is made or it runs out of power.

What is the driving force behind the changes? I've been running the patched DLL on 0.23 and have an extensive network deployed through the Kerbal system and honestly, I can't break the damn thing. Everything is working exactly as expected. There has been communication failures but EVERY ONE of them has turned out to be my fault from poor design.

My only complaint is I feel the satellite and omni ranges are bit out of balance and could be adjusted somewhat. There is a lot of short and long range stuff but not much in between. Id' be happy to submit a proposal if you're interested.

Best regards,

The Dude

[Cilph]

Greetings,

Option #1 and #2

These options don't make much sense to me. Dish antennas have very high gain and are meant for point-to-point long range connections and they work very well in that regard. Omni Antennas are meant to cover large areas and talk to anything in those areas. They too work very well in that regard. Having a dish talk to __anything__ that's in range (act as an omni) goes against the very idea of how a dish is suppose to work. To me this just breaks the entire mod. To me it allows for bad design. If that's the case let's just have one omni antenna with rediculous range to connect to everything else.

Option #3

This I can see having some use. If a dish can't connect with its target then it will try another target in the list until a connection is made. This will solve some problems with satellites going behind plantets and will give some redundancy to the communication network. I don't think it should "target everything" but instead go though the list one-at-a-time until a connection is made or it runs out of power.

What is the driving force behind the changes? I've been running the patched DLL on 0.23 and have an extensive network deployed through the Kerbal system and honestly, I can't break the damn thing. Everything is working exactly as expected. There has been communication failures but EVERY ONE of them has turned out to be my fault from poor design.

My only complaint is I feel the satellite and omni ranges are bit out of balance and could be adjusted somewhat. There is a lot of short and long range stuff but not much in between. Id' be happy to submit a proposal if you're interested.

Best regards,

The Dude

"Anything in range" is a cone of 0.5 degrees on a range from Kerbin to Duna. Most dishes are balanced to have a cone with the width of Kerbin-Mun at max range, giving some use to the cheaper/worse dishes in lower ranges.

As for your comment on Option 3: the way I proposed is the easiest way to implement it, just by adding the edges to the network graph and having the pathfinder sort it out. Limiting it to one connection brings up a load of other issues related to priority.

[Rokker]

Greetings,

Option #1 and #2

These options don't make much sense to me. Dish antennas have very high gain and are meant for point-to-point long range connections and they work very well in that regard. Omni Antennas are meant to cover large areas and talk to anything in those areas. They too work very well in that regard. Having a dish talk to __anything__ that's in range (act as an omni) goes against the very idea of how a dish is suppose to work. To me this just breaks the entire mod. To me it allows for bad design. If that's the case let's just have one omni antenna with rediculous range to connect to everything else.

Option #3

This I can see having some use. If a dish can't connect with its target then it will try another target in the list until a connection is made. This will solve some problems with satellites going behind plantets and will give some redundancy to the communication network. I don't think it should "target everything" but instead go though the list one-at-a-time until a connection is made or it runs out of power.

What is the driving force behind the changes? I've been running the patched DLL on 0.23 and have an extensive network deployed through the Kerbal system and honestly, I can't break the damn thing. Everything is working exactly as expected. There has been communication failures but EVERY ONE of them has turned out to be my fault from poor design.

My only complaint is I feel the satellite and omni ranges are bit out of balance and could be adjusted somewhat. There is a lot of short and long range stuff but not much in between. Id' be happy to submit a proposal if you're interested.

Best regards,

The Dude

The way he is suggesting 1 and 2 are actually realistic, and much more common in the real world than the 3rd (which is similar to something i suggested back in the 180s-190s pages i think, as a suggestion on how to create a failsafe that doesnt make RT too easy.) All dishes create cones, and typically anything within those cones, capable of receiving that frequency would be possible to communicate with. this is the entire basic idea behind dishes. whe you point the dish at an area, such as a part of space, anything that passes through tthe cone surrounding that area, within range, will be able to communicate.

As for your mid-range suggestion, i disagree wholeheartedly. It starts off with an antenna to get you into orbit, then one to get you to a sub-geostationary orbit, then to the moon and minmus, then the next largest one gets you to duna, the closest celestial body, etc. the whole thing is based on its overall usefulness. there is no use or reason for something like a mid range antenna as it would not reach any locations.

Edited January 24, 2014 by Rokker

[TheDude]

Ummmm.... OK..... I think I get what you're saying. It's the "connects as if the dish were an omni" that's kinda throwing me.

I guess the best analogy that I can come up with is satellite TV. The orbiting satellite points its dish "at the planet" where the cone covers a given area. The small dish bolted to the side of your house still has to point at, or targets, the satellite to get a signal. They both connect and you can watch the Simpsons.

Am I close?

As far as option 3, I think we're thinking the same thing. I'm guessing one satellite would target "the group" which would consist of multiple satellites somewhere. Would that automatically make every satellite in that group target the single satellite or would you need to manually do the targting?

What about one satellite group (Group A) target another satellite group (Group ? It's not a feature I want but I can see it come up sometime in the future. I'd bet that would get really messy very quickly.

Lastly, I know it's been brought up before but range indicators in the map view would be very helpful. Not only from a planning standpoint but also from a troubleshooting/support standpoint as well. I'd imagine it would help eliminate many of the "Why doesn't my satellite connect?" questions.

Best regards,

The Dude

As far as Option

[Rokker]

Ummmm.... OK..... I think I get what you're saying. It's the "connects as if the dish were an omni" that's kinda throwing me.

I guess the best analogy that I can come up with is satellite TV. The orbiting satellite points its dish "at the planet" where the cone covers a given area. The small dish bolted to the side of your house still has to point at, or targets, the satellite to get a signal. They both connect and you can watch the Simpsons.

Am I close?

As far as option 3, I think we're thinking the same thing. I'm guessing one satellite would target "the group" which would consist of multiple satellites somewhere. Would that automatically make every satellite in that group target the single satellite or would you need to manually do the targting?

What about one satellite group (Group A) target another satellite group (Group ? It's not a feature I want but I can see it come up sometime in the future. I'd bet that would get really messy very quickly.

Lastly, I know it's been brought up before but range indicators in the map view would be very helpful. Not only from a planning standpoint but also from a troubleshooting/support standpoint as well. I'd imagine it would help eliminate many of the "Why doesn't my satellite connect?" questions.

Best regards,

The Dude

As far as Option

To my best understanding, yes that is what he is suggesting with options 1 and 2, except in the cases where it is an omni to dish connection in which the antenna can connect with a dish as long as it is in range and within the dish's cone. As for option 3, that question actually made me thing, but i believe what it would be is something like either the Active Vessel option or it would simply rely on the "within the cone" logic put forth in options 1 and 2. Perhaps Cliph can clarify as I can't speak for him of course.

[cfds]

Personally, I like the Group Targeting idea. It would absolve me of the need to construct some four-dish satellite for the Jool-System

[Sma]

Mode 3: Groups. You can subscribe a number of satellites to a group, such as "LKO Sats", and you will be able to target everything in that group at once. For performance reasons, this would NOT have a cone of vision.

So far it all sounds good to me, however with mode 3, how would this work if you have a dish on one or all of the sats that points out of the LKO network, say to Duna or Jool for instance? Maybe I'm just missing something as I have a bit of a cold or something and my brain isn't functioning quite at 100% (not like thats much different from normal anyway )

[Sax Man Aeronautics]

There's no remotetech2 config file in the RT2 folder.

[Rokker]

There's no remotetech2 config file in the RT2 folder.

RemoteTech_Settings ? Have you run the game with RemoteTech2 installed at least one time?

[Sax Man Aeronautics]

Oh, ok. I downloaded RT2 and I didn't see a config. I just ran the game and the cfg is there. Thanks!

[Rabada]

I don't have a communotron 32, only the 16... Did I accidentally delete it or was it removed from the mod?

[AdmiralTigerclaw]

Okay, here's the idea for dish targeting:

Mode 1: Target planets. Has the cone of vision (dish parameter), anything in the cone connects as if the dish were an omni.

Mode 2: Target satellites. Currently it's very static and does not use the cone of vision in any way. I intend on changing this to function like above. This way it won't matter what you point at, behaviour is identical.

Mode 3: Groups. You can subscribe a number of satellites to a group, such as "LKO Sats", and you will be able to target everything in that group at once. For performance reasons, this would NOT have a cone of vision.

OPINIONS?

EDIT: Memos of a rambling fool:

• Revise targeting;
  
• Exception-robustness;
  
• Debug menu / configuration menu / satellite fixer
  
• Refactoring
  
• Eggs
  
• Crisps
  
• Find some sort of agile board to track my current issues
  
• Delete half the issues on GitHub.
  

Mode 1 with the tweak to make mode 2 work more like Mode 1 in utilizing the cone on the sat are pretty good.

Mode 3 makes no sense to me. I'd have to understand what this is mimicking to understand how this mode works.

I restate a suggestion I made a while back. An 'idle' mode on a dish that automatically locks up with the first outbound link that tries to contact it. (Assuming of course, range criterion are passed on both units.)

That way, even if you mess up link configuration, you can use an established vessel to 'call' the one with the listening dish.

I explained the concept before, but the dish is effectively listening on a special multi-directional receiver for a low-power timing pattern. And that receiver can tell the dish where to turn to establish the actual full comm-link.