-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plans for 1.2 #677
Comments
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. |
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). |
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?
|
@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):
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.
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:
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. |
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.
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. |
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
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. |
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 |
@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. |
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 |
I also agree with @Netrilix. With regards to Commnet integration the most important features for me in descending order are:
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. |
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:
|
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. |
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. |
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, |
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. |
Perhaps in the absence of a pilot or drone core with a connection to KSC, On Sat, Oct 29, 2016 at 6:01 AM, Mike Jacobs [email protected]
|
Has there been a consensus on how to proceed, yet? |
We are already working on it. |
Have there been any changes so far? The Milestone "2.0" here seems to be dead: https://github.com/RemoteTechnologiesGroup/RemoteTech/milestone/16 |
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. |
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...
The text was updated successfully, but these errors were encountered: