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]

At no point did I ever say the team shouldn't be given time to polish the stuff that is actually planned for the game's release. [snip] And even at that, I've made myself abundantly clear about what exactly I'm not willing to get delays for, and it has nothing to do with the base game, it's proper implementation, or the delays necessary for that. At no point did I ever say that implementing realistic (or even non-realistic) aerodynamics in any game would be "just some optional feature" [snip]. What I said was that in my opinion an official FAR-like aerodynamics model as an option within the stock KSP2 (developed more integrally than a mod could be) would be good and very welcome, but that an aerodynamics model similar to FAR, that is secondary and optional to whatever becomes the main model (presuming KSP2 doesn't plan on a FAR model being the main; which is the same assumption inherent in the suggestion of it on this thread, [snip] is not something I'd wish to get extra delays for it to be present at KSP2's launch. Meaning I'm willing to wait as long as necessary for the base game to be done and polished; but would not welcome extra delays for launch, for extra, unnecessary features, which a secondary aerodynamic model is. [snip]

I'd rather you didn't confuse or conflate mine preference for there not to be delays for the sake of a specific, optional feature, with any form of impatience or wanting things rushed in any way. Those are VERY DIFFERENT THINGS.

Is FAR one of my absolute must-haves in my KSP installs today? YES. Was FAR required when I started playing KSP? No. Will I need KSP2 to have a FAR-like aerodynamics model embedded in stock in order to buy it? No. Would I absolutely love it if it was done and done right (optional, balanced, moddable, etc)? YES. If it were to be implemented in stock KSP2, would I prefer the game to be delayed in order to have this at launch? No, with some extra words to make it clear: While I'd love it to have it at launch, I'd rather start playing KSP2 sooner and without this, just like it was for KSP(1), than to have this be the reason KSP2's launch gets a delay of any kind. I'd prefer that this gets implemented as any other feature update. Maybe a high-priority one, but still not as something required at launch (absolute base game).

Thank you!

Which resource pack? Doesn't seem to be working here now either. Fuel Cell is "running" but EC is not generated, and resources are not consumed. UPDATE: Nevermind. Doesn't work if containers are full and you forgot to set it to dump excess.

Hey Chris. Just wanted you to know that you and your mods are awesome! Take as long as you need. I consider RC one of my absolute essential mods, and frankly, 1.11 without it and a couple other essentials, is still enjoyable, but barely. One really does get addicted to the good stuff. People ask you about updates because they appreciate the value of your mod on their playthroughs. And because they miss your mod until it's updated, they're anxious for it. Yours is the kind of mod so good for KSP that people (me included) literally can't wait to get it as soon as a shiny new version comes out. And many, if not most people don't know how to deal with that anxiety. So they vent it by asking "Is it ready yet?" or "When is it coming?". Which can sound like they're putting pressure on you to work more/faster, but, if I understand anything about psych, mostly isn't the case. It's like a kid in the car going to an amusement park and asking "Are we there yet?" or "How long 'till we get there?"; it's excitement for something cool, and the anxiety from the fact it's coming but not "here" yet. Anyways, you do what you gotta do. It will be ready when it's ready, and I'll be patiently (albeit anxiously ) waiting for it. Thanks once again for your awesome mods and your awesome presence among us! Cheers!

I actually only (re-)started RO/RP1 play recently and was doing my setup. I've some of your other mods installed on my "normal KSP" build and trust you so much that I just installed the two "companion" mods outright once I saw them. I don't even know if they are needed. But I would prefer to just have your mods and not even have to know. But alright; I guess I'll remove NF companion for now, play a bit of a temporary career just to get the feeling of RO things back, and wait for your patch. The real/serious career can wait. No problemo, amigo! Take your time and do your excellent work as always! And thanks a lot for the support! And if you can notify me when the patch is ready and out, I'd also appreciate it!

Sure thing: https://drive.google.com/file/d/1lZ0dfWBRgPp84N91XUQwzdidgEmlZeiU/view?usp=sharing

Getting the fatal error message on startup, and these little fellas in the log file: Here be the full log: https://drive.google.com/file/d/1ZEOOou1AxOCLXFiX6qnS59N4iIdXyfoE/view?usp=sharing (NOTE: I decided to 7zip it because the thing is 30MB raw )

@Lisias I seem to be lucky a lot of times then, because I get this "halfway" effect regularly! Specially with mirroring of scaled parts! So yea, can confirm! (and sorry, forgot to mention it in my initial but-reporting post; was not even sure the problem was with TS back then) Actually... *loads KSP and does some testin based on rememberance*... I even know how to reproduce this! Anywhere before step 3) Make sure any kind of mirroring is on. 1) Select tank. 1.1) Drop tank "ghost" without attaching it. 2) Scale tank (ghost) UP. 3) Attach tank. 3.1) (Optional[?]) Right click original scaled tank. You can see it has scaled values as if TS was working correctly. 4) Right click any mirrored tank. You can see it has the default scale resource amounts, and default maximum. 5) Right click the original scaled tank (again). It now has the original scale resource amounts, but with the scaled up maximum. WHAT THE FURBALLS? So yea, bugged mirrored parts (dark-)magically UNDO TS resource scaling if you right-click them (while keeping capacity intact). EDIT: Some more testing. If the tank is scaled DOWN in step 2, capacity on the mirror-clone is set back to the original size's, but resource stays down on both parts... Basically, the bug works the other way around. Also, another thing that maybe may be (yes, I did just do that lame pun) a useful indicator of the problem is that I seem to only get the bug with some resources but not others... For example , EC (Electric Charge) and LOX( LiquidFuel+Oxidizer) tanks seem to work fine all the time. It's Monoprop, SolidFuel, etc that gets mangled. EDIT: NVM, seems to happen to all tanks on a test install with just TS. I guess it was not happening to EC and LOX on my main install because of other mods. (I suspect specially Kerbalism)... Which indicates that yea, some resource-related mods can workaround/fix whatever causes TS's bug... But it also indicates they may have only a partial, unreliable solution. Haven't tested with Interstellar Fuel Switch. Also, also, other mods that used to support/rely on scaling seem to have problems with other stuff related to scales, not just resources. For example, StageRecovery, which I remember working correctly with TS and having scaled "m/s" (drag power prediction) values for scaled chutes, now gives default parachute "drag power" on it's calculations no matter the scale of the parachute. (While the "real" drag power of the chute is scaled normally, as I could confirm by totally not harming a kerbal with a test of straping a 0.1m chute on top of a mk1 capsule+"flea" solid booster... )