StahnAileron

To be perfectly honest, I think @linuxgurugamer at this point needs a monument or something within KSP to honor his role of keeping fun and useful mods alive as they get abandoned by modders from lack of time, energy, or drive. (You have to admit it: the breaking changes that come with new KSP versions for some mods must frustrate those modders to no end.) Remember: half the fun in KSP comes from mods. It sometimes feels like he keeps half of those mods alive.

When I do bother with docking, RCS all the way. I once was mucking around with an Apollo-ish-style mission for the hell of it. I realized in orbit I done goofed and forgot the RCS. "No problem," I thought. "I just need to align prograde, decouple, thrust a bit, flip over to retrograde, and thrust again." Yeah, no. I forgot exactly what went wrong, but I wound up either colliding with the other craft or thrust wrong, so alignment went balls. This was with RemoteTech installed; neither craft had probe cores. (It was a fairly minimalist design; as I said, just goofing around.) I had to EVA a kerbal to the other craft first to stabilize it. Then tried to dock. Took longer than I cared for with too much effort compared to RCS-controlled approaches I've done before. (Ah! I think I recall the problem: the separator was in the way and I had to nudge it away. My attempt knocked the lander as well, screwing up the alignment.) Since I was just goofing off and really just testing the design, I reverted to the editor and made sure to add RCS for later runs. I don't think I ever did anything productive with that design afterwards. Just did it to do it; no real objective beyond that in mind. (I don't even remember if I bothered with a munar landing and rendezvous test.) The last set of docking I did was for my first real attempt at a true functional space station, something I always wanted to do by was too lazy to attempt (plus, 1.0.5 was not conducive to high part counts; I skipped 1.1). That was all RCS and MJ's Target Alignment Auto-pilot all the way. The station was built using NFT station parts and ports, so proper alignment was important, both for the aesthetics and for the ports to work. Frame-rate was meh too, so RCS control was kinda important for the precision. It was also needed for orienting the station and fine-tuning its orbit. It was a large and heavy stand-up guy, probably the biggest and largest I've actually designed and put up, either single-launched or assembled in-situ. The few SSTO spaceplanes I've designed and built for docking rely on RCS as well. The docking ports I use on them are rarely ever aligned with the main engines to even attempt engine-only docking. I do recall someone using a bunch of normal engines in each axis as RCS on a massive mothership he built. He had to; it turned WAY too sluggishly otherwise. (Never mind the frame-rate...) He had to map each set of engines to an action group. (I don't recall if AGX had a hand in this. I imagine it would considering the amount of functionality he had in that ship.)

In the very first or second challenge (I forgot which), I suggested they rename the thread series to something more appropriate because I knew the connotations the word "challenge" triggers in the KSP community. (Or anyone who understands competition. A challenge is a type of competition in the end.) I still find it a bit irksome, but it's minor since beyond the use of that word for whatever reason they have, they explain the actual point behind the "challenges": having fun in KSP. Sometimes just having someone else define a goal for you in a open-sandbox game like KSP makes it easier to have fun because you're not limited by what your mind can come up with. (Or lack of motivation; I get lazy after a while trying to achieve goals I set for myself in KSP.) I imagine the term is used to garner more attention to these threads. It may backfire if players associate a "SQUAD Challenge" as "meh" compare to their expectation when seeing the word, however. Even so, turn out for these seem to be decent, so it not a lost cause. If anything, it's a good way to get newer players involve with the community. There's a more typical challenge section here if players are up for it. Otherwise, just ignore these threads if the interest isn't there for you. Hell, it's what I've been doing. (I've been out of KSP for a couple of months now.)

That might be tough because (A) I'm still on 1.2, (B) run a mod-heavy installation, and (C) haven't really touched KSP much over the past 2-3 months. I could create a stock 1.2 install (I'm waiting on mods to update) to do it for you, however. I just don't recall what KSP had for stock part selection. It probably won't be as pretty(-ish; I'll admit the cockpit I used wasn't really befitting).

This is old, built in KSP v1.0.5: https://kerbalx.com/StahnAileron/Vector-Mk1A-BDA Not sure if it would be viable now (the main concern is the engine; the engine worked in 1.2, but that WALL of gimbals it uses for the animation...) Well, I guess another concern would be BDA itself since it's changed hands and I have no clue how the newer versions handle and what changed, if anything.

Assuming you mean purely stock. If you get into mods, there are some decent choices. I've built a couple of Mk2-based drone SSTO spaceplanes. One was just a basic crew shuttle. The other was just a glorified SCANsat "satellite" that was easier to retrieve once Kerbin was fully mapped. (I don't remember if the design was capable of Mun or Minmus orbits...) The Mk2 Expansion mod was the bulk of the extra parts needed to make them look nice, but I vaguely recall toying with Mk2 parts from OPT and QuizTech for the design.

First one: ActionGroupsExtended is the closest thing I can think of. It gives you up to 250 action groups to work with. You have the option of displaying the action groups with customized names. Clicking on them will trigger the group (because groups 11 and up do not have hotkeys assigned by default; you can assign them however.) You can even edit groups in-flight rather than just in the editor. Trajectories would be the one to look at for landing on atmospheric bodies as it takes into account drag, though it assumes a few things (mainly AoA; there are settings to adjust that and get a better prediction.) I don't know if either have been updates to 1.3 yet. (I wait after a major update to let modders get up to speed before I even think of updating myself.) The last set is harder. I don't know any mods that calculate trajectories like that from the launch pad. GravityTurn and MechJeb can get you into space easily enough, but direct interception/rendezvous launches I have yet to see a mod for. Mods like KER and MJ give you the info you need to figure this out yourself to some degree. (Mainly the phase angle.) Sub-orbital hop trajectory planning I haven't seen anyone attempt a mod for. (Has far as I can tell, most people just use a plane instead after a certain point on Kerbin and wing it on non-atmospheric bodies.)

Just to make sure I get this right from the info released so far: T2 has bought full right and ownership of Kerbal Space Program while SQUAD has been left alone. Essentially, SQUAD is now a "contract studio" working as a "third-party developer" on a property T2 now owns. For the time being, T2 is simply a publisher for KSP, backing SQUAD with resources for KSP development/support until such time that they (T2) can do something original with the IP. This is NOT just a simple licensing and publishing deal where T2 gets a cut of profits in exchange for support and promotion/advertising while SQUAD still have rights to and/or ownership of KSP. KSP was actually sold-off to T2 wholesale. (Kinda like how the Fallout games were completely sold-off to Bethesda by Interplay.) Next: any plans regarding T2 reps directly involved with KSP to join THIS forum at some point in the (near-ish?) future? The thing about indie game development is have direct access to the actual developers by the community. I think it might placate some of the community if they felt they had similar accessibility to the new party involved with KSP. If anything, it could be a gesture of goodwill and faith by T2 and acknowledging the established KSP community. (IMHO, half the enjoyment of KSP came from the community in the form of mods and Let's Play-ers.) If there's one thing a community like KSP dislikes, it's probably feeling like they/we are being ignored. (I think nearly everyone has had that feeling at one point or another with large companies in general, if not within gaming specifically.) I have a few other things I could say, but I think it's best if I just keep my mouth shut for now. In any case, cautious optimism during this "wait and see" period. (And let's admit it: at least it's not EA or Activision. Though on a half-joking note, I kinda wanted Elon Musk to buy KSP if it was gonna happen ^_~ Guess he was too busy investing in ACTUAL rockets and didn't have any funds to spare. His loss, I suppose. But just imagine if we had rocket scientists and software engineers available to KSP.)

If I recall, that part requires KAS as a dependency because it attaches to kerbals for usage. Installing KAS should let it show up. Without KAS (and probably KIS), it's pretty much a useless part, so no reason to have it otherwise. TL;DR - That part needs a dependency, KAS. Do you have that installed as well? (KIS is also recommended if you intend on actually using it. It's easier to added to inventories and using it directly rather than attaching it to the vessel and needing to un-attach and re-attach it.)

The "ore" bit is just the same abstraction as Liquid Fuel and Oxidizer: generics names applied to resources for the sake of simplicity. LF/O could be many things; it's not specified what exactly (seems many just assume RP-1 and LOX). "Ore", as much as a misnomer it can be (I associate it with metals first), is about as generic as you can get with mining. It's just one of those things I try not to think about too hard for a game like KSP. Besides, it's not like this is the first time something got implemented in a sorta half-assed way. Abstraction of terminology is not compared to the lack of meaningful or poorly implemented gameplay mechanics in career mode, IMHO. But that a whole other can of worms I won't get into here.

As noted, it's because the original ALG code was never ported to 1.1.x+. The current ALG is base on KF code (which I think ported over some ALG features to facilitate functionality), the KSPWheel API. However, it's just like any other set of parts: delete the parts you don't want (texture assets might be a bit harder; there are named ALG textures, but I don't know off-hand if there are any shared assets with other part) and keep the KSPWheel DLL. Granted, it's not as responsive in the editor as the original ALG (which I think was based off FireSpitter?), but I think a lot of the issues stems from the inherent changes made to KSP itself. (Or my install has too much crap in it *shrug*) Still, for someone to adopt ALG and split it off once more would mean porting the 1.0.5-era code and modify the models to work with current standards. Unless someone thinks they can (and will) do a better job than KF has so far, I believe players are just happy to even have it available and working now. (ALG was in limbo for a LONG time; I consider it an essential part mod.) If ALG didn't need model edits and was just pure coding issues, I'd BEG linuxgurugamer to adopt somehow, but that's not the case (and he has A LOT on his plate with KSP mods as it is anyway.)

I meant in how they're implemented in KSP. Though it was a gameplay compromise I can understand. Still, infinite torque (over-time) eliminates the need for RCS rotation controls in most cases. (Massive builds still need them to turn within a reasonable timeframe.) ISRU as implemented in KSP is fictional as well, but just like SAS/RWs, it's a gameplay compromise I'm totally fine with. At least ISRU has more things to balance it out. RWs just have output strength, EC use, and mass. The un-reality is the amounts you would expect to find and being able to fill a giant fuel tank. Water is a volatile in the environments of space, so it's actually hard to find in significant amounts across the board on planetary bodies. Granted, the ore concentration system sorta mimics that, but "ore" typically implies something else. Very generally speaking, you're not gonna find much water near the equator of most bodies. (Unless you have something like Earth/Kerbin/Laythe with temps and atmospheric pressure to help contain it.) Still, gameplay mechanics. As stated by the devs before, realism takes a backseat to fun and playability. There just needs to be a bit of justifiable logical sense.

I would argue SAS/Reaction Wheels . Those are pure magic in stock KSP . But that's beside the point. I have yet to get myself to bother with ISRU because there isn't much to do in the stock "end-game" once you know how to consistently get into space and deal with orbital mechanics as a beginner. Maybe once/if I get around to figuring out EPL or that other off-world construction mod... I gave up on KSP regarding "realism" long ago. (It's a game; you need to give up at some point.) As long as it's balanced for whatever gameplay the devs intend... *shrug*

That's just mass though. I was actually talking about physical dimensions. It's possible to have a VERY dense craft if one wants with clipping. (As already demonstrated with ROUND-8's.)

What's the upper-limit cut-off for the definition of "small"?

@AeroGav Is probably on to something regarding body-lift aspect of KSP. KSP models body lift for parts not explicitly defines as aero-lift parts (a.k.a. "wings"). For designs that rely heavily on aerodynamic characteristics beyond static lift in straight line flight (be it a dive, climb, or level flight), the basic aero indicator is wholly non-indicative of the inherent stability of the craft is certain flight regimes. I had this problem when I was building a shuttle design. It would flip the hell out if I exceeded a certain AoA on re-entry. Simply put, the MK3 body would start generating sufficient body lift that the CoL/CoP move forward ahead of the current CoM. It took waiting for dynamic pressure to get low enough for me to regain control, if at all. Judging from the screenshot of the design in the editor, this is probably the problem you're facing. The CoL indicator only accounts for the control surfaces. If you're going belly first with that design, you will be generating A LOT of body lift. Probably far more than what the control surfaces can compensate for. (Besides, the CoL indicator doesn't give you a real sense of magnitude either. Just because you have the CoL in a supposedly stable point doesn't mean its exerting STRONG stabilizing forces.) You have a lot of body area in front of the CoM and not as much behind (Looks about 3:2 ratio Front:Back). This is probably the cause of the instability. Test the design but with Aero Forces (F12) on so you can see what is generating lift and how much of it in the flight profile you want. This will inform you as to how to correct the CoL and resulting instability issue. This is how I figured out, on my own, what was screwing over my shuttle design. (Well, once I remembered body lift was a thing; I was mostly a MK2 user before that attempt at a more typical shuttle design.) This is part of the reason I have better appreciation for the MK2 design profile: it accounts for "body lift" in the editor already by design (in most cases). BTW, maybe it would be easier to build this in the SPH first than import to the VAB later for booster integration? I find the VAB horrible for aerodynamic-dependent designs. (It's not as intuitive to me since everything is rotated/aligned to the vertical by default.)

Is there an altitude restriction? Planes hit max speeds at different altitudes. I think you should standardized on an altitude or have it as a stat to report (X Speed @ Y Altitude). Or both: it would give everyone a reference point that can be compared across all craft submitted while letting players see peak performance at ideal conditions for each design. Also, level(-ish) flight only? Power diving? (True level flight is only doable with an autopilot... Or player with skills and/or a joystick that actually works in KSP...) I'm assuming an entry shouldn't ever leave the atmosphere? (Is there an upper altitude limit? There usually is with these plane-related challenges.) Any specific same settings as well? You mention no heating effects. (I'm assuming the very least no atmo heating since that creates an upper speed limit that's mostly out of the control of the players.) Not bashing the idea; just giving you points to think about and consider. Challenges tend to need clearly stated rules/conditions to level the playing field and all that. And so you spend more time judging entries and less time answering questions.

In addition to @DStaal's post, the other option is to subscribe/bookmark the forum thread for a mod here and check back every so often. This is VERY manual and all on the user, but is perhaps the most thorough method. (Pretty much any KSP mod will have a thread here for announcements and advertisement.) I have a large bookmark list of mods. Unfortunately, it was created during the 0.90/1.0.x days. Many of the threads are defunct (mod no longer supported or changed ownership with a new thread) or got nuked during that weird forum issue some time last year. Like I said, very manual, but I also rely on any mods that support KSP-AVC to let me know if I need to update. Between the two methods, I can keep up to date on mods. (I don't use CKAN for various reasons.)

I think you would need to completely rewrite how water is implemented. As far as I know, water is just a secondary planetary body superimposed on the primary body. (or something approximating that.) As this is a space-oriented game, I imagine this was done to save on processing power since real water effects tend to be somewhat processing intensive. (Both graphically and computationally if you want believable behavior.) Seeing KSP can choke on physics calculations for a large, complex vessel, I can only imagine the slideshow if that entire craft was under perpetual acceleration due to water waves. And that's on top of calculating the waves in the first place. And then you need to do the water calculation for a large area to boot. (About everything within the standard 2.5km or so physics range of the game.) I can't see this being simple or easy to do without a fundamental change to KSP. Water is not it's forte (for good reason: Kerbal Space Program.) I get that KSP is a fun physic sim sandbox for people, but it can only do so much given its intended purpose/design as a space sim. (Aircraft only got added since flying through air is something rockets need to do. "Flying" though water? Not so much. I think we're luck enough to even have functional buoyancy and therefore submarines and boats.) Not to shoot you down or "hate on you". It's just I don't think KSP as it currently stands is the right platform for what you're asking for. I think it would be more effort to shoehorn in real water effects into KSP than it would be to just make a Kerbal Marine Program from scratch with that as the basic premise and goal from the start.

RemoteTech and SCANsat integration would mimic the features requested. Not as explicit as stated, but close enough given KSP's capabilities and the current availability of plug-in mods. RT (mainly, its computer) would replicate the instruction transmission. SCANsat, as noted, would replicate the ground surveying. Something like CactEye could handle snapshot imagery. Anyway, I think even getting the assets into KSP might be a job. You'd need to import the original files (I'm guessing CAD rather than actual 3D models, though I'm sure converters exist) and probably add colliders at a minimum. I can only imagine adding animations and other module-specific requirements. Then there's texturing (I'm guessing some of this already exists judging from the render @technicalfool referenced.) After that is stat balancing and tech tree integration. Still, that satellite looks very nice. I would like to make something like that, unlike the logs I have to make now (partly due to limited part selection, partly due to RT not supporting dish augmentation like they do omnidirectional antennae.)

I believe this is a known problem and is being addressed in the next major release: It's mentioned in the second paragraph. (I swore I saw before/after image comparisons posted someplace...) EDIT - Ah, found it. It's in a post later in the thread: Anyway, as far as I know, it's something inherent to the rendering within KSP itself; so no, you can't do much other than turning off shadows (don't recall if you can even do that in KSP...) You have to live with it for now until the next update gets released.

The CPU itself won't cause KSP to crash (unless there's a CPU-specific bug; I'm not aware of any concerning KSP and AMD chips.) It's usually plug-in conflicts or memory issues. The only hardware-related crashes I know for KSP are due to KSP having memory-leaks/poor memory management, resulting in out-of-memory crashes. However, that's really all on KSP. (It's partially on the user with how many mods one uses and how you play the game... KSP shouldn't have been based on something like Unity, but that's water under the bridge at this point...) If I recall, I think scene changes and/or reverting still has memory leaks. (It has gotten better over time; I just don't recall if it's been completely eliminated.) I tend to test designs often, so this was a major cause of OoM crashes for me. I have had crashes when in the editor after extensive editing as well. Not quite sure if this is a memory- or game-related. (I have plenty of editor-mods to ease assembling vessels.) I wouldn't be surprised if the Undo function has a memory-leak/quirk. You'd really have to get some odd interactions in KSP going with stock KSP and mods for it to crash due to processing errors. (Or just a buggy plugin...) I've had those, but mod devs tend to be quick on game-breaking bugs in their mods. I've had several versions of particular mods doing dumb things in the background the mod dev forgot to remove for release. (I think one had massive log-spamming used during dev and testing but was left in by accident for release.)

Personally, I just ignore the monoliths. Only the green monoliths matter in career mode. Otherwise, the normal monoliths are just Easter Eggs you can look for if you want. They serve little purpose beyond that. Though I do admit that I find the SQUAD logo to be mildly irritating for some reason. (I don't hate monkeys, but I'm not a fan of them, either.)

I had a similar opinion of the gears in 1.2. (I skipped 1.1.) For 1.2, the best thing I could do for the stock gears was crank the spring and dampener settings to max. It made the wheels "stiffer". I could still bounce off the runway on a hard landing, but it wasn't exacerbated (as badly) by the recoil from the gears. It was my workaround until Adjustable Landing Gears was picked up by the KerbalFoundries team/dev. ALG is a bit quirky now with it using KF's plugin (KSPWheel), but it's VERY nice to have flush-fitting gears that look nice and have motors. (My only complaint would be the max weight limits.) I haven't touched the stock gears again since KF picked up ALG. 1.0.5 was fun while it lasted, but the performance and stability enhancement in 1.2 (plus mods leaving 1.0.x behind) don't really make it worthwhile to play 1.0.5 unless you have a vested interest/investment in it (like a very advanced career save or a MUST-HAVE mod for you that hasn't been updated for newer version.) Not to mention official 64-bit support. (1.0.5 required a workaround for that. Heavily modded installs would crash regularly and easily otherwise with the horrible memory leaks.)

With the right mods, staying on Kerbin is actually enjoyable. Scatterer makes daytime, dawn, and dusk on Kerbin quite gorgeous. I'd play with Eve, but I would need to figure out how to turn off the faux-city effects below certain altitudes (or barring that, completely). It's immersion-breaking when up-close to one of those areas. In my old 1.0.5 career game, I would just design VTOL science planes and do the science collection missions around Kerbin. I used KerbinSide to make it less tedious. (Having more than one location to launch from and land at.) I was only in space long enough to set up ScanSATs and RT constellations for the local Kerbin system (Kerbin, Mun, Minmus). So yeah, KSP is a bit more Kerbal Flight Simulator for me. There's something about just cruising around Kerbin and staying under 30km. (At least with some visual mods.) If anything, I have yet to really leave the Kerbin area and go interplanetary. In that old 1.0.5 career with KerbinSide, I did launch a solar survey probe (DMagic Orbital Science survey mission). That's about as far as I got. My end goal in KSP is really to just colonize the Mun and Minmus. (I advocate lunar colonization in real life. IMHO, Mars is overdoing it in the near-term.) Lack of endgame gameplay mechanics has deterred me from really doing it. If I ever get my head wrapped around EPL, maybe then. The last thing I did that I wanted to do but didn't get around to it was finally build a space station. This was mainly because 1.2.x could handle high part counts better than 1.0.5 ever could.