SquareCube Law Transmission model and so on.

[AdmiralTigerclaw]

This is a suggestion/request. I do not see as of typing this, any buttons to mark it as such. I've never touched GitHub before, so I don't know the interface.

So I was asked to post my suggestion here. The core of my suggestion involves essentially changing the model for transmissions from a fixed range value, to a value that actually involves power ratings and apply that to the systems involved.

I'll truncate long explanations down as short as I can. Some ideas are touched on in other suggestions. However, each point builds upon the previous here and are interconnected.

1: Convert the link model to a transmission power model. Where power drops off based on square cube law from the source Xmitter.

-- a: 'Range' is based on a power level above a certain value threshold. For example: If values are from 0 - 100 where zero is background level, and 100 is fresh off the High Power Amplifier; A commlink can only be established if the final power level after all losses and gains is 10 or greater.

-- b: Antennae have two values that affect transmission and reception. --- I: Transmission power. Which is self explanatory --- II: Passive gain. A value specific to the dish or part that has to do with its geometry. (Such as dish size ore antenna shape). May be either a fixed value added, or a percentage add. I'm thinking the latter makes more sense.

-- c: Passive gain affects both transmitter and receiver, giving bonus energy on both ends of a link.

2: Make the transmission power a tweakable function.

-- a: Transmission power directly affects range.

--- I: More power increases range. --- II: More power increases electricity usage on an exponential level. (Thus reaching a certain practical limit of power for the Xmitter without limiting the player with a hard cap.) ---- * A cap for max power may be introduced at the balance stage that keeps Xmitter levels sane for a given antenna. You know, tiny little commlink antenna transmitting with enough power to require a nuclear reactor... That miiiiight just melt it. ---- ** Tweakability only in the VAB or SPH to imply the part was 'assembled' with the power equipment desired.

-- b: Passive Gain boosts transmission power by a percentage.

--- I: A dish's aim cone reflects side lobes in the direction of travel. So otherwise 'spilled' transmission power can be redirected. ---- * :Dishes have far more passive gain than omnidirectionals. --- II: A dish's aim cone intuitively also allows it to gather more signal energy from distant objects. Larger the dish, the more energy it can gather, the more passive gain it has.

3: Change the requirements for a vehicle to be controlled from a full duplex connection, to a listening only connection. (IoW: If the control signal from a mission control can reach the probe or sat, It can be controlled even if it can't transmit back.)

-- a: All satellites and probes are really just multi-million dollar RC cars with rocket motors. If it can listen, it can be controlled. It doesn't have to talk back. -- b: At space travel distances, full duplex connections are an illusion anyway. You don't have TcPiP connections when one packet exchange is going to take almost a minute and a half easy. --- I: [Figure out a way to rebalance the mod for that later. No science return transmissions are obvious. But something else is needed in exchange.]

4: (As stated elsewhere) Resolve transmission connection/aim types from the 'cone and direct connect' down into 'cone only' and fix whatever caused that limitation in the first place. Obviously this will fix a lot of the counter-intuitive 'connection shuffle' issues players have.

5: Introduce a GUI calculator that supports master points 1 and 2.
-- a: Graphical representation will not work, as connection ranges depend on both active and passive ranges from Xmitter AND Rcvr. New players would also be confused if such a visual function showed something was out of range, but a connection was established.

6: (Tentative) Introduce 'bandwidth' as per someone else's comments. But in a simplified format such as only 'x' number of simultaneous connections on a given antenna. -- a: Establishing connection 'priority' may be too troublesome and calculation intensive to apply this idea. -- b: If applied, MUST be kept simple

I'll cut the post here and leave it for discussion. This is, I hope, a little more thought out, cleaned up, and simple version of my post from the forum thread: http://forum.kerbalspaceprogram.com/threads/83305-Development-Resumed-RemoteTech-2?p=1234512&viewfull=1#post1234512

Apologies in advance if I'm treading on feet or presenting a very daunting verbal map of the model I'm imagining. I know how grossly complex comms systems gets in a hurry. And trying to bring a simplified model of that to the table is my goal. Players don't want to spend their time tweaking satcomm signals is a SPACE SIMULATION GAME. (Right?)

[Starstrider42]

This is a suggestion/request. I do not see as of typing this, any buttons to mark it as such.

That's because the button is only visible to people who have access to the repository. I've taken care of it.

I know @erendrake already expressed his support for this on the forum, but here are my concerns:

1+2: having a system based on separate transmission and reception gains, and making the former tweakable, adds a lot of complexity to the mod. As you yourself say, the focus should be on space simulation. So maybe this part needs to be simplified even more than you already have. (For reference, I'm an astronomer, so I know a bit of basic dish theory, but I still find your description daunting.)

3: If most players play the way I do, they spend a lot more time controlling the ship (doing burns, activating parts, etc.) than they do transmitting science. This means that the working connection requirement has always, in practice, been "KSC can transmit and probe can receive" rather than a continuous duplex link (especially since we don't require connections to get probe status). It's only by introducing transmission gain that a distinction becomes possible.

4+5: agree with both these points

6: I feel this would be replacing one form of counter-intuitiveness, i.e. the current targeting system, with another, i.e. knowing what kinds of transmission capacities you need for a given satellite in a given situation.

Finally, an administrative point: implementing point 1 will almost certainly break compatibility with existing saves. That alone makes it a serious undertaking, regardless of how easy or hard the code changes are. Not to say we won't do it, but it does mean we want to be careful.

[Starstrider42]

Now that I think about it, could the current rule that transmitting science requires much more power be a very primitive version of the transmission gain mechanic?

[erendrake]

On the forums i was mainly expressing my support for 2, right now the antenna are very static. I think letting them be tweaked in the VAB and to a lesser extent in flight could unlock some fun design opportunities.

splitting rx and tx ranges is a big scary features that is going to take a lot of design and ui work and documentation but we can surely carve this into several chunks of functionality.

1. Very Long Term
2. Can be added iteratively starting soon.
3. Very Long Term
4. Duplicate of other tickets
5. is a part of all of the other issues
6. Interesting concept, I think to start it might be cool to simply show how many craft depend on each link, then go from there.

Thank you @AdmiralTigerclaw for sharing your ideas :)

[AdmiralTigerclaw]

The separate transmission/reception gains mainly affect what combinations of dishes players put in place, but it has the side effect of allowing the player to slap together a new configuration as they see fit.

An example of that would be if you want a small satellite, but need it to have some antenna range. You can't de-compact it without reengineering your entire rocket, but you have electrical power to spare and can boost the Tx power. Conversely, you have more room, but you need to conserve power, so lowering the Xmitter power while using a larger dish gets the job done.

The combinations introduce would make it complex and daunting, but I can see a way to keep it simple for new players.

Simply have default settings programmed in for each dish/antenna and have 'ranges' for them already solved and use clever wording in the part descriptions.

Example: "Fancy Plate Dish: Glued back together after Jeb broke his mother's fine china. Default [I]Power level guarantees transmission range up to [u]at least[/u] 50 Mm.[/I]"

(And then in detail text below it that you would reference when using the calculator) Default Power Level: X Mwatts Passive Gain : Y%

The basic player only needs to know that just slapping the dish on, it can reach 50 Mm and they can move on.

Build the mechanics of it in such a way that the player doesn't HAVE to tweak anything unless they want to. Passive gain is determined by the shape of the antenna anyway, so the 'range' that is solved for in the description already includes that. The player eventually will discover that in certain situations, they find they get more range. Then on their 'own time'*, they'll play around with it or discover the calculator.

The purpose of the calculator is to be there ready to solve when a player wants to take it to the next level. Simply take antenna A with X power and Y gain, and antenna B with X power, and Y gain, a simple typed in distance value, and hit 'check' and get a feed back on if it would be in range... and if more feedback is desired, what the reception power level actually is and what maximum range for that combination would actually be.

• 'own time' being: 'I WANT to mess with it' rather than 'I HAVE to mess with it.'

[guto8797]

Some Ideas are very good in here, specially around power etc, but most of it are very difficult, If not applied with proper explanations. A lot of players struggle with RT2 as is, and adding even more things such as power effectiveness might just make it even worse. I would propose a line in the Config file to switch back to the old mechanism, if possible.

[jdmj]

Weren't configurable range models implemented already? I remember a discussion for three modes:

1. Max(a,b)
2. a+b
3. Sqrt(a^2+b^2)

Everything else in this suggestion is either oversimplification or overcomplication.

[AdmiralTigerclaw]

'Power Effectiveness' is mostly transparent to the player if done right. In reality, these hard and fast ranges don't exist. And while a good set of defaults would hide this complexity, it is certainly a better model to work from once you start tweaking it and 'getting under the hood'.

And while RT2 is complex, complexity in itself is not the problem players have. We're playing KSP. These players are understanding ROCKET SCIENCE. They can handle a little more, but the interface has to be set up in such a way that they can plug and play right from the start without having to deal with it. Just like a car. You want to get in and drive it first. You can learn to change the oil later.

Proper intuitive interface design, good simple defaults, and clear documentation written to explain and simplify the concepts can make even the most complex task a breeze. I have taught electronics engineering concepts to people, I know the difference proper handling of the principles taught can make.

And that reminds me, I need to make another suggestion...

[Starstrider42]

FreeThinker has offered another suggestion along these lines, namely giving antennas a series of discrete "modes": http://forum.kerbalspaceprogram.com/threads/83305-0-25-0-RemoteTech-v1-5-1/page29?p=1501041#post1501041. I think it might be a good way to introduce this kind of change, if we abstract all the physics into simple trade-offs between cone diameter, power consumption, and useful range. His specific version also gives the breakable dishes another advantage over fixed dishes besides just lighter mass.