swjr-swis

I did a bit of editing on the Volta VIII Spear II. It probably still needs some finetuning, but let me know what you think so far. https://www.dropbox.com/s/08iakxlna5y98b1/Volta VIII - Spear IIa.craft?dl=0 edit 1: I've added a second version, with improved maneuverability. This version is fully fueled with 880 units of LF and so a bit heavier than the Volta I, but I think you'll find it doesn't lose much in maneuverability because of it. Even so, you can empty it down to 180 units like the Volta I in which case it is actually lighter, with even better maneuverability. https://www.dropbox.com/s/hsxlm8knp5btew4/Volta VIII - Spear IIb.craft?dl=0 Very fun plane you got yourself here, I enjoyed flying this. edit 2: Aaaand a third version. Crazy maneuverable now, even when fully fueled. Man is this thing fun to fly. https://www.dropbox.com/s/qd04m7sgpazzczg/Volta VIII - Spear IIc.craft?dl=0

Start with this. Radiators may look like they should be pretty aerodynamic, but they work like extended airbrakes when it comes to KSP stock drag.

I like it. Except it still requires at least one control input after leaving the pad: changing SAS to follow target (which can only be done once the craft has lifted off and velocity is >1.0m/s).

No worries, I answered the challenge just to see what I could do within the given constraints, it was an interesting problem and quite relevant to me right now since I'm trying to get myself motivated to rebuild several of my older craft. My 'disappointment' stemmed just from being left wondering if I had met that particular part of your challenge. All's well. The tank size difference set me to thinking though: the stock craft should probably be rebuilt entirely from scratch first, and move from there, to prevent any import artifacts from obscuring the real issues. Which also tells me reworking my older craft may be a lot more work than I care for, if I'm going to have to watch for clues of import errors that the game doesn't warn us about.

I was mostly trying to keep the original appearance while still getting it to orbit and back with as much functionality as possible, since that seemed to be what you asked for specifically: Considering the wording of the challenge, I am a little disappointed that in your assessment the look wasn't factored at all. There are many many things I would do differently for a spaceplane, if trying to keep the appearance of the original had not been a criterium. Because it can in fact dock. LKO rendezvous and docking is almost the only thing it's good for. It retains the Jr docking port on the underside of the panel floor of the cargo bay, like the original. If you check the RCS ports, you'll notice they are set to work only for translation, leaving the reaction wheels to do what they do best. Reaching LKO with 120+ LF and 95 units of mono offers good margin for rendezvous and docking. True, and I might've looked at moving RCS into the cargo bay if it had been absolutely necessary. But the drag of the RCS ports does not prevent the craft from easily making LKO, and placing them outside provides the beneficial side-effect of pushing the heat bow slightly ahead of the cockpit, which means I can keep the original cockpit. The oxidizer space left on this version is just there because of the bicoupler; stock offers no LF-only alternative. Adding almost any oxidizer to that part -just to fuel vernors- quickly unbalances the plane when returning low or empty of LF causing it to spin, and requires rather extreme counter-measures that affect the original appearance more than I was aiming for. Additionally, I saved more mass removing the vernors and oxidizer than I added with the mono tank and RCS - in fact I can add another almost full tank of mono with what I saved. And since this craft gets nowhere near to leaving Kerbin SoI, any changes aimed at landings on other bodies is pointless. Btw, I noticed just now that by using the bicoupler that was in the original 1.0.5 craft, it kept its original tank sizes, which are significantly smaller than they are now (135/165 vs 180/220). Makes me wonder what other values and modules are wrongly translated when importing a craft from older to current versions...

I gave it a shot: https://www.dropbox.com/s/ix0sqitbcp1jkiz/Stearwing D45 fixed1.craft?dl=0 I tried first to keep it almost intact, but I found it horrible to fly, I really disliked the idea of dropping the jets (I may want those when coming back from orbit), the angled tail fins kept messing with the controls, the intakes kept knocking off parts when sliding off, all kinds of heat, drag and rigidity issues.... I quickly lost all incentive to try and keep that contraption. So, I rebuilt it almost from scratch and I did a lot of things different, but I think I managed to keep very close to the original appearance, and it's now LKO and reentry capable in 1.2.1, with ample RCS for docking maneuvres, and LF to spare to find a landing spot after reentry. Terrier+Whiplash replaced by Nerv+RAPIER, only the mk0 tanks drop now, less intakes placed on the Mk2 edges, doubled up on the wings and control surfaces to create enough lift, replaced the short LFO Mk2 tank by a long LF one, removed all oxidizer from the bicoupler, replaced all vernors and RCS by 3x 6-way linear ports, reordered all Mk2 parts (had to redo the entire cargo bay content to do so), added Mk2 drone core, repositioned gear, repositioned all wings and control surfaces, added a small RCS tank, and added some panels so the antenna, solar panels and docking port can be used without 'exposing' the passenger section to space. Ladder and front gear have been attached further back on the fuselage and then offset to the cockpit, to minimize the nr of parts that bleed heat to the cockpit; that and the front RCS ports allow the cockpit to survive ascent and reentry. I really just wanted to rip out the regular unfueled wing sections and use fueled Big-S rakes instead, much like what you did, but that changes the look a lot.

I have put a copy of the 1.0.5 version from a pure stock install on my dropbox: https://www.dropbox.com/s/w3byc0jlofmv5dc/Stearwing D45.craft?dl=0

One way I can reproduce it reliably is in a fresh new save, launch the standard first pod-on-a-flea straight up from the launch pad - leave out the parachute. Zoom in close and angle the camera just below the pod and watch it crash. If it doesn't happen automatically, you can also angle the camera slowly down after the crash. It appears to happen when the position of the camera clips into the terrain, or into a building/tower. Zoom level doesn't matter when you do it that way. I think the one particular case you show is when the crash is with high enough speed that the craft 'penetrated' a good bit into the terrain before the game registers the destruction, but the above gives the same effect.

The Spacecraft Exchange section of the forum is probably the better place to ask for this. This thread is mainly about the workings of the KerbalX website, not so much about the content shared on it. That said, you'll need to be a bit more specific. Other than stack diameter, do you have length/height limits? Power type requirements? Array strength? Is it to be an independent satellite, a module for a station, or maybe even to be part of a base? Do you have limits on part number? Stock, or can it include mods? You'll find people willing to share craft files or even make new ones on order, but without more than size 2 to go on, the variations possible are... endless. And they might still not fit what you need.

Yes. I keep having this, with my pure stock install. It seems to happen especially if I follow the crash into terrain with the camera zoomed in fairly close, or positioned at an angle where the camera ends up under the terrain when the crash happens (ie. when watching from an angle slightly under the craft). It does seem to happen more often around the KSC though, and come to think of it I do have other vessels nearby: a rover with some kerbals and a couple of flags.

Long before the days of artificial satellites, the Ancient Ones were already measuring latitudes and longitudes (to varying degrees of accuracy)...

You're gonna feel real silly when you load a craft in stock KSP, rightclick the probe core, and notice the 'KerbNet Access' button. Pro tip: it's also documented in the KSPedia (the icon of a white book with a blue rocket, under 'Communications network').

Seriously? Arsonide. I need some popcorn, so badly. You sound like you're so 'old' at KSP that you're not aware of the new 1.2 KerbNet features. These days, them young whippersnappers find anomalies by scanning the surface through KerbNet... the anomalies pop up as question marks. Altitude, scanner and probe cores govern the field of view, so one can even scan the entire broadside of a planet with the right choices.

Actually, at that distance, orbital velocity is still a screaming 1.5km/s, which means the fly-through happens at a 3000m/s speed difference. At that speed, good luck getting your video recording to catch even a single frame of the fly-through that can serve as clear proof. The only place where you can get single digit orbital speeds is close to the edge of Gilly SoI. As far out as the game will cheat, 111862m, it's 8.1m/s, which still means racing at each other at a double digit 16.2m/s, and a collision at that speed means getting deorbited or launched into an escape trajectory for the smaller craft. Pol and Minmus are only somewhat worse at 26-28m/s, everything else is three and four digits. Outer Kerbin orbits are 400-ish m/s. A mere fraction of a degree in deviation of inclination will still show as 0.0, but at those distances will put you off course tens of km.

I play stock, but I wholeheartedly support the request to enable us to change the autostrut setting on landing gear, legs and wheels. A fixed setting to 'heaviest part' becomes an issue in stock too, when docking two complex craft together and both have an identical 'heaviest part'. Knowing how it works one can game the system a bit, but in particular when docking things together, having the system try to be 'smart' will regularly be counterproductive. Let us decide, please.

RIC, any update on this status?

Agreed, I would very much like to be the one to decide when I can switch to another craft, thank you very much. It does seem like Unity could not be the restriction in this particular case. Whatever the technical reason for the 'cannot switch' thing, I think that many cases where this becomes a problem could be prevented by giving us a toggle to select whether we want 'switch to' to work for debris without control points yes/no. Default should be no, in which case the 'switch to next/previous' hot keys should only switch between craft that have kerbals, command pods/seats, and/or probe cores. In those few use cases when one needs/wants to be able to switch to uncontrollable debris, turn the toggle on. I have found it handy at times to be able to switch my camera to a piece of debris that had no control point whatsoever, but after having experienced a few times how switching to a completely useless piece of debris -and then not being allowed to switch back anymore- made me lose an entire ship, I would really prefer this to be something I only enable in those very few circumstances. Especially since we get absolutely no way of controlling/predicting what exactly the game will select next when we hit the 'switch to next/previous craft' hotkeys.

I was merely making an aesthetics suggestion with this: it visually smoothes the transition between the two engines, both in shape and texture. It's about the smoothest fit I've found. But you are correct about the drag penalty. For a craft design that easily breaks Mach 1 at sea level it'll hardly make a difference (top speed affected by perhaps 1-3%), but if it is struggling to break Mach 1, every bit of drag can make the difference. So one should weigh aesthetics against performance. Relevant tidbit: in 1.2.1, shock cones are again the least draggy nose and tail cones, by a noticeable margin. Very worth swapping a midge of fuel for the extra weight compared to other cones (and it also allows more compact stack designs).

I do want the 0.625m mini-nukes, if only for superefficient 0.625m probes and size0 spaceplanes. Yes please. But it is possible to use 1 RAPIER and 1 Nerv in a completely balanced way with all the thrust through the CoM: node-attach the RAPIER on the bottom node of the Nerv, then offset the RAPIER 5.5 clicks (or 11 in fine mode) into the Nerv. The exhaust of both engines will work perfectly without overheating either one. With a shock cone on the RAPIER end, rotated to face front and offset upward, it even forms a nice smooth transition between the Nerv chamber and the RAPIER front edge. Or placed behind a pre-cooler, the Nerv can be offset fully into the cooler to neatly align the RAPIER to it.

Protip: don't run KSP from the default Steam directory. Instead, copy the whole directory somewhere else and run it from there. KSP doesn't require Steam to be running, and it'll saveguard your game from forced patches/updates that may screw up your carefully modded install. It also allows you to keep an older version alongside the latest version pushed by Steam.

Confirmed, I had one appear in low Munar orbit in 1.2.0. I don't know if it's meant to happen or not. Was this in any release notes?

Well, if they do this, I hope they do it right. The two larger landing gear already turn off the light automatically when retracting, but then they do not automatically turn on the light again when extending. What happens then is that the landing gear light loses sync with the Light button/action and any lights that are toggled by it. So, if they are going to turn off lights when retracting, please also turn them back on when extending. Otherwise please stop adding half-implemented 'smart' automatic features.

This issue has been identified and reported several times, all requesting a way to stop the automatic switching: http://bugs.kerbalspaceprogram.com/issues/3980: Option to disable automatic switching of reference frame? http://bugs.kerbalspaceprogram.com/issues/5283: Reset (at least some) autopilots to basic SAS when navball switches modes http://bugs.kerbalspaceprogram.com/issues/6570: Navball should switch NOT switch to Target mode in proximity of a target if the target is landed or if SAS is in pro/retrograde tracking mode I particularly enjoyed the response on the first report I found, from 2 years ago: "A very good and well described suggestion. It has been forwarded for attention." Ah well... they'll get to it at some point. Right?

I'm a bit disappointed that he goes to the trouble of formulating a model for gravity that doesn't require dark matter, specifically with the intent of removing the need for it, which got me all excited... but then it still requires dark energy. It's all a lot of math wizardry to me, so 'disappointed' is very relative in this context; but still, I keep hoping someone will come up with a model that does not require any of the magicks to make the numbers work out.

Can the above explain why in some places the seams leave a gap big enough to move an entire craft or rover into the core of the planet/moon one is on? I've already found at least one such location, and reported it (report #13190).