VincentLaw

One day left until 1.0, but I figured I'd make an entry anyway. It's been a while since I played with roller bearings. After a number of iterations I came up with this bearing which is pretty stable at both high angular velocity and high torque. The propeller could probably use some improvement, and The craft has too many parts to be of practical use, but I managed to hit 160 m/s at 10217 m before running out of fuel. Each shaft is powered by 16 turbojet engines which can get pretty messy with particles, so the only mod used was disabling particle effects to reduce lag. Craft file download here. No guarantee it will work with 1.0: https://drive.google.com/file/d/0BzhG7bt4aJ2dZHl2c2c2eHh3WHM/view?usp=sharing Another screenshot: http://i.imgur.com/BWeI79h.jpg

I tried using a screw to control the height. It kind of worked, but It couldn't lift very much weight. The ramp is probably better. Also, reaction wheels worked better for controlling rotation than the powered wheels. You can also see a weird bug in this picture that caused the root part (structural fuselage) to be improperly scaled.

Dun dun dun.... download: https://www.dropbox.com/s/c6h7021p0p7ma72/Wheel.craft no jet engines, no ion engines, infinite range, 100% stock.

Your prop came off because you cut the throttle to 0%. You should keep it at 15% throttle or more even when coming in for a landing (until you come to a complete stop) so that the prop stays spin stabilized. I had to use a different bearing design because of the ARM patch, and the joint on this one isn't very stable. Also, as I hinted at in the first post, it goes slowly at launch because of the fixed pitch propeller. I designed the propeller for maximum speed, so it doesn't get much thrust at low speed. If you wanted higher acceleration at low speed, then it would reduce the max speed.

The ARM update broke my old helicopters, so I decided to revisit the stock turboprop. (my last turboprop was in version 0.17) These designs use decouplers as bearings so that the rotating part is not separate from the craft (a la roller bearings). With my experience from other projects, I was able to make this faster, smaller, and more maneuverable that my previous turboprop. The tail and wings keep it stable enough that contra-rotation is not needed. I also switched from tricycle gear to conventional gear for prop clearance and including tail wheel steering. Notes: *Sometimes the propeller will break on start. This is a KSP bug. Just reload the mission. *Do not exceed 60 m/s or the prop may become unstable and can separate. *Never reduce throttle below 15% unless parked at 0 m/s (even when landing and taxiing). Low prop RPM while moving can make the prop unstable. *Never time warp. *Do not press the stage button more than once or else the prop will separate. *Be careful not to brake too much to avoid nosing over. *Recommended cruise speed 55 m/s. *Landing speed ~35 m/s. *Thrust increases with speed because it is a fixed pitch propeller (The prop is stalled out at low speed). *~200 part count. Download link: https://www.dropbox.com/s/myxolpz322b04hz/Turboprop%20Mk_%202.craft Swirly Exhaust: Island Flyover:

I redirected an asteroid:

First off, nice job Aphobius. I'll just make an entry with this old thing. It is a practical heavy lift helicopter. Unlike the post above this by ihtoit, no mod parts were used. 3076 m altitude 62.8 km from KSP As you can see, I had plenty of fuel to go futher, but I got bored. It flies more slowly than a slug. The little distance indicator there is at KSP on the other side of the mountain range. I accidentally exited the flight after landing so I lost the F3 screen info. And the download link: https://www.dropbox.com/s/scfpgat6ocw1n32/Heavy%20Helicopter.craft (or the thread if you want more details http://forum.kerbalspaceprogram.com/threads/55393-Stock-Helicopter )

Thanks. He did a good job of not exceeding the roll input limitations. I like that he showed the ejection system too. The rotors are most likely tearing themselves apart because you don't have any struts connecting the rotor arms. You should run at least one strut between the I-beams across the middle that isn't connected to the decouplers. This will reduce the stress on the decouplers and help keep them from bending unevenly.Your lift problem could be solved by adding more fins, increasing the length of the blades, or possibly increasing the angle of incidence of the blades. The larger the rotor, the more efficient it will be. You also would not have any pitch authority if you did manage to take off because the blades are not angled as I showed in the picture on page 2. You would not have any yaw authority either because of the missing vertical fins at the rotor tips.

It's not that difficult to make the rotors not pass through each other, but since KSP doesn't detect same-ship collision, it doesn't really matter, and it makes designs a bit more bulky. Jet engine exhaust used to have a "laser beam of doom" effect that would destroy any part that got behind it (within a certain distance). For this reason, it used to be necessary to design rotors so that the blades did not intersect. That is why I used to prefer coaxial design because it was the easiest way to keep parts out of the exhaust. If you look at this design, you can see how difficult it used to be to make designs that were not coaxial. Those props are about as close as they could get to the fuselage without the exhaust shearing it in half. http://forum.kerbalspaceprogram.com/threads/21688-Stock-0-17-TurboPROP-%28fully-functional-propellers%29?highlight=turboprop (If you want to comment on that design, do in this thread) You could try slowly modifying my design until you have something different. My cargo helicopter just used a modified subasssembly from the first one in this thread, so I didn't have to redo the rotor from scratch. (unfortunately the subassembly didn't preserve strut connections). Otherwise, send me the file and I can tell you what you are doing incorrectly.

It is possible, but there is a reason I use contra-rotating rotors in my helicopters. Reaction wheels provide only a tiny fraction of the torque that the jet engines produce, which is why I called them "ballast" in the first post, They are not very effective for counter torque. RCS works if you give it a long enough moment arm, but it runs out of fuel quickly. mounting a jet engine sideways like a tail rotor works, but jet engines have too much thrust, so they have to be mounted on a short arm to provide the correct torque, which causes a large side force. using a small rocket engine has the same problem as RCS of bad fuel efficiency. One thing I have not tried is more fins at the rotor tips to control yaw enough for counter-torque. It would not make sense for that to work, but sometimes KSP doesn't make sense, so it can be worth trying ideas that seem illogical. Another problem with a single rotor design is there is no way to control roll with a single rotor in KSP (unless you mount the cockpit vertically, then the controls act differently) so you would either need a ton of reaction wheels, or RCS for roll control. As you can see in one of my posts on page 2, roll input basically works like a collective that depends upon the direction of rotation, so if the rotor is mounted at the center of mass, it doesn't induce roll. The main advantages of a single rotor design would be lower part count, and lower chances of the sticky bug affecting the rotor (it seems to affect parts randomly, so less rotors means less chances of sticking).

This should help as long as you are not color blind. If you are colorblind an unable to decipher these, let me know and I might number them or something. For first image: The red angle gives pitch authority to the rotor blades. The higher the angle, the more pitch authority, but at the cost of lift. I am guessing getting the angle backwards will invert your pitch controls, but I have not tested it. The cyan angle is the angle of incidence of the blade. This is necessary to generate lift. for wing parts, the ideal angle is probably around 20 degrees for hovering. Steeper angles increase power required to hover, but increase max speed. (I'm not sure if control surfaces can stall in KSP, so steeper angles may be better. Maybe someone can confirm this.) The green control surfaces give yaw authority. They also act as stabilizers, but reduce max speed. The yellow circle is a micronode. These are very strong joints, so it helps keep the engine from breaking off. The blue strut increases engine efficiency. Without it, momentum will cause the engine to point at an angle. For second image: The cyan strut reduces axial loading on the rotor hub and keeps the rotor blades inline. Without it, they will bend around wildly. The green vertical decoupler allows the rotor blades to rotate relatively freely around the mast. Being connected to an I-beam seems to mitigate (but not eliminate) the new sticky bug. It acts like a periodic torsion spring, so really lightweight rotor blades will get stuck easily at low throttle. The red horizontal decouplers are attached using symmetry so that they are equal distances from the axis of rotation. They allow rotation of the rotor disk relative to the mast to reduce out of plane torque on the rotor hub. Without it, rotor failure is inevitable. If you want to eject the rotor blades for some reason, these are the best decouplers to use since they will be flung away from the craft. For third image: The red distance determines roll authority. The larger the gap, the stronger roll controls will be. Left roll input increases the lift on a counterclockwise spinning rotor and decreases the lift on a clockwise spinning rotor. Right roll input does the opposite respectively. For this reason, the left rotor should always spin clockwise and the right rotor should always spin counterclockwise (when viewed from above and behind). If you get it backwards, then your roll controls will be inverted. The blue stack separator is not necessary, but it absorbs some of the shock between the rotors and the fuselage. I'm not actually sure if the green decoupler does anything. It might mitigate the sticky bug, or it might not do anything useful. As you can see, there is complete three axis control from the rotors themselves, and the contrarotation cancels torque. so RCS, SAS, reaction wheels, etc. are not necessary. If you are trying to make an SSTO, you might actually want to take all controls off of the rotors and just use wing parts on them, since control input may cause them to rotate at speed. If you are going high speed and the rotor tries to rotate, it will most likely be ripped off. You can also see how I put vertical stabilizers on one end of the rotor blades on my SSTO to help keep them from rotating. Tip: the center of lift of the swept wing part is at the root of the wing, so it's actually better to mount them from the outside of the rotor disk pointing in.

It relies on a physics exploit. It used to work really well, but now (since 0.21) there is a bug that makes it hit and miss. Basically, all parts are wobbly to a certain degree, but decouplers are extra wobbly. Certain combinations of parts make them even more wobbly (to the point of being able to rotate indefinitely), but now there is a bug that makes some parts completely rigid some of the time for no reason. It seems that certain combinations of parts make the new bug happen less frequently, but I honestly don't understand the new bug. No download link because it is not compatible with this 0.22. It could only barely make it into orbit, but I could probably do a better design now. Obviously it is a hybrid helicopter, so it stowed the rotors for minimum drag and went into space like an airplane. It was capable of transition between helicopter and airplane modes during flight.

Okay, Here it is flying around with the world's ugliest bus. (Also, I just updated the file to remove the canards. They were causing undesired pitching.)

Since RocketscientistV expressed interest, here is a cargo helicopter. (cargo not included). Again, I recommend quicksaving before spooling up, and if the rotors get stuck, quickload and it will probably work the second time. This one also sometimes has a problem with unbalanced torque which I have not figured out. I blame KSP inconsistent physics bugs. helicopter download link here: https://www.dropbox.com/s/scfpgat6ocw1n32/Heavy%20Helicopter.craft (warning, 304 parts) It can lift the equivalent mass of about one orange fuel tank, so basically anything you can drive into the cargo bay is liftable. Press 1 to open and close the gate on the back. Raise the landing gear while on the ground to make it easier to drive cargo in. Cargo used in the screenshots is MeticulousMitch's Delorean DMC 12, available here: http://forum.kerbalspaceprogram.com/threads/49670-Cars-by-MeticulousMitch?highlight=delorean Screenshots:

Yes, wing parts can be used for the structural elements, but it's more difficult to get good symmetry using only wing pieces, and wings are less structurally sound for various reasons. Also, wing pieces near the center of the rotor disk are much less efficient than wing pieces near the rotor tips, so those end up mostly producing drag except under precise circumstances.(I just updated the craft file to remove some garbage like unconnected struts and fuel lines.)

Picture first, then details. Download link here: https://www.dropbox.com/s/3d7caiivkv993na/Light%20Helicopter.craft (Prototype variant. Different tail and lacks ejection system.) I was just messing around with stock helicopter designs to see if the pylon bug is still there in the new update. Unfortunately it is, but I managed to come up with a more reliable rotor design. With this design scheme the rotors get stuck on mission start much less frequently. I'm still not exactly sure why this "workaround" works at all. Mostly just trial and error. I recommend quicksaving before spooling up, then if it does get stuck just reload and it should work the second time. You are free to modify/redistribute but I don't guarantee it will work properly if you change anything. Max speed ~55 m/s (level flight) Controls are mostly like you would expect them to be for a helicopter, except it uses throttle instead of collective, which makes the response time terrible. Just remember that lift depends on rotor rpm, not engine rpm or throttle. Hover is around 30% throttle with full tanks. The SAS helps stabilize a little, but it is mostly there for ballast. I have not tested landing with empty fuel tanks, so more ballast may be necessary for that. Be somewhat gentle on the roll controls, and don't try doing barrel rolls or rotor failure may occur. The limiting factor here that causes rotor failure is the angle between the rotor disk and the mast. The larger the angle becomes, the more undesired torque occurs at the hub. The first stage is engines, the second stage ejects the rotor blades, the third stage ejects the cockpit (zero-zero capable), and the fourth stage is a parachute. If you try to blend the second and third stages, then the blades won't eject, and launching yourself into blades is generally a bad idea. Improvements over my previous design: Higher speed Vastly less prone to rotor failure More fuel (range) More stable This design is mostly just for flying around for the fun of it. I may do a cargo helicopter later.

I tried using I-beams with structural pylons in a rotor hub design, but it didn't work, so I tried the standard radial decoupler and had more consistent results. It seems that when the decoupler gets stuck, the I-beam will spin, and when the I-beam is stuck, the decoupler will spin. These alternate modes have different amounts of friction, so if the two rotors are stuck in opposite modes, there will be an unbalanced torque. To mitigate this, I gave the helicopter extra yaw authority and a bunch of SAS. The new 0.21 reaction wheel implementation may be strong enough to control yaw, pitch, and roll entirely without rotor input, which would allow for greatly simplified rotor design. This helicopter has a lot of stability/integrity problems though, and needs a redesign. I also discovered that if you make a part other than the cockpit the root part and it separates in a crash, the view/control will not follow the cockpit, and the pilot will be helpless. More relevant to this topic: when I had the bearing I-beam connected to a micronode, both the I-beam and the decoupler could fail to rotate. Currently I have the I-beam mounted to a cubic octagonal strut and I have not had a rotation failure yet. I am not really sure what causes these rotation problems, but from my recent testing the physics have been inconsistent (varying between scene load), so I would say the locked structural pylon is in fact a bug, not a bug fix. I have included my helicopter craft file as an example of a working rotor hub in 0.21. I assume it can also be applied to the motorized hinge system. https://www.dropbox.com/s/p2wibk4u2yrj29g/Clover%201.craft

As per rule 3.4, most forums prohibit criticism of moderation even if it is at fault. (and since I am just informing you of the rule and not enforcing it, I am probably not violating rule 3.2) However, it is quite possible to create a stock craft that flies using only pod torque and roller bearings without the infiniglide bug. Making a craft fly with ion engines is comparatively easy. Despite the fact that ksp wings have physically impossible stats, infiniglide only applies to control surfaces, not wings, so any craft without control surfaces will not have infiniglide. This is not an official entry. It is also from 0.19 I think, so untested in 0.21.

Discovered 0.21 broke my stock helicopters (structural pylon bearings). Although technically I guess that is a bug fix. Spent the past couple hours trying to work around it to no avail.

I thought some people might be interested to see this. While KSP didn't make the headline, it got a tag and a video link. The article is currently on the front page of pcgamer.com, but I have included a link directly to it. http://www.pcgamer.com/2012/10/03/todays-other-news-guild-wars-2-gets-patched-war-of-the-roses-releases/ Congratulations to twigg82 for getting your video featured and to the KSP team for being awesome.

I am now going to refer you to this link as I think it will fix your problem: http://kerbalspaceprogram.com/forum/showthread.php/20983-Kellven-Fixes-your-FPS-Round-2-Kerbin-Lag-Fix

Have you tried disabling the SM3 terrain shaders? It will disable the water transparency effect.

This is correct. Basically the further aft your center of lift is, the more stable your airplane is. The problem with this is that as your center of lift moves back, your maneuverability decreases and you may not have enough control authority to trim for level flight anymore. This can be solved by increasing the size of your elevators or giving them a longer moment arm. Basically it does not matter if your center of lift is not on the center of mass to fly level, it just matters that the pitching moment at the center of mass is zero, and you want the pitching moments of disturbed flight to return the airplane to its original orientation. This would work even if your airplane had negligible drag because the lift (and therefore moment) of your wings and stabilizers is a function of angle of attack. Also, since fuel usually drains towards the back of the airplane in KSP, it is not a good idea to place the center of lift directly on the center of mass during construction, because your airplane may be stable at takeoff, and then after a while of flying become unstable and crash into the ground. You want your center of lift to be just behind the furthest aft possible center of mass.

That statement is 100% contradictory. "Feature Complete" very obviously includes a working career mode (and associated features), which would be new content. I am personally hoping that base building, refueling, and more types of generic mechanical parts (eg. docking ports, rotating devices, etc.) are also considered prerequisites to feature complete. 0.18 will probably include things in the most logical order to improve or compliment already existing features. Its just up to the devs to decide what that order is, and what those things are.

The hub of the entire propeller assembly is held together by a single structural pylon with no struts between the propeller and the main structure of the airplane. Using symmetry in the VAB causes the attached blades to be distributed evenly around the center of rotation of the structural pylon. This means only one of the blades physically touches the pylon and the rest float around it at the same radius. The structural pylon provides some resistance to making full rotations, but if you force it all the way it will continue to rotate without breaking, so there is a minimum power required to get the propellers to spin. The small radial decoupler also works, but its not possible to center the rotation around what you mount it to, so that's why I prefer the structural pylon. This construction technique had a bug in 0.16 that would cause the hub to spontaneously explode after about 6 km of travel (someone called it the aerokraken), but that bug was fixed in 0.17, which is why I waited until now to try this design out. I was able to successfully cruise this airplane until my fuel ran out without encountering any bugs. Also I want to emphasize the importance of the counter rotation of the propellers. The friction on the structural pylon is high enough that if you only use one propeller it will spin the entire airplane. A coaxial contra-rotating design can be used to compress the propeller layout, but this results in higher vibration on the mounting point.