[1.11] RemoteTech v1.9.9 [2020-12-19]

[aluc24]

@tomek.piotrowski Hello! I am a big fan of RemoteTech. I'm now playing a career with RT and lots of other mods. However, as I progressed into it, I noticed my FPS drops with each new flight. With just 12 flights going on, my FPS in KSC dropped to 15 (with no vessels, it's 40-60). When I removed RemoteTech from Gamedata folder, the FPS went back up to 40 in KSC, same career, same number of flights. It appears that RemoteTech eats a lot of CPU power. Is this a bug, or a "feature"? Is there a fix for it?

[Ippo]

Hello,

I had made my own custom settings back before KSP 1.1 came out. I have now found out they are not working anymore. This config file was supposed to add more stations around the planet, but when I load my game the KSC is the only base.

Can anyone help me to port the settings to the latest RT version? Thanks.

[KerbalExplorer]

Bug Report regarding use of RT v1.7.1 with ScanSAT v16.3 in KSP v1.1.3 x64: Scans of bodies using a satellite that has no link to KSC (directly or indirectly) continue to perform as normal. For instance, in my current game, my Minmus scanner probe (biome and altimetry sensors) has only a C-16 antenna and can't communicate with KSC (I sent it out before RT was active on my game), yet my scans are increasing in completion.

[blu3wolf]

Isnt that something that should be handled by SCANsat?

[d4rksh4de]

On 7/29/2016 at 1:20 AM, nightingale said:

@tomek.piotrowski - I have no idea who to ask, so I'll start with you.  Can I have permission to use the RemoteTech logo in the RemoteTech contract pack?  Here's how it would be used in game.  Also note that the contract pack itself is under the CC BB-NC-SA 4.0 license (I don't know who created the image, or if they were explicit in setting a license for its use).

Rough93 made the logo for RT, I believe it's OK to use it.

[blu3wolf]

So Ive got a probe instructed to point to TGT prograde at the moment. The tooltip says that TGT prograde is directly towards the target. Instead, its orienting itself to orbital prograde, which is not really the same thing at present. Known bug?

[DrPastah]

Does this work in Career? I don't see the parts in VAB or in the science tree. I tried unlocked all the facilities to max and I don't see the parts.

Edited August 5, 2016 by DrPastah

[ExplorerKlatt]

38 minutes ago, DrPastah said:

Does this work in Career? I don't see the parts in VAB or in the science tree. I tried unlocked all the facilities to max and I don't see the parts.

Yes it does work in career mode. This problem is usually a caused by improper installation. Can you post a pic of your GameData folder?

Edited August 5, 2016 by ExplorerKlatt

[DrPastah]

1 minute ago, ExplorerKlatt said:

Yes it does work in career mode. This problem is usually a caused by improper installation. Can you post a pic of your GameData folder

I see the issue, I didn't have the module manager dll.

[Diche Bach]

ADDIT: hold on . . . I think I was in error that I have a bad install, so scratch everything I posted below . . .

I just spotted the Communotron 88-88 in a tech called "Electronics" which is at the 7th tier (300 science level) and I haven't got that far yet . . . Communotron 32 must be around here somewhere, and that is the one I want to use for my first relay network so I'll hunt it down in the tech tree. I'll probably find it by going through it real slow but appreciate if anyone familiar with the Community Tech Tree can point me at the right one.

-strike all below-

9 hours ago, DrPastah said:

I see the issue, I didn't have the module manager dll.

I think I may be having a similar issue. The communotron 32 isn't showing up in my tech tree (which is retooled with Community Tech Tree mod).

Anyone see anything obviously wrong here?

And here is a closeup of my RemoteTech sub-directory

I'm guessing that using the Community Tech Tree is causing some sort of issue that is causing some of the RemoteTech parts to fail to become available at appropriate tech levels?

Edited August 5, 2016 by Diche Bach
correction; previous question erroneous

[Zhetaan]

@Frida Space:

@SilverlightPony has it right.  You can't have a one-way, 'pass-down-the-line' link such as you have set up.  If you intend to connect your satellites by dish antennas, then you need to point dishes on both satellites so each satellite looks at the other.  If you're getting two-way connectivity without this, then there is something else going on:  either you have omnidirectionals you didn't mention, or else you're catching something in the cone of your dish signal.

 

@KerbalExplorer:

Not a bug; this is intended behaviour per the SCANSat literature.  When you tell a scanner to run, it will continue to run until you tell it to stop or the scanner is destroyed. If it runs out of power, it waits until it gets more power and picks up scanning again.  It's set to do this because you can then let it scan while you do other things (and in my opinion is reasonably realistic; if you send the probe a command, it should be intelligent enough to execute that command after LOS).  If you want more information or to know whether you can set it to shut down on LOS from RemoteTech, you'd be best served asking the SCANSat people in the SCANSat thread.

 

@Diche Bach:

The Communotron-32 is in High-Power Electrics; it's the greyed-out node directly below Electronics.  It appears that you'll need to unlock Advanced Electrics to get to it, though.  Also, so far as I know, RemoteTech does not yet have CTT implementation.  The RT antenna parts are all on the stock tree, which CTT does not modify (it only adds extra nodes for modders to use; it does not rearrange the tech from stock).

Edited August 6, 2016 by Zhetaan

[KerbalExplorer]

5 hours ago, Zhetaan said:

Not a bug; this is intended behaviour per the SCANSat literature.  When you tell a scanner to run, it will continue to run until you tell it to stop or the scanner is destroyed. If it runs out of power, it waits until it gets more power and picks up scanning again.  It's set to do this because you can then let it scan while you do other things (and in my opinion is reasonably realistic; if you send the probe a command, it should be intelligent enough to execute that command after LOS).  If you want more information or to know whether you can set it to shut down on LOS from RemoteTech, you'd be best served asking the SCANSat people in the SCANSat thread.

Thank you for responding. I was anticipating that a scan would proceed normally but not be "sent" home unless a connection was present. Perhaps that would be too difficult to implement, or perhaps no one cares about this. Either way, thanks again for addressing this.

[Zhetaan]

5 hours ago, KerbalExplorer said:

I was anticipating that a scan would proceed normally but not be "sent" home unless a connection was present. Perhaps that would be too difficult to implement, or perhaps no one cares about this.

Oh!  I see what you mean now.

In that case, yes, it would be extremely difficult to implement.  Shutting off the scanner entirely at loss of signal would require DMagic to rewrite the background processing code to mesh with RemoteTech somehow.  Having the scanner continue to operate, but 'queue' the data in some internal buffer until the signal is reacquired would require a total rewrite.  The way it works now, you can for example have six probes scanning all at once, and they will all add their data to a communal pool.  This makes the mod fast, requiring little processing time, because it all reveals one map.  So far as I know, there's no way for RemoteTech to interfere with that, and there won't be one unless DMagic builds it into SCANSat; that functionality is very much in his coding jurisdiction.  I strongly doubt DMagic would be interested in doing so, either:  having to keep track of six separate scan maps plus the master map, poll the probes for the data (or be denied because of no link), and to update those maps (plus the master) would add to the processing time by a factor of how many scanners you had in the solar system.  Given that DMagic has been pursuing leaner code, faster loading time, and better memory management with that mod practically since he took it over, I think this is one of those times that you'll have to accept that KSP must ignore the realities of spaceflight in order to favour the realities of current computer technology.

I admit that it would be an interesting mechanic ... I just don't think it's compelling enough to keep me staring at single-digit frame rates for the half-hour it would take just to find out whether I've gotten another hectare of Kerbin's surface.

That being said, however, there may be a poor-man's way of doing what you want to do ... if you're willing to work for it, and equally willing to put up with a rather hacked-together alternative.  It leaves much to be desired because it would no longer perform background processing (meaning that you'd have to stare at it while it scans, thus limiting you to running one scanner at a time), but if you're willing to install kOS Scriptable Autopilot System, you can write a script that will hook in to RemoteTech, poll for a KSC link, and from that information activate or terminate a SCANSat scanner as it would any other part.  Do please keep in mind that this is very similar to the way scanning used to work, and getting away from the tedium is why SCANSat was written in the first place--but it can be done.  I would not enjoy it, but you may see something in it.  If you do go for it, I'd be interested in knowing how it worked out for you.

Edited August 6, 2016 by Zhetaan

[KerbalExplorer]

On 8/5/2016 at 10:32 PM, Zhetaan said:

there may be a poor-man's way of doing what you want to do ... if you're willing to work for it, and equally willing to put up with a rather hacked-together alternative.

I don't have experience using scriptable autopilot. Even if I did, I think only a small minority of players would truly be interested in something like this. Besides, the game is quite fun to play with the mods I have. RemoteTech is one of my favorites.

[Diche Bach]

@Zhetaan : thanks man! Yeah i found it

Few questions:

Background: I have one unmanned sat in orbit "Zal 1." This is intended to be the "bow" module of an eventual Kerbal Space Station (taking up the living quarters/victuals/labs is next mission on my list) so it is heavy on the solar power, antenna, monopropellant, alkaline generators, etc.

Top View

Underside (note it has like 8 DTS-M1 antenna on it, they have [supposedly] a 45-degree cone but pretty good range, so I figured long-term having them pointing in pretty much all directions would enable it to serve as a relay for future missions)

Here it is with all the antenna deployed.

So I launched that baby to fullfill a mission for a 'satellite at specific orbit.' the next lower stage was a docked gemini probe, and then the boosters below that. I used it to practice how docking works: got it into orbit, undocked then tried to redock . . . I figured it might be easier to learn that way.

I then moved it to the lower orbit (apo < 250km) to set it up to fulfill a second mission: Kerbal Space Station.

So it is up there right now, and of course, as it is my only orbital antenna it goes out of contact pretty frequently, like  . . . 4 ours out of every 6 hour day it seems!

Okay, my questions:

1. As you can see, I have all the solar panels in one direction: a compromise for costs/size. A subsequent version has a mirror set of panels and "edges" so it should provide more or less 360 coverage. It does have alkaline cells for backup and like 3500 electric power cap . . .

I naturally orient it toward Kerbol while it is in contact, and _sometimes_ it seems to retain this orientation, but then other times, it turns right around. Is this an inherent aspect of orbiting? Is there a way to get a sat to point in a particular direction and ALWAYS try to automatically point in that direction so it doesn't loss contact/power?

2. It seems it is "not a good idea" to try to dock with an unmanned vehicle like this while it is "not in radio network?" I'm certainly no pro on docking (really just now getting the hang of it) and I also am using DMagic's "flexo-docker" on the incoming vehicle so that might be a problem in some way.

What I have experienced is this: I get the incomer lined up, eliminate all radial motion and pro/retro motion and wait a bit to make sure, then slowly pro-grade in with "H" key on RCS thrusters. Get it down to 0.1m/s for the last 30 m. Then come to full stop, and watch it to confirm little to no motion, switch to target (the unmanned satellite) wait for it to come into network and turn it toward incomer . . . actually it didn't work out quite this way: I realized my window for orienting the satellite was nearly closing so I did the "orientation" at more like ~200m gap. Tired and got a bit off center I guess (not even sure how on-center it MUST be for stock let alone this modded docking port) and by the time they were close things were just a hair out of line and the sat had gone out of network. They came into contact at a slight angle and wobbled around for a while and then the sat toppled over and started drifting away spinning a bit at a very unfortunate periodicity/angle: effectively making it much WORSE than it had been.

I don't know if having had the sat in full control all the time might have helped me to dock this (I suspect it would) and that is what this question is really about:

  A. Is it just a "bad idea" to try to dock with an uncontrolled vessel in general?

  B. Is there a way to temporarily disable RT in these instances (to reflect the fact that, the pilot in the incoming manned vehicle should be able to make contact with the target vehicle and effectively 'take control' of it's reaction wheels)?

 C. Might there be any plan to include in the mod functionality so that manned vehicles with sufficient comms equipment can "take control" of unmanned vehicles in their network even when they are otherwise out of network? It might be a coding nightmare, but it would seem cool.

D. Any general suggestions on good/fun/challening/realistic ways to cope with these early career game issues while using RemoteTech?

3. Obviously I haven't got this far yet, and this is sort of a variation of question 1 above, but . . . once I do have a couple more unmanned comm sats up, is there a way to tell them to always maintain orientation in particular directions so that they don't wobble out of contact? I haven't noticed any obvious stuff in the interface, and honestly I'm just exploring it as I go, so if there is such functionality, appreciate if anyone can point me in the right direction.

Phantastic Mod!!

ADDIT: ah one more question:

4. Do the "cones" of effectiveness actually work as advertised? Meaning for example, the ones on that sat, supposed to have a 45-degree cone (which I assume is an actual "cone" shape with the apex and center of the base aligned on the central strut of the antenna when it is deployed?).

Once I got it up there, I fiddled with setting some to target Mun, and some KSC and while the "being on the wrong side of the planet" effect certainly is clear, it was pretty difficult to make out how the "cone" effect was playing into it.

This question might well also be a slight variation on #s 1 and 3 . . .

 

Edited August 7, 2016 by Diche Bach
ADDIT

[Zhetaan]

@Diche Bach:

Holy compound questions, Batman!

Anyway, in order:

#1:

One solution:  The flight computer.  Tell your sat to point to a particular heading (you'll have to figure out which direction points to the sun, though) and it will face that way.  You'll have to revisit it periodically, though, because as Kerbin orbits the sun, the sun, relative to Kerbin, will appear to precess about the sky and thus you'll need to reorient your satellite every few months.  It's probably better the throw a few extra panels around the sides of the next module.

Next solution:  Get the mod Persistent Rotation and select body-relative rotation with respect to the sun once you've got it lined up.  Essentially, this is the same as the above, but where it does all of the calculating and readjusting for you.  It sounds attractive, but keep in mind that it also causes uncontrolled ships to keep rotating indefinitely--meaning that the timewarp-to-stop-spinning trick won't work--so if you're relying on that to help you as you figure out docking, you're going to be making docking a lot more difficult to master.

Permanent-for-the-future solution:  For your next satellite, stick some panels on the ends of those booms you've got (the ones with the ladders on them) and that will give you some coverage in every rotation except with the sun directly behind you.  Just don't shake it too much.

 

#2:

A:  It can be tricky, but good idea or not, it's necessary.  By definition, one of the vehicles involved in a docking procedure is always uncontrolled, because you're controlling the other one.  I think what you're driving at, though, is how to dock with something when you don't have good stability on it and every nudge sends it wobbling off into nothing.  Use the flight computer for that, as well.  Usually the best thing is to tell it to point normal or antinormal.  This is going to come into conflict with having it point towards the sun per the last answer, though.  Here's why:

An uncontrolled but non-moving ship in low Kerbin orbit will always point the same way with respect to the stars.  However, relative to Kerbin's surface, this means that it rotates once every orbit.  Relative to the sun, it additionally rotates once every year.  A craft that is set to point prograde will rotate with respect to the stars once per orbit and be nonrotating with respect to Kerbin's surface.  Since low Kerbin orbit has an orbital period of approximately thirty minutes, this means that such vessels rotate with respect to one another by several degrees per minute, and that can make docking unnecessarily difficult.  Pointing the ship in a radial direction gives you the same problem; it's really the same as prograde except that your command pod is pointing sideways rather than straight ahead.  Pointing normal gives the ship a whay to actively orient itself, but allow it to maintain a nonrotating orientation relative to the stars and thus the most motionless position for you to use as a docking target.  If you nudge it while it is normal-oriented, it wil stop spinning and you can try again.  Also, since the flight computer is making this happen, it works without a radio link.  Power can still be a problem, though; I hope you have lots of batteries.

B:  There is; it's in the settings UI under 'cheats', I believe.  RT somewhat compromises between options here and says that a single pilot is not capable of flying two ships, but allows a team of six (plus the right core) to fly everything it can link to.  Perhaps you ought to be able to 'ping' another ship and tell it to turn on its reaction wheels, but in any case you can't do that in RT without bringing the requisite personnel and hardware.

C:  It already exists.  If you take six Kerbals and the largest probe core (the 2.5 metre RC-L01 Remote Guidance Unit; it's pretty far down the tech tree), you can set up remote command posts.  It's handy for landing Jool and Eeloo probes.

D:  Most of the advice I can give pertains to what you're already figuring out.

Put a solar panel on each directional axis so you're not trying to keep weird orientations to maintain power.  If you point the ship in the normal direction for docking, but it then runs out of power after a minute, well, that wasn't very good, was it?  If and when you switch to deployable panels, put pairs of panels at right angles to one another for this reason, as well.  I've lost many probes because I had deployable solar panels in 2-symmetry on opposite sides of the probe; this gets solar power from every direction except when the axis of rotation points directly at the sun, and for some idiotic reason, that's how I inevitably end up facing.  Having panels with rotations at right angles eliminates this design flaw, at the cost of never getting full effectiveness from all of your panels.  I prefer always having power, so I'm inclined to take more panels anyway.

Always point stations in the normal direction (using the flight computer) if you can possibly help it.  Put docking ports on the normal and antinormal ends of that station so you don't have to deal with rotation at all as you try to dock.

Learn to plan your burns well in advance; you will often lose radio links until you put a few megatonnes of radio hardware in the sky.  When you go to the Mun, you're going to have to make your capture burn on the other side, out of radio contact.  That means you need to set up the encounter, node, and burn long before you get out of radio contact.  Some people prefer to wait until they enter the target sphere of influence before they set up those things.  RemoteTech cures you of that foolishness in a hurry.

When you get to landing probes in faraway places, you may consider trying out kOS rather than sending a remote command station.  But that's getting pretty far into the future.

 

#3:

In RemoteTech, maintaining contact involves having a clear line-of-sight with another antenna that is within range, but it does not involve physically pointing the antenna at the target.  As I understand it this mostly has to do with the 'on-rails' state of ships outside of the physics bubble, where KSP notes the location but not the orientation (this is the same thing that makes the warp-to-stop-spinning trick work).  Taking eight dish antennas, for example, only helps you if you want to keep track of eight different targets.  Until you do, it's just a power drain.  If you are losing contact, there are four possible explanations:  1) you lost power, 2) you went out of range, 3) for dishes, you switched targets to something out of range, and 4) someone put a planet in the way (those pesky planets).  If you want extreme wide coverage from one sat, use ModuleAntennaMultiplier (it's in the settings), set it to 1, and trade your dishes for omnis.  The multiplier makes it add up the ranges of all the omnis on the ship and theoretically goes from 0 (no addition) to 1 (full addition), though there's a weird coding bit that makes it go either full-on or full-off (unless they've got that fixed now).

 

#4:

They work as advertised, but as with all advertising, you need to read the fine print.  The cones are 3-d, but are displayed as 2-d in map mode to avoid visual clutter.  Also, dishes aren't really meant for ship-to-ship communications; they're meant for planet-to-planet.  Point a DTS-1 at the Mun from Kerbin, for example, and it'll pick up everything in Mun orbit that it can see; anything in the cone that has enough range to talk to Kerbin (and is pointed at Kerbin--don't forget that part) will automatically connect, just as Omni antennas do.  It will not pick up anything on the far side of the Mun--use Mun-orbiting relays for that--and it will not pick up anything if the Mun is on the far side of Kerbin--use Kerbin-orbiting relays for that (pesky planets!).  If you point a dish at a ship, the cone won't pick up anything else (essentially because it's being told to listen for the ship and only that ship).

Edited August 7, 2016 by Zhetaan

[Diche Bach]

Ah thanks a million for taking the time to provide such a detailed and thoughtful answer Zhetaan!

And with that I should be able to figure out the rest of it!

[superman123Batman]

I downloaded it and did everything correctly but i get a error when i click my coms it says they are locked, how do i fix this.

[Diche Bach]

3 hours ago, superman123Batman said:

I downloaded it and did everything correctly but i get a error when i click my coms it says they are locked, how do i fix this.

Is the vehicle in VAB or in orbit? If former, it might be that weird thing where they won't respond when you click "Extend" but _will_ extend when you click "Start Deployed."

If the latter (and unmanned( it might be that the ship has no comms link to Mission Control so you cannot communicate with it so you cannot control it.

If neither of those seem to be solutions, see if you can post a screen cap; with a bit more to go on someone should be able to help you fix it.

[Tyko]

In the RT tutorials on creating an Omni-Only network there's a note at the bottom about changing the SMA for the satellites in the Save File. If I'm forcing a specific orbital period, many of the other orbital parameters would have to adjust to account for the new period. It seems like changing that one value without modifying the others would break something. Does the game look at SMA when it loads and just automatically adjust the other params?

 

[undercoveryankee]

2 hours ago, tjt said:

In the RT tutorials on creating an Omni-Only network there's a note at the bottom about changing the SMA for the satellites in the Save File. If I'm forcing a specific orbital period, many of the other orbital parameters would have to adjust to account for the new period. It seems like changing that one value without modifying the others would break something. Does the game look at SMA when it loads and just automatically adjust the other params?

 

Any orbit of the same body with the same SMA will have the same period. The other elements affect the shape of the orbit, but not the period, so you can leave them set to wherever they were in the file and the orbits will still sync.

[Tyko]

Installed RT over the weekend on a new career save. Read the tutorials and set up the Kerbin system...I'd love any feedback on whether I got it right. What you're looking at is 4 sats in a 500km orbit with omnis and a KR-7. One opposite pair (sats 1 & 3) has their KR-7 pointed at Minmus, The other opposite pair (sats 2 & 4) is pointed at the Mun. The Mun and Minmus each have an identical satellite in a highly elliptical polar orbit with its KR-7 pointed back at Kerbin.

 

Edited August 9, 2016 by tjt

[SilverlightPony]

14 minutes ago, tjt said:

Installed RT over the weekend on a new career save. Read the tutorials and set up the Kerbin system...I'd love any feedback on whether I got it right. What you're looking at is 4 sats in a 500km orbit with omnis and a KR-7. One opposite pair (sats 1 & 3) has their KR-7 pointed at Minmus, The other opposite pair (sats 2 & 4) is pointed at the Mun. The Mun and Minmus each have an identical satellite in a highly elliptical polar orbit with its KR-7 pointed back at Kerbin.

Not bad.  Gets the job done, and in a neater fashion and with less funds spent than mine. 

[Zhetaan]

7 hours ago, tjt said:

I'd love any feedback on whether I got it right.

That's some fine work.  The only real improvements you can make would be aimed to filling the tiny and intermittent gaps in coverage so you can get a true 100%--in other words, you've done a good enough job that the only way you can make it any better is to resort to nitpicking.  So it's perfectly suited to give coverage for just about anything you want to do.

On to the nitpicking, then:  Your Mun polar satellite orbit will align so that you lose signal twice for each revolution of the Mun around Kerbin.  The same is true of Minmus, but in either case, the total blackout time is measurable in minutes per month, if that; I noticed that you put your satellites in highly eccentric orbits, and I assume that this was to limit time-in-shadow.  If you want to have a foolproof link to Kerbin, put a second polar satellite in orbit of each moon, but adjust the longitude of the ascending node by ninety degrees.  Then, when your one polar sat is aligned to go behind the Mun, the other sat's orbit is face-on to Kerbin and you never lose your link.

If you care about total ground coverage, you'll need something for the poles.  The minimum would be three equally-spaced polar sats with Communotron-16s at an altitude of 601 to 843 km at Kerbin, four DP-10s at 83-153 km at the Mun, and three DP-10s at 60-228 km at Minmus.

The only other coverage gap exists in the spaces of Kerbin's sphere of influence that are not near the moons.  To get these, you need a forest of omnis and an antenna multiplier, to use the otherwise-eschewed 'Active Vessel' targeting mode, or else to put a high-power dish somewhere far enough away that all of Kerbin's sphere is in its cone ... and then to target that dish with all of your near-Kerbin vessels.

Of course, actually doing any of this would require many thousands of Funds and an extreme investment of time to provide for what probably totals 1% of your entire coverage potential and far, far less of your spacecrafts' mission time.

As I stated earlier, that's some fine work.

[Tyko]

3 hours ago, Zhetaan said:

That's some fine work.  The only real improvements you can make would be aimed to filling the tiny and intermittent gaps in coverage so you can get a true 100%--in other words, you've done a good enough job that the only way you can make it any better is to resort to nitpicking.  So it's perfectly suited to give coverage for just about anything you want to do.

Thanks for the feedback and the write-up of improvements. Your explanations will help me when I go interplanetary.

How does NASA do deep space comms with our probes? Do they have dedicated satellites for each probe or do they use an Active Vessel model? (my guess is it's likely a hybrid because it's been 5 decades, but just wondering what their prevailing thought is on it.) If there's a good article on it that I should read I'd love that too.

Edited August 9, 2016 by tjt