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

[Draft]

Let's not have that discussion here, yeah? However you feel, it's not exactly relevant to the mod

[Sandworm]

Would anyone be interested in a full pdf-type manual for remotetech?

I'm seriously considering writting a full manual for KSP, including major mods. Remotetech would be a good place to start.

[Cilph]

Three confirmed bugs:

• Collection Modification exception when you click cancel in the flight computer. Minor issue, does no harm and has been fixed.
  
• Infinite nullexception spam when you do something specific with the nodes that I can't yet reproduce.
  
• Maneuver Node creation is delayed, but adjusting them is not. Will fix.
  

[Paul Kingtiger]

Would anyone be interested in a full pdf-type manual for remotetech?

I'm seriously considering writting a full manual for KSP, including major mods. Remotetech would be a good place to start.

A Remote Tech manual with some example satellite constellations would be a big help and reduce the starting trial and error I'm currently going through (my whiteboard is working overtime).

[OtherDalfite]

Let's not have that discussion here, yeah? However you feel, it's not exactly relevant to the mod

Pretty sure constructive criticism is necessary to a mod here, bud.

[Sacred Aardvark]

Release 1.2.1:

• Removed kOS integration;
  

The extension DLL was causing Kethane and possibly other mods not to work and for some reason wouldn't even properly load half the time for arcane reasons involving dll load order, versions and time of day.

There are only two mods that matter, RemoteTech and kOS. Everything else can either play nice with them or stay off my KSP If kOS and RT don't work together... *shudder* the horror! D: (though then I'd just run two installations, one with rt and one with kos )

Think I'll keep running 1.2.0 for a bit and see if I can't get some spectacular crash with some lovely error data to lighten your day. (thinking about trying other style tech trees anyway, so risking breaking my save isn't currently a big deal)

[AndreyATGB]

Here's my log for the past few hours. It's HUGE, I'm guessing mostly Remote Tech's fault, might be some incompatibility with something else but I can't confirm. https://dl.dropboxusercontent.com/u/8821504/KSP.log

Also I could watch this all day

Edited November 15, 2013 by AndreyATGB

[m4ti140]

4chan...

I'm lurking /b/ for 3 years now. I know how this site works. Believe me, they are not giving feedback, they will just destroy you for whatever reason, or come up with their own. Mostly for lulz. That's how they roll.

Do NOT take anything you find on 4chan seriously. Read rules of the internet - for 4chan it's 100% true, not only for /b/, for all boards. It is NOT a place to get feedback. They would bitch even if your mod was perfect...

[Cilph]

Here's my log for the past few hours. It's HUGE, I'm guessing mostly Remote Tech's fault, might be some incompatibility with something else but I can't confirm. https://dl.dropboxusercontent.com/u/8821504/KSP.log

Also I could watch this all day

Could you send me the KSP_Data/output_log.txt? That one has more details.

[AndreyATGB]

Could you send me the KSP_Data/output_log.txt? That one has more details.

It's...235mb but OK give me a sec.

https://dl.dropboxusercontent.com/u/8821504/output_log.txt

[Cilph]

It's...235mb but OK give me a sec.

https://dl.dropboxusercontent.com/u/8821504/output_log.txt

Zipping it will GREATLY reduce the size. You're lucky because that's exactly what Dropbox did for me as I tried to download it.

I'll put a fix out tomorrow. For now, stop targeting stuff I guess.

[AndreyATGB]

Zipping it will GREATLY reduce the size. You're lucky because that's exactly what Dropbox did for me as I tried to download it.

I'll put a fix out tomorrow. For now, stop targeting stuff I guess.

That didn't go through my mind, I'm pretty tired..Thank you.

[Draft]

Setting the kOS integration aside for now, the way that the flight computer cuts warp to execute commands is an excellent feature, and the queue is extremely useful. Thanks Ciph.

[Cilph]

Setting the kOS integration aside for now, the way that the flight computer cuts warp to execute commands is an excellent feature, and the queue is extremely useful. Thanks Ciph.

Thank JDP for that last minute feature. (Cutting timewarp)

[Ricardo.b]

hey, Cilph, I really enjoy to use old models from remote tech 1, 1m and 2m remote control command (that one with a blue stripe), that fits pretty nice on KW parts.

is there any way to implement that part to work on remote tech 2? how?

or maybe an extra release for those who like that?

[Deejay2000]

Release 1.2.1:

• Removed kOS integration;
  

Here, I have something perfect for us all...

Nooooooooooooooo

[jpinard]

Cliph your work here is beyond amazing. I just love how much immersion this brings. Please keep at it!

[DerekL1963]

It's included in the GameData folder. Drop that folder in place exactly as in the zip. If you have ModuleManager.dll in the GameData folder it should work as intended.

I went and got it from the actual mod's download thread, and everything is 'working' now. ('Working' in quotes because it's working, but I'm still trying to suss out the rules behind how it works.) Thanks!

[Sandworm]

Anyone find this helpful?

Building a Remotetech relay network - Part I

The first step in building a remotetech relay network is to establish a small network of relay sats around Kerbin. The logical approach is to place a single relay in a geo-stationary orbit (2868.75km) above the KSC. In theory, this lone sat would always be in contact with the KSC and could therefore be used to relay signals to more distant sats. The reality of KSP is that even geostationary sats drift. There is no station keeping in KSP and orbits can never be made truly perfect. The most logical approach to overcoming this problem is to fly multiple geo-stationary relays so that at least one will be over the KSC at any given moment. Again, good in theory but bad in practice.

Here is a formation of relays at 700km orbits. Each has only a communitron 32 and a dipole used for launch. The formation isn't perfect, but does provide total coverage. Note the equilateral triangle formed by three of the relays. Theoretically, three relays in 700km orbits would provide total coverage.

But here is that same formation after a couple years worth of warping. Note the dead area in the lower left. These relays are at 700km but the same would happen at 2868.75km, just more slowly. Similar gaps in a geo-stationary network could result in downtimes measured in weeks.

No matter how hard you try, sats in KSP will always drift relative to each other. The relative position of sats on nearly-identical orbits is never stable in KSP.

But now look at this...

I have shifted four of my relays into Molniya-type orbits. They now have a very low periapsis (80km+/-) and high apoapsis (3000km +/-). Their orbital speeds vary from around 560m/s at apoapsis to 3000m/s at periapsis. This means most of their time is spent loitering high over Kerbin, where they are best able to act as relays to the KSC. I have also left a couple sats in their initial 700km orbits to act as links between the Molniyas. Because orbits are stable in KSP, there is no clumping. Each relay remains clearly separated in its respective orbit. This basic formation should give you 99.9999% uptime for probes out to 5000km, the max range of the communitron 32.

Part II - Dishes

With our network of molniya relays in place we can conduct operations near kerbin without issue, but are limited by the range of our omnidirectional antennas. Anything beyond 5000km will require dishes. Dishes come in various sizes, appearing at various points in the tech tree, but I'm going to assume everyone is playing in sandbox mode. A single sat with a big dish might be enough, but Mun presents a problem. From the perceptive of a deepspace probe, a single sat can easily be blocked by Mun. There are a couple options to deal with this. We could use a polar molniya-type orbit, throwing a relay sat high above Mun's orbital plane, but a single sat is still too easily blocked. The answer is two sats in perpendicular polar orbits.

Build something like this...

The key parts are a single big dish, a communictron 32, and enough equipment to keep them powered 24/7. Launch the first into a high polar orbit (90*/2500km). Activate the communictron 32 and the big dish. Target the big dish towards "Active Vessel". Then head back to the KSC and ready a second, identical, relay sat. Wait until the KSC rotates 90* away from the orbit of the first sat before launch. The resulting orbits should look like this...

The relays are in perpendicular orbits and are connected via their omnidirectional antennas to the Molnyia network (removed for clarity). Probes heading for Mun or Minmus can target either of the polar relays and should remain connected whenever they become the "Active vessel". Probes heading beyond kerbin can alternatively target "Kerbin".

That's it. With this basic network we can reliably send probes to nearly any point in the solar system. They should remain connected so long as they have a line-of-sight to kerbin and a sufficiently large dish pointing home. Here is my complete near-kerbin network...

Part III - Dedicated Paths ...

Edited November 16, 2013 by Sandworm

[therealcrow999]

Good idea, this never occurred to me. Almost like a nucleus type setup.

Anyone find this helpful?

Building a Remotetech relay network - Part I

The first step in building a remotetech relay network is to establish a small network of relay sats around Kerbin. The logical approach is to place a single relay in a geo-stationary orbit (2868.75km) above the KSC. In theory, this lone sat would always be in contact with the KSC and could therefore be used to relay signals to more distant sats. The reality of KSP is that even geostationary sats drift. There is no station keeping in KSP and orbits can never be made truly perfect. The most logical approach to overcoming this problem is to fly multiple geo-stationary relays so that at least one will be over the KSC at any given moment. Again, good in theory but bad in practice.

Here is a formation of relays at 700km orbits. Each has only a communitron 32 and a dipole used for launch. The formation isn't perfect, but does provide total coverage.

But here is that same formation after a couple years worth of warping. Note the dead area in the lower left. These relays are at 700km but the same would happen at 2868.75km, just more slowly. Similar gaps in a geo-stationary network could result in downtimes measured in weeks.

No matter how hard you try, sats in KSP will always drift relative to each other. The relative position of sats on nearly-identical orbits is never stable in KSP.

But now look at this...

I have shifted four of my relays into Molniya-type orbits. They now have a very low periapsis (80km+/-) and high apoapsis (3000km +/-). Their orbital speeds vary from around 560m/s at apoapsis to 3000m/s at periapsis. This means most of their time is spent loitering high over Kerbin, where they are best able to act as relays to the KSC. I have also left a couple sats in their initial 700km orbits to act as links between the Molniyas. Because orbits are stable in KSP, there is no clumping. Each relay remains clearly separated in its respective orbit. This basic formation should give you 99.9999% uptime for probes out to 5000km, the max range of the communitron 32.

Part II - Dishes

.....

[DerekL1963]

Ok... version 1.2.1 does not appear to play nicely at all. The flight control computer jerks the throttle all over haitch and back, and there does not seem to be a way to disable it. (The 'kill' button doesn't seem to kill anything.)

[cyoung_mi]

Good idea, this never occurred to me. Almost like a nucleus type setup.

Thank you very much.. this is very helpful!

Currently I have 4 setup in a somewhat Geostationary orbit, but I can see where things might drift.

I will change my configuration shortly

Looking forward to Part II.

[DresCroffgrin]

First of all, thank you for this wonderful mod, Cilph! It really makes KSP a lot better .

A quick question for anyone who might know, though: Now that signal delay is on by default, how does one turn it off? I may enjoy hardcore KSP, but not quite that hardcore .

Thanks!

[johnsonwax]

No matter how hard you try, sats in KSP will always drift relative to each other. The relative position of sats on nearly-identical orbits is never stable in KSP.

I notice you put everything in terms of altitude, presumably apoapsis. Altitude really doesn't matter for geosync or even for maintaining uniform coverage in other orbits - orbital period does. Further, you get more precision with orbital period in game than you do with altitude. You may not be stationary relative to the surface this way (which requires having both apo and periapsis dead-on equal), but as long as apo and peri are in the same neighborhood, the sat will not drift far from the target over the course of an orbit.

A geosync satellite should have an orbital period of 6 hours (21600 sec). You can get that period with an expected error of 0.05 sec/orbit or .00023%. That's better than what you can accomplish by using altitude and would amount to a maximum of 5 minutes of drift per year. That's not nothing, but it's pretty tolerable. Chuck an ion engine on your sat like I showed on my previous comment and you can correct that drift every few years without much trouble.

There's a number of utilities for giving you orbital period. MechJeb will give you period to a precision of 1 second, but Kerbal Engineer Redux will give you to .1 sec. Very handy for this sort of thing. Getting the orbital period dead on 6:00:00.0 requires very low thrust/weight (.01 or below). Ion drives are good for this, but may be insufficient for getting your sat into the proper orbit. Combining a conventional engine with either an ion drive (for station keeping) or some RCS and a linear RCS port for that purpose are a good idea. You'll use very little RCS for that fine-tuning. Click on docking mode if need be.

[Sandworm]

I notice you put everything in terms of altitude, presumably apoapsis. Altitude really doesn't matter for geosync or even for maintaining uniform coverage in other orbits - orbital period does. Further, you get more precision with orbital period in game than you do with altitude. You may not be stationary relative to the surface this way (which requires having both apo and periapsis dead-on equal), but as long as apo and peri are in the same neighborhood, the sat will not drift far from the target over the course of an orbit.

A geosync satellite should have an orbital period of 6 hours (21600 sec). You can get that period with an expected error of 0.05 sec/orbit or .00023%. That's better than what you can accomplish by using altitude and would amount to a maximum of 5 minutes of drift per year. That's not nothing, but it's pretty tolerable. Chuck an ion engine on your sat like I showed on my previous comment and you can correct that drift every few years without much trouble.

There's a number of utilities for giving you orbital period. MechJeb will give you period to a precision of 1 second, but Kerbal Engineer Redux will give you to .1 sec. Very handy for this sort of thing. Getting the orbital period dead on 6:00:00.0 requires very low thrust/weight (.01 or below). Ion drives are good for this, but may be insufficient for getting your sat into the proper orbit. Combining a conventional engine with either an ion drive (for station keeping) or some RCS and a linear RCS port for that purpose are a good idea. You'll use very little RCS for that fine-tuning. Click on docking mode if need be.

You can get close, but even if you get them exact, KSP has issues when it comes to warping. KSP's math isn't perfect during high warps. The little simplifications add up. Geo-stationary may look pretty, but just isn't worth the effort. Anything that requires maintenance defeats the purpose. And if you are playing under career mode, the low-power engines necessary to perfect an orbit aren't available when you need them. The molniya orbit's I described are very simple, do not require exact positioning, and survive decades of warping without degradation.

Whether one describes an orbit in terms of dimensions (altitudes) or periods is wholly a matter of preference. I prefer dimensions because apoapsis+periapsis provides an exact description, whereas two very different orbits can share identical periods (ie a molniya orbit with a 6h period is not properly geo-stationary).

Edited November 16, 2013 by Sandworm