xtoro

Also, you don't have to attach all of them to your center tank. Have them go from 400 tank to 400 tank in order of staging. And then the last 400 tanks will go to the center tank.

Sorta. The only way they survive is if I put the RTGs on the outside, and in the cargo bay I have cubics with the science parts on those. Not really a fix though, just a workaround.

LOL yeah, the problem is with that many parts, it doesn't leave much room for my little probes that I launch with the plane...

Yep, not just RTG's. I placed the RTGs on the outside, on the wings. They survived, but all my science gear in the bay exploded. So basically, cargo bays are now useless for storing things on reentry?

Another tip: You can invert which way it deploys. So if you have large wings with 2 sets of control surfaces, invert one of the pairs. Now when you deploy them, one set goes up, the other goes down. This makes for good braking without affecting your pitch because they counter each other.

Rads on top not helping... Anyone else having issues with RTG's in cargo bays blowing up on reentry?

Yeah I wasn't sure how realistically they were in the sense of drawing in heat as well. Then I thought "I can't put them on top because of the cargo bay doors!" Duh... Flip it around so the doors open on the bottom lol will try it tonight.

Sometimes I also get phantom forces. Sometimes they're more dramatic to the point where a ship will actually deorbit with hours. Sometimes a restart will fix it but I've also had to relaunch because restarting didn't help. This is stock ships with nothing but MechJeb added, sas off a d rcs off. Just some bug.

I have a rad on each side of the cargo bay and 2 on the bottom. Maybe I'll try flipping the bay around so the rads are on top. Perhaps the rads on the bottom make heating worse?

Happened in 1.0.2 but it's worse in 1.0.3. In fact I only posted this AFTER trying it in 1.0.3.... I even tried putting cubics in the cargo bays and attaching things to those, but still, the rtgs explode. I said screw it and decided to land my plane anyways, and all the science parts in the cargo bay blow up later on as well! After RTG's, the Thermostat blows, then the Gravioli, then everything else.... What's the point of the cargo bay? Do we need a shielded cargo bay now?

Yeah, plane starts getting reentry heating burning effects, and then the RTG and batteries get orange bars, then red, then they blow up. They don't cause anything else to blow up, but yes, I do want to recover, and reuse everything.

Thought of that but the real issue is when I'm reentering the atmosphere. If I left the cargo bay door open with a radiator sticking out, I imagine it would tear off

These things always pop up as overheating, even in space. I realize that RTG's actually do produce heat, but for spaceplanes, it kinda sucks. It I stick RTG's and/or batteries in a cargo bay, they're the first to overheat, and even they explode. Even though the rest of the plane is fine and nothing else explodes, they usually do. Anyone find a way to keep them cool without adding some dragging rads to the fuselage? Do radiators in cargo bays work maybe? Or RTG's on the outside?

Luckily none if my 28 ships were affected. I'm spamming Duna and Ike so no heat shields

I think it can be solved by using some method to split a single ship into several sections in which different threads will handle different sections. Select a part to use which will link the 2 threads together, so to speak. I made these images a while ago to suggest this but I never got around to posting it. Lets say the physics engine decided that one of the fuel tanks (highlighted in blue) is where the physics for the ship will be split in 2: Physics thread 1 (above), handles all physics for the link (blue) part, and below. It doesn't see anything above it. However, the link part will have the same total mass, and the same center of mass of itself and all parts above it. This artificial center of mass and artificial added mass will simulate having the entire ship actually being there. But, the thread is still only computing for the link part and below. Any drag or lateral forces coming from the top half of the ship as a result of atmosphere, reaction wheels or RCS, is not calculated by this thread. Its forces are being passed from Thread 2, and exerted onto the link part. Similarly, any forces being applied from the engines, gimbaling, rcs etc such as thrust, drag, rotation, etc to the link part, are being passed onto Thread 2. Thread 2 (above) is only aware of the link part, and above. It doesn't see anything below the link part. It only reacts to and computes forces against the link part and everything above it. For Thread 2, the link part has the same mass as itself, plus everything below it. When the engines produce thrust, Thread 2 doesn't see it. But since Thread 1 is exerting thrust (or any force) on the link part, Thread 2 sees this force being applied to the link part as well. It doesn't matter where this force originates from because all that Thread 2 cares about is the link part and above. So as far as Thread 2 is concerned, there is thrust, or acceleration being applied from link one originating from a virtual CoT which is, in reality, the real location of the engine. So for a simplified example: The rocket in the pictures launches. X kN of thrust are coming from the engines. Thread 1 is pushing physical force from the engines all the way up to the link part, and that's it. Thread 2 is receiving data that the link part is exerting Y kN of upwards force (Y=X kN - the kN expended from moving the mass of the lower part of the ship). The ship starts moving upwards and the upper parts start dragging (I know all parts get drag but I'm leaving it out for simplification). Thread 2 exerts downward drag forces all the way down to the link part. Thread 1 receives drag resistance from the link part which is equal to the entire drag from all parts that Thread 2 has calculated. The upper part of the ship has RCS thrusters which start firing towards the 90* heading. Thread 2 handles the upper part of the ship and exerts lateral force towards the 90* heading, to the link part. Thread 1 receives lateral forces from the link part, towards the 90* heading. But the important part is that this force does not act like there are RCS thrusters on the link part. The force is duplicated from the same source and with the same force as if the entire top of the ship was actually there. This means you still get the leverage force from having the RCS thrusters up high towards the top. That's my theory of how it could work. There would of course be a thread which would be handling the data exchange between threads, using the link parts as physical inputs and outputs. But doing it this way means that each thread has less work to do per physics frame. Now imagine a much larger ship. It may be split into 3,4,5,6 sections, with each section being computed by individual threads. The more sections you have, the more threads you're using, and the more physics is being calculated at once.

Source? Or speculation? I've programmed multithreaded apps, and yes, the management can be tricky with synchronization and preventing thread locks, but it can be done. And once you have a good system in place to handle the threads properly, you never have to worry about it again unless you change the thread sync behavior.

I don't see why separate ships within physics range can't do their own physics on different cores though if they're not interacting with each other...

I've seen this. There's also a scene where the Kerbals are standing around the crashed lander looking at it.

Fun stuff! I recognize many of those places! I lived in Wesel Germany for years, and the Netherlands was a common Friday or Saturday trip to go for dinner and movies. Mostly Arnhem, Malden and Zevenaar (which has the best steaks and salmon at a place called De Markt, and the best all you can eat ribs next to Movie Unlimited!). Been to The Hague a lot too. My wife and I went on regular road trips, Poland, Austria, Switzerland, Prague, Slovakia, Poland, Belgium, France, Hungary, Czech, Luxembourg... We actually want to MOVE to the Netherlands next. The Germans and Dutch are super friendly and hilarious,we have friends in both countries

Cheaty? No. But reusable? Also no. For career gameplay's sake, I believe the usual purpose of having an SSTO is to be able to refuel it and reuse it over and over again. At least in my career game it is.

Quantum Struts should do the trick. You just have to make sure that they're pointing where they will reattach once the 2 ships dock. When you're in the VAB, you can see the lines where the struts will connect to whatever it's aimed towards. Like on my ship here: When I dock the 2 ships together, the struts reattach from the transfer ship to the plane.

My VTOL minmus mining rover Mines, refines into fuel, then goes into orbit to fill an orbital tanker

Deutschland ist toll! I've used decouplers on probes I planned to bring back, but forgot the docking port to redock and bring it home...

Not worth a lander: Moons like Minmis, Gilly, Bop etc, low grav. If I'm supposed to land and collect science from Bop, I just send a probe, not even any landing legs, just drop onto the engine...

By no means do I intend on starting a console war by saying this, because although I own several, I'm a PC player. But, when comparing the PS4 and XBox One's hardware, I'm surprised that the PS4 is the choice. While the PS4 has a slightly better GPU, KSP is CPU intensive and is not heavy on the GPU as it does not use things like bump mapping etc. When you compare the CPU's, they both use the same 8-core processor: Custom 1.75 GHz AMD 8 core APU (2 Quad-Core Jaguar modules). But the XBox's processor has a higher clockrate, therefore higher throughput. Like I said before, KSP's bottleneck is in the physics calculations done by the CPU. If it's rewritten so that it uses the GPU for physics calculations, then the PS4 would be the way to go. Just my 0.02 m/s.