Bartybum

Regarding a storyline, I'm not sure I'd want KSP to actually have one that plays out via plot. I'd much prefer we get given small snippets of lore over time that tease information about ancient Kerbals (it's obvious at this point that they had interplanetary ancestors) - stuff like the face and SSTV signal on Duna, the Kraken, the ruins on Val, the pyramids near the Dessert launch site. Small bits and bobs that are added from time to time. Stuff that when discovered, incentivizes you with science via contracts to set up a base, collect samples, data, reputation, etc. Nothing necessary, but stuff that'll reward you for your curiosity with snippets about ancient Kerbals. I see this as the perfect non-invasive way of including a story.

[snip] Personally I'm not against the idea of it, as long as it's optional. From what I've gathered you're open to this, so we can move on. My issue is that I don't think it's the time to start tackling it yet - not when after more than six years there's still serious polishing (more complete part sets, weather/clouds) and features (life support, more planets, more systems/FTL) that have been missing from the game - features that are vastly more integral to the mechanics/logistics of spaceflight, and the game's story/identity. Features whose absence leave me feeling like I'm playing an incomplete game. Once that's all done, by all means please, bring it on.

Well you'll need more than that for a discussion lol. I'm talking nothing more complicated than one or two resources, ala the Snacks! mod. It's really nothing complicated.

I understand that some players will relish in the opportunities that more realism offers, but KSP is a game at heart - I can guarantee that 90% of the community isn't gonna care for compressor stall, mixture control, proper starting sequences etc. They just wanna fly in space and visit planets. I'd MUCH rather the devs focus their efforts on content that majority of the playerbase will want to utilise - more/better parts (we REALLY need more adapters, long/short landing wheel varieties, more 0.625m fuel tanks, etc.), basic life support, more planets, clouds, art improvements, etc.

I mean, it's not really fair to blame them, because it's in the name - COUNTER-clockwise, "counter" meaning "opposite to the default", the default being clockwise. I don't really think one should be worried about default settings not lining up with arbitrary standard practices, especially since Kerbals are their own nationality. To me, the issues relating to physics are much more important than those relating to national convention.

I wonder if having tweakable prop discs as a single part would’ve been a better idea. That way you could use smaller fudge factors.

Yeah no you’re right, that’s pretty much what my argument stems from. It’s more about the principle of it, and teaching KSP players the right thing. Because at the moment what it teaches imo makes it more difficult than it should be. Regarding the European CW/CCW stuff, that doesn’t really apply to me because I already knew that the direction was defined being viewed from the front. But yeah, changing your engine to CCW fixes the invert issue.

Sorry, I should probably elaborate that when I say that the devs got it wrong, I mean that the blade variants should have been mirrors of each other around a plane 90 degrees to the current mirror plane. The inverted deployment stuff would be solved by changing that. Under my method it'd be like this: Clockwise: Counter-clockwise:

Can you elaborate what you mean by design-time creation of multi-engine layouts?

Relax, he's not being snarky. Single prop aircraft have to deal with the unbalanced torque too. In KSP people just counter the torque with reaction wheels.

I mean, that's quite literally what their method does, if you look at it in game. If you apply negative pitch to the blades, the blade airfoil starts moving backwards through the airflow - just take a look below: (This is a clockwise running motor by the way) If you're wondering what about when the aircraft is flying forwards, I can tell you that the deployment required to produce negative thrust becomes more positive the faster you go. It's why if you reduce deployment your aircraft is forced to slow down. Look, I'm sure they put research into variable pitch propellers, but to me it's obvious they missed this. The whole reason I orient my blades the way I do is that by doing so I always driving the airfoil forwards through the flow, because that's how an airfoil is designed to run, with the curved end at the front, and the pointy end at the back.

You mean collective, not cyclic. Cyclic controls each blade independently, whereas collective controls all at once

This is a bit late, but from my understanding, would it be correct to say this isn't a problem with snack use rising non-linearly with time-warp, but with the EC calculations being tied to delta-time?

I've been thinking about it too, and I think at the very least you'd require some sort of way to detect the angle the rotor hub is at in order to be able to do that, as well as lump various inputs to a single action. To be honest I'd really like to see a primitive scripting system ala WireMod from Garry's Mod, that lets you take output values of a part such as thrust, fuel consumption, mass, capacity, status, etc., and then use those as a list of inputs for another object.

Well I mean, it works in reverse because under my system, pitching the blades backwards induces a negative angle of attack between the flow and the blade, generating negative lift. Don't worry, I saw the edited post I'm all too guilty of doing that myself. But yeah, I'm happy to cop the few extra seconds adjusting stuff, and sit back with the knowledge that what I'm doing is technically the correct way Another thing that I've noticed is that the helicopter blades are set up under my system by default, but the turboprop blades aren't. Quite interesting

Well then, I'm confident in saying the devs got it wrong. Under their system, reverse thrust is done by driving an airfoil backwards into the flow (see below), which is absolutely not how reverse thrust works in real life. Real reverse thrust is done by driving the airfoil forwards but at a negative angle of attack to the flow. Thoughts, devs?

I understand how lift vectors work - I study aerospace engineering I position mine such that 0 deployment corresponds to 0 pitch: And then forward and reverse pitch, respectively: Dunno what to tell you, but that's how I do it. I base it off this: I have no idea what other way people would position the blades.

I can agree with your first point, but only to the point that the devs should've added fixed pitch blades too, for those who aren't interested in variable pitch. Saying that variable pitch blades aren't accurate to real life because they're not fixed blades is not a valid argument, because they're not trying to be fixed blades. Other than that, variable pitch is awesome, and (save for the few problems outlined below) I don't see how else it could be set up. To me it's no more complicated than configuring flaps with an incremental authority limiter. Cyclic-collective pitch propellers are notoriously difficult to build efficiently and stably out of props, and (as far as I'm aware) aren't possible with just the blade and rotor pieces, so I'm not sure what point you're trying to make there. So far I've encountered three main issues: 1. I don't think the symmetry and inversion issues are the fault of the blades, but the way KSP handles multiple symmetry groups for the same part. I've found that if hubs are part of the same symmetry group, then you can't attach X blades to one, and X blades to the other, because the editor will automatically set symmetry to mirror instead of radial, and add a single blade to each hub. As a result you can't have both rotor hubs be part of the same symmetry group, and consequently the hub "invert direction" tweakable becomes redundant when using blades. 2. However (and I WILL fault the blades for this), the deployment of blades is reversed (for me anyway), meaning that positive pitch requires a negative input, which logically doesn't make sense. When you choose the counterclockwise blade variant, the required deployment direction suddenly reverses. This is strongly tied to the fact that different variants are symmetrical around the wrong plane (the opposite blade variant is 180deg backwards, rather than just counterclockwise but still facing forward), so you have to also rotate the blade. 3. There's no hologram indicator to say which orientation is forward facing. These problems are purely editor based, and I'd imagine 2 & 3 are simple fixes (number 1 will be a bit harder). However, once you acknowledge these problems they're super easy to work around.

Oh damn, that's crafty. Any idea if you can simulate a swashplate mechanism with the blades using KAL?

Stock (except for Mechjeb autopilot) King Air bootleg, dubbed Aeris Regent. Max cruise speed at these RPM and blade pitch settings. Weirdly enough, increasing RPM any further reduces acceleration. Uses E-props powered by fuel cells. After flying for an hour at this speed, it's used only 1/6th of its fuel, so this thing could maybe circumnavigate Kerbin, even more so if I added another set of solar panels

@Dragon01 I’ve just thought about another thing - what orientation are the props supposed to be installed at? Because up until now I’ve had them installed them such that 0 deployment corresponds to the props facing into the freestream (full pitch), and 150 deployment corresponds to no pitch (props facing in-plane to the prop disc). I feel like I’ve been doing it wrong, because intuitively, zero deployment should correspond to no pitch and full deployment should correspond to full pitch. I’m gonna go experiment a bit more now. I wish there was some sort of marker you could enable for the prop to help identify whether you’re facing the correct way. EDIT: I can report that I have found a marker! At the edge of the blade (for blade type B anyway) there's a light grey triangle - mount the blades such that when not deployed, the arrow points sideways. That way when you deploy them, the arrow turns forward or backward depending on which way you want to go. This isn't super obvious though, and it took me a bit of time to notice it. I've also found that when cruising, it may be in your interest to reduce your RPM and increase the pitch on your blades. Somehow this resulted in roughly a +25m/s speed boost... this seems fishy

I agree, there should be a double sided limiting slider like for actuators, hinges and servos - binding blade pitch authority to throttle should traverse along that limited region. That being said, I wouldn’t bind pitch to the throttle, but translation F/B, and let the throttle control the RPM. In addition, pitch beyond 100 isn’t useless at all. I’ve found that blade type B is most effective for takeoff when deployed at 115, then you reduce the deployment (i.e. increase blade pitch) as you roll down the runway to pick up more speed. Blade pitch is pretty much an air-based gearbox.

This update is so great. Really enjoying trying to learn about variable pitch and constant speed propellers by messing around. A small thing I'd like to see though - regarding action grouping, it'd be really nice to be able to reverse the deployment direction for blades and control surfaces via action group, as this would allow quick reverse thrust on landing. It can already be done by incrementally limiting authority, but a quicker method would nonetheless be nice. Another thing would be to have a 0.625m equivalent air breathing turboshaft for smaller aircraft, or at least more 0.625m LOX tank options to use with electric rotors and fuel cells.

The slowness isn't temporary though like you'd expect from a few calculations, it keeps persisting for as long as the game runs. In task manager, CPU usage jumps from ~25% to 95%, and stays there until i reboot the game. Are there any mods Snacks is incompatible with, say Restock or Stockalike Station Parts, etc.? Those are the only two that I can think of that integrate Snacks into their parts.

Is this what's causing excessive stress on my computer? When I'm playing KSP, everything runs smoothly until I click on the Snacks! icon while piloting a ship, upon which the entire game starts lagging out/stuttering like crazy.