Jump to content

Please Add Realistic Aerodynamics (FAR) and Perhaps Procedural Nozzles for Optimizing at Different Pressures


Recommended Posts

@mcwaffles2003 @Bej Kerman

7 hours ago, mcwaffles2003 said:

How does asking for multiple stock aerodynamic models not seem insane to you? Genuinely curious.

What do you mean?

  • It's not impossible: Multiple other games have done it. (War Thunder, Flight Simulator series. IL-2 series. Ace Combat series. Just to name a few. --- It is so doable in fact that even the games that don't have it natively usually receive it in the form of mods. You might have heard of one called Ferram Aerospace Research [FAR] for KSP1 ;))
  • It's not overkill: Again, multiple other games have done it; usually in the form of different game modes or difficulty settings; to satisfy both arcade and more realism-centered audiences.
  • It's not "asking too much of the devs": Whether they accept the suggestion is entirely up to them. Specially in my specific suggestion, where they can launch the game with a base model first, and only worry (if at all) about the work on the secondary model post-launch, taking as much time as they may need.

In my honest opinion, it is your view that seems insane. If there is only one model, it can only be:

  • Arcade, displeasing the majority of the realism crowd.
  • Realistic, displeasing the majority of the arcade crowd.
  • Or a mix of both,  displeasing a majority of both crowds.

On the other hand, having both models would please the majority in both crowds, because they could then literally just choose; and even for any displeased minority, it would possibly/probably make the aero model integration modular enough that even anyone displeased could just implement their own model *with proper integration*. --- Meanwhile, for the negative aspects, they come down to if the devs don't agree that it would be a worthwhile endeavor for the dev team, they can just say "no".

8 hours ago, mcwaffles2003 said:

That would make craft sharing hilarious... "Try my plane! It flys like a dream in model A but in model B it flys like a lawn dart"

Isn't this the exact same situation we already have, in between KSP1 crafts created for vanilla VS crafts created for FAR? I don't think people have a big problem with sharing crafts created with or without FAR, right now. What would be the problem, exactly? People right now just communicate that the crafts are created with A or B model in mind; and I don't see any huge misunderstanding or confusion. Why do you think it would be any different if different flight models came as a boolean toggle on a menu, and not as a "install toggle" on CKAN?

8 hours ago, mcwaffles2003 said:

how crazy would something like this sound to someone discovering KSP

The same level of "crazyness" in talking about FAR to someone discovering KSP. -> None at all.

8 hours ago, mcwaffles2003 said:

Not to mention you would have to balance each part for both models

... Like FAR does on KSP1?

I mean, seriously, what are you ranting on about? We have the example of this in already practice through KSP1 and FAR. The only real differences would be in manner of integration and activation.
If FAR can do it as a mod, then if anything, it would be easier for the official dev team to implement something similar in an integrated manner.

8 hours ago, mcwaffles2003 said:

There's a MOBA I used to play called vainglory

Shocking news: KSP is not a PVP game, and an analogy about PVP balancing issues on a PVP game do not at all apply to KSP.
What are you on about? :/

Are you trying to imply some problem with KSP2 having multiplayer? The solution is not only (relatively) easy, it's obvious: For MP, the model becomes a server setting; everyone in that server uses the aero model the server is set to use. --- This is literally the same thing that has already been solved in multiple other games that I mentioned. It's not a big issue, and certainly not rocket science. :P

And again, this is something we have in practice with KSP1, FAR and Luna MP, right now. There are LunaMP servers requiring specific mods, including FAR.

8 hours ago, mcwaffles2003 said:

You might as well just make 2 similar but separate games

Again, FAR exists, in practice, right now. I'm pretty sure FAR did not need to convert KSP1 into an entirely new game. While aero models are no simple task to implement; they are definitely simpler to implement than a full physics-based game. So with all due respect, I'm pretty sure you are WAY overestimating the challenges of integrating multiple aero models into a single game. It's busy work, sure; but it's not such a 7-headed monster as you seem to think. FAR was initially done by a single person. It's in the name of the mod. And it was done as a mod; with no access to the game's source-code; and certainly not access to core integration; and yet it still was done, and pretty much works fine. I am plenty sure a team of multiple developers, with access to the actual base code and integration, can figure it out. :P

Link to comment
Share on other sites

38 minutes ago, AlmightyR said:

People right now just communicate that the crafts are created with A or B model in mind

The entire point of getting physics right in the first place is to minimize the hassle of sharing craft between difficulty settings and entire versions.

Link to comment
Share on other sites

7 minutes ago, TLTay said:

Have the devs made any statements about the KSP2 aero/reentry model yet?

Yes, it was confirmed a very long time ago that far style aero isn't coming. So I have no idea what this debate is about.

We're getting the hilariously silly drag cube based one for stock and then anything else will be modded in 

Link to comment
Share on other sites

4 minutes ago, Incarnation of Chaos said:

Yes, it was confirmed a very long time ago that far style aero isn't coming. So I have no idea what this debate is about.

We're getting the hilariously silly drag cube based one for stock and then anything else will be modded in 

Hopefully FAR can be modded in quickly. I'm hesitant to start a career save without it.

Link to comment
Share on other sites

1 hour ago, AlmightyR said:

@mcwaffles2003 @Bej Kerman

What do you mean?

  • It's not impossible: Multiple other games have done it. (War Thunder, Flight Simulator series. IL-2 series. Ace 

As someone who has also played these games, you're misrepresenting what's going on with them here big time.

WT doesn't have 3 different flight models for arcade, realistic and simulator (if they did it would solve so many complaints from the community)

They have the same flight models, and adjust the parameters for the planes accordingly. Similar to KSPs fudge factor for lift.

IL2? Just has toggles for resources and damage, if you flame out? You still gotta wait for the compressor to spool up.

Ace combat? Arcade all the way.

2 minutes ago, TLTay said:

Hopefully FAR can be modded in quickly. I'm hesitant to start a career save without it.

I think it's more will than work, the skill set to do it isn't common and upkeep between updates is a job with less gratitude than working at McDonald's.

Link to comment
Share on other sites

Hmmm,  ultimately I will settle for whatever stock aero model gets implemented.  It's more about the space flight aspect for me, but yes a realistic feeling aero model would be welcome, whether or not it is FAR or similar being the stock choice.

Toggles or sliders for difficulty would be ok, but two DIFFERENT models in stock is just asking for stuff to go wrong IMHO.  

Edited by pandaman
Link to comment
Share on other sites

6 hours ago, Bej Kerman said:

FAR shouldn't be as difficult to implement as it was with KSP 1. Intercept is building the game from the ground up and there should not be nearly as much problems as there were with fitting FAR into KSP 1. Intercept has all the money they'll need and an entire blank slate - it should be easy for them when it was possible for a single guy with no extra income to fit FAR into a game it wasn't built for.

Sir, you are defeating your own position.

FAR is already an example of an effectively a separate, secondary, and optional aero model for KSP1. It's existence on KSP1, with no major problems across multiple game updates, parts mods, craft sharing, etc, disproves most if not all your concerns about multiple aero models on KSP2. And as you accidentally indirectly argue, implementation of a secondary model by the official dev team, in the official game, would be both easier and better that it was done by FAR on KSP1. :wink:

6 hours ago, Bej Kerman said:

I just simply don't get why having FAR from day one would end up with KSP 2 being rushed

Well, one portion of the KSP fanbase plays stock aero, and another plays with FAR. If there is only one model in KSP2, one of those crowds will get what they want, and the other will get nothing. So, on a one-model view, a critical, golden question needs to happen: Who gets the cookie, and who goes home disappointed and empty-handed?

(Meanwhile, on a multiple-models approach, this is not a problem, as both sides eventually get what they want. Which is why I think we can agree that having both is better than having one.)

While the game probably can't be released with no aero model; requiring multiple aero models at launch actually is probably overkill, since the second model would be a great addition, but is not strictly necessary for the game to be playable.

So assuming the devs don't go the overkill route: That means that, at KSP2 launch (if not forever), either the more casual, arcade-like people will get what they want, or the more realism-centered, FAR-like users will get what they want. But with a single model, overall or at launch, both cannot be true at the same time, and one side will go without a cookie (in my two-model suggestion, temporarily; and in your one-model, permanently).

Well, then the next step from that is to decide which model should be implemented (first)? Again, "Who gets the cookie?" Unless we want to be egocentric, then we can't judge which option is "better" by our own preference, and need to judge based on other factors common to everyone. In that case, here are some I considered:

  • Which of the models is closer to the one on stock KSP1 (KSP2 is kind of a sequel, after all)? That's the arcade.
  • Which of the models is less complex, and, given the same development time, would be more polished (less bugs, less imbalances, etc), at launch? That's the arcade.
  • Which of the models is easier to learn for new users (which I'm assuming KSP2 will get a lot of)? That's the arcade.

... And so on.

So I can only see anyone wanting just one model ever,  and it being the model you prefer, that will take longer to implement to the same degree of polish, and it being the one at launch, contrary to the "tradition" from the original (KSP1), contrary to what would IMO be best for new users, and at the cost of the dissatisfaction of the entire arcade-like-preference side of the fanbase, as a desire for a rush for a suboptimal solution, just so they'll be getting what they want first, at the cost of others.

7 hours ago, Bej Kerman said:

evolving physics engine breaking rockets

Was already argued and already debunked multiple times, as FAR as I'm concerned; and I won't repeat myself.

7 hours ago, Bej Kerman said:

updates obsoleting stuff

8 hours ago, Bej Kerman said:

a lot if things weren't breaking and physics wasn't shifting between updates.

It's in the nature of updates to update stuff (it's in the name!). It's in the nature of what an update is to cause the stuff being updated to become obsolete (it's in the definition!). --- Unless you expect KSP2 to never get updated post-launch, which is frankly a ridiculous expectation, then stuff getting obsolete and breaking between updates is something that will happen anyway, and so you are arguing nonsense. :)

7 hours ago, Bej Kerman said:

we could delay KSP 2 a few months

Or we could plan on two integrated aero models; delay the least-like-the-original, more complex to learn for new players, and more complex to implement, of the two aero models to a post-launch implementation; and  avoid the problem entirely while getting more people happy.

Link to comment
Share on other sites

55 minutes ago, Incarnation of Chaos said:

Yes, it was confirmed a very long time ago that far style aero isn't coming.

I heard similar, but only something along the lines of "want KSP1 players to have a familiar experience"

 Desire for a "familiar experience" does hint that the higher lift and drag at low speeds could be kept, but when I asked about that (thread link) people seemed to like that  particular choice of KSP1 -- it allows building SSTOs that can land a an easier speed.  That is also a change in parameters so is easy to mod away.

I've been playing a lot with FAR lately, and myself I like the treatment of the craft as a whole for figuring drag (no individual-part drag cubes).  I do not like the very sharp stall with the tendency of wings to tuck down upon stall (I have not yet succeeded in a snap roll) and in FAR that aspect is not changeable by configuration files.  Wing interactions in FAR have some discrete jumps when you move wings just a little, so you have to test a lot to confirm that FAR implemented what you intended.

I don't know if the KSP2 developers confirmed anything that puts them down the path to the drag cube model of KSP1, but I'll accept it if you have.

Edited by OHara
de-typo
Link to comment
Share on other sites

2 minutes ago, AlmightyR said:

Sir, you are defeating your own position.

FAR is already an example of an effectively a separate, secondary, and optional aero model for KSP1. It's existence on KSP1, with no major problems across multiple game updates, parts mods, craft sharing, etc, disproves most if not all your concerns about multiple aero models on KSP2. And as you accidentally indirectly argue, implementation of a secondary model by the official dev team, in the official game, would be both easier and better that it was done by FAR on KSP1. :wink:

Well, one portion of the KSP fanbase plays stock aero, and another plays with FAR. If there is only one model in KSP2, one of those crowds will get what they want, and the other will get nothing. So, on a one-model view, a critical, golden question needs to happen: Who gets the cookie, and who goes home disappointed and empty-handed?

(Meanwhile, on a multiple-models approach, this is not a problem, as both sides eventually get what they want. Which is why I think we can agree that having both is better than having one.)

While the game probably can't be released with no aero model; requiring multiple aero models at launch actually is probably overkill, since the second model would be a great addition, but is not strictly necessary for the game to be playable.

So assuming the devs don't go the overkill route: That means that, at KSP2 launch (if not forever), either the more casual, arcade-like people will get what they want, or the more realism-centered, FAR-like users will get what they want. But with a single model, overall or at launch, both cannot be true at the same time, and one side will go without a cookie (in my two-model suggestion, temporarily; and in your one-model, permanently).

Well, then the next step from that is to decide which model should be implemented (first)? Again, "Who gets the cookie?" Unless we want to be egocentric, then we can't judge which option is "better" by our own preference, and need to judge based on other factors common to everyone. In that case, here are some I considered:

  • Which of the models is closer to the one on stock KSP1 (KSP2 is kind of a sequel, after all)? That's the arcade.
  • Which of the models is less complex, and, given the same development time, would be more polished (less bugs, less imbalances, etc), at launch? That's the arcade.
  • Which of the models is easier to learn for new users (which I'm assuming KSP2 will get a lot of)? That's the arcade.

... And so on.

So I can only see anyone wanting just one model ever,  and it being the model you prefer, that will take longer to implement to the same degree of polish, and it being the one at launch, contrary to the "tradition" from the original (KSP1), contrary to what would IMO be best for new users, and at the cost of the dissatisfaction of the entire arcade-like-preference side of the fanbase, as a desire for a rush for a suboptimal solution, just so they'll be getting what they want first, at the cost of others.

Was already argued and already debunked multiple times, as FAR as I'm concerned; and I won't repeat myself.

It's in the nature of updates to update stuff (it's in the name!). It's in the nature of what an update is to cause the stuff being updated to become obsolete (it's in the definition!). --- Unless you expect KSP2 to never get updated post-launch, which is frankly a ridiculous expectation, then stuff getting obsolete and breaking between updates is something that will happen anyway, and so you are arguing nonsense. :)

Or we could plan on two integrated aero models; delay the least-like-the-original, more complex to learn for new players, and more complex to implement, of the two aero models to a post-launch implementation; and  avoid the problem entirely while getting more people happy.

Or we just take advantage of the fact that these equations don't care if they are fed realistic numbers and use the same model with different parameters like all of your examples do.

Slider settings can be displayed on shared craft, and only using the one model prevents issues like wings suddenly not generating lift.

Everyone is happy, two models aren't needed. Just a couple additional functions and getters and setters, so time for coding is limited.

Link to comment
Share on other sites

14 minutes ago, AlmightyR said:

Sir, you are defeating your own position.

FAR is already an example of an effectively a separate, secondary, and optional aero model for KSP1. It's existence on KSP1, with no major problems across multiple game updates, parts mods, craft sharing, etc, disproves most if not all your concerns about multiple aero models on KSP2. And as you accidentally indirectly argue, implementation of a secondary model by the official dev team, in the official game, would be both easier and better that it was done by FAR on KSP1. :wink:

When I say FAR in stock, I mean a singular aero model in the base game. I never asked for two. I believe it's been made clear enough by others that a secondary model is 1. going to bloat the game, 2. spaghettify the code and 3. only make things confusing for the craft sharing community. It's one thing to have to give your modlist for a craft, it's another thing to have to give your difficulty settings. So far, these things have been trivial, like re-entry heating. But a secondary aero model is ridiculous.

17 minutes ago, AlmightyR said:

It's in the nature of updates to update stuff (it's in the name!). It's in the nature of what an update is to cause the stuff being updated to become obsolete (it's in the definition!). --- Unless you expect KSP2 to never get updated post-launch, which is frankly a ridiculous expectation, then stuff getting obsolete and breaking between updates is something that will happen anyway, and so you are arguing nonsense. :)

What I'm saying is that KSP 2 should minimise the amount of physics things that updates change. This can be done if we just stick with one aero model through many updates.

Link to comment
Share on other sites

7 minutes ago, Incarnation of Chaos said:

Or we just take advantage of the fact that these equations don't care if they are fed realistic numbers and use the same model with different parameters like all of your examples do.

Slider settings can be displayed on shared craft, and only using the one model prevents issues like wings suddenly not generating lift.

Everyone is happy, two models aren't needed. Just a couple additional functions and getters and setters, so time for coding is limited.

You argued exactly what I was going to argue back at you. The interaction is fundamentally equation-like. You can "zero" it at either side of the "=". It doesn't matter if in those games different aero behavior is achieved by changing the parameters of how the crafts react to the system, or if it's in how the system drives the interactions. They are, effectively, the same changes in result, and thus, effectively, different aero models.

If you think a part-based solution rather than a system-based one would be the best, I don't necessarily disagree with you. Two separate instances of either solution effectively creates two separate models of interaction.

I personally think a part-based solution would be worse, because it would need parameters to be created and adjusted per-part; which is a lot more variables to adjust overall than adjusting it on the system side of the equation.

Link to comment
Share on other sites

26 minutes ago, Bej Kerman said:

1. going to bloat the game

In the same way installing FAR "bloats" KSP1? The original KSP1 aero system doesn't magically disappear from the source files when you install FAR to override it in-game, you know?

Not a big problem with FAR = Not a big problem for KSP2.

26 minutes ago, Bej Kerman said:

2. spaghettify the code

  1. That depends on the devs, and is not something you can speak as truth unless you're the one making the code. Systems far more complex exist in the world of programming with very clean code.
  2. A mod integration from outside, by someone with no access to the game's source code, and done with less access, is inherently more likely to be "spaghetti" than one done by the game's dev team.
26 minutes ago, Bej Kerman said:

3. only make things confusing for the craft sharing community.

Such presumed confusion does not happen with FAR on KSP1, indicating that it would also not happen with an integrated secondary model on KSP2. You're just repeating an already debunked argument here.

26 minutes ago, Bej Kerman said:

What I'm saying is that KSP 2 should minimise the amount of physics things that updates change. This can be done if we just stick with one aero model through many updates.

"What I'm saying is that KSP 2 KSP1 and FAR, separately, should minimize the amount of physics things that their separate updates change. This can be done if we just stick with one aero model through many of the separate updates of either or both."

Not a big issue through the separate updates of either KSP1 or FAR mod = Not a big issue through the updates of KSP2 with multiple models.

Two models integrated in KSP2's core creates no extra issues compared to modding a secondary model in from the outside; quite the opposite: It solves many of the integration problems, like FAR having to be updated just to change the "compatible versions" metadata with no functional changes, just because an update to KSP1 came out.

So again, you're arguing nonsense here.

Edited by AlmightyR
Link to comment
Share on other sites

1 minute ago, AlmightyR said:

In the same way installing FAR "bloats" KSP1? The original KSP1 aero system doesn't magically disappear from the source files when you install FAR to override it in-game, you know?

Uh, no. The original aero model doesn't remain in the difficulty settings.

Let me just establish this in concrete: I believe KSP 2 should have a realistic aero model from the start and try its best to unify the physics among all clients. It should also have a good physics system from day one, one that won't need to be replaced for a while, maximising time between major versions that may involve craft breaking. Have you got this, yea? What I'm saying is: no more than one aero model in the game, don't replace physics too often like KSP 1.

4 minutes ago, AlmightyR said:

So again, you're arguing nonsense here.

lol no.

Link to comment
Share on other sites

2 minutes ago, Bej Kerman said:

doesn't remain in the difficulty settings

You're reduced to arguing about UI details. That is literally the same as arguing that the CKAN install toggle for FAR is ticked on or off.

I'll consider that an admission of having no more arguments to present against two separate models in functional terms. So we're done. :)

Link to comment
Share on other sites

On 7/13/2021 at 8:18 PM, mcwaffles2003 said:

This is not fine... but it is hilarious

But can you hear the pure joy in that kid's voice as he describes the exploit (video link) ?  You wouldn't want to take that away from the next generation of KSP2 players, would you? 

I played around a bit with this exploit, checking that it works as far back as version 1.3.   Looking at physics.cfg the cause is obvious; the heat shield ('capsule bottom') is defined as a type of wing with zero drag. Apparently the intention was to let the separate system of body-drag give drag to heat shields.  So it looks like a side-effect of the evolution and expansion of the design of KSP through the early versions.  I have not seen anyone notice this loophole between 2015 when it probably appeared with the aerodynamics overhaul of KSP 1.0, and that video from October 2020.

Honestly, if that were the only type of exploit, I would say things are 'fine' .  The frustration comes when exploits, that are less obviously exploits, appear naturally in trying to optimise craft

(And, fine or not, KSP1's aerodyamics is good enough to have a lot of fun.)

Link to comment
Share on other sites

There are two main (or at least most vocal) arguments here:

1) KSP should have FAR and only FAR from day one

2) KSP should have the regular aero model and FAR should be added later as a toggle

Can't you all see that there are perfectly valid reasons for both opinions? There's even a completely reasonable third argument:

3) KSP should have the regular aero model only, and FAR should remain a mod as it is today.

 

Guys, be passionate about your argument by all means, but recognise that each alternative is just as valid as yours. Personally, I don't like messing around installing mods and keeping them up to date, but I would love to learn more about aerodynamics, so I would be over the moon with either suggestion 1 or 2. In reality, it looks like we're probably going to get option 3, but it hasn't been released yet, so who knows?

Link to comment
Share on other sites

2 wildly different aero models supported at the same time has a pretty much 0% chance of happening.

1. Developing 2 different models costs dev time (and therefore money)

2. 2 different methods have to have all their interactions regression tested with every release (costs money)

3. 2 different methods means twice as much surface area for bugs. More bugs to fix, harder to diagnose (costs money).

Link to comment
Share on other sites

22 hours ago, OHara said:

But can you hear the pure joy in that kid's voice as he describes the exploit (video link) ?  You wouldn't want to take that away from the next generation of KSP2 players, would you? 

I played around a bit with this exploit, checking that it works as far back as version 1.3.   Looking at physics.cfg the cause is obvious; the heat shield ('capsule bottom') is defined as a type of wing with zero drag. Apparently the intention was to let the separate system of body-drag give drag to heat shields.  So it looks like a side-effect of the evolution and expansion of the design of KSP through the early versions.  I have not seen anyone notice this loophole between 2015 when it probably appeared with the aerodynamics overhaul of KSP 1.0, and that video from October 2020.

Honestly, if that were the only type of exploit, I would say things are 'fine' .  The frustration comes when exploits, that are less obviously exploits, appear naturally in trying to optimise craft

(And, fine or not, KSP1's aerodyamics is good enough to have a lot of fun.)

I personally don't care how fun an exploit is, I'd much prefer realistic aerodynamics. This, bugs being dismissed because they're fun, is a mistake I hope KSP 2 avoids. I want a solid game, not one full of bugs that are only ever 'fun' in very specific moments.

Link to comment
Share on other sites

On 7/18/2021 at 6:43 PM, OHara said:

But can you hear the pure joy in that kid's voice as he describes the exploit (video link) ?  You wouldn't want to take that away from the next generation of KSP2 players, would you? 

Who's to say there won't be other bugs to exploit? With a game whose scope is as large as KSP 2's seems it will be I would be very surprised if there weren't new exploits to be discovered.

Also, doesn't the joy come from the discovery and revelation of finding an exploit moreso than just the specific content of it? The discovery has been made and is now in the past. Also, should the game intentionally make sure kraken drives stay working as well? That said, I don't think it's a good idea to keep bugs or buggy systems intentionally unless they will be intended as features in the game.

Edited by mcwaffles2003
Link to comment
Share on other sites

On 7/18/2021 at 5:43 PM, OHara said:

But can you hear the pure joy in that kid's voice as he describes the exploit (video link) ?

Uhh, stratz is a grown ass adult lol.

 

On 7/18/2021 at 5:43 PM, OHara said:

You wouldn't want to take that away from the next generation of KSP2 players, would you? 

I played around a bit with this exploit, checking that it works as far back as version 1.3.   Looking at physics.cfg the cause is obvious; the heat shield ('capsule bottom') is defined as a type of wing with zero drag. Apparently the intention was to let the separate system of body-drag give drag to heat shields.  So it looks like a side-effect of the evolution and expansion of the design of KSP through the early versions.  I have not seen anyone notice this loophole between 2015 when it probably appeared with the aerodynamics overhaul of KSP 1.0, and that video from October 2020.

Honestly, if that were the only type of exploit, I would say things are 'fine' .  The frustration comes when exploits, that are less obviously exploits, appear naturally in trying to optimise craft

(And, fine or not, KSP1's aerodyamics is good enough to have a lot of fun.)

I actually independently discovered the heatshield glitch at about the same time stratz did.  And I also discovered some heating exploits related to the aero model, allowing entering Kerbol's atmosphere, which have since been built upon by others.  There have also been found in the last few months, glitches that allow permanent floating bases, including on Jool, based partially on the work Stratz did for his Dres bridge.

Finding all these bugs is fun and exciting.  But at the end of the day they are bugs and exploits, they need to either be removed, or replaced with functional gameplay mechanics.

New players shouldn't have to take a college course on ksp exploits to even be able to understand what a high skill ksp vet is even doing in a mission.

It's ok to have a high skill ceiling, but it needs to be based on clearly designed and laid out game mechanics, not strange arcane exploits that live only in the minds of vets and in secluded discord servers.

Edited by Lt_Duckweed
Link to comment
Share on other sites

On 7/18/2021 at 5:43 PM, OHara said:

But can you hear the pure joy in that kid's voice as he describes the exploit (video link) ?  You wouldn't want to take that away from the next generation of KSP2 players, would you? 

Yes. Yes I would.

Link to comment
Share on other sites

×
×
  • Create New...