[1.1] RemoteTech v1.6.10 [2016-04-12]

[Beale]

That's a 90 Mm dish, not a 90 Gm dish (the 60 Gm dish looks pretty similar, but has a much, much narrower cone). Kerbin's SoI has a radius of a little over 84 Mm.

Even with a mod as complex as RemoteTech, sometimes the solution is pretty simple.

Haha! My mistake yes.

At least I got a few magnetometer readings on the way out.

Thankyou!

[AdmiralTigerclaw]

Now I am getting to grips with this mod and loving it. I have at least a proper Kerbin network (99% uptime anywhere in the Kerbin system).

http://puu.sh/9Lp9s/ee6be1e596.jpg

But! When I leave Kerbin's SOI with this probe... (90.0GM Dish)

http://puu.sh/9Lpbz/16227fb3da.jpg

You sure that's the Ninety Gigameter dish? The cone looks awfully wide for it, not to mention it looks short-ranged.

It's dish is targeting Kerbin, but no luck. It's dead.

http://puu.sh/9Lpf1/22a69ede1d.jpg

My relay sats around Kerbin are using the largest dishes and pointed to "active vessel".

What am I doing wrong?

Otherwise, love this mod more than ever, now it's starting to make sense.

That's not a 90 Gm dish... That's a Reflectron KR-7 with a range of 90 MEGAmeters. OR 90,000 kilometers. Which is enough range to beam to twice Minmus orbit, or the Diameter of the Kerbin planetary system. You are out of range. The hint is in your view cone width. The longer the dish range, the more narrow the beam cone. All the really long range dishes have silly narrow cones and your beam cone looked too wide for 'just outside kerbin SoI.'

EDIT: Got ninja'd while I was booting the game up to confirm...

[Beale]

That's not a 90 Gm dish... That's a Reflectron KR-7 with a range of 90 MEGAmeters. OR 90,000 kilometers. Which is enough range to beam to twice Minmus orbit, or the Diameter of the Kerbin planetary system. You are out of range. The hint is in your view cone width. The longer the dish range, the more narrow the beam cone. All the really long range dishes have silly narrow cones and your beam cone looked too wide for 'just outside kerbin SoI.'

EDIT: Got ninja'd while I was booting the game up to confirm...

Hmm, now I have another issue.

New probe with 60GM dish.

Again, issue.

This time, there is no "Cone" visible, but my main dish is targeting Kerbin.

I lost signal just passing the orbit of the Mun, there are atleast 4 relays in line of sight...

The Mun is not blocking either.

Thanks for the help though!

[Eric S]

The cone of the interplanetary range dishes is so tight you can't target the planet and expect to have satellites in orbit of that planet within the cone while still in that planet's SoI, if I remember correctly. So you'll need to target satellites specifically until you get a ways away from Kerbin.

[Xiong]

I've played heavily with RT2 now for a couple months and through two careers; I've spent way too much time thinking about it -- what it is, what it's meant to simulate, what can be simulated well, and so forth. Now my experience with suggestions is that people would rather stay wrong than change -- which means being better but having to have been wrong in the past. Don't ask me to argue, please. This mod needs a major overhaul.

The basic concept is sound: An uncrewed, robot craft must communicate with Mission Control; and the only practical method is by radio -- possibly laser, which is the same in effect.

Two restrictions are guaranteed by physics:

1. Communication links must be straight lines (geodesics for the wonks); that is, a clear line-of-sight (LOS) must exist between endpoints [Yes you can bounce signals off the ionosphere, if you have an ionosphere, and with enough gear, off a moon. Not practical to simulate.]
   
2. No signal can propagate faster than light ©. [No you cannot avoid Officer Einstein.]
   

Other restrictions are a bit more flexible:

• Robots are stupid; the smartest robot ever built in reality is no smarter than a housefly. They cannot adapt well to novel situations. [This may change in your lifetime, not in mine.]
  
• Robots are buggy and cannot be expected to follow a stored program for very long before making a mistake. The more complex the program, the sooner the bug surfaces.
  
• Radio systems generally get bigger, more massive, more expensive to build, more costly to run; the higher the bandwidth provided. Transmission demands more than reception.
  
• Bandwidth: video > still photos > programs > commands > status
  

Therefore, reasonably, a robot craft must communicate at intervals with MC; and the more complex its programming, also the more variable the robot's environment; the more frequent the communication. And, obviously, every command must be sent in advance of execution; every report from the robot will be received after an equal delay. The delay between distant points in a system the size of Kerbin's is significant, on the order of minutes.

However: RT2 is even more restrictive than this; and that's just asking for trouble.

Losing control of a robot is a serious issue; it usually means that you lose the robot altogether -- gone, Jack, not coming back. So engineers work hard to avoid this disaster, even if MC does an oops.

Robots designed to operate under harsh conditions out of reach of a helpful hand to push the big red button are kept up at all times with some subsystem that reboots the computer whenever it crashes, freezes, or otherwise fails. The first thing after a reboot and self-test... reacquire signal from Control. You engrave into the most durable possible storage all of the info needed to restore power to antennas, aim them at known stations, and lock on. This routine has the highest possible priority after safety routines needed to preserve the robot from immediate destruction.

But that's not all! it's never enough to build a high-bandwidth channel; you cannot guarantee it will always be up. It may just use too much power to run continuously. So you always include a low-bandwidth channel, an entire, distinct subsystem. This may not even have ability to report, although it should report status, at least. What it certainly can do is hear MC, even under very difficult conditions. It may only be able to hear the commands: Wake Up! and Turn On Your Big Ears! But the probe will not be dead.

So you simply do not spend $10 million to put up a probe and as soon as it goes around the Moon, you lose it. People down at JPL do make mistakes but if the dish didn't deploy, it likely still can pick up a command to deploy.

Meanwhile the entire Flight Computer thing is broken. Suggest you trash it altogether. We already have a flight computer; it's called MechJeb; and it's in constant use by many players. You need to get in there anyway because MJ, now, simply ignores signal delay. Write a MJ submodule, get that working properly.

As for the endless juggling of RT2 antennas, comsats, and stations... no, just no. I absolutely endorse the demand that one launch sufficient comsats to maintain control: If you want to talk to, or hear, your robot probe then a path from MC to the probe must exist and each link in the path must be a straight line not passing through any celestial body. Absolutely. But let the computers embedded in the network decide how to route the signals. Do not ask me to dedicate any more dishes!

I understand that the game engine really isn't sophisticated enough to aim, physically, a dish directly at another dish a billion meters away. I fear an attempt was made to substitute, for this realistic requirement, the funky requirement to dedicate a dish to a single target. Bad idea.

It's an oddity of the core KSP game that not more than one craft is "active" at any time; and then there's a gray area defined by physics range: Within a radius of a bit more than 2 km, other craft are pseudo-active. If this were not the case then there would be a clear motivation for multiple antennas on comsats, with multiple probes all transmitting reports, receiving new programs, or sending HD video of that leaky pipe aft. As it is, and as RT2 is now, I find it very hard to justify a comsat containing 24 huge dishes. But it's either that or spend all day re-dedicating the dishes I do have, instead of building and launching rockets. This stinks.

This stinks all the more because a single omnidirectional antenna seems to be able to handle infinite bandwidth -- one omni can control a thousand probes within its range.

A reasonable compromise might well be to take note of how many active links terminate at a given comsat or relay ship; and call this the vessel's load. If the total bandwidth provided for a given range falls below load, then comms at that range degrade. Then this can be fixed by adding more dishes or omni antennas. Then the distinction between dishes and omnis becomes a little less distinct, as in real life, where the chief difference is capacity, not dedication.

In sum:

RT2 does not look sexy, provides player with no new capabilities, extends nothing, makes nothing easier, gives nothing, yields no science. It demands more of player, takes away things, consumes. This is good but a hard sell. The only basis on which to advance RT2 is realism. So let's try to be a bit more realistic, eh?

[dlrk]

^ Agree, especially about the flight computer being awful. Needs scripting + MJ

[bas]

When doe the microsat from remote tech 1 come to remote tech 2?

[velve]

I've played heavily with RT2 now for a couple months and through two careers; I've spent way too much time thinking about it -- what it is, what it's meant to simulate, what can be simulated well, and so forth. Now my experience with suggestions is that people would rather stay wrong than change -- which means being better but having to have been wrong in the past. Don't ask me to argue, please. This mod needs a major overhaul.

The basic concept is sound: An uncrewed, robot craft must communicate with Mission Control; and the only practical method is by radio -- possibly laser, which is the same in effect.

Two restrictions are guaranteed by physics:

1. Communication links must be straight lines (geodesics for the wonks); that is, a clear line-of-sight (LOS) must exist between endpoints [Yes you can bounce signals off the ionosphere, if you have an ionosphere, and with enough gear, off a moon. Not practical to simulate.]
   
2. No signal can propagate faster than light ©. [No you cannot avoid Officer Einstein.]
   

Other restrictions are a bit more flexible:

• Robots are stupid; the smartest robot ever built in reality is no smarter than a housefly. They cannot adapt well to novel situations. [This may change in your lifetime, not in mine.]
  
• Robots are buggy and cannot be expected to follow a stored program for very long before making a mistake. The more complex the program, the sooner the bug surfaces.
  
• Radio systems generally get bigger, more massive, more expensive to build, more costly to run; the higher the bandwidth provided. Transmission demands more than reception.
  
• Bandwidth: video > still photos > programs > commands > status
  

Therefore, reasonably, a robot craft must communicate at intervals with MC; and the more complex its programming, also the more variable the robot's environment; the more frequent the communication. And, obviously, every command must be sent in advance of execution; every report from the robot will be received after an equal delay. The delay between distant points in a system the size of Kerbin's is significant, on the order of minutes.

However: RT2 is even more restrictive than this; and that's just asking for trouble.

Losing control of a robot is a serious issue; it usually means that you lose the robot altogether -- gone, Jack, not coming back. So engineers work hard to avoid this disaster, even if MC does an oops.

Robots designed to operate under harsh conditions out of reach of a helpful hand to push the big red button are kept up at all times with some subsystem that reboots the computer whenever it crashes, freezes, or otherwise fails. The first thing after a reboot and self-test... reacquire signal from Control. You engrave into the most durable possible storage all of the info needed to restore power to antennas, aim them at known stations, and lock on. This routine has the highest possible priority after safety routines needed to preserve the robot from immediate destruction.

But that's not all! it's never enough to build a high-bandwidth channel; you cannot guarantee it will always be up. It may just use too much power to run continuously. So you always include a low-bandwidth channel, an entire, distinct subsystem. This may not even have ability to report, although it should report status, at least. What it certainly can do is hear MC, even under very difficult conditions. It may only be able to hear the commands: Wake Up! and Turn On Your Big Ears! But the probe will not be dead.

So you simply do not spend $10 million to put up a probe and as soon as it goes around the Moon, you lose it. People down at JPL do make mistakes but if the dish didn't deploy, it likely still can pick up a command to deploy.

Meanwhile the entire Flight Computer thing is broken. Suggest you trash it altogether. We already have a flight computer; it's called MechJeb; and it's in constant use by many players. You need to get in there anyway because MJ, now, simply ignores signal delay. Write a MJ submodule, get that working properly.

As for the endless juggling of RT2 antennas, comsats, and stations... no, just no. I absolutely endorse the demand that one launch sufficient comsats to maintain control: If you want to talk to, or hear, your robot probe then a path from MC to the probe must exist and each link in the path must be a straight line not passing through any celestial body. Absolutely. But let the computers embedded in the network decide how to route the signals. Do not ask me to dedicate any more dishes!

I understand that the game engine really isn't sophisticated enough to aim, physically, a dish directly at another dish a billion meters away. I fear an attempt was made to substitute, for this realistic requirement, the funky requirement to dedicate a dish to a single target. Bad idea.

It's an oddity of the core KSP game that not more than one craft is "active" at any time; and then there's a gray area defined by physics range: Within a radius of a bit more than 2 km, other craft are pseudo-active. If this were not the case then there would be a clear motivation for multiple antennas on comsats, with multiple probes all transmitting reports, receiving new programs, or sending HD video of that leaky pipe aft. As it is, and as RT2 is now, I find it very hard to justify a comsat containing 24 huge dishes. But it's either that or spend all day re-dedicating the dishes I do have, instead of building and launching rockets. This stinks.

This stinks all the more because a single omnidirectional antenna seems to be able to handle infinite bandwidth -- one omni can control a thousand probes within its range.

A reasonable compromise might well be to take note of how many active links terminate at a given comsat or relay ship; and call this the vessel's load. If the total bandwidth provided for a given range falls below load, then comms at that range degrade. Then this can be fixed by adding more dishes or omni antennas. Then the distinction between dishes and omnis becomes a little less distinct, as in real life, where the chief difference is capacity, not dedication.

In sum:

RT2 does not look sexy, provides player with no new capabilities, extends nothing, makes nothing easier, gives nothing, yields no science. It demands more of player, takes away things, consumes. This is good but a hard sell. The only basis on which to advance RT2 is realism. So let's try to be a bit more realistic, eh?

I must say, I'm trying very hard to understand what you mean. Its obvious you have the capability to lay down a good point, but I just didn't get it hehe.

In response to what I did understand....Don't you think its a massive step up from being able to launch probes without a comm. network? And I do agree about the dishes, but thats most likely just the restriction of the game.

This is my most recent albeit messy network, Im still relatively new and if theres one thing RT2 has taught me is matching orbital velocities. Have learned quite a bit already through this mod so thank you!

[Pyromaniacal]

Hi. I have a question. I used Remotetech a while ago, back in 0.22 I think it was, and kinda stopped in the delayed update. I recently tried reinstalling the mod, and found that the mod crashed my game. (Maybe it was something else, but my game stopped crashing when I uninstalled it, and then resumed when I reinstalled.) My list of mods is pretty darn long, so it may be easier to ask if there's a list of common mods that conflict with RT2?

Thanks for the assistance!

[OldMold]

I must say, I'm trying very hard to understand what you mean. Its obvious you have the capability to lay down a good point, but I just didn't get it hehe.

I think what he is saying is that setting up a comm network is fun, but micromanaging it is not, and I agree. Basically think about what would happen if you remove the targeting mechanics from the game, and assume that the comms computers at KSC and in the probes are smart enough to establish and re-establish links. It would be like making every antenna in the game as an omni antenna just with different ranges. You still need to create a comms network and account for line-of-sight and range issues though.

This is something you can actually try already by tweaking the .cfg files to make all antennas omnis but keeping their ranges as they are.

Instead of targetting, introduce the concept of "bandwith caps" for each antenna that dictate how many active antennae they can support. You would still want to put a bunch of dishes on your Kerbin comm sats, though not because you have to target each of them, but because a single dish only supports 4 active antennas in it's range (for example). You would want to add more antennas to support more stuff being launched.

It would also be neat to integrate with some life support mod (or keep fit) to require comms on manned craft so the crew doesnt go crazy without contact with home

[MOARdV]

I must say, I'm trying very hard to understand what you mean. Its obvious you have the capability to lay down a good point, but I just didn't get it hehe.

I think the distillation of that post is that having to manually juggle dish connections detracts from the game play. Provided that's a reasonable summary, I have to agree. That is one gripe I have with RT - having to manually aim dishes, and if I screw up, I lose the craft. I've already lost two interplanetary probes because their 0.04* cone of communication aimed at Kerbin can't even hit the KSC, since the satellites are on an inclined orbit. Having SPUs smart enough to lock on to another dish when their primary is lost would improve gameplay. That's the gist of my proposal on issue #107 on github.

[AdmiralTigerclaw]

Snip Critique

Partially agree with Xiong on certain things. There are things that RT2 does that doesn't make sense. Fun to play with setting up commsat relay networks, but network management too quickly becomes a chore to perform.

'Aiming' dishes is the biggest hassle for any large network. And as a player, being only one person simulating the task of thousands of engineers and techs, 'set-it-and-forget-it' and automation are key factors I look for. Personally, I like the operational cone, but there are some things that need to be pointed out.

Most importantly, the dish is the receiver. When beaming a signal, you don't need to bounce it off a reflector, you just beam it. The dish is used to refocus an incoming signal so you can boost a faint one to recover from attenuation. In this manner, the ability for a satellite to listen is independent of its ability to talk. Of course, most functions of this manner are engineered to complement each other. But it should be noted that larger dishes/arrays are better at listening to faint signals because the surface area of the reflector gives it more signal to focus on the reciever. Which means that you can use a huge dish on the ground to receive a satellite's weak signal, but only a small dish on the satellite to receive power from a ground antenna/array with powerful power amplifier systems.

If I were to change dish behaviors, I'd make them reflect this. Dishes would have two features. One being signal receive boost, and the other being a tweakable power level. I'd have to review actual receiver dish dynamics to see how the FoV cones behave, but this would be my first 'tweak'. Then you can set up tiny satellites in orbit with powerful transmitters (Solar Panels are going to get more important) talking to ground, but small reflector dishes because they don't need to recover much signal.

Of course, this would require the addition of a 'signal strength' function and free space attenuation over distance. In this manner, an antennae no longer has a fixed 'range'. But rather, 'range' is determined by a combination of the signal power of the transmitter, and the size of the receiving dish.

If this got reworked into remote tech, I would suggest a simple GUI menued calculator that lets the player find the communications ability of any combination of dishes and power levels. The headaches that would occur otherwise...

Now, if this change were to occur, omnis would require reworks as well. Transmission and reception are independent functions. You don't actually transmit on the same antenna you receive on. Otherwise, your Xmit signal would burn up your receive channel right at the electrical connection. So any given commsat would require two omnis for full comms. One to transmit, and one set to receive. (In real life, Xmit and receive occur on two different frequencies so the having an Xmitter next to a Rcvr doesn't result in the Rcvr just being jammed.)

I wouldn't get into forcing the player to set frequencies or play with bandwidth. It might be fun early on, but that gets too close to becoming a chore for my taste when you have expanded networks. If frequencies and bandwidth are to be handled, let RTech handle said function in the background and automate connections. Players have a hard enough time understanding current RTech-2's mechanics. Don't force advanced telecommunications theory down their throat. I'm coming up on the end of my electronics degree plan and I'm thinking that would be a little too much like Work.

But anyway... for Omnidirectional Antennae, they would need two (three, technically) tweakables functions.

1: On/Off obviously. Antenna needs low power for receive.

2: Switch between Rcv and Xmit so players can define the antenna.

3: Xmit Power level. (On an exponential electricity usage curve.)

Unless of course, the antennae are tweaked to show two of them. The Always On one is a good example of this. And since Omnis all effectively behave the same way, you don't really need to have two dozen different types aside from choices in style and maybe methods of how they deploy when turned on. (The only real purpose of different length omnis is that you need a longer antenna for lower frequencies. But like I said, I don't want to subject players to a college level communications course just to play a game.)

Now, if one asks why dishes can Xmit and receive at the same time, but not omnis, I should point out that a dish already IS technically two antennae. If you look at a satellite dish, the horn sticking out in front of it has a receiver facing the dish itself, and the beam is fired out the feeder horn on the part facing out. At least, on dishes that actually do transmission. Your DISH network Satellite Television dish bolted onto the side of your house doesn't transmit, so you won't see that just walking outside.

Now, the next thing I'd speak of is aiming dishes. Like I said, I need to review reflectors to see their actual FoV mechanics, but believe it or not, just because the main uplink is down doesn't mean the device can't hear you. If we switch to power attenuation models instead of current models of fixed range and aim, then technically all you need is raw power from the Xmitter to at least 'ping' the satellite or in the case of interplanetary distances, your probe.

If you can PING the satellite, you can give it a command, even if it can't talk. If you have the right device on board, you can get it to lock on to the timing signal.

Explaination: On at least military satellite ground dishes, the feeder horn has a receiver built into it that allows it to lock on to a satellite via a weak timing signal. Using four signal detect pads, it evaluates the difference in signal strength across the pads and turns the dish so that the signal levels are even across all four. If we assume that such a component is built into even the most rudimentary probe or satellite, then you should be able to force feed any probe a signal that it will go 'oh, I see that' and lock onto it.. IE 'aim'.

Finally, there's control. I know an 'established connection' is a two-way street, but a probe is really just a ten million dollar RC car at its most basic. So long as you can transmit TO it, you should be able to at least control it... Though you don't get feedback in real life on what you're actually doing. (Not an issue with typical KSP though unless we force it by say, blacking the camera out.) But if it can't get a returned signal, you can't say, get science back from it.

It must also be considered that at interplanetary distances, 'established connections' aren't. Not in the way the IT industry understands them anyway. Packet exchange occurs, but it's not the fast back and forth of TCPIP. It takes seconds to minutes to receive the data packet and then transmit it back across the void. Communications is less like the internet's traffic streams, and more like two people passing notes back and forth.

So really, all this being said... I think the 'model' being used for Remote Tech should be based on power and attenuation. Forget playing Mr. Bandwidth... As neat as that might be, that becomes a headache and I don't think such a niche mod should be more niche than it already is. It becomes too much like work too quickly.

Edited June 27, 2014 by AdmiralTigerclaw

[velve]

Ok, thanks guys I understand what he was saying now.

As you saw I'm not very far into delving into RT2 mechanics and I am yet to send probes further than 200km orbit around kerbin, this is why I havent had to use the comm. devices that you need to aim. I thought the main problem was that the dishes can only focus on one target at a time. I see now the actual aiming is a problem. This is probably why I didn't fully understand.

[Rassa Farlander]

I honestly agree that a complete overhaul, and possibly a start from scratch might be for the best. Wait for .24 to come out and take a few months to work out some fresh code tailored to .24. RT as it now is much more about maintenance of networks, and just gets too tedious after awhile. I also support ditching the flight computer for mechjeb integration. I would love to see a fresh take on this mod. Although I realize this would be a massive undertaking resulting in a lot of time to dedicate to it. Thats just what I think though, and either way Im looking forward to seeing where this mod is headed!

[BigD145]

Hi. I have a question. I used Remotetech a while ago, back in 0.22 I think it was, and kinda stopped in the delayed update. I recently tried reinstalling the mod, and found that the mod crashed my game. (Maybe it was something else, but my game stopped crashing when I uninstalled it, and then resumed when I reinstalled.) My list of mods is pretty darn long, so it may be easier to ask if there's a list of common mods that conflict with RT2?

Thanks for the assistance!

KSP version? OS?

[Ghost13]

I played with RT2 for around 4 months both with and without time delay. So my thoughts on the topic, the major problem of RT2 in particular and KSP in general that it offers challenges without proper tools to deal with them, i.e. all stock KSP offers challenge in interplanetary travel with very basic tool of maneuver nodes to solve them, same here RT2 offers potentially very interesting and in a way realistic gameplay mechanic with very limited tools to cope with new challenges. And freqent answer for those who are find such a gameplay way too challenging there is a short answer "just get better in the game". This paradigm should be changed first of all since games are played for fun and entertainment challenges they offer shuld be within the grasp. So here is my thoughts what shuld be changed in RT:

1. Antenna alignment - There is way too much managing the antennas in the RT2 gameplay right now. As I mentioned before this shuld be automated or simplified in some way. Automatic alignment system, wider signal cones that allow to target Kerbin successfully outside of kerbin SOI e.t.c. So as a player I'm ok with some micromanaging, but I want to concentrate on flying and exploration rather than tedious switching from craft to craft trying to sustain signal.

2. Flight computer – current implementation of RT2 autopilot is crude at best, in most cases it fails to complete burn properly. And I believe that investing more of human\hours on the current flight computer is a waste of time. There is a MechJeb with just everything RT2 player needs. So only thing is required is to add the support for MechJeb to work without the signal by the preprogrammed path. It will solve many things such as landing or launching probes on and from non atmospheric planets with time delay enabled. As well as orbital rendezvous and even docking. Having the MechJeb support will basically allow time delayed gameplay.

3. What about science? - Even with MechJeb running things, you will have to run science experiments somehow, so I suggest that instead of developing RT2 autopilot, efforts shuld be made to make it Science autopilot where you can choose conditions which triggers experiments to be pefromed and transmitted, i.e. reaching high or low orbit, reaching specific height, landing on surface e.t.c, and also set the conditions whenever experiments should be transmitted or stored.

4. Introduce the signal straight concept, it is very strange that in RT2 mod there is no signal straight. This will help people more intuitively understand the signal loss as well as potentially can lead to some improved gameplay mechanic (i.e. low signal=longer science transfer time and higher energy consumption). Signal disruption events (i.e. solar storms, areas of signal loss at some Jool orbits e.tc.)

5. Remote control from Kerbals, the current restrictions on becoming the mobile command center is way too high, 5 kerbals in the craft with large probe core. I believe it should be lowered to say 3 kerbals.

[BigD145]

3. What about science? - Even with MechJeb running things, you will have to run science experiments somehow, so I suggest that instead of developing RT2 autopilot, efforts shuld be made to make it Science autopilot where you can choose conditions which triggers experiments to be pefromed and transmitted, i.e. reaching high or low orbit, reaching specific height, landing on surface e.t.c, and also set the conditions whenever experiments should be transmitted or stored.

This is something more inline with ScanSat, which actually maps biomes and tells you what you are over.

[Colseg]

I would also have to agree with Xiong that the best route forward for RT2 would be to strive toward improving realism.

[AndreyATGB]

Ghost13, I disagree with lowering the kerbal limit. 5 is there so that you can't just launch a command pod and have it act as a station. I see where you're coming from (old space stations didn't hold a lot of people) but simply lowering the limit would defeat the purpose as I said.

As for the overhaul discussions, I'm really liking what's being said here. Really thorough and detailed criticism, the suggestions are fantastic and they would be amazing for the mod.

[Z3R0_0NL1N3]

Is there a way to add more mission controls on Kerbin? Because I think this mod, with added Tracking Stations, would be great! Like NASA's ones, really.

[Cilph]

I agree with Xiong on some points, but the best way to get your voice heard is to put in a feature proposal at the GitHub issue tracker. For example, I just wrote out this proposal: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/111

[AdmiralTigerclaw]

But then some of us have to sign up to GitHub [/Whine]

[erendrake]

I would also have to agree with Xiong that the best route forward for RT2 would be to strive toward improving realism.

I would say the best route forward for any mod would be to strive to be more fun and rewarding. Realism is only one avenue to get there.

But then some of us have to sign up to GitHub [/Whine]

Sack up, your alternative is to have your brilliant life changing idea languish on some long forgotten page of forum posts.

[Starstrider42]

Damn, you guys can write a lot of text in the space of a few hours. Now that I've had some time to read everything properly, here are my remarks on the subject. I believe I'm speaking for the team here, but Cilph, woogoose, erendrake, please feel free to correct me if I've misrepresented something.

First, on the issue of a complete overhaul: this has already been tried, and it's the reason we hadn't had any updates since December. Something like that is simply too ambitious for the manpower we have available. When we took over the project, Remote Technologies Group decided to go with small, incremental changes to the existing mod rather than starting over. It's less flashy. It means no single release will fix everything. But it gets results.

So, to echo what Cilph said above, please post specific, well-contained changes (e.g. "I want satellites to pick targets intelligently" rather than "I want you to redo everything") to GitHub or, if you really can't set up an account, this forum. Specific goals are something we can realistically act on.

Second, replacing the flight computer with MechJeb. Some of you love MechJeb. That's great. But other players hate MechJeb, and I mean really hate it. It's one of the few mods that get branded as "cheating". While we would like to see MechJeb integration in the future (and I have no idea whether it's really as simple as "just write a MechJeb module", as two people above have claimed), we will never, ever, ever make it so that you must have MechJeb to play RemoteTech. That would just alienate too many players.

Is the built-in flight computer broken? Yes, but it can be fixed, and more easily than some of you seem to think. It's one of the big things we've been working on, actually. The recent update has already made the computer much more accurate at executing complete burns. We've got an update to RCS support in the works (using code from MechJeb, in fact), and getting more precise (and more stable) pointing will come next. So please bear with us just a little bit longer.

Finally, the most common complaint in the last 20 posts is that RemoteTech requires lots of micromanagement. This, I'll admit, is a serious issue -- because the current rules were not designed to require lots of micromanagement. Clearly, something's not working as intended.

We've already gotten a couple of specific suggestions to make things better. One is dish auto-targeting (there's a discussion about what exactly that should entail on this GitHub thread). Another is making cones behave more consistently and intuitively (here, here, and here). Yet another is adding connection diagnostics (here).

What I would like to see from the community, however, and I've asked this before, is examples of how your networks are set up at the moment. How many satellites do you use? How many dishes? Where are those dishes pointed? Most importantly, which part requires ongoing management? Knowing how RemoteTech actually gets used by the average player will help us improve the game rules much more than merely saying "RemoteTech requires juggling" as if it were obvious.

I think that covers about everything. Thank you for your feedback, we appreciate it!

Edited June 27, 2014 by Starstrider42

[erendrake]

Damn, you guys can write a lot of text in the space of a few hours. Now that I've had some time to read everything properly, here are my remarks on the subject. I believe I'm speaking for the team here, but Cilph, woogoose, erendrake, please feel free to correct me if I've misrepresented something.

I agree, smaller changes are less risky and this team is fairly new to both the codebase, each other and the community at large. If you advocate for a larger change than we are ready to tackle that is fine. Just be prepared for us to say no. We are also much more likely to work with someone on a large change if they have been constructive with us on smaller changes in the past.

Everyone on the team are excited to make RemoteTech a fun and engaging mod to a game that we love playing. Otherwise we wouldnt have volunteered our time in this way.