swjr-swis

Using a decoupler of the same size as the tanks would be the best option. If you don't have one unlocked yet, struts to the rescue once again: attach them in symmetry from the part below to the part above the decoupler.

There's a few ways to do this: The simplest would probably be to attach a strut to the fairing base in 3 or 4 way symmetry, and attach it to the payload as high up as they will reach. Attach a cubic octagonal strut in 2 to 4-way symmetry on the outside of the fairing base. With the offset tool, slide them up and inwards, to where they are near the top but still covered inside the fairing. Then attach a strut from those to the center payload. The cubic struts will work as if they are rigidly attached to the fairing, and wtih the struts will hold your payload in place. If you prefer attaching to the fairing shell, you need a workaround: you can temporarily attach some long parts outside the craft, extending far outside the fairing. Then attach a strut on the payload and extend to the temporary parts. If they're far enough away, your cursor won't make the fairing 'expand' anymore, it will stay closed, and when you try to attach the struts they will actually attach to the inside of the (now closed) fairing shell. You could close the fairing to surround the pod as well. That would allow you to put a Jr docking port on the nose. If you attach another Jr docking port on one of the fairing's interstage nodes, you can offset that one up so it's close enough above the pod's docking port that when the craft loads on the pad, they will dock together. This will hold the payload pretty well too.

High ejection force, no clamshell, and it tends to help to keep the seams of the fairing shell sides on whatever parts you want to protect - in this case, mainly the wings. You may want to turn the fairing base 90 degrees to make the seams be on the horizontal plane.

Are you sure those two pictures are of the same rocket? Because picture nr 2 does not look like it's the same craft as picture nr 1, not even after dumping all those SRBs and the side boosters. There's also suddenly a large fairing that isn't anywhere in the first picture, and the diameter of the center bottom is a size (or two?) bigger. They don't look like the same thing. Either way, there's a whole lot going on with both of those craft. Sharing a craft file would allow more help, or a few more screenshots from better angles. About the first one: you are attaching a lot of things on the outside surface, even though you have service bays - that's a lot of drag at the forward end of the rocket that doesn't need to be there. Additionally, the payload does not look heavy enough to need all those boosters to get to orbit. On the second rocket: I would say the main problem is that your payload is bending out of the fairing - you need to use a few struts you ensure the top end stays firmly locked in place. I would say once you get that resolved, it should prove a lot easier to coax into a gentle gravity turn.

"It's a game." Reasoning done. Time to play.

1.3.1 - MMB after arming, without fail. But you do have to be within a certain camera zoom range - zoom too close or too far from the starting default and it will not work. Explanation? Who knows.

That looks clear enough. If you can make the banner clickable and link to the original craft, even better - that will serve to redirect viewing/download traffic to the original craft, which will further discourage the reposting. How about copying/moving those craft objects to a separate table, one that only exists to keep a record of removed/reported craft? That would seem to solve both issues - a hasty/accidental moderator click is not fatal anymore, and it keeps the report history. Additionally, that way you can also check if there's a repeat offender involved - the delete step could check that second table to see if there's more objects from that same user. How about separating the two? Keep the lightweight hashing system you use now for the automated upload-time check, and only invoke a more thorough test when someone submits a report. Doing the heavier test only on reports would make a huge difference in processing load, since you need only compare the two craft and nothing else. It would require the report to offer a way to unambiguously identify the craft in question though - some type of user/crafts from user pick list. My time is not in abundance either, but I tend to be on KerbalX at least a few moments every day, so until you get better offers, I'm willing to help out. We need at least one more though, cause it could be my craft being reported and then it would not be ok for me to do the moderation.

Install your 1.5.1 in another directory. Copy over just what's in the 'saves' folder. That way, you can have the two games side by side. If 1.5.1 works, you can decide later to delete or archive your 1.2.1 install. If it doesn't work, you can still play 1.2.1 unaffected. This is assuming a stock game. Mods will complicate things, but mostly comes down to the same thing as long as you install the same set of mods in both games.

The Stayputnik is as early as you'll get a core, tech level 4; one could argue its cross-section is more Mk1 than Mk0, despite the size of its attachment node. After that you'll have to do with the the OKTO and other 0.625m cores, which can be stuck in a 1.25m bay to make a shielded 1.25m control package (with batteries, RW, antenna, etc). But if you want early-game probe control the stock tech three is not the place to look anyway, Mk1 or not - stock considers probe control an 'advanced' thechnology.

Actually there is, pure stock: https://wiki.kerbalspaceprogram.com/wiki/RC-001S_Remote_Guidance_Unit

I think you're looking for All Y'All:

Try it with three nothes down on the LFO - it's enough for the transfer and the suicide burn. Would be 305kg 1979.

Any other material and we're back to 3D printing, really. Last I checked Scotty still didn't have the replicators online...

I haven't used it, but from the description: it's supposed to show a list of parts for the craft in your save (among other things), and you can rightclick the docking port for the tug and 'repair'. The last page of that thread has someone asking about fixing a docking port, and the author explaining - you might want to read that exchange.

There used to be a stock bug that made docking ports sometimes get stuck into a state where they 'thought' they were undocked, but were still attached - which resulted in the problem you're describing, that they could not be released anymore. I think it was never definitively fixed and it reappeared a few times in newer versions. A bug fix mod used to solve the issue, but that mod hasn't been updated for a very loing time and won't work with newer KSP versions. The solution unfortunately is not something you can do in-game: you have to edit the save file to fix it. It can be done in a text editor, but it's probably easier / less error prone to use this: Make backups of your savefile before editing etc etc.

@Ampeag This is the link: The first post is a bit hard to read because it's from before a major forum disaster, but the link it gives still works. There are models for every part the stock game had at that time, plus a number of mod parts.

This has been attributed before to the Scatterer mod, but obviously in a stock install that can't be the case. Apparently it's not a harmless graphical glitch either: those floating squares have been reported to actually collide with ships, or missing squares causing ships to explode when trying to land. Scatterer may have just triggered it faster, but perhaps it's something underlying the stock game after all?

Alt-F12 for the debug menu -> Input Locks -> Clear Input Locks. Either that, or you've been playing for a bit 'too long' and KSP has ran into a Null Ref Exception or ran out of memory... which can only be resolved by restarting the game.

Where would one find this mysterious mission? I checked the scenarios and training, I checked the MH mission forum, I checked the Steam workshop... I even made Google search the Internet for it. It doesn't seem to exist anywhere.

KSP's brand of aerodynamics is fundamentally different from real physics. It's a reasonable gamified simulation, but it's not the same thing. You're talking about fine-tuning the simulation, which is fine - suggest away. Just don't expect any of this fine-tuning to make it all 'act more realistically', because that is not due to any of the fine-tuning, it's due to how KSP calculates drag to begin with, at the very basic coding of it. For one: they'd first have to change the game engine to make drag only apply to the craft outline as a whole, instead of all individual parts by themselves as if atmosphere phases right through solid matter (selectively, to only hit each part individually). As for the lack of performance you mention: that could have more to do with how you build your planes than with the game's parameters. I'll admit that I've not specifically paid attention to that last point. I have on occasion built subsonic planes that could circumnavigate Kerbin on very little fuel (Wheesleys are amazingly economic, although Panthers in dry mode offer other advantages at almost the same fuel economy). It's just tedious to do in 3+ hours what can be done in under an hour if pushed supersonic instead, so not a lot of people do that out of habit. And I don't know for sure if it ends up using less fuel, but I do know that in the case of spaceplanes it's worth at times pushing right up or through supersonic in dry mode when using Panthers instead of lighting the afterburners from the very start. What you may be seeing is that in general, supersonic craft fly significantly higher than subsonic - and altitude definitely makes jets more economic in their fuel consumption. I'm not sure what you mean by not gaining speed at altitude - if that were a fundamental problem in KSP, none of us would be able to make working spaceplanes in the stock game. Jets do have imposed operating ceilings and power curves, yes, but that's a simulation choice and somewhat akin how real engines work. It's not that difficult to cruise at 10+ km on Kerbin with most stock jets - which if you consider Kerbin's scale compared to Earth is way higher than what most conventional or even experimental jets can do. 10km or 33000 feet is where jet liners tend to fly, but that's on a planet roughly 10x the size of Kerbin. On Kerbin, that'd be the equivalent of 1km (or 1.75km) up... all stock jets fly well at that altitude. I also don't recognize the second point you make: slow take-off rolls are almost childishly easy to achieve in KSP, ironically in part due to high drag, which you are suggesting should be lowered. You almost have to be careful to not make your plane flip backwards at take-off. Or even before starting to roll... (just place your main gear a little too close to the CoM ). And speed does generally build up as altitude increases, even for Wheesleys; atmosphere density drops faster in the first few km than the jet power curves, so for most planes it's immediately beneficial to get out of the lower draggy atmosphere. There's a lot of well-performing (space)planes being shared every day; here, on KerbalX, on Steam. Which tells me a lot of KSP plane builders are not held back by the current stock parameters. Maybe check out how they are doing things?

Thunderbird3... now there's a tiny little detail that might've helped! Why avoid engine clipping btw? Nothing about Thunderbirds ever pretended to be remotely realistic or subject to known laws of physics. Best you can do is get the shape right and make it fly - you'll not be able to replicate TB3's magic flight capabilities even with outright cheats on.

With a lot of lacking detail and no craft file shared, all we can do is try to build a lookalike and see if it can work. I built mine in 1.3.1, which makes the fairing and tank textures different, and the pod is an Mk1-2 (no Mk1-3 in 1.3.1). But this should load and work as is in 1.4.x or 1.5.x too. It makes it comfortably to LKO 80-200km. There's still plenty of unused space under the fairings to add more stuff or fuel, and there is a big surplus of TWR, so there is potential to expand it or use it beyond LKO. I can't tell what you used between the rockomax brand adapter 2 at the top, so I put in a large battery. For the nacelles I switched the intake (heat & drag), and I used a combo of Whiplash and Dart for the engines. Obviously everything under the opaque fairing in your screenshot is a complete guess in mine - I mostly filled it with 1.25m LFO tanks, which still leaves a lot of empty space. Ascent is easy: the rocket is pre-tilted so all you need to do is stage and switch SAS mode at the right moments and it will steer itself. Instructions are in the craft description. A few screenshots: Craft file: https://kerbalx.com/swjr-swis/TheDunatian-Psychic-2c Full album with record of ascent to LKO 200km: https://imgur.com/a/CQG8cCe

Ok.

Just a heads up: it's unclear what you are suggesting/asking here. Do you want the VFX to disappear, just at a different distance? Or do you want the background calculation of the VFX to stop as soon as they disappear? The second one sounds like a no-brainer and I'm in favour of stopping the game engine from calculating stuff it is not actually using, especially when it's just visual stuff that has no effect on the physics. The first one I'd like to be a slider of some kind in the graphics settings - let us adjust ourselves the max distance at which the VFX are rendered. It would not only help players choose their own compromise between visual bling and performance, but also allow for adapting to circumstances - normal play, recording, streaming, humongous craft, etc.

If you name it, you'll never get rid of it...