[0.20] RemoteTech: Relay Network – V 0.5.0.1

[JDP]

I encounter some problem,

I have a group of satellite at 600Km orbit to prevent kerbin block signal

all satellite have one 50Mm dish pointing to kerbin and connected each other by antenna

I send a interplanetary satellite which have 1 50Mm dish and 1 900Gm dish

orbiting 40Mm*40Mm orbit

50Mm dish pointing to kerbin

but it can't receive signal from 600Km orbit's satellite

Do I did something wrong?

Yep. To get an actual range of 900 Gm between two ships you need a 900 Gm dish on them both, and each dish needs to be pointed at the other (or the star/planet/moon the other ship is in orbit around if they orbit different bodies). If you point a 900Gm dish at a ship that only has a 8 Mm range antenna, you will get a signal boost of x2, giving you an effective range of 16Mm, but you will never have the full 900 Gm range.

Just to be safe, I'll mount a series of test missions, setting up linked relay networks between Kerbin and Duna. I'll report back with my findings once I'm done.

[royying]

Yep. To get an actual range of 900 Gm between two ships you need a 900 Gm dish on them both, and each dish needs to be pointed at the other (or the star/planet/moon the other ship is in orbit around if they orbit different bodies). If you point a 900Gm dish at a ship that only has a 8 Mm range antenna, you will get a signal boost of x2, giving you an effective range of 16Mm, but you will never have the full 900 Gm range.

Just to be safe, I'll mount a series of test missions, setting up linked relay networks between Kerbin and Duna. I'll report back with my findings once I'm done.

I stuck in 600Km to 40Mm satellite connection:(

Edited April 20, 2013 by royying

[JDP]

I stuck in 600Km to 40Mm satellite connection:(

-snip-

Ahh I see your problem. You're still in orbit around kerbin. Which means that it won't be enough to target Kerbin, you'll have to target one of your POSTMEN directly, and you need to set your POSTMEN dishes up to point directly at POSTMEN SOLAR.

Once POSTMEN SOLAR leaves kerbin orbit and enters its orbit around the Sun, it will be enough if you just point your dishes at Kerbin, as long as the dishes on the POSTMEN relay satellites are pointed at either POSTMEN SOLAR or the Sun.

I just did a completely unmanned mission to Duna without problems. I did have to contend with loosing signal connection for a brief while, while going out of antenna range but still being in orbit around Kerbin. But I set my relay satellites up to point directly at my probe and set the probe dish to point directly at kerbin, so once I got far enough away (I.e.: left Kerbin orbit) Connection was regained through the 900 Gm dishes.

Here's the final result of my mission:

[waerth]

Well I managed to set up a 10 sattelite network. With about 15 launches. I have one satellite in an almost stationary polar orbit and the rest in orbits ranging from 2.500 km to 73 km very circular orbits. It seems to work reasonably well. I am now going to redesign and build a geostationary network ..... I hope.

W

[JDP]

Well I managed to set up a 10 sattelite network. With about 15 launches. I have one satellite in an almost stationary polar orbit and the rest in orbits ranging from 2.500 km to 73 km very circular orbits. It seems to work reasonably well. I am now going to redesign and build a geostationary network ..... I hope.

W

-snip-

Nice work Just remember that a relay network is most reliable if the satellites travel at the same speed, or else the constellation will drift quickly, which probably creates blind spots. Strictly speaking the sats should have the same semimajor axis. A simple way to make sure that they do is to make sure their apoapsies and periapsies are equal.

A way of ensuring this is using the flight computer in step 3. Just remember how much delta-v you need to circularize from apoapsis and input that into the throttle computer in delta-v mode each time you launch a satellite from the carrier. That way you get pretty uniform orbits of your satellites.

[DuckZero]

Not sure if anyone's mentioned this, but the drone is a pretty effective SSTO aircraft. Get it up to 30km and fire the "deorbit" engine: puts apoapsis at about 200km.

[CAPFlyer]

I've always setup my relay network pretty simply - put 3-4 "TDRS" satellites up in orbit around Kerbin at KSO (2868.4 km) with 1x 8000KM, 2x 900GM dishes and 1x 500MM deployable dish. I then deploy (via rover) DSN A at KSC which is equipped with 3x 900GM dishes and a 5000 KM omni. Finally, I launch DSN B and DSN C at 120* intervals around Kerbin with the same antenna setup as DSN A but on a lander body. The way the system works (and it works quite well as the real system does) is that the TDRS network handles everything within Kerbin's SOI (including the Mun and Minmus) and then the DSN handles all interplanetary operations. If I need to boost my signal or have a "backup" I may key in the TDRS satellites for my long-distance probes, but the DSN network usually has sufficient coverage except very early in the voyage to get 100% coverage. The only drawback is that you can only effectively control 3 probe missions as once and maintain continuous contact. Otherwise, you have to start re-pointing the dishes on the DSN to maintain contact.

[stibbons]

I've just finished my fourth launch to get a relay satellite around Kerbin. Each sat has 2x 900GM dishes, 2x 50GM dishes and and 8MM deployable omni antenna. The first is in a stationary orbit over KSC, the others at roughly 90° intervals. Took four separate manned launches (they're pretty big, flew them up separately to be on the safe side), but now I've got pretty thorough coverage of everywhere I've sent probes before.

Next launch will carry four relays to Mun, each with a single 50MM dish and an omni. In my last 0.4 save, I found putting those in a semi-synchronous orbit around Mun meant that I was always in contact with all of the satellites, and seemed to have good coverage on the surface, at least in the central latitudes my two test probes landed.

[Bremech]

It seems kind of silly to me to remove the functionality of being able to extend antenna etc. once the probe is out of radio range. Heck the programing in the control modules should automatically extend them to try re-establish radio contact whenever it loses it as its default functionality. Satellite dishes are a more complicated matter, but they should at least switch on and look for signals in the direction they are facing. No one designs a remote control device to just give up at the first sign of signal drop, it's just too simple and obvious (let alone expensive) an oversight to make.

Needing to have two devices of equal range also seems silly to me. If the transmitter is powerful enough to broadcast a signal to another planet the receiver on the other end shouldn't need an equal amount of signal gain to pick it up. If it's inside another devices broadcast radius it should receive the signal regardless of it's own range. Obviously with satellite dishes they should still need to be pointed at each other, but the range of the broadcasting dish with the control signal should be the one for which the transmission range matters.

My first flight after installing this mod (which I love the idea behind btw) was a disaster. Here's what went down... Designed an expensive communication satellite to start building my initial network (and I try to stick as close to stock parts as possible, I have the sister mod that add the remotetech functionality to stock parts) and launch it got 2km up and lost signal... Seriously? That giant ass tracking station can't send command signals more then 2km? I've built radios the size of peanuts that can broadcast further then that. Admittedly miniaturization technology wasn't always there but by the time we developed satellite dishes? The thing had solid boosters so when it tipped over that was that. Millions Kerbal dollar down the drain. Bad start for our space program. So the next flight we tried extending the antennas before we reached 2km height and they ripped off and down everything went... I'll take responsibility for that one. So next I designed a command rover with 3 Kerbals in it and stuck every kind of dish and aerial on it I could find, extended and activated everything. Bought out my launch ship, activated the dishes that wouldn't tear apart and pointed them at the command vehicle, pointed all the command vehicles dishes at the ship. Took off, landed in the ocean. We refuse to stick a Kerbal in one of our designs until we've proven it can complete an equivalent mission unmanned first (e.g. probe in orbit before Kerbal, Rover on Mun before Mun walk) and I was just about convinced that with this mod that was impossible. But other people here on the forums were clearly doing it... Billions of Kerbal dollars in failed research flights later I stumbled on the fact the dipole antenna doesn't need to extend to activate and we got our first probe in space... I mean looking at it I'd suspect the thing is more likely to rip off then some of the extended models but regardless what we learned is of all the omnidirectional antenna to choose from, every single ship has to have this model on it to get off the ground. Unless I'm missing something obvious? Either way I couldn't handle the silliness of it so I modified every one to have a minimum range of hundred kilometers so the probes could at least break atmo and extend them, but I shouldn't have had to (also edited the weights to be more consistent with the stock parts). Now the mod is usable, temperamental nature of the dishes aside. Still the Kerbal tax payers are calling for RemoteTech's blood. :-P

Edited April 20, 2013 by Bremech

[CAPFlyer]

The problem isn't the tracking station, it's the antenna's attached to your ship. The retracted antenna only have a 2km range. Try attaching a 5000km UHF Omni antenna to the final booster stage of your ship. That will give you plenty of radio coverage through launch until you're over the horizon. Just make sure that your initial burn gets you into an orbital trajectory because you won't be able to do any orbit adjustment maneuvers until you're back in contact with KSC again on the next orbit unless you program your apoapsis burn prior to loosing contact. That's what I do with my first satellite. I make the initial launch using MechJeb lifting to a apoapsis of 450km with the gravity turn starting a 1km, ending a 70km, a final pitch of -5*, and a curve of between 40* & 43* depending on the launch vehicle. Once I reach MECO-1, I time out where apoapsis is fire up the RT flight computer, shutoff MechJeb and set a prograde delta-V burn timed for about 10 sec. before apoapsis to give me a roughly circular orbit. Now, even though I'll be over the horizon at apoapsis, the second burn will still go and I'll get it in an established orbit. Then once I pick back up KSC contact, I can use MechJeb to make the last 2 burns to put the satellite in to KerboSynchronus orbit as I'll always been in LOS of the space center and within 5000 km. Don't forget to leave a RT Remote Control antenna on the final booster stage and a couple of batteries so that you can deorbit the booster when you're all done.

[Bremech]

The problem isn't the tracking station, it's the antenna's attached to your ship. The retracted antenna only have a 2km range. Try attaching a 5000km UHF Omni antenna to the final booster stage of your ship.

You don't say? Let me guess TL;DR? I'm sorry but you kind of missed the point. Also I can't seem to use mechjeb without it causing a tonne of lag.

[CAPFlyer]

With MechJeb - Have you hit Alt+F2 to see if you're getting errors? I suspect something is either installed wrong or something is working against each other.

Anyway, I was just giving you a suggestion and how I do my launches. Take it or leave it. Don't get sarcastic or tell me I missed the point. I didn't miss the point. The point is that you want complex radio propagation to be modeled. There's a major problem with that - processing.

If you wanted it to work like the real world, here's what he'd have to do - he'd have to create a system for raycasting every dish and antenna with a fade curve. Then the system would have to calculate whether a given antenna can "hear" the rays that are being sent out by each dish or antenna around it and do this for every dish and antenna present in the game to determine whether there is a valid path from your vessel to KSC or other valid command post or not. It would have to do this every cycle. The moment you get more than maybe a dozen antenna and dishes into the game, the amount of processor time required to do all this will become substantial and as the network grows, it will bring even the most powerful home PC's to a standstill before long. What JDP has done is simplify the operation so that even fairly "casual" users will want to use it for a challenge because the rules on how it operates are well defined, unlike how it is in the real world.

[stibbons]

It seems kind of silly to me to remove the functionality of being able to extend antenna etc. once the probe is out of radio range. Heck the programing in the control modules should automatically extend them to try re-establish radio contact whenever it loses it as its default functionality.

Disagree that we should be able to control antennas and dishes when they're out of range. But I do agree that they should extend to try to establish contact.

Poking around in the part config for the MicroSat to understand how the plugin works now, I discovered its antenna module is setting willWakeInPanic to true. The way I read the source code, all antenna modules have that variable, and setting it to true in a part's configuration will cause the antenna to toggle on if the vessel is out of range.

Your post sounds like you're not going to like this solution either, but adding

willWakeInPanic = true

to the antenna module should solve some of your problem.

[Nemitis]

I just started using the new version and I've found a bug with the throttle. When focusing on a program other than KSP, the throttle will be set to 50% until KSP is re-focused. This is annoying for me because I run KSP in full screen windowed mode and often have something running on my second monitor. My short-term solution is to just pause the game.

Edit: I just did some more testing and found out that this only happens when my joystick is attached and only when there's an axis assigned to the throttle.

Edited April 20, 2013 by Nemitis

[JDP]

...Now the mod is usable, temperamental nature of the dishes aside. Still the Kerbal tax payers are calling for RemoteTech's blood. :-P

I get why RemoteTech can be frustrating to you, because... well... it's designed to be.

One of the main design concepts of RemoteTech is to add an extra aspect of danger: catastrophic signal-loss failure. Such an event takes a lot of care, planning and foresight to prevent. To me at least, that makes a mission that much more rewarding. When you know that you've managed to maintain a line of communication while at the same time being able to maneuver a vessel under signal delay. It's not nearly as casual as stock KSP and a lot more dangerous; one miss step and you could send you'r probe on a colision course with Duna, another miss step and you risk loosing contact with your probe forever.

Adding an emergency protocol has been suggested before, and in fact I've experimented with adding one in a test build. But ultimately I found that it made the plugin feel too safe. I kept the "willWakeInPanic" functionality, simply because it's a way of simulating higher-tier antennae. The bulky deployable antenna has this functionality, and is a lot more resistant at launch, mainly to make it an ideal choice for communication during atmospheric flight.

[Bremech]

Anyway, I was just giving you a suggestion and how I do my launches. Take it or leave it. Don't get sarcastic or tell me I missed the point. I didn't miss the point.

Dude really? I know you're trying to be helpful but seriously...

Billions of Kerbal dollars in failed research flights later I stumbled on the fact the dipole antenna doesn't need to extend to activate and we got our first probe in space... what we learned is of all the omnidirectional antenna to choose from, every single ship has to have this model on it to get off the ground.

The problem isn't the tracking station, it's the antenna's attached to your ship. The retracted antenna only have a 2km range. Try attaching a 5000km UHF Omni antenna to the final booster stage of your ship.

Your advice is tell me something I've specifically already established I know. That's not helpful it's insulting. You got served sarcasm because I'm giving you the benefit of the doubt in assuming that's not your intent. As for for the rest of your post, I don't know how he's modeling the code but from in game it looks like he's currently doing the range check at both ends where as what I'm suggesting is just do them at one, which is less processing not more. It is possible he already is doing a single check on the receiver which I guess then does an additional check is the signal also has command in which case I'm just suggesting switching it to the broadcasters with command instead again presumably less checks. I never said hey I expect you to go all out and make a perfect mathematical model accurately simulating real life. But it seems to me there are simpler more accurate ways to simulate it that are worth giving consideration.

Disagree that we should be able to control antennas and dishes when they're out of range. But I do agree that they should extend to try to establish contact.

...

Your post sounds like you're not going to like this solution either, but adding

willWakeInPanic = true

to the antenna module should solve some of your problem.

That's a valid point. "IF" they already try to call home you shouldn't be able to tell them to when they fail. :-P

Adding that is better then nothing. I'm glad the option is at least there just wish it was more transparent.

I get why RemoteTech can be frustrating to you, because... well... it's designed to be.

One of the main design concepts of RemoteTech is to add an extra aspect of danger: catastrophic signal-loss failure. Such an event takes a lot of care, planning and foresight to prevent. To me at least, that makes a mission that much more rewarding.

Hey I can appreciate that. It's your mod and you have the right to run it how you like. But when you distribute something to the public they will want their say... Mine is I'm totally fine with catastrophic failure due to insufficient planning... As long as that is actually my fault, not because the devices I'm using are arse backwards by design. You've moved the sense of reward from successfully setting up a well planned network to defeating your own technology constantly working against you... Which hey that's fine if that's your thing (Of course the prescience of the areo probe and microsat which I refuse to use because they seem too much like training wheels seem to work against this design philosophy). Like I said I am glad the option is at least there, but I had to complain to learn of it... So worth complaining. :-P

Edited April 21, 2013 by Bremech
Responding to post made while posting.

[JDP]

Your advice is tell me something I've specifically already established I know. That's not helpful it's insulting. You got served sarcasm because I'm giving you the benefit of the doubt in assuming that's not your intent. As for for the rest of your post, I don't know how he's modeling the code but from in game it looks like he's currently doing the range check at both ends where as what I'm suggesting is just do them at one, which is less processing not more. It is possible he already is doing a single check on the receiver which I guess then does an additional check is the signal also has command in which case I'm just suggesting switching it to the broadcasters with command instead again presumably less checks. I never said hey I expect you to go all out and make a perfect mathematical model accurately simulating real life. But it seems to me there are simpler more accurate ways to simulate it that are worth giving consideration.

Range checks are indeed done for both sender and reciever. I have to make sure that they each have a sufficient range to establish a connection. The range check goes thusly:

1. Check if both vessels have omnidirectional antennae, then check if both their ranges are equal to or greater than the distance between each vessel.
   
2. else: Check if one has a dish pointed at the other, or (if they orbit different planets) the other's planet, and the other has an omni antenna, then check whether the range of the dish is equal or greater than the distance, and check whether the antenna range x2 is equal or greater than the distance.
   
3. else: Check if both have dishes and both have dishes pointed at each other, or (if they orbit different planets) each other's planets. Then check if each dish range is equal or greater than the distance.
   

I could make a range model that works off of gain and not range, and in fact I've dabbled in that a bit in the past. But the problem here is one of transparency. It get's really hard to figure out which effective range you'll get out of an antenna pairing making it a bit too hard imho. In stead I've elected to use the simplified model.

and back to the willWakeInPanic function: I've done as much as I can to make the plugin configurable. You can edit some key settings in the <modifier key> + f11 settings menu and there are a lot of variables that you can add/change in the part configs. All common variables and their default values can be found in the OP.

And of course you are allways wellcome to grab the sourcecode and remake the plugin to your liking. If you can make sense of C#, and my, admitedly not so transparent, coding style.

Oh and don't feel insulted by CAPFlyer. I can vouch for the non-insulting character of pretty much every common-poster in this thread .

[Camacha]

So, I notice the stock parts are edited to include specific modules for Remote Tech to work. However, I'm also using FAR. How can I make sure both mods work like they are supposed to? Just add the following/corresponding code under the FAR code in each CFG file?

// --- RemoteTech parameters ---

MODULE

{

name = ModuleRemoteTechSPU

minimumCrew = 0

EnergyDrain = 0.02777778

isRemoteCommand = false

}

RESOURCE

{

name = ElectricCharge

amount = 5

maxAmount = 5

}

[JDP]

So, I notice the stock parts are edited to include specific modules for Remote Tech to work. However, I'm also using FAR. How can I make sure both mods work like they are supposed to? Just add the following/corresponding code under the FAR code in each CFG file?

ModuleRemoteTechSPU should replace ModuleCommand, so it's only for pods. Probably the pod cfg you're looking at already has ElectricCharge defined as a resource. All you need to do is replace ModuleCommand with ModuleRemoteTechSPU and set whatever variable you want for EnergyDrain. Remember that you can make it a remote command part by setting isRemoteCommand = false.

Parts that are neither SPUs or antennae don't have any RemoteTech modules at all, so those should work without issues.

[Camacha]

So just to be clear; in addition to the regular requirement of having a probe body or kerbonaut to control a (part of a) vessel, I now also have to have an antenna and contact? The probe body is still mandatory for unmanned flight, since that contains the flight computer?

ModuleRemoteTechSPU should replace ModuleCommand, so it's only for pods. Probably the pod cfg you're looking at already has ElectricCharge defined as a resource. All you need to do is replace ModuleCommand with ModuleRemoteTechSPU and set whatever variable you want for EnergyDrain. Remember that you can make it a remote command part by setting isRemoteCommand = false.

Parts that are neither SPUs or antennae don't have any RemoteTech modules at all, so those should work without issues.

For example, the ProbeCoreCube config has become:

name = probeCoreCube
module = CommandPod
author = NovaSilisko

mesh = model.mu
rescaleFactor = 1

CrewCapacity = 0

node_stack_bottom = 0.0, -0.2845967, 0.0, 0.0, 1.0, 0.0, 0
node_stack_top = 0.0, 0.2845967, 0.0, 0.0, 1.0, 0.0, 0

cost = 500
category = Pods
subcategory = 0
title = Probodobodyne QBE
manufacturer = Probodobodyne Inc.
description = QBE is a sturdy, cubic, and relatively lightweight probe core. It also can survive higher heat loads than its counterparts. Its simplistic shape also appeals to modern art collectors. Truly, something for everyone.

attachRules = 1,0,1,1,0

mass = 0.08
dragModelType = override
maximum_drag = 0
minimum_drag = 0
angularDrag = 0
crashTolerance = 30
maxTemp = 3100

explosionPotential = 0

rotPower = 0.5
linPower = 0.5

Kp = 1.0
Kd = 1.0

vesselType = Probe

MODULE
{
	name = ModuleCommand
	minimumCrew = 0

	RESOURCE
	{
		name = ElectricCharge
		rate = 0.02777778
	}
}

RESOURCE
{
	name = ElectricCharge
	amount = 5
	maxAmount = 5
}

MODULE
{
name = FARControlSys
}
MODULE
{
name = FARBasicDragModel
S = 0.5

	CdCurve
	{
		key = -1 0
		key = 0 0.3
		key = 1.0 0
	}
	ClCurve
	{
		key = -1 0
		key = -0.5 -0.03
		key = 0 0
		key = 0.5 0.03
		key = 1 0
	}
	CmCurve
	{
		key = -1 0
		key = -0.5 -0.01
		key = 0 0
		key = 0.5 0.01
		key = 1 0
	}
}

// --- RemoteTech parameters ---
MODULE
{
	name = ModuleRemoteTechSPU
	minimumCrew = 0
	EnergyDrain = 0.02777778
	isRemoteCommand = false
}

RESOURCE
{
	name = ElectricCharge
	amount = 5
	maxAmount = 5
}

I just added the RT code to the FAR configs, but I see that the ModuleCommand you mentioned is still there. The resources also seem to be defined twice. I should remove those or is it not really a problem? It does seem to work, but I'm not sure it might cause problems.

I also just realised I will need to add FAR code to the Remote Tech command pods/rings, because I think those won't work properly otherwise.

Finally I noticed that Damned Robotics parts are still controllable when the connection is lost. It doesn't change much gameplay wise and I think I understand why it works like that, but it feels a bit weird

[Tase]

Having the "List comsats" page open brings my FPS to 10.

This is what it displays: http://i.imgur.com/vJVEFCm.jpg

[JDP]

So just to be clear; in addition to the regular requirement of having a probe body or kerbonaut to control a (part of a) vessel, I now also have to have an antenna and contact? The probe body is still mandatory for unmanned flight, since that contains the flight computer?

Anything that contains a ModuleRemoteTechSPU will add the flight computer, input locking, and everything else RemoteTech to the vessel. It's always been the case that you need something to control your vessel in order to be able to control it. Either crew on board or a connection to a command station.

I just added the RT code to the FAR configs, but I see that the ModuleCommand you mentioned is still there. The resources also seem to be defined twice. I should remove those or is it not really a problem? It does seem to work, but I'm not sure it might cause problems.

I also just realised I will need to add FAR code to the Remote Tech command pods/rings, because I think those won't work properly otherwise.

Having a ModuleCommand on the part as well shouldn't be a problem, but it is unnececary and just puts more strain on your CPU. In essence you hav two ModuleCommand modules (one of them RemoteTech) where you only need one.

Finally I noticed that Damned Robotics parts are still controllable when the connection is lost. It doesn't change much gameplay wise and I think I understand why it works like that, but it feels a bit weird

Sadly I cannot implement signal delays in other mods. I've implemented an interface into RemoteTech to make it possible for other modders to implement signal delays themselves in case their mod is used with RemoteTech.

Having the "List comsats" page open brings my FPS to 10.

This is what it displays: http://i.imgur.com/vJVEFCm.jpg

You'll have to show a bit more than than. You should include the output log. You can find that in: \KSP_Data\output_log.txt

[oggylt]

Just converted my 36 flight save manually to RT 5.0... version i added willactivateonpanic(or smthing) to true to long antenna so i could reestablish the low range sat connections and for far-away probes i edited save to set the pointed at to "Kerbin" and modstate to 1 and range to appropriate, i only had to do so for only one sat in eve's orbit cause others could communicate through it and then to turn on dishes by themselves, also i redeployed the dish i edited in save to reset any wrong values i might left over so i am really happy about that, also as far i saw the new version is great and looks nifty

1 minor though.. i noticed increased lag while list comsats window is opened i turned off unfocused control but still..

Thanks JDP )

[Camacha]

A minor quibble I've found is not being able to program any mission parameters or vectors in advance. I real life, temporarily losing contact is not a big problem, as long as it is planned and a connection can be re-established somehow. Launching satellites into orbit without contact should not be a major problem, since everything could be programmed in advanced, with the craft looking for contact afterwards. I think this is a general problem with KSP though, the problem is just somewhat more visible due to this mod.

Except for that little bit this mod adds a lot of realism and - in my book - fun!

Anything that contains a ModuleRemoteTechSPU will add the flight computer, input locking, and everything else RemoteTech to the vessel. It's always been the case that you need something to control your vessel in order to be able to control it. Either crew on board or a connection to a command station.

I had a little test around. Adding just an antenna to a part does not work, unless you add some kind of command module. The only exception is the RemoteTech RC antenna, which functions as a command module too.

[JDP]

...I noticed increased lag while list comsats window is opened i turned off unfocused control but still..

Thanks JDP )

A bit of extra lag should be expected, since it takes some computation to check whether you are in contact with a vessel or not. Right now this computation goes on every frame, which might be a bit overkill, and I could see how it could cause lag on slower CPUs or massive relay networks. I'll look into handling the computation in the same way I currently handle the computation that calculates the shortest signal path. That should get rid of the lag, but you might experience a small "hiccup" every second if you're on a very slow computer.

I've thought about running the heavier calculations in their own thread, but as the devs have said a lot of times, there are some big problems with multithreading in Unity. Still I hear r4m0n and The_Duck have managed to implement multithreading in MechJeb 2. So there might be some hope for an implementing the relay network a bit smoother.

A minor quibble I've found is not being able to program any mission parameters or vectors in advance. I real life, temporarily losing contact is not a big problem, as long as it is planned and a connection can be re-established somehow. Launching satellites into orbit without contact should not be a major problem, since everything could be programmed in advanced, with the craft looking for contact afterwards. I think this is a general problem with KSP though, the problem is just somewhat more visible due to this mod.

Making a dedicated launch autopilot is certainly doable. but doing it would be a big job to do. I'm still hoping that Harv expands the maneuver node system to also allow you to set up a launch profile, in which case I'll implement the stock launch profile system into the flight computer. Either loosing connection partway through launch isn't that much of an issue anymore, since most launch profiles have you abve 70 km when you lose signal. That's more than enough height to set up your circularization burn in the flight computer and let it handle the rest of the launch.

I had a little test around. Adding just an antenna to a part does not work, unless you add some kind of command module. The only exception is the RemoteTech RC antenna, which functions as a command module too.

Well adding just an antenna only adds the antenna functionality. If you want your part to command the ship you'll need a moduleCommand. And if you want RemoteTech to control your ship, you'll need to add a ModuleRemoteTechSPU, which as said earlier is actually also a ModuleCommand, so you don't need that module if you have a ModuleRemoteTechSPU.

Of course if you launch a vessel where none of the parts have ModuleRemoteTechSPU RemoteTech will simply ignore the vessel and it will behave as if it where completely stock, just like what always has been the case (if we overlook some unfortunate input lock bugs in older versions).

In this new version of it's pretty straight forward, what you add in the way of PartModules is what's going to be on the ship. A part can have multiple antennae, dishes and even SPUs (though you only really need one of those). Take a look at the AeroProbe for example. It has both a ModuleRemoteTechSPU, a ModuleRTAnimatedAntenna (controlling the omni) and a ModuleRTModalAntenna (controlling the dish). So the part has remote control (which comes with a built in ModuleCommand) and two antennae that can be controlled individually in the context menu and action groups.

Edited April 22, 2013 by JDP