swjr-swis

Using your mass that way implies homeworld-level gravity. In a command chair in orbit, or even in the tiny gravity of Minmus, this would not have the effect you expect.

Because the KSP code is Kerbals are very wasteful when using EVA prop for attitude corrections. The same reason I tweak RCS thrusters on smaller craft to only be used for translation, and let the reaction wheel take care of rotations - especially now we can set its authority.

Tease. Now I want.

Because we humans can get a multi-tonne ship into space by walking a ladder and bumping it with our heads, or flip it upside down by standing up while underneath it? I honestly don't think we need even more phantom forces to haunt our craft, at least not until Squad has fully figured out where the current ones come from and how to keep them under control. Also having a bit of trouble imagining how this would be implemented practically: we already need all the directional controls for the Kerbal's attitude and moving, we'd need a third hand and controller/key set for the torque we want them to impart at the same time? Can you explain how you envision this? I guess if a practical control method can be devised, it doesn't cost much dev effort, and it's made fully optional, I'd be curious to see what it adds to the experience.

Well, to be fair: 2km/s is really just under orbital speeds, he's not asking that much . I had already done an attempt with an earlier, less stripped variant (the b2; the entry I submitted above is the b3). The oxidizer tanks were still full and the RAPIERS were left to switch when out of air, and it dipped into space for a spell, but remained just short of going fully orbital. Then I noticed in the thread that you specifically asked for airbreathing only... so the space parts were further stripped and RAPIERs forced to stay in airbreathing mode, and the b3 was born. To be clear, the pictures here are not submitted as an entry, it needed the RAPIERs to switch after all; just to show that higher scoring entries are definitely still possible (notice the 61.7G), so get cracking:

Probably because we stubbornly keep looking at parts and game mechanics in completely unintended ways, and then KSP doesn't stop us at just thinking 'what if...' but let's us try it. I have a friend that makes a living revising and repairing antique and precision clockworks. I have this feeling I'm gonna have to buy him KSP and beg you for the craft file the moment I show him your video. Awesome work.

Ok, I dug out one of Jeb's experimental spaceplanes, stripped it of some non-essentials to get below the 75 part limit, removed the unrequired RCS and docking port, drained all the monoprop and oxidizer and half the LF to lighten the load... and got these results for a double engine, no cheat entry: Name: SpeedFighter-05 (yeah I'm horrible with names) Top speed: 1470.2m/s (1470.2 points) Highest G-force endured: 51.2G (51.2 points) Parts: 64 (no points deducted for staying under the limit) Cheats used: none (5 points) Total score: 1526.4 points. Link to album: http://imgur.com/a/X5Ipw Link to craft file: https://kerbalx.com/swjr-swis/SpeedFighter-05 Pics (see above album link for more):

A quick slap together of parts in 1.2.0.1532 show that judicious use of the new autostrut tweakable can successfully rigidize a 1km cargo beam, even once cheated into space. I imagine this will work for much larger too. Should be easier to find the limits of the system. Proof (pics, craft file and save file) in this Dropbox folder link.

I think you should be able to do this with stock parts. A combination of: Sepratrons to quickly push the cargo with a powered kick out of the bay and clear of the plane without damaging anything. Limit the solid fuel to the bare minimum so the kick is just the split second needed to push the cargo clear of the plane. Drogues/chutes that are staged at the same time. Since the sepratrons will only fire for a split second, they won't accelerate the cargo enough or burn long enough to damage the chutes. I did a delivery system like this as a 'bomb' bay of sorts for a challenge recently, where I needed a fully loaded radial ore tank to be forcefully kicked out of a 1.25m service bay. There was no need for chutes, since it was playing the role of a bomb, but it was actually more complicated than your use case, because the tanks only barely fit in that bay and got stuck, and they have a very unhelpful asymmetric center of mass location that made them tumble. So with balanced cargo in a roomier bay, this method should work even better. Feel free to test drive and/or reuse it for your purpose. The craft file that includes it: https://www.dropbox.com/s/qpjc4m43nn8yfiw/TwinJunoBomber-Mk3.craft?dl=0 Some pics showing it in action: https://www.dropbox.com/sh/82a7gw0w0ct8ks2/AAC4vl-poWwB81j4f8_zpPTfa?dl=0

So we're getting back the actual turbine part of the jet engines too...?

I perceive a possible danger from this desire to let Kerbals simulate things: what stops them from simulating a human world, and then making us take seat in their wobbly noodles of fiery destruction...?

What you are referring to is called 'symmetry' in the game. And yes, I agree: it would be nice if the game gave us the option to configure one part individually without affecting the rest of the symmetry group. Or at least break up the symmetry so once placed as one wishes, the configuration can be done individually. Ideally I would want 'symmetry groups' (handles the placement of parts) and 'configuration groups' (handles the tweakables of parts) to be two different, independently configurable things. This should probably be moved to the suggestions forum btw, because unfortunately the stock game does not give us these options.

The way I see it, science/sandbox modes just wholesale disable entire features that I know at one point or another I may suddenly feel like including in an ongoing game, and then a game started in a non-career mode wouldn't let me. So I only ever start career games anymore. But I don't remember the last time I used one of the preset choices as is without customizing a good number of options, and then some of my new 'careers' end up being sandbox games anyway - but with contracts and tech tree and building leveling available when I feel like it. Technically we already have this too, hidden in plain sight as a 'savefile'. Start a new game, go through all the trouble of customizing the start settings, once loaded to KSC do any futher customizing with the difficulty options screen or cheat whatever stuff you want to make irrelevant for that game, then hit Esc and save to a named file. Next time you want to start an identical game, just grab the savefile you set aside, and skip the entire 'get my game set up as I want it' routine. This can be extended to entirely skipping initial parts of a career. Say if one wants to play with a comms network and relevant constraints but setting up the initial comms network has become a tedium (something people are already preemptively complaining about in the prerelease forum): dedicate a new game to just setting up the initial comms network to the level one wishes to start out with in upcoming new games, then save it and use that savefile when needed. Regardless what I said above, I would still welcome the game remembering my last selected options, as mentioned here. I guess I've come to expect computers/software to remember my preferences.

Ok, Jeb wouldn't take no for an answer and hid all the snacks until Bill agreed to tune up his VertiPlaneTiny. So here's a slightly improved version of my 2nd entry, to get full points for fuel and more points for speed (and because it needed a few touch-ups anyway ). Please replace my 2nd entry by this one and rescore. VertiPlaneTiny-01a - 301m/s with Jeb onboard (200m/s with four kerbals), 250 units of fuel, and improved landing gear and vertical trim. Craft file: https://kerbalx.com/swjr-swis/VertiPlaneTiny-01a

All the likes. All the likes for this suggestion.

The pics are accessible now, I notice. I like how it looks when in the 'vertical' configuration; you should show that one on the download page as well. The large wings rotate through the others? Some feedback: A craft file download is always nice and appreciated, thanks. But: people would have to mess with their current set of mods to test fly a modded craft, so 'download the craft and try it' is not a good method of verification for a challenge. Hence the usual request for screenshots with key information in them. Speaking of which: your entry (and the pics) miss the details needed to score your craft on speed and fuel. And at such low resolution judging the aesthetics gets difficult too. It deserves better pics to showcase the design, very different from the other entries so far.

Ok, I notice you've updated the requirements about that, no problem. In which case, remove my first entry, because it had no Kerbal pilot aboard at all, just the probe core (the cabins don't work as command pods). And you still need to adapt the fuel score of my second entry, it's too high.

I think you scored too much for fuel, and perhaps too little for speed. 150 units at 2 per 50 units, should be 6 out of 10 for fuel, yes? And the top speed -unkerballed- is 312.5m/s, which at 5 per 50m/s would score 30 points. The 175m/s is when it's carrying 4 kerbals in the external seats. Ok, an attempt (I'm not good at this): Assuming the 2nd pic is its top speed (you don't say it is), with 290.2m/s it scores 25 points for speed. I can see no indicator for the fuel amount on either picture, so I can't score fuel. Do you have another screenshot with the resources visible? Aesthetics: well this is very subjective. I'd say 6/10 for meeting the basic design requirement of the challenge, -1 for a slight lack of visual & drag symmetry in vertical mode (gear, the one Juno on the under/left side), +1 for using the resurrected old small gear (I like, wish it was still in the stock game), -1 for the navball/controls orientation in horizontal mode, +1 for making it unobvious how you provide lift in the vertical mode, and +1 for puzzling me on what the function of the one Juno could be... 7 out of 10. Interim total: 32 points without the unknown fuel score.

I didn't know it was supposed to be fixed, I thought it was one of those 'known problems for OCD people because the code can't handle too close to zero orbit parameters' things, or I would've kept a save. I can see if I can redo it, but I've been playing pure stock and there's no stock readouts that trigger the urge to flush out the last decimals. As I remember it takes a few more decimals than stock will show.

That imgur album is doing the zoinks thing. Is it set to public?

You wouldn't happen to have the station in a polar orbit, and disaster strikes when you're flying over the poles? Up to 1.1.3 at least, there's still this bug around that will randomly kill craft when they pass 'too' close over the exact position of the poles. Just throwing out some ideas; I haven't had any random overheats in 1.1.x yet otherwise.

The challenge asks for something out of the ordinary and generally recognized as impractical. Why do you expect practical realistic designs as entries for this challenge? Does everything in this forum have to be frowny-face serious, or can we just have some fun with the amazing sandbox that KSP is? For no other reason than that it was fun to do so. I entertained myself for a good nr of hours designing something that met the weird requirements, and flying them around. Judging from Jeb's face, he agreed with me.

Ok, so slightly different from what I pictured in my head. Dude, easy. It certainly misses a few... refinements. But I'm sure it was just given as a crude example of what he had in mind; I'll admit, I would've not known how to describe this either. Ok, so based on the example, I made a different type of VertiPlane. And I'm glad to notice what I came up with also meets The_Rocketeer's high standards. (*) I present a more fitting entry, the VertiPlaneTiny-00: top speed level 312.5m/s (unkerballed; with 4 Kerbals in ECS 175m/s). 150 units of fuel. Dual probe cores at 90 degree orientations, and control surfaces appropriately configured for proper steering controls regardless of the orientation chosen. Control from 'vertical' probe core or when kerballed, the upright pilot; when on landing approach, select the 'horizontal' probe core again. Landing gear doubled up so it can be landed upside down in an emergency. Flies like a dream, lands quite easily. Brake action group deploys ailerons/rudders as airbrakes. (*: it has sufficient lifting & control surfaces and is balanced for flight in all orientations, and has dual probe cores in 90 degree offset for 'proper' navball and controls both horizontally and vertically.) Craft file: https://kerbalx.com/swjr-swis/VertiPlaneTiny-00b Imgur album: http://imgur.com/a/xM3WC

Really? It seemed immediately obvious to me... An entry, the way I interpreted this: (Takes off and lands horizontally, uses one jet engine. 840 units of fuel, so I guess that gets capped to the 250 max. Forgot to do a speed run, but the last album pic shows 194.7m/s, so let's go with that.) Craft file: https://kerbalx.com/swjr-swis/VertiPlane-00 Video of it landing at the Old Airfield: https://www.dropbox.com/s/60ktx5826514c4k/KSP113-VertiPlane-00.mp4?dl=0

I don't see anyone complaining about engineers being able to magically repair a visibly completely shredded tyre in the blink of an eye without any cost or effort (spare tyre? materials? jack?), something that's been in the game for a long time now. In that context, I don't see any problem with engineers also being able to switch tyre types. Whatever the explanation behind magic tyre repair rematerialization is, it can explain switching the tyres too, probably even easier. I'd say go for it, but I fear the problem lies more in the wheels code still not being quite tamed. Wheels behave a bit better in 1.2, but Squad would still need to first fully figure out what combination of settings make wheels behave certain ways at all, before they can add multiple 'presets' that reliably simulate different types of tyres and their respective effectiveness on different surfaces. Baby steps.