Jump to content


  • Posts

  • Joined

Everything posted by Raptor9

  1. @Intercept Games, thank you for your time and efforts. The community appreciates your dedication to KSP, just as we appreciate all the Squad team members that came before.
  2. Thank you for the candid update Nate. Rome wasn't built in a day, so we appreciate the drive toward quality over expediency. Keep up the good work, we're all pulling for you.
  3. Great video; a wonderful summary of the past decade. Thank you to Felipe/HarvestR, all the members of Squad (past and present), and the community. It's been a great decade of Kerbal experiences, and I'm looking forward to another.
  4. I foresee Kerbal street racers on the runway using those light strips.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. I hope @SQUAD releases KSP 1 v2.0 the same day Star Theory releases KSP 2 v1.0. The forums will literally implode.
  10. We appreciate your continued dedication to the site @katateochi. Hope you recover from your injury soon if you haven't already.
  11. Flying, vertical takeoff hangers that can be landed in while in flight...you never cease to impress. Well done sir.
  12. Helo pilot. The closest I'll ever be to an engineer is the KSP VAB/SPH.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. Like Kamov and Mil had a baby...wait a sec, why is the Mk3 Cockpit white?
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  • Create New...