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

[Pirsig]

@starstrider42:

While it may be easy to read other configs, I won't disagree. I do believe that at least the main folder name of the mod and the :FOR[*] should be the same, that's an even easier thing to see.

While I know of nothing that mods RT before, I know at least RealismOverhaul modifies a lot of what RT touches afterwards. With the :FOR[RemoteTech*] tag, because of naming conventions, "Rem" comes after "Rea" and so therefore, we will have to specifically make new configs for parts touched by RemoteTech with AFTER:[RemoteTech*] in order make changes to distances/power/etc. If that's the way it is, so be it, we'll make the changes. I'm still in the boat of leave things alone.

My understanding is that you should be running :AFTER[RemoteTech2] (or whatever) anyways. :FOR is for the author of said mod to put patches for that mod.

[Starstrider42]

Why should this be yet another mod that doesn't follow the defined naming conventions? MM has defined naming conventions for this, we should follow them.

*Deletes lengthy and no-longer-relevant quote* Aha, found the post you were referring to. Fine. But, for the record, the ModuleManager OP did not include the version 2 capabilities at the time that I wrote that patch, and the post that introduced them did not mention any convention or priority for :FOR names.

I'd still prefer to keep the mod name as RemoteTech, so I'll see if the others are game for a DLL rename.

At least on the master branch that's on git right now, everything that's not the new FASA configs runs in :FIRST because they don't have any :FOR statement at all.

With the exception of the FASA configs, which were misplaced, everything on master is the previous version. You want the develop branch (yes, it's an unnecessarily confusing system, and yes, we'll be changing it after the next release).

That's not the point, what if someone finds a reason to? I totally admit the likelihood is low, but why make it harder if someone does want to when there's no reason for it?

That was in reply to RedAV8R's claim that RemoteTech must be run before all other mods. I know that it wasn't your point.

[Pirsig]

*Deletes lengthy and no-longer-relevant quote* Aha, found the post you were referring to. Fine. But, for the record, the ModuleManager OP did not include the version 2 capabilities at the time that I wrote that patch, and the post that introduced them did not mention any convention or priority for :FOR names.

I figured, and that's why I was just offering to do it, but since I was working off the master branch I had no idea you were already addressing this.

I'd still prefer to keep the mod name as RemoteTech, so I'll see if the others are game for a DLL rename.

This seems like the best solution as things stand.

With the exception of the FASA configs, which were misplaced, everything on master is the previous version. You want the develop branch (yes, it's an unnecessarily confusing system, and yes, we'll be changing it after the next release).

That's totally my bad then, I didn't realize.

Edited September 30, 2014 by Pirsig
typing fail

[lipatden]

Hello all

Is there any plan to provide for commands in the Flight Computer that survive vessel switches? I am thinking of a more advanced scenario where a vessel hibernates and wakes up once per hour to receive commands to save power, but before that happens RT would need to implement: Queued commands that are remembered between active vessel switches; and a generic "sleep" and "wake" function (turn on/off antennae) that doesn't necessarily depend on action groups (though this is how I'm doing active-vessel power management now).

I often find I need to execute a mid-orbit correction while out of range, and while I can happily schedule a burn for e.g. 2 days past going out of contact range, if I have something else that needs attention in the meantime I'm done for.

Any thoughts?

[Drew Kerman]

Hello all

Is there any plan to provide for commands in the Flight Computer that survive vessel switches? I am thinking of a more advanced scenario where a vessel hibernates and wakes up once per hour to receive commands to save power, but before that happens RT would need to implement: Queued commands that are remembered between active vessel switches; and a generic "sleep" and "wake" function (turn on/off antennae) that doesn't necessarily depend on action groups (though this is how I'm doing active-vessel power management now).

I often find I need to execute a mid-orbit correction while out of range, and while I can happily schedule a burn for e.g. 2 days past going out of contact range, if I have something else that needs attention in the meantime I'm done for.

Any thoughts?

This should be possible with data saved to the .sfs file, but where this stands on the RT2 developer's ToDo list I'm not sure. Check the Issues tracker on the GitHub page. If it's not there, add it.

For now tho, a bit of manual save file editing will work. Make a backup of your current .sfs file. Load the game and queue the commands, let the game run and the maneuver perform. Then, exit to the space center and watch the clock tick over to something like 09:45:00 Day 143 (for example) and hit Esc. Save your game under a new filename. Now bring up the Esc menu again and reload your original game from the backup. Do what you need to do with other missions until you reach 09:45:00 Day 143 and exit to the main menu. Now just copy over the VESSEL structure from the custom save into your normal save. I "time hop" like this often. Works well.

[lipatden]

...with data saved to the .sfs file... save file editing ... backup of your current .sfs file ... queue the commands, ... maneuver ... exit to the space center ... Save your game ... bring up the Esc menu again ... Do what you need to do ... exit to the main menu ... copy ... custom save

Works well.

I respect your dedication. Holy mackerel that's a lot of steps!

It does unfortunately break the ingame experience, and as Squad pointed out in the 0.25 notes even Return to Space Center should be in-game (as opposed to ESC). I'll track down the issue list on Github, thanks!

[Superfluous J]

What Lodestar said. Your reflectron KR-7 Probe should point to "Kerbin" so as to pick up any satellites in that SOI that are within the angle of the cone. The satellites that you have as acting relays should either point to "current Vessel", the Reflectron Probe, or in this case "Kerbol" (sun). The Sun setting isn't very good I don't think as the SOI area is significantly larger than any area the relay probe cones will provide.

Personally, I favor setting the Probe vessel focus on Kerbin and 2 of my relays around Kerbin to that probe.

Okay I'm about to ditch RemoteTech. I redid my "test" mission and what you said above worked. Yay!

I then sent my Duna mission. Exact same setup as above except it's got a KR-14 to talk to the two KR-14s in the 1,000km orbit satellites. I pointed it at Kerbin. It's activated. The probe has power. But it has no connection and is yet another dead hunk of metal flying through extrakerbin space.

I see no cone, but again I'm not sure under what circumstances a cone should appear. What am I doing wrong NOW?

[undercoveryankee]

Okay I'm about to ditch RemoteTech. I redid my "test" mission and what you said above worked. Yay!

I then sent my Duna mission. Exact same setup as above except it's got a KR-14 to talk to the two KR-14s in the 1,000km orbit satellites. I pointed it at Kerbin. It's activated. The probe has power. But it has no connection and is yet another dead hunk of metal flying through extrakerbin space.

I see no cone, but again I'm not sure under what circumstances a cone should appear. What am I doing wrong NOW?

When you have display of cones turned on, is there a line from the Duna probe to the center of Kerbin? That's the normal appearance of a cone that just isn't far enough out yet. Since, per your handy chart, the KR-14 is too narrow to cover keosynchronous from Duna orbit at Duna's closest approach to Kerbin, you may just not be far enough out for your KR-14 to cover your 1000km relays.

Since I've never had the patience to wait for a probe to get several million kilometers out before I can control it, I've always used 88-88s in pairs, one targeting each Kerbin-orbit relay directly.

[Superfluous J]

When you have display of cones turned on, is there a line from the Duna probe to the center of Kerbin? That's the normal appearance of a cone that just isn't far enough out yet. Since, per your handy chart, the KR-14 is too narrow to cover keosynchronous from Duna orbit at Duna's closest approach to Kerbin, you may just not be far enough out for your KR-14 to cover your 1000km relays.

Since I've never had the patience to wait for a probe to get several million kilometers out before I can control it, I've always used 88-88s in pairs, one targeting each Kerbin-orbit relay directly.

I'll send it farther, but as everything's in the same plane wouldn't it get small windows of being able to talk when the 1000km satellites were in a line between my probe and Kerbin?

I fiddled with those 4 icons in the lower left and one of them showed a grey line between my probe and Kerbin. I guess I'll wait a bit and see if it just starts working.

[Starstrider42]

Hello all

Is there any plan to provide for commands in the Flight Computer that survive vessel switches? I am thinking of a more advanced scenario where a vessel hibernates and wakes up once per hour to receive commands to save power, but before that happens RT would need to implement: Queued commands that are remembered between active vessel switches; and a generic "sleep" and "wake" function (turn on/off antennae) that doesn't necessarily depend on action groups (though this is how I'm doing active-vessel power management now).

I often find I need to execute a mid-orbit correction while out of range, and while I can happily schedule a burn for e.g. 2 days past going out of contact range, if I have something else that needs attention in the meantime I'm done for.

Any thoughts?

It is on the list: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/32, and I personally would like to see it because I tend to play with a lot of simultaneous flights.

However, since we haven't had too many requests for it (you're the first since the new thread opened, I think) it's a lower priority than e.g. better network troubleshooting, with which we already have our hands full.

Okay I'm about to ditch RemoteTech. I redid my "test" mission and what you said above worked. Yay!

I then sent my Duna mission. Exact same setup as above except it's got a KR-14 to talk to the two KR-14s in the 1,000km orbit satellites. I pointed it at Kerbin. It's activated. The probe has power. But it has no connection and is yet another dead hunk of metal flying through extrakerbin space.

I see no cone, but again I'm not sure under what circumstances a cone should appear. What am I doing wrong NOW?

I'm sorry to hear you're having trouble. The cone should appear whenever the second icon on the lower-right panel shows a planet icon instead of an "X" (and when the antenna is pointed at a planet). But the cone for the KR-14 is quite narrow (0.04°) so the odds of you hitting one of your satellites from just outside Kerbin's SoI (90,000 km away, or a 63 km diameter cone) are quite low. By the time you actually need to make a course correction to hit Duna, though, it will be a lot wider. As undercoveryankee said, one workaround is to point the dish at a specific satellite until you get farther away.

Although it won't appear in the next release (at the moment it only works in one specific case), I've started work on some text-based reporting for, among other things, how wide your cone is: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/2#issuecomment-57039242. Feel free to drop some feedback on that thread.

[AetherGoddess]

[...] As undercoveryankee said, one workaround is to point the dish at a specific satellite until you get farther away.

that's super cool tech, and i am always for more information.

I'd like to register an related possibility: how about a grouping mechanism in the target selector? so we could mark 4 or 5 satellites and designate them collectively as "the Extra-kerbal snack logistics reporting relay system" and tell our automatic snack delivery drone to point it's one dish at that collection, and it would seek to through the satellites in that group whenever it got "no connection" looking for a nearby, in range, powered, unexploded, non-kraken relay that is pointing in the correct direction? that would certainly help me with my goal of creating a trans-kerbol-onian message bus. this might help with the guy who was overburdened with relays, since anything targeting to a relay group could be declared as end node and ignored for graph trees and routing decisions.

[Starstrider42]

Quick poll: if you saw the following button on RemoteTech's map view toolbar, what would you think it did?

I'd like to register an related possibility: how about a grouping mechanism in the target selector? so we could mark 4 or 5 satellites and designate them collectively as "the Extra-kerbal snack logistics reporting relay system" and tell our automatic snack delivery drone to point it's one dish at that collection, and it would seek to through the satellites in that group whenever it got "no connection" looking for a nearby, in range, powered, unexploded, non-kraken relay that is pointing in the correct direction?

That's not too different from some of the suggestions floated in this discussion: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/107.

TL;DR: while we're all open to different ways to make dish targeting simpler, we also all have different views on what would make the game too simple, and we never agreed on a single scheme that would make things easier while keeping the game balanced.

Edited October 2, 2014 by Starstrider42

[Drew Kerman]

Quick poll: if you saw the following button on RemoteTech's map view toolbar, what would you think it did?

Something related to dish cones, but that would be my best guess. If it's a cone angle display I'd suggest making the angle mark larger

[AetherGoddess]

Quick poll: if you saw the following button on RemoteTech's map view toolbar, what would you think it did?

Toggle Antenna cone display. possibly antenna cone helper. maybe put a target in the big open space in the middle if it's a dish targeting aid.

That's not too different from some of the suggestions floated in this discussion: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/107.

most of these discussions revolve around a "fix my comms" button. i'm talking about a pre-planned group of satellites that can be targeted so large communications networks can be addressed as a unit. no one would accept separate networks for each website, everyone connects to "the internets" by whatever local signal is available and allows the network to do the routing work. building a network is work, and can be fun, loosing a vessel after hours of precision maneuvers because the comms relay you were targeting went behind a moon, or the next relay in the orbit is just a little outside it's envelope, so it's not quite in cone, is generally not so.

however, unlike most of the posters in that group, i like to see things completed. i'm much more interested in using RT to give me an expanded set of accomplishments to knock down in my gaming nights (i.e. Comms network covers kerbin surface: check, comms network around minimus: check, signal relays for duna: check, local relays for eeloo explorers: check, overhead comms for rovers, etc), rather then a "convert vessel to debris" minefield that must be waded.

i also play with signal delay turned off, so maybe my opinion is invalid....

[VaporTrail]

Quick poll: if you saw the following button on RemoteTech's map view toolbar, what would you think it did?

http://i.imgur.com/ATUSw4H.png

Something related to dish cones, but that would be my best guess. If it's a cone angle display I'd suggest making the angle mark larger

My first guess too... I'd think, if that were the case, a better icon would be something like this:

Wow... a 12 pixel change makes more difference than I thought it did...

Edited October 2, 2014 by VaporTrail

[mech_engr]

When using the RC-L01 Remote Guidance Unit by itself with no Kerbals on board, I'm always getting "Local Control." I thought I'm supposed to have 6 Kerbals for it to become a remote control outpost. What's going on?

[Superfluous J]

I'm sorry to hear you're having trouble. The cone should appear whenever the second icon on the lower-right panel shows a planet icon instead of an "X" (and when the antenna is pointed at a planet). But the cone for the KR-14 is quite narrow (0.04°) so the odds of you hitting one of your satellites from just outside Kerbin's SoI (90,000 km away, or a 63 km diameter cone) are quite low. By the time you actually need to make a course correction to hit Duna, though, it will be a lot wider. As undercoveryankee said, one workaround is to point the dish at a specific satellite until you get farther away.

Although it won't appear in the next release (at the moment it only works in one specific case), I've started work on some text-based reporting for, among other things, how wide your cone is: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/2#issuecomment-57039242. Feel free to drop some feedback on that thread.

No, I should be the one that's sorry (and I am). This was part of an otherwise happy-free day and it was the final straw, so to speak. I did as you suggested and fast forwarded time sufficiently into the future and indeed, the cone started appearing. I knew it wouldn't cover Kerbin until the probe was sufficiently far from the SOI, but I didn't quite realize that the cone would essentially be a line even that far out.

I actually found that button but didn't know what it did, and when I saw the line I didn't know it was actually 2 lines.

I do like that button idea you have, and think I'd have made the link between it and the cones I was expecting to see. If I may make a suggestion, instead of an X, put a circle/slash (like on "no smoking" signs) over the symbol.

Anyway, I'm back on track and liking the mod. I promise!

[ArrTeeD2]

Hi all!

I must first say this is an awesome mod!

I'm having some problems with connecting two ships using Communotron 32 antennas.

I have an orbiter in orbit around Duna with a stable connection to KSC with Reflectron KR-14.

I also have a lander attached to it. Both the orbiter and the lander have an active and powered Communotron 32 antenna. But when I decouple the lander, there is no connection to the orbiter (and thus to KSC).

Did I miss something?

[Athlonic]

Quick poll: if you saw the following button on RemoteTech's map view toolbar, what would you think it did?

That's an easy one !

Toggling the ice cream machine on/off ?

[bitbucket]

I came up with a couple of unconventional solutions when dealing with interplanetary communications and the tiny phase angles of dishes:

One, deep space relays in solar orbit:

Bit of a mess, but what's going on is that I have two deep space relays (the station icon ships), a mission orbiting Eve waiting on a return window, a probe around Moho, a flotilla of ships heading for Duna, and a probe heading out to Jool.

I launched two ships with a bunch of dishes (enough to point at every planet and then a couple more), then aimed to place them on pseudo-Lagrange points in Kerbin's orbit (yes, I know n-body isn't a thing) by putting them on solar orbits with 5/6 and 7/6 of Kerbin's orbital period, then re-circularizing their orbits when they come back to Kerbin's orbital distance. Interplanetary missions then point at one of the L4/L5 relays to stay in contact with Kerbin once they're outside omnidirectional antenna range, but too close for direct dish communication with Kerbin to be practical. Better a delay of a minute or two than no contact at all.

Two, ground stations:

Two of these abominations sit 120° east and west of KSC at 46° and 166° east longitude (the 166°E had to go about 15° south of the equator because ocean), with a third at KSC itself over by the tracking station. They took 20 parachutes to land safely and are running off a reactor part from a discontinued parts pack because that many dishes uses up a LOT of juice. As you might expect, they've got a dish pointing at every planet, the L4/L5 arrays, and a couple spare dishes to point at active interplanetary missions.

And the local neighborhood before I started launching stuff out of the Kerbin system:

There's a ring of six commsats in a 90 minute orbit to cover everything near Kerbin, uplinks to landed craft on Mun and Minmus, and three geosynchs over the ground stations. It's basically a Deep Space Network style setup; at least one and often two ground stations will always have a line of sight to anything in the solar systemâ€â€unless it's behind the sun, and then the L4/L5 relays have that covered.

[ArrTeeD2]

Hi all!

I must first say this is an awesome mod!

I'm having some problems with connecting two ships using Communotron 32 antennas.

I have an orbiter in orbit around Duna with a stable connection to KSC with Reflectron KR-14.

I also have a lander attached to it. Both the orbiter and the lander have an active and powered Communotron 32 antenna. But when I decouple the lander, there is no connection to the orbiter (and thus to KSC).

Did I miss something?

Ok I found the problem. I have a relay sat in KSO with two KR-14. Target on one was set to Duna and the other to Active vessel. I disabled the one with 'Active vessel' and it works fine.

But shouldn't the one with the 'Duna' target setting still keep the connection?

[undercoveryankee]

When using the RC-L01 Remote Guidance Unit by itself with no Kerbals on board, I'm always getting "Local Control." I thought I'm supposed to have 6 Kerbals for it to become a remote control outpost. What's going on?

Do you have any non-stock command pods or probe cores on the vessel?

[Kitspace]

Hello.

How can I possibly use the built in attitude computer interface and the task planner on a manned vessel with local control?

Just I usually think of it as a convenient autopilot thing.

Can I make a vessel that would be able of both local and remote control depending on whether it is manned currently?

Thank you!

[undercoveryankee]

Hello.

How can I possibly use the built in attitude computer interface and the task planner on a manned vessel with local control?

Just I usually think of it as a convenient autopilot thing.

Can I make a vessel that would be able of both local and remote control depending on whether it is manned currently?

Thank you!

Yes. If your vessel has both a probe core and a manned pod, the probe core should allow you to access the flight computer while the manned pod is providing local control.

[Starstrider42]

That's an easy one !

Toggling the ice cream machine on/off ?

Why would your ship need an ice cream machine? Minmus is right there.

Thanks for the feedback, everyone -- as most of you guessed, it was supposed to be a more intuitive replacement for the planet icon in the current toolbar. With VaporTrail's permission, I'd like to incorporate their version into RT.

Ok I found the problem. I have a relay sat in KSO with two KR-14. Target on one was set to Duna and the other to Active vessel. I disabled the one with 'Active vessel' and it works fine.

But shouldn't the one with the 'Duna' target setting still keep the connection?

That's correct -- there is absolutely no case where turning off a dish should cause you to have a connection that you didn't before. If you haven't changed the save game yet to the point where it's impossible to reproduce the problem, can you please post it and a bug report to the issue tracker?

Edited October 3, 2014 by Starstrider42