Claw

I heartily agree that fairings are too heavy. Indeed, I'm not completely surprised by your results.

Fellow Kerbonauts, There has been a lot of discussion about all the aerodynamic and thermodynamic changes within KSP 1.0. It makes me pretty excited to see all the discussions about what works, what doesn't, and people figuring things out. However, there's been a trend on the forum the last few days that seems to be leaning toward animosity. Aerodynamics in particular has always been a polarizing topic between the "realism" crowd and the "fun gameplay" crowd. For me personally, it has never been a question of which should win out: Realism or Gameplay. There is simply no possible way to achieve the perfect blend of realism and gameplay that satisfies every single player. I would sincerely like to point out that the beauty of this forum is that we all come together to understand difficult and complex concepts that have been boiled down to a relatively simplistic (and ideally understandable) representation in KSP. Accomplishing this is no small feat, and can be quite the challenge to balance while maintaining some level of realism and gameplay. To me, this community has always been incredible because of it's willingness to help each other. So I thought perhaps, instead of having yet another thread that goes back and forth about how the game does or doesn't meet your expectations, I would try to explain a bit about how complex the new aerodynamic and thermodynamic system is, and just how big of an undertaking the system has been up to this point. Perhaps that will lend some insight as to why finding a good balance is quite difficult. This isn't meant to be a "defense of the system" sort of post, but more of an attempt to explain how the system works, to the people who love (and hate-to-love) this game. Basic Drag: The basic drag system for most parts is based off of a cube system. Every time KSP starts up, it looks into the PartDatabase.cfg file and checks for all the cubes. If a cube doesn't exist for a part, then KSP generates a drag cube for that part and stores it in the database. - This has the advantage that you can (generally) look at the shape of the part to figure out what will be less draggy and what will be more draggy. - However, this also causes issues with hollow parts (such as cargo bays) which have incorrectly built drag cubes. - Parts can also have drag cube multipliers, to adjust the size of the drag cube if the model shape is insufficient to really define the drag. Physics.cfg contains several curves in it. One set of curves (tip, surf, tail, mult) controls the level of drag that the cubes produce, by cube face. KSP uses these curves to build a profile curve that is used to calculate the weight of drag that each face contributes to that part. The cube face that points into the wind uses tip * multi, sides use surf * multi, and the back face uses tail * multi (in simplified terms). The multiplier value is (in essence) a standard drag profile from subsonic through high hypersonic (in KSP's case, Mach 0.0 through Mach 25.0). This includes the supersonic drag rise in the transonic region, which for KSP is Mach 0.8 to 1.2 (270 - 410 m/s). Part occlusion is accomplished only through node connections. Parts that are connected to other parts via nodes have the size of that cube's face reduced by the size of the parent/child part. So surface mounted parts are not occluded from drag. (This is why stuff built with lots of things hanging off suffers a lot of drag.) - Because of how drag cubes are built, open ended model parts can cause problems. Not all of these parts were adjusted to account for this, which is why there is some imbalance. Basic Thermo: Builds off the drag cube system to calculate how much of the part is exposed to the air. This basically sets up how much friction the part is going to experience. Thermo also includes simulation of shock cone occlusion, which deflects heat based on the part that's out front. This is why the location of surface mounted parts matter. Put them too far forward, and they hit all that heat. Put them too far back, and the forward blunt body doesn't provide shock cone occlusion anymore. - Balance for this is also tricky, so as to provide occlusion for parts when it makes sense, but not block all heating for the entire craft by mounting an antenna out front. Basic Lift/Drag for Wings: Wings (more specifically, lifting surfaces and control surfaces) are handled separately from all the other parts in terms of drag. Wing lift is based on two curves, a Maximum Coefficient of Lift based on Mach, and a Coefficient of Lift based on Angle of Attack. - Wing lift is based on the V-Squared drag model, but is also scaled by the Cl-Mach curve to account for different levels of lift based on flight regime. Building a system this way has good and bad qualities. First, it simplifies things a bit in the KSP lego world of parts. However, it's not as complex as accounting for things like wing sweep and aspect ratio. - Balancing this curve also causes weird problems like shuttles that can glide at unnaturally low speeds (because they have a lot of wing area). - Wing lift from AoA right now is very forgiving in KSP. There is a stall Angle of Attack, but it is quite high. This is also part of why things can fly unnaturally slow and don't fall out of the sky even at extremely high AoA. Wing drag is based on two curves, a Maximum Coefficient of Drag based on Mach, and a Coefficient of Drag based on Angle of Attack. - The Cd-Mach curve for wings is higher than that for fuselage pieces. There's a variety of reasons for this, but the end result to the game player is that if you build a plane with a lot of wing area, you will have a hard time getting through the supersonic barrier. However, once you're past it, it's generally easier to keep accelerating... EDIT: By popular demand, here is a more in-depth discussion of the wing lift/drag modeling. So, on top of all that, many parts have special cases. As noted above, parts that have open models (such as a cargo bay) can cause issues with part occlusion. Models with multiple cube types (such as parachutes) need to be built and adjusted properly. With all these special cases, I'm sure some of them were missed getting updated. On top of that, with any change to the global modifiers, it throws all of the other parts out of balance. It's a difficult act to balance. So yes, feedback is more than welcome. But if you want your feedback heard, avoid clouding it with too much angst and frustration. Sure, we can have a back and forth on the forum about why the model is built this way and whether or not everyone agrees with it. But really my point in all this is that this is our new model (like it or not) and perhaps understanding a bit about how it works will aid people in their design process. As a final note, all of these parts were built to be completely controllable and configurable by the user. No, I'm not saying "If you don't like it, go install a mod." I'm say that if you find something out of balance, try playing with the numbers and posting your findings! It's the community, working together, that really makes this place awesome to me. Hopefully this all helps a bit to understand what those sliders and buttons do. Cheers, ~Claw

Just to avoid confusion, fuselage pieces will generate drag due to their skin friction. However, it looks like there's also a bug with the Mk3 cargo bays, where they aren't occluding properly.

Yep, you did. It will hopefully be rolled into my fixes tonight.

Yes, this. And I'm working on it. Possibly will be added to my fixes tonight. Cheers, ~Claw

If it's still doing it, then yes. It will help me consolidate what's happening. Cheers, ~Claw

Are you referring to the sub panels? That specific note is in regard to the three sizes of fairings. I would say it's probably not possible to change the ejection force on each fairing panel. However, I am working on something that may allow a bit more control over the fairings. It's already possible to control how many panels around the base, but I'm working out if I can control the panels length wise.

Ah okay. So it looks like pretty much no matter how you revert, inter stage fairing shielding is broken. Thanks for the video.

Parts are now draggy based on how they look. So if something looks pointy or rounded (like a nosecone), then it probably has less drag than something blunt (like a fuel tank end). Cheers, ~Claw

RexKramer is 100% right. Those were the drag values used by the old aero model, and are not in use by KSP v1.0+ Cheers, ~Claw

Your video is set to private.

Updated for 1.0.2. Includes a few internal bug fixes, refreshing modules for 1.0.2, and deprecating some fixed ones. Cheers, ~Claw

Thanks for the report. I'm reworking a lot of these modules right now. I don't know off hand either. I'm not sure if the wheel was put in as a separate model piece, or if it's somehow a static part of the model. I'll write this down as something to look into though. Cheers, ~Claw

I have plenty of realism in my life, so I don't really get upset if a video game doesn't perfectly represent reality. On the flip side, I don't like aspects of a simulator style game to be completely misleading in how things react. So it's a bit of a balance. One such example would be the ion engine. Personally, I really don't want a "realistic" ion engine. Why, because ion engines on small probes burn for months. That doesn't sound particular fun for me from a gameplay standpoint. So yeah, I'm willing to except unrealistically over powered ion engines for the sake of not having to 4x warp my way through a month long burn...

Well, for chute problems (with all the adjusting going on) if you run into strange drag problems... the best bet is to delete the PartDatabase.cfg file (in the root KSP folder) and restart the game. That will force it to rebuild and reload all the drag cubes. Cheers, ~Claw

Well, I think it's probably a side effect of the fact that they aren't set up to accept surface attachment. The problem being that if surface attachment is turned on, then you can attach things to the fairings themselves. This sounds like it's not a problem, except for the fact that things start phantom floating (sticking in their original position) when the fairings are jettisoned. So, a bug of sorts, but I'm guessing it's due to the current mechanics. Cheers, ~Claw

Kerbonauts! I am creating this thread to collect all of the issues with parachutes that burn up, are way out of balance, or any other bugs. In this particular thread, feedback about chute performance is welcome. There are a lot of these threads, and I want to collect the issues into one place. Purpose of this thread: To consolidate all of the issues with parachutes in one place. What parts: Stock parachutes. Details: Are important. Provide pictures or a craft file of what's happening. If you don't know how to do that, see this thread. What this thread is not: Do not use this thread for complaining or general bug reporting. Any such posts will be removed, since this thread is specifically designed to get to the root issues of parachutes. Cheers, ~Claw

Kerbonauts! I am creating this singular thread to collect all of the issues with parts that "Cannot activate while stowed!" despite the fact that they are not stowed. Parts that are stowed are intentionally disabled. That's another topic all together (feedback, and not a bug). There are a lot of these threads, and I want to collect the issues into one place. Purpose of this thread: To consolidate all of the issues with parts that are not able to activate while stowed, despite the fact that they are not stowed. What parts: Stock cargo bays, stock service bays, and stock procedural fairings. Details: Are important. Provide pictures or a craft file of what's happening. If you don't know how to do that, see this thread. What this thread is not: Do not use this thread for complaining or general bug reporting. Any such posts will be removed, since this thread is specifically designed to get to the root issues of the "stowing" process that disables various parts. This thread is also not about the functionality of procedural fairings beyond stowing. Cheers, ~Claw

If this problem is still happening, please upload some more info such as log files... Or saves/craft files that consistently do it. http://forum.kerbalspaceprogram.com/threads/92230-%21%21%21-PLEASE-READ-BEFORE-POSTING-%21%21%21-Stock-Support-Bug-Reporting-Guide Thanks, -Claw

You are 100% correct. Deployment altitude is AGL, but the thinner atmosphere will take it a bit longer to slow down. Cheers, -Claw

I've not seen this in stock yet, though I'm not sure if I've tried to trigger this yet in 1.0.2. Please do try to narrow down if it's due to the mod or not, so we can make sure the bug report gets to the right place. Cheers, -Claw

Yes, deployed chutes are now subject to heating and can burn up rather quickly. But the blunt capsules (and other parts) should also be a bit better at slowing down. So you should be able to wait longer now before deploying chutes. Although I would agree. If chutes are burning up while staged (but still stowed), that's a problem. It's hard for me to tell from this thread if that's actually the case...? Cheers, -Claw

Good to know if people are enjoying it. It sounds like something that I can add to Stock+. Also, good idea on the decoupler. Was this with my fixes installed? If so, is it also repeatable without them? I haven't seen or heard of this yet. Cheers, -Claw

You can tweak them, but also realize that everyones preference of a good altitude is different (in terms of a good default). Although point taken. The current default should be giving a safe deployment over the water or at KSC. Any higher landing locations probably require a higher deployment altitude, and generally craft don't come back to KSC. I have a plugin in my signature that unlocks deployment speeds too, if that's something you are interested in. Although I'm in the process of updating for the changes in 1.0.2. Cheers, -Claw

Yes. Undo is quite buggy/broken. Be careful with it, as it has a tendency to corrupt ships. Especially if debug clipping is enabled. Cheers, -Claw