Spricigo

I would gratefully settle for a good form factor to presenting this report after inputting the data myself. I end up using a code in the name to know what a particular Launch Vehicle is capable of, but IMO something like "Heracles" sound a lot better than "125F Heracles"

Thank You! Tried your amazing idea with a Terrier+2spark. Now it have a docking port and get into 75kmx75km orbit with 400+170m/s(rocket+RCS). That is just the performance wanted. Still didn't tried reentry/landing, but looks like Wolphin is ready.

Nice rocketplane

Yes, that is how it works

The craft started to flip before 30km, that seems to be the point where aerodynamic forces and reaction wheels gave up. Your SAS is desperately trying to point you back to the desired orientation without success resulting in the spin. The balance of weight and drag is still off. You can try to move fuel around to adjust the CoM, but better yet is to try to make it remain unaltered regardless of fuel level and loaded cargo. Get rid of the vector, use 4 darts. This will put your CoM right in the middle of your vessel (provided you keep the cargo bay also there) which in turn will make balancing the drag much more easily.

Yes. BTW I prefer Outsourced R&D

I have this vessel and intend to improve it a bit, adding a bit of extra deltaV in orbit , a docking port, and some RCS. Higher tech may be used but I prefer to avoid (specially I'm not going for the simpler solution: RAPIER). The main question is if there is any hope to extract more juice from the spark+whiplash combo or should I just change to stronger rockets? If the later, how do you think a single Thud will fare? I feel that 2 Thud may be a bit to much for that small craft, but using 2 terrier means 2 stack of 1.25m. Thank in advance for any input.

@bewing the belly is blunt and draggy but so is the top and mass is fairly symmetrical up/down, not difficult to make the top just a bit more draggy and get the thing sorted along that axis. However the longitudinal axis present about 50% more area ahead of CoM and need rework. @sevenperforce The problem with multipurpose designs its that you end up being suboptimal in everything, sometimes even bad at most things. That, unfortunately, is the case with your vessel. The engines are bad for use in space, you have to much thrust for small celestial bodies (mun, minmus), not enough deltaV to go much far from Kerbin SoI, and tthe list goes on. I strongly suggest to narrow down to a more specific purpose (e.g landing and return from Duna; or 2nd stage to LKO and reentry). As it stands now its even difficult to us to give advice. edit: also, if there is constraints in regard to technology or cost.

To be honest, I gave low consideration for the whole weight issue. to the OP: what is the intended purpose of the vessel? How much cargo/crew you want to transport and to which orbital height? Maybe we can figure out some way to reach your goal with less.

Pretty much this. You need to consider the surface area exposed to airstream ahead and behind CoM, if there is more area ahead it will flip. Bringing CoM closer to the geometric center may help, I would consider moving the vectors to the side stack and forward. A side note: 7 thuds weight a lot. Exploring different engines alternatives may result in a lighter but still functional landing propulsion.

Which means you need to shift the CoM forward or the CoD rearward. Easier said than done, I know. Do you have a picture with CoM & CoL for us?

All you need is three satellite in a roughly equatorial triangle formation to cover everything except, maybe, the poles. If MJ don't have a routine for this at least the readout of orbital period make it trivial. There is a example of how it's done :

http://www.orbiterwiki.org/wiki/Launch_Azimuth

You may now forget, since there is an option "deploy when safe" enabled by default. it reentered point end first or blunt end first? You want blunt end first, which is draggier and reduce your velocity much more, opening the service bay to make it act like a improvised airbrake. Just do a few flights in sandbox mode (or unkerbaled fligths) to get used with the new aerodynamics (and some other thing you may need to relearn). It's like ride a bicycle: everyone fail while learning, it may hurt when you fail and when you learn to do it correct you think "how clumsy I was".

Doing the landing manually that is the step I feel most difficult to do.

Not only SM, there is other good tutorials (video and also text/pictures) around. Just be careful with outdated info. If nothing else, is usefull to understand why MJ do what MJ do.

No problem in using MJ, but is always good to have a basic understanding of the orbital mechanics. So you can spot that kind of misbehaviour and know how to solve it. I secound the suggestion of Bewing, doing the capture maneuver manually at Minmus periapsis. Also a good idea to do a mid-course correction maneuver at kerbin SoI to get into Minmus orbit with a good maneuver for what you want to do. Who don't know can learn, who does know can teach. Don't be afraid to ask for help if you are in trouble and by all means don't just assume you are incompetent.

more like normal subsonic, at supersonic speed turn upsidedwon, reduce wing incidence and sweep wings backwards, at hypersonic speed drop almost all wings .

It's a know bug. The tutorial, for some reason take in consideration the buildings in your saved game. Just leave the tutorial, start a new sandbox game (building upgraded to max) and try again. BTW, welcome aboard

Welcome aboard, As there is a CoM indicator, also there is a CoT (center of thrust) indicator. Adjust your staging/thrust limits so only the vertical engines contribute to de CoT and check if it line up with the CoM. Another important think to consider (vtol or not) is how the CoM shift as you burn fuel. Wouldn't be nice to design a vtol that spins uncontrollable with a few units of fuel burned.

That's what confuse me. I'm not seeing how it relates with the general case. Will the assumptions made for the particular case remain valid? Or the math need to be done again from scratch?

I'm somewhat confused. Particularly, its not clear to me why, or if, what works so long as we're using the same engine specs everywhere would still be valid when we decide to use different engines for each stage (as we usually do when building a rocket in game). In the same vane, what happens if we decide to drop tanks (but not engines) at some stages or use a asparagus/onion arrangement?

Not sure if I understood correct. You said that the one issue its that any, or some, pair of ground stations don’t connect? It may be a case of obstructed line of sight because of the terrain, to solve that you will need to figure out what is blocking and how to circumvent it. Connecting only the stations is somewhat easy, providing signal coverage for an entire area is a whole different issue. In any case high ground is what you are looking for. The other point you mentioned its that the surface is not occluding signal as you expected. AFAIK there is a setting somewhere to fix this, butt I don’t remember and can't check now.

Question about the nitpick: since kerbin don't precesses, it don't mean that sideral day = stellar day?

Its a know bug for which the typical advice is either "use debug menu to complete" or "use debug menu to hack gravity and let it land softly". Since you figure out a work around that don't requires the use of debug It may be util for those people unwilling to use of debug menu. Good job. I suggest to mark your post as correct answer (click the grey check mark to turn it green), it helps people offering and seeking help.