swjr-swis

Making PAW toggles actionable from action groups -as a general rule- would be a great idea. It keeps coming up all the time, for all kinds of reasons, and they're all great. Alas, action groups action apparently have to be coded in individually, which is why we've ended up with only a completely arbitrary selection of them, and we only get a new one every now and then at random intervals (and when we do, we go all wild over getting them and wonder how we ever got by without).

Literally how some of the best inventions in human history have happened.

We sure like to think so, don't we. Has it though? How many times across our history have we essentially made this same statement, only to learn something new and bam, everything we thought we knew needs correction and we get a flurry of new inventions and applications based on our latest '99%' mark. There are still a good number of rather fundamental questions that we know we haven't figured out yet, and we have no clue how paradigm-breaking any of them may be.

My views on clipping are simple: I don't restrict myself in sandbox or career of any form of clipping (except the misleadingly named 'part clipping' option in the debug/cheat menu - I do try to avoid that, but only because it can lead to difficult to correct/diagnose issues with craft). First of all: building craft in KSP is already limited enough in many unnatural ways, leaving us lacking very basic and common engineering techniques. Apparently, despite clear visual evidence from the existing part set and the KSC buildings that kerbals have the capability and tools for molding and bending metal, riveting and soldering parts together, building intricate multi-functional parts, and fitting and integrating all kinds of resource containers into various kinds of volumes... none of those tools or techniques are available to us in the KSC. At least not in any apparent way. So how is it then that kerbals manage to mold and fit a complex pressurized cabin, monoprop tanks, RCS engines, sensors, antennae, wiring and computer equipment into a small conical shell? It took me some time to figure this one out, but once it dawned on me, it was stunningly obvious: the Pauli exclusion principle does not apply in kerbal physics. Kerbals do not need tools to integrate components into a single part... because matter can occupy the same space. I know, crazy right? But it's true! Try it! So why would a society limit themselves to rules that do not apply in their universe? Who in their right mind would stunt their creativity and engineering options by doing such a thing? I've never looked back after that epiphany. So these days, I do as follows: For forum challenges or requests, I abide by the specified challenge rules or the limitations imposed by the requester. For craft I share on KerbalX, I try to minimize clipping to the degree I feel may appeal to the widest audience, but I will still clip when I feel the design or performance goals call for it. For my own craft, even in career, there is no limitation at all. If factory default KSP physics allows it, I use it. Applied Engineering. Seriously though: We can't build custom-designed parts. We can't mold the aerodynamic shell. There's no built-in way to put the often underutilized volume of parts to good use. And we are severely punished by counter-intuitive physics that on one hand makes parts entirely unshielded to airflow regardless of placement, and on the other hand arbitrarily kills their functionality while inside enclosed spaces (even though they still work while phased inside 'solid' parts!). A ton of disadvantages, very few benefits. I think we're allowed a LOT of leeway in employing the few benefits we do get over regular physics to compensate.

This part may be relevant to your issue:

This could've been a scene from a NG/TDC documentary about large predatory robotic birds hunting for and scavenging smaller planes for parts, and it would still have made total sense.

It's a nice challenge to tackle, very worth the effort. If you want to shop around for some design ideas and concepts, there's a long-running thread in the challenge forum specifically about shuttle missions.

Well, shuttle-style vehicles are genuinely difficult to get right. Rockets and spaceplanes tend to be easy in comparison, because their thrust almost naturally aligns with the center of mass of the vehicle. With shuttles, you have to design it to specifically ensure the thrust aligns, and stays that way even while the fuel is being expended. If you're going into it eyes open good for you, but be aware that It's a very real challenge. If you're set on a vertical launch and are not particularly attached to a shuttle, I'd suggest a more traditional rocket would be easier. They used to when they were first instroduced, but they were changed to LF-only. Have been for a good while now.

Mun orbit was mentioned and I indeed overlooked that. Still, replace the single orange tank by a smaller set of LF tanks and a small orbital tug and I think it would still fit in the cargo bay... just one more launch, and then from LKO, have the tug do the Munar injection.

There's already a few challenges of the sort; not specifically requiring the scanner but seeing how low one can get. There's even a trick (exploit if you will) of a stock mechanic that will allow to go as far as slightly dipping into the surface. Search the forum for Kerbol Limbo.

Load to runway. Engage SAS, set it to Orbital mode, throttle to full, stage. Plane will take flight hands-free. At 500 m/s, switch to follow prograde. At 22km altitude, action group 1 to switch to closed cycle. Cut throttle when Ap is 72km. Set up the maneuver node and circularize. For the return, just fire retrograde at the right time (crater rim), point radial out until plane starts wanting to nose down, glide her over the mountains and onto the runway, at a stall speed of 25-30 m/s. Recover, load with a new payload, rinse and repeat. Short of letting a mod like MechJeb or kOS handle it, it hardly could be any easier.

If you have the tech, use a spaceplane that can return again to get most of the craft cost refunded. It also makes it easier to send up more than one tank if needed.

The tail is pushing up to keep the nose from pointing too much up. This is not negative lift, it's actual lift. Vector point up into the air, away from the ground.

And then there's guys like me that only knew the term 'stall' from fairs and markets. My thanks for the very clear explanation of the provenance and applicability of the term in this context. Considering lift and downforce and length of arm and vectorial math and all, yes, I agree that this is what we would expect. And it may well be exactly how it works in real life, I have no means to question that. What I've learned in KSP is that, aside from the stock 'CoL' indicator often being rather misleading, overall stability of the plane (as in the passive tendencies of the plane to stay more or less upright and pointing into the airflow towards the intended heading) tends to have more factors to it than just main wing lift and elevator deflection. I find that when optimizing for efficient flight and stability, the CoL ends up considerably more forward than the theory would have us expect, either almost right on top or even in front of the CoM. I observe that and acknowledge it, but I don't go and 'correct' it simply because of theory if the plane is actually more efficient and stable that way. I've also noticed that my tail elevators end up having to work against the natural tendency of my planes to want to climb. I don't know if that is considered 'bad design' in the theoretical sense, I just know it works. My planes are optimised to be at equilibrium and at minimal drag state at their cruising altitude and speed. At any point before that in the flight envelope, while applying full power, they want to climb, and the tail elevator is having to inhibit/control that natural tendency to climb, which they do by creating lift/upforce to force the nose a bit down from where it wants to be. By the time the plane gets to cruising altitude, keeping the plane level needs no elevator input anymore and it's at neutral, which is also the least drag and thus the most efficient at the point of the flight envelope where that is the most important element. Result = plane goes far on very little fuel. If someone goes ahead and tells me that all this is a sign of bad engineering according to theory, I won't even argue. It might be. I just know in KSP it works. And it's the result I'm after. If I see someone asking 'how do I design a KSP plane to go far and use less fuel', my answer is going to be based on what I've learned, even if that deviates from what is generally considered how it should be. This here I guess is where our designs differ. My planes want to go up from the moment I start applying power on the tarmac. I have to control their tendency to climb. I don't have to raise my nose to make the wings gain incidence, they already have incidence to start with, which means that airflow into prograde already generates lift. My elevators don't fight a tendency to drop the nose... they inhibit the rate of climb. Up to getting to cruising altitude, where they are at their neutral and least-drag configuration.

Personally, I see better results from instructing people like upcoming experts rather than like momentary newbies. The 'newbie' part tends to wear off when they try to apply the principles learned, maybe with a bit of trial and error and some faster than others. The OP indicates they already know the basics of plane design, and their choice of unlocked tech evidences awareness of what parts a plane needs. I feel it's safe to give the benefit of the doubt and expect them to be able to take off the training wheels. If not, they've already shown willingness to ask further questions and we can pick up from there. To be clear: I'm not an aeronautical engineer. I have no training or experience in such matters. When I say traditional, what I mean is 'what I see used in most flying apparatuses'. I would literally use the word 'apparatuses' in that context. In fact, when I use any terms that might remotely sound like actual science or engineering, assume I am merely reproducing the words in roughly the same order as I have encountered them in aimless Wikipedia clicking or TV/movie watching. I won't be offended, honest - I'm quite aware of my lack of formal training in the matter. What I am is a KSP addict, and what I do have is a wee bit of experience with how KSP physics works and how to clunk parts together to achieve certain effects in the game. Clunking btw is the appropriate technical term. That said, and at the risk of overstepping the boundaries of my knowledge, I feel the need to question. Are you absolutely certain about the way 'passive stall recovery' is supposed to work? As I understand it, stalling happens when either the airspeed drops or the main lift surfaces are over-pitched, to the point where either or both cause the airflow around the airfoil to no longer provide enough lift. Designing a plane so the passive reaction to a stall is to pitch up even more (pushing down on the tail will point the nose up, after all) seems extremely counterproductive in that situation, making the stall worse. The normal stall recovery reaction should be to pitch down to regain airspeed again and/or point back into the airflow. Pitching the nose down, for a traditional tail design, requires the control surface to push the tail up, which means adding lift, not downforce.

You are usually a good source of information, so it pains me to have to strongly disagree with your -at first glance very plausible-sounding, but incorrect- explanation. My 'inefficient' tail designs certainly do not work like that, nor suffer from the drawbacks you describe, and offer all the same benefits you sum up. If you can give me an example of a tail design that behaves the way you describe, I think I would be able to point out how to correct it, without requiring to change to a canard design. In any case, it is somewhat ironic you say my design would be inefficient of all things, when you suggest needing 800-1200 units of LF to get around Kerbin and back with your canard proposal, where I just mentioned that a plane of my design would require 200-300 units. That's a factor 4 difference, and not quite in your favour. I'm feeling the tingle of a challenge here. Care to build a canard plane limited by OP's restrictions, and pit it against one of my inefficient tail designs? Full circumnavigation of Kerbin, parts limited to OP's tech tree. "I have the greatest enthusiasm and confidence in the mission, Dave." - famous last words

That would explain our different perception - I don't watch or follow streams. My idea of 'The Community' is this forum and the KerbalX site. My suggestion: don't let general perceptions or 'hate' bother you. Do what works, and let the results count.

https://bugs.kerbalspaceprogram.com/issues/9557 https://bugs.kerbalspaceprogram.com/issues/13413 Very old problem which is being attributed to the Unity/PhysX engine. On the other hand some mods appear to find ways to work around it to more or less degree (and so far none of them apply to kerbals - yet):

Really? I see them constantly used/suggested, which gives me quite the opposite impression.

The unlocked tech level you show is not an obstacle, you have all the parts you may need to achieve this, and you don't need any mods - pure stock will do. You don't mention your facility levels, but it's quite possible even staying within the 30 part limit (and you shouldn't even come close to the 18t limit). The limited part selection means you'll have a few less than ideal parts and it may not be 'pretty', but it can still be done. 3-4 Junos can do it, or a single Wheesley - pick whatever you prefer or what you are more familiar with. The Wheesley will generally require less parts in total, but it's possible with Junos too. Regardless of your choice, I would suggest using the Engine Nacelle as intake. You can place it inline on the main body with fore and aft nodes closed and it will still provide ample air to any engine setup you pick in a very drag-minimal way. As a bonus, it adds 150 units of LF which is at least half of what you should need. Keep the plane as light as you can for what you need to do, as the landing gear you have are easily the most 'risky' parts. I would suggest using the Mk1 Inline Cockpit either in front or after the engine nacelle (depending on how you balance the fuel), it's the best compromise between weight and drag. A service bay to place your science instrument(s) in is advisable. The goal is minimal drag so your plane can cruise supersonic, which will help it get high and save fuel on the long trip. It's quite possible to get Mach 1.7 with the Junos or Mach 1.8 with the Wheesley with what you have at your disposal. Give it enough main wing area so it can cruise between 13-14km, but don't go overboard as wing area also adds drag that will fight the plane in the transsonic regime; if you stay around 5-6 tonnes, about 1-1.5 lift area per wing should be good. The somewhat prettier Swept Wing can be used, but be aware they offer a less than optimal lift to weight ratio. If you pick the Wheesley, keep in mind that its thrust fades very quickly once over 14km, so its optimal cruising altitude is likely to be slightly below that. The placement of the wings, contrary to what some believe, is completely irrelevant - the KSP physics model quite simply does not care. So place them in whatever manner that will make it easier to get CoL as close to CoM as possible. What is VERY important though: use the rotate gizmo to give the main wings a bit of Angle of Attack - iow the leading edge should be slightly higher than the trailing one. This way your wings will generate lift for minimal added drag, while the plane's body can stay pointed prograde for a LOT less drag. When the rotate gizmo is set to angle snap, a single fine tick will add 5 degrees, which as a general rule of thumb tends to be close enough to optimal to not need to bother with any finer adjustment. In contrast, I suggest to keep your control surfaces perfectly horizontal, even the ones on the wings (counter-rotate them after adding the wing incidence). If you pick the right wing parts, you won't need the relatively small additional lift of the control surfaces anyway, but it will help minimize drag and will make balancing CoL easier. I don't know why you're being told to use canards - there's no need to, and a more traditional design tends to be easier/more intuitive to new players, so my advice would be to ignore that. Regular wing with a traditional tail is easily possible with what you have. I would suggest to dial down the authority limiter of all control surfaces. If you get CoL nicely aligned with CoM, this tiny size of plane doesn't need much and it will make flight and landing smoother and easier to control. Do all the above, and you should be able to make do with 200-300 units of LF. That should be enough for a complete circumnavigation if need be, which at Mach 1.7-1.8 should take a bit over 2 hours game time. Staying within your restrictions, I was able to make a 3x Juno, 29 part, 5t plane, and one with 1x Wheesley, 25 parts, 5.5t; both can do what you need. You only asked for advice so I won't post them yet, but if you run into a dead end and wish for some examples, ask and I can post you a download link.

I don't think I had my coffee yet when I typed this. Cycle back is not Backspace by default.... it's Shift-Tab. Which still explains why it's one of the first key assignments changed, as trying to cycle back inevitably (Shift!) throttles up your engines if you haven't deactivated or locked them, and the next moment you're wondering why your orbit is changing.

Probably because the factory-default key for that is 'Backspace', which will also trigger whatever actions you placed in the Abort action group.

Visible light and near infrared/UV is only a tiny part of the spectrum we can and do use to observe the universe through what we colloquially call telescopes. Microwave, radio receivers, x-ray observatories, gravitational wave sensors. Many of those do not use what you would consider 'optics', certainly not in the conventional way.

I was thinking well beyond optics to be honest. Optics covers just a tiny subset of the spectrum used for space observation. But they're still single contained parts with all functionality built in. Add the part or not, then activate and collect the result, basically. Not separate components (sensors, casings, computing hardware, etc) that can be stuck together in self-designed ways, which is what you suggest for telescopics. Would. Still think it would be enough scope for its own game/sim. I'd likely be in for it.