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

[undercoveryankee]

Is anyone having any issues with deploying satellites from a manned craft?

The setup:

KSC -> high kerbin orbit sat(dish) -> manned vehicle(dish + omni) -> newly deployed commsat(omni)

as soon as i decouple the commsat i can fly and control it, however once i pass 2.5k away from manned craft i lose connection. It appears as though the manned craft isnt counted, or is blocking the signal as soon as it isnt physics loaded anymore. Thoughts?

What is the target of the relay satellite's dish? This sounds pretty similar to what happens when the dish that was communicating with your mothership was targeting "active vessel", so it no longer targets the mothership after you switch away. I hadn't heard of an "active vessel" situation working until the mothership was unloaded before, but I wouldn't be surprised to see it work that way, either.

[undercoveryankee]

Do any of you have any tools for calculating the best insertion orbit for a single launch?

For instance, if I want to launch 4 sats at 2000km using one ship. I would orbit then raise my apoapsis to 2000km creating a nice elliptical orbit. Launching the first Sat is easy, but then if you want reasonably even spacing you have to warp and warp and warp till you get roughly the right setup.

I imagine that if you setup the launching ship's orbit in just such a way that when it gets back up to the apoapsis it would have perfect spacing.

You need to set the bus's orbital period to an appropriate ratio to the target orbits' period. For a 2000km target orbit, the best deployment orbit would have apoapsis at 2000km and period 3/4 of a 2000km circular orbit. The best way to do this is with a mod that can display orbital periods, but a quick attempt at running the 3/4 ratio through Kepler's third law says a 2000x1092 orbit on the bus will be pretty close.

[CatastrophicFailure]

You need to set the bus's orbital period to an appropriate ratio to the target orbits' period. For a 2000km target orbit, the best deployment orbit would have apoapsis at 2000km and period 3/4 of a 2000km circular orbit. The best way to do this is with a mod that can display orbital periods, but a quick attempt at running the 3/4 ratio through Kepler's third law says a 2000x1092 orbit on the bus will be pretty close.

that 3/4 number will vary depending on the number of sats in your constellation. I find it easier to set them up based on orbital period rather than altitude. For example, if you want 3 sats with an orbital period of 6 hours (2868km alt). Set up your bus to an ApA of 2868, then raise your PeA to whatever gives you a two hour period. Once this is done you can actually separate all your sats, they'll float together in a little cluster, then circularize each one as it swings back to ApA.

[Tinweasele]

What is the target of the relay satellite's dish? This sounds pretty similar to what happens when the dish that was communicating with your mothership was targeting "active vessel", so it no longer targets the mothership after you switch away. I hadn't heard of an "active vessel" situation working until the mothership was unloaded before, but I wouldn't be surprised to see it work that way, either.

Target is definitely the mothership, just checked. Went to map mode and checked and all the ships have lines between them, even when the probe shuts down due to no connectivity. Yet somehow i cant control it.

[Nori]

You need to set the bus's orbital period to an appropriate ratio to the target orbits' period. For a 2000km target orbit, the best deployment orbit would have apoapsis at 2000km and period 3/4 of a 2000km circular orbit. The best way to do this is with a mod that can display orbital periods, but a quick attempt at running the 3/4 ratio through Kepler's third law says a 2000x1092 orbit on the bus will be pretty close.

Kepler's third law eh? Heard this mentioned but now I will have to look up up. Thanks

that 3/4 number will vary depending on the number of sats in your constellation. I find it easier to set them up based on orbital period rather than altitude. For example, if you want 3 sats with an orbital period of 6 hours (2868km alt). Set up your bus to an ApA of 2868, then raise your PeA to whatever gives you a two hour period. Once this is done you can actually separate all your sats, they'll float together in a little cluster, then circularize each one as it swings back to ApA.

That makes sense. Less math that way.

[undercoveryankee]

that 3/4 number will vary depending on the number of sats in your constellation. I find it easier to set them up based on orbital period rather than altitude. For example, if you want 3 sats with an orbital period of 6 hours (2868km alt). Set up your bus to an ApA of 2868, then raise your PeA to whatever gives you a two hour period. Once this is done you can actually separate all your sats, they'll float together in a little cluster, then circularize each one as it swings back to ApA.

I meant to suggest just going by period if you have easy access to display the orbital periods in question (KER, VOID, MechJeb). Since stock doesn't tell you your orbital period directly, but makes you calculate it from the times to periapsis and apoapsis, I went on to suggest how you might calculate a resonant orbit using numbers that are easy to get in stock and only require you to watch one number at a time while doing burns. The whole Kepler thing is "if you need to play without informational displays" advice.

[CatastrophicFailure]

I meant to suggest just going by period if you have easy access to display the orbital periods in question (KER, VOID, MechJeb). Since stock doesn't tell you your orbital period directly, but makes you calculate it from the times to periapsis and apoapsis, I went on to suggest how you might calculate a resonant orbit using numbers that are easy to get in stock and only require you to watch one number at a time while doing burns. The whole Kepler thing is "if you need to play without informational displays" advice.

seems reasonable to me that if he's bothering with com sat constellations with RT2 then he's got one of the above mods (I dunno HOW one can play RT2 without MechJeb, unless you never land on most of the bodies beyond Kerbin:sealed:)

oh well at least he's got options now lol

[mecki]

Two things I still struggle with while using RT2:

- nearly all of my crafts tend to shake/jitter/wobble/oscilate quite a lot when I set their direction via the Flight Computer. It doesn't really matter if I use SAS, RCS or both. I have MechJeb on all of my Command Modules.I don't use it while I'm using the Flight Computer and it doesn't make a difference if I switch to Stock SAS or disable RCS Balancer.

If I disable RCS Balancer RCS gets used a lot (it's aggressively overcompensating). The RCS thrusters are perfectly fine aligned with the help of the RCS Builder mod. If I use RCS thrust forward in addition (on an ascent maneuver) things become much worse, often the vessel will loose its orientation.

- The Flight Computer doesn't remember its location and wether it's been expanded or not

[soulsource]

I dunno HOW one can play RT2 without MechJeb, unless you never land on most of the bodies beyond Kerbin:sealed:

In my opinion MechJeb is to easy. To me it feels like I don't only delegate the task of landing to a soulless machine, but also the fun of it. Maybe this is because the risk of failure is very low when using MJ.

I recommend to use kOS instead for this reason. While it is a powerful autopilot, it doesn't do much by itself that the flight computer couldn't do as well. Nevertheless, due to its scripting capabilities it can be programmed to perform very complex manoeuvres, of course including landing. This has the advantage, that, while the landing is performed by the computer, it is doing exactly what the player told it to, so one doesn't delegate the responsibility, and of course the risk of failure (and with it the fun) is still there. To me it is nearly as thrilling to have a probe land by a self written script as it is to land it manually. This thrill never goes away, since every probe is slightly different (at least if you don't use the same subassembly for all of them), and a different TWR or torque can make a script that worked dozens of times suddenly fail miserably.

[CatastrophicFailure]

In my opinion MechJeb is to easy. To me it feels like I don't only delegate the task of landing to a soulless machine, but also the fun of it. Maybe this is because the risk of failure is very low when using MJ.

I recommend to use kOS instead for this reason. While it is a powerful autopilot, it doesn't do much by itself that the flight computer couldn't do as well. Nevertheless, due to its scripting capabilities it can be programmed to perform very complex manoeuvres, of course including landing. This has the advantage, that, while the landing is performed by the computer, it is doing exactly what the player told it to, so one doesn't delegate the responsibility, and of course the risk of failure (and with it the fun) is still there. To me it is nearly as thrilling to have a probe land by a self written script as it is to land it manually. This thrill never goes away, since every probe is slightly different (at least if you don't use the same subassembly for all of them), and a different TWR or torque can make a script that worked dozens of times suddenly fail miserably.

Lol, see now we're getting into entirely different concepts of fun. Anything that involves deciphering and scripting code is well off into the "unpleasant" end of the fun scale for me. Right up there with "going to the dentist" or "watching a political speech." The last thing I ever scripted was a BASIC Russian roulette program back in computer class. The teacher was not amused (the fact that I was still able to do so with only an eyeroll & facepalm instead of a full SWAT response should give you some idea how long ago that was).

In my experience, MechJeb fails far more than "enough" to keep things entertaining GIGO still applies, Y'know?

[undercoveryankee]

seems reasonable to me that if he's bothering with com sat constellations with RT2 then he's got one of the above mods (I dunno HOW one can play RT2 without MechJeb, unless you never land on most of the bodies beyond Kerbin:sealed:)

oh well at least he's got options now lol

That's why signal delay is optional. If you'd rather hand-fly, you can pretend that you're the local autopilot.

[junkie_business]

Hey, I'm not getting any stock antenna RT2 functionality. I've got the latest ModuleManager. Any ideas? If I edit a mod antenna to have RT functionality, it works fine.

[sidfu]

check your log junkie and give us any info. and i mean both logs the ksp.log and the output log thats in whatever version u using.

[junkie_business]

check your log junkie and give us any info. and i mean both logs the ksp.log and the output log thats in whatever version u using.

Thanks sidfu:

http://www.dropbox.com/s/c2bmxjfk68fgabh/KSP.log

https://www.dropbox.com/s/urzh6u0ltv53gqv/output_log.txt

[undercoveryankee]

Hey, I'm not getting any stock antenna RT2 functionality. I've got the latest ModuleManager. Any ideas? If I edit a mod antenna to have RT functionality, it works fine.

I've looked at your logs, and I don't see ModuleManager loading anywhere. Exactly where is your ModuleManager dll located?

[junkie_business]

You're right, I just reinstalled all of my mods. Except ModuleManager. Herpa derp.

[Gotcha]

is working with .24.2 ?

[Brucey]

Hello. I wanted to drop in a comment for this mod. Just started getting into to it the past few days. I was worried it might be too complicated or difficult to set up at first. I was wrong. It's easy to learn, difficult to master. i.e., it's perfect. You guys did some excellent work here!

[undercoveryankee]

is working with .24.2 ?

I can confirm that the development builds are.

[soulsource]

is working with .24.2 ?

I've been using 1.4.0 since I installed .24.2, and up to now I didn't encounter any issues with it. Nevertheless, if you prefer software not yet considered stable over not rigorously proven to be compatible software, you can get the Development Build 47, which is considered release candidate for RT 1.4.1, and is .24.2 compatible.

I've got a question regarding massless parts. Do antennas, that are massless in stock KSP retain this property with RT2, or is their mass taken into account properly?

[undercoveryankee]

I've got a question regarding massless parts. Do antennas, that are massless in stock KSP retain this property with RT2, or is their mass taken into account properly?

RT2 doesn't change the physics significance of the antennas. It'll be the same as stock.

[Ashery]

...you can get the Development Build 47, which is considered release candidate for RT 1.4.1, and is .24.2 compatible.

Any reason for using DevBuild 47 over the more recent 49? I couldn't find any real notes on the changes between versions and so I'm not sure which one to use.

[tomf]

Is there a good way to establish reliable connections with a probe that is between 90Mm and 2.5Gm from Kerbin? Furtherthan 90Mm the KR-7 and SS-5. With the longer ranged dishes I can aim that at Kerbin but their angle is to small to reliably lock on to my relay satelites orbiting at an altitude of 900km. If I aim at an individual relay satellite I lose comms half the time while it is behind Kerbin?

Also is it possible to tell a probe to re-open its comm dishes after a fixed delay? I want to furl my antenna while I aerobrake and then have it unfurl when it is safely out of the atmosphere.

[uncle natzer]

My game is crashing every time I resume my save. Always at the space center or if it doesn't crash then, it crashes when I select any of the buildings. It did not start doing this until after I put up my first comm sat.

This is a list of mods that I am using,

AIES Aerospace (updated)

Toolbar (updated)

Deadly Reentry (updated)

Dmagic Orbital Science (updated)

KAS (updated)

Kerbal Joint Reinforcement (updated)

MechJeb2 (updated)

SCANsat (updated)

Chatterer RMB (updated)

Real Chute (updated)

Kerbal Alarm Clock (updated)

Module Manager 2.2.0 (updated)

KW Rocketry (updated)

Raster Prop Moniter JSI (updated)

Vessel View (updated)

ALCOR (updated)

Final Frontier (updated)

Crew Manifest (updated)

Procedural Fairings (updated)

Firespitter.dll (updated)

Spaceplane Plus (updated)

HexTruss (updated)

Infernal Robotics (updated)

Hot Rockets (updated)

SmokeScreen.dll (updated)

RCS Build Aid (updated)

NothkeSerCom (Service Compartment Tubes) (updated)

Tac Fuel Balancer (updated)

KS Industries (updated)

Distant Object (updated)

Connected Living Space (updated)

FusTek (updated)

Mods By Tal (tet and sphere tanks) (updated)

Mod Statistics (updated)

RemoteTech 2 (updated)

They are all updated to their latest version and I am using KSP version 0.24.2 x64. Any help would be great!

[undercoveryankee]

Is there a good way to establish reliable connections with a probe that is between 90Mm and 2.5Gm from Kerbin? Furtherthan 90Mm the KR-7 and SS-5. With the longer ranged dishes I can aim that at Kerbin but their angle is to small to reliably lock on to my relay satelites orbiting at an altitude of 900km. If I aim at an individual relay satellite I lose comms half the time while it is behind Kerbin?

Best way I've found to communicate at those distances is to use two dishes in the 88-88/KR-14 class, targeted on different relay satellites. If doubling up is prohibitive for you for whatever reason and you have to use a single relay satellite, second best is to put the relay into a high polar orbit so it's eclipsed for a smaller fraction of the time.

Also is it possible to tell a probe to re-open its comm dishes after a fixed delay? I want to furl my antenna while I aerobrake and then have it unfurl when it is safely out of the atmosphere.

If you expand the flight computer, there's a field where you can manually add delay to commands on top of any signal delay that RT2 is applying on its own. Put "open antenna" and "close antenna" on separate action groups so you can fire them regardless of the antenna's current state. Estimate when you'll be in position to reopen your antenna, add a suitable amount of delay, and send the "open" command. Then, while the "open" command is in the queue, set manual delay back to zero and send the "close" command.