Radio Signal Ping

[Guest]

55 minutes ago, Dragon01 said:

Again, not true. For one, it would mean you have to plan ahead, scheduling commands while knowing that if something goes wrong, you may not be able to reprogram the probe in time. Even better, lower-tech probes might have a limited space for commands. You may need to decide whether you want the "fold antenna" command or the "do more science" command (anyone remember the Galileo antenna?). "Build the rockets and program them" is a valid way to play the game. It won't be mandatory, because probes themselves won't. I don't think the devs could be convinced to go with a "probes first, Kerbals later" tech tree, so signal lag would do nothing as long as you keep Kerbals aboard all your interplanetary vessels. 

Also, something like stock kOS is very highly likely. The devs wanted a LUA-based... something in the game, and it doesn't seem to be related to writing plugins. If this was supposed to be a major part of the gameplay, though, I'd prefer something like MechJeb with a more streamlined GUI.

Oh, and autoland is automation, at least in its simplest form. It's a pretty simple process, if your craft is designed right. Landing on an airless body is essentially a gravity turn in reverse. Doing it manually with maneuver nodes would be quite possible if KSP had a GUI to allow viewing the descent path in more detail.

I'm not saying that programming with or without the delay is exactly the same, my point is that the programming/automation part is the biggest component of the whole delay idea.

In this scale:

1- Programming and real time control

2- Programming and commnet control (comment as KSP1)

3- Programming only (you can send "pings" to the program, not controlling anything directly)

4- Programming only with delay on the pings

I would set the default at 2 and play at 3 

Edited September 20, 2019 by Guest

[Guest]

42 minutes ago, Brikoleur said:

There is no way Star Theory would do something as boneheaded as implementing a large set of systems (probes, CommNet) and then gating it behind a programming requirement, thereby ensuring that only a tiny fraction of the player base would ever use them.

There will be no time delay. 

It's programming only in the widest possible sense. Is making a flowchart-style sequence of events really "programming"? Or lining up a few maneuver nodes? There were actual LEGO sets (1st generation Mindstorms, to be exact) that used this exact sort of thing. Expanded flight planning is something KSP really needs, anyway. Once we have a way to plan the flight, making the ship automatically execute it isn't that big of a jump, and interesting gameplay options could be built on that.

You can be sure that the time delay will come up in suggestions, whether you like it or not. And if the devs find a way to implement it that works for them, they will, whether you like it or not (or at least, I hope they do. Squad has faced similar comments from those who were dead set against a realistic atmosphere). Probes need to differentiate from Kerbal control, right now they're simply not very interesting. 

Proliferation of difficulty options isn't really a good idea. An optional feature can't be relied to be on, which means it can't serve as a base for other mechanics. Signal delay might be a good choice for a difficulty option, but some difference between probes and Kerbals needs to remain, otherwise it'd fall into the same pitfalls as KSP1 (that is, lots of choices that don't really matter).

[Guest]

7 hours ago, Dragon01 said:

It's programming only in the widest possible sense. Is making a flowchart-style sequence of events really "programming"?

Certainly. There are plenty of visual programming languages. 

7 hours ago, Dragon01 said:

Proliferation of difficulty options isn't really a good idea. An optional feature can't be relied to be on, which means it can't serve as a base for other mechanics.

I agree. Making features optional is also a waste of developer time - they’re spending time making things that they think a significant number of players won’t like.

Signal delay still isn’t going in, or at most in some extremely symbolic, almost not there way - like, interstellar only, with autonomous probe cores and interstellar comms never allow non-autonomous probe control. It’s would change the gameplay too much, and in a way that is not appealing to most KSP players.

KSP is a game first and foremost. More realistic is not automatically better.

 

[Guest]

7 hours ago, Brikoleur said:

It’s would change the gameplay too much, and in a way that is not appealing to most KSP players.

Is your name "most KSP players"? Sorry, it isn't. Visual programming, when explained right (and if you're not trying to do too much with it), is simple and intuitive, almost like building a KSP rocket, in fact. In fact, there are real rockets that are programmed like that. While I don't think they'd implement DRAKON-Lua wholesale, something of that sort would help even little kids get into programming. And that is a very good thing, because programming is a pretty useful skill.

KSP is an educational game first and foremost. It has a chance to teach people about real science and engineering. Every time Squad added a new "realism" feature, it improved the game in the long run. Therefore, I'm convinced this would be the case here, too. And yes, many of those features received complaints from people exactly like you. Squad didn't listen to them (well, not until they started adding non-core features like comms, anyway), and I hope Star Theory doesn't, either.

[sgt_flyer]

8 hours ago, Brikoleur said:

Certainly. There are plenty of visual programming languages. 

I agree. Making features optional is also a waste of developer time - they’re spending time making things that they think a significant number of players won’t like.

Signal delay still isn’t going in, or at most in some extremely symbolic, almost not there way - like, interstellar only, with autonomous probe cores and interstellar comms never allow non-autonomous probe control. It’s would change the gameplay too much, and in a way that is not appealing to most KSP players.

KSP is a game first and foremost. More realistic is not automatically better.

 

Well, interstellar comms are going to be a problem though - you’d need new kinds of antennas / laser based transmissions to be able to have the necessary signal strength (based on ksp’s current signal system) at interstellar distances.

maybe controlling probes in other solar systems will only be feasible if you set up a control station manned with kerbals in that system. (Kinda like in Remote tech 2 where you need a manned local space station to eliminate most of the signal delays)

[Guest]

3 hours ago, Dragon01 said:

Is your name "most KSP players"? Sorry, it isn't. Visual programming, when explained right (and if you're not trying to do too much with it), is simple and intuitive, almost like building a KSP rocket, in fact. In fact, there are real rockets that are programmed like that. While I don't think they'd implement DRAKON-Lua wholesale, something of that sort would help even little kids get into programming. And that is a very good thing, because programming is a pretty useful skill.

KSP is an educational game first and foremost. It has a chance to teach people about real science and engineering. Every time Squad added a new "realism" feature, it improved the game in the long run. Therefore, I'm convinced this would be the case here, too. And yes, many of those features received complaints from people exactly like you. Squad didn't listen to them (well, not until they started adding non-core features like comms, anyway), and I hope Star Theory doesn't, either.

Except programming doesn't require to be a mandatory step for all probe missions to be considered.

Nobody is objecting against in-game programming, we're objecting against locking half of the game behind it with actual delay in place.

Any failure involving delay would only be frustrating and unfun for most of the players.

Edited September 21, 2019 by Guest

[Guest]

3 hours ago, Dragon01 said:

Is your name "most KSP players"? Sorry, it isn't. Visual programming, when explained right (and if you're not trying to do too much with it), is simple and intuitive, almost like building a KSP rocket, in fact. In fact, there are real rockets that are programmed like that. While I don't think they'd implement DRAKON-Lua wholesale, something of that sort would help even little kids get into programming. And that is a very good thing, because programming is a pretty useful skill.

I am not most KSP players but I can still have an informed opinion of how most KSP players play the game.

And as I said, I would love stock kOS, except better -- and some visual programming language would be a perfect fit for it. No argument there!

3 hours ago, Dragon01 said:

KSP is an educational game first and foremost.

No, it's not. Any educational benefit it has is a side benefit.

20 minutes ago, Master39 said:

It has a chance to teach people about real science and engineering.

It can teach some things about real science and a very few things about real engineering, but, again, that is a side benefit.

20 minutes ago, Master39 said:

Every time Squad added a new "realism" feature, it improved the game in the long run.

Therefore, every other realism feature would also improve the game in the long run? That's what they call a non sequitur, my friend. I am 100% sure that making KSP a realistic rocket simulator -- which would not be a very big leap! -- would immediately cause 95% of the player base to switch off. Even a majority of the really enthusiastic fans who hang out here would drop it. Look at the number of people playing with Realism Overhaul, Real Solar System, Principia, RemoteTech with signal delay, hardcore LS mods, and so on: they're there, and they're a significant contingent, but they're not numerous.

KSP is not, and should not become, a hardcore rocket simulator. Signal delay is one of several features that really do not belong in it. As @Master39 said, locking a major chunk of the gameplay behind a programming requirement is not the way to go.

(And before you start on another of your "you probably haven't gotten very far then" assumptions, I personally have no fear of programming -- I shipped my first production software 35 years ago in two months, and haven't stopped since.) 

[StarStreak2109]

I'd love to see the whole CommNet thingie getting some love!

I do not necessarily want to make it more complex, but giving it more options and adapt it to reflect the interstellar theme. Here are some key points that I think would be needed:

1. Having optional signal delay, however with an integrated autopilot. This adds an extra challenge for those who want it. This autopilot would in my line of thinking something similar to MechJeb, where you pre-program the necessary manouvers and it will execute them at the appropriate time. This would also include for instance executing science experiments during closest approach of a planetary body. And I also would not make this a scripting language thingie, but rather an intuitive GUI, where you select the manouvers and science bits you want to use and say like: "Circularize at perigee; decouple lander; initiate autoland; deploy science equipment."
2. Better simulation of planetary occlusion and network ranges. Right now, I need extra tools to plan out my communications network. I'd love to have an integrated tool that takes into account the ground stations, any orbital communication satellites and other relays to tell me whether or not I have sufficient communication hardware on my probe or space ship. I know that it is "the Kerbal way" to find that out on the go and then send out rescue missions, but to me, this is just frustrating...
3. Have communication systems adequate to their range. We are moving now beyond the confines of the Kerbol system. So yes, for the earlier game play we would still rely on the good ole Communitrons, but later, I would like to see tight beam laser communication systems etc. Maybe even as the ultimate tech some "subspace" gear, that allows FTL communication on interstellar distances...

Just my 2 cents...

[Guest]

3 hours ago, StarStreak2109 said:

And I also would not make this a scripting language thingie, but rather an intuitive GUI

It's pretty standard in every "space engineering" game right now and objectively would be less disruptive than the signal delay for new players, if coupled with a visual programming interface would be as easy as the action groups to use and way easier than the timeline-based robotics computer we have now.

The programming part is 90% of the signal delay challenge, without programming signal delay is basically just an excuse to use an autopilot without it feeling like a cheat.

[Guest]

2 hours ago, Master39 said:

It's pretty standard in every "space engineering" game right now and objectively would be less disruptive than the signal delay for new players, if coupled with a visual programming interface would be as easy as the action groups to use and way easier than the timeline-based robotics computer we have now.

Here's one thought about how signal delay could work without locking out a major part of the gameplay behind a programming interface -- while obviously the programming interface could be used to enhance the experience and do certain specific things that couldn't be done this way. Let's assume we have an implementation of a nice and intuitive way of programming probes, including manoeuvre planning and execution, autoland, auto-orbit, and auto-dock as well as running science experiments and so on.

And no it's not 100% realistic, it's a simplification. Reality is overrated anyway.

Define a "radius of direct control." Let's say this is big enough to encompass, say, the Jolian system, but not so big enough that it covers interplanetary distances. 

Within this radius, probes work as they do now -- direct control if there's a signal, no control if you don't. So for example sending a probe to the Mun would work exactly as it does now. Probes could be remote-controlled like now, if you have a command module with a probe control point. So if you want to do probe missions like you do now, you need to have a functioning probe control station in the target system, with a signal to the probe.

Outside the radius, if you have a signal to the probe, you can reprogram them, transmit Science back, and so on, but there is no direct control.

I would in fact leave it at this: I don't think introducing an actual signal delay would improve things, it would just introduce mandatory busywork time-warping through it until your new program got received by the probe. However if the realism crew really enjoys clicking the timewarp button, that could be an option; it wouldn't change gameplay at all, other than making that button-clicking mandatory.

To make it a bit more interesting and give a feeling of progression, you might unlock the probe automation in the tech tree. Early probe cores can only execute orbital manoeuvres autonomously; later ones will get autolanding, auto-orbit, and auto-docking in some order.

Edited September 24, 2019 by Guest

[StarStreak2109]

2 hours ago, Master39 said:

It's pretty standard in every "space engineering" game right now and objectively would be less disruptive than the signal delay for new players, if coupled with a visual programming interface would be as easy as the action groups to use and way easier than the timeline-based robotics computer we have now.

The programming part is 90% of the signal delay challenge, without programming signal delay is basically just an excuse to use an autopilot without it feeling like a cheat.

This leads to the old "autopilots are a cheat" discussion, so I won't go into this. Let's just say it would be a game play balancing issue to decide how much autopilot becomes a cheat.

[Guest]

2 minutes ago, StarStreak2109 said:

This leads to the old "autopilots are a cheat" discussion, so I won't go into this. Let's just say it would be a game play balancing issue to decide how much autopilot becomes a cheat.

I don't think that autopilots are cheat, I just don't use them. Probably people who want signal delay just to justify them are the one thinking they are a cheat.

We don't need signal delay to justify having some decent auto-pilot features.

[StarStreak2109]

5 minutes ago, Master39 said:

I don't think that autopilots are cheat, I just don't use them. Probably people who want signal delay just to justify them are the one thinking they are a cheat.

We don't need signal delay to justify having some decent auto-pilot features.

Fully agreed.

[Guest]

2 minutes ago, StarStreak2109 said:

Fully agreed.

Same. I'd just like them a bit further down the tech tree so you'd have to fly those things manually to start with. Autopilots could greatly mitigate the grindy aspects of the late to mid-game actually.

[tseitsei89]

Better than giving us autopilots is giving us an in game programming language so we can make our own autopilots. Kind of like kOS but better version preferably

Edited September 24, 2019 by tseitsei89

[StarStreak2109]

This is going off-topic now, so just a short remark. I think the MechJeb approach is quite good in that regard by offering an GUI'd set of autopilot functions and additionally a scripting language. Giving the average player only a scripting language for autopilot purposes provides too much of a difficulty for novice players.