swjr-swis

Tl;dr. (P.S.: your exclamation point key seems to be sticking...)

It's very hard, near impossible really, to give any meaningful suggestions about a craft based on just a single picture from a single orthogonal angle. You add a lot of text, but it adds more questions than clarification. One thing I notice immediately though: you're using a diverse spread of angles of incidence on your wing sections, which will basically cancel out any beneficial lift and leave just the detrimental drag. That's not going to help you get this craft to orbit - it's like flying the whole time with giant airbrakes/spoilers deployed. As best as I can tell from your text, you're wondering which is better: to have the CoL higher, lower, or at the same height as the CoM. It won't make a difference for how fast you can take off - that's purely about lift/weight ratio. It won't affect wing strength either - that will depend on attachment method and (auto)strutting. I can't figure out what "higher speed adjustment of the nose" means, so I can't say if it would make any difference for that either. If you mean a more reactive plane to control inputs - that depends on your control surfaces and how far away from the CoM they are (your CoL and CoM are already relatively close, that won't need much change). The height of the CoL relative to CoM mostly affects flight stability and behaviour at high angles of attack or when banking. In my own experience, having it slightly above CoM, combined with a bit of camber, tends to help with stability during reentry. Theoretically the aero forces would then keep the craft heading belly-first, or trying to get back into that attitude if disturbed. But it's a delicate combination of factors that can't really be taken individually only - sometimes it adds more instability instead. It highly depends on the specific craft. A few more screenshots from other angles would be useful. Ideally, a craft file. Help people understand the craft, so they can help you.

Quoting for relevance (and for the awesome and accurate title ):

Not really much to offer there. If you stick with tall and topple-happy, the best you can do is pick an absolutely flat piece of terrain to land on, land very very carefully, and keep SAS on radial out... and hope it's enough to keep the rocket balanced on its end. KSP is still having trouble with random bouncing of landing legs, and oscillations in SAS... neither of which are going to help much. And it's pretty hard to pinpoint a perfectly flat, unsloped spot to begin with. It sucks to have to redesign a craft, but in this case I think it's pretty inevitable. Not to say it's absolutely impossible to use as is, but I think most experienced players would not even try this. But don't let that stop you - sometimes the best way to get a feel for what works and what doesn't is by simply trying out what you build. There's something to say for not taking anyone's word for it and just learning from your own experience.

Well, it's a very tall rocket, which is not very stable for a lander. Main rule of thumb for landers to stay upright is to keep center of mass as low as you can, and the base (distance between landing legs) wide. A table can't fall over on to its side very easily, but a stool only needs a little shove. If your payload is intended as a lander, you need to consider building it wide and low.

Not necessarily expensive: my PassengerRocket1 uses a few tier 6-8 parts, and 78 parts in total... but the per-passenger cost is very cheap (204.08 in the one challenge attempt, just the fuel and recovery cost) and remained unbeaten in a previous cheap passenger SSTO challenge. Even the total cost is pretty low (65350 for 64 kerbals to orbit and back). With a few small changes it could be limited to tier 6 parts (it does need a probe core capable of pro/retro SAS) and go down to 63520 total. A few trial runs to tune fuel for 71km LKO and an exact deorbit burn (there is a bit of excess fuel), and per passenger cost could go below 143.44 (assuming 100% recovery). That's a pretty harsh depreciation for a recovery. The stock game doesn't depreciate that much even when the craft lands half-way between KSC and the mountains (96.4% for the challenge attempt). Anyway, obviously your rules are quite specific and not exactly default, so my rocket will not be a valid entry. It can serve as example of how low things can go. Good luck with your challenge, should be interesting to see what entries come in.

Those nodes are only meant for engines, even the center one. It's not meant to be used as an interstage, the center node is not big enough for that, which is what causes the bending. It's a bit of a puzzler to me, because as far as I can tell, the only configuration that even works ok is placing 5 Mastodons on those nodes, and then only in the bare variant. Might as well just've made it one part with the engine bells included, like a supersized Mammoth. Not sure what to say about that one. The center nodes of the engine plate are definitely the right size, it should be stronger - assuming you used the largest size one. Either way, looks like you'll still need to do some additional strutting to rigidize it.

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.

New textures look crisp, they move these two parts from eternally looking 'out of focus' to a well-defined look. Especially the end-caps were sorely needed. Thank you. I don't have much issue with the square edges etc. It allows you to keep the old models, which means less work; I'm fine with that. If you do decide to smooth the model more between now and release: please make sure they still fit perfectly flush to the 0.625m and 1.25m diameters on each side, just as the current models do. The FL-A10 surface texture is too busy. It's a very small part to be so overly subdivided. If you absolutely want to have panel divisions, and I'm not against it, I'd say that the bigger panels in the center row are more than enough. I have to agree that the part variant names seem to lack consistency when compared to the actual colours of the parts. Back to the endcaps for a second, in particular the FL-A10: in replacing the black holes by clearly defined endcaps, you've removed the implied (if not real) hollowness of the part. While the implied hollowness fit with the part being purely structural, now the part is very clearly not hollow anymore. What I'm getting at: even as small as the part is, the new look would be very deceptive if the part doesn't get internal tank volume.

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.

I'll be honest: I'm going to miss that one. It's done a lot of work for me over the years. The revamp looks good, and the bare variant will be welcome. If I may ask for one tiny improvement: can you please rotate the part 90 degrees so it is symmetrical through the dorsal to ventral plane? This will make mirror symmetry -and rotations in mirror symmetry- work correctly. It's the one thing that's always bugged me about the Spark and makes me break symmetry every time to rotate them 'the right way'. (*) (*: it's a flaw that other parts have too, but like I said, the Spark has seen a lot of use and so I run into it often)

Gradual tech introduction: isn't that what the stock 'part upgrade' mechanism is supposed to be used for? If not for that, when is that ever going to see use in the stock game? And variants can have different mass and other variables. So the question remains. They go to the trouble of coding in these really nice tricks... and then don't use it in new/revamped stock parts. Missed opportunity.

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.