swjr-swis

It would help if we knew why this is so absolutely true...

Jeb got his latest online purchase delivered: AlteraCo's Invisible Phantom. He wasted no time unwrapping it, fueling it up and taking it for a spin. But Jeb wouldn't be Jeb if that's where it stopped. 3.5 hours of metal banging and grinding sounds later, the Invisible Phantom II emerged from the SPH. And Jeb had another little try out... (With thanks to AlteraCo for an entertaining end of my weekend.)

Indeed. We have the BadS attribute for that.

I beg to differ. Flying Wing Starboost88 It's not bidirectional, so not a valid entry here... but then it doesn't really need to be. Very stable and agile, mach 2.8 cruise, enough range to circumnavigate Kerbin twice. Why complicate things? Moving on... I want to try my hand at making a proper bidirectional one as requested. I have a few ideas of how to achieve this. No promises though, I don't have nearly as much time for KSP lately.

A while back I adapted a very similar looking plane with dual props, on a request for help in this forum. The final version performed very nicely for a gas-powered prop. Feel free to take any part of that build to get a performance boost for yours. I think it should be possible to get upward of 250 m/s out of it, even with the bigger wingspan yours has. https://kerbalx.com/swjr-swis/DDE-proptest2

"Landing in a field instead of KSC. Pizza's gonna be cold by the time we get there. Sad face."

Ahh yes, I remember. Spaceship heroin. Still feel the pull sometimes, but I power through. I do miss my Damnations...

Take a look at a (semi-)stock solution in this: SWiS-Sub-1D. Semi-stock because it uses a bit of manual editing of the craft file, but it loads and works in a stock+ game without requiring mods. Monoprop is used as ballast. The key parts to look at (or copy): The Mk1 Lander Can in the center, of which the MP tank was edited to hold enough MP to sink the boat when flooded. Saves spamming parts. For your own craft, any part that is conveniently centered mass-wise (needs to be) can be edited this way to serve as the 'ballast tank'. You'll have to experiment to figure out the tank size required to manage buoyancy for your craft. The O-10 Puff monoprop engine clipped in the front section (zoom inside the front fairing, the top of it sticks out of the front hatch of the crew cabin. Its thrust limiter is edited to a high negative value, which means it produces MP instead of using it - but without generating any thrust. So it's basically a ballast flood pump now. The pair of drain valves set to drain MP, visible port/starboard between front fairing and lander can. They just do their stock thing. Check also the action groups configured for those parts. (Ore would of course have been the preferable ballast since it's more dense, but there are no parts that can be hand-edited to produce ore. So MP got the job instead.)

Making me think of the sound of the motion detector in the C64 'Aliens' game (and movie) for some reason...

Did it register on the grand slam sensors?

Tip: visit the following thread for a wealth of ideas on where to go.

"Jeb-Ball, in the Eloo gravwell, via Eve and Jool." <chalks the cue> Yep, totally happening.

Camera angle just slightly different and this would make a perfect flag. This looks like the perfect way of letting tourists experience EVAs. (not like we can trust 'em to put on an EVA suit properly, but not gonna tell 'em that - they do pay for the tickets )

Look at it this way: when you're in orbit around Earth, you're literally running circles around the planet. So you are in actuality moving through the 'same' orbit -around the sun- faster than the planet itself... just doing so in a very tightly wound spiraling path. That's extra speed/energy that you wouldn't have if you were traveling Earth's orbit all by your lonesome. That extra speed/energy goes with you when you decide to burn to leave Earth, so you need less *extra* energy to get into a Mars transfer orbit than if you were traveling Earth's orbit all by yourself. (hiding now from the physicists everywhere gnashing their teeth and plotting my impending doom)

.. doesn't 'make sense' in the context of the stock KSP system. Just like 'the entire Apollo stack' doesn't make sense in stock. It's not Earth, it's Kerbin; it's not NASA parts, it's whatever Jeb banged together in his scrapyard or found lying beside the road. The fine print warns us not to expect similar results.

I was always told that truck stops offer the best food along the high ways. I'm sure the kerbals appreciate a good source of snacks in the middle of nowhere.

You've already reported this on the KerbalX site. No reason to mention it here too. And a btw: we all started out as new players once, some of us as very young kids. If you look at this player's other uploads, they show a starting player going through starting career designs. Let's allow others to have their first encounters with KSP too?

I've always wondered what causes some alien species to 'maybe (...) be aggressive'. I get the distinct feeling that there's some type of causal relation, but I can't quite put the fist on it...

Yes, and it does work as a workaround for the reason you explain. As a stop-gap in an emergency oh-I-don't-have-time-to-revert-and-redo-let's-just-finish-this-mission kind of situation, it would help. Going forward though, with that plane, you lose all benefits of symmetry, while the problem will continue to manifest itself. So now you have DOUBLE the checks (and potential corrections) to perform, every time you use the plane, while trying to remember that each control surface has to be adapted individually when you make any changes on the editor/template version. In the case of the Pegasus shown, that line of planes has a years-long history, spawning multiple models, and nothing says it wouldn't go on to many more. All the while, now one would be forced to constantly work the control surfaces individually, in any changes made and in checking/verifying the plane before launching. I would hate to saddle @Hotel26, or any of the players downloading his plane, with that kind of a legacy cave at. And that's just one (line of) plane(s)... of many, many others. Just to be clear: the input is appreciated, and yes it is a workaround, just not one you want to have to rely on, for either one's own planes or for tweak work you do for others.

Ok, I am really hoping someone here sees merit in my request this time. Context: KSP 1.12.3, stock + both DLC, no mods of any kind (but it's an issue that I see happen even in stock 1.3.1, and it has existed in all versions in between). Reproduction: Pegasus 4 Lux or Pegasus 4 Mk2G (before it was renamed and uploaded). Download it, launch to runway, and try engaging flaps by toggling RCS. Look at left and right wings. The problem should be evident: one of the mirror-symmetric control surfaces is deploying in the wrong direction. Inverting deploy direction is no use, because then the other of the mirrored pair will be deploying wrong. Their symmetry is still mirror, not radial, but deployment is not obeying that. That craft has gone through a whole series of iterations, all the while being flown and tested several dozens of times in both my game and Hotel26's. He finally settles on this last one for upload. I empty the SPH, and specifically because of this issue, try one more time loading the craft and launching it to double-check, and it all works correctly. Satisfied, I send the file, Hotel26 publishes it to KerbalX, and .... the uploaded file is crapped. I restart my own KSP hoping the original is still good, reload the craft... and the control surfaces are deploying in opposite directions, just like the uploaded craft. So it crapped out *after* I had checked it worked, after which I made no changes to the craft whatsoever. So TL;DR, my plea then: is there any chance at all that someone please, please, fix the piece of code that keeps randomly flipping the deployment direction of control surfaces? Some more context, in a spoiler because... well, levels of frustration: Does it sound like something that could be corrected in this fix pack?

I looked at the version you placed on KX. The monoprop tanks and the batteries you added are in the airflow, and creating enough drag to prevent the craft from going supersonic. If you can do without the extra back row of EAS seats and move the RW to the back, make sure the MP tanks and batteries stay inside the cargo bay shielding, that should make the difference.

My apologies for the untypically terse post. Ascent was a standard swjr-swis 'least-effort-results' technique: launch to runway brakes on, throttle full, fine control, SAS on set SAS to Orbit Prograde (this here does practically all the flying; just get your choice of beverage, sit back, observe, and leave that stick alone.) release brakes and stage to fire the jet let it roll off the runway by itself, retract gear when off the runway continue to just sip your beverage while it accelerates -slowly at first- to supersonic speeds up to mach 2.8+ wait until you reach 13 km altitude, then stage again to fire rockets watch Ap develop while sipping your beverage, cut throttle when Ap reaches 80km coast to about 15-20 secs before Ap circularize (it doesn't need a full blast of 15-20 secs, pace it) you should have just enough dV left to retroburn back into the atmosphere for reentry I didn't test beyond just going up and coming back down. I could've added fuel for bigger margins. It's not even a fully built plane: no RCS, no solar panels or fuel cell, no antenna, no science instruments. Also I didn't go through recruiting 9 extra kerbals to seat. But it's easy enough to add those, plus some extra fuel, and it should still be able to make orbit. The important bits are the angle of incidence added on the wing, and switching to the lighter, more efficient, and less draggy Terriers for the rocket stage. Other than that it flies itself with minimal interaction to orbit.

https://imgur.com/a/ogDl74e https://www.dropbox.com/s/1hu0ybf2diwmfs6/Naz-SSTO.craft?dl=0

Tip: you need at least 5, or in stock symmetry terms, 6, sets of gear to achieve more predictable behaviour. Wheels as coded in KSP no longer register as touching terrain when their angle to said terrain is 45 degrees or greater. Resulting in very randomly triggered 'hard' non-wheel collisions and friction on gear that are set at exactly 45 degrees.

"Don't complain to us about the 30 m/s drop in orbital dV. Some test pilots apparently prefered to have a ladder..." - overheard in the SPH corridors