Plans for 1.2

[Ristellise]

what are your plans for 1.2? will you be discontinuing RT in favour of the stock part? or will you be integrating into it? et cetra...

[jameswolff96]

I believe plans at the moment are to integrate over the new system. However @d4rksh4de and @tomekpiotrowski are currently looking for someone new to take over the project more info here. I would gladly do it, but I don't really know that I have the time (or the experience). to be able to handle the project mostly on my own.

[neitsa]

Plan is to port the current RemoteTech code base on KSP v1.2 "as is" (that is, without any big modifications). We already have a working version for the current code base (it will require some testing though).

Once this release is out (probably with the release of v1.2), we will start working on porting RemoteTech over CommNet (the built in KSP communication network).

[petersohn]

Does this mean that the current RemoteTech implementation will completely replace CommNet when the mod is installed? If so, is it planned that the old functionality can be opted in even after the CommNet integration (fpr example, to continue old games as is)? How is the integration with partial control planned? If there is no connection according to CommNet, then RemoteTech will completely disable the control of the vehicle?

[neitsa]

Does this mean that the current RemoteTech implementation will completely
replace CommNet when the mod is installed?

@petersohn I haven't a defintive answer for your question yet. There are some dark corners that haven't been tested (see point 3. below).

I see 3 possible scenarios (for the next release):

1. Satellites using only RT Antennas / dishes (RT only communication network)
2. Satellites using only CommNet Antennas (CommNet only network)
3. Satellites using both ??? (I haven't tested the case where both antennas from RT and CommNet are used on the same vessel though, this is on my todo list but my guess is that this is the path to a lot of problems.)

So if we want to avoid the 3rd point problems we might need to disable CommNet altogether to keep things simple. We haven't discussed this point though.

Supporting both RT and CommNet on the same release would probably require to add code to prevent weird behaviors when antennas from both networks are used on the same satellite. This is not the point of the very next release which is meant to be a strict port of the RT functionalities from 1.1.3 to 1.2.

If so, is it planned that the old functionality can be opted in even after the CommNet integration (fpr example, to continue old games as is)?

When RT will be built on top of the CommNet code I'd like (this is a personal preference we haven't discussed about it yet) to retain the current RT controls, that is:

• No control
• Local control [total control without delay]
• Delayed control [if delay is opted-in]

From my point of view, It'd be possible to add a partial control (as in current CommNet implementation) instead of "No control" if opted-in from settings for example.

I'll update this thread when we have a clear consensus on the RT team about what should be implemented. Naturally, players' feedback will help us to make a choice.

[Netrilix]

If you're looking for player feedback, here's my two cents. I love the CommNet system, but it's severely lacking in a few key areas that RemoteTech really nailed.

• Flight Computer (this is huge for unmanned probes)
• Manual dish alignment (CommNet feels too easy with the automatic routing)
• Delayed control (including queuing commands)

Getting these three features working seamlessly within the existing CommNet architecture should, in my opinion, be the first priority, since they'll go the furthest in improving the base game.

[PBscoots]

I agree with @Netrilix. I would personally like to see more of an overlay adaptation to make the commnet more like RT was but with bonuses. Have the overlay

• incorporate the flight computer, (it would probably be fitting to replace to current commnet mechanic of coarse control due to lost signal with the flight computer)
  -have option for time delay,
• have option for no remote control(although I think that already is an option in stock new stock, I do appreciate being able to aim antennas at least if I have lost connection).

A nice list of check boxes that just modifies how commnet behaves. (flight computer or course control, signal delay, antenna control, stock lost signal control, no control... etc.
Also, if it is more of just an overlay to change behavior, it will probably be easier to integrate with KOS(which is how I have been playing lately and its a fun challenge).
I advocate for the overlay instead of replacement also because of the cool new mechanic of signal strength relating to science recovery that I would like to play with.

[evan2645]

As a KSP player, I want to be able to use RT with KSP 1.2.

Currently, RT doesn't seem to work at all under 1.2, with all of the RT elements I expect missing from gameplay. If the fastest way to make RT work with KSP 1.2 is to strictly port the old functionality over, then awesome, that's what I want.

Ultimately it would be nice to see greater harmony in these two systems, but for now, I just wanna play KSP

[neitsa]

@evan2645 : RemoteTech 1.8.0 (KSP 1.2 support) release is scheduled for next Saturday (Oct. 15 2016). This is a strict port of the current code base (RT 1.7.1) with bugfixes.

We'll start to work on the next release (Integration with CommNet) as soon as it is released.

[evan2645]

awesome, thank you @neitsa !

kudos on the management of this project, i've had nothing but positive interactions with the maintainers, and it looks like the project is very healthy

[adempewolff]

I also agree with @Netrilix. With regards to Commnet integration the most important features for me in descending order are:

1. Delayed Control/Flight Computer
2. Directional Dishes (with manual alignment)
3. Root range model, stackable omnis and other tweakables for realism

Using the new ground stations would also be nice but I can live without.

Eventually (read: far future), it might be nice to try to incorporate some of the new gameplay elements of Commnet (signal level + tech level of probe core influence which features of flight computer can be used) but I would be perfectly fine even if this never happened.

[EoD]

As this is still requesting for comments, here is my opinion:

Unlike the others here, I prefer to be able to "convert" my RT network to a CommNet, as I always disabled Delayed Control (too much hassle) anyway and I can live without the other features in order to have one consistent system. Hence my ideal solution would be:

• make RT satellites/dishes use the stock mechanic
• Make "connection lost" mechanic as RT's default, hence overwrite stock (as @neitsa described above)
• Keep Flight computer (as a mod on top of stock mechanics)
• (maybe) tweak the stock mechanics to allow directional requirements
• (maybe) tweak the stock mechanics to allow delayed control

[Zhetaan]

So long as you're still soliciting input, I'm very much with @Netrilix on this one. I'd like to see the flight computer, signal delay, and manual dish alignment, in no particular order.

I personally would resort to the flight computer rather than partial control Perhaps a setting for partial control that allows you to put a probe to sleep and wake it back up again would be in order (something like this now exists in stock, I believe, but I don't know how it interacts with CommNet or would interact with RemoteTech), but it's not on my list of top priorities. Honestly, as a quality-of-life improvement, I'd really like to see a setting in the flight computer where you can more easily set a delay to retract and then redeploy an antenna (useful for aerobraking and reentry). Stock, with no partial control, has no means to redeploy an antenna after aerobraking, and that strikes me as a gross oversight.

Concomitant with the flight computer, I'd like to see RemoteTech do away with the stock restriction on setting manoeuvre nodes while under loss-of-signal--that game mechanic simply does not make sense to me, because signal or no, a manoeuvre node is essentially a flight plan and thus not subject to delay, signal, or anything else. Far better in my opinion is the 1.1.3 RemoteTech behaviour of allowing one to set the node but not send an instruction to execute it. while there is no signal.

Along with signal delay, I'd like to point out that the stock implementation of 'require signal for control' seems to operate differently from RemoteTech's implementation in 1.1.3. I know this because, with it enabled, the stock system will not allow any control of a probe without a signal, which interferes with kOS scripts for far-side Mun landings, for example. I may be wrong and it's simply a kOS problem, but if not, then delayed instructions to the flight computer may require a bit more work to implement overlaid on the stock system.

Lastly, manual dish control is a priority for my own satisfaction's sake: the stock system makes a relay dish mass more in order to simulate multiple dish antennas, and then runs that antenna essentially as a more powerful omni. Honestly, at that point, I don't see the point: just give me a massive and powerful omni instead. I would be much happier with sending multiple dish antennas in order to make my own relay than accepting the stock mechanic on this one.

[Netrilix]

I'd like to see RemoteTech do away with the stock restriction on setting manoeuvre nodes while under loss-of-signal--that game mechanic simply does not make sense to me, because signal or no, a manoeuvre node is essentially a flight plan and thus not subject to delay, signal, or anything else

I think this plan would break manned vessels though. If you're able to create nodes, then a Scientist would be able to create a node and execute it without ever having contacted KSC, which they're not supposed to be able to do. With unmanned vessels, that sounds good, because you wouldn't be able to execute the maneuver anyway without KSC contact, but with manned vessels, it'd be an issue.

[Zhetaan]

Not necessarily: the idea is that creating and executing nodes could be two different tasks. However, my idea still leaves unsolved the problem of a Scientist who cannot fly the ship but can still program the flight computer (using local control) to fly it instead, so I concede that you have a point. I would, I think, be satisfied if my ship full of Scientists can still light its engines (essentially, someone is brave enough to take the stick and try anyway) if not easily direct where it will go,

[Netrilix]

Your way of thinking is exactly how I wish the stock game worked: If you don't have a connection to KSC, you can still plan maneuvers at ground control, but not actually have them available on the ship until a connection is made at some point. Or you can make them locally on the ship, but only if you have a connection or pilot.

Programmatically, I think it would present a huge challenge, because the stock game doesn't offer a way of creating maneuvers that aren't immediately present on the ship. Without that option, everything's going to be a poorer version of what you and I both seem to want.

[adempewolff]

Perhaps in the absence of a pilot or drone core with a connection to KSC,
you could just disable display of the manoeuvre node on the eight ball and
the ability to use hold manuever autopilot. The manuevers would still be
present on the ship (ie. viewable in map view), just unable to be used.

On Sat, Oct 29, 2016 at 6:01 AM, Mike Jacobs [email protected]
wrote:

Your way of thinking is exactly how I wish the stock game worked: If you
don't have a connection to KSC, you can still plan maneuvers at ground
control, but not actually have them available on the ship until a
connection is made at some point. Or you can make them locally on the ship,
but only if you have a connection or pilot.

Programmatically, I think it would present a huge challenge, because the
stock game doesn't offer a way of creating maneuvers that aren't
immediately present on the ship. Without that option, everything's going to
be a poorer version of what you and I both seem to want.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#677 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQvFzqfe3W7oo0OMfE78ZXcWvXWaYr-xks5q4nC_gaJpZM4J_3Jy
.

[EoD]

Has there been a consensus on how to proceed, yet?
On which branch do you intend to develop 2.0 / CommNet integration?

[YamoriYuki]

We are already working on it.
You can see our work in new repos started for that purpose here: https://github.com/RemoteTechnologiesGroup
Also here's our plan: https://github.com/RemoteTechnologiesGroup/RemoteTech/wiki/RT-2.0-Proposal

[EoD]

Have there been any changes so far?
All the repos in RemoteTechnologiesGroup seem to be inactive. Is the project dead?
Is there some kind of list of things which need to be done and stuff which as been done (progress-meter)?

The Milestone "2.0" here seems to be dead: https://github.com/RemoteTechnologiesGroup/RemoteTech/milestone/16

[KSP-TaxiService]

Unfortunately, the other 2 developers are no longer active due to the lacking of free time. I and one new joiner are working on some RT parts offline without contributing to the master codebase yet.

Last time I checked, the new developer has a working primitive antenna system in separate repository and like myself is having work life.

I am resolving few interaction issues between KSP's CommNet and my CommNet layer, and then start to fix the autobuild of multiple repositories.

Still, the progress in RT 2.0 is still made, even though it is slower pace.