Raptor9

Thanks @Dash8466. In recent weeks, I've been diving heavily back into KSP for the first time since the summer. The first thing I did was clean out a lot of craft/subassembly files that I no longer use, are no longer relevant, or were quite old and didn't take advantage of the latest parts/functions of KSP, or my personal build techniques and strategies. One thing I finally got around to doing was rebuild my Space Shuttle analogue from scratch with a new airfoil, RCS control scheme, and re-balanced payload range. I also rebuilt the launch stack to utilize the 2.5m Clydesdale SRBs, and built an entirely new External Tank, which led to better balance and control throughout the ascent profile. The Breaking Ground robotics became quite an important aspect of it as well. Not just in making a robotic arm for the cargo bay, but designing an articulating body flap mechanism to the aft end of the Shuttle. This allowed me to maintain near-perfect lift/drag balance throughout the entire reentry profile, to keep the Shuttle neutrally stable whether it was nose up during hypersonic reentry, or nose down in it's terminal glide phase. The final piece was the 1.9 fuel drain valve. Since I could now drain all residual liquid fuel and oxidizer from the Shuttle prior to reentry, it allowed me to optimize the airfoil for a more narrow CoM location. On average, throughout about dozen reentry tests, I only use about 20-40 units of monopropellant for attitude control until I switch to aerodynamic flight controls. I have to say, the Breaking Ground robotics are definitely worth their price and more. Aside from the robotic arms, ramps and other immediate uses I thought of when they were first announced, they add so much more functionality to a craft when coupled with the expanded Action Group options; and that's even before you need a KAL for really advanced stuff.

Not sure about how it affects its radar cross-section, but the primary reason it was designed with a 55-degree separation vs the typical 90-degrees in 4-bladed tail rotors is to increase tail rotor efficiency and performance. The 55-degree separation, coupled with the lateral offset of each blade "pair" ensures that the second set of blades operates in clean air, instead of operating in the wake of the first pair of blades. It's like following close and to the side of another aircraft, avoiding it's wake. However the further back and/or closer to its tail you are, the greater chance you will encounter turbulent air trailing behind its airfoil surfaces, which will expand the further back you go. Another common misconception was that it was designed to make it more quiet. While avoiding the wake of leading pair of blades does lead to less noise, this is a convenient by-product of the aerodynamic design, rather than the primary reason for the design implementation.

What you're experiencing is normal. In real helicopters this is called dis-symmetry of lift, and requires more forward cyclic to counter the pitch up tendency the faster you go. As a result, you will need to trim the nose down to maintain attitude, in lieu of physically holding the controls forward. As an alternative, try adding a horizontal stabilator to the tail, and map the trim to something like the Translate U/D action groups. As you speed up, you can apply more and more stabilator incidence to keep the pitch stabilized. To avoid large forward cyclic applications in the CH-47, the flight controls have what's called a Longitudinal Cyclic Trim (LCT), which you can read about in the hyperlink in Maxsimal's post at the top. Also included is talk about main rotor flapping, which is not simulated in KSP. As a result, KSP helicopters will experience much greater pitch down attitudes in forward flight compared to their real-life counterparts. And unfortunately, this also prevents designing a tandem-style helicopter with authentic yaw control.

Like Kamov and Mil had a baby...wait a sec, why is the Mk3 Cockpit white?

There are a lot of real-world helicopter physics not simulated in the KSP rotor blade physics. However, to be fair, there are a lot of real-world aerodynamic and rocket physics not simulated either. In regards to stabilizing a KSP helicopter using trim vs SAS, I'll say this: Flying a helicopter requires a lot more control inputs and "cross-control" compensation to keep all the competing physical forces in a constant state of balance, when compared to controlling a fixed wing aircraft. Any change in cyclic position, collective position, pedal input, airspeed, etc, requires the controls to be adjusted to maintain the balance of forces and the desired attitude and flight path. The SAS in KSP is very rudimentary and comes nowhere close to the complex flight control systems in modern aircraft. Depending on the sophistication of the flight controls and avionics, some real-world helicopter SAS systems have very limited authority to maintain the desired attitude, requiring the pilot to constantly adjust the controls to a position that the SAS can operate within it's authority envelope. The most common "trimming" mechanism for helicopters is called "force trim", which can be augmented with SAS, or further augmented by active flight control systems where the computer has complete authority to control the helicopter in a similar manner to autopilot in fixed wing aircraft. To read a brief run down of each, you can go here: https://www.danubewings.com/stability-augmentations-systems/. However, the level of sophistication required for the KSP SAS to account for any number of rotary-winged craft that may be "lego-ed" together is (in my opinion) unrealistic. What I'm getting at is that real-world helo pilots must constantly adjust controls to maintain level flight, so it is reasonable to assume any simulation of such physical mechanics (even a semi-realistic one), would require the same level of constant attention to the controls. I would recommend using a more complex flight control setup, like a joystick with twist yaw control or rudder pedals, if you plan on doing long-duration helicopter flight. This would also allow you to more easily "phase in" Alt-WASDQE trim input to decrease your workload. But if you plan on using just a mouse and keyboard, don't expect rapid changes in flight condition, like airspeed, to come without it's associated workload tapping those keys. I was able to make a compound helicopter very similar to the S-97 Raider using a coaxial twin-rotor with a rear-facing propulser using fan-blades. The craft was very well balanced, but did require a horizontal stabilator to maintain pitch stability throughout all speed regimes, and the only real trim I had to apply was roll to account for the torque generated by the tail propulser blades when in use. But to easily fly an "asymmetric" helo design like a single main rotor with anti-torque tail rotor throughout all possible flight conditions using just a keyboard is quite a tall order for what could be asked from KSP.

Since there are a lot of personal assumptions being thrown about (some of them reasonable, some of them not), I'll add another. My personal take on why T2 is having a different developer produce KSP 2 is because they want to consolidate the team under one roof. IIRC, as the dev team at Squad grew and morphed over time, some of its members that came on board are at various parts of the world, even though the majority are in Mexico City. Consolidating the dev team into a single time zone, let alone a single location, most likely was a decision based on efficiency, rather than competency.

Let's review some underlying facts. 1) Just because a sequel to a game comes out, doesn't mean it will be better. 2) Businesses must have a positive money flow to survive. If they do not, they will close. 3) Business strategies to accomplish said positive money flow vary, and sometimes are only known to the individuals making such decisions. 4) The version number assigned to any game is irrelevant and has nothing to do with a title. When two different developers are designing separate games, even if the publisher and intellectual property owners are the same, the artistic and game mechanic views of the development teams can be quite similar, or quite different. However, even with quite similar artistic design and game mechanics, the slight variances can make a difference in a player's overall satisfaction with the game. I've played several video game series where follow-on sequels were quite horrible (I'm looking at you Jetfighter), despite the huge jump in graphics. Just because you have two different development studios, there is nothing wrong with having two different games being developed in parallel sharing the same overall Kerbal concept and lore. As long as the intellectual property right owners allow the development, and both products continue to make money for all involved, it is usually a safe bet such a business practice will continue. There will undoubtedly be some players out there that will only ever play KSP 1, some will have only ever played KSP 2, and there are others that will play both (either sequentially or concurrently). We don't know what the strategy is for the powers-that-be, and we probably will never know. I think it is reasonable to assume that KSP 1 will see noticeable drop in revenue when KSP 2 is released. However it is very possible KSP 1 will continue to evolve in it's own direction, and continue to enjoy financial prosperity. Especially if future DLC's are planned that "break new ground". Lastly, KSP 1 was in alpha-state when I bought it at v0.13. That doesn't mean I was playing KSP Zero version 13. You can have KSP 1 v2.8, and you can also have KSP 2 v1.0.

Nah, just re-focusing. @Jester Darrak, @Cisco Cividanes, @Jestersage, @paleofrank, and @Rune, thanks for those kind and flattering words. @paleofrank, I don't understand what the hold-up is. I emailed Photobucket support on Monday regarding my account (which I renewed my annual service in November), but I still haven't heard back from them. I understand it's the holidays; maybe they are just backed up with similar issues after their power outages in December. I'll send you a PM.

The time has come for me to wind down any further catalog work. With 291 craft files and subassemblies, the download list has grown far, far larger than I ever originally intended over four years ago. At that time, Kerbal Space Program was on the cusp of it's official 1.0 release, and a few forum posters asked if I could post some of the craft I was sharing via screenshots, the original EV-4 'Longship' to be exact. They suggested KerbalX which I hadn't yet heard of. After a few individuals messaged me saying that those craft helped them get to Duna, I decided to post some more craft from my KSP save with the hopes those would also prove useful to some other players. The cooperation among KSP players, especially in the early development days, has always been the virtue of the KSP community. As such, it was something I always wanted to contribute to. As KSP continued to evolve through Alpha, Beta, and then all the post-1.0 releases of content and game mechanics updates, I had always striven to keep my craft updated in current working order. Unfortunately, that commitment became quite the workload as the catalog continued to grow. I had always found a way to balance craft file maintenance with my own career gameplay; but over the past year, that ratio has become quite one-sided. Halting catalog expansion and maintenance has been something I've been considering for quite some time; since around last February actually. After finishing the Ranger Corps project, the thought of working on any further graphics or craft file updates kind of took the wind out of my sails and made me question why I was so committed to it in the first place. Especially compared to how little I had advanced in my own career save. So many players had explored the entirety of the Kerbol star system, to include the Outer Planet mod, and they were turning to other star system mods to increase their re-playability. My crewed expeditions had stalled and gone no further than Eve's orbit and Duna's surface, with just probes arriving anywhere else. Don't get me wrong, I have still had way more hours of memorable game time per dollar in KSP compared to any other game I've ever played, and I've been gaming for decades. My real-life job in the past year has gotten quite busy and I need to focus more of my mental energy on it, especially in recent months. This has resulted in less recreational gaming time, which means less KSP time to divide between the catalog and my career save gameplay. As we clock into 2020, I'm sure we will start hearing news of the next KSP update, as well as KSP 2 down the road. There were some things I wanted to tidy up in my catalog, as well as more things I wanted to try, but regretfully I simply do not have the time for it anymore. This, coupled with the unfortunate fact I've had almost zero KSP play in recent weeks, I've decided to commit to letting the catalog go. I also want to branch out different avenues for my creativity. What I don't want to do is set unrealistic expectations for catalog expansion and maintenance when it can no longer be a sustainable priority. If anyone needs help or has questions about the various craft, feel free to message me. I'll of course still be around on the forums. (On a separate issue, I'm still trying to resolve the issue with my Photobucket account so the catalog images are restored to the forums and KerbalX) First and foremost, I want to thank @katateochi for his maintenance of the KerbalX website. He is probably one of the most accomodating KSP community members out there, always willing to adapt KerbalX to suit the community's needs. His recent recruitment of volunteer moderators for KerbalX is also worth a notable mention. Another singular mention is @linuxgurugamer for maintaining the Kronal Vessel Viewer mod that has been the linchpin of generating graphics for my catalog. The community members that have been the most influential and inspirational to me are @Rune, @Nertea, @Nils277, @Majorjim!, @Cupcake..., and @KerrMü. Aside from their contributions to the community at large, they've challenged my build techniques, my mission ideas, and have influenced my overall style of craft files. In addition, community members that have consistently thrown ideas my way (even when I don't always incorporate them) are @Jester Darrak, @Majorjim!, @Jestersage, @AlchemicRaven, and @Crobal. They've not only helped to identify craft deficiencies to make the catalog better, they've also assisted with mission architecture refinement and smoothed out some of the rough edges of the catalog itself. The literal bottom line is that this catalog was built with the help of KSP community members, with the singular purpose to help community members accomplish their goals in Kerbal Space Program, and hopefully inspire others to do the same. Thank you to everyone for the help and assistance.

It's not just you. Photobucket has been experiencing website disruption the past week or so.

You can send me a private message.

I can't say that I've had any serious issues with people downvoting my craft. The thing with downvoting is it costs several points to downvote a craft. These points come from the downvoting user's own collection of points that they receive from upvotes or from other activity. It's in a user's best interest to only downvote a craft that is unplayable, extremely hard to use, or representative of something that would be in bad taste. You could also downvote a craft that is plagiarized from another user, but that would be a waste since you can simply report it and it will usually be taken down if the report is legitimate. But in the end, you will always have haters out there. I've experienced the occasional troll myself, but eventually the upvotes will outnumber the downvotes if your craft isn't unplayable, hard to use, or in bad taste. KSP generally has a lot more positive players that contribute to the KSP community than negative ones that detract from it, despite the negative players usually making a lot more noise. If the behavior becomes a serious trend that you believe is excessive, you can always report the activity to one of the awesome Kerbalx volunteer moderators.

No and no. Unfortunately, due to real-life stuff, I haven't had much time for gaming recently.

@Zenrer, it appears that Squad have thankfully fixed the bug that was causing your issues earlier this month with 'Skiff Sail' (and a lot of my similarly affected craft). You should be good now.

When I saw the thread title, I was going to essentially post this exact sentence...but I was 13 mins too late.

Nah, just too busy with work. Still haven't been able to boot up 1.8, let alone see what is or isnt working.

@katateochi, that does sound painful for sure. Take care of yourself first, but don't enjoy those pain meds too much. I hope you kicked the cow back.

Too soon to tell. I've been so busy with work recently, I haven't had any time to play KSP. I haven't even had time to download and install 1.8 yet. However, it would be cool to make an Antares and/or OmegA-style lifter that was really cheap, but we'll just have to see (whenever I can get back to KSP). I definitely plan to use the S2-33 Clydesdale for my Shuttle. But I'll probably keep the Kickback boosters on my SLS analogue; they already work just fine, and are sufficient for the typical payload masses I put into orbit with my 3.75m lifters. True, but the various lifters were primarily designed in such a way that revolved around their manufacturer. And since Rockomax is the intended manufacturer of the Thunder families, I went with the Thumper boosters. If anything, I would want to go smaller, but I doubt the new Shrimp would be sufficient, and I haven't even looked to see who manufactures each new booster. Again, I just need to get time away from work to investigate all of these possibilities.

I figured I might as well post a few images I was messing around with for the KSP loading screen contest. I was mainly experimenting to see what kind of images I could piece together from multiple sources. The first one was my submission for the contest. The others were just some other ideas I didn't think would meet the guidelines but were still fun to make.

Just tested it, and the LITE responds correctly. Like @Jestersage said, you might have had a non-standard control axis engaged.

(Sigh) I'm afraid it's not just with the 'Skiff Sail', it's with all my rockets with fairings used as interstages (at least the handful I tested anyway). Apparently, if you stage (jettison) the interstage fairings that cover the LV-T91 engine on the upper stage, when the 1st stage decouples, the RCS thrusters work fine. However, if you don't stage the fairings, and let the 1st stage sepratrons pull itself away, sliding the interstage fairing away from the upper stage engine, those RCS thrusters won't work for some reason. Yet the aft-facing thrusters do still work like you said. Another subtle but significant behavior change that will force me to update almost the entire catalog. But, with the 1.8 update in the near future, and with it the Unity engine update...I really have no motivation to correct anything. Especially after just getting my computer operational again this past week, and about to go on a business trip for a few weeks. Hopefully the 1.8 update will correct any such behavior like that; but if it doesn't, I guess I'll have to find the time to tweak all my craft files with similar launchers sometime in the future.

Aside from Kronal Vessel Viewer for making my graphics, Stock Visual Enhancements for screenshots, and Hanger Grid: Zero Deviation for ensuring proper landing gear alignment on aircraft/spaceplanes.

Hey @Jestersage, my apologies for taking so long to answer your question. This week has been very busy at work, and I had to wipe my personal computer hard drive several days ago and re-build everything after experiencing some serious issues. Thankfully I had all my KSP work and various projects backed up so I had minimal data loss. Regarding your first question. Really it just came down to personal preference. Didn't make sense to place the crew compartment so far away from the docking port; and in real-world comparisons, having two separation events prior to reentry increases chances of failure. Another big reason is I didn't want to make my Soyuz analogue like everyone else's. I've had several people on KerbalX drive this point home on my Soyuz-inspired craft. It lead to some heated comments too, for one reason or another, but that happens sometimes on the internet when people are sending text-based messages. I prefer not to use aerobrake maneuvers unless I absolutely have to...since I'm not that skilled at predicting the outcome. The tests I performed and annotated on the graphics are all strictly propulsive-based.

Yesss....YEESSS!!

In the spoiler is a text-free version for any potential localization needs. Only mod used was stock visual enhancements for the atmospherics.