OHara

The effect of wing dihedral in stock aerodynamics (where all parts see aero forces from the undisturbed airflow) works pretty well, probably because the wing parts with functional dihedral tend to be in undisturbed airflow anyway. The first serious aircraft I built in KSP, trying to make something that would handle well based on my experience as an engineer and a pilot (but not knowing the KSP aero model) slowly levels from a roll. You can also make a plane that over-corrects roll, doing the wallowing 'Dutch roll' motion. That first aircraft had long wings because it wasn't meant to go fast, so it was mildly disappointing when I found that long wings don't help low-speed lift-to-drag ratio at all in KSP. I can't imagine a way, though, to simulate the effects of one part of the airframe on the airflow around another part, like shock-wave cones, simpler than figuring the airflow in a mesh of voxels in 3D space like Ferram's FAR mod does. Is there an alternative to FAR that does less computation but handles wing-shape effects more satisfactorily ?

To push an asteroid, keep the pushing rockets short, or disable gimbal. In the picture below, the poodle engines on the orange tanks have gimbal disabled, otherwise they would turn the orange tanks alone by flexing the klaw, resulting in gimbal opposite the desired direction relative to the asteroid. The gimbal on the small pushers works as desired, and is sufficient for steering. It might have been obvious from the linked photos, but to be explicit: The game allows transfers of fuel, kerbals, electriity, etc., between any parts of an assembly attached by klaws and docking ports; you might say it abstracts away the details of hooking up fuel lines and EVA tethers after the docking or klawing is complete. This encourages base building with parts separately klawed to the rock. Going in and out of time-warp, the game's physics simulation still has some discontinuity in objects momenta, sometimes causing klawed parts to crash into the asteroid. Keeping bulky structures far from the rock, where possible, reduces this problem.

In case you decide to try your original plan -- aligning docking ports on the ground -- I have had success on Mun and Minmus building a base with small sections, each section having both rover wheels and landing legs. The landing legs are set to lift the section somewhat higher than it sits on the wheels. Given a base with its legs extended, a new section with its own probe core and solar power to drives up to align docking ports with the base in every direction except height. Upon extending its legs the new section is likely to dock to the base the new section rises. If the new section doesn't rise high enough, I briefly retract the legs on the base. This does require a flat patch of ground, but the flat patch can have some slope, so long as the rovers are capable of driving around on that slope, maybe up to 15°. When I put this into practice ( image image image ) I used struts instead of legs for some parts, and sometimes moved un-powered sections with a rover, but given hindsight I would prefer to have done exactly what I wrote above.

We should acknowledge that the original post did report an experimental result that agrees with others' results, but not the outdated KSP wiki. I created myself a wiki login and updated the two linked entries, based on the information in 'PartDatabase.cfg'. It seems that the individual part .cfg files still contain the old drag coefficients formerly reported in the wiki, presumably for backward compatibility using the option 'replace drag cubes with spherical model' in the alt-F12 menus.

Games like this are fun because they are just challenging enough to be interesting. A plane with just enough wing-area and thrust to support its weight at 3° incidence at 500m/s, does need some extra design feature to take off and land in 2.5km (plus the descending glide over they bay). It could be an engine with good low-speed thrust, or flaps (to the small extent they help in stock aero with non-interacting wing parts) or gear positioned to give the wing 15° AoA, or rocket-assist, or just larger wings chosen as a compromise to best serve the whole flight envelope, and then maybe arresting chutes for landing. These challenges appeared just about when I was ready to deal with them, so 2.5km might be just about right. Some other area to use for specialized aircraft might be nice. Specialized aircraft use dry lake-beds. In KSP we have the ice caps at the poles, if we somehow teleport there. A dry fossilized tidal flat south of KSC might be nice.

There is a new bug that matches this symptom, and a text-file edit to workaround the issue described the bug-tracker. The workaround seems to have no side-effects, and I was glad I applied it to my install.

Real Solar System makes Venus rotate retrograde by giving it a negative 'rotationPeriod'. The 'north' pole is in the same direction as the other planets' north poles, due to the fixed orientation of the poles in KSP, making the sun rise in the west in RSS Venus -- same as for the real Venus using the convention NASA chose to orient Venus's 'North' generally along ours. It looks like each of RSS and Kopernicus have code in their .dll s to read such values from configuration files, so at least that amount of code seems necessary to un-align Kerbin's orbit- and rotation- axes.

I do. Axial tilt of Kerbin's rotation axis relative to its orbit (the nit-picky definition) is the interesting part of the tilt. It gives seasons, and makes launches to other planets a bit more interesting. It was still worth implementing in the 'Real Solar System' mod by tilting the orbit, rather than the rotation axis. I have been tempted to try re-configuring the orbits following the very good suggestion from guigui30000 linked above (following a couple levels of links) and wonder if can be done through edits or Module Manager following RealSolarSystem.cfg as a guide.

When the 1.25-m ISRU was new there was some discussion about its role here. It was easy for me to guess that the smaller ISRU would produce less output, and the thread linked by Magzimum above explains how it would be less efficient in terms of output per electricity consumed and per heat generated, compared to the larger version with its efficiency of scale. The lower efficiency in terms of output per input ore, however, is harder to understand and remember, and is frustrating for people designing their first asteroid-mover where ore-mass is limited. The current design encourages the use of the 1.25-m ISRU with a field of drills manned by an engineer. The balance works better for me if I use the same mass-ratio between input and output as the large drills, and maybe reduce the efficiency of fuel-per-electricity even further. Then the small ISRU works on a hopper, limited by the solar energy collected between hops.

If you continue to refine on the surface, a minimal shuttle using a terrier pushing an orange tank has 6000m/s dV [front view / rear view]. You might want aircraft wheels so you can build up orbital speed on Minmus flats, but even a rocket-style launch cost less than 10% of the payload in fuel. Wheels steer nicely (each turning to fit its individual turning radius) if you select a part for "control-from-here" that (1) points forward and (2) is right-side-up. When the bottom half of navball does not show ground, KSP switches to a different pattern of wheel-turning, the purpose of which I cannot guess. For making connections in stock (without KIS or KAS) I chose a standard height for docking ports, and give each module its own probe core and powered wheels.

The auto-strut settings do make a difference for me in 1.2.1, and act consistently with their descriptions, when I test them with a cantilevered fuel tank. People can make things re-usably dock in that cargo ramp forum.kerbalspaceprogram.com/index.php?/topic/148649-12-compact-mk3-single-stage-to-anywhere-with-mining-rover-update-0211/ I tried to simplify that craft today, using a single docking port and elevons to raise the rover off its wheels to alight heights of docking ports. You might consider using internal docking ports to be a frustrating waste of time, but you might enjoy that time.

I don't know why, but all my drills in my original save file (2MB) conserve mass when converting asteroid to ore at normal speed, eat 2× asteroid mass when on any time-warp. I went into the persistent.sfs, made my glittery asteroid boring and grey, checked that the settings in ModuleResourceHarvester and ModuleAsteroidDrill are identical to those in new saves, and still the drills in this save behave as I first reported. Anything in a new game acts more simply: drills remove 2 tons asteroid per 1 ton ore when at ideal temperature, 2-tons asteroid per (xx/100) tons ore when at xx% thermal efficiency. (It would be simpler, of course, if was 1 ton per xx/100 tons in agreement with the wiki)

Confirmed. In a freshly started 1.2.1 game (191-kB savefile) all drills (both big and junior) remove 2 tonnes asteroid per 1 tonne ore. I rechecked my original test (save-file started in 1.05, converted through versions to 1.2.1). The rock I use for refueling is one of the rare kind with the glowing cracks (because of course that was the one I brought into Kerbin orbit) and my drills on that rock give a 1:1 conversion ratio to ore, so long as I don't time-warp. When ore tanks fill up, the mass-loss stops. So Plusck's answer to the original question (close the tanks while drills warm up) stands.

I do get 0.05 ore/sec from an asteroid with the small drill (0.85/sec with a 3-star engineer, 0.05 when he goes on EVA) [edit] Half the mass taken from asteroid appears as mass of ore. Mass is conserved by the small drill (as opposed to the small ISRU) when it is at operating temperature. The decrease in asteroid mass matches the increase in mass of ore in the tank (10 kg/ore). Even with simultaneous conversion to liquid fuel using the big ISRU, total mass is conserved. - But, there is a bug with the small drill under time warp. The loss of asteroid mass is double what it should be, when using any speed speed of physical or on-rails time-warp. That is, to fill a 300-unit tank of ore to its 3-ton capacity, the asteroid loses 6 tons of mass, but only under time-warp. The small drill at xx% fractional 'thermal efficiency' removes mass from the asteroid as quickly as it would at 100% 'thermal efficiency' but only stores xx% of that mass as ore, losing the rest to space. As Plusck says, closing all ore tanks while the drills warm up will avoid this loss. Amusingly, having any on-board engineer go on EVA during the warm-up period reduces the rate of mass extraction during this period and thus the loss.

There is a known bug that landing gear, landing legs, and kerbals in EAS-1 chairs are not protected from drag by fairings, in version 1.1.3 only. The bugtracker indicates that the bug seems to be fixed for the forthcoming release, but also shows an example rocket suffering the bug but flying straight. Whatever fins you had at the bottom of your rocket, making them a bit more effective (one size bigger, more fins, further down the tail) is likely to work. The CoL indicator (unwisely, I think) shows the result of 'lift' forces only, not drag. So, give some margin to keep your CoL behind CoM to allow the the possibility of drag forces up front moving the center of pressure, including all aerodynamic pressure, forward.

Works for me in build 1553, at least for cargo bays. I put a demo file on the bug tracker. @Rune maybe you can check your craft with the fairing.

When I first pre-assembled a station in the VAB, I noticed when I delete or move parts connected by EAS-4 struts, the struts remain with the part from which they start, and re-attach to any later-added part along their original direction. I through that was a very clever way to let us add struts in space: build the mounting points and telescoping tubes on one part, then have them extend straight out and clamp to any part they meet on a joined craft, once the docking port has roughly stabilized the motion. It works nicely in the VAB -- if I save the station modules as separate files and use the 'Merge' button to load them and assemble in the VAB the struts connect the modules -- but does not work outside when assembling by docking.

Now I see that the post-maneuver orbit does cross the target orbit twice. If you really meant version 1.2 pre-release (which is new within the last week, released for bug-reports) the state of the bug there is changing rapidly

When the orbits do not intersect, KSP shows your craft at the closest approach of the orbital paths, and the location of the target at that same time. (Your title implies that when there is an intersecting point, it is not shown correctly, so I might have misunderstood your images)

It looks nice in 1.2 pre-release. It looks like the solution for "which two intercepts to plot, when there are three or more minimum distances?", is simply the to plot the first two following the craft's final maneuver-node. That's nice and simple, and adjustable by placing a dummy maneuver node if needed. I like that the two near-intersections with this asteroid orbit are marked, even in the presence of significant inclination. The periapses of the craft and target orbits is a closer local-minimum distance between the orbital paths, but not a useful rendezvous point. As long as my craft's maneuver is after her periapsis, KSP plots the two useful close-approaches in deeper space. Plotting later close-encounters and repeated SoI entries is nice as well.

Probably the repeated clicking is for demonstration purposes only. When I first used the similar map from the ScanSat mod, I clicked update three times in a row, to understand what it did. After that I only want on-demand snapshots. I don't see any requests for a live update directed at ScanSat. Live updating might be convenient for similar maps centered on a rover location, as opposed to the location under a satellite in orbit. I would wait to try the feature, before making the request here.

The default should be appropriate for new players (because we don't know we want to change a setting until we've tried the default). That being said, I think it would be good to weaken the default pull by a factor of 2. As a beginner I needed decent strength from the magnets (1) when the ports first touched, but were not yet parallel do to the error in orientation between the two craft, and (2) when assembling bases on moons, to pull the ports together the last 0.1m as the extendable legs lift the newest part of a base off its wheels.

The similar zoomed map in the mod ScanSat updates on-demand only and that works nicely. You don't want the view in the map to be moving by while you are planning setting a waypoint.

@Barang, use strut connectors between the boosters or their nosecones and the central tank. Or, rotate your rocket 90°, because the asymmetry happens to be just about right to make a nice curve into orbit. The Kerbals who construct our ships operate under an arcane set of regulations, requiring them to add stiffening to some of the joints, but only when particular parts are present in the craft... or something equally mysterious. In any case, the decoupler on your north-facing booster flexes more than the others, so the direction of the net thrust is a bit off-axis. @Claw he did mean rockets pulling to the north, in-flight, where the pulling was triggered by the mere presence of landing legs. The effect is more pronounced with just two boosters, and might be a nice test-case for any recent changes in auto-strutting.

I was going to say 'works for me' because I started using the klaw in version 1.1.3 --- but I decided to test it quickly first. My first test does not pivot, but one on a simpler craft does pivot, as do most of my klaws in use in the game. (All of my in-use claws pivot, if I un-dock enough parts.. Maybe wheels and docking ports on the same craft somehow interfere with the pivoting?) I see no bug-report in the tracker (unless my blurry eyes missed it --it is past my bedtime). Any and all are welcome to steal or refine my examples if that helps to file a report.