Linkageless

Indeed - I've on occasion needed to reduce thrust just to give reaction wheels/RCS a chance of keeping it on the straight and narrow. Fortunately, this happens automatically when you're relying on mining the asteroid as you go, have too few drills and too many thirsty engines!

Thanks for reporting your findings - That's an interesting fact that we're not bound to just the 256x160 .png flag size.

The extent of my experience with flags is the tutorial you probably followed: https://wiki.kerbalspaceprogram.com/wiki/Tutorial:Create_custom_flags! I've never experimented beyond that size. If you do, let us know how you get on.

Yes, that sounds very like what I've experienced. It would be interesting if anyone was able to get screenshot evidence of a PAW showing a blade with any significant lift/drag/etc inside a closed bay. I have seen, for example, -0.1kN forward lift on an un-powered yet still rotating blade in a closed bay mid way on an Eve ascent. I did wonder if that was fractionally slowing me down or if it was just a rounding error and could be ignored. I chose to ignore it.

Sadly, it doesn't look like Intel have bothered with anything for Linux for the HD Graphics 5500. I wasn't holding my breath. I'm content to bumble along with what I have for now, but it's always nice to be able to coax some more performance and reliability out of it. I shall tinker further with the game settings Back on topic - it did seem to me that the high thermal load that has been causing me CPU throttling at times coincided with a few oddities like this. I'm not complaining - I'm asking a lot of this little machine at times, and the game is a complex beast that has every right to demand to be run on decent hardware.

Good call - yes, halving my FPS does increase my performance and might have marginally reduced heating. I already have v-sync on, and had actually considered turning it off. I've not experimented with how to do that in Linux, could be interesting. It's not clear to me if system performance has a bearing on the original problem of occasional RUD after set position, but it can only help with gameplay!

I too, have notice this RUD after set position to Eve, with the indestructible cheats enabled. (I even found some previously solid designs that didn't need the cheats at all falling apart when loading on the KSC runway.) I've found the 'unbreakable joints' cheat seems to spontaneously stop working, persisting after revert to launch or SPH and initially resorted to quit/start the program. I then discovered that it almost always can be cleared by disable/renable the unbreakable joints cheat. After this problem is usually cleared. It's not clear if this is a change in behaviour however, as I've only really recently been pushing the boundaries of what my feeble laptop can handle in terms of spaceplane complexity. My machine runs hot and most atmospheric flights are in the yellow not-quite-realtime, only eased by reducing graphics effects. Certainly I recall it being a problem in 1.9.1 which has persisted in 1.10. Hope that helps!

As @FleshJeb says, autostrut your main structural components to the asteroid. I use grandparent on any significant structures, but to heaviest part on one or two will link those directly to the asteroid to stop those wobbles. Use heaviest or root part autostrut sparingly and temporarily if possible. Be ready to change back to grandparent on those parts if you're disconnecting from the asteroid or risk the wrath of the Kraken. Be aware that parts near the klaw could be under tremendous strain. Don't push them too far, or they will weirdly slip, deforming your ship, or even fail in an explodey way. Very long vessels with lots of reaction wheel/RCS are especially prone to this. Control point is significant when it comes to SAS oscillations. Experiment with 'control from here' on the klaw and other places. You may even want to turn SAS off while you slowly get it to the general attitude you want. Larger asteroids are annoying to turn. If you need to go from prograde to retro, you may even want to decouple and go round the other side. The very best way to deal with the big ones I've found is to carry a small fleet of drones, each with their own klaw, reaction wheel and RCS. Deploy those around the asteroid and you'll all be united as one vessel. Doesn't have to be very neat as long as they're reasonably spread across the surface, the RCS will work it out from there. Extrapolating from that, you may even want to have your vessel split into functional modules, each tacked onto the asteroid, which is fun. Just be sure your main drive units are all equally lined up (I'd keep them in one module), you control from there, and that is perfectly aligned with the centre of mass.

I don't know about actually having props still propelling from inside a closed service bay, I've not experienced that. I could only guess they are seen as not shielded. If it's possible, perhaps only temporarily. What I have definitely seen a lot of is prop blades continuing to be shown by the F12 aero forces visualisation, when the bay doors are closed and it seems they're not doing anything. Worse still, those forces keep being shown even if I turn off F12, leaving the vessel with a permanent pink halo while it stays in focus. I don't recall if I'd actually checked the aero debug in the part action menu of those blades for drag. It being a problem with the service bay calculations wouldn't surprise me. I'd found that if I turn off the F12 display, disable the motor and close the doors, then enable F12, the blade forces aren't shown. I've been happy enough to do that ever since, just so I don't get stuck visualising (seemingly) irrelevant forces. I wonder if, like a tree falling in the forest making no sound, just because one can't see it, it isn't there?

The most useful thing I've found to help me with mission planning is this Alex Moon's Launch Window Planner: https://alexmoon.github.io/ksp/#/Eve/200/Moho/100/false/optimal/false/10/80 For larger or more eccentric initial orbits I do have to tweak my initial burn by comparison, but otherwise you can usually get an encounter straight way if you use the information correctly. I'd started with the 'Mid course plane-change' method that this tool will calculate for you, so tended to stick to what I knew once I found it. However, since I've grown to love the 'Optimal' mode it offers and getting those burns right in 3d really makes sense when theres dV to be saved. I like the fact that it doesn't railroad you into a specific transfer, you can explore around the graph working with the trade-offs of departure date, transfer time, and dV. Even when customising like that, you can usually get a slightly better suggestion by hitting the 'refine transfer' button without loosing what you wanted.

I just want to say a big thank you to @jfrouleau for creating this mod, and to @zolotiyeruki for carrying on the good work! I find it indispensable for any design that needs precision building or careful tuning.

That's great to hear, @Booots Thank you again for this excellent mod and your continued improvements!

Yes, as @bewing says, it's extremely tricky to safely land a first stage from a suborbital trajectory within atmosphere while getting your upper stages to orbit. You have to have so much TWR on your second stage that you can significantly boost its apoapsis quickly before you're out of physics range to switch back to the first stage. Fortunately, KSP scales are such that a Falcon-9 like booster can easily be an SSTO, release it's payload and go back to KSC. I've been tempted to try FMRS but always found ways to SSTO anything I wanted to recover, which in my experience is a whole lot easier.

I've got lazy and use the Trajectories mod these days. However, with a bit of trial and error you can get the right trajectory back to KSC by retro burning almost the other side of Kerbin. The technique is ideally from a perfect 80x80 equatorial orbit (line yourself up the the Mun as target is easiest) ideally with less than 200dV so you have a good TWR for later. A lower apoapsis will mean you reenter sooner after the burn, meaning more atmospheric drag, so your periapsis will need to be higher. I find it easiest to disable 3/4 of my engines so I don't have too much uncontrollable TWR at this point and the suicide burn later - remember you've burn most of your fuel on ascent. Set a manoeuvre node over certain continental features on the other side of Kerbin from KSC. You need a retro burn to bring your periapsis down to maybe 30km over a spot on the next continent past KSC. (This depends on your vessel's weight and drag. eg A heavier vessel with more fuel on board may need a lower periapsis.) Save at this point, so you can return and repeat with any necessary tweaks. As you re-enter, stay pointed retro all the way, your periapsis will move away from you as air resistance slows you and alters your orbit. It will eventually disappear below the surface further round Kerbin. Your trajectory will keep getting gradually steeper, more so as you hit thicker atmosphere. When you're below 1000m/s you know a landing is imminent and it's best to switch to landscape radar altitude (rather than sea level altitude). It may be useful to save at this point in case your targeting is good, but the suicide burn goes wrong. If only SpaceX had this facility for real life! With nerves of steel, wait until around 2000m, at 200-300m/s, for your suicide burn. (Highly dependent on your TWR - I usually have disabled most engines and still have a high TWR.) Deploy landing gear (if you have any), stay retro until your speed is ~5m/s, throttle down and hit radial out in case you've overcooked it. There's no shame in landing with 50m/s of dV after having slowly descended the last 50m, way better than leaving a new crater! Beware of using up all your dV with a long slow burn, though. Make a note of what throttle setting gives you the fastest deceleration within a manageable time period for landing, it may be useful to adjust your engines' thrust limiters accordingly, or enable/disable some on larger vessels. Expect to be way off on your first attempt, but you can crudely refine this by adjusting the periapsis height of your re-entry burn node and repeating the process from your save in step 1. Less altitude will bring your landing closer west, more will push it further east. Try 500m increments first if you're 10's of kms off. Tuning of the landing point can be achieved either by subtle adjustments to periapsis, or by moving your burn node and hence periapsis east or west. Finally, airbrakes or a small burn gives you some good control of landing site. I found airbrakes have most effect in this respect between about 1500-300m/s so use sparingly. I've yet to find an effective way to affect north-south alignment once in atmosphere other than using aerodynamics. It's so much easier to steer a spaceplane in this respect, so small winglets or fins can be helpful if you're bothered about that aspect. I hope that helps, happy landings!

A bit off-topic now, but I might add to @Streetwind's explanation by saying the cooling required is what the part needs when operating at full capacity. I've observed that some parts, such as ISRU, are able to run under capacity, for example if the supply of ore isn't sufficient to keep it at 100% output (or indeed 125%). In this case, I've found cooling requirements are proportionally lower. I've not scientifically tested this, as I generally will over-engineer cooling. There's so many variables involved and my attention is usually elsewhere. I do have a craft in progress that might benefit from a cooling weight reduction along these lines, however, so perhaps I'll test.

Is this also the reason why they can't hear rotor blades in atmosphere?

My point of view is that there's evidently many happy users of this mod. At present, I'm at a loss to explain the seeming swift degradation in stability I've experienced when I've changed nothing aside from trying a few of it's settings. There's easily any number of reasons why mine is unstable, so I'm looking for troubleshooting suggestions. Does, for example, RCS Build Aid play nicely?

Firstly, my congratulations, @Booots on an amazing achievement. It reveals so much detail that so far I've had to only guess at - why I didn't try it out earlier, I don't know. I've had an interesting time loading up a couple of my existing vessels and inspecting their calculated performance, giving me clues as to how I might improve them. I've also started working on improving a design in progress, an Eve plane with BG fans at which point I started experiencing game crashes. First time it happened was when I'd selected Eve in the dropdown, calculations got only a few percent then the game abruptly exited. I now find it's increasingly sensitive, I can't get it to look at the very same existing designs I looked at yesterday. It rarely gets through calculating the stats and even if it does, it stays on 100% in the flight envelope screen. For example, I was able to get that far with just a mk2cockpit, and I found AoA curves were viewable. Once I added a mk2 rocket fuel tank & a vector and hit update, the game crashed after only a few percent of calculation. The tail of the KSP.log: Head of my KSP.log: and all references to 'wind': I'm running 1.9.1 on Linux, with Wind Tunnel 1.2.4. I also use 'RCS Build Aid Continued 0.10.0', and 'Precise Editor 1.4.0' in the SPH, but was using neither at the time. Do you have any suggestions as to how I might debug this further?

The answer is to use a Klaw - advanced grabbing unit. With it grabbed, poke your drills in and 'start asteroid harvester' on them. Don't forget cooling and an engineer if you're in a hurry! Edit: of course you would have used a Klaw, that's how you hauled it, right? Still, it really is as simple as poking in your drills and telling them to harvest.

Yes, I think it is random these days. Doesn't make it any better than others in terms of resources, but they look fun!

Where your drag is, compared to C/o Mass, is definitely the first and foremost consideration. Something possibly not mentioned is that the shock cone intake is lowest drag for its performance and only one is normally needed per four rapiers. Also, stick standard intakes on the Nodes at the back of all your engines, then offset them so they don't block the thrust. This removes the trailing drag from the engine and may be that little extra that enables you to go supersonic for the rapier and later hypersonic as you're leaving the thicker parts of atmosphere.

The method I used first was pointing the two vessels at their respective docking ports and very subtly using a main engine to nudge one to the other. Getting this to work meant I barely had need for RCS on early career vessels, and is still useful in combination with RCS in almost all situations.

I have a separate sandbox to develop craft in, often removing most of the fuel and cheating them into orbit round the target body for a simulated proof of concept mission. The iterations I go through in this are as fun as doing the final mission. Once happy with the design, I copy my final .craft file to my career Ships folder so I can keep the career cheat free. There's some missions I'm happy to 'wing it' with, so do the build in career and just go for it. The occasional missing ladder is all part of the fun, isn't it? And to answer the specific case of rovers, there's a cheat to surface position in there since 1.9 I think, which is quite a time-saver once you have figured out the important settings.

I'll be interested in others solutions to this on larger scale wings like this. I have had some success with crocodile hinges locked in place, but changing them in flight is impossible. The only other solution I have so far is big hinges, hydraulic rams with small unpowered hinges either end strutted to part way up the wing, but I've yet to have that looking elegant.

Build a rockery next to KSC. Decorate with carefully placed magic asteroids.