• Content Count

  • Joined

  • Last visited

Community Reputation

169 Excellent

1 Follower

About NoobTool

  • Rank
    Noob... also kind of a Tool

Recent Profile Visitors

1,477 profile views
  1. NoobTool

    New Editor Tool

    I think you've misunderstood. I'm suggesting that you would attach the part to the fuselage simply for the ease of ensuring proper alignment. You would then offset to the desired position on the wing, then using the change parent tool, change the parent part to the desired wing piece while preserving the position and orientation of the engine. The engine would then no longer be attached to the fuselage, but to the wing. So it would flex with the wing, not the fuselage. Yes, I nearly always do this. There can still be issues when removing and re-attaching these wings though, especially when that first part is rotated along multiple axes. The game often attempts to save the orientation, but I've found that it isn't always accurate. There have been many times when I re-attach wings and have trouble matching the aerodynamic performance of the previous configuration. Perhaps, but then I'd be asking for two new tools instead of one. There would also be other applications for the adoption tool. I tend to build large aircraft/spaceplanes. I've found that part placement can make a big difference in the structural integrity of the craft. I often find myself reassembling various structures in different configurations of part attachments and autostruts in an attempt to maximize structural integrity. The ability to change the parent part while preserving the position and orientation of the part would streamline this process a lot. I recognize that my experience or play style might not be representative of a majority of KSP's player-base, but I still think many or even most players would find some use for the tool.
  2. NoobTool

    New Editor Tool

    I realize that there might be some challenges to overcome in implementing such a tool, and it may turn out to be more of a hassle than it's worth, but the end result can be achieved manually now. Changing the parent part is no different from removing the part and placing it somewhere else. All of the subordinate parts will still be subordinate to the part in question, which will now be subordinate to a different part. I'm not suggesting that this would be used for node-snapped parts, those are simple enough to replace. Right this can be done, the new tool wouldn't be adding capabilities here, only simplifying the process. I wasn't necessarily talking about node-snapped parts. Those are easy enough to replace, and you wouldn't want to change the parent part for those anyway. I was more talking about radially placed parts: landing gear, wings (which again, might be rotated on multiple axes), rcs, solar panels, etc. Re-parenting those parts would be much simpler and quicker than removing, replacing, re-orienting, and re-positioning each individual part, even if you re-parented the part back to its original placement afterward. Holding shift while using the offset tool allows you to increase the offset limitations. But there are reasons to want the part attached to the wing in this scenario. Wings flex in flight, and if the engine/nacelle is attached to the fuselage rather than the wing, the wing can flex through the engine. Moving the engine to the wing also reduces the stresses on the attachment point of the wing during flight, since less of the mass is attached directly to the fuselage. Thanks for taking the time to reply. I appreciate the feedback.
  3. I have an idea for a new tool for the VAB/SPH editors. We'll call it the adoption tool. The adoption tool would allow you to change a selected part's parent part without changing that part's position or orientation relative to the root part or the rest of the craft. The tool would work similarly to the root tool. After selecting the adoption tool tooltip, you would select the desired part on your craft. The part would then be highlighted, along with it's parent part (perhaps the parent part would be highlighted a different color). You would then change the parent part by selecting the new parent part. There are any number of scenarios where such a tool would be useful. I'll list a couple of examples that spring to mind. When building aircraft whose wings are assembled from multiple wing segments, those segments are often rotated on multiple axes. These parts might also be rotated in order to impart angle of incidence to the wing. When attaching engines, or multi-engine nacelles to these parts, it can be difficult to correctly orient them parallel to the fuselage. The adoption tool would allow you to place them on the fuselage, using angle snap rotation and shift+offset to orient and position them, then change the parent part to the appropriate wing part. If you wish to replace a part on a craft, say to change a fuel tank from LF to LF+O or visa versa, you often find that several parts are attached to the part to be replaced. These attached parts might also be rotated and offset to their desired position. Using the adoption tool, you could simply change the parent part for all of these attached parts, instead of having to replace, re-orient, and re-position each part individually. Feel free to list other scenarios where such a tool would be useful, or point me to mods where such a tool exists, or tell me I'm an idiot and that such a tool would be superfluous.
  4. NoobTool

    Strategic Bomber Procurement (Reboot!)

    So, I went to fit one of my existing craft with a bomb load to participate in this challenge and discovered that there is an occlusion issue with my cargo bays. I'm not sure why, but my payloads are not shielded from the airstream. I'm using Mk3 cargo bays (a lot of them). I went back and checked some of the other payloads I've carried on the craft and discovered that they hadn't been occluded either. Apparently it wasn't a major issue until I tried fitting hundreds of separate tanks inside. I was hoping some helpful soul here might have some insight into what might be causing this issue, and how it might be addressed. I'll include a download link to a similar craft that's experiencing the same issue in case anyone wants to take a look.
  5. NoobTool

    Strategic Bomber Procurement (Reboot!)

    Question: Are the career switch points only applied once? Or are they applied per craft launched from the parent craft?
  6. Thanks for the feedback! It means a lot coming from you. My mind is routinely blown by your creations. I try to make my helicopters reliable and reusable. I have intentions of taking some to Laythe to help with construction and transport of surface modules for a large scale colonization project, but I keep running into snags. I was pretty disgusted when 1.4 broke my helicopters and I only recently got around to fixing them. The new bearings work great. The Kernuck Redux flies much better than the original ever did. In case you're interested in trying them: Oh yeah, reverse thrust works best if you have enough altitude for a shallow(ish) dive. Still best to disengage before too long or she'll overflare and pendulum out of control.
  7. Thanks for this. I'll have to give that a try. The burn-time for nodes using NERV's are pretty inaccurate atm anyway (or at least, they have been for me).
  8. I haven't yet tested various throttle settings, but the performance drops happen whether throttle is set to 0, or 100%. Even with throttle at 0, simply activating the NERV's with action groups causes the performance to drop, deactivating them remedies it. I also noticed something interesting on a recent ascent. NERV's are the last engine type to shutdown before apoapsis on the craft in question, so were the only engines active (throttle at 0). I set a maneuver node to circularize and the burn-time indicator displayed a figure that seemed reasonable. The craft was still in the atmosphere at the time. As soon as the craft reached 70km altitude, the burn-time indicator changed to N/A. The indicator didn't show any values thereafter even after burning w/ the NERV's again. Not sure what that means (maybe the burn-time indicator is checking for the presence of intake air for NERV's?), but I thought it might be useful information.
  9. To clarify, the performance issues I'm reporting are occurring with a relatively high-part-count craft. Also, they occur whether or not the extended burn-time indicator is turned on or off in the settings (I imagine the calculations still run whether it is turned on or not). Even though this is occurring with a somewhat high part count craft (~460 parts?), the difference is quite pronounced. As soon as NERV's are activated, the game begins to freeze for 1/3 of a second every second. As soon as the NERV's are deactivated, this behavior stops. This did not happen in 1.4.5.
  10. I've noticed a pretty substantial performance hit in a clean stock install. What's more, the performance changes seem related to how many/what type of engines are activated (NERV's seem to be the biggest offender). This, along with the fact that burn-time is being calculated incorrectly for NERV-powered craft, leads me to believe that the issue is related to the new extended burn-time calculator.
  11. NoobTool

    1.5.1 Hotfix

    This is great! Thanks to the Dev's for addressing this so quickly.
  12. It seems obvious from reading this thread (as well as from my own craft testing) that there exists an aero bug, or perhaps some inexplicable, intentional, and uncommunicated change to the aerodynamics. However, I haven't seen any of the Devs in this thread categorically acknowledge that such a bug does or does not exist, or that it is being addressed. I have seen a few "We're looking into it" posts, but without a referenced comment, it's hard to know what's being looked into. I don't expect it to get fixed overnight, but it would be nice to know that it's being addressed. I'm also having similar issues to those mentioned in previous comments where the burn time calculator isn't working properly for NERV powered craft. Also, I appreciate the time and effort that the Devs put into keeping my all-time favorite game fresh. Thanks to @Lupi for the analysis.
  13. "No, You're Compensating for something!!" Below is a brief compilation of perfectly practical and reasonably-sized spaceplanes for the pragmatic, utilitarian buyer. Czar Galactica Mk5 Itself the culmination of a design series whose every successive iteration represented a significant leap forward in terms of design and performance, the Mk5 set the standard for all subsequent spaceplanes to roll out of NoobTool design studios. Though not without it's shortcomings, the Czar Galactica Mk5 is a sober, practical, and able spaceplane, capable of modest payloads to LKO in the 500 ton range. With lighter payloads, she's more than able to reach interplanetary destinations especially if In-situ refueling is utilized. She does suffer from balance issues owing to the bulk of the engines being situated so far aft. Even with active management of CoM and CoL with fuel transfers and deployable control surfaces, atmospheric re-entries with low fuel/cargo loads require a relatively low AoA to avoid stalls and spins. Osiris Because her successor was released before testing was complete, Osiris was never released to the public (and not on Kerbalx). An early attempt to overcome the limitations of the Mk3 cargo bay, the Osiris is a competent lifter in her own right, roughly mirroring the maximum payload capacity of the Czar Galactica Mk5. She suffers from many of the same balance issues as the aforementioned craft, but still makes a great addition to any moderately-proportioned spaceplane fleet. While passenger space is practically nonexistent, she does come standard with a full complement of mining/refining gear in the ventral opening cargo bay. Oso Grande The spiritual successor to the Czar Galactica series, the Oso Grande alleviates many of the balance issues that design series suffered from by moving the primary lifting surfaces and the bulk of the engines closer to the center of mass. The improved aerodynamics have allowed for increased cargo volume and payload capacity. Loggerhead Building on lessons learned from the Oso Grande, the Loggerhead is again an attempt to rectify the balance issues suffered by her predecessor. The Loggerhead represents a significant improvement over the Osiris. Part placement was planned to allow for the fuel load to be easily reconfigured to meet specific mission requirements. All of the Mk3 fuel fuselages can be swapped for LF+O with only a few node snaps. This allows for longer-range interplanetary missions with lighter payloads, or payloads in the 600+ton range to LKO when fitted with more oxidizer, making the Loggerhead the heaviest lifter currently in the showroom. The payload adapter can also be modified to allow for more imaginative payloads.
  14. I tinkered with several rotor setups. Adding to the rotor diameter actually decreases the static lift. I've found that larger diameter rotors pair better with higher diameter blower plates (more torque). Since the engine needed to fit into a MK3 cargo bay, I was limited to 2.5m for the blower plates. I've tinkered a bit more with the rotors since I uploaded that craft (same parts, just played with the offsets/orientation). They're now pushing ~420kN of static lift a piece for around 840kN combined.
  15. I recently started playing KSP again after a long break. I was pretty bummed when 1.4 released and killed my favorite helicopters. I finally got around to fixing some of them. I also revived an old project that I had back-burnered. Sporting the new UberNoob turboprop engine, the BumbleBug may be a bit smaller than my other helicopters, but she's pretty spunky. She produces a bit over 800kN of static lift, and sports the same retractable grapple arm as the Wyvern. I built her originally just for something fun to putz about in, but it turns out she might be more useful for moving small payloads than the Wyvern. She's definitely more fun to fly. The Wyvern has her beat for top speed, but the BumbleBug is much more nimble.