swjr-swis

Well, in space, anything not permanently bolted to your ship can double as propellant. No shame in a more down to earth (kerbin?) application of Newton's 3rd law when circumstances call for it.

I used the wrong word, didn't I? It's dihedral, sorry. I only play at being an aeronautical engineer.

Try SAS Prograde in ORBital mode (click on the top indicator of the navball). It works well when you fly strictly eastward. I use it routinely for quick testing/prototyping of planes - shows pretty quickly if you have the basic design parameters right and balanced. As far as I've been able to gather over the years, unexpected roll tendencies in an otherwise well-designed and balanced plane is the result of things that we can't really do much about: Differences in part placement/rotation of mirrored parts. KSP isn't particularly precise about this. Tiny fractions of degree differences of lift/drag inducing parts can add a technically and visually imperceptible but still significant torque, especially when approaching maximum dynamic pressure (you often notice it most when its trying to break the sound barrier). KSP's penchant for part asymmetry combined with an inconsistent default radial attachment/rotation position of parts, especially in mirrored symmetry. Drag cubes are not always 'mirror-symmetric', so this sometimes results in a slightly different drag/lift profile left and right of the craft even when you think you have identically mirrored sides, causing a tendency to roll. Autostrut recalculation while a plane is under physics stress causing parts to slightly move/rotate from where they should be. This is most noticeable in newer versions when a staging event happens, like when dropping fuel tanks mid-flight, and suddenly a perfectly stable plane will start rolling to one side strongly. But it also happens right on first load of a craft. You can tell that this is playing a part when you revert to launch a plane, without making any changes to it, and it displays different degrees of roll tendency every revert, sometimes even in opposite directions. KSP's SAS (not a role in your case, but still worth mentioning). Somewhere between 1.0 and 1.3.1, they did something with the SAS code that introduced a constant 'micro-flutter' to the SAS PID, which often adds a tiny unwanted attitude shift every second or so. Since none of the SAS modes do anything to keep a plane level, and yaw/pitch are usually strongly dampened by most planes' basic design, it tends to be most noticeable in the roll axis. You can add a bit of camber to wings to compensate for roll tendencies. I often end up adding a five degree (one fine snap) angle upward towards the wing tips. This adds a roll-countering difference in lift between wings when you're not flying exactly level, so it effectively becomes self-stabilizing (at the cost of a tiny loss of total lift capacity). It's more of a workaround than a solution, but it helps.

Maybe we should've started with some simpler entries. Not as many challenge participants left, it seems. I'd say yes. I misplaced the original, and ended up just slapping my own copy together. It's just the three parts and the flag placed the way you'd expect, there was nothing special about it. Yes too, I think. I see nothing in the rules prohibiting this, and the first 'Goal' states 'per Kubesat'. This is probably the winning strategy anyway. So go on and enter!

Would this be a valid entry: 3050 funds, 2.78 t, 18 parts (including the KubeSat) Pure stock, no DLC, no mods whatsoever Single-stage lifter Places KubeSat in LKO with minimal inclination (Pe 77 km, Ap 84 km, 0.5 degree INC) Lifter is fully recoverable (with the exception of the fairing and the heatshield used as separator)

KSP installed on an M2 SSD. KSP 1.3.1 pure stock: just under 20 secs to main menu. (compare the exact same install copied to and started from a 7200 rpm HDD: just under 42 secs to main menu) KSP 1.12.3 pure stock, no DLC: just under 25 secs to main menu. KSP 1.12.3 stock+DLC: just over 71 secs to main menu. (Interesting: I can start a stock+DLC 1.12.3, immediately start and stop 1.3.1 three times in a row... and still catch 1.12.3 cycling through its final loading screens. Why the disproportionate extra loading time for the DLC?) At the time of this test, I had open -aside from some background stuff- FireFox (30-ish tabs open), Steam, Skype, a handful of Explorer windows and three editors working on large text files. I've not noticed much difference even with heavier application loads, so I don't usually bother with closing stuff before launching KSP. I currently don't have any modded instances installed to compare. Although unless we test perfectly identical modsets, comparisons are next to meaningless.

The kerbal-breathable atmosphere, its mean temperature, the liquid water - it's all just a fortuitous side-effect of the Kraken creating its habitual planet-wide nesting place. Laythe is simply an unfinished nest. It's clearly following the same pattern as Kerbin, a much older and finished nest, but the process was interrupted by the Kraken's untimely demise.

Right-click on an appropriate part of the drone, preferably one along the center line and as far to the nose as possible. Select 'Aim camera', and zoom in extremely close. Then switch camera to 'locked'. If you picked the right part, you'll have little to nothing obstructing your view, and it'll be just like you're flying in FPV.

I don't see why not. Start a new save, go into the tracking Station, and wait for an asteroid to spawn. Cheat (Alt-F12) the asteroid to an orbit at the very edge of the solar system, where its orbital velocity essentially becomes zero. Build your course as one craft. You can keep the part nr. down by using hollow parts (3.25m or 5m decouplers come to mind), but this will put a limit to the size of your drone. Add a Jr docking port to the course craft as a place to add the drone later in a standard starting position. Save the course craft. Build your drone and save it. Make sure to build the drone so it can be attached to the course - add a docking port or simply leave one node open on the root part. Load the course again, and now load the drone but with 'Merge'. Attach drone to the starting point of the course. Launch the craft, and then cheat it to 'rendezvous' (Alt-F12 again) at a safe distance from the previously placed asteroid. Stage to release drone from course starting point. Race on. Or even simpler: use the same cheat menu to set gravity to zero, then you only need to build course and craft, spawn at the SPH, and run the race right there. You really should use a new save for this, as zero gravity will mess with any other craft in your system at the time. EDIT: I should've mentioned that you will likely need to either edit the game's settings file to allow much bigger offset limits, so you can pull the hoops apart from each other, or use a mod like editor extensions to remove those limits entirely.

And we all want to know how you got your hands on 1.12.9 ... 32-bit no less.

I'm glad you asked. [deep breath] The answer is simple: best-performing fastest-loading version of KSP by a long shot, and the only one that manages to stay alive, lagless, and glitchless, through hours (and day)-long sessions of constant scene changes (ie: iterative edits, tests, reverts, and back to editing of craft). Would I love to have some of the new gadgets and QoL stuff of later versions (like for this one plane, the separate deployment/authority sliders for control surfaces)? Of course. But aside from the aggravation from half-implemented half-bugged features, the game just simply won't run problem-free for the extended sessions and many scene changes I usually do. I downloaded 1.12.3 a week ago, and after the second time of having to restart it through just the very start of a build session (I started this plane in 1.12.3), I was too annoyed and just fired up 1.3.1 again. I had to rebuild the plane entirely from scratch, but boy was it worth it for my peace of mind. Side bonus: once finished, most 1.3.1 craft work and perform with only minimal adjusments in any of the later versions, including consoles and the many diverse modded installs in the wild, so for sharing compatibility to the broadest audience it's hard to beat. As far as I'm concerned, the question isn't why was I doing this in 1.3.1; the real question is why isn't everyone else. At least until we get a decently finished version... [/semi-unsolicited rant] You did ask. Back to doing some more River Runs in my plane. In 1.3.1. (spoiler: Val and Lisfel actually make it to the end) Craft file: https://kerbalx.com/swjr-swis/SWiS-Fury-MRAC

Today I continued work on a plane prototype I started, the SWiS Fury multi-role aircraft. Coming along nicely, still some final touches left. Sent Jeb and Bob off to do some testing and finetuning. Jeb decided on a River Run; Bob got a bit more than he bargained for. Screenshots of a slightly earlier prototype, showing the general design. Testing a different loadout.

Not to mention the increased risk to EVA astronauts, with an undetermined and non-trackable number of bullet-like objects flying by the station in the near future.

Val quantifiably wins from Jeb: she can take higher G's before passing out. Argument ended.

<looks around in puzzlement, then walks on muttering something about @Hotel26 playing tricks on him again>

I disapprove. Without individual bannermasts, how are we going distinguish House Krakendoor from the other houses?

What you see can be deceiving, because the KSP code doesn't check the visual model to decide on blocking. Also, some engines have an offset added to their exhaust effects. Visually, it can look like the exhaust is going right through another part, and yet to KSP, the engine is not considered 'blocked' and the other part is not getting heated. On top, there are different multipliers for the exhaust heat some engines produce, which makes them more/less likely to show heating effects. Unfortunately we've been given no way to see directly whether the thrust is considered blocked. The PAWs, even the debug windows, will all merrily continue to show full thrust being produced, even when you have none. Once upon a time it used to show in the logs when engines were heating another part, and that's how we could tell. I haven't seen such entries anymore in a long while though, I think they were removed; possibly it was part of the old engine module. Or it was some undocumented setting that I forgot along the way, I'm not sure. So, all we got to go on now is this: if you can notice the engine is producing thrust, ANY thrust, it's not blocked. The way it works, it's an all or nothing thing. Obviously this is per individual engine, so if you have more than one, you have to account for that. Note also that you do need to check this per exhaust nozzle, if the engine has multiple. Engines like the RAPIER, Mammoth, and others, will still produce thrust from the unobstructed nozzles, which will affect torque and total effective thrust produced.

Sorry... I posted this before my coffee, apparently. The first would reward NOT recovering parts. Obviously needed to be the other way around.

The question was about unselecting a target without going into orbital view. The method I mentioned works regardless if the target is visible or outside the 100km range. So it's useful to know.

Welcome to the forum! KSP doesn't offer us a way to map stock SAS pitch/yaw/roll inputs directly to servo/rotor controls. We can however trick KSP into achieving the same result you're after. We start by creating a 'bucket' attached to a probe core (and an extra reaction wheel), which will contain the payload/device that we want to point-and-track targets. This bucket we then suspend in a set of three rotating gimbals, using servos, and taking care to balance it such that the CoM of empty/full bucket always stays precisely in the intersection of the gimbal centers. We can't directly control the servos to do the steering, so we leave them unlocked and unmotorised. BUT: since we have suspended our device with three degrees of freedom, to the probe core it's as if it's floating freely in space, and its SAS can effortlessly point it at any target and keep tracking it. I created a craft as a proof of concept of this: https://kerbalx.com/swjr-swis/SAM1 Notes: There is a risk of 'gimbal lock', where axes can become aligned in the same plane, losing you one degree of freedom. In the time I've tested this, it's not happened to me. But it's possible. KSP's SAS code gets confused when switching away and back to the device, causing a deviation to build up from where it should be pointing. I haven't found a way to solve or prevent this. As requested.

The first question was about UNselecting a target. You can UNselect any target by double clicking the vessel you currently control.

I have to agree with @krautfed1 that part spamming is a bit of a spoiler with this scoring formula, because it works even without resorting to physicsless parts. A quick example of why can be seen in this album: https://imgur.com/a/04YKK3h The 0.625m separators are not physicsless, but they're an easy way to add to the part multiplier. Even only reaching 6182 m, it still propels the calculated score to 302918. A suggestion: since the intent of counting those parts is to reward recoverability, how about dividing parts launched by parts recovered? Making the formula: Altitude * (PL/PR + bonus). A suggestion: since the intent of counting those parts is to reward recoverability, how about dividing parts recovered by parts launched? Making the formula: Altitude * (PR/PL + bonus). Perhaps then the bonus for landing on VAB/tower can also be somewhat lowered. +1 for VAB, +2 for tower would be enough.

Ok, getting an entry into this one to give @Andetch something to compete with. The Mite-E uses 10 parts to reach 7338 m with a single kerbal, and lands all 10 parts intact on the KSC tower. Score: 7338 * (10 + 10 + 15) = 256830. A few more pics in the album: https://imgur.com/a/mr6pjLV

No. As long back as I remember using the resource panel for anything, really. Before posting that reply, I quickly tested it again in 1.3.1, so at least that long; but pretty sure it's been that way before that too.

Question: shouldn't this also be in the technical category? I get that you're focusing on aero and clipping, but if the Purist category is defined by what is 'physically possible', perhaps free-floating gear and payloads phasing through the hull are out of bounds for that.