intelliCom

Procedural Radiators actually wasn't known until it was said. Procedural wings on the other hand were introduced. We've only just recently gotten confirmation that manuevers can be executed during timewarp. It just feels like you're willingly ignoring everything genuinely new to support the argument that "they're not posting anything new", except they have been. And besides, you can just ignore KSP2 for a while and do something else, right? Try and make an Eve SSTO? Practice gravity assists? Maybe get better at KSP1 so you can jump into KSP2 with a large body of experience when it releases?

What was the budget for the original KSP?

Are there other types of powered descent besides the suicide burn? With their own special properties and whatnot?

Lmao. Point is that most suicide burns to date have been automated ones, with the only major manual ones having been done decades ago. Any other manual suicide burn was in a training sim or in KSP1 itself.

Assuming that automation is the only option here. Since we've established that automation is optional, this argument doesn't hold up. I might be recalling my history incorrectly, but Neil had to manually peform the suicide burn because the computer was having problems. Maybe all of them were manual?

Absolutely agreed. Also, automating suicide burns like on the Falcon 9. iirc, the last time a suicide burn was done manually in a non-training scenario was Neil Armstrong with Apollo 11.

I once made an argument in favour of scripting like this trying to present the "why". In retrospect, I really should've said that I'm fine with it being optional, with probes allowing real time control. In terms of "whys", I thought it'd be nice to provide the option for players to automate their rovers and space probes this way, same as how all the space probes in history have done due to signal latency.

nice picture edit: it fixed itself, it's a link to a deleted post of the exact same thing. what?

DLC is definitely going to be used for more star systems, hopefully more engines (MOAR BOOSTERS!!!!!!) that just start reaching ludicruous sizes. Size of a damn Mun crater kinda stuff. Could fit the VAB under one of them kinda stuff. Real Daedalus material man.

Of course, everyone wants at least 2 extra star systems besides Kerbol, but how many do you guys think we'll actually get? I estimate around 4, maybe.

I'm not trying to say that use of an actual fully-fledged programming language is what's best. I genuinely just mean absolutely basic programming like Scratch does. Clicking and dragging blocks. Absolutely basic kiddy stuff that could still allow for accessible automated probes. Unless you're looking to feed new programming into the probe core, but speed-of-light delay for real-time inputs would be a good incentive to 'program' probe cores to do things on the player's behalf when the inputs won't get there in time. Which is what I was trying to say. It's like Scratch. Not actual typing of code, but pre-made blocks to tack onto each other. Before I got into learning javascript and php, I used Scratch to learn how coding works. Considering how KSP is all about giving players complex concepts in a simpler form, Scratch-like programming would be perfect. Scratch - Imagine, Program, Share (mit.edu) Scratch. For the third time in this reply, Scratch. Anyone can write functioning code in Scratch. The learning curve is literally a plateau that's about 10% the height of the entire graph. I'm not literally saying that Scratch itself should be used for probe cores, but definitely something similar. For players who already have a moderate to advanced knowledge of programming, the blocks could be converted to a text format like conventional programming languages are. I don't want autopilots everywhere because that defeats part of the fun of KSP. However, it should be mandatory in cases where a Kerbal isn't operating anything directly, and where inputs would be delayed due to the speed of light. Perhaps to combat the problem of probe cores replacing everything, each probe core should have a limit for how much code they can store. Really simple ones like the Stay-putnik could only manage 3 blocks. Potentially just the following: "If" condition block (e.g., vertical speed < 0) execute block (e.g., SAS = retrograde) "else" execute block (e.g., return) This alone would introduce the player to a very basic situation to use programming in; a probe automatically aiming its heatshield retrograde, even during plasma blackout without user input.

At least bigger than the VAB, as Tom Vinitas said in the start of the video. Thank you for coming to my Ted Talk.

You're talking abou the Final Frontier mod.

Might've missed the latest KSP 2 video. They're wanting to put in Brachistone trajectories. That being said, KSP1 is the best training you can get for learning how to play KSP2. Don't worry if you don't master KSP1, KSP2 will offer really good tutorials for teaching people who are completely new to the game.

Don't claim that the majority's on your side if they might not be. Especially if you're going to ignore the good use cases for probe automation that I already mentioned twice now. This is going down the right idea, but it's starting to overcomplicate probe automation. I was more thinking about small things like if you put a barometer onboard, and it read some air pressure, the probe would assume the worst and prepare for an aerobrake. Perhaps you could put in all the maths for a suicide burn and let the probe core do it? I feel as though a lot of these problems could easily be done by a KAL-1000 that has if-else conditions. And, not making 5 different KAL-1000s that do different things, but just one unified KAL with individual actions by individual conditions being met.

Do the vessel designs look the same?

Because I was trying to explain how even attempting to try and make moving planets "realistic" would run into so many problems that suddenly make it less realistic all over again. I'm trying to stay with the post's topic here. Yes, there's mods for it. Yes, "moving planets" can work. But "moving planets" suddenly introduces a bunch of extra issues in realism that make it not worth it to begin with, as per OP's motivation for a more realistic physics engine. This is why I compared such a feat to "Unreal Engine 15". Because trying to make such physics "realistic" would put such an unbelievable amount of strain on a computer that it's not even practical for a scientific simulation. It's not processing moving planets on its own that's intensive. It's making that "realistic."

Why not ask them yourself? Not cherry picking pilot-nuts, but just average KSP fans. Would they like an easy, basic programming system along the lines of the KAL 1000 but with a conditional 'if-else' feature? Prove that people really want probe cores to be a boring alternative to Kerbals, instead of probe cores being good and fun for some things and kerbals good and fun for others. Also, I notice you didn't provide a counter-point for rover automation. You also ignored suicide burn automation. Care to explain that, or should we sweep that under the rug?

Either: You ignore the effects of such a close pass, so it's no longer "realistic", as is the point of this post, or; You include the effects of such a close pass, so your computer reaches the heat of a nuclear reactor. Just leave the planets on rails, moving them isn't important or within KSP2's idea of "rational situations". Stop insisting the planets need to move.

Oh that's what's being referred to. Oh yeah, except there's still the whole sequence of getting back home and splashing down. Either the last video is of the mun landing, or the mun landing's only halfway.

Programming's more fun than you think. Making the experience of controlling probe cores into just "same as a kerbal in a command pod but there's no kerbal" isn't fun. Besides, programming probes could also allow for proper automated rovers like literally every Mars rover ever without keeping the rover loaded in at all times. Relying on user input to get the rover from A to B is much more annoying than automating that stuff. Even worse when you have to deal with communications blackout, but since you said that should be removed anyway, you're basically saying that the tracking station serves absolutely no use to probes but science transmission. In other words, "same as a kerbal in a command pod but there's no kerbal". The only good use for probe cores at this point is minaturisation. Anything larger than an external command seat is useless, and uninteresting.

The moon causes significant tides, and you're telling me that if an Earth-sized planet were to pass closer to Earth than the moon is, just barely skimming the atmosphere, that tidal forces don't mean anything in that situation?

[snip] Space probes have to be able to do this all the time. Cassini and Juno need to do it when they end up behind their respective planets. It's called a communciations blackout. And, as I said, really basic Scratch-like stuff. Basically telling the probe to immediately aim its heat shield retrograde if it detects atmospheric pressure, or to program a suicide burn like Falcon 9 boosters do. Basically giving a KSP-ified experience of software engineers preparing their probes for every potential scenario.

1. I didn't mean to imply that, Unity's great, but I have this idea that OP thinks of realistic as being "cool" like Unreal Engine's uber-realistic graphics nowadays, instead of "cool" like "oh hey I can actually make an aircraft that functions as it would in reality" 2. But the actual tidal forces of such an event would have to be completely ignored in order to function on the computers of today. Hardly "realistic", is it?

So you propose that probe cores should be reworked? Honestly, I agree with you on that one. Doesn't make sense that the player should be able to tell the probe core what to do even when no inputs should be available. I just hope they add some sort of really basic Scratch-like programming system for KSP 2's probe cores.