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

[velve]

Wouldn't this whole pointing problem easily be resolved if all of the directional devices were just set to omni?

This way the range of the higher tier directional antenna would still give them an advantage over the lower tier antenna, without the hassle of aiming them.

[AdmiralTigerclaw]

Wouldn't this whole pointing problem easily be resolved if all of the directional devices were just set to omni?

This way the range of the higher tier directional antenna would still give them an advantage over the lower tier antenna, without the hassle of aiming them.

Yeah... but then there wouldn't be a point to having a dish.

[DerekL1963]

The point you are failing to understand is that your solution is not something every player can or will do. Either from inadequate knowledge, such as either not understanding the mechanics or the math. Or from not wanting to go into THAT much detail in orbital drift mechanics to tune it to a knife's edge.

Then, maybe, RT2 isn't the mod for them. RT2 is like a life support mod in that respect, along with the added realism comes the burden of dealing with the added effort and complexity. (You can't have your cake and eat it too and all that.)

Seriously, with a properly designed bird (itself a task of only modest complexity, especially since tweakables came along) and a mod to give you a readout of your detailed orbital parameters, it's not that difficult to tune an orbit to the point where it only requires a touchup every Kerbal year or so. Or, if you don't want to deal with even that... the option exists to build a massively over-engineered network that's highly resistant to drift.

[Starstrider42]

I just started trying to use RT2 and I can't make any sense out of the instruction manual. The thing that seems missing is just the simple "what button does what" with the flight computer panel.

If I launch an unmanned vessel to the launchpad and want to tell the flight computer to just do one simple instruction like:

20 seconds from now, start aiming north, pitched up 85 degrees, throttle at 100%, and burn like that for 60 seconds.

I can't figure out what buttons I'm supposed to hit in what order to queue up that instruction.

First off, no matter what I type into the "delay" box, the command seems to start immediately as soon as I hit stage 1, ignoring the delay I typed in.

Secondly, no matter what I type into the pitch/hdg/roll boxes, the command still always says "Target: None".

I clearly don't get how the UI works, and I can't find the instructions for it anywhere in the manual webpage.

Thanks for your feedback. The flight computer guide was the hardest part to write, so I'm not surprised there are unclear points. I'll try to get them cleaned up for the next manual release (I'm not sure when that will be, since I'm waiting on some contributions from other developers).

As AndreyATGB said, the flight computer is really not designed for atmospheric flight. The intended use is to first turn in a desired direction, wait for it to stabilize the pointing, then start the burn.

For the delay you'd need to hit enter after typing "20" or "20s" into the box. The manual does say you need to hit enter anywhere manual delay is mentioned, but maybe I should make it bold since it's easy to miss. You'll want to double-check that the "Delay (+Signal)" display does NOT read zero. Also make sure to set it back to zero when you're done; closing the flight computer window does not turn off delay or any other flight computer feature.

Your "simple command" is actually two separate commands: "point north", and "do a 60-second burn". For the first one: type 85 for PIT, 0 for HDG, and an appropriate angle for RLL. The default of 0 will put you upside down (think space shuttle's "belly up" launch path), I'm not sure if 90 degrees is clockwise or counterclockwise from that. Then hit CUSTOM (which is probably the step you missed). Hitting CUSTOM again should turn off computer attitude control.

For the 60-second burn, I thought that part was described pretty well. More specific feedback on what was unclear would be nice. Anyway, you want to drag the slider at the lower left to 100%, then type "60" or "60 s" into the text box below it. Hitting enter while in that text box or clicking "burn" will make a burn command (scheduled at 20-second delay, if you set it as above).

If that clears things up, can you point me to specific wording in the manual that was unclear?

Edited July 1, 2014 by Starstrider42

[diomedea]

The problem is at this stage, I don't think anyone is aware of a constellation that:

1. Is relatively simple

2. Provides complete coverage of a body (particularly interplanetary)

3. Requires no maintenance, and

4. Has zero downtime.

I have a system in mind that currently provides 100% uptime to any body and requires no maintenance. But I'm stuck at providing 100% coverage on the body's surface. The connection between planets is easy enough.

But getting a connection to anywhere on the surface seems a bit tricky. At least in a way that is simple and requires no maintenance. At this stage I'm thinking of three highly elliptical orbits that are 120 degrees apart. It's not 100%, but at least when it goes dark the satellite uplink should come back fairly quickly.

Maybe the one below is not that simple, but absolutely makes for complete coverage, no maintenance, and zero downtime. Fact is, it is obtained by using 24 GNSS satellites as comms relays, each one equipped with just one Communotron 32 Omni. As everybody knows, Global Navigation Satellite Systems provide for continuous coverage with at least 4 satellites in every spot of the globe (and generally there are about 8-10 always above the horizon); so I can assure the comms capability is highly redundant. The picture shows my network around Kerbin, apart from some KSO satellites with dishes, there are those 24 satellites placed in 4 orbital planes in circular orbits at 1588 Km altitude, 55° inclination. What is surprising, is that RT2 is able to manage all those connections without too much effort (compliments to the developers ).

[DerekL1963]

Seriously, with a properly designed bird (itself a task of only modest complexity, especially since tweakables came along) and a mod to give you a readout of your detailed orbital parameters, it's not that difficult to tune an orbit to the point where it only requires a touchup every Kerbal year or so. Or, if you don't want to deal with even that... the option exists to build a massively over-engineered network that's highly resistant to drift.

To add on to this - managing drift is one of the key reasons to go all the way out to KSO (which some folks seem heck-bent on avoiding). As you go higher, a .05 second error represents proportionately less of your total orbital period and thus the drift in degrees/day goes proportionately down. An error of .1 second at 700km generates 0.0067° drift/day, the same error at KSO generates 0.0017° drift/day. (And with a modest amount of practice, getting your error below .05 second is quite doable.)

[AdmiralTigerclaw]

Actually, the proposal for snap-to orbits for constellations in the GitHub discussion would allow us to have and eat our cake. Easily. Along with delicious Pie, and ice cream.

All it takes to switch back and forth for the hardcore realists at that point is a config option to allow or disallow.

[PapkoBodrik]

this mod will work with AIES?

[Mecripp]

this mod will work with AIES?

Here http://forum.kerbalspaceprogram.com/threads/83305-Development-Resumed-RemoteTech-2?p=1240307&viewfull=1#post1240307

Or here https://dl.dropboxusercontent.com/u/72893034/RemoteTech_AIES_3.cfg

[Aedile]

The point you are failing to understand is that your solution is not something every player can or will do. Either from inadequate knowledge, such as either not understanding the mechanics or the math. Or from not wanting to go into THAT much detail in orbital drift mechanics to tune it to a knife's edge.

I understand there are super low drift satellite constellations if you do everything perfect and put a lot of time and effort into it. But you are neglecting to realize that the player base for this mod is ALREADY strapped for understanding of how to do these things to this level of precision, or are unwilling to expend that much effort. You don't need to explain to me in rigorous detail HOW to do it. I know how to do it already. But the problem isn't knowing how to do it, it's whether one feels it is worth the expended effort to do it if they also know they'll have to tweak it, no matter how long down the line. Yes, it may drift over a longer period of time than most orbits, but when it comes time to 'fix' the phase angles, does the player really want to drop whatever else they're doing to do a tedious maintenance task?

It's the dividing line between what is fun, and what is retentive tedium that becomes the problem here. I could, with some work, likely get my constellation into lockstep like a champ. I did it once before just to prove to myself it could be done, but it's not something I want to have to make a routine side task. Why would I force other players to do this?

Nobody is forcing you to do anything. Play as you see fit. This is most certainly pretty hardcore mod.

Signal is not blocked by relief (as far as I know), so 3 sat configuration works just fine, and is by far the simplest to build and maintain, and gives you almost 100% coverage. Math is pretty easy too, you need the minimum altitude - which for 3 sat is the radius of the planet. The higher away you put them, the less precise you need to be with the phase. If you put them at 750km round kirbin (2500km antenna), you'll need to be precise, or fix them often. If you put them at 2000km (you'll need the 5000km antenna), they can drift much further before the planet blocks them off.

The other thing to "calculate" is the distance between the sats. You don't want your omni antennas to go out of range. This also tells you how far they can drift apart before they disconnect. This is pretty easy calculation as well, but if you can't be bothered with trigonometry, just take the antenna range, divide it by two, and subtract the planet radius. This will give you relative clue about how much drift room you got.

I am not sure what is tedious about matching periods. As I said, 3 or 4 sats are more than enough if you put them on the right height . You say most people can't be bothered, I'd say takes much less time and effort to match 3 orbits than any alternative. Again, atmospheric issues and huge planets excluded, 3 sats will do just fine, you might get very small uncovered points on the surface of the poles, but that's about it. Adding 2 polar sats will make sure that does not happen. In reality I have found out you don't need them.

I really think I could never make the effort to add more than 5 comsats around any planet other than Kirbin, and 3 around any moon.

We are not talking about n-body mechanics here, but matching periods. Anybody who has ever made an orbital rendezvous knows the concept of orbital period, and how to increase or decrease it. Match 2 numbers, it's really as simple as that. All it requires is getting the sat in the roughly the needed distance from the other sat (which you need to do one way or another, you can just eyeball this), orienting prograde and nudging it with rcs until the 2 periods match. This is difficult or impossible to do with signal delay, but you can easily use manned mission or a node. If you are using a node, you need Pe+Ap (the sum) to match, which will cause your semi-major axis (which is half of that) and therefore period to match. Your apoaps and periaps don't need to match, your sats will oscillate, but will not drift apart if they have the same period. I cannot understand someone will go through the trouble of installing this mod, launching satellites, getting them connected, and will not bother a minute to match their periods. (Edit: you might get more precision matching semi-major in some cases)

You don't need your sats to be exactly 120 degrees apart either, your phase wiggle room will depend on your altitude.

As far as interplanetary communication goes, easiest way is solar orbit close to the planet's, with similar period. Pretty easily accomplished as well. If you manage to put it on slightly inclined orbit, you can prevent some 3rd bodies blocking it. In any case, the sun will block direct communication between 2 planets at some points, other planets and moons can cause this as well , this is most notable around Jool. I usually make network only around the moons, with 2 interplanetary sats.

In fact one of the biggest issues you will face with this mod is signal delay, and powering your active vessel. If you are building bases, you'll need some generators.

At one point had the great idea of control base on Laythe. Turned out pretty poor idea, as I did not bring generators. Night is rather long, not only that, but you'll get eclipse from Jool, Vall, Tylo.

Edited July 1, 2014 by Aedile

[Rayder]

your sats will oscillate, but will not drift apart if they have the same period.

While this is true, even the readout from MechJeb or Engineer is not accurate enough to exactly match the orbital period. Even if you get them accurate to the second, they will eventually drift. The only way to do this and have it not drift is editing the safe file, as the semi-major axis has to be exactly the same, and you will never ever be able to do it by hand, or with MechJeb.

Some people might enjoy fine tuning the orbits, and that's fine. If that's acceptable to you then more power to you. Unless your satellites are crashing or you're not getting any connection whatsoever, there's no right or wrong way to play this game or this mod.

As far as interplanetary communication goes, easiest way is solar orbit close to the planet's, with similar period.

The method I've bee using is having two satellites in a polar orbit, but offset by 90 degrees. This means that as long as you can see the planet, you can see at least one of the satellites. Both satellites will never be out of view at one time and they can't bunch together.

Interestingly, I have thought about having two satellites both leading and trailing a planet along its orbit. This would be great as you could route signals around the sun if you needed to. I didn't end up going with it though, as even these satellites will drift and eventually you will need to do some maintenance. The risk here is if you forget about it for too long, your satellites could crash into the planet. The other method is using a third planet to route your signal through

In fact one of the biggest issues you will face with this mod is signal delay, and powering your active vessel. If you are building bases, you'll need some generators.

I agree with this. As it stands, unless your planet has an atmosphere that you can aerobrake in and use parachutes, sending an unmanned probe to a distant planet with huge delays is almost impossible. You could have command centers around every planet if you wish, but it gets difficult to manage if you're using a Life Support mod.

[Drew Kerman]

Maybe the one below is not that simple, but absolutely makes for complete coverage, no maintenance, and zero downtime.

Impressive. Most impressive!

[dlrk]

How does kOS currently work with RT? Is the signal delay simply ignored with kOS?

[rabidninjawombat]

Here http://forum.kerbalspaceprogram.com/threads/83305-Development-Resumed-RemoteTech-2?p=1240307&viewfull=1#post1240307

Or here https://dl.dropboxusercontent.com/u/72893034/RemoteTech_AIES_3.cfg

Thanks for the link! Been wanting to get the AIES antennas working, i like their look alot, manually edited the part files on a couple, but this saves me alot of effort!

[Aedile]

While this is true, even the readout from MechJeb or Engineer is not accurate enough to exactly match the orbital period. Even if you get them accurate to the second, they will eventually drift. The only way to do this and have it not drift is editing the safe file, as the semi-major axis has to be exactly the same, and you will never ever be able to do it by hand, or with MechJeb.

Some people might enjoy fine tuning the orbits, and that's fine. If that's acceptable to you then more power to you. Unless your satellites are crashing or you're not getting any connection whatsoever, there's no right or wrong way to play this game or this mod.

The thing is they can drift for years before they disconnect. Unless they are too far 1 sat will cover half planet. So as long as you have 1 sat between them to connect them, you can leave them to drift very long time. The other thing is no matter your configuration, they will drift apart to some extent, so the fewer sats you got, the better. The problem will generally won't be the precision of KER, (using semimajor will give you pretty good precision for large orbits) but the sensitivity of the controls (rcs), if you have signal delay, oh well. You can use Kerbulator for high precision readout, or kOS to do it automatic semimajor match(program you'll need is just few lines), and you'll still have problem matching them completely. As lazy person, I just tend to fix them if they disconnect and I'll be performing mission nearby, which usually takes a decade or so. The drift problems we are having are nothing compared with what we'd face in reality, so I take it as degree of realism, challenging me to figure out simple network which works well despite of drift. You'll likely have other things in orbit too to provide redundancy. Likely scansat/kethane sat space station. Depending on how many other mods you happen to be using, and the degree of re usability you prefer, how comfortable you are with orbital rendezvous. F.ex I usually use few nuclear tug/skycranes and they are hanging in orbit for ages.

In any case 3 sats will need less work than 10. One of the other reasons I prefer 3 sat configs is dish management. Say you send a probe to eve. Most omni antennas with big enough range will just break in atmosphere. So I place 2 dishes on the probe, and connect each one to a sat. I'll have at least one connection going. What if I had 4 or 5 sats? Where do I point the probe's dishes?

You might be fine putting 10+ sats in Kirbin system, but the amount of work (and dv) you'll need to do this around moho, dres or the Joolian moons is just much more than fixing your sats every 10 years or so. My intent is not to tell how to play the game 'properly', but to show there is simple, low-maintenance configuration, and how you can reduce the drift, or problems it causes. Sure if the mod would keep them in sync would be nice.

The method I've bee using is having two satellites in a polar orbit, but offset by 90 degrees. This means that as long as you can see the planet, you can see at least one of the satellites. Both satellites will never be out of view at one time and they can't bunch together.

Interestingly, I have thought about having two satellites both leading and trailing a planet along its orbit. This would be great as you could route signals around the sun if you needed to. I didn't end up going with it though, as even these satellites will drift and eventually you will need to do some maintenance. The risk here is if you forget about it for too long, your satellites could crash into the planet. The other method is using a third planet to route your signal through

Truth to be told, I do this from laziness, as part of my flyby missions, or asteroid redirection, as well as having few stages from interplanetary trips serving as sats, one antenna pointed to active craft, other to a huge antenna array in solar orbit similar to kirbins. I put it there, as powering some 20 dishes can end up badly if you load it and happens to be dark. It depends on the planet really. For example joolian moons have a 'harmony', and you can use that in your benefit.

One polar sat on highly elliptical inclined orbit will give you pretty good coverage. Two sats on 90+ degree inclined orbit, should be generally enough, with your major problem still being the sun (and some extent other planets, but this happens really rarely (if at all?). Still if you are planning on actually landing a probe, you'd likely send a command center along (unless you have delay off)

Then there is always kOS. Not sure how well it plays with current version of RT, but it used to be pretty great for sat maintenance and unmanned missions (especially rovers). Though turning off delay or sending command center is easiest way if you are planning unmanned landings. I don't really think there is any way to drive a rover with big delay without kOS to be honest.

Edited July 2, 2014 by Aedile

[cdugas4]

I'm building an install in .23.5 and want to use RT. I had heard there were issues with this mod in the recent past. Can anyone confirm that it is relatively issue free? Also, if I do run into issues, can I disable to mod somehow mid-game?

[Rockstar04]

I'm building an install in .23.5 and want to use RT. I had heard there were issues with this mod in the recent past. Can anyone confirm that it is relatively issue free? Also, if I do run into issues, can I disable to mod somehow mid-game?

I've had no issues with the latest version of the mod, and it you have issues with it just delete the DLL's and leave the parts and you will be fine!

[BigD145]

I'm building an install in .23.5 and want to use RT. I had heard there were issues with this mod in the recent past. Can anyone confirm that it is relatively issue free? Also, if I do run into issues, can I disable to mod somehow mid-game?

Go to github and look at all the issues.

Most issues are PEBKAC.

Edited July 2, 2014 by BigD145

[AdmiralTigerclaw]

RT2 runs fine in most cases. It has some quirks in it that you have to get used to until the fixes and improvements to the code are introduced. However, I've seen nothing game breaking in my time using it, and most reports of something not working such as connections have been user mistakes.

Expect to find the flight computer troublesome to learn and dish aiming is notoriously less intuitive than it 'SHOULD' be. But those are issues that the fix ideas are rolling hot on.

[Grays]

Draft of omni-directional illustration. Thoughts?

[BigD145]

More numbers are needed. Ranges. Sizes. Diameters. Radii.

[Grays]

Ok...I could embed that information. I was intending it to go at the top of a table.

[cdugas4]

Thanks for the quick replies guys. I had already looked over the issues on github and didn't really see anything too important. Thanks for your help!

[Drew Kerman]

How does kOS currently work with RT? Is the signal delay simply ignored with kOS?

I'm wondering this too. Kos runs programs stored on a local disk so the only signal delay you should experience is sending the command to execute the program, and reviving any response. But I haven't had time to try it yet and the EC time warp bug caused me to revert so I can't comment on how the latest version handles kos

[dewin]

Hmm. Does the new RemoteTech release fix the long-standing issue posted here?:

It always happens when switching spacecraft from the in-flight map (not from '[' or ']' though). I like to deploy my sats/sat upgrades from a manned ship with two or three attached, so there's a fair bit of switching going on. If I'm not doing things like that, it seems to take forever for it to show up.

Has anyone experienced this issue without doing doing a deployment like this?

I'm not the plugin author (nor have I poked at the source), but I practically have a 100% "breaks games until next reload" test case of build comsat as subassembly, build multi-satellite carrier craft, attach comsats in symmetry, deploy 1-2 satellites successfully, crash somewhere around the third or fourth deployment when changing ships. The one common link I can think of is that the satellites all have the same origin vessel and have been renamed. (In fact, one crash was while cycling between them to change them from "Kerbin Comsat Launcher Probe" to "Kerbin Comsat E1" etc.

The crash only seems to be on scene change, so cycling with '[' and ']' doesn't trigger it (nor switching from the map if the target is in physics range)

(Sorry for odd quoting, not entirely certain how to properly quote from a closed thread.)

I checked an earlier dev snapshot (it was never published officially, I just snooped around on Github) and it didn't seem to be then, so I figured I'd check again.