Raptor9

Members
  • Content Count

    1,577
  • Joined

  • Last visited

Community Reputation

2,754 Excellent

About Raptor9

  • Rank
    Spacecraft & Rocket Dealer

Profile Information

  • Location Array
  • Interests Array

Recent Profile Visitors

16,937 profile views
  1. If you wish to promote your KerbalX craft, please do so in your own thread. This is not the place for it. If anyone has any questions relevant to any existing craft in the catalogue, please PM me and I will answer when I am able.
  2. Maybe, but then again, you may get more questions regarding your craft if you cut down on the detailed graphics. But that's just my take on it; I could be completely over-emphasizing the need for more detailed craft documentation. Everyone has their own priorities for managing their time. For myself, I will sometimes use my own craft graphics as a sort of checklist to keep in mind what action groups do what as I perform critical maneuvers like atmo entry, descent and landing. Having the ability to edit/view action groups in flight still doesn't necessary capture the whole picture of what each action group is intended to do. In a nutshell I mapped it to my Wheel Throttle, which I use Numpad 8 and Numpad 2 for Drive Forward/Drive Back respectively. This allows me to essentially use those keys as a trimming function separate from my conventional attitude and translation keys. If my Pitch axis indicator starts going up or down, indicating the SAS is inputting control surface/RCS to maintain the pitch attitude, I will trim the body flap with short taps to maintain the neutral aerodynamic balance of the Shuttle. This cuts down on monopropellant usage during upper atmosphere flight, and also allows me to more precisely trim the Shuttle for a certain glide airspeed/angle when it gets to the lower atmosphere.
  3. At the time I was still maintaining the catalog, and the reasoning behind leaving it vanilla was because I was no longer using it in my career save anyway. But both of those facts have now changed. Since a lot of my craft files have undergone drastic revisions since the last time I heavily played my career (~2 years ago), I've decided to start a new career after the rest of the Kerbal planets/moons receive their respective revamps. In the meantime, I did a complete assessment on every craft file on my hard drive, and the associated strategies behind each exploration architecture. This resulted in cutting out a lot of duplication and excess. In all, I think I removed around 50 craft files/subassemblies so far, as well as a handful of mission architectures. I then identified which craft files could be improved using the latest parts and build techniques. Getting into the Breaking Ground robotics has not only allowed me to make a Shuttle I actually want to use again, but also allowed me to revise my ISS analogue, 'Pioneer Station', to drastically cut the part count. Namely, using robotics to revamp the main solar arrays, as well as a few tweaks to some other space station modules, I've managed to shrink the part count of 'Pioneer Station' from 488 parts and 24 modules to 366 parts and 16 modules. And with a single, Shuttle-mounted robotic arm, this also allowed me to get rid of the EMU. Each one of those little buggers was a solid collection of 24 parts, and needing two of them to assemble a station by pulling modules out of the Shuttle's cargo bay added quite a lot of parts in physics range of the station. So with all of that, I'm looking forward to the challenge of building an ISS-style station in my upcoming career restart (hopefully this one will be my final career restart, and actually make it to the entirety of the Kerbal system ). Thanks @davidy12. Although I do want to make it clear, to avoid any confusion, that I am back to playing KSP; not back to catalog updates/maintenance. On the topic of the Apollo-style landers, that was one of the more heavily slashed mission architectures in my VAB. Currently, the catalog has quite a large collection of Apollo-style landers that extended into the Apollo Applications proposals. The problem with habitation landers like the LV-1H or the LV-2B, was that they really didn't serve much purpose aside from "role-play" habitation. Without the ability to conduct long-term surface research via a Mobile Processing Lab, my next career will have no extended surface stays on the Mun or Minmus beyond what is needed to deploy surface science experiments, or take measurements with legacy science sensors. To this end, I've removed rovers from my Apollo landers entirely. I know, it doesn't seem "right", but I've been forcing myself to look beyond how things worked in real-life, and look to what would work better in KSP. Kind of like how my Soyuz-analogues have no separate orbital and reentry modules. With the purpose I designed them for, it wasn't necessary, so I didn't want to force myself to make design decisions solely based on how real-life "equivalents" function. In KSP, I don't want to box myself in using real-life contemporaries as the measure for success. Further, this allowed me to avoid making a lander big enough to accommodate a rover, and avoid trying to make a rover small enough to fit on such a small lander frame in the first place. Of course, I still plan on having surface bases on the Mun, and those will of course have rovers; but this will allow me to optimize the size and layout of the rovers if they can be delivered on dedicated cargo landers versus needing to be folded up and fit in such a small space.
  4. 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.
  5. 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.
  6. 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.
  7. Like Kamov and Mil had a baby...wait a sec, why is the Mk3 Cockpit white?
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. It's not just you. Photobucket has been experiencing website disruption the past week or so.
  14. 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.