What do we know about the RemoteTech/AntennaRange-alike in 1.1?

[MaxwellsDemon]

Knowing that something like this was in the works for stock, I've delayed on d/ling RemoteTech... I'm waffling over whether I should wait or not.

[Sharpy]

I can see a case for multiple non linear triggers for actions having merit and also being implemented in a way that is much more simple than KOS yet only slightly more complicated than RT2.

If for example instead of just a pure timer, if altitude, velocity and pressure (and other triggers I am sure) could be used to trigger events then the interface would not need to be much more complicated than a pure timer but would expand the usability of the flight computer a great deal.

There could be linear events such as `in X seconds arm parachute` followed by `in X+10 seconds deploy landing gear` or non linear triggers such as `altitude<20km log temperature`

You might look into Smart Parts

Some of them add such triggers as parts attached to the ship.

[razark]

We have a method for programming complex maneuvers for spacecraft in stock, it's called a maneuver node. There is no reason for a probe flight computer to be more complex than this. Make m-node, m-node is uploaded to probe (meaning the node must be at least _light-lag_ seconds ahead of the craft), probe executes m-node at the right time. Ideally all this should be able to happen out of focus.

I still hold to the position that this is what pilots should be able to do as well, without the lag. So there we go. Orbital maneuvers should be solved this way.

Landing is trickier.

I could see a simple parachute reentry as being possible, but the powered descent and landing I didn't. Maneuver nodes could be a workable solution. That does leave the problem of deploying gear and such, or staging off sections. I'm not sure how the nodes would work with landing on a planet with an atmosphere, though. Would air resistance change throw off the delta-v/burn time calculations?

[Renegrade]

Thank goodness for no signal delay. Signal delay in RT was about as fun as colon cancer - I turned that off right away. I don't think any mission has ever used remote pilot control since the Soviet Lunokhod program, so it's not unreasonable to imagine that direct instant player control is an abstraction of the probe core's control program doing (or not doing, as the case may be) it's job.

I'm also glad to hear that it will use a Deep Space Network model, as stock tends to leave some rather important things unmoddable. :C

[FancyMouse]

Signal delay is realistic in the sense that you can't react on something too far away immediately. I do agree that the lack of a better flight computer is making life harder, but turning signal delay off is IMO a wrong direction, at least not what I will do.

and hey since neither 1.1 new stock nor RT is forcing signal delay, life is good for both sides.

[Renegrade]

Signal delay is realistic in the sense that you can't react on something too far away immediately. I do agree that the lack of a better flight computer is making life harder, but turning signal delay off is IMO a wrong direction, at least not what I will do.

The probe core's control program is the thing doing the reacting. Autonomous control has been THE thing in deep space probes since forever. Direct control and input lag is the exact opposite of realistic. A realistic system would basically be like kOS scripting, but with absolutely zero direct control over the probe. And it would be in some nasty IBM RISC assembly (remember, you have to NOP a couple of times after a branch or else you'll create a hazard and cause a fatal exception) or some bizarre thing like APL.

Instant direct control is a more than sufficient abstraction, especially given Squad's development time constraints.

Remember, you aren't ground control when you're operating a manned craft, so why would you be ground control when you're operating an unmanned craft?

[KerikBalm]

Personally, this is one change that I am not looking forward to...

"Planets affect line of sight"

Unless probes are given the ability to execute maneuver nodes that were set while they were in contact, this means almost no probe will ever go to a location before a kerballed mission, and insert into a prograde orbit...

"the lesser of the antenna range and tracking center range is the limit"

-Pretty much all your probes you launched in career with just the Comm 16 beyond LKO are now lost.

"they can still fly the ship, but they would lose access to the probe’s piloting capabilities (i.e. a ship where a player uses a probe core for control, and crews it with a non-pilot)."

That makes no sense... I guess the aviaonics nose cone is unaffected, since its not a probe core?

If the piloting capabilities of a probe are based on the skill of the remote operator, then all probes should just inherit the ability of the highest skilled pilot in range.

A Lvl5 pilot can make one probe point at a target, or point prograde, but not another probe, while a scientists can't even get the probe to stop spinning?

I guess this is to make pilots more useful, but this isn't the way.

Give pilots the ability to execute maneuver nodes (like the probes should have if we can't control them on the backside of a celestial body).

Give them the ability to level the ship with respect to the surface, to hold a certain orientation to the surface, etc.

Then for the probe core advancement, if they can execute maneuver nodes, that automatically means it must be able to orient for the burn, which is currently restricted to the highest tier probes.

Instead, we should redo the probe tiers:

Tier 1: Basic remote control, inherits the piloting skills of the best pilot within control range.

Tier 2-3: semiautonomous remote control, can engage SAS, hold prograde retrograde, etc etc, to act as an autopilot for scientists and engineers, etc.

Tier 4-5: can execute 1/multiple preprogramed maneuver nodes without being in comms range - but maneuver node must be set while within coms range.

Heck, it doesn't even need to be done "on rails" in the background - we could still have to have the probe in focus - it just wont accept commands

Right now I'm pretty unhappy with the system as described, and I think I'll be turning it off if possible.

[FancyMouse]

The probe core's control program is the thing doing the reacting. Autonomous control has been THE thing in deep space probes since forever. Direct control and input lag is the exact opposite of realistic. A realistic system would basically be like kOS scripting, but with absolutely zero direct control over the probe.

If you agree with the kOS model, then unfortunately I would disagree the rest parts. A probe can react on something that is preprogrammed. The reaction can be instantaneous upon some monitored event, but the programming itself must happen at least [signal delay] amount of time in advance. If you forget to program something, then you blow up. Without signal delay, this cannot be possibly modeled.

Unless you claim in your KSP world your probe is equipped with an AI as smart as you. Then I'll have nothing to say.

[godefroi]

Signal delay is realistic in the sense that you can't react on something too far away immediately. I do agree that the lack of a better flight computer is making life harder, but turning signal delay off is IMO a wrong direction, at least not what I will do.

and hey since neither 1.1 new stock nor RT is forcing signal delay, life is good for both sides.

I think the point here is that it's not fun (or realistic) to force you to suffer signal delay as if you had to react from light-minutes away, while also not giving you the tools to build the intelligence where it would actually exist (in the probe). In real life, the probe would react instantly (to any foreseen events). Letting the player react instantly is a fair tradeoff, I think.

- - - Updated - - -

Right now I'm pretty unhappy with the system as described, and I think I'll be turning it off if possible.

You can. It's one of the difficulty settings.

- - - Updated - - -

Unless you claim in your KSP world your probe is equipped with an AI as smart as you. Then I'll have nothing to say.

When it comes to orbital mechanics, pretty much every real-world probe built and/or launched since I was born is smarter than me.

I do think that probes (at least higher tiers) should be able to execute maneuver nodes. I'd even be 100% ok with them requiring a connection in order to create a maneuver node. Once the node's created, though, it should execute itself when the time comes, even if the connection has been lost. Hm, someone should make a mod...

[Renegrade]

If you agree with the kOS model, then unfortunately I would disagree the rest parts. A probe can react on something that is preprogrammed. The reaction can be instantaneous upon some monitored event, but the programming itself must happen at least [signal delay] amount of time in advance. If you forget to program something, then you blow up. Without signal delay, this cannot be possibly modeled.

Exactly - how often does this unexpected issue crop up? You're taking about adding a whole bunch of extra programming (on both Squad and end-users) to cover that tiny corner case that happens almost never. I'd guess that the times that the probe would be doing something that it shouldn't under direct control would be what..3%?

In fact, I'd go as far to say that based on current changes in KSP (up to 1.0.4 anyhow), modelling transmission at all is largely a waste of developer time. Manned missions are generally preferable to unmanned (science transfer/reset, more science, engineers to repack chutes and repair stuff, etc), and I think the only thing that has any point in transmitting these days is the science lab results (and only because I didn't see any way of picking up those results for manned return). Transmissions feature some pretty hard caps (I think only EVA and Crew reports get to 100% with transmissions now (and science labs), and are manned-only), so it's becoming rather useless.

Actually, I should probably start a thread about improving the usability of transmissions. I'm not opposed to transmissions...it's just that they've been overtaken by changes (unfortunately, IMO).

As a background, I was a seasoned RT2 vet (that's why I sometimes write 'RT2' instead of 'RT') back in the 0.22/0.23/0.23.5 days. After you've set up a comm net a few times, the wow-this-is-neat factor wears off, and it turns into pure grind. :/

(NB: In my simplified model, you wouldn't even need a connection at all save to transmit data, hence my concerns about transmission becoming useless)

Unless you claim in your KSP world your probe is equipped with an AI as smart as you. Then I'll have nothing to say.

I dunno, I bet I could come up with just straight, non-AI programming that could handle any non-bug situation that could arise in KSP. There's really only two states afterall: you have enough delta-v complete the necessary maneuvers to complete a mission, or you don't. The first case is relatively simple math. I don't think I have to explain the second case. Doesn't take an enormous amount of programming to make Quake bots that absolutely wreck human players. You aren't using your whole IQ to burn retrograde until AP and PE are equal.

Actually, refer to godefroi's post. It's explaining it even better than I can. And it's shorter too.

[rcp27]

For one example, most capture burns that I do are on the far side of bodies which means that without some form of automated control (or manual control with no signal) there will be no unmanned probes attaining orbit around planets on their own, a kerbal will have to be there to control it to allow this.

If you have the dV on your craft, you can achieve a stable orbit (by stable I mean non-escaping and non-crashing) with a single burn from anywhere within the sphere of influence of a body. It is most efficiently done at Pe due to Oberth, but it can be done from anywhere. Just put a manoeuvre node somewhere with LoS back to base and fiddle with retrograde and radial until you get a captured orbit. Once you're captured and stable you have time to fiddle and get the orbit you want at your leisure. With remote tech, I built my comms relay networks around Kerbin, Mun and Minmus entirely based on unmanned launches. For Duna and Eve I carried sufficient probes to construct a comms network as a payload on a manned mission and deployed them once I got there. I've not tackled Jool yet, but that's more advanced stuff.

[godefroi]

In fact, I'd go as far to say that based on current changes in KSP (up to 1.0.4 anyhow), modelling transmission at all is largely a waste of developer time. Manned missions are generally preferable to unmanned (science transfer/reset, more science, engineers to repack chutes and repair stuff, etc), and I think the only thing that has any point in transmitting these days is the science lab results (and only because I didn't see any way of picking up those results for manned return).

The easiest way to make probes useful is to make life support a thing.

[Renegrade]

The easiest way to make probes useful is to make life support a thing.

Yeah, that would make unmanned a lot more attractive, and I'm generally in favor of (very simple; ie single resource) life support.

Not sure the rest of the Kommunity would agree though :/

[godefroi]

Yeah, that would make unmanned a lot more attractive, and I'm generally in favor of (very simple; ie single resource) life support.

Not sure the rest of the Kommunity would agree though :/

I would. Snacks! could work nicely, with a difficulty option to replace the rep loss with kerbal expiration. Mods could provide parts for storage and recycling (and they already do).

[Rath]

I would. Snacks! could work nicely, with a difficulty option to replace the rep loss with kerbal expiration. Mods could provide parts for storage and recycling (and they already do).

STORAGE!!!! we need that wor long range missions!

[waterlubber]

*snip*

Unless you claim in your KSP world your probe is equipped with an AI as smart as you. Then I'll have nothing to say.

http://www.curse.com/ksp-mods/kerbal/220221-mechjeb

Frankly, if we don't have auto-exec manuever nodes, turning off this except for science. Or just stranding Kerbals in orbit. Because I can. Plus, we already have at least two drone cores with AI.

[rcp27]

If you agree with the kOS model, then unfortunately I would disagree the rest parts. A probe can react on something that is preprogrammed. The reaction can be instantaneous upon some monitored event, but the programming itself must happen at least [signal delay] amount of time in advance. If you forget to program something, then you blow up. Without signal delay, this cannot be possibly modeled.

Unless you claim in your KSP world your probe is equipped with an AI as smart as you. Then I'll have nothing to say.

That's all well and good, but in the real world you can do all kinds of simulations and experiments on Earth to work out how various components will work and do detailed mission planning before uploading your program to your space probe. Nothing as simplistic as kOS can hope to match that kind of mission planning, and frankly if it did, it would almost certainly be dull as ditchwater to play. An example of what a space probe can execute without real-time control, is illustrated by this:

In KSP I expect to be able to pull off similar missions. If I can't to tens of pre-flight simulations and part tests, then the next best thing is to just let me, the player, take the role of on board flight computer and let me fly the descent.

[KerikBalm]

then the next best thing is to just let me, the player, take the role of on board flight computer and let me fly the descent.

This.

For transmission of science, fine, but probes should be controllable as an abstraction of them having an AI.

The science stuff is only a minor annoyance to my game, because I often equipped my probes with just a com 16 (reasoning that I can just use a really big receiver, or that the scanning antenna can also be used to send messages).

I do have some ships equipped with the next two large antenna, and now 1 with the antenna from the asteroid day mod (I wonder how that will behave, will I need to add some lines to the .cfg text and make up some numbers to get it to work?)... but for the most part, I think my interplanetary missions won't be transmitting any science for a while once 1.1 hits.

I don't need any science anymore though, I just use it for generating funds now.

[PKing Zombie Spy]

Hmmm. Not pleased with this; even if I liked the feature it's a really bad sign that people are this confused about how it will work. It's sort of like whoever designed this adopted the same incomprehensible complexity of the overhauled science lab and new ISRU, two inessential parts of the game. The trouble is this new artifact of complexity is applied to controlling spaceships, the most essential part of the game.

just let me, the player, take the role of on board flight computer and let me fly the descent.

I've always consciously held this exact abstraction in my head as to how I was able to control probes even when they were many lightseconds or even lightminutes away. The game does not allow me to create a probe control system in game, so it compensates by pretending I am the probe control system. Seems fair to me.

[Dunbaratu]

Nothing as simplistic as kOS can hope to match that kind of mission planning

Sandbox mode exists. Lots of people use it as the simulator for their career game. Try it in sandbox first, then do it in the real game.

[monstah]

(NB: In my simplified model, you wouldn't even need a connection at all save to transmit data, hence my concerns about transmission becoming useless)

There are some sparse situations where I believe planning the connection would add to gameplay value (to hell with realism if it isn't fun), such as rovers on the far side of some planet or moon.

But, then, IRL, rover commands are uploaded in advance and then executed autonomously and painfully slow, so... whatever.

I think I will use the new system, but I'm not too passionate about it (or against it, either). After all, even if RT gets very boring after you set the Nth comm network, there's always that critical moment when you don't plan your connections as carefully as you should and you lose connection 30 seconds before touchdown (been there). In my opinion, those moments are great. If stock is going for an abstracted DSN to take away most of the druggery of setting up your first comm, then the adrenaline you get from missing something crucial, or making sure you didn't, might be well worth it.

But I'm only having an opinion after it's out and tried.