Jump to content

JDP

Members
  • Content Count

    301
  • Joined

  • Last visited

Community Reputation

59 Excellent

About JDP

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That's the main reason for signal delay in RemoteTech: to slow it down
  2. So you're basically SuperDad. Either that, or you neglected listing experimenting with human cloning.
  3. 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 ch
  4. 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 ins
  5. 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 func
  6. 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.
  7. 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.
  8. 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 KS
  9. 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.
  10. 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.
  11. 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 s
  12. 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
  13. 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: SpeedOfLi
×
×
  • Create New...