Jump to content

Raptor9

Members
  • Posts

    1,599
  • Joined

Everything posted by Raptor9

  1. @Mr.Gentlespy and @tremonthedgehog, please stop distributing my artwork without my consent. That is my personal artwork that I spent a lot of time creating for my own presentation of the craft files, and exploiting it in such a manner is in very bad taste.
  2. @tremonthedgehog, the images that I used to present my craft is artwork that I personally created. I originally posted my craft files on KerbalX to share with others, but the artwork itself is my work and was part of my personal style of presentation separate from the actual craft files. I chose to remove my downloads from KerbalX and the artwork from my forum thread for my own personal reasons; and I find it very offensive that others are intending to exploit and re-post such artwork without my consent.
  3. I don't think it comes down to an all or nothing choice between the current KSP2 implementation and the KSP1 implementation. It's not a "this or that" choice, it's a feedback thread to try to find solutions that work for as many players as possible. It would be a much greater experience in the long run to take what was proven to work in KSP1 and merge it with the advancements made within KSP2; especially if they were coupled with some potential user-configurable settings. As it stands, the current KSP2 view controls are way too coarse and make it quite cumbersome and difficult to position the camera into very specific orientations and locations to properly judge precise part placement and rotation on a craft. If a player is content with simply snapping parts together, then the camera controls in their current form are sufficient. However, if a player is into building craft with very precise part placements for specific designs or replicas, the current camera controls in KSP2 are too cumbersome and coarse to provide the level of precision and orientation that is needed for such gameplay.
  4. But that doesn't make a difference. That's just saying aim for a different target altogether. The point is that if you move the mouse to the far left side, you'll simply drop the part into the VAB again because of the gap between the edge of the screen and the parts palette. And depending on what parts category you have displayed, in some cases the entire parts palette saturated with parts from top to bottom so now you may inadvertently select a different part, and then you need to delete that one. Are there alternatives? Of course. But the point is to increase efficiency where possible, not workarounds. However, that was just an example to illustrate my point of how a lot of small changes to the UI accumulate to reduce efficiency in several areas of gameplay and UI/UX, it's not a prime issue of the UI that I think needs addressed.
  5. It's not so much the camera controls I have a problem with, I can get used to those. It's the UI elements themselves and how you interact with them. For example, the Parts Action Window in KSP1 was a much more efficient method of presenting and interacting with part-specific data than the monolithic Parts Manager they have now. When I right-click on a part, I want to interact with that part only. Presenting information about all parts on the entire craft is inefficient in that it forces me to concentrate more on interacting with the Parts Manager itself to process all of the data that I don't want at that moment, instead of focusing on just the data I am requesting at that moment in time. This will be especially important when designing large interstellar ships in the future. Another example is how there is now a gap between the parts palette and the edge of the screen. In KSP1, if I didn't like a part or wanted to get rid of several parts quickly, I could simply click on them and jerk my mouse to the left side of the screen. I didn't even have to look at where the mouse was when I left-clicked to throw the part away because I knew my mouse was up against the far left side of my screen, and anywhere along the left side would allow me to left-click again to drop the part to delete it. Now, I have to pause what I am doing and place the unwanted parts in a very narrow target area in the bottom left part of the screen to delete them. This may sound like an inconsequential issue, with a difference of fractions of a second, but its the cumulative time spent needed to hit a smaller target each time I remove a part and the attention constantly being pulled away from my craft to focus specifically on the action of deleting the part. This is quite cumbersome over several hours of gameplay.
  6. The current VAB controls are a significant step back in my opinion. There are certainly some new features that I like that leverage some of the new tools in the VAB, and there are some occasional limitations and bugs in KSP1's VAB/SPH even to this day, but overall this is an instance of why they say "If it isn't broke, don't fix it." Before anyone says this is just people set in their ways and resistant to change or progress, this isn't the case. The VAB experience of the early KSP1 versions in 2011-2014 timeframes was quite raw, just how it is now in KSP2. KSP2 certainly has more tools compared to the early access version of KSP1, but the overall VAB experience in KSP1 was very well tuned after years and years of player feedback into how they felt KSP1's VAB/SPH experiences could be improved. It seems that there was a lot of institutional knowledge as to why the KSP1 VAB experience was the way it was, that was either lost or disregarded in an effort to rebuild the experience from scratch. As a result, we are back to square one and the developers and community are going to have to rediscover why the solutions fielded in KSP1 were implemented in the first place.
  7. I agree. This was my main method of doing fine-tuned adjustments. With individual clicks of the scroll wheel.
  8. I agree with the OP. Having the Parts Manager is definitely a step up if you have a large complex craft with many parts behind fairings, structural pieces, cargo bays, etc. However, the old system was much more efficient for craft building in that it only presented the information that you wanted at that moment, but still allowed you to pin the information to keep it open so you could have several open at once. I think the OPs suggestion of having the Parts Manager as an optional pop-up window via a widget icon at the bottom would be preferable, but the legacy KSP1 system for when you right click directly on a part itself.
  9. @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.
  10. 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.
  11. 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.
  12. I foresee Kerbal street racers on the runway using those light strips.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. I hope @SQUAD releases KSP 1 v2.0 the same day Star Theory releases KSP 2 v1.0. The forums will literally implode.
  18. We appreciate your continued dedication to the site @katateochi. Hope you recover from your injury soon if you haven't already.
  19. Flying, vertical takeoff hangers that can be landed in while in flight...you never cease to impress. Well done sir.
  20. Helo pilot. The closest I'll ever be to an engineer is the KSP VAB/SPH.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
×
×
  • Create New...