OHara

That lands easily on Gilly for me (in contrast to the large craft from the Exploring Gilly scenario). I can also use it demonstrate one of the un-physical behaviors that frustrate some of us. If I land on >20° tilted ground while pointing vertically, or land tilted on flat ground, so that some but not all LT-2 legs compress when the Poodle's bell touches the ground, I am accelerated to 8 m/s upwards within 0.2s. Learning to land parallel to the ground is part of the point of KSP, but when we do badly we like to be punished by KSP's usually-reasonable physics, not by un-physical glitches. We shouldn't have implied that small aircraft or large landers on Gilly were impossible, or that every new player needs to always increase damping / spring-strength. There seem to be serious-enough problems, though, to frustrate players. To me it looks like the best advice is a choice of : use Kerbal Foundaries or stock landing gear configured to use KSPWheel, play version 1.3.1, or test craft and be ready to set higher damping

@Tyko ,the system was explained rather well by HarvesteR when it was introduced: https://forum.kerbalspaceprogram.com/index.php?/developerarticles.html/on-cargo-bays-and-part-occlusion-r156/ The parameters are sparsely documented at https://kerbalspaceprogram.com/api/class_module_cargo_bay.html. Some parts have one end-wall at their local-coordinate origin; these need a non-zero lookupCenter so the search for enclosed parts finds the parts before hitting that end-wall. The node* variables support a check if the stack-able ends of cargo-bays are open to the air or covered by the next part in the stack. I set these node* variables for completeness, but I do not find that extra check to be realistic. If an Mk2 bay is ever the top of a stack, its opening gets the drag of a flat-plate of its cross-sectional area. The air inside will be rather still, so I see no need to estimate extra drag of the full airspeed on the contents. @Dafni, simple changes like these can be installed by putting the configuration lines above into a new or existing configuration file for the very popular mod Module Manager. Many of us contribute such patches here https://forum.kerbalspaceprogram.com/index.php?/topic/139980-130-community-database-of-module-manager-patches-for-stock-ksp/ I do not use the mod-hosting sites (except for github) so will not be putting these drag-patches there; they would merely be the contents in my spoilers above plus individual no-rights-reserved statement and the version-check file. I also expect no changes in this area from Squad, but I think making well-considered suggestions at least increases the odds of getting the changes that users want into stock. There is an argument that making nose-cones into containers disrupts balance, so we might suggest increasing mass or cost to make hollow parts closer in cost/benefit to the service bays. The obvious bug with the Making History tubes, missing definition for effective areas, might also go unfixed. That bug swamps any benefit of my later patch, so I'll insert the missing definition to the relevant spoiler block above.

If anyone who has avoided the oscillating landing legs knows exactly how they avoid it, that information could help new players (who don't yet know that the cool kids land on engine bells and don't bother with light aircraft). A current bug-report (https://bugs.kerbalspaceprogram.com/issues/19427) has craft-files attached , or just see if a basic light plane bounces on the runway in version 1.4.5. An easy way to test your install on Gilly, where everything is light, is to start the Scenario "Exploring Gilly" and toggle the landing gear on the mother ship the "Vules Jerne (sic) Kermin" to bounce it 4m/s into the space; then try to land it on its legs.

I see from the parts you are using version 1.4.x, and have the problem on very level terrain. Versions 1.4.x tend to have continuous increasing oscillations in the landing gear or wheel suspensions, much worse than in any version since 1.0. I think the reason some of us find the problem intolerable is the (lightweight) type of craft we tend to make. The problem is reproducible, in that some users post example craft on the bug-reports and different users can confirm them. If you notice the oscillation while at KSP, you can go back to assembly and (selecting 'advanced tweakables') set a weaker spring and/or stronger damper. [In version 1.5, you can change the spring settings in-flight, but here you do need to enable 'advanced tweakables' in the settings menu] ShadowMage's KSPWheel mod, with the configuration files for stock wheels he posted above, solves the problem for me, but your wheels on any existing craft might run or steer backwards unless you re-check in assembly. (In the end, I went back to version 1.3.1, which is still available as an option to you from wherever you bought KSP.) The Wold Stabilizer mod mentioned above, was meant for version 1.3.1, to avoid one specific type of jumping: upon starting physics simulation, such as when returning to the craft.

The bug-tracker entry 19343 is still open. The behavior on the example craft there is much better with version 1.4.5 (just a 1/2-meter jump even when full) than when the bug was reported with version 1.4.4 (landing legs destroyed with half-full tanks). Even the improved behavior is not smooth enough for the landing-leg method of constructing surface bases that we designed in version 1.3.1 (but version 1.3.1 is still available)

The Making History expansion includes more parts that one might expect to shield things inside: Structural Tubes and Engine Plates with shrouds. The additional module manager below patch shields contents of these new parts, when both ends of the enclosing tube are covered. (I do not usually use the Making History expansion, so this patch is less-extensively tested than the one above patch.)

I came to a similar conclusion, except that it seems to be the velocity that is dated. The physics time-step is 0.02 seconds. I spun one of these eternal engine propellers with blades spaced by 45° at 2250°/s, so that the position and orientation of a blade at previous time steps is illustrated by the successive blades. The velocity defined by the change in position between time t−0.02s and t is applied to the blade as it oriented at time t to compute a force applied to the blade in its position at time t, but the overlay draws that force on the blade in its position at time t+0.02s. I find it difficult to use this to make a craft like @seiryu's because the effect makes the rotor speed tend to run away. Greater rotational rate gives more lift until the rotor self-destructs.

Occasionally people post here to discuss a project in-progress, then post the result on Steam Workshop. (example) I happen to have a Steam installation and account for Cities:Skylines (which I don't actually play) so can 'Subscribe' to the craft but could find no way to persuade Steam to send the 100kB text file over the net. I was tempted to post "use KerbalX, noob" and probably should have (using different wording of course). A way for purchasers from the KSP store to access Steam-workshop craft would be welcome. There would be some benefit to Take-Two, in the greater community support for new Steam customers from old-timers. I do agree, though, that we are likely on our own to figure out how to share between platforms.

I vaguely recall that mods have to trim hidden text larger than tens of kB (something about crashing mobile browsers) so I stashed it here.

You might be noticing the old problem with overlay arrows., which you can ignore If those are structural tubes you might be noticing the new problem with drag on variant parts, which you can patch as shown on the bug-tracker if you can use module manager.

When I started with KSP I thought "symmetry around parent/vessel" meant where to hang the N new parts: N attached to one parent, or 1 attached to each of N symmetrically-related parents. But for me, KSP enforces the rule "if parts are attached to a parent that has symmetry about a grandparent, the attached parts have the same symmetry to the same grandparent." (That is, I had not figured out how to do what 4x4cheesecake did.) It seems "symmetry around parent/vessel" gives us only the choice: when we attach N parts radially to a single parent, about which axis should they be arranged, that of the parent or that of the vessel? This is rarely useful (but the option doesn't get in the way so I have no complaints.)

If it is always the starboard prop, and the reported collision is with the MK3 ramp, you might be running into a bug in version 1.4.x. That version updated the game engine, which people notice when pushing the physics engine with things like props. I still use version 1.3.1 for these things (and wherever you bought KSP there should be a way to chose which version(s) to install for yourself). Your props are still somewhat wobbly, and props do fall apart when they wobble faster than the physics engine can keep up, so maybe they are breaking on their own and falling into the MK3 cargo ramp. There are less wobbly bearings that you might like to try; you can find them in the spacecraft-exchange threads about propeller craft. Generally, you seem to have KSP propellers figured out. You scaled the blades so they spin near 40 radians/sec (2200°/s) which gets the most out of the reaction wheels without hitting the physics-simulator limit of 50 rad/sec. You can easily get TWR>1 on pure electric-prop craft, but KSP engines are heavy so they will have to lift themselves and their fuel.

You can see how this mystery unraveled, if you like, following these links: Someone doing what they thought was normal playing found it difficult to avoid the bug, "your game is unplayable", but then once somebody confirms the problem (on the bug-tracker) with a different save-game, it gets narrowed down pretty quickly, and then in this case fixed pretty quickly.

That question raises more questions. You might be noticing the old problem with overlay arrows. If it is new in the version of this announcement I haven't seen anybody notice it. Unless someone from Squad answers and recognizes what you mean, you might need to explain more in the Technical Support sub-forum to make sure they know about it.

I guess, if they're interesting. Badges for finding conditions that exacerbate, or avoid, the bug.

This could be a mini-challenge: Create a new sandbox game in KSP 1.4.5. Download the persistent.sfs from the bug-tracker (18017) into that newly-created save-folder. Select the 'Main Testing Rover' on the runway and time starts at 5:15. Drive as fast as you dare, but very carefully, through the Tunnel O' Doom and deploy the panels on the other side. Fastest time wins. https://imgur.com/a/B9XxABv Maybe a contestant will recognize what exactly is going wrong with the collision-detection.

There is something strange going on with retractable solar panels and mk3 ramps, and it is clearly not by design because the affected panel is always the one near starboard side of the ramp. It is an intermittent bug that is difficult to reproduce in a simple craft. But there is a bug-tracker entry and I didn't come to read the 1.4.5 news to find out details of whichever problems the more-vocal users are complaining about. The airspeed indicator is now correct when we target a flag or rover near the runway. Target mode used to give the velocity relative to the center of the body on which the flag was placed, which differs from the velocity relative to the flag itself, because of the rotation of the planet. (The old behavior could cause confusion on approach https://youtu.be/VU-_InTkc54?t=681). Did anybody notice which version that happened?

Who? Not much point advertising "The 1.3.1 Club" if new players cannot join. As of last week, new purchases on the Squad store had access to 1.4.4 and 1.3.1 and 1.2.2 and some earlier versions.

I still play 1.3.1, with a side installation of 1.4.5 to satisfy my curiosity and try craft that others share. But what to recommend for new players? Pluses and minuses: Version 1.3.1 had some problems - Landed craft on wheels or landing gear jump when loading from a save or returning to them from another ship (sometimes requiring a temporary 'unbreakable' cheat) - Asteroids potentially change shape on each load of the game (requiring that we quicksave/quickload until they stabilize before attaching a ship to them) New things in 1.4.5 - Full-screen mode at non-native resolution tends to switch back to native resolution - Windowed mode occasionally has the clickable region for buttons shifted upward from their screen location - Surfaces of craft tend to shimmer, 'z-fight', after a period of being flown [seems common in 1.6.0, quicksave/quickload stops it] - Landed craft on wheels or landing gear jump when docking (not as badly as in 1.4.4) [was repaired in 1.5.1] - The fixed aircraft landing gear very often start a bouncing oscillation (which has happened to varying degrees in earlier versions) [overrides in 1.5.1 give us a way to solve it] + Kerbals can parachute + Variant parts give some more freedom in building craft + You can install the Making History Expansion - Several parts in the expansion are inconsistent or unfinished Version 1.3.1 gives a player essentially all the spacecraft-sandbox aspects that we like about KSP. Version 1.4 upgraded the Unity engine and added infrastructure to support the Making History expansion, which turned out to be a mild disappointment on average with the players here. (Glad Squad is still developing the game; better luck next time.) I think version 1.3.1 gives new players a better first impression of KSP, but the newer versions are getting better and it is close.

So, one spark and the smallest applicable tank gives 20kN for 31s, about 100m/s for a 6-tonne craft, leaving 0.125 tonnes dead weight while one puff and its smallest applicable tank gives 20kN for 39s, about 130m/s for a 6-tonne craft, leaving 0.14 tonnes dead weight I can see why the extra burn-time of the puff might overcome its heavier empty tank, but isn't that just an artifact of what tanks are available ? If you have 4 tanks on the spark and 3 on the puff -- so each design has the booster burn for 2 minutes -- the spark would come out ahead. Also, I don't see how you computed a (slightly) higher TWR with the puff. Puff and spark have the same thrust, and the build with the puff is (slightly) heavier. In real life, monopropellant is good when you need to stop and start a thruster repeatedly. KSP doesn't simulate the difficulties of restarting combustion engines, so monoprop seems to lose its main advantage. I think the only 'Puff' engine is only useful if you want a monopropellant-only craft. [Edit: never mind all those numbers from version 1.3.1, you're using 1.4.x where the monopropellant tanks are much smaller-capacity, and the puff should have even more of a disadvantage. Are you using the monopropellant in the lander can for your puff test, and leaving it unused in the case of the spark ? ]

Good idea. This should be interesting. The base category invites a space-plane that re-configures to ion drive, which is likely to inspire a few designs that you may or may not consider exploits. Do you want to define any these of these as exploits or not before we get started? * Ion drives stack by default, the thrust from one passes through another ion drive, giving a summed thrust. * Ion drives thrust through anything else stacked upon or enclosing their outputs; they thrust through closed cargo bays. * Other engines, Rapers, Vectors, etc., can form stack with all producing thrust if you offset them. I don't know what "3x kerbin" means. Is it reaching an orbit 3x that of Kerbins around the sun? SSTO from 3x gravity? from Kerbin scaled 3x, with normal surface gravity? The sub-category rule would seem to allow a Tylo gravity assist, if done after intercepting Jool, and I'm not sure if 'intercept' means entering the SoI or passing a periapsis with Jool.

But Isp is thrust per fuel-rate in terms of weight of fuel burned per second -- not units of fuel per second (weight at sea level on Earth, for some historical reason). The units used to measure fuel don't seem to mean anything specific in KSP. So the effect you get from a kg of monopropellent is best expressed with the Isp of 250s, which is not bad.

I was about to say "yes" but just checked what the alt-F12:aero-data says, and am happily surprised to see the parts of the prop that are inside the fairing have no drag. [Edit: if the fairing is closed on the nose-cone at the front] Maybe the game remembers they were shielded at launch, and 'forgot' to un-shield them because the fairing never opened before they un-docked. (Off topic, it would be nice if ships 'rescued' for contracts, when we bring them back to KSC loose in cargo bays, were also sheilded.) But I was noticing a bigger problem, where the static nose-cones that are part of the main craft had big drag on their flat surfaces, which should have been joined up to the fairing walls. [Edit: Now I see. Those nose-cones were not intended to be static, but were meant to rotate with the prop, separated from the fairing. In that case they would have a flat surface unprotected by the fairing.] When I picked up the nose-cones, dropped them on inter-stage nodes, and closed the fairing on those cones, that extra drag went away. You can stack the Wheesley in front of the cylindrical pre-cooler air-intake, and then offset it, and stock KSP's rules assume no net change in drag from the offset; the Wheesley still counts as protecting the flat face of the pre-cooler. This gives a reasonable result, with no fairings needed. The fairing where you had it could be extended to enclose the pre-cooler, removing its skin-friction drag, but also preventing it from taking in air (which is only fair). Before: drag was 20.3kN at 82m/s and 800m; After: drag is 17.8kN at 91m/s and 800

I tried it just now and liked it. Turn off that silly SAS. With throttle down, the airflow keeps the engine turning, creating a lot of drag, airspeed falls, lift falls, aircraft descends, so the nose drops. The craft tracks the trimmed angle relative to prograde, as it should. You can feather the props (extend 150%) before cutting power to reduce their drag. [Edit: also the drag model seems to be confused by the fairings; alt-F12:aero-data in action menus shows the fairings and parts ahead of them as if they were disconnected, where they should show near-zero entries in YP and YN. When we enable "clip parts in editors" the final part attached to a node seems to determine what is attached there for airflow purposes, so maybe a re-assembly of fairings with that in mind can cut 20% from the drag.] The aero-forces overlay sometimes drops a couple arrows on props. If you switch to a prop and set camera to 'locked' you generally see the true arrows, though you might get dizzy.

You are in good company. Kergarin (who is very good at SSTOs) suggested the same thing But remember the jet engines in KSP have lots of thrust, so most aircraft can takeoff on the existing 2.5-km runway. For specialized aircraft that can't, adapting them to be also able to use the runway is one more challenge from the game.