JDP

That's the main reason for signal delay in RemoteTech: to slow it down

So you're basically SuperDad. Either that, or you neglected listing experimenting with human cloning.

A quick disclainer: yours truly isn't really an RT dev anymore. At most, I'm an infrequent contributor. Since signal delay won't be added, there will still be a place for RT. The only change is that the relay network would now be maintained by stock. We'd still need RT to impose challenges coming from signal delay. Possibly, this would even help to focus efforts a bit, since devs can now focus entirely on the game mechanic of signal delay and providing tools to allow players to still do cool stuff like interplanetary transfers, landing, flying and rovering around. I am a bit saddened by the choice only to include omnidirectional antennae. But I do understand how dish management might not harmonize that well with what the devs historically have wanted stock game mechanics to feel like. TL;DR: Basically only the core RT prerequisite; relay network implementation, is going to be stockified. a future RT implementation could easily build on this for a more RT feel of signal delay and flight computer madness.

When it comes to line-of-sight checks, each celestial body is treated like a perfect sphere. It would be an order of magnitude more taxing to do a raycast for each satellite link than to just do a simple trigonometric line-sphere intersection check, even when taking into account that the check must be done with every celestial body in the kerbol system for each link. The vessel doesn't need to be active for queued commands to fire. It does however need to be loaded. Unloaded vessels don't really exist as physical objects, basically just some orbital informations and instructions on how to instantiate a physical object once the vessel is loaded. In stock KSP a vessel is loaded if it is within a 2.5 km radius of the active vessel (which of course includes the active vessel itself). In the tracking station no vessels are loaded, not even the focused one. So to answer your question, yo can queue up commands on one vessel and then switch to another vessel while waiting for the commands to activate. You just cannot switch to a vessel that's further than 2.5 km away, or your first vessel will to some extent seize to exist. Of course the commands will be saved along with anything else about the vessel, so you can come back to the vessel at a later time when the commands are set to activate. You could use [thread=24786]Kerbal Alarm Clock[/thread] to help you with keeping track of everything.

From your description, it sound like RemoteTech works just fine. The fact that you're seing the red icon indicates very strongly that at least the code part of RemoteTech is installed just fine. It sounds like you are just in local control (the kerbal in the pod having direct control of the ship) but don't have the requisite parts for the ship to send/receive signals with KSC. In order to remote control a satellite, you need two things: An activated antenna, with a connection to KSC and a SPU (Signal processing unit) to process the signal. The pods (the ones that can carry kerbals) do not function as SPUs, you'll need one of the the probe cores for that. Also make sure that your antennae are actually activated. Basically only the Reflectron DP-10 starts out activated. It also won't blow off in flight when deployed like most of the other antennae will do. RemoteTech has somewhat of a steep learning curve. I recommend you read the wiki before going much further. Of course it might be that ModuleManager isn't installed. Most of the modules added by RemoteTech are added through ModuleManager. maybe try posting a screenshot of your ship, so we can take a look at what parts you've put on it.

That's an excellent idea. You can suggest that over on the RemoteTech github. RO should add a whole bunch of ground stations. From looking at the config available at the RO github it looks like they are using an old format. The config must be wrapped in a RemoteTechSettings node. It looks like this might be the problem. Wrapped correctly, the settings file should look like this.

Do they both have a signal processor? Signal processors are needed both to remotely control a vessel and relay signals to other vessels. the stock probe cores all work as signal processors, the stock pods however do not. If both your satellites have a probe core, maybe it could be helpful with some screenshots of both the satellites and the map view. Oh, and by the way, the communotron-16 is an omnidirectional antenna, so it will be in contact with any other satellite(s) within it's and their range. You only need one.

The main reason is trigonometrics i think. A vertical line downwards towards the ground station will often be shorter than any line off at an angle towards another orbiting satellite. So you'd find yourself in a situation where your satellites are within range of KSC when they are above it, but not in range of each other, that way they won't be able to relay any signals. And another note. Are you absolutely sure about the altitude of 6 million metres? that would be halfway to the mun. (of course you could be playing in a rescaled world). At 6 million metres you should be far out of range of KSC with the antennae you're using, and very very far out of range with the other satellites, providing you have a constellation of 3. Are your satellites perchance manned? or do they use probe cores added from other mods? that would give them local control, meaning that the crew or probe on board will be able to control the satellite directly, even when out of contact with a control station. Dishes don't need to be physically pointed at their target. Requiring this would make the game pretty much unplayable. In stead you select the target for each dish from a context menu (right click the dish and you can set a target). RT does have a pretty steep learning curve. I'd recommend you read the intro of the wiki from start to finish to save yourself from any headaches caused by common misconceptions. And pour yourself a hot cup of coffee for the read. It's an excellent analgesic for misconception related headaches and good for mind and spirit

Signal Processing Unit.

I've just tested this and could not reproduce. Mostly the cause for this is using probe cores that are not implementing moduleSPU. They will be registered as a valid control source, giving the vessel local control (meaning instantaneus control) even when there is no crew.

It was never gone in the first place. I've been keeping it (sort of) updated throughout releases. I never could get the antenna animations to play properly with the new handling of RT2 though.

The main problem here is that PartModules don't actually exist in unloaded vessels. The vessel itself only exists as a set of data, not much code is run. At a part and partmodule level, no code at all is run. So for unloaded vessels you need a separate bit of code to run in the backbround and calculate changes in values such as electricCharge in batteries based on values of +/- electric charge per second in probe cores, RTGs and solar panels. This is exactly what BackgroundProcessing does. This means that you don't need to add any modules to probe cores, RTGs and solar panels (in fact, doing so would get you nothing, since those modules would be destroyed the moment the vessel is unloaded). The plugin continuously runs in the background and takes over the power drain / generation functionality of those parts when they are unloaded. Of course you could also do it with a small plugin that remembers each vessel and how long it has been unloaded and then simply calculates the net value for electricCharge whenever a vessel gets loaded in pseudocode for each probe core: netPowerDrain = probe core power consumption per second * time since unload for each RTG/solar panel netPowerGenerated = RTG/solar panel power production * time since unload netPowerChange = netPowerDrain + netPowerGenerated VesselTotalCharge = VesselTotalCharge + netPowerChange This however has a few drawbacks. For example if you switch to your vessel while it is in the dark, behind a planet/moon, this method would assume that it was without sunlight the entire time and wouldn't calculate any power generated from the solar panels. Another advantage of the way BackgroundProcessing does it, is that other mods can act on changes in unloaded vessels while they are unloaded. For example, if RemoteTech ever where to implement BackgroundProcessing, unloaded satellites could go out of power and the mod would actually know about it as it happened and remove that satellite from the relay network. Hmm. That might be a good idea actually. I think I'll go implement BackgroundProcessing in RT

If the code for RemoteTech where running, your timewarp control (The bit up in the upper-left corner of the screen where you can change timewarp and see which time it is) would have an extra field showing you your current signal delay and giving you access to the flight computer. Since this is not there, the only conclusion is that you either are running a very old version of RemoteTech or that RemoteTech isn't running at all. To check if the code part of the plugin is even installed, you should look in GameData\RemoteTech\Plugins. If you don't find a file called RemoteTech.dll in there, then something very important is definitely missing. There also seems to be some issues with loading textures. It doesn't look like the texture for the dish you are using is loaded. If everything is in its place within your GameData folder, there might be some file access problems within KSP. If your game folder is somewhere in a folder like Documents, this can sometimes occur.

Well in the old days of RT1, this was done by having the signal delay be a round trip delay. You would simply wait twice as long for the probe to visualy act on a command, simulating not only an uplink delay for the command, but also a downlink delay for the visual feed and telemetry. Of course this in actuality is simply doubling the delay RT imparts on commands. You can still do this with with RT2; simply halve the speed of light in the config file (Once RemoteTech has been run once, you can find it in: GameData\RemoteTech\RemoteTech_Settings.cfg. the value you need to change is: SpeedOfLight = 3E+08 to SpeedOfLight = 1.5E+08 This is in fact what I do. I would be a proponent of the realism of a round trip delay, but I also see the need to maybe constrict the possible max delays you would be experiencing in-game, simply from a gamemechanic viewpoint.