[Forget about DLCs and create a new game instead]

I completely agree.

However, isn't it kinda trendy for developers of a game to draw a line where they will start to milk out any income gain by selling expansion content. 

This are often items of secondary interest, and often no interest at all unless you want to show your fanboyism.

This is a likely route for any game developers team.

The question is when will we hear the first hint of a new game. A new game by Squad is definitely something I want. It could take a year, 5 year or never. 

[Why does this SSTO spin backwards on re-entry?]

Issue solved. The wrong lift display must be really far off then. I had to space the COL/COM markers by quite a margin to get it right.

[Why does this SSTO spin backwards on re-entry?]

Never ran into this issue on my other designs, so I guess I missed the consequences so far of not knowing wrong body lift display.
I'm going to adjust it a bit more and see if it works.

I had hoped that such a troublesome bug would have gotten the deserved attention and be solved in v1.2
Granted there are countless fixes so I'm hardly ranting about this one.

But it doesn't seem like a minor bug and could really annoy people when constructing vessels. I hope it gets fixed ASAP.

[Why does this SSTO spin backwards on re-entry?]

*Playing v1.2 Career mode.

My own answer would be that my COM would drift behind my COL when my tanks are empty and my cargo is jettisoned in orbit.

I built a Panther, Spark and Thud engine SSTO design that can carry about 6 tons to orbit. (I don't have better engines yet)
It takes off and gets into orbit with no problems.

The following screenshot shows the COM and COL on the picture with all fuel tanks emptied.

And a few more images on this link if that could prove any evidence to issue.

I have active connection to the KSC btw.

With all fuel tanks filled the COM will only move forwards about a meter, because I designed the empty mass in such a way that I wouldn't need to worry much about the shifting COM in the first place.

 

Unfortunately it behaves just like the COM is forward even while it isnt during reentry. As soon as I hit the atmosphere and the Reaction Wheel Torque fails (@ about 64km) the vessel starts tumbling backwards with the tail to the retrograde marker.

When I go below 10 Km I can usually get control back somehow and get the nose back down and commence flight.

But because I cannot control my reentry angle I cannot control my aerobraking and I cannot make a precise landing at the KSC.
I never use Aerobrakes on SSTOs but rely on a balance to achieve high angles of attack. I rather not use them, especially because I want it to land at the KSC, and Aerobrakes on the back will make it a projectile.

On this design the plenty of forward and rear pitch control surfaces seem totally ineffective.

Any ideas?

[When the contract is ridiculous]

I accepted these contracts a few times.

Only with mechjeb installed to autopilot so I can go to the kitchen, make a sandwich, then get back to my monitor to see I have arrived as expected.

[EVA bug in 1.1.3]

@Kerbal101

Can you elaborate on what there is not to understand about? Or not want to understand because you seem Finicky about your problem.
Technically a new version is added content with bugfixes like you say. That is how I understood it and it has always been this way, you have thereby answered why bug fixing is applied this way. So you already know there won't be any fixes.

So is this a suggestion to do bugfixes prior to a new release?
If so then why not open a new thread to suggest it then use a new thread that reports the problem, knowing that there is no setup in place yet to do post release bug fixing of any kind.
And even if frequent bug fixing in between main releases does get implemented then it will start today and the implementation of these bug fixes as soon as V1.2

Also I was not referring to the age of the problem but the age of the thread.
Also to call the problem "current" 1 day before a new release is a big stretch although accurate for a few more hours. Your current probem will be solved in a few hours, and I advice a alternative solution for your current savegame. A solution you probably don't appreciate since you didn't mention it. Unless that is the part where you thought you were reading Chinese. IF it does, I'm not a native English speaker.

While I hope for everyone including myself that you get your way, because bugfixing is important it is not going to happen in 1.1.3.

 

[EVA bug in 1.1.3]

Attention people: This thread was posted on June 22nd and refers to a problem that will be fixed in v1.2. Seems to me that opening a new thread would be a better idea. Since hijacking a thread is like posting your own thread but now we have to read something from months ago, which doesn't even apply anymore by tonight. Making a new thread and notifying that the issue still applies gets you better attention, and sadly no help because 1.1.3 will not be patched so your at a dead end unfortunately.

@Kerbal101

As for starting a new game. If you want to have your old savegame in place. You can see if you can copy/past the craft files from 1.1.3 to 1.2 (if that is compatible)
If not rebuild them and atleast hyperedit your more valuable and necessary equipment to the places you'd send them. My condolences if you have hundreds of vessels in the solar system, good luck!

It really doesn't seem cheating to me because you just recreate the universe you already created. And it's not like your put on a public cheat list so no worries there.
This can be quite time consuming but alteast it's a option. Although I doub't you'd do it just for that 1 single bug.
It won't work if you have mods.
But then you really cannot complain, it's just the consequence of having newer versions every 3 to 6 months.

[Ship not controlling as expected during docking?]

The camera has nothing do with controls. If you change camera view the "D" key will do the same just with another camera angle.
And the Locked mode is best as Glutonny pointed out, but it will only change your view, nothing else.

We will await the pics and by tonight you can probably do it in V1.2 of KSP

[Ship not controlling as expected during docking?]

So first you docked, then after docking you released from the docking port and then your ship seems to control badly? Am I correct, because I can't tell by how you told it to me.

If this is the case it is possible you had a command pod/probe core attached to the module that you docked, then after releasing a offset probe core or pod or rotated one switched to be the active probe core on the vessel. By the sound of it this is the case and the probe core that becomes active after docking is rotated in relation to your previous probe core (the one you shed during docking I guess)
Depending on the orientation of your active pod/probe part it will change the navball in the direction it is facing. Probably rotating the horizon on the navball. Does your navball switch after you undock? If the answer is yes then I'm 99percent sure this is the case. Potentially this also whacks the RCS symmetry of balance because you shed weight, also causing control issues obviously.

You can still use the vessel in most cases though. You just have to cross translate and rotate against the offset rotation of your probe core. For someone new to docking this might be really difficult, especially since you said that normal docking took you 30minutes.

Can you post a picture of your craft, just before you docked and a picture thereafter (where things go haywire)
That way we can be specific in our advice.

[Why do we need mods?]

The reality is, KSP out of the Box must be a challenge. That's why stock parts offer a select amount of parts with limitations in size that allow you to do basically anything in KSP while still maintaining a challenge.
I think KSP has fixed size stock parts (without the option of rescaling) to maintain the general difficulty of constructing things that allows all possible missions in the game to be completed without making them necessarily more easy.

Apart from graphical and instrumentation mods all mods make the game easier by introducing custom parts, engines or other peripherals that will make the part selection to vast for a Layman to keep his head above water.

When I first started KSP back in V 0.21 I think I had my time pretty much occupied with learning whats in stock. Now I to desire many mods to expand my game. But KSP has quite alot of stock applications ready for a new guy to spend weeks if not months figuring out the stock game to it's fullest potential.
I can Imagine as a new guy you'd not want twice as many parts because i.e. Joe or Tom are still playing with arguably a already vast collection of parts from a new guys perspective.
I have some fervour for a stock tweakscale function that may be unlocked in the debug panel just to toy around with miniature or oversized vessels. But it's not that I care that much that I would want it that way necessarily.
But then again, the download link for anything you'd want is 2,3 or 4 clicks away from where you are now. So why people desperately want things in stock so much is beyond my understanding.

[Docking Port Rules (0.625m Vs 1.25m) 1.1.3]

The way KSP works is that if you dock 2 vessels it becomes 1 vessel. And because KSP cannot identify joints in between 2 crew containing parts it won't work.
Maybe they can make it as such, I don't know. It's so silly that you can attach a crew capsule to the other side of the rocket with only fuel tanks in between and you can still transfer them from here to there.

I don't agree that Kerbals shouldn't be able to squeeze through a junior docking port. Many real life docking nodes are very small, especially during the early space age. People had just enough room to squeeze through a joint.
What you are forgetting is that the Kerbals look alot bigger then they are. Just take a look inside the helmet and see how much of a volume the helmet alone uses.
So a naked Kerbal *cough* probably has enough room to squeeze through.

[How many things do you use the wrong way?]

Using empty Solid rocket boosters part clipped in a heavy fuselage as a stock constructional solution to build stock things that would normally require Kerbal join reinforcements mod.
In this case to carry 4 x 46 Ton custom made rapier engine blocks without them falling off due to constructional failure.

Pic

Completely overkill for stock KSP, I know.

[Multi-port Docking]

@Sharpy

While I agree that a easier option will solve this by launching the thing in one go, I personally have the gaming sentiment to make rockets look like they should in real life. Both in RSS and Vanilla.
That means that 2.50 meter parts fit into 2.50m fairing and 3.75m into 3.75meter fairings without the top bulging out like a mushroom top or the first stage base as wide as the first stage of project Orion.

That means no wide structures, and desired wide structures will then have to be docked in space. Because of that I'm a very big fan of using multiple docking ports myself and docking in general obviously.

A construction tip:
Take any part for example and hold left alt + Q or E (or left shift as it is on my Ubuntu machine) (might be right alt on windows, I dunno) You know what I mean.

A full 360 rotation of a part is incremented into 72 rotation increments. Thats because if you keep pressing alt/shift + Q+E you have to tap 72 times before any part comes back around.

So a hexagon ring station for example like I build is 72 / 12 = 6
So when you Alt/shift + Q,E,A,S,W,D (depending on how you want to rotate it) 12 times and you copy paste that as a Subassembly you'll have it right. It doesnt even matter if the docking ports are centered on the module (although you'll need symmetry enabled) because they're all copies of themselves.

As for the docking ports on the side of your tank (the one that doesn't fit) a similar aproach can be used.
But you don't want to use 12increment rotation in that case.

Put your angle snap to the hexagon marker.

Put your docking port on your fuel tank and try to drag the docking port all around the tank. Because the haxagon angle snap is chosen any part (docking port in this case) displaces itself in increments.

That shows us that there are 24 snapping points on the circumference of a fuel tank.
You want it to be a hexagon? Then you'll need to start with 6 way symmetry always since 24/6 = 6

Try to use 6 way symmetry on one subassembly and then you can just copy paste that module and everything will be symmetrical. Whatever you dock thereafter doesn't matter. But if you require the same docking connections later on with the same vessel in orbit you reuse that subassembly as a joint instead of trying to rebuild it.

If copy pasting doesn't work, your doing something wrong, and I can't tell what it is.

 

[Smarter stock contract system.]

Your right, but that are some big names that leave.
Because of that I get the impression that we have to deal with a new crew that may not orientate itself in fixing broken aspects of the game. (or better said, hard to implement aspects as you call it)
They might rather leave us with the option to install a contract configurator, and that is okay. But I would like to see it work flawlessly in stock, and I hope the new team sees value in that.

Can you tell me the reasons that you think prevent implementing what I'm suggesting. The contract system has been bombarded with critique since it was introduced since v 0.22 I think. And while it has been reworked several times little has been done to balance it despite multiple requests for a overhaul.

[1.3 - What will it have?]

I can remember having read a thread in the mod subsection about a third party plugin for multiplayer. But I recall it didn't work properly and I never tried it yet. I'm not even sure if that exists for 1.1.3 or 1.2 later on.

I was just wondering how a Multiplayer in KSP would look like since it's been mentioned a few times.
Could a multiplayer session download part textures from third party mods? Would that work? I know many multiplayer games can do this, but would that work for KSP? Basically that means that you won't need to have B9 aerospace while another user in your session has a B9 ship because the session can download third party textures and stream it to your game environment directly.

Or would everybody need to limit themselves to stock parts?

Wouldn't we need multiple KSC locations on the planet? Otherwise ships spawn into ships. What would the max number of players per session be?
Would a shared savefile work on a server cloud so people can reload mutiplayer saves with a engine that can remember and localize vessels to the original authors online account without removing inactive vessels from orbit?

Or would it be more like a sandbox environment only where the session will end when the host disconnects or something?

 

[Smarter stock contract system.]

While my hopes aren't high for the devs to ever fix one of the few calamaties in KSP I'm suffering from since they're leaving, I want to discuss a very important aspect of the stock contracts system, that fails miserably.

I had about 12 tech nodes unlocked at which point Wernher asked me to Fly by Duna. I couldn't get to Duna yet!
Not because of lacking tech nodes but the fact that Duna was about 140 through 180 degrees behind the desired launch window (months behind). I'm not willing to store that contract in the active mission list because I want to fully uttilize the max contracts available, not have one sitting idle for a few months until the mission actually arrives. I would need a Eve/Kerbin gravity assist with a very very long mission time just to get there.

I would really consider a in game system that detects this interplanetary dance around the sun to know it's even possible to get the mission done that the random slot machine (that is the KSP contract system) pumps out now and then.It's about as random as a slotmachine, you can get 3 berries or 3 x 7, KSP doesn't give a #@!*#@&

This should also be incredibly easy to program. The KSP universe starts at a fixed date with the planets at a fixed position. So a toddler could program the actual time frame in which these contracts should spawn in your contracts list.

Atleast these missions don't spawn in the early career game when your reputation is to low. But they also don't when you do have higher rep before your first Duna launch window (or Eve for that matter)
Atleast not in my case, and I got my rep very high in one of my savegames prior to my first Duna launch window. So that's the overal silliness of the contract system for you.

This is very important atleast to me because since it's random the contract system oftenly refuses to spawn Duna missions in the contract window when Duna does reveal itself in a desired relation to Kerbin.
Very Ironic, because I want my Duna missions to earn money. When I go to Duna first time in 1.2 I want multiple sattelites being sent right there immediately on the first transfer window.

Preferably including atleast a fly-by contract if not a additional contract to obtain experiment data around Duna and it's surface.
Also I want the contract system to have the intelligence to determine that I have actually send a mission to Duna.

And when it detects this that the contract system atleast spawns 1 additional mission with Duna in this case as a target in the next week after signing the first Duna contract so I don't have to wait 2-3 revolutions around Kerbol to do a 2nd Duna mission.

Also, certain game activities seem to trigger certain contracts. So it might not be completely random. However, I don't know this for sure.

But it seems that when I go interplanetary from the get go the contract system seems to spawn more interplanetary contracts from there on.
Maybe you'll have to go interplanetary first before such missions are spawned in mass.

The thing is, I don't want THAT!

In the early career, either Duna or Eve are months away from their desired launch window, In those early weeks months I do many Mun/Minmus missions.
I want that damn contract system to give me any interplanetary missions whenever any target planet is in a normal hohman transfer window. Duna in this example, but the same goes for Eve/gilly or Ike obviously.

I don't want to install a contract configurator as a necessity to bypass this silliness or have to use the Debug panel to spawn contracts I desire in stock KSP.

 

[Blue Origin Thread (merged)]

There is something I don't understand, probably because I'm not a engineer
I've been following spaceX activities for years and I dreamed about Elon's plan coming into fruition and well, it's going into a satisfactory direction from a Layman's perspective.

The way I see this endeavor is like the passenger airline industry since the wright brothers. But more specifically the Jet airline industry later on.
SpaceX needs to get the right kind of plants in operation not just for production but also for maintenance and testing of already used stages. They already do that, I know but I mean in a way to try identify problems before they happen kind of way. Especially for a rocket that's supposed to launch 100 real living creatures

Because my gut feeling here is that if let's say Elon delivers his promise of creating his BFR and it succeeds all mission objectives including recovery that the same rocket is going to fail in the next 3, 6 or perhaps 9 subsequent missions due to constructional failure. Think about cracks due to multiple refueling operations, re-exposure of the same parts many times over again in between near absolute zero and 2000+ Fahrenheit (depending on what stage we talk about)

Failure during x many times wouldn't be bad ofcourse, even if he manages to launch the thing only once it is a achievement, but I'm talking more long term here. Elon mentions a active maintenance program, but I haven't really been able to understand how that would look like.

The reason I bring this up is because although we managed to recover a rocket stage it has never been tried to use that same piece that many times in order to get that desired price tag that Elon Musk has sugar coated for us.

What are your expectations where failure because of re-use could go wrong, and how would a maintenance program look like to tackle these issues before it creates a problem?

Or is what SpaceX is doing simply a trial and error aproach in this only? Like, see how many times it works, then investigate and see where to improve.

While you obviously only go to Mars if your willing to die I think it is important to have already active implementations in place in how to identify problems before they cause havoc and how to solve them.
The same maintenance solutions should also still work if you need to re-apply them like on a airplane.

How else are you going to get that desirable price tag? Getting 100people killed IRL is like your reputation slider in KSP drops from max to negative.

Any thoughts, or better yet real intel? We're trying to do something that I think has a higher mortality rate then the Ships that crossed the atlantic in the late 15th century and carry even more people. The price tag Elon talks about is like assuming nothing goes wrong from A,B, to Z.

[Awful terrain detail]

KSP is not a high end graphics game and never will be. But admitted I think there is some room for improvement. Atleast give us a slider for auto generated textures like trees (with a tree line this time please)
It's kind of a fixed objective of any game developer to make the game playable for everyone.

Don't expect major changes for that reason, and I'll explain why more specifically if you want to know.
KSP already is CPU intensive. I have a overclocked 4.3ghz 3570K Processor with 8gigs of ram. This particular processor seems to do very well for ksp according to a chart I read sometime ago. The reason for this has to do with calculations (flops) per clock which is technical and I'll spare you. Most newer CPUs are better at this but the 3570k in this instance has that and a high base clock + overclockability. Other CPUs might not work as good as mine.
I get 15+ fps just on my 200 part vessels and even lower if I go near 300 parts (which is where things are still tolerable)

What your suggesting is to make the game besides CPU demanding also GPU demanding. The problem there is that the CPU supplies RAW pre-calculated data for your GPU. The higher the graphics, the more the CPU has to do to serve the needs of the GPU. This is minal though, especially in KSP, so mostly this should not be a bottlenecking factor. But because your CPU in KSP is already pretty much stressed atleast on one if not multiple cores any more load is only going to get the FPS further down.

So making KSP with higher end graphics will exponentiate the performance losses because the CPU now has to do a 2nd thing while already stressed with it's basic physics and KSP related calculations. This is why you see frames per second loss if you got a variety of graphics mod installed on KSP. So expect FPS loss if you are going to mod. With the right settings a proper CPU and enough RAM it should still be very playable, regardless of your gamedata folder contents.

I see it is basically a trend for CPU intensive sandbox environments to have lower graphics. Take vanilla FSX for example. Because programmers are often limited to choose either a CPU or GPU intensive environment because a environment that has both elements will always make the CPU a bottleneck no matter what Extreme overclock edition + phase change cooling you'll choose.

 

[Donate a save file]

@micha

Ah, I couldn't tell his real motives in this but that clears things up.

[KSP on HP EliteBook 8570w]

I tried running KSP on my Linux Mint and Ubuntu versions with open source drivers and the result is always the same. A KSP window open that's totally black. Music starts playing but no graphics.
Some applications just don't work properly on linux with the open source graphics drivers.

The specific graphical implications and or overall functionality of KSP with open source GPU drivers seems to depend on the type of PCI-E or integrated graphics card your using.

Some GPUs with open source drivers wont show the game at all (like in my case)
Some GPUs do work with open source drivers but have a variety of graphical glitches like you have.
It's strange the Demo works fine and the full game does not. But obtaining the proper GPU drivers is the first thing you should do anyway imo.
So try to figure out what graphics card your running and try to obtain the proprietary Linux Mint proprietary drivers.

If that doesn't solve the problem we can go from there.

[KSP 1.1 heavy lag]

Any new version of KSP comes with more content and if optimization of the game was not a main focus during this release it is likely to use even more resources then before.
It all depends on what OS your running. And as long as you run Windows as you do (untweaked) your going to need anywhere from 500mb to 1gb of ram just to keep the system running.

That means KSP can only uttilize 2-2.5gb of ram. The recommended system specifications for KSP is 4GB of ram!
I've run KSP on different machines ranging from 3gb ram up to 16gb of ram. 4GB already seemed to slow down the system of more complicated 100+ part vessels. But background processes and OS services were not tweaked and optimized so 4GB should be enough in most cases. 3GB really seemed to make playing KSP pretty disastrous for me.

6GB seems to be the best way to go just to be safe and future proof.
The recommended RAM specifications for KSP is a minimum to be honest, but at the same time just enough. That's because going over 4gb really wont give you much more performance.
But going under that is going to maximize the available RAM capacity and your system will slow down by running on virtual harddrive memory (at which point it doesn't matter whether you have a 2003 2.2ghz Pentium CPU or a i7 3970 @ 4ghz.
Having excess ram in KSP doesn't matter. But 4GB is recommended and is just enough and more of it won't do much (unless you got many mods installed)

It also depends on what vessels you build. If you build complicated vessels with higher part count the CPU has to work harder and it will need more and more data from the RAM. Complicated vessels + mods is well over 4GB.

At some point though the CPU will start becoming the bottleneck no matter what and it doesn't matter how much RAM you have.

I'd say 6GB is a save bet, preferably 8GB is you want to heavily mod the game.
As for upgrading your notebooks memory, that is in most cases possible. Because it is a 2008 laptop it probably has DDR2 or DDR3 SO-DIMM, and you can get 4gb of both for just 30-35bucks.

Type in your Notebooks Brand + model number on google and find the manufacturers site to see the notebooks specifications to see how much RAM can be installed.
If you can't find it just give me the name of your notebook and I may take a look.

 

 

[Donate a save file]

So you like the surprise factor of somebody else handing out his save file for you to experiment with? (Wouldn't the spacecraft exchange be more suitable place for this?)

Or you just hate the early career like I do and you want to jump ahead?

Alt+F12 (or R-shift+F12 on linux) "Dunno for Mac PS or xbox"

Step1:Cheat yourself money and science.
Step2:Create your satellite and/or any other desirable vessel.
Step 3: Edit your orbit SMA and inclination to match equatorial orbit to match geostationary orbital period. 2868km up or something.
Step 4: Repeat process for any number or variety of vessels you want in orbit from the get go and the result is profit.

I can't help you. I don't yet have a 1.2 career save with enough of a relay coverage to suit your needs. What I do know is that everybody plays on different difficulty settings. While I'm sure you could edit those saves it is unlikely these people play on the same settings you desire. Since your likely willing to edit that savegame to your needs anyway it seems best to create your favored setup of satellites yourself then asking for somebody elses savegame.
If I had such a save I'd give it to you, but that just isn't the point really as I shouldn't need to.

 

[KSP the Antidepressant]

@Choctofliatrio2.0

Yes, I to lose all my depression I obtain during the day when I get back home, launch a rocket with a max 12G acceleration and Jebediah is still laughing with that sweet and joyfull expression on his face.

BTW,

Kalium,
Sulphur and,
Potassium

^^May also do the trick.
 

[Mk2 Cockpit Heating]

@Jarin

You are right. But you know how to change your Com by draining fuel from your tanks in the vab/sph as much as you would have during re-entry.

You then now where to change the com to and by how much. A little offcenter is also not necessarily catastrophic. 

[Mk2 Cockpit Heating]

Theres a reason why high speed aircraft or spacecraft (spaceshuttle) have blunt noses.
Sharp edges tend to soften or even melt faster then a more blunt end on a fuselage.

Less of a volumetric area means it absorbs and dissipates heat more quikly. Which is why radiator ribbons are small and not big. That's why it takes in upwards of an hour for your icecube to melt and decades for the polar caps to melt. The polar caps have more volume and can absorb that energy alot longer.

Those properties of a nosecone (i.e. a metal) however are based on the ambient temperature. And the ambient temperature during re-entry is to high to make sharp metal edges. The material becomes to weak because it has to little volume to dissipate that heat and basically gets heatblasted and your fuselage starts to crack and deform and at some moment you'll get a boom and the result is a funeral with some new headstones.

OT

KSP doesn't simulate that and as far as I know not a single game does. (hit me if I'm wrong)
It would explain why blunt shielded docking ports don't overheat as quikly but that can also be the bowshock effect as is pointed out.

It's the fact you decelerate on a high AoA alone that explains the results your getting as you say that you used a gentle re-entry aproach at first. This is basically the worst to do anyway from any Orbit or atmospheric encounter.
If your nose cannot hold a high AoA in your current plane design then try to move fuel from one tank to another to move the CoM to your CoL.
The lower heat on a Mk2 nosecone on a high AoA seems more a result of aerobraking as you'll decelerate more opposed to going in the atmosphere nose first (hypothesizing that in both scenarios they'd have the same re-entry aproach, speed, except for the attitude that is)

While I haven't tested this out recently I can remember my own first attempt at building SSTOs since v1.x and I had a few instances where I went nose first during re-entry due to bad designing of my craft. The difference between nose first and a high 40-60 degree AoA on the same spaceplane or aircraft for that matter is game changing. With a nose first aproach and a few airbrakes you'll need almost half a orbit from the KSC to land due to poor deceleration. But with a high AoA aproach without any airbrakes I'll need about a quarter orbit from my de-orbit burn to get to land.

Keeping that AoA during descent is all about balance. You can do it without any control surfaces and thus with the cockpits onboard reactions wheels only. Although you'll need very good balance. So make sure you'll have a fuel tank in front of your Col and behind your Col so you can transfer mass from one end to another to center it over your CoM. If you balance it well enough the plane will almost reenter by itself.