surge

Addenum, types of rotor hubs: Teeter-totter (fully-rigid): Boeing Iroquis variants (UH-1, AH-1, Jetranger). 2 blades rigidly connected together with a small stabilising crossbar. The blades are free to move up and down like a see-saw as they rotate (thus the name), the crossbar absorbs the remaining vibration. Semi-articulated: OH-6 Cayuse? Possibly the american UH-60s still use this design. This rotor head has independent single axis hinges on each blade allowing for more stability in windy and unstable environments. Fully-articulated: Nearly all modern helicopters, cheap plastic drones from toy stores. Has 2 way hinges on each blade (essentially a ball joint, but ball joints are weak); the original vertical axis to assist with unstable environments, plus a rotational axis forward and backward "flex" allowing for high speeds. The retreating blade is allowed to "fling" itself forward some 3-10° preventing blade stall, while the advancing blade is damped by drag from moving forward & occasionally preventing supersonic flight. You're welcome

As many have said, this is an incredibly good guide for helicopters. Let's say intermediate level A few points: 1) Flex - real world (non-coaxial) helicopter rotor systems have ALOT of flex in the axial-horizontal direction. See an inert heavy lift soviet helicopter like the Mi-6. The need for this is partly because the rigid underslung frame tends to shake apart, but mostly for control. As history goes, the swashplate was invented many years before someone (Igor Sikorsky?) thought to allow the rotor blades to flex and forgive the rigid control system, thus making them inherently stable - and therefore flyable. I notice in the photo of your rotor hub, you (by experiment or accident) have multiple "cuboid struts" before the rotor blades are attached. These are very floppy parts, and I suspect a flyable single rotor design using that wouldn't be hard to make. 2) SAS. Wouldn't really be a point if 1) above was taken into consideration. KSP does not make this easy, but no helicopter has ever had any form of "SAS" and the latest versions theoretically allow this. If we put 1 and 2 together, a "standard" single rotor design should be possible and flyable. I've been messing around with it myself, (limited) time allowing. Reading your post, I was hoping you'd fully solved the problem but alas. With the addition of the KAS-1000 controller it should be possible to modify the tail torque to match the main rotor torque such that the craft presents a linear and human-flyable input system just like a real helicopter. 3) Updates: The first few versions of breaking ground did not control the surfaces sensibly. They still treated the spinning blade as a fixed wing and pushing cyclic forward would increase the flap angle on *both* sides of the rotor. For these versions is was impossible to make helicopters other than the original purely SAS controlled ones. I implore you to look up the exact version and mention this, I think it's 1.11.0, but I may be wrong.

Far from the "latest and greatest", but I just use this: Realplume Stock which includes Smokescreen & using: maximumActiveParticles = 800 equates to an essentially free sound & graphics upgrade on my system. Not sure what Waterfall is, but I've known about Realplume for many years. The fact it seemed to be tied to RP-1 or some other intrusive, graphics board abusing addon prevented me from bothering with it until now. It's still unavoidably linked to Smokescreen obviously, but it includes configs for nearly all the stock engines, including both the mods. If you follow the spacedock references back, I think it's a re-compile/re-package from linuxguru? Can't remember.

There is a setting called "Max Physics Delta" you may want to change if your craft is complicated and enormous. Later fixes in the game (>= 1.8 from memory) mean that "on-rails" and part loading switching no longer screws up orbits as drastically as it once did, but if you don't give the game enough time to calculate the physics properly, wierd excrements like this can happen. Traditionally, it has been blamed on "The Kraken". I'm about to launch a similar orbitally constructed ship to Laythe and Bop (to see the dead Kraken :), but my setting is 0.04s. I seem to have no problems with timewarp in a 100km, near 0 eccentricity orbit. Note that there are now additional settings: "Ease in Gravity" and "Orbital Drift Compensation". The latter I suspect you may wish to ensure is on (for some reason they made the previously mentioned on-rails bugfix an option).

Rename your savegame so that it only contains alphanumeric characters. e.g. "My amazing trip to Mün" == "MyamazingtriptoMuen" You can change it back after saving from ~1.10+, it was an anomaly related to the language translations.

The native alarm clock is completely broken in many ways. It is entirely useless. The Kerbal Alarm Clock addon is an appropriate workaround. (This message was not subsidised by the legal owners of KAC, it's subsiduaries and/or affiliate companies)

A simple goo experiment huh? Your kerbal didnt happen to grab a sample from a nearby rocket while he was placing it, and return to Kerbin in the meantime? Check the science centre - and your specific environment. If your kerbal already brought back 100% of it, the remote experiment will just store it internally because theres no benefit in transmitting it.

Now you know why they "nickname" missions really dumb things like "curiosity", "hope", etc In all seriousness, once your rocket no longer exists in the KSP world it is deleted from persistence.sfs.

It is barely scaled mathematically, and mostly hard coded: // Schedule, ratings and modes: // orbit kerbin = +1, LAUNCH, KE_CIRC, MU_INT, MU_TCM // flyby mun = +1, MU_TCM // orbit mun = +1, MU_CIRC, MU_ESC // flyby minmus = +1, KE_INTMIN, KE_TCMMIN, MI_TCM // orbit minmus = +1, MI_CIRC // land on minmus = +1, MI_LAND, MI_LAUNCH, MI_ESC // plant flag on minmus = +1 (remove flag), N/A // escape kerbin = +1, KE_ESC, SU_RETURN // land on kerbin, KE_BRAKE, KE_LAND ...from an old version of a "tourist" rocket that flew around just to get these points. Please ignore the KE_, MU_ stuff after the commas; they are internal state indicators. 1 point = about 1/3 of a "gold star"/level up, apparently? If you want to get max points for minimal effort, plant a flag on the Muen, orbit Minmus, leave Kerbin SOI, return safely. It will give your kerbal 3 stars. Enough for most Kerbals to repair things, fly properly, etc... and basically be proficient. Instead of bumbling around like little green idiots.

Ivcastro, please do everyone a favour and click on the icon beside Kerb24's name to mark this as SOLVED.

https://sourceforge.net/p/obtlib/code/HEAD/tree/head/Ships/Script/obtlib/launchwait.ks ... it requires a hell of alot of ugly maths if you want to do it accurately (that is by no means accurately), but a "dumb" human can do it equally as well by eye... It just requires an understanding of where the target orbit and the "assumed" orbit the ground object is under cross. Thus the mathematical name for it: "cross product"?

It's not technically for "lifting the nose", it's so that the elevators act as a fulcrum and are able to rotate the aircraft. The CoM (yellow/black ball), the rear wheels and the rear control surface should form a triangle. If you look closely at the image in my last post, the craft actually has a distinct nose-low configuration when on the ground, yet it's liftoff speed is only about 60m/s. There are some wings in the real world that have so much thickness and camber they can still generate lift at slightly negative AoA, like the J-3 Cub (from memory), but that's a topic for aerospace engineers, not KSP I am quite impressed by the way KSP does it - it seems to reshape the wing (in the editor?) so that these flat planks end up being modelled as proper wings with camber, reynolds numbers and the leading edge is facing the right way. Therefore "somehow" they end up generating at least some inherent lift. That said, angle of attack doesn't hurt... until it stalls... or you need more speed!

Actually, it's a VERY good idea to do that because it tells you if the "plane" will drop like a rock or flip backwards uncontrollably, etc. In regards to the actual problem, try rotate-wiggling it a bit? Watch the vectors in various AoA configurations? When you first slap huge pieces on (like whatever disaster is going on with those toroid spikes :), those aerodynimc aids do seem to not work so well until the game redoes the calculations a few times, I've found.

The yellow/black ball (mass) is MUCH too far ahead of the cyan/black ball (lift). All you've made is a front-heavy dart...assuming you get it off the ground. Be sure to move the rear landing gear when you fix it (it is about right, relatively speaking for now). https://ibb.co/LRXCwxb Rudders rarely help with steering, since aircraft roll, then pitch, and don't just turn sideways like a car. I say leave it, you have bigger problems to fix.

Isn't this (accidentally) by design? KSP is not a submarine simulator! In real life, if you put a propellor designed for air into an incredibly dense fluid like water, it would immediately shatter into a bagillion pieces, or bend into a useless clump of metal. I don't see a problem here. Come on, be reasonable. Personally the fact that Jet-Turbines work in water is already ridiculous.

I concur with this for KSP 1.12.0. As I prefer to use a 3 button trackball without a scroll-wheel, I barely care, but did notice it. I wonder if it's specific to linux? What about the BSD users (MacOS)? I did try to invert the controls in the settings menu, but it didn't do anything *shrug*. I guess that is broken too. So, no workaround yet... I haven't perused the settings.cfg yet for anything relevent. Maybe you want to?

After careful reading, I notice that the file descriptor iterators need a :next after opening a file. Sorry about that, problem solved. The developers might want to change that error message to something less panicky, like "invalid iterator", though. During my fiddling, I did notice that :atend does not work at all. Nothing in the docs about it, it *always* returns "False". The docs mention that :reset no longer works, I wonder if :atend lost its functionality in the process. Certainly worth a look.

Janus92, Do you plan to release your work? Those images are quite impressive. I've nearly perfected the same thing for bodies which have no atmosphere. Available at http://obtlib.sourceforge.net mentioned above - file landnatm.ks. I won't link to the direct file because it depends on a few other parts of the system. I've had a go at atmospheric versions, but never really nailed it. A long time ago a guy made a similar thing: His relied heavily on RCS and B.R.A.K.E.S. (or whatever they're called now) and quite a few fudge factors from memory. but he had some innovative vector calculations in there. I am too dumb to understand them, but seeing your cute little targeting triangles, I figure you might be interested.

...just noticed i gave the head revision, you'll want r83 if you are looking at that URL in the future. "ooo time travel! magical"

...it's more likely you want R * V, rather than the more logical V *R... because that's the way matrices in maths work On another topic, if someone wants to set DEBUG to True. and take a look at: https://sourceforge.net/p/obtlib/code/HEAD/tree/head/Ships/Script/obtlib/lib/obtlib_mission.ks https://imgur.com/z6uQoxk (slightly more advanced, working copy - also points out another error in kOS caused by "peeklog()") I've been warned off trying to use the normal file access in kOS before, but for this case, JSON is far overdoing it and entirely unnecessary. All I need is a simple line by line access to files. Also there's that "Contact the developers" thing. Normally I'd put this on github, but with the forced password changes a while back, I've lost access to my github account and I have little reason or desire to make a new one. Cheers. (no, i'm not called Kevin

Ah, figured it out: I misread the priority thing and had them the wrong way around. I'll leave this post instead of deleting it before anyone has read it because there is so little information about this topic.

Hello, Ive been getting the message in the title sometimes. I beleive it is caused by renaming a .craft file, but not editing the name contained in it. Usually, the game does a pretty good job at guessing, but in a few cases it seems to be doing strange things. e.g. The root part in this case is the probe called "R5 Angara". Why does it want to rename it to the rover core (RedAnt) and how do I stop it from doing that? The craft file's internal name is set correctly as follows: ship = R5 Angara version = 1.11.2 description = Angara R5 powered Red Ant bound for Dres.¨¨ This is also the development craft for the R5. Real max. payload is 25t. Copy to Subassembly.¨¨ Due to kerbal scaling, if this were to scale, it would have waaaay too much fuel, so we had to shorten it. It's also only supposed to carry 25t, but this one can carry much, much more.¨ type = VAB My google searches returned nothing about this relatively new feature so I ask here. I should point out that this craft file was pretty old and still uses some of the archived parts (they are still in the game, but not in the "Filter by Function" section of the part list). Not sure if that matters. N.B. As the "Insert image from URL" part of this forum is broken, I was unable to test before posting if they work. I'll try to fix in edit, but as I write this, I can only see the URL and can't check if the forum can access them. If not, the two images are of the rename ship message being displayed and the 3 probe PAWs showing vessel renaming properties. I see nothing unusual about them.

Number 2 is in the Changelog: It could get mildly annoying, but I'd rather have that, than it starting inside "vessels" (I assume they mean ships connected to large asteroids ... and comets?). That's much more confusing and disorienting. I guess they could make everyone happy by including the asteroid/comet when calculating whatever "appropriate distance" means? Oh, and FYI the option FLT_CAMERA_ZOOM_SENS = in settings.cfg can be used to change how fast zoom works. I have mine set pretty high, so a quick jab of the zoom button usually brings us back to a sane distance.

Tried rotating them 180 degrees before attaching them? Some of the IR/breaking ground parts have wierd affinities.

Heh, I'd hope they would wait a bit more than a few days to find & fix *extremely minor* bugs. I have to say, this is one of the cleanest, most bug free major releases I've ever seen, so congratulations to (whats left of) squad. I'm still testing, but so far, this is the only problem I've found.