Raptor9

Members
  • Content Count

    1,587
  • Joined

  • Last visited

Community Reputation

2,816 Excellent

About Raptor9

  • Rank
    Spacecraft & Rocket Dealer

Profile Information

  • Location Array
  • Interests Array

Recent Profile Visitors

18,097 profile views
  1. can i get duna mission package rocket

    1. Show previous comments  1 more
    2. ItsSnowyy

      ItsSnowyy

      may i know why you quit

    3. Raptor9
    4. mvb4298

      mvb4298

      which craft would you recommend for a duna mission??

  2. Best part of the video: Nate: "That thing's awesome, dude!" Nate's son: "...Crash it." I liked seeing all the dev team as regular people, drinking coffee trying to wake up, not wanting to deal with a commute, etc. A good reminder that the dev's are people like all of us, dealing with the same issues, and not a faceless logo.
  3. My open letter to the KSP community (developers and players): I will not take part in any boycott of any product based on conjecture and emotion in lieu of facts and reason. I will evaluate KSP 2 when it becomes available for purchase, and if I determine it is worth the money that it's being priced at, I will purchase it and play to my heart's content. If I determine KSP 2 is not something I wish to purchase, I will move on with my life. I will not criticize, degrade, attack, or demean anyone that reaches a different conclusion as to whether or not to purchase KSP 2, or their reasons for their decision.
  4. Personally, I don't feel like the amount that Squad listens to the community has waned over the years. The process by which they collect feedback, and their manner of communication to the community has evolved over time, but our feedback hasn't exactly fallen on deaf ears. Early on, like REALLY early on in the alpha days of KSP 1, the community was small and the dev team indeed had more direct interaction. But as the game grew in scope and depth, so did the KSP community, which led to community managers, less talking directly to the devs as the staff itself grew, etc. But if the last several years of updates are any indication, they ARE in fact listening to our feedback (not necessarily implementing everything we want obviously). For those of us that have been around KSP long enough, I can't tell you how many mods are no longer in use because of features or gameplay aspects Squad has added to just the base game for free; I'm not even talking about DLC's. On occasion, they even reversed plans when the community waved their hands in protest (a la the great "ROUND8" revolt of 2015). And let's not confuse "development disagreement" with "ignoring the community". A development team, even when faced with overwhelming support for the addition of a potential feature, may still disagree with what or how something will be implemented based on a variety of reasons, such as coding/engine/hardware performance limitations, development time/budget, priority over other features, bug fixes, or simply long-term direction for development of the game, etc. As for the interaction that Star Theory has or has not had with the KSP community, that's sort of open to interpretation. However, (again my opinion) I don't think we know enough about what, where, or how in regards to the state of KSP 2 development to make a determination on whether Star Theory is "involved enough" with the community. The fact they apparently talk to Squad on a regular basis, and their creative producer is a diehard KSP fan, along with other members of their staff, I'm not too worried. When it is permissible to talk to the community about KSP 2, I'm sure they will. I think it is quite unlikely that the value of that communication would be lost on them.
  5. Thanks for keeping us in the loop. Honestly, with the original release date seeming so soon, I was slightly concerned on the state of the game at release. This reaffirms my confidence that a solid product will be released when it is ready. Of course, that was all my own internal speculation, but we appreciate the update.
  6. I hope @SQUAD releases KSP 1 v2.0 the same day Star Theory releases KSP 2 v1.0. The forums will literally implode.
  7. We appreciate your continued dedication to the site @katateochi. Hope you recover from your injury soon if you haven't already.
  8. Flying, vertical takeoff hangers that can be landed in while in flight...you never cease to impress. Well done sir.
  9. Helo pilot. The closest I'll ever be to an engineer is the KSP VAB/SPH.
  10. Helicopters do in fact adjust their main rotor plane of rotation to generate rotational attitude changes. It just isn't very obvious unless you observe them on the ground with a crew that is deliberately moving the tip path plane without collective applied, which they won't do because there is no need for it and in some helicopters can cause damage to main rotor components. However, you can see the effect demonstrated at 5:23 in this video: https://www.youtube.com/watch?v=XNd5cF2DIgI. What is happening is in flight the main rotor thrust is being offset to one side, instead of remaining in line with the aircraft center-of-mass, which is lower in the fuselage. This "thrust" vector, called Total Aerodynamic Force in helicopter speak, is creating a rotation movement since the the vector is being generated from a location that is above the center-of-mass. It's like if you mounted an engine high above a plane's center-of-mass in the SPH, the plane will want to nose down because the thrust is not in line with the center-of-mass. When a helicopter rotor disk is tilted in a direction due to movement of the cyclic, the lift vector being generated by the main rotor is tilted away from straight vertical, and offset away from the center-of-mass below it, causing a rotational movement in roll or pitch, or both. In KSP, this is not simulated with the stock rotor mechanics, but instead relies on differential lift vectors. So it simulates the effect of the cyclic application, but does not recreate the real physics behind it. This creates a problem when creating a tandem helicopter like the CH-47 Chinook, since yaw control in that aircraft relies on differential cyclic tilting, as shown in the cited document. EDIT: I should clarify that cyclic blade feathering in rotor systems do create differential lift on one side of the rotor disc, but the differential lift is what tilts the rotor disk as a whole, which generates the offset lift vector, which in turn creates the rotational motion around the CoM. In KSP, the differential lift itself is what causes the rotational motion around the CoM. The lack of rotor disk tilting is what differentiates KSP rotor mechanics from real life. In the Chinook, the Roll and Collective are controlled similarly to conventional single-rotor helicopters, and because of this, Roll and Collective are easily simulated by the KSP rotor mechanics. Pitch, relying on differential collective, is also easily simulated by the KSP rotor mechanics. However, without an actual rotor disk tilting, Yaw cannot be accomplished through the standard KSP rotor control input method. So in effect, there is no direct swashplate movement to control the Chinook in the Pitch axis, since it relies on differential collective for Pitch control. However, through the Longitudinal Cyclic Trim (LCT), both rotor systems can be tilted forward (as described in the document) to increase overall speed without having to pitch the aircraft itself down as much as would be required to attain the same effect without it. So in effect you have both rotor systems tilting forward in unison, much like they tilt left or right in unison to generate roll. However in this case, this increases speed rather than pitch due to the layout of the tandem rotor systems.
  11. 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.
  12. 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.
  13. 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.
  14. 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.