AlmightyR

Almost zero is not zero. Even the "almost zero" part is debatable: It really depends on the community and the community pressure for it. Agreed. But that is not a problem as long as the devs expect to profit more out of implementing than they expect the cost to be. Again, community pressure for it is a big factor there. Technically true, but functionally false, IMO. Automated testing is an integrated part of development nowadays and doesn't need to be reimplemented from scratch for every release. It has a very small footprint overall, and a microscopic one between releases, to be honest. Again, technically true, but functionally false. And if you put it into perspective, since a large portion of KSP1 players use FAR, a FAR-like secondary model is pretty much guaranteed to be implemented to KSP2 through mods if it's not done by the official team, and so you're still dealing with the same problem here, because the "surface area for bugs" is equal at best, and greater at worse; as is the difficulty of diagnosis; through an external 3rd-party implementation. This is basically hot-potato'ing the problem to a different set of hands, and then claiming "not my problem". Not a realistic criticism of the idea, IMO. As @OHara already pointed out in a different way, most of the interactions are dealing with fluid dynamics (name is misleading; it applies to gasses too); and so the same model applies well for interactions with both water and air for the most part, with some caveats at special points like buoyancy and density.

Agreed. But there is a forth alternative some have argued for or painted others as arguing for: 4) Regular aero model, AND a FAR-like model as a toggle, at launch rather than later. (overkill, IMO) I disagree that each of the alternatives are just as valid as any other, and have largely already pointed out and explained their differences, advantages and disadvantages, in my opinion. I disagree particularly with #1, as, to me, that is by far the worst option. The only advantage I can see with it is that it's the best for people who like a FAR-like model (and to be clear, I'm one of them; FAR is a must-have on my KSP1; but that's KSP1; a game I also played without FAR for years); but then it's cancelled out by being the worst for everyone else. And at that point, I see no good side to it. But I thank you for at least presenting your point in a nuanced, respectful manner, without misconstruing anyone's argument. And I'm along side you in that I would be ecstatic with happiness if a FAR-like model was implemented a secondary model with a toggle on the official game. Exactly as you said: Probably not going to happen, but we can dream.

Just for future reference, how do I find out the name of the transform (ie when it's not that)?

Trying to create configs for KWRocketry. Tried following the documentation, and got to the effects part in the in-game editor, but when I try to add an effect, nothing happens. New to this kind of modding, so probably some noob mistake, but if you have any idea what's wrong, please help! https://imgur.com/0cxfrb5

Why not both? A skycrane that, much in the Kerbal tradition, doesn't have (enough) cables to lower the hover to the surface, and thus just drops stuff high, which then need to be cushioned by airbags. Overengineered? YES. Fun? Very!

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.

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. 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. 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. 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. "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.

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.

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. 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.

@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 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". 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? The same level of "crazyness" in talking about FAR to someone discovering KSP. -> None at all. ... 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. 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. 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. 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.

I think, as I explained, that it's inherent to the one-model, at launch, stance you seem to have. So saying it's not true sounds to me like a contradiction with your own stance. But if you say it's not the case, then ok. --- Maybe you've changed your stance, don't realize the contradiction, disagrees that it is a contradiction, or some other thing. I really don't care at this point.

One model instead of two means less features. KSP(1) does not have a native FAR-like model. No mention was made of a more complex aero model for KSP2. So a FAR-like aero model at launch for KSP2, while some KSP fans have expressed not to like FAR, is rushing. I'd rather KSP2 come out as intended by the devs at launch rather than rush a FAR-like aero model into it for the sake of my impatience. I'll gladly agree to disagree. Although FAR is an absolute must-have on my KSP installs nowadays, and I'd be overjoyed if the devs decide to add a FAR-like aero model, a lot of people, probably a majority of the KSP1 casual players in fact, don't use and/or don't like FAR, and similarly wouldn't use or wouldn't like FAR at the main model on KSP2. With that in mind, if the devs decide to add FAR-like at all, and specially as a second model optional or difficulty-setting toggle, I'm fine with it being post-launch. Meaning I'll gladly let the people who don't play with FAR get their simplified model first. That when KSP2 launches, I'll enjoy the simplified model alongside them too. And that if and when a FAR-like model gets added, I'll use it. But hey, if you want the game rushed with a FAR-like model, and to get less features, and for the people who don't like FAR to get a worse KSP2 experience, for the sake of your impatience, you do you.

Which is why it's a second, separate aero model; in all of my arguments; and in the suggestion of most people who discussed. This is only a problem for your view where there can ever be only one model. Which is not what I'm talking about. I'll wait as long as needed for the game to be launched. And I'll wait further for as long as needed for a second, FAR-like aero model to be implemented as an option post-launch. For a solid future-proof game that ensures not only stability but also freedom, since some people clearly prefer to have an aero model that is not FAR-like. But hey, if you want the game rushed, and to get less features, for the sake of your impatience, you do you.

If either model ever gets adjusted, which it almost certainly will because aerodynamics models are complex and hard, and internal and limited public testing have their limits, almost never becoming the final model without post-launch wide-audience data, then you will get craft designs conflicting ("broken") between the changes for that model. If you mean "broken" as in actually broken with bugs, then most of the issues with FAR come from integration with the game and engine, which a stated reason for the suggestion of doing it in the stock game as part of an officially-developed thing in the first place. As for what a secondary model is; let's just say my patience and good will are gone, and reading shouldn't be hard.

...MAIN... ---------- Meanwhile, I was clearly referring to a ---------- And you still insist on quoting me, as if I was saying I'd like for the main model to be rushed in order for the game to be launched faster; which is not the case, not what I believe in, and not what I'd like my image to be associated with. As I explicitly told you, multiple times. [snip]