RemoteTech
RemoteTech copied to clipboard
RemoteTechnologiesGroup
Dish auto-targeting / Satellite recovery
This apparently doesn't have a dedicated issue yet, so, for the record:
A common request on both the old and the new threads is for dishes to be able to automatically select a new target when the ship is out of contact. This is, potentially, a very large change to the existing game mechanics, and may not be compatible with Cilph's proposed new system (#27).
Personally, I suspect auto-targeting will break gameplay unless it comes with a huge number of restrictions. Thoughts?
I would like to point out that we already have antenna that behave like this, they are the Omni's :)
Here are my two cents about some limits that i would want in my saves if we wanted to add seeking to dish antenna. Other's mileage may vary.
- I would get quite cross if RemoteTech ever changed the targeting of one of my dishes for me. Ever.
- in the vein, I think you should either need to plan ahead and put a dish in "Seek" mode or have it not assigned to anything in order to be used as a seeking dish.
- If you had an extra dish that you could put into a "Seek" mode. I view it as an emergency connection, and all you would be able to do in this mode is enable/point antenna. flight computer and other tasks would still be unavailable until you had established a dedicated connection.
The thing is, I seriously doubt real sats and probes don't have an emergency protocol, if comms fail. Perhaps a new dish could be added, emergency dish, regularly unusable, untill comms fail. In that case the player can hit the "turn-on" button the on dish that would start seeking a usable acess point, providing something like 30 seconds of comms before shutting down and becoming unusable.
Just a tought...
Here's how I'd propose "auto-targeting" would work, FWIW:
- The "auto target" only applies to the active vessel. It will only try to connect a) if there's no connection, and b) there is at least one dish that is configured to track the active vessel (either with the generic "Active Vessel" setting, or by specifically targeting the vessel). It will not work on background vessels.
- When the "auto target" selects a dish, the vessel will remember that dish, so when the player switches away, the connection is maintained, provided the dish on the other end is configured to track that vessel. If it's configured for "active vessel", the connection would break. Essentially, auto-target would update RTAntennaTarget for the dish in question.
- RemoteTech_settings.cfg has a boolean that enables the feature globally - that way, if a player thinks it's too cheaty, the player can switch it off.
@guto8797, realism is not the issue. There's plenty of unrealism in the stock game, beginning with the whole idea that you can launch a space mission without extensive and careful planning. Since KSP is a game, the real question is, "how can we make RemoteTech both fun and challenging"? If that means sacrificing realism, so be it.
I have not tested anything here, but what is the current alternative to a seeker dish minus the omni?
X-dishes in opposing directions to 'scan' for other dishes? On Jun 25, 2014 11:41 AM, "Starstrider42" [email protected] wrote:
@guto8797 https://github.com/guto8797, realism is not the issue. There's plenty of unrealism in the stock game, beginning with the whole idea that you can launch a space mission without extensive and careful planning. Since KSP is a game, the real question is, "how can we make RemoteTech both fun and challenging"? If that means sacrificing realism, so be it.
— Reply to this email directly or view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/107#issuecomment-47127540 .
@Starstrider42 I am aware of that. I have just finished launching a giant sepatron banana into space. However I think the emergency dish mechanism, or MOARdv's solutions are fitting and wouldn't tune down the fun. The dish would be junk after the emergency comm, and if you don't like it, don't add it into the ship. MOARdv's solution is more automated and can be toggled in the settings so I think they are nice solutions. Any enhancement to RT2 is welcome, and having a well built probe run out of comms at Jool is not that much fun.
@guto8797 Building a communication network that reaches all the way out to Jool without loosing connection is, at least for me, Fun.
Having to plan and be meticulous about orbits and antenna ranges and antenna assignment is where so much of the reward of RemoteTech comes from for me. I understand others might have a different playstyle.
On a slightly related note i would love to extend the RT API to let other mods enable/disable and repoint antenna. I would then like to have kOS scripters write their own emergency script like we are talking about here.
@erendrake Yes I agree with you. We have no acess to Kerbal Engineering (which seems half spit half struts), but IMO kerbals would have a very simple programation language:
-IF CAN NO SEE HOME: :SPAZZ OUT :LOOK FO HOME :FIND HOME: IF NO HOME FOUND KEEP SRCHING FO SNAKS
I mean we all know that feelin. Did I forget to turn on the dish? Yes I did. Crap. Well, another glorious hunk of metal to feed Kerbol.
Cilph wrote:
I propose a new solution: The Emergency Recovery Button (enchanted with +10 Shame and Tears).
Upon loss of connection for a minute, a button would show up in the corner of the screen that upon activation would instantly activate all (or configurable) antennas and set them to point at Kerbin (or configurable). The player would then be given the opportunity to recover the craft by pointing one of their satellites at it to re-establish connection.
MOARdV wrote:
I think this is similar to my proposal #107, with it being an explicit "Press me to recover your sat" instead of an "automatically recover this sat", although you're proposing it being in the tracking station, where I was proposing you had to switch to the derelict vessel and recover it there.
From a play perspective, I don't think the Tracking Station is the best place to put the recovery option - it may be normal for craft to go out of contact temporarily (solitary probe orbiting a distant world), so it could pop up as a false positive. It also requires additional effort to provide a pick list of all out-of-contact craft at a given time. If the button only pops up on out-of-contact craft when they're selected in the Tracking Station, then I think it becomes easier to manage.
Starstrider42 wrote:
Just pointing out that pointing at Kerbin is not necessarily a good solution -- one of the common mistakes players make is using a too-narrow cone from too close a range.
So to summarize the brainstorming so far, the options are:
- A virtual "Seek" target that enables control only of the antennas on the ship, to keep conventional targets competitive.
- A special dish that gives the player some limited time to fix their main links themselves.
- An auto-target (command? target?) that selects a satellite to point to by some criterion. The newly established connection is treated equivalent to all others.
- A reset command that directs all dishes to point to a predefined target.
- Scripting support so players can write their own search program.
As the pessimist of the team, here are the problems I see with each of these (with very occasional suggestions for solutions):
- While RemoteTech is about planning ahead, this proposal basically amounts to players having to keep a separate dish in reserve for emergencies. = Extra weight, extra tedium. How about having a "can seek" flag on the antenna that can be toggled with either the right-click menu or the target selection window? That way, you don't have to carry extra antennas, but you can still make sure that the Clippy effect won't mess up your targeting.
- As above, I'm not sure I like the idea of an antenna that's dead weight most of the time -- while real spacecraft do have backup systems, it doesn't really fit the feel of KSP. Also, I can see a time limit (even a user-triggered one) causing a lot of frustration.
- How will the auto-targeter pick connection targets? I could see this leading to a situation where the player can't connect, despite there being an obvious good target, because the targeter stubbornly insists on picking useless targets. Or what happens if you're just, say, swinging around the far side of the Mun? Will the target be permanently set to something that isn't appropriate when you come back over the horizon? On the other hand, if we do find an algorithm that always picks good targets, will this make manual targeting obsolete? Will it make dishes into basically big omnis?
- Is the problem of picking good back-up targets any different from the problem of picking good targets in the first place? I would think this just pushes things one step back.
- Too complicated, methinks. Users would have to learn scripting just for this one situation, and we'd either make kOS de facto required or waste time implementing a minimal copy.
I do like MOARdv's idea that auto-targeting should be restricted to the active vessel; that would keep players' carefully configured networks from getting Clippied just because one vessel somewhere in the network has a temporary blackout. I suggest we do that no matter which (if any) of these ideas we end up implementing.
To answer (3) - first, I'd make one change from my previous proposal: make it a button that's available when there is no connection (taking Cilph's idea from #111) instead of auto-magically reconnecting. When it's pressed, the active vessel will check for any networked dishes it can see that are pointing at it (tracking the vessel, tracking Active Vessel, or pointed at the SoI). A "networked dish" for this discussion is any dish node that has a connection to KSC or another command center.
Since this is a "recover my vessel" button, it will pick one of those connections if it can, even if it's not perfect. For the far side of the Mun, for instance, maybe it latches on to something farther away from Kerbin. When it swings around to the near side, it'll lose that new connection. The player would have to recover again if communications needed re-established right away.
Continuously-connected interplanetary relays still require manual setup - if the remote vessel latched on to the signal from a dish configured for "Active Vessel", its connection will go dead when the player switches attention elsewhere.
True, Cilph's manual toggle would solve the far side-of-Mun problem, since that forces a human to decide that the network is broken.
My question about intelligent target selection, however, was more along the lines of "can we even write a program that will, for example, know that a relay near Kerbin is preferable to one in interplanetary space".
To answer (5) the API changes i proposed wouldn't have to use kOS, If someone else wanted to make a mod that did auto targeting and utilized the API would be able to do so as well. I dont want to sound like a kOS chauvinist, even though i am ;)
Just to throw another log on this fire. We could allow each dish to have a priority target list. so a user would specify an ordered list of targets and if the dish cannot find the first one it attempts the second and so on. I think that is very consistent with real world limitations in that you could not set it up if you dont have a connection, but it is not a all-or-nothing pointing like we have now.
each dish part cfg could define the number of targets it will be able to hold, and users can mess with it if they want.
@Starstrider42
My question about intelligent target selection, however, was more along the lines of "can we even write a program that will, for example, know that a relay near Kerbin is preferable to one in interplanetary space".
Once we select the list of antennas that our vessel can talk to, we find which one is the least expensive (in terms of delay to KSC / other command center) and pick it. Presumably "shortest delay" is a reasonable proxy for "good choice to talk to home".
@erendrake
We could allow each dish to have a priority target list. so a user would specify an ordered list of targets and if the dish cannot find the first one it attempts the second and so on.
I think that would be a good feature, even if it's somewhat orthogonal to "auto-targeting". Having a prioritized list of dishes would likely eliminate some consternation - "Aim at KSC, or Deep Space Relay 1, or Deep Space Relay 2" is better than "Aim at KSC and be out of touch 50% of the time" or "Aim at Kerbin and ... wait, how narrow is this cone again?" I think a "find home" button is still a good thing to support.
@MOARdV I have come up with an orthogonal solution because of a strong dislike the idea of "auto-targeting" and i also believe that target management is a issue that we need to address.
I believe we can find a solution that is computationally easier and leaves deep space networks as something you need to design which is the heart of RemoteTech. I am not opposed to ideas that make target management easier, just those that eliminate it altogether.
@erendrake I agree that auto-targeting - as in "completely autonomous targeting, the player doesn't need to do anything" - is undesirable. Maybe I am being misconstrued since the issue title is "auto-targeting". I am not arguing that RemoteTech should automatically manage dish connections. I do think that the player should be able press a button on a "lost" craft and have it attempt to re-establish communications with KSC in the manner I detailed previously. Making it an opt-in action ("push the button") allows players wanting a more challenging environment to ignore the feature while reducing the current steep learning curve for less experienced players.
Ok, I've edited the title to make it a little more inclusive.
erendrake's target priority list is basically a more complex variant on Cilph's idea of a backup, I think. Though the way MOARdV puts it makes it sound more helpful than I'd assumed at first. I still have two concerns about the idea, though:
- I think we would need to limit the number of targets per dish to 2-3. Any more, and dishes start becoming too omni-like. This concern also applies to Cilph's target groups (#27), incidentally.
- Allowing multiple targets could add another layer of complexity and/or unintuitiveness to a mod that already has problems with good feedback and easy-to-understand options. So the UI design for multi-targeting could make or break the feature.
@Starstrider42 You are right, a target list should be something manageable and it would be a fairly small number maybe even 2 at the start.
One of the reasons i am liking this is that it retains the point to point nature or dishes, because it only actually links with one other satellite. That being the first one it can get a connection to.
as for the UI complications i think you are right, Ill make some kind of mockup to share with the group.
@MOARdV I do understand that sometimes you might have a problem with the mod or your save or a silly mistake and that can ruin your 10 hours of work setting up a network around duna and we should try to address it. I am simply uncomfortable advocating for allowing any control of disconnected satellites.
I might be pigheaded about this kind of thing but i think that there should be a few bright lines in RemoteTech that we cant cross, In the same way that resource conversion mods should never allow for a net gain in mass after a conversion. and balloon mods should't let you hover over an airless moon. If we are a mod that is about establishing deep space networks and we dont obey the simplest rules of what i would consider our domain, I think it cheapens the reward of success.
I can think of a few tools we could give users that will help them mitigate these oops moments, and we should do them all in time. It will be a long process where we refine and add to the planning tools users have. Having said that there should always be a way for you to screw up and watch your new expensive craft drift away.
@erendrake I won't keep flogging for the "save my bacon" button. :)
I think a priority list of multiple dish targets will go a significant way towards reducing the inexperienced "oops" moments. Allowing 1 or 2 fallback (so, 2-3 total) targets should cover most any reasonable situation, particularly if "Target Active Vessel" remains an option for those relays over Kerbin.
I am interested in seeing the UI mockups, once they're ready to share.
As a Dwarf Fortress and KSP player, I wholeheartedly agree - losing is fun! On Jun 27, 2014 5:55 PM, "Chris Woerz" [email protected] wrote:
@MOARdV https://github.com/MOARdV I do understand that sometimes you might have a problem with the mod or your save or a silly mistake and that can ruin your 10 hours of work setting up a network around duna and we should try to address it. I am simply uncomfortable advocating for allowing any control of disconnected satellites.
I might be pigheaded about this kind of thing but i think that there should be a few bright lines in RemoteTech that we cant cross, In the same way that resource conversion mods should never allow for a net gain in mass after a conversion. and balloon mods should't let you hover over an airless moon. If we are a mod that is about establishing deep space networks and we dont obey the simplest rules of what i would consider our domain, I think it cheapens the reward of success.
I can think of a few tools we could give users that will help them mitigate these oops moments, and we should do them all in time. It will be a long process where we refine and add to the planning tools users have. Having said that there should always be a way for you to screw up and watch your new expensive craft drift away.
— Reply to this email directly or view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/107#issuecomment-47404529 .
I agree with and really like the idea of a failover system rather than an "all powerful' auto targeting system. Real networks (computer networks, not necessarily sat networks) use failover very commonly.
-Most relatable might be for internet name servers or DNS as most people know them. They would be an example of individually specified failover where you must add each server you want to try to connect to. If you look at your DNS settings you commonly have the option to add a second one which will be tried if the first can't be reached.
-Time servers are similar but act a bit more like a failover group (in round-robin sequence). If you open up your computers clock/time settings you can find an area where you can specify which server to try to connect to for syncing your computers time. If you select "time.nist.gov" your computer is essentially trying to connect to a group of 30ish servers, if one is unreachable you will get another instead.
I think that a mix of the two might be a good thing for RT. Whereby you would have your main target, a single assignable failover, and a permanently fixed priority 3rd failover "group" that would always have KSC or Kerbin, as well as crafts set to be part of the failover group.
I do think that you should have the ability to add to the failover "group" but that it should be more difficult in league with creating a new control station (needing X# of kerbals or an equivalent metric, maybe a new BIG part). In my mind I was thinking an antenna array (like those at NRAO) which would be special in that you would "assign" it to be part of the failover group and it must always be looking for crafts that are trying to use the failover group.
As such an example might be for a craft in low jool orbit: -Target: Jool relay satellite. (within or near jool's SOI) ---Failover: Interplanetary Comms. (outside kerbins SOI, near duna perhaps) ------Failover Group: (KSC, MUN Antenna Array, Solar Antenna Array, etc
Just my thoughts on the topic.
Just going to place down my idea for this:
Instead of autotargets, place an antenna into 'standby ready'.
It is similar to 'no target' with the exception that the moment you target that vessel with another antenna from another vessel, it behaves as if it had just been called and locks onto the one talking to it.
It then remains locked to that transmitting antenna until said antenna is powered down, out of connection range (via distance or occlusion), or untargeted.
The limitations of this mode are the following.
1: You have to place the antenna in Standby Ready mode. Which means you have to dedicate it to the function and can't aim it elsewhere. 2: It will not acknowledge any other attempts to connect to it and retarget unless it is sitting in standby.
It's like a telephone. You can ONLY call it if it's on the hook.
Hmm... this is similar to MOARdV's suggestion, but without the ambiguities about what connects when. I like it.
Only one problem: what happens if you have Standby Ready on the active vessel, and you have multiple ships with antennas set to target Active Vessel? I imagine that which antenna connects "first" in that situation is basically undefined.
Only one problem: what happens if you have Standby Ready on the active vessel, and you have multiple ships with antennas set to target Active Vessel?
I'd propose "shortest connection to a command center" would win. That seems to me to be the most appropriate criterion, since available bandwidth isn't a factor in RT.
Unfortunately, I think the links will be created one at a time. So the SR antenna will be offered an Active Vessel connection without being told that there are other options.
Ah. I haven't looked at the network code. I guess I assumed there'd already be state info available, so all it'd have to do is collect a list of dishes that it could connect with and query the minimum cost from them. I've been wanting to tinker with the network manager locally anyway (woke up in the middle of the night mentally sketching a design for how I think it ought to work) - maybe I should go do that and find out how the current design works.
Whatever solution is chosen, remember to keep it intuitive and simple. RT2 is a complex mod, many users being scared by it, adding even more unchecked complexity is only going to make it worse. The solution needs to be largelly intuitive, as in any sort of game, thinking: "Well, that should do that, its logic" and then having it do the complete opposite is very frustrating. In the best games (and in this case mod) the users are able to tackle the issues by themselves just by thinking.
All things considered, really if SR mode is applied, how it goes about finding which 'active vessel' link would be transparent anyway. So that won't be anything players need concern themselves about just yet.
The real question is determining what the best criteria for the link would be. Because you don't want it throwing inappropriate links at the player.
So far, the two suggestions on that are 'First Come First Serve', which is simply when multiple connections come down the line, it just goes linearly to the first one that comes up in the code; And 'shortest distance' where the shortest cost hops to the command center win, which requires evaluation.
However, thinking about the nature of the connection I don't think even that is necessary.
See, you don't want to use flat linear progression through the list because there's the chance that the first acceptable connection doesn't link to the command center. But calculating lowest cost in terms of hops introduces more code and CPU time. With a physics engine already strapped for cycle time when scaled up, we don't want to introduce superfluous additions to the code.
I suggest linear progression with a simple qualifier check. 'Is connected to mission control' (or IS mission control in some cases.)
When said connections go active, they check if there's a M.C. route active. If so, it stops right there. If not, it passes on it for the next in line. No special algorithm needed, no sorting required.
And it doesn't matter if the connection won't be the best or that it will drop soon or any other dozen reasons why nobody wants it. Because in RS mode, as soon as a connection drops, it starts looking again. Just carry that out a little more in this case. If the Mission Control link fails, it just reverts to the standby search.
In fact, make that THE qualifier for the satellite to accept a contact in Standby Ready, not only is it being talked to by another antenna, it MUST have a M.C. link. This will still be transparent to players because they'll need an established connection to control the existing satellite they're aiming around anyway.
But calculating lowest cost in terms of hops introduces more code and CPU time. With a physics engine already strapped for cycle time when scaled up, we don't want to introduce superfluous additions to the code.
I had envisioned RT could offload network graph generation to a background thread which could step through, evaluate the network, and collect the essential metrics for querying. That's not how it appears to work currently, but I don't know of a reason it can't work that way (I intend to see how tough it is to implement when I have spare coding time). But, without cached info in the nodes, I agree that evaluating the path repeatedly is too costly.