[0.20] RemoteTech: Relay Network – V 0.5.0.1

[csiler2]

To each their own. Pre-programming a probe to launch/fly/land on the Mun sounds really exciting to me.

Anyway it sounds like you aren't using RemoteTech right, you can already use MechJeb to plan maneuvers and use RemoteTech to execute them. It just goes finicky when you try to let MechJeb fly everything on autopilot at long distances.

You are correct, I am not currently using RemoteTech. I've seen it in a lot of Let's Play videos, but didn't know what it was until recently. I'm too lazy to back-date my game to give it a go and would rather wait to see where RT 2 goes first.

Does RT 2 beta makes MechJeb finicky or the original RT?

I do use mechjeb and find it really useful for mundane actions, like routine launches of proven vehicles. I think I would also find the interface useful as a roundabout way of 'programming' my spacecraft without having to sit down and write out code.

I agree with to each their own as a general sentiment about mods. I recognize that RT is geared towards players that want a realistic depiction of remote space exploration, and I want some of that, just not all of it

[Ralathon]

Oh right, signal delay. Silly speed of light. Does anybody know if players will be given the option to toggle the delay and act as if transmissions are instant? I don't mind having delay, but I'm not to keen on trying to hand-program landing sequences, etc. It would be nice to have the option to use Mechjeb in conjunction with RT to plan maneuvers ahead of time while the spacecraft is in radio contact, though it seems the MJ + RT compatibility is a bit... contentious right now.

I'm a bit on the fence about whether or not I will use the mod once it's out of beta, but I'll keep my eye on it. I like the idea of having to build a communications network to use my probes, I'm just not too keen on having to figure out how to perform orbital maneuvers or land them with hand-written programs.

You can simply crank up the speed of light by a factor 10000 or something in the RemoteTech config file. That way you'll be able to directly control any craft with negligible delay.

[Toyotawolf]

You can simply crank up the speed of light by a factor 10000 or something in the RemoteTech config file. That way you'll be able to directly control any craft with negligible delay.

Cool, that will be useful

[Cypherwraith]

RT is great, but when something (inevitably) goes wrong on a probe that's orbiting Eeloo, the 8-minute time delay between input and response can be a problem. Granted, that's realistic.

[Sma]

Oh right, signal delay. Silly speed of light. Does anybody know if players will be given the option to toggle the delay and act as if transmissions are instant? I don't mind having delay, but I'm not to keen on trying to hand-program landing sequences, etc.

From my understanding, if you setup a command station, say...around Duna with at least 3 Kerbals there won't be any time delay. Also with the delay, I don't think planning maneuvers would be much different than usual at least for those not using MJ. You just setup the node, note down the t- time, and the burn time and put that into the RT2 system. At least that's how I'm imagining it. I've never used it or really seen much of a video on it though so I'm just guessing from the little bit I have seen.

Landing or docking on the other hand, that's another story, I haven't figured out how that'll work that one out yet.

[nhnifong]

Anyone know if it's possible to schedule a dish to re-open after a delay? For example, you need to close deployable dishes during aerobraking maneuvers, but if you close your only IP dish, you are out of contact, and can't re-open it.

[astropapi1]

How do you guys perform a landing with a 8-minute delay?

[Asdpyro]

I'm a huge fan of RT1 and am really excited for RT2. I have one question though. When trying to determine if a dish on a probe is within LOS, does the path look for the exact position of the dish, the "main" part (where ksp makes everything relative to) or to the center of gravity? I ask because I would like to take advantage of the new mountains and deliver com towers to many ground based positions around Kerbin. I have flown around and established many mountain ranges that can see each other. However this will be much more difficult if RT2 will be looking for visibility to the base of the tower I build rather than the top or middle even.

[Ralathon]

I'm a huge fan of RT1 and am really excited for RT2. I have one question though. When trying to determine if a dish on a probe is within LOS, does the path look for the exact position of the dish, the "main" part (where ksp makes everything relative to) or to the center of gravity? I ask because I would like to take advantage of the new mountains and deliver com towers to many ground based positions around Kerbin. I have flown around and established many mountain ranges that can see each other. However this will be much more difficult if RT2 will be looking for visibility to the base of the tower I build rather than the top or middle even.

Pretty sure it is based on center of gravity. But don't worry, mountains don't actually block LOS. the whole LOS thing is based on a perfect sphere with the radius of the planet. So you can easily dump some radio stations on mountains without worrying too much about LoS issues.

[nhnifong]

How do you guys perform a landing with a 8-minute delay?

On Duna, I've landed with the 2ish min delay from kerbin. I didn't do any burn during landing. Just had a drogue chute, normal chutes, and the strong legs. I opened all chutes upon entering the atmosphere. I was entering from low orbit and my peri was about 8km.

[xZise]

When you don't want to program your own landing program for RT2, shouldn't MechJeb do? Use the landing autopilot and only input the values once prior to landing. Of course it would be nice, if MJ would be aware of the signal delay. But as MJ is a computer on the craft, the control from MechJeb would be instant and only your actions like "point towards prograde" would be delayed.

I'm not sure how MJ exactly works, but maybe it is possible (when the developers of both plugins work together) to implement this. So when you execute an action on MJ it adds this action the RT's flight computer queue and after it's being transmitted RT's flight computer then executes the corresponding functions in MJ.

I'm going to have to correct you here and refer to an actual github post when a user asked about MJ and the response from a(one of) developer of this mod was "F&%$ MechJeb" so they aren't assumptions but it's fun you actually gave me a chance to point that out.

Apart from the rest of your discussion: It's unfair for the developers if people don't recognize that this is a playtest (aka alpha/beta?). So features aren't finished and bugs aren't fixed, so nobody could say: “I don't like that RT2 doesn't support MJâ€Â, because this mustn't be true, except the person could time travel and knows if RT2 support MJ.

Fabian

Edited August 4, 2013 by xZise

[Kimberly]

Anyone know if it's possible to schedule a dish to re-open after a delay? For example, you need to close deployable dishes during aerobraking maneuvers, but if you close your only IP dish, you are out of contact, and can't re-open it.

I don't know if it's possible currently, but I'm pretty sure that sort of thing is planned to be possible in the full release. The probe wouldn't be able to receive any new commands, but it would execute any queued ones. And ideally, you could send new commands while it was out of contact, and the probe would receive it as soon as it opened its dish.

[Corax]

ideally, you could send new commands while it was out of contact, and the probe would receive it as soon as it opened its dish.

Ideally, it would not receive commands as soon as it opened its dish if the dish is closed when the transmission arrives. You can queue received commands, but you can't queue radio waves to be received when it's convenient. You might time your transmission to coincide with the reopening of the dish, if (when) that is possible, but that's about the only way for the scenario you described to be possible.

[xZise]

[…]You might time your transmission to coincide with the reopening of the dish, if (when) that is possible, but that's about the only way for the scenario you described to be possible.

That would be a nice addition. (Of course to do that, the flight computer needs to know when the dish opens)

Fabian

[Kimberly]

Ideally, it would not receive commands as soon as it opened its dish if the dish is closed when the transmission arrives. You can queue received commands, but you can't queue radio waves to be received when it's convenient. You might time your transmission to coincide with the reopening of the dish, if (when) that is possible, but that's about the only way for the scenario you described to be possible.

You can queue up to one command for an indefinite period by sending a continual signal to the planet, surely? The probe would receive it whenever it opened its dish, assuming enough time had passed between when the signal started being broadcast and the opening.

[Corax]

You can queue up to one command for an indefinite period by sending a continual signal to the planet, surely? The probe would receive it whenever it opened its dish, assuming enough time had passed between when the signal started being broadcast and the opening.

"timing the transmission to coincide..." with brute force

Yes, that could certainly be an option. You will probably need a way to make certain the command is executed only once, though...

Edited August 4, 2013 by Corax

[Mitrophan]

When set RT2 soon as I ceased to work properly all decouplers?

[csiler2]

You can simply crank up the speed of light by a factor 10000 or something in the RemoteTech config file. That way you'll be able to directly control any craft with negligible delay.

I would call that an adequate solution!

From my understanding, if you setup a command station, say...around Duna with at least 3 Kerbals there won't be any time delay. Also with the delay, I don't think planning maneuvers would be much different than usual at least for those not using MJ. You just setup the node, note down the t- time, and the burn time and put that into the RT2 system. At least that's how I'm imagining it. I've never used it or really seen much of a video on it though so I'm just guessing from the little bit I have seen.

Landing or docking on the other hand, that's another story, I haven't figured out how that'll work that one out yet.

Landing/docking is why I would want to use Mech Jeb. I just tell it what I want and it operates the spaceship as if I'd written the program using RT.

I'm not keen on the idea of setting up remote stations ahead of my probes because it doesn't seem very thematic to send a manned mission first and then a robotic mission. It defeats the purpose of sending a low-cost unmanned mission first.

Ralathon's tip is a good workaround for dealing with signal delay in case mechjeb compatibility doesn't happen and I don't want to program in RT. I'll just pretend it's subspace transmissions like in Star Trek

[CAPFlyer]

I'm going to have to correct you here and refer to an actual github post when a user asked about MJ and the response from a(one of) developer of this mod was "F&%$ MechJeb" so they aren't assumptions but it's fun you actually gave me a chance to point that out.

Really?

Guess you and I are looking at two different bug trackers -

https://github.com/Cilph/RemoteTechExtended/issues/15

https://github.com/Cilph/RemoteTechExtended/issues/24

Both of these clearly show that MechJeb compatibility will continue to be supported as much as possible and that they are trying to make them work together. The problem is not with RT though. It's the fact that the MechJeb crew has gone almost silent on any of the public forums making collaboration much harder.

The only time I've read either developer say something along your lines is that they've stated that the RT flight computer will not ever be as advanced as MechJeb and told people to stop asking them to make it that way.

Edited August 4, 2013 by CAPFlyer

[PDCWolf]

-nevermind me-

Edited August 4, 2013 by PDCWolf

[G Wave]

So I was attempting to test rover stuff in RT2 and noticed something. Shouldn't a command module of 3+ crew act like a mission control? I tried sending them to the mun to deploy / control a rover, and kept getting 'no signal'. I guess ill need a whole network for that, huh?

[nhnifong]

So I was attempting to test rover stuff in RT2 and noticed something. Shouldn't a command module of 3+ crew act like a mission control? I tried sending them to the mun to deploy / control a rover, and kept getting 'no signal'. I guess ill need a whole network for that, huh?

Such a ship will act like a mission control if it has a RemoteCommand module. And this is noticable when you're flying some other craft that can receive a signal from it.

When you're flying the 3 manned ship itself, it will try to connect to some other command center, but where or not it succeeds it a non-issue because you have local control.

I'm not keen on the idea of setting up remote stations ahead of my probes because it doesn't seem very thematic to send a manned mission first and then a robotic mission. It defeats the purpose of sending a low-cost unmanned mission first.

I like to play with the additional constraint that command stations have to be grounded. First I set up a limited constellation of about 4 satellites and a 5th interplanetary relay in a high orbit, then I send a manned command center and land it. After that it's possible to land robotic missions.

Edited August 5, 2013 by nhnifong

[G Wave]

Sorry to be a sad-sack if it's not supposed to be posted here, but I haven't found much literature regarding the topic of how RT really talks to its self, so allow me to ask 3 questions VIA visual aid.

1. Do you need dishes at both ends in RT2 for communication.

2. Does the range on OMNI antennas stack? (Shown by KSC and a sat.)

3. Do Sat's targeted at a planet or anything work in a arc? or are they pin-point accuracy.

Thanks for answering these, and maybe this can be linked to in case the questions pop up again.

[Dappa]

Sorry to be a sad-sack if it's not supposed to be posted here, but I haven't found much literature regarding the topic of how RT really talks to its self, so allow me to ask 3 questions VIA visual aid.

*big image*

1. Do you need dishes at both ends in RT2 for communication?

2. Does the range on OMNI antennas stack? (Shown by KSC and a sat.)

3. Do Sat's targeted at a planet or anything work in a arc? or are they pin-point accuracy.

Thanks for answering these, and maybe this can be linked to in case the questions pop up again.

1. No, Dish to omni works fine.

2. No, the range doesn't stack, it's averaged.*/**

3. Targeting another planet should connect anything in it's Sphere Of Influence, as long as it's not up in the hierarchy.

*Note that there's currently a bug where satellites not in your scene often have a range of about 0km (or 2km?), which brings the range between it and the vessels in the active scene, down to half what you expect it to be. It also makes connections that are not with your active vessel or KSC, almost impossible.

**KSC has a range of 8Mm.

Edited August 5, 2013 by Dappa
Uncovered new facts

[NeoMorph]

There is something screwed up with my network... Perfect line of sight, aligned perfectly, well in range and STILL the darned sat in Mun orbit says it is out of range. I used the biggest dish out there too. I think some mod is messing with RemTech because sometimes it says it is in range and aligned and other times it doesn't. Isn't power either. I think I'm just going to have to scrap my network and try again but I haven't been able to land my remote control miner on the far side of the Mun because of this (and yeah, I am using a polar sat to relay to the far side... it's that one that keeps fritzing out for no apparent reason).