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

[DerekL1963]

And here's a cfg that has the new stuff: (note: configured for RSS; you'll want to change stuff back for regular KSP)

ConsumptionMultiplier = 0.05
RangeMultiplier = 10
ActiveVesselGuid = 35b89a0d664c43c6bec8d0840afc97b2
SpeedOfLight = 3E+08
MapFilter = Omni, Dish, Planet, Path
EnableSignalDelay = False
RangeModelType = Additive
MultipleAntennaMultiplier = 1.0
ThrottleTimeWarp = True
DishConnectionColor = 0.9960784,0.7019608,0.03137255,1
OmniConnectionColor = 0.5529412,0.5176471,0.4078431,1
ActiveConnectionColor = 0.6588235,1,0.01568628,1
GroundStations
{
	STATION
	{
		Name = Mission Control
		Latitude = -0.131331503391266
		Longitude = -74.594841003418
		Height = 75
		Body = 1
		Antennas
		{
			ANTENNA
			{
				Omni = 7.5E+07
			}
		}
	}
}

So what do you reconfigure for regular KSP?

[Rokker]

There actually is pretty much no such thing as KSP Mod Incompatibility unless you're using BIG mods like Universe Replacer and I believe Planet Factory as well(at least from what I have gathered from playing the game with mods and stuff since 0.20)

planet factory? what? im running like 20-30 mods with planet factory

[thecoshman]

Inability to activate a dish without a connection might not be realistic since, if such a scenario was possible in real life (which it likely isn't,) a fail safe, in the form of a couple lines of code, would be built in that allows the dish to be activated and pointed at a specific location.

Well, the way I figure it, if you turn off all the dishes on your satellite, you actively chose to do that whilst directly controlling it. If that means you have now closed the final communication channel, so be it. The last thing the satellite was told was that it should no longer communicate. However, it is very easy for you to render a satellite inoperable by doing something to some other satellite, or just passing through a black spot for those few satellites it is set to communicate with. In which case, for me at least, I would like to still be able to tell this now connectionless satellite where to point to to try to get that connection back, and I would rationalise it as saying it is a tiny boot strap program on the satellite but it is easier for the mod to simulate it via having me tell it where to connect to. Now I realise there are some who feel even that is too 'cheaty'. The way I see, there are a few options for how to handle satellites that have no active connection.

1. Tough luck, maybe you should have left that small omni-directional antenna activated
   
2. Allow 'dead' satellites to have targets set for ACTIVE dishes - this simulates a program running that sweeps for a connection
   
3. Allow 'dead' satellites to have targets set for ACTIVE dishes - but also impose a distance based delay until the connection actually works again representing the time it takes for the signal to be found
   
4. Allow 'dead' satellites to have targets set for ANY dish - this simulates a program running that sweeps for a connection
   
5. Allow 'dead' satellites to have targets set for ANY dish - but also impose a distance based delay until the connection actually works again representing the time it takes for the signal to be found
   
6. Have a 'dead' satellite automatically sweep for a connection with ACTIVE dishes
   
7. Have a 'dead' satellite automatically sweep for a connection with ALL dishes
   
8. Allow dishes to be controlled via EVA, in which case both target can be set and dishes activated
   

Now, I like to think we can start to discuss these possibilities, so if you do want to refer to the options I have presented here, please link back to this post (rather than quoting) so people can see some context.

Personally, I think option 8 (allowing EVAs) should be added any way (It might even be, I'm not sure). I can see the appeal of options 1 for most players, it is the most stringent way of dealing with the situation. Options 4, 5 and 7 all allows dishes to be activated, which I think is a bit too much, especially when you consider the last thing you told that satellite was to stop listening for commands. I think 6 is nice ideas from a players point of view, but implementation wise would be too much. So yes, option 2 or 3 is where my money is at, I think that the delay imposed by option 3 would be a PITA to have to deal with, but it would be a fair punishment for not planning things out properly.

[calkurne]

I almost got to orbit in RSS, then the communications line was severed. despite the engine having plenty of fuel and being put to full thrust before the end of the connection, it was deactivated by Remote-tech.

why is this a "feature"?

[krenshala]

While for the most part I agree with you, thecoshman, having omni's sweep for signals would be perfectly reasonable but dishes would need to be properly oriented to receive the target signal. Usually this would be by uploading a targetting program so the dish points in the correct direction, however, I can also envision the sat being preprogrammed with at least one fall-back target in case its primary comms link goes down and the satellite in question isn't the problem.

I don't know how much extra work it would take to change the targetting behavior to allow a secondary target to be specified. Probably not worth the effort when your suggestion of letting the player retarget the dish is easier to implement. Then things get back to "how much realism do we want?". On the one hand, letting the player retarget can simulate preprogramming. On the other hand, the player making decisions is currently assumed to be programs uploaded from KSC and if you are 'not connected' you can't upload programmatic changes. On the gripping hand, its pretty much up to Cilph how he will resolve this one in the end.

Edited December 23, 2013 by krenshala

[DerekL1963]

Then things get back to "how much realism do we want?". On the one hand, letting the player retarget can simulate preprogramming. On the other hand, the player making decisions is currently assumed to be programs uploaded from KSC and if you are 'not connected' you can't upload programmatic changes. On the gripping hand, its pretty much up to Cilph how he will resolve this one in the end.

You're over thinking this. With the simple setup of allowing the user to retarget (but not reactivate), the user chooses how much realism he wants. Those that want to roleplay a few lines of code can do so, those who play hard mode can simply not use the option, and everywhere in between.

[DerekL1963]

I almost got to orbit in RSS, then the communications line was severed. despite the engine having plenty of fuel and being put to full thrust before the end of the connection, it was deactivated by Remote-tech.

why is this a "feature"?

It's a feature because that's the whole point of Remotech - you need a communications link.

[ludsoe]

It's a feature because that's the whole point of Remotech - you need a communications link.

So what told the engine to turn off if he doesn't have a link?

[calkurne]

It's a feature because that's the whole point of Remotech - you need a communications link.

I think you're missing what I did

>Get to orbital stage

>activate stage and go to 100% thrust

>start burn

>loose connection

>remotech kills burn

I would hope that I could trust the inboard computer to hold the craft on prograde until it ran out of fuel

[n01487477]

I think you're missing what I did

>Get to orbital stage

>activate stage and go to 100% thrust

>start burn

>loose connection

>remotech kills burn

I would hope that I could trust the inboard computer to hold the craft on prograde until it ran out of fuel

Well doesn't work like that - sorry. You need to program the computer to do a burn while you have an active link. This can be set up with prograde, node or other variables. But it needs to be set. I like the feature except when it glitches out once in a while - mainly due to probes spinning (unbalanced) or in previous .22 from an unknown mod issue I was having where the engines weren't burning long enough.

[n01487477]

I think you're missing what I did

>Get to orbital stage

>activate stage and go to 100% thrust

>start burn

>loose connection

>remotech kills burn

I would hope that I could trust the inboard computer to hold the craft on prograde until it ran out of fuel

Sorry, but that's not a good idea either for the others that would have craft zooming off into the cosmos or want adjustment burns. I think that it is best to program the onboard computer with the burn details as it already stands. This allows you to burn prograde, node, etc with m/s, time etc ... Do you know how to use the computer nav properly ? I only ask cause it only takes a few mouse clicks to set it up right - as long as you have a connection. If you don't - I'm willing to post a quick youtube video for you.

This is my second post cause the first got lost somehow...

[Moleculor]

So what do you reconfigure for regular KSP?

The following is an ABSOLUTE GUESS from someone in the same boat as other people: I've never used RT2 before, have no settings file, and am attempting to piece one together from scattered forum posts.

(I don't understand why a settings file isn't in the download. That doesn't make sense to me.)

ConsumptionMultiplier = 1
RangeMultiplier = 1
ActiveVesselGuid = 35b89a0d664c43c6bec8d0840afc97b2
SpeedOfLight = 3E+08
MapFilter = Omni, Dish, Planet, Path
EnableSignalDelay = False
RangeModelType = Standard
MultipleAntennaMultiplier = 1.0
ThrottleTimeWarp = True
DishConnectionColor = 0.9960784,0.7019608,0.03137255,1
OmniConnectionColor = 0.5529412,0.5176471,0.4078431,1
ActiveConnectionColor = 0.6588235,1,0.01568628,1
GroundStations
{
	STATION
	{
		Name = Mission Control
		Latitude = -0.131331503391266
		Longitude = -74.594841003418
		Height = 75
		Body = 1
		Antennas
		{
			ANTENNA
			{
				Omni = 7.5E+07
			}
		}
	}
}

[calkurne]

Sorry, but that's not a good idea either for the others that would have craft zooming off into the cosmos or want adjustment burns. I think that it is best to program the onboard computer with the burn details as it already stands. This allows you to burn prograde, node, etc with m/s, time etc ... Do you know how to use the computer nav properly ? I only ask cause it only takes a few mouse clicks to set it up right - as long as you have a connection. If you don't - I'm willing to post a quick youtube video for you.

This is my second post cause the first got lost somehow...

well it "worked" I got into orbit, but only because I had enough ÃŽâ€V to deal with it not actually holding prograde, or anything close to prograde.

I still think that it shouldn't kill the engine, or have that bit be toggleable.

[diomedea]

... I think that it is best to program the onboard computer with the burn details as it already stands. This allows you to burn prograde, node, etc with m/s, time etc ... Do you know how to use the computer nav properly ? I only ask cause it only takes a few mouse clicks to set it up right - as long as you have a connection. If you don't - I'm willing to post a quick youtube video for you.

...

If what you mean is that the RT2 Flight Computer is better than relying only on radio commands, totally agree.

If you mean that the Flight Computer allows to fly a correct ascent profile, then I would like to know how.

I wrote ascent autopilots with kOS, able to adapt to specific profiles and to keep strict control of flight parameters so to maintain the desired profile even if case of unpredicted events, therefore I believe to know something on the subject.

But I can't fly any acceptable profile by just giving commands like "set pitch to 60°, heading to 90° and burn for 30 sec (or for 300 m/s DV)". I want to be able to set a specific altitude with apoapsis and periapsis and obtain a specific inclination of the orbit.

Therefore, if you know how to set apoapsis/periapsis and inclination with the RT2 Flight Computer, I am here to listen; if that can't be achieved, I better rely on radio commands or hope kOS will someday work with RT2 and KSP 0.23.

[Sacred Aardvark]

Sorry, but that's not a good idea either for the others that would have craft zooming off into the cosmos or want adjustment burns.

Because craft zooming off to infinity is so much worse than a craft crashing down to kerbin without any control. One of these is (in theory) recoverable, the other is dust. (hint, the recoverable one isn't the version where the thrust was cut before reaching orbit)

I think that it is best to program the onboard computer with the burn details as it already stands. This allows you to burn prograde, node, etc with m/s, time etc ... Do you know how to use the computer nav properly ?

I'm under the impression that his question was related to the engine -automatically- shutting down when the connection was lost. Not the operation of the FC.

I almost got to orbit in RSS, then the communications line was severed. despite the engine having plenty of fuel and being put to full thrust before the end of the connection, it was deactivated by Remote-tech.

why is this a "feature"?

Just a guess, but I think it's because KSP doesn't let you save or change ships while throttled up, thus leaving the throttle open would get you stuck on that vessel until it got a connection again, if it ever would.

[Creat]

Even though I'm still relatively new to RemoteTech, I'd still like to chime in on the whole "Failsafe-Debate".

I don't think it's worth the time and effort to implement a full failback system, possibly allowing complex mechanisms for what dishes should target in case the lose contact. Even just the "target anything in the same SoI" seems already unnecessarily complicated: imagine that in the SoI of Kerbin in a old save with dozens of crafts (or more). Make it a simple config file switch with only two options: Assume failsafes exist, or losing connection is permanent.

This gives those who want the possibility of failures as a behavioral option, and - like others have suggested - the player acts as the fail safe for those who want one. It's much simpler and allows for as complex a backup as you (the player) can imagine, you just have to execute it yourself. You want to target a specific vehicle? Target it. You want to fly a rescue mission to re-establish contact? Launch the ship and target it once it's in the desired recue-/contact-range. You want anything in the current SoI? Just pick a target in the current SoI.

There are so many wonderful features being talked about or planned (or even already in development) for this mod. The effort it would take to properly do an actually worthwhile fail safe mechanism are just not worht the effort in my opinion, as it's much simpler to juts let the player act as the fail safe himself. As I said, make the ability to reconnect once contact is lost permanently a config file option and most people should be reasonably happy

[HoneyFox]

Just come to give you a feature request. And i think it will be very useful

Can you add a new target named "Active Vessel's Main Body"? This will be very useful to establish interplanetary comm network.

Suppose we have several commsats on kerbin's orbit, and they are all set to "Active Vessel's Main Body".

Now if the active vessel is in the same SOI as these commsats, we can write logic to make them use "Active Vessel" logic to aim towards the current active vessel.

If the active vessel is in other SOI like Mun/Duna/Eve/..., they will use "Active Vessel's Main Body" logic to aim towards Mun/Duna/Eve.

Thus for example, if we have a comm network orbiting Duna, and we have a rover on the back side (relative to Kerbin) of Duna, we can set all Duna commsats to aim towards Kerbin, thus establish the Kerbin-Duna comm network interconnection. Now even if you are controlling the rover at the back side of Duna, the Kerbin's comm network won't aim directly to the rover but to Duna so that the interconnection won't break.

[John Nowak]

If that's not an option, what about a (short) list of connection priorities?

I like this. Either have a list of objects to point at or allow wildcards in the names of targets.

Say I have a communications network of three satellites, called Comms 800-A, Comms 800-B, and Comms 800-C. Either let me connect to "Comms 800-?" or "Connect to Comms 800-A. If no connection, connect to Comms 800-B."

That said, I've got two suggestions for other users:

1) Always F5 before changing the target on a probe.

2) I've noticed that if you open the target of a probe and switch it to a target that is not in communication, the indicator under the clock will turn red. This gives you a chance to change the target back before closing the window.

Anyway, it's an incredible mod. I don't like playing without it. Sitting in orbit around Minmus waiting for a window to open up so i can transmit science is a lot of fun.

[John Nowak]

I almost got to orbit in RSS, then the communications line was severed. despite the engine having plenty of fuel and being put to full thrust before the end of the connection, it was deactivated by Remote-tech.

why is this a "feature"?

Actually, that strikes me as a perfectly reasonable safety measure.

If you lose communication with a vehicle that needs a control link, you can either cut the engine or let it run. If you cut the engine, you'll have fuel on board if you're able to re-establish communication. If you let it run, it's probably going to burn through all the fuel before you establish communication again -- with a probe that can't be controlled.

Sure, if the engine cuts off while going into orbit, you'll crash. But if the engine stays on while going into orbit, you'll probably go into an orbit with 500km apoaps and -600 periaps. You'll crash anyway.

[HoneyFox]

Actually, that strikes me as a perfectly reasonable safety measure.

If you lose communication with a vehicle that needs a control link, you can either cut the engine or let it run. If you cut the engine, you'll have fuel on board if you're able to re-establish communication. If you let it run, it's probably going to burn through all the fuel before you establish communication again -- with a probe that can't be controlled.

Sure, if the engine cuts off while going into orbit, you'll crash. But if the engine stays on while going into orbit, you'll probably go into an orbit with 500km apoaps and -600 periaps. You'll crash anyway.

Well, why not just provide an option for users to decide...

if they have very good calculated rocket deltaV budgets, these rockets can even get into orbit with no communication at all. (though there might be some error of the orbit, but that can be fixed later when they re-establish communication)

At least i've done similar thing when using a fully solid fuel rocket... you know solid rocket cannot be shutdown.

[thecoshman]

Personally, I think the correct thing for RT2 itself to do is cut all engines if the vehicle loses connection.

What would be really nice is tight integration with kOS. KOS is a mode that let's your write small scripts, such as 'launch to orbit' scripts, that will be executed on your probe (or manned vessel). It would be nice if there was some way of letting kOS scripts run even if the vessel has no comms connection. Of course the script would have to be started before connection is lost. This does still have the slight issue of what happens if there is a bug in your script that stops it from ever ending, and it keeps the throttle held high and thus unable to change from the vessel... for the sake of game play, might need a way to kill a script... but this is a kOS issue really...

[Himidori Shoumoto]

Just come to give you a feature request. And i think it will be very useful

Can you add a new target named "Active Vessel's Main Body"? This will be very useful to establish interplanetary comm network.

Suppose we have several commsats on kerbin's orbit, and they are all set to "Active Vessel's Main Body".

Now if the active vessel is in the same SOI as these commsats, we can write logic to make them use "Active Vessel" logic to aim towards the current active vessel.

If the active vessel is in other SOI like Mun/Duna/Eve/..., they will use "Active Vessel's Main Body" logic to aim towards Mun/Duna/Eve.

Thus for example, if we have a comm network orbiting Duna, and we have a rover on the back side (relative to Kerbin) of Duna, we can set all Duna commsats to aim towards Kerbin, thus establish the Kerbin-Duna comm network interconnection. Now even if you are controlling the rover at the back side of Duna, the Kerbin's comm network won't aim directly to the rover but to Duna so that the interconnection won't break.

Still waiting for the RT2 for 0.23.

I think HoneyFox got a very good idea.

I am wondering if it is possible for a satellite to make connection with a planet instead of another satellite.

For example, if I can let a satellite orbiting Kerbin point to Duna (instead a satellite over Duna) and make connection with all the available satellites that orbiting Duna and Ike？

[Zander]

sorry I havent read the whole thread but is there any word on when he will update for .23?

[KerbMav]

Execute node does not aim at the navnode before burning the set dV.

Can this be fiddled in?

[Himidori Shoumoto]

Just come to give you a feature request. And i think it will be very useful

Can you add a new target named "Active Vessel's Main Body"? This will be very useful to establish interplanetary comm network.

Suppose we have several commsats on kerbin's orbit, and they are all set to "Active Vessel's Main Body".

Now if the active vessel is in the same SOI as these commsats, we can write logic to make them use "Active Vessel" logic to aim towards the current active vessel.

If the active vessel is in other SOI like Mun/Duna/Eve/..., they will use "Active Vessel's Main Body" logic to aim towards Mun/Duna/Eve.

Thus for example, if we have a comm network orbiting Duna, and we have a rover on the back side (relative to Kerbin) of Duna, we can set all Duna commsats to aim towards Kerbin, thus establish the Kerbin-Duna comm network interconnection. Now even if you are controlling the rover at the back side of Duna, the Kerbin's comm network won't aim directly to the rover but to Duna so that the interconnection won't break.

Still waiting for the RT2 for 0.23

I think HoneyFox got a very good idea.

Is it possible for a satellite to make connection with a planet instead of another satellite？

For example, is it possible to make a satellite orbiting Kerbin point to Duna and make connection with all the satellites (that point to Kerbin,of course) orbiting Duna and Ike in the available raycast?

HoneyFox said it will make the calculation much more complex, but I think this will make the game more comfortable……