[DISCUSSION] RemoteTech 2 Lite development

[Galliard]

a thought on kOS and RT.. how about only needing a signal connection to upload kOS programs, but still allow execution if the trigger is properly defined.. IE, you have a probe going to orbit Jool for science, but you dont have any com arrays that can reach the dark side, where you want to burn at Pe to circularize.. so you write your program and send it up while youve got comms with it.. then all you can do is watch with fingers crossed as it passes out of comms to see if your program worked as you wrote it...

[Mokmo]

I'm actually ok with no-delay flight controls as long as you have a KSC/Command center signal available.

Delayed flight-controls could be a difficulty option, but just making sure you have a signal is a pretty good challenge in itself.

For Science, i would apply transmission delay and maybe an eventual storage on command posts if signal to KSC is unavailable.

Extra difficulty options:

-Needs to have ship active for all the time the transmission takes to get to KSC, warp allowed of course.

-Increment in power need for sending a packet depending on total distance

[BruteMan]

just a common sense thought limiting game progression with the higher range antennas at much higher tiers as well as maybe adding more / modifying the current ones to have a more (tiered range to match the science research) start with the old 9mn antenna then onto the 20mn dish up to 50mn dish 100mn ... etc. this would prevent the cluster of dishes all at KSP pointing at everything and have a more spread out network system as you progress in the game. enough communication power to reach the mun and minimus then enough to reach eve etc. it would kind of flow with the research tree. Just my 2c. back to the peanut gallery

[arq]

In real comms systems, you would expect the transmit power to be relatively consistent over different ranges. What does change dramatically with distance is signal power. A lower signal power means more errors, which means increasingly sophisticated error-correction coding must be applied to maintain data integrity. This means that you must send more total bits to get the same volume of 'data bits' across the channel. Even for a fixed power, this increases the total energy required for transmission.

I don't think making someone sit through a 15 minute transmission is very interesting, but increasing the required transmit energy over distance could be a valid mechanic. It could, in some cases, drag out the transmission to be much longer if the power requirements were dramatically increased so that power generation is also important.

Also, I like the idea of Science as a resource that can be transferred across parts or ships, but I expect relays being unloaded could pose a difficulty in this.

[rhoark]

Don't overcomplicate. RT is accomplishing its mission when it makes the design and deployment of a satellite network not just an exercise for show.

All that needs is three things:

No direct control over a craft without a comm route to a controller (preventing science transmission is an automatic side-effect of this point)

Antenna range and power drain balanced so bigger is not always right

Non-interference with kOS or MJ carrying out previously issued instructions

Other considerations are superfluous.

[Dexter9313]

I agree with rhoark. We should focus on these core functionalities first. When we have a stable release then work on science ! Don't jump over steps.

[Lexif]

Don't overcomplicate. RT is accomplishing its mission when it makes the design and deployment of a satellite network not just an exercise for show.

All that needs is three things:

No direct control over a craft without a comm route to a controller (preventing science transmission is an automatic side-effect of this point)

Antenna range and power drain balanced so bigger is not always right

Non-interference with kOS or MJ carrying out previously issued instructions

Other considerations are superfluous.

Yes, I agree with your points. Keep it simple. Focus on the challenge to have a com network available when your probe needs input. And make it so that you have to design your craft in a way that there's an incentive to use the smaller antennas, either to keep power demands low or because larger antennas are hard to package and heavy.

I would like the integration with sending scientifical data a lot, though. For me, the new research mechanism is the logical point for RT to tie into the game. It seems to me that in historical real-life space exploration pre-programmed control of probes was available pretty early on, and transmitting your data back to earth was more of a motivation to make networks of relay stations and satellites. It also just seems to be the logical point to tie RT into the current state of the game, expanding on a mechanism that is already in the game now.

Though I agree with Dexter, don't rush that. The most important point is to get the connectivity working. It might also be important to get the list of parts needed stable early on to lessen the pain when upgrades come along. The rest can follow and people will most likely be able to continue to use the networks they built with your first new version, so an expansion of the features will propably be painless for the user.

[Cilph]

Speaking of core functionality, I'll have to modify some core bits. I want the science routing to only work on the antenna that is maintaining the actual connection. Currently connections are just straight edges from satellite to satellite, taking the Max() of Omnidirectionals plus individual targeting for the dishes. However I need to change this into interface-based routing, where the incoming/outgoing antennas are collected as well. Just giving a heads up on what I'll probably be working on tomorrow.

I've written up a new ModuleDataTransmitter that replaces the stock one for easier modding. Squad forgot to actually use their CanTransmit() functions so I will have to come up with a way to add/remove the partmodules as a connection is established. Probably a notification event when routing involving the antenna gets updated.

Edited October 18, 2013 by Cilph

[TomatoSoup]

I suppose that the integration of science could be implemented very easily. Just make literally NOTHING on the ship controllable unless you're in range. How will you open the science panel if you can't hit any buttons?

[NathanKell]

That's....not so good for future-proofing. One thing I'd really like to see is the ability to add a module that can transmit science when connected to the network but NOT control the craft. So you can launch uncontrollable, lightweight early satellites that have no heavy, expensive guidance ring (probe core) but can still have sensors and transmit data.

Like how RT can control debris, except with only right-clicking allowed, not actually turning/burning.

[tom1499]

I would so use this. I liked the signal delay but it started to get on my nerves after a while. I think something to consider would be (optional?) two other stations on kerbin, as with apollo. Still preserves challenge, but removes some pains of travelling. Some people don't want to do tedious com-sat launches over and over.

[Dexter9313]

By the way are you currently developing on GitHub or something so that we can see what you are actually doing ?

[Cilph]

By the way are you currently developing on GitHub or something so that we can see what you are actually doing ?

https://github.com/Cilph/RemoteTech2/tree/lite

Quick TODO: Redo pathfinding to be 'network interface'-based, sort out science, add configuration UI, add in control blocking / delay framework.

[Dexter9313]

https://github.com/Cilph/RemoteTech2/tree/lite

Quick TODO: Redo pathfinding to be 'network interface'-based, sort out science, add configuration UI, add in control blocking / delay framework.

Nice, thank you, I'll take a look.

[brienne]

Great. It's on the way!

[Cilph]

A few other things:

Range: Old-RT1 style. 10km distance means both antennas require minimum 10km range. Simple.

Dishes: Dishes can target planets and this will turn the link into a "cone of vision" using a dish angle that will be balanced at 2 kerbin diameters at max range.

Parts: I intend to mod the stock parts as well as include a few of the RT1 parts, and maybe a small AIES part.

Science: Science can now only be transmitted across antennas that are a part of a connection to KSC. No cheating by using a low-cost omni while a high power dish maintains the connection. Implementation might be a bit buggy as of now, but we'll fix that in testing.

Quick TODO: User interface, adding planet targeting back in, adding control block / delay framework.

Edited October 19, 2013 by Cilph

[Cairan]

Please, put the omni 5Mm antenna in there, because so many ships use it as a "everyday" antenna for launch control that it breaks a lot of things when it is not included...

[NathanKell]

Cilph, couple questions.

1. What do you think of the range model in my RT1 fork? For two nodes, one weaker than the other, range = weak + sqrt(weak*strong), clamped to 100x weak (1000x weak if both are dishes) to simulate transmit power.

2. Why not use the RT2 parts?

[Cilph]

Cilph, couple questions.

1. What do you think of the range model in my RT1 fork? For two nodes, one weaker than the other, range = weak + sqrt(weak*strong), clamped to 100x weak (1000x weak if both are dishes) to simulate transmit power.

2. Why not use the RT2 parts?

1. Too complicated for mental calculations. If I wanted to do it right I'd just use a gain system. The old RT1 system was simple. In a future I might switch over to a system of gains and minimum signal/noise ratios.

2.I didn't really like most of the AIES parts we had for RT2. They're nice but I prefer to stick to the stock look. That's also why it's less of a menu-fest and tries to fit in more with the standard UI.

If someone can make me stock looking antennas, I will gladly include them.

Please, put the omni 5Mm antenna in there, because so many ships use it as a "everyday" antenna for launch control that it breaks a lot of things when it is not included...

Which antenna are you referring to? Remember that since RT2 was never released I have no obligation to support it. Stock parts will always be supported.

Edited October 20, 2013 by Cilph

[NathanKell]

1. Ok. I do suggest using the reogranization of the max distance code I did, though; that lets you display the current length of the last leg in the path, and the max possible for it, so that you can be careful to not exceed it when flying.

2. Ok.

3. Cairan is talking about the dipole antenna _from RT1_.

[Cilph]

3. Cairan is talking about the dipole antenna _from RT1_.

I'll put that one back in.

[Cairan]

I'll put that one back in.

Yep that's the one, the dipole ... Sorry for being vague on details, my daughter was born less than 2 weeks ago ... So I'm reading the boards and playing some KSP inbetween two feeding windows

[NathanKell]

Wow, congrats!

[FellipeC]

Don't overcomplicate. RT is accomplishing its mission when it makes the design and deployment of a satellite network not just an exercise for show.

All that needs is three things:

No direct control over a craft without a comm route to a controller (preventing science transmission is an automatic side-effect of this point)

Antenna range and power drain balanced so bigger is not always right

Non-interference with kOS or MJ carrying out previously issued instructions

Other considerations are superfluous.

This will bring a huge smile on my face! Although more things would be nicer, I think it's better a solid simple and fun Remote Tech than never have a complicated one.

And thanks a lot for your time developing this

[CAPFlyer]

While I understand the complexity of the AIES dishes may not be what you're looking for, I would humbly ask that you consider including at least a few of them as I'd like to still see a dish that I deploy pointing where it's targeted instead of just generically pointing back or forward along the ship's axis and transmitting the a location that is well outside that line of sight.