nhnifong

Completely aside from how they work in theory or in real life, how do you keep a multi-part prop blade in KSP from stretching ridiculous amounts at the joints?

Here are some lessons I've learned from prop design - A prop where the blades are connected directly to the spinning collider of the motor, and are one part only is the lest likely to self destruct, though it still won't hold up under 2x time warp. Multipart blades stretch too much at max RPM, it doesn't matter what kind of parts they are, cubic strut, servo, fin, etc. Stick to a single part for the blades. The part which makes the best blade for me is the basic fin because It's light and therefore doesn't stretch out as far has the best lift/mass ratio of any lifting part is small to fit in more fairings. Since it's small, use a lot of them per motor, maybe 12 per prop or more. Unfortunately putting props anywhere except inline with the center of an aircraft causes disastrous unbalanced forces as soon as the plane is flying non-straight. Two nacelles, one under each wing, does not work. clipping 2 or 4 props inline in the center of the plane body works well. Have half of them spinning clockwise and half spinning anticlockwise. The best pitch for me was about 60. (90 being parallel to the direction of flight). Doubling up motors to get higher RPM isn't effective, it's basically as destructive as 2x time warp.

How does one make a high-thrust electric propeller in KSP? You may have noticed that if you just stick some blades on an electric motor it does generate thrust, but not very much. I'd ballpark the one I made with a medium motor and three small blades at 10kN. So here are some thoughts about propellers. The propellers will products a constant max torque and consume a constant maximum amount of power. It's not very much power so I won't focus at all on how to make more efficient propellers. There is no way to make more thrust by consuming more power from a given motor. It's as if they're driven by a constant current supply (real motors can consume more power until they overheat) The thrust generated is maximized when the prop is spinning at it's maximum RPM, all other things being equal. Max RPM is limited in two ways: 1. Spinning too fast may destroy blades because they stretch away from the hub and either hit the ground, or break off. The craft does not self-collide though. 2. There is a point where the counter rotational drag on the blades exceeds the torque coming from the motor and RPM decelerates. At rest, for a given pitch (discussed below) the counter rotational drag on the blades is proportional to the thrust they're giving you. So you want to add more of it until it's almost equal to the torque your motor can apply. You'll know you've succeeded at this if your propeller takes a very long time to spin up. The counter rotational drag on the blades will increase with the total amount of wing area of the blades, the distance from the center hub of that wing area, the air pressure, and the angle of attack of the blades, and the speed of the blades through the air. Thus if you have enough wing that counter rotating drag is nearly equal to torque, you'll find max RPM limited not by the slider, but by the drag of the blades themselves. As the blades spin faster, this drag increases until it exceeds torque and your blades slow back down. This is what you want your RPM limited by for maximum performance. There's another irritating limit on max speed - the fact that the blades will stretch away from the hub and either hit the ground or break off. You can limit this by using lighter blades, making blades out of a s few parts as possible, and keeping blade COMs close to the hub Amount of wing area can be increased with number of blades or bigger blades. consider these interchangeable. You can see that there is a tricky design trade off between having a lot of blade wing area far from the hub, and minimizing stretch. Especially since it's not just stretch you're probably concerned about but the effective diameter of your prop so it doesn't hit the ground. The angle of attack of the blades is very important. At a stop, blades at a high angle, say 45°, would create the most force (and thus require less blade area to do the same job) but as your craft speeds up, the effective angle of attack of the blades decreases. Imagine them screwing into the air. at some point, your blades are spiraling through the air at exactly the angle they're mounted at and applying no force (but there is virtually no counter rotating drag either) Then, if you were to go faster than that, say by diving or turning on a rocket engine. They'd actually start causing drag on your craft, even when the motor is spinning at max speed. Worse, the air spins up the propeller faster than it's designed to go, and they usually destroy themselves past 500 RPM. Instead of measuring the pitch of the blades in degrees, it's helpful to measure it in the distance in meters that the blade would screw through in one revolution, a blade mounted at 20°, with it's center (the place where KSP applies all forces) 1m from the hub, would travel a distance of 2π meters, up at a 20° slant. The forward travel is then tan(20°)*2π = 2.29m. So if it spins at 360 RPM, (six revs per second) then it wants to screw through 2.29*6= 13.74 meters of air per second. if the craft moves forward at 13 m/s, it produces a little bit of thrust until the craft moves forward at 13.74 m/s and it produces no thrust. If we reached this speed and want more trust we have to either spin the prop faster, slow the craft down (booo) or change the pitch. My formula says increase it it but this is the part I don't quite understand. What would a pitch of 89° give us? at 360rpm the blades would want to screw through 2159 meters of air, which is a respectable flying speed, but somehow I know it's not going to work. they're practically paddleboards at that angle and most of the force they make would be counter rotational drag, which would limit the max RPM we can reach, probably nowhere near 360. This craft airspeed at which the blade's angle of attack becomes 0, and we can't increase the RPM any more will end up being our cruising speed. The counter rotating drag on the blades at this speed should be zero, since they're just cutting through the air without doing anything. Since blades seem to function this way, it would seem they're much better suited to hovering than to winged flight. The ideal pitch depends on many factors that change during flight so aim to use the movsble fins as your prop parts. How can a control input be mapped to the blades independent of their orientation on the craft? airbrake function? I want to increase the number of blades until the counter rotating drag produced is enough that it begins to limit my max RPM, not the slider. At craft speeds close enough to my pitch-determined maximum, ultimately the slider will limit my max RPM no matter what, and I want that speed to be high, which means I want the pitch to be close to 90, which would mean high counter rotating drag. What exactly is the drawback to having a pitch close to 90 anyways?

It should be possible to save some dv on an Eve ascent with electric propellers. I know the props cannot make much thrust, but I'm counting on large folding fixed wings and a gradual ascent. Maybe optimistic but I expect to be able to reach 30km altitude on electric propulsion and then reach orbit with a 3500 dv rocket. Payload 1000kg.

Yesterday's update fixed it. Must have been a bug.

I've deployed a set of experiments on Duna, but haven't gotten any science from it after a few years. The cluster consists of 1 controller, 1 weather, 1 goo, 1 seismic, and 6 solar panels. All deployed by a level 0 scientist. The controller was the last part deployed. They have adequate connection to Kerbin most of the time. They have power during the daytime. They were all enabled when I left. They are all within range of eachother. When I left them, the controller said 3 experiments connected. But a few game hours later, it says only 1 is connected. Even this connected one (I don't know which it is) has not produced any science. I did get science back from minimus with a similar setup.

Very clever! If the terrain collider doesn't exist past that speed though, why does the craft sink a little bit and then explode? It clearly hit some other (possibly lower resolution) collider right? Or else it would have sunk about 10 meters to the ocean under the ice cap.

Really? That sounds like good news. Pardon the stupid question, but what do I need to do to use NathanKell's improvements?

Rather than fix every part, wouldn't it be quicker to scale down the density of water on all planets, and then fix a few parts that should still float? Is there any configurable way to do that?

The core life is a prediction of how long the EnrichedUranium would last if the reactor were running a full power the whole time. To make it last longer, either turn down the power level in the reactor's context menu (also available in flight) or bring more EnrichedUranium in fuel containers.

Hahaha! I hadn't checked how much it would be. Yikes. I've only gone out to gas giants so far with nerva-type engines, but I've recently unlocked lithium plasma thrusters, and I'll probably go with those for the Ulrum crew vessel. Probably with a reactor in the range of 4000 EC/s. There's probably an optimum somewhere between heavy hab long trip, and heavy fuel short trip but I don't know what it is yet.

I think one of the most fun parts of KSP and MKS to me is the challenge of making a compact and low-mass vehicle that unpacks into a large, spacious and highly functional base or station at the destination. I think the angle I'm going to take with my Ulrum mission is to send a large packed station ahead of time, and later send a super-fast manned ship on a ~1y trajectory to meet up with it and deposit the crew, who will unpack it. If you say deep freeze is too easy, I'll take your word for it

I'm certainly not just looking for a way to circumvent the challenge! But I thought that a long journey (10+ years) might call for a different strategy than a medium one.

Has anyone looked into the feasibility of keeping kerbals "on ice" for long journeys? (let them become tourists and revive them when they reach the destination) Say I'm taking an 11 year journey out to Ulrum with 10 kerbals. I would plan to have a habitat only large enough to keep a single medic happy for 11 years, but let everyone else become a tourist (can effectively isolate habitats on the same vessel?) I would also carry a med bay and colony supplies to revive the kerbals when they reach Ulrum. But it looks like this is not a better use of mass than just bringing a bigger habitat unfortunately. It seems to revive 9 kerbs of 10 years of homesickness would require 9*10*6*416=224640 Colony Supplies (349t) But maybe it is still a viable strategy if the revival method is just to expand a very large habitat when we reach ulrum, and transfer all the tourists into it.

Also, the wiki says "Once your Hab timers reach the same level as the highest Habitat they've been in, the Colonization Module will freeze the Hab Timers at their maximum amount." Does that mean it will freeze at the highest value of the largest habitat the kerbal has been in, if one kerbal were alone in it, or the highest share of a habitat the kerbal under treatment has ever experienced?

Nowhere is the effect that medbays and colonization modules have on home time documented in numerical terms, So I'm taking a guess at how it works https://github.com/UmbraSpaceIndustries/MKS/search?utf8=✓&q=TimeMultiplier&type= Seems to show that all the med bay and colonization modules share a parameter called TimeMultiplier. It is correct to say that if the duna medbay has a TimeMultiplier of 2, then it runs the kerbal-under-treatment's home and hab timers backwards at 2x speed while active?

Try pressing Alt-X to clear trim. (right shift x on linux) Was that broken? Cause I was never quite sure if my dishes got used as relays, and I know I bought the upgrade. I'd never once seen them do it. Greatly relieved that there may be a fix for it. Just hoping I will not encounter problems merging said fix into my 1.2.2 install, as It would be too much trouble to upgrade KSP to 1.3

Hi, just dropping by to say I love this mod and thanks for the hard work it really makes the end-game more challenging.

Thanks for the reply. Yes that may very will be more helpful.

Hey there, I'm looking for a way to show resource rates of change to more than 6 decimal places, so I can assess bottlenecks in my MKS base. Does this mod do that, or can it be configured to do so? Looks like a no but I could be wrong. Thanks.

Thank you voicey99 for helping me find the workshop

WHA!? Could it really be that simple! No I have not researched that yet. Damn If only I had tried that before I went to work. >_<

I suspected CTT recently as well, It was in my save from the start, but MKS was recently added. I can confirm that without CTT, the workshop does appear! But how can I continue my current game without the tech tree? Perhaps uninstalling both and then putting them back in the reverse order somehow helps, or maybe there are some CTT configs to be deleted and restored.

I tried that, but it's completely identical. Inflatable Workshop shows up in sandbox mod but not carreer mode it seems. (at least I can't find it in Andvanced Construction in R&D, or in the Manufacturing category, or by search) Do you know of any other reasons why something shows up in sandbox and not carreer?

What does this part mean? [LOG 20:23:48.688] [ModuleManager] Deleting Node in file UmbraSpaceIndustries/MKS/OSE subnode: @PART[Ranger_Workshop]:NEEDS[Workshop] as it can't satisfy its NEEDS It's dropping the OSE support due to OSE not being installed? Would that prevent the part from loading?