Potential changes to probe cores

[swjr-swis]

2 minutes ago, mcwaffles2003 said:

No, but I don't see why adding that would be a daunting task

So ... yes you actually agree that that functionality would be required. You just want it as part of MJ. Ok so let's put that in a feature request in MJ's thread. Here I think we're discussing wished-for stock functionality of KSP2, specifically a change in stock probe cores to integrate a form of signal delay.

 

4 minutes ago, mcwaffles2003 said:

Was referring to real ones

You've lost me.

 

5 minutes ago, mcwaffles2003 said:

The programming required to make it work is complex, but from the user end it offers less than a VPL would and is more easy to use

I think I'm running out of energy for this exchange, but I'll venture to ask (again, i feel): where would an MJ-level of sophisticated AI fit in the suggested consistent progression from basic low limited tech to high complex fully featured tech? You say you want to position it at the low end. How does that not completely obsolete any of the proposed probe core classes before they're even introduced? This has nothing to do with how difficult or easy of an interface is offered to the player... it's about the capabilities accorded to the part. Specifically those capabilities that would be required to perform independent from a direct remote control connection.

 

6 minutes ago, mcwaffles2003 said:

I will simply say that I've established whole relay networks around other planets under signal delay with the two mods and the tools afforded make the task possible and well within anyone's skill set to do

Ok. I'll assume it is true. It still does not answer in any way how the mechanic of signal delay was implemented nor how those mods and their functions solved the discussed issues expected/implied by a consistent implementation, or even a (what I feel is only partial) implementation like suggested in the OP. It also tells me nothing about how or even if it would work for me, because of the lack of explanation/context.

A simple counter example: I have successfully designed and flown entire armies of atmospheric craft on Kerbin, Duna, Eve and Laythe in a full stock environment, with the parts and tools afforded to make dealing with aerodynamics possible and within what I think is anyone's skill to do.

While this statement is at least as true as yours, it says exactly zero about how consistent and complete aerodynamics as a mechanic is implemented and modeled in the game, how (or even if) it has solved the many issues of simulating aerodynamics in a game, or how and to what extend the parts and tools offered enable me to satisfactorily deal with the challenges of the simulated aerodynamics. I have very strong opinions on it, to be sure, but in a brainstorm session on how to implement aerodynamics in the game, this statement adds nothing.

[Guest]

2 hours ago, mcwaffles2003 said:

What if you were able to reference Long./Lat./Alt. for waypoints? It would just be a more sophisticated version of maneuver nodes.

I think think that having access to a coordinates system it's a prerequisite to land something precisely, not something that makes it easier.

But again, signal delays force you to deal with precise landings in one of this 2 ways:

• You remove the precise landing problem entirely from the game by automating it with mechjeb (click on the map and watch your probe land there on its own).
• You lock it behind a programming knowledge requirement, and not any basic visual scripting (we're talking about "my hobby is writing quadcopters firmware" level of programming).

And that's just choosing where to land, then you need to avoid slopes and/or obstacles while landing (if the terrain system and collidable scatters are half as good as they said this could be a major prolem for automation) and then write some serious obstacle avoidance software if you ever think about moving on the surface, let alone taking off, flying and landing again, or automating basically the whole game and making probes work like units in a RTS game, you point and click and they move on their own.

[mcwaffles2003]

8 minutes ago, Master39 said:

I think think that having access to a coordinates system it's a prerequisite to land something precisely, not something that makes it easier.

But again, signal delays force you to deal with precise landings in one of this 2 ways:

• You remove the precise landing problem entirely from the game by automating it with mechjeb (click on the map and watch your probe land there on its own).
• You lock it behind a programming knowledge requirement, and not any basic visual scripting (we're talking about "my hobby is writing quadcopters firmware" level of programming).

And that's just choosing where to land, then you need to avoid slopes and/or obstacles while landing (if the terrain system and collidable scatters are half as good as they said this could be a major prolem for automation) and then write some serious obstacle avoidance software if you ever think about moving on the surface, let alone taking off, flying and landing again, or automating basically the whole game and making probes work like units in a RTS game, you point and click and they move on their own.

If you want to use mechjeb to land I would say you should have to pick a place where the hazards you mentioned don't pose much of a problem, for avoiding those types of hazards conditional statements in a VPL should make automatic avoidance of obstacles like that feasible.

48 minutes ago, swjr-swis said:

So ... yes you actually agree that that functionality would be required. You just want it as part of MJ. Ok so let's put that in a feature request in MJ's thread. Here I think we're discussing wished-for stock functionality of KSP2, specifically a change in stock probe cores to integrate a form of signal delay.

What? The functionality for signal delay of new commands is already in mechjeb/RemoteTech. I was referring to adding action groups at maneuver nodes so you could automate landing gear deployment by making the desired landing gear part of an action group

50 minutes ago, swjr-swis said:

I think I'm running out of energy for this exchange, but I'll venture to ask (again, i feel): where would an MJ-level of sophisticated AI fit in the suggested consistent progression from basic low limited tech to high complex fully featured tech? You say you want to position it at the low end. 

I don't think you asked me this before, sorry if I glossed over it. I suppose full mechjebs support could come in after the first lunar flyby, thats normally when it's more sophisticated features enter the game already anyways and before that the signal delay is unnoticeable since you have yet to leave low kerbin orbit.

54 minutes ago, swjr-swis said:

How does that not completely obsolete any of the proposed probe core classes before they're even introduced?

Can you explain what you mean by this?

55 minutes ago, swjr-swis said:

This has nothing to do with how difficult or easy of an interface is offered to the player... it's about the capabilities accorded to the part. Specifically those capabilities that would be required to perform independent from a direct remote control connection.

Unless you have disabled CommNet this is already the case.

56 minutes ago, swjr-swis said:

Ok. I'll assume it is true. It still does not answer in any way how the mechanic of signal delay was implemented nor how those mods and their functions solved the discussed issues expected/implied by a consistent implementation, or even a (what I feel is only partial) implementation like suggested in the OP. It also tells me nothing about how or even if it would work for me, because of the lack of explanation/context.

I'm not sure what you are asking for here. Are you asking me to explain how signal delay is incorporated into mechjeb already?

1 hour ago, swjr-swis said:

A simple counter example: I have successfully designed and flown entire armies of atmospheric craft on Kerbin, Duna, Eve and Laythe in a full stock environment, with the parts and tools afforded to make dealing with aerodynamics possible and within what I think is anyone's skill to do.

While this statement is at least as true as yours, it says exactly zero about how consistent and complete aerodynamics as a mechanic is implemented and modeled in the game, how (or even if) it has solved the many issues of simulating aerodynamics in a game, or how and to what extend the parts and tools offered enable me to satisfactorily deal with the challenges of the simulated aerodynamics. I have very strong opinions on it, to be sure, but in a brainstorm session on how to implement aerodynamics in the game, this statement adds nothing.

What? Maybe try mechjeb with RemoteTech and you might understand what's going on, unless you want me to explain all the core mechanics of both the mods or something. Can you like, just ask a question instead of making statements and assuming I know what the question you're asking is? 

[Guest]

10 minutes ago, mcwaffles2003 said:

If you want to use mechjeb to land I would say you should have to pick a place where the hazards you mentioned don't pose much of a problem, for avoiding those types of hazards conditional statements in a VPL should make automatic avoidance of obstacles like that feasible.

Basically use mechjeb or write "probe.justUseMechJeb()" into the programming interface.

No thanks, I have nothing against mechjeb, but I don't like forcing everyone to use it and masking it as a "realism" or "difficulty option".

 

You can have Mechjeb, the VPL, a text-based scripting language and some new gameplay loop to make Kerbals more useful even without signal delay, for people automating everything (either with mechjeb or by programming everything) can do so anyway and people loving manually flying their crafts don't lose half of the game.

Edited September 10, 2020 by Master39

[mcwaffles2003]

23 minutes ago, Master39 said:

Basically use mechjeb or write "probe.justUseMechJeb()" into the programming interface.

No thanks, I have nothing against mechjeb, but I don't like forcing everyone to use it and masking it as a "realism" or "difficulty option".

 

You can have Mechjeb, the VPL, a text-based scripting language and some new gameplay loop to make Kerbals more useful even without signal delay, for people automating everything (either with mechjeb or by programming everything) can do so anyway and people loving manually flying their crafts don't lose half of the game.

What if we still had Commnet as optional, as it is, and circumvent your discomfort with the whole scenario?

I just feel probes, as they are in the game now, are way OP, you get the reaction time and all the benefits of a 5 star pilot with no drawbacks and less dry mass. I just feel adding signal delay to the game could add for some rewarding challenges to work around.

Edited September 10, 2020 by mcwaffles2003

[Guest]

27 minutes ago, mcwaffles2003 said:

What if we still had Commnet as optional, as it is, and circumvent your discomfort with the whole scenario?

I just feel probes, as they are in the game now, are way OP and I feel adding signal delay to the game could add for some rewarding challenges to work around.

I don't think going for signal delay would be a good game design choice at all, even as an option, it's not different for me than having the game default to RSS.

The problem is not the probes being OP, it's the Kerbals being useles, and you solve that problem by making them useful, not by making probes equally useles. 

Adding signal delay (which basically is just an excuse to effectively forcing automation on the players) would just kill the use of probes as an exploration tool, it kills so many uses for probes that it's not worth it from any perspective.

 

This proposal turns every skill about flying a craft in KSP either an automated Mechjeb function or something you can't do if you're not good enough as a programmer. 

Edited September 10, 2020 by Master39

[mcwaffles2003]

Just now, Master39 said:

I don't think going for signal delay would be a good game design choice at all, even as an option, it's not different for me than having the game default to RSS.

There is a world of difference between adding signal delay and RSS

1 minute ago, Master39 said:

The problem is not the probes being OP, it's the Kerbals being useles, and you solve that problem by making them useful, not by making probes equally useles. 

All I can say is I disagree. I think we should find more uses for kerbals, but I still think probes are overpowered.

2 minutes ago, Master39 said:

Adding signal delay (which basically is just an excuse to effectively forcing automation on the players) would just kill the use of probes as an exploration tool, it kills so many uses for probes that it's not worth it from any perspective.

This proposal turns every skill about flying a craft in KSP either an automated Mechjeb function or something you can't do if you're not a good enough programmer. 

Or you can just do what you would have done with the probe... with a kerbal (it's almost like they would be useful)

[Guest]

30 minutes ago, mcwaffles2003 said:

There is a world of difference between adding signal delay and RSS

I'm comparing the two as "bad game design choices", in my view they are both equally respectable mods that are equally bad as a default stock feature.

30 minutes ago, mcwaffles2003 said:

I still think probes are overpowered.

Overpowered how? Compared to what? Kerbals in KSP1 are useles, everythign is overpowered compared to "useless" and science becomes irrelevant in the game before any signal delay can come into play,  where signal delay is relevant any use for a probe would be roleplay anyway and science parts cosmetic.

 

30 minutes ago, mcwaffles2003 said:

Or you can just do what you would have done with the probe... with a kerbal (it's almost like they would be useful)

"what you do with a probe" is roleplay or cosmetic anyway, so no, putting a saddle and a Kerbal with a cowboy hat on my Perseverance replica is not an option since "sending a probe" is the only possible goal of that mission.

 

Any experience we have is deformed by how KSP1 works: any use for both Kerbals and Probes finish before ever going inteplanetary and even the best mods just add more science points/money requirements without ever touching the balance between Kerbals and probes if not by making Kerbals even more useles by adding Life support.

The easiest way out is scrapping KSP1 science and career systems and write something new from the ground up. There's nothing to salvage in how KSP1 progression works.

 

Edited September 10, 2020 by Master39

[swjr-swis]

37 minutes ago, mcwaffles2003 said:

I just feel probes ,MechJeb, as they are it is in the game mod now, are is way OP, you get the reaction time and all the benefits of a 5 star pilot plus a crapton of additional functionality that neither pilots nor cores have with no drawbacks and less dry mass.

I just fixed the above for you. What you keep proposing as the solution creates an even worse version of what you yourself claim you wish to change.

I'm out, before this becomes more than a mere irritation. I feel like we've monopolized and polluted @catloaf's thread enough already. My apologies.

 

[mcwaffles2003]

50 minutes ago, swjr-swis said:

I just fixed the above for you. What you keep proposing as the solution creates an even worse version of what you yourself claim you wish to change.

Dude, you said yourself you've barely even ever used it but whatever. Also, way to tell me I'm not responding to your questions then dismiss me trying to address them to crap on my opinion while priorly admitting you are uninformed on the subject. Pretty evident you're just looking to argue, have fun with that.

1 hour ago, Master39 said:

Overpowered how? Compared to what? Kerbals in KSP1 are useles, everythign is overpowered compared to "useless" and science becomes irrelevant in the game before any signal delay can come into play,  where signal delay is relevant any use for a probe would be roleplay anyway and science parts cosmetic.

 

"what you do with a probe" is roleplay or cosmetic anyway, so no, putting a saddle and a Kerbal with a cowboy hat on my Perseverance replica is not an option since "sending a probe" is the only possible goal of that mission.

So you dismissed my stance as roleplay then validated your reasons because of roleplay... cool...

1 hour ago, Master39 said:

Any experience we have is deformed by how KSP1 works: any use for both Kerbals and Probes finish before ever going inteplanetary and even the best mods just add more science points/money requirements without ever touching the balance between Kerbals and probes if not by making Kerbals even more useles by adding Life support.

I disagree

[Guest]

19 minutes ago, mcwaffles2003 said:

So you dismissed my stance as roleplay then validated your reasons because of roleplay... cool...

 Wait. I think we're starting from very different premises and since you're not volunteering what you mean by "overpowered" here's were I start from:

When I say that probes are "overpowered" compared to Kerbals I mean they're overpowered in science return / cost, the only measurable way of evaluation we have for KSP1.

I don't think at all they're overpowered because they should be inherently less controllable than a craft piloted by a pilot kerbal, space flight is mostly automated anyway.

I'm also convinced that the core gameplay loop of KSP is "Design, build and Fly [cool rockets]", then you can build a lot of other gameplay loops on top of this core, but I don't think anything should ever get in the way of that and losing the ability of directly flying a big portion or my builds is a big disruption of that core concept.

That's were I start from, that's why I said that outside of Kerbin's SOI every mission of KSP1 is pure roleplaying, you've already finished all the missions that have a measurable impact on the only quantifiable game objective: unlocking the tech tree.

Now I'll make the question again, what do you mean by "overpowered"?

Because if you mean that probes science/return cost compared to Kerbals is too high I agree with you, but I think that signal delay would come into play too late for KSP1's gameplay and that KSP2 should have a completely different progression system and a lot more to do for Kerbals.

On the other hand if you mean that a probe should have inherently less direct control than a pilot, regardless of the science it generates, that's what I think is "realism for the realism's sake".

[catloaf]

Why not just have signal delay be a difficulty setting like comnet? That way people can have their manual flying instant probe cores and others can have their scripted probe cores. Plus, I think many are underestimating tools like vizzy in SR2, which look pretty simple and powerful to me. If you combine that with the simulation idea you could get a fun and accessible scripting system. I believe that vizzy is currently easily capable of non atmospheric flight, but atmospheric flight is many times more complicated, but perhaps could be assisted by commands that could manipulate smart A.S.S. and large automated functions like killVelocity() and point towards. For example, a dragonfly like landing script could look something like this:

var targetLat = null
var targetLong = null

function getTargetPosition () {
   targetLat = prompt ("enter latitude for target")
   targetLong = prompt ("enter longitude for target")
}

function flyToTarget () {
   getTargetPosition()
   control.Throttle(60)
   control.setPitch(90)
   control.setYaw(0)
   control.setRoll(0)
   time.Sleep(1000)
   pointTowards(targetLat, targetLong, false, false, true)

   while (currentAltitudeASL <= 3000) {
      if (currentAltitudeASL <= 3000) {
          control.Throttle(40)
      }
   }
   control.setPitch(100)

   var currentPosition = null
   while (currentLat !== targetLat) {
      if (currentLat === targetLat) {
         killVelocity()
      }
   }
   
   control.Throttle(30)
   
   while (currentAltitudeAGL > 300) {
      if (currentAltitudeAGL < 300) {
         control.Throttle(60) 
         if (velocity < 4) {
            control.Throttle(39)
        }
        if (touchingGround === true){
           control.Throttle(0)
        }
   }
}

flyToTarget()

As you can see, that short script rely's on many functions and variables that would be built in to the scripting thingy such as currentAltitudeAGL and control.Throttle, it also has other useful functions like time.Sleep. to make code easier for everybody. In addition you could get download libraries and put them in your script, allowing even more functions made by the talented community. There would also be a block code based option that would basically be pretty similar to vizzy. There is a flaw in this script which is that it would only work with rocket engines, not propellers, but it gets the point across that this would be a useful feature, rather or not the user chooses to enable comm delay or not.

Edited September 10, 2020 by catloaf

[Incarnation of Chaos]

Signal Delay really should be left for mods, and i really, really don't want to get into the whole "Realism" debate over it.

KSP2 is still using scaled planets, scaled distances, and timewarp. So Signal Delay just becomes an annoyance rather than enhanced realism/drawback, and the whole "Why not just use a kerbal instead" thing really bothers me.

There's plenty of applications where i cannot "Just use a kerbal" if i need instant control without significantly changing my design and bolting on a wack ton more dry mass. My 3-piece interplanetary mothership? Yeah i can't really "Just use a kerbal" to control the sections containing the engines and labs, nor can i really "Just use a kerbal" if i want to refuel it with an automated lander while my dudes are doing science on Duna. I don't want to write scripts to control all of this stuff because quite frankly.....there's really no need to. I want to make a flexible, multipurpose craft that i can decide to use for one-off missions should i choose.

Not have to write page after page of useless, bespoke "Code" that doesn't even teach me programming because it's some garbled mess of other languages and custom API calls that the developers dared called their own. Or use a visual scripting language that while making it more accessible to beginners; doesn't do anything but get in my way.

Mods that try to implement actually realistic things can implement Signal Delay, and that's for the best.

 

 

[Guest]

2 hours ago, catloaf said:

Why not just have signal delay be a difficulty setting like comnet?

"Build cool rocket => fly cool rocket" that's the core identity of KSP to me, everything else has to be build on top of this and not in its way or is a big nono for me. Signal delay would be a huge obstacle since it's basically a way to kill most of the "flying" part out of the Kerbin's SOI.

I would welcome signal delay the same way I would welcome a default stock RSS, as a red flag that tells me that after all the devs don't understand KSP that well.

 

3 hours ago, catloaf said:

others can have their scripted probe cores.

That could happen even without signal delay.

 

3 hours ago, catloaf said:

Plus, I think many are underestimating tools like vizzy in SR2, which look pretty simple and powerful to me. If you combine that with the simulation idea you could get a fun and accessible scripting system.

I don't think I mis-understand how powerful a VPL can be, especially since I proposed it 3 whole months before Vizzy was even announced, in the last signal delay topic.

I want an in-game programming language, I want some automation and autopilot features (especially for planes, I want my altitude and heading hold autopilot, we're not in the '40), I know how powerful they can be but I want to use them to automate the chores, when I think that the challenge of automating that part of the flight is more fun than flying manually (reentry sequences, especially for Eve) but I don't want to be deprived of the fun of directly flying my probes and crafts manually.  

[Bej Kerman]

On 9/9/2020 at 12:06 PM, mcwaffles2003 said:

On 9/9/2020 at 11:46 AM, Master39 said:

Isn't signal delay a bit extreme to start with? You're basically killing flying any probe manually outside Kerbin's SOI.

If we're going for extreme realism to have extreme difficulty you need kOS, otherwhise it's just "realism for the sake of realism" and it's quite pointless to have such an extreme feature just to have as an outcome to have to be a spectator instead of a player.

 

I disagree, you shouldn't be forced to learn programming to play a game though it would be awesome if that was available as well. Also, it wouldn't be realism for the sake of realism, it would make using kerbals actually have a real benefit, it would add balance. If you want that kind of real-time control, send a pilot.

The general consensus is that your inputs in game are just preprogrammed inputs in lore. KSP sacrifices many real world phenomena for the sake of gameplay and signal delay is one of those things, and there's an explanation for why there's no delay. There's no need for delay, nada, unless challenge for you is having an autopilot have to do everything for you.

[mcwaffles2003]

7 hours ago, Master39 said:

 Wait. I think we're starting from very different premises and since you're not volunteering what you mean by "overpowered" here's were I start from:

7 hours ago, Master39 said:

Now I'll make the question again, what do you mean by "overpowered"?

Because if you mean that probes science/return cost compared to Kerbals is too high I agree with you, but I think that signal delay would come into play too late for KSP1's gameplay and that KSP2 should have a completely different progression system and a lot more to do for Kerbals.

On the other hand if you mean that a probe should have inherently less direct control than a pilot, regardless of the science it generates, that's what I think is "realism for the realism's sake".

10 hours ago, mcwaffles2003 said:

I just feel probes, as they are in the game now, are way OP, you get the reaction time and all the benefits of a 5 star pilot with no drawbacks and less dry mass.

I've already blatantly answered this... and let me be clear, I dont care for realism for the sake of realism. I just find it fun to have that delay, to have to predict and plan my encounters in advance. From a gameplay perspective, this also seems more balanced to me and like a fair trade off. I understand that you don't agree, and that's fine, you are welcome to your perspective, so please allow me to have mine.

 

 

Edited September 10, 2020 by mcwaffles2003

[HansAcker]

9 hours ago, catloaf said:

There is a flaw in this script

Is it the "while (X) { if (!X) { unreachableCall() } }"?

I spend too much time in the VAB mulling over security and redundancy constraints that no gameplay will ever need, so maybe I don't have a much qualified opinion on this I think that "stock" should not require a player to have planned ahead much in any situation and that improvising your way out of an unplanned situation and still complete a mission is an important part of KSP for me.

By the way, doesn't KSP's Mission Builder already implement much of the "visual programming" for mission plans? Combine it with an autopilot that can launch and execute maneuver nodes as they come up.

 

Getting to orbit is half the game, everything after that is bonus play

Edited September 11, 2020 by HansAcker

[probe137]

I have a few questions, and they are about the appearance of the new probe cores. 1. What will be the cross-section profile of the HECSIII? 2. What will be the 'shape' of the DODEC series? 3. What will be the cross section profiles of the DODEC and DODECII respectively?